waruqi

--[[ json.lua

A compact pure-Lua JSON library.
The main functions are: json.stringify, json.parse.

## json.stringify:

This expects the following to be true of any tables being encoded:
 * They only have string or number keys. Number keys must be represented as
   strings in json; this is part of the json spec.

waruqi

@implementation UIImage (Decompressed)
+ (UIImage *)decompressedImageWithContentsOfFile:(NSString *)path
{
    NSDictionary *dict = @{(id)kCGImageSourceShouldCache : @(YES)};
    
    NSData * data = [NSData dataWithContentsOfFile:path];
    
    if (data == nil) {
        return nil;
    }

waruqi

#!/bin/bash

if [ $1 == "1" ]; then
    echo "start proxy on 127.0.0.1:8888"
    adb reverse tcp:8888 tcp:8888
    adb shell settings put global http_proxy 127.0.0.1:8888
    adb shell settings put global https_proxy 127.0.0.1:8888
else
    echo "stop proxy on 127.0.0.1:8888"
    adb reverse --remove tcp:8888

waruqi

# extract audio
ffmpeg -i input.mov -f mp3 audio.mp3

# merge audio
ffmpeg -i input.mov -i audio2.mp3 -c:v copy -c:a aac -strict experimental -map 0:v:0 -map 1:a:0 output.mp4

waruqi

Comparing assembler syntax

A variety of assemblers are available for programming on Intel machines. In this gist, commonalities and differences between them are illustrated. This exploration does not expose the ability of most assemblers to lex/parse different code syntax such as Intel or AT&T, and variations for 32 and 64 bit. Examples of some syntax variations are shown to illustrate. Effort has been taken to reduce the syntax differences to only those absolutely necessary.

waruqi

Colours in terminal

It's a common confusion about terminal colours... Actually we have this:

• plain ascii
• ansi escape codes (16 colour codes with bold/italic and background)
• 256 colour palette (216 colours + 16 ansi + 24 gray) (colors are 24bit)
• 24bit true colour ("888" colours (aka 16 milion))

printf "\x1b[${bg};2;${red};${green};${blue}m\n"

waruqi

引用源地址

语义化的版本控制 2.0.0-rc.1

在软件管理世界里存在着被称作“依赖地狱”的死亡之谷，系统规模越大，引入的程序包越多，你就越有可能在不久的将来发现自己深陷绝望之中。

在多依赖的系统中发布新版本程序包很快成为噩梦。如果依赖关系过紧密，可能面临版本控制被锁死的风险（必须对每一个依赖程序包改版才能完成某次升级）。而如果依赖关系过于松散，又无法避免版本混乱（\产生超过合理值的版本数/）。当你项目的进展由于版本控制被锁死和/或版本混乱变得不那么简便和可靠，也就意味着你正处于依赖地狱之中。

为了解决这个问题，我提议通过一些规则和约束来表述版本号如何命名及何时更新。要使此系统正常运作，你首先需要声明一个公共应用程序接口（以下简称API）。可以\以文档形式或代码形式实施/。需要注意的是，这个API必须是清晰和明确的。一旦公共API确定下来，你将通过版本号增量来描述版本修改。形如X.Y.Z（主版本号.副版本号.补丁号）这样的版本格式。通过增加补丁号来表示不影响API的错误修复，增加副版本号来表示兼容现有API的扩展/修改，而增加主版本号则表示不兼容现有API的修改。

waruqi

#!/bin/sh

palette="/tmp/palette.png"

filters="fps=$4,scale=$3:-1:flags=lanczos"

ffmpeg -v warning -i $1 -vf "$filters,palettegen" -y $palette
ffmpeg -v warning -i $1 -i $palette -lavfi "$filters [x]; [x][1:v] paletteuse" -y $2

waruqi

#!/usr/bin/env python

import os
import sys
import struct
import time
from opster import command, dispatch

header = struct.Struct('iii')

waruqi

# set prefix: Ctrl + x
set -g prefix C-x
unbind C-b

# split window
unbind '"'  
bind - splitw -v   
unbind %  
bind | splitw -h