remove some files

5 years ago · e3646ee1a6
parent 1ab4ddd688
commit e3646ee1a6
8 changed files with 1 additions and 2914 deletions
--- a/API.md
+++ b/API.md
@ -1,857 +0,0 @@
 Redis Modules: an introduction to the API
 ===
 The modules documentation is composed of the following files:
 * `INTRO.md` (this file). An overview about Redis Modules system and API. It's a good idea to start your reading here.
 * `API.md` is generated from module.c top comments of RedisMoule functions. It is a good reference in order to understand how each function works.
 * `TYPES.md` covers the implementation of native data types into modules.
 * `BLOCK.md` shows how to write blocking commands that will not reply immediately, but will block the client, without blocking the Redis server, and will provide a reply whenever will be possible.
 Redis modules make possible to extend Redis functionality using external
 modules, implementing new Redis commands at a speed and with features
 similar to what can be done inside the core itself.
 Redis modules are dynamic libraries, that can be loaded into Redis at
 startup or using the `MODULE LOAD` command. Redis exports a C API, in the
 form of a single C header file called `redismodule.h`. Modules are meant
 to be written in C, however it will be possible to use C++ or other languages
 that have C binding functionalities.
 Modules are designed in order to be loaded into different versions of Redis,
 so a given module does not need to be designed, or recompiled, in order to
 run with a specific version of Redis. For this reason, the module will
 register to the Redis core using a specific API version. The current API
 version is "1".
 This document is about an alpha version of Redis modules. API, functionalities
 and other details may change in the future.
 # Loading modules
 In order to test the module you are developing, you can load the module
 using the following `redis.conf` configuration directive:
    loadmodule /path/to/mymodule.so
 It is also possible to load a module at runtime using the following command:
    MODULE LOAD /path/to/mymodule.so
 In order to list all loaded modules, use:
    MODULE LIST
 Finally, you can unload (and later reload if you wish) a module using the
 following command:
    MODULE UNLOAD mymodule
 Note that `mymodule` above is not the filename without the `.so` suffix, but
 instead, the name the module used to register itself into the Redis core.
 The name can be obtained using `MODULE LIST`. However it is good practice
 that the filename of the dynamic library is the same as the name the module
 uses to register itself into the Redis core.
 # The simplest module you can write
 In order to show the different parts of a module, here we'll show a very
 simple module that implements a command that outputs a random number.
    #include "redismodule.h"
    #include <stdlib.h>
    int HelloworldRand_RedisCommand(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
        RedisModule_ReplyWithLongLong(ctx,rand());
        return REDISMODULE_OK;
    }
    int RedisModule_OnLoad(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
        if (RedisModule_Init(ctx,"helloworld",1,REDISMODULE_APIVER_1)
            == REDISMODULE_ERR) return REDISMODULE_ERR;
        if (RedisModule_CreateCommand(ctx,"helloworld.rand",
            HelloworldRand_RedisCommand) == REDISMODULE_ERR)
            return REDISMODULE_ERR;
        return REDISMODULE_OK;
    }
 The example module has two functions. One implements a command called
 HELLOWORLD.RAND. This function is specific of that module. However the
 other function called `RedisModule_OnLoad()` must be present in each
 Redis module. It is the entry point for the module to be initialized,
 register its commands, and potentially other private data structures
 it uses.
 Note that it is a good idea for modules to call commands with the
 name of the module followed by a dot, and finally the command name,
 like in the case of `HELLOWORLD.RAND`. This way it is less likely to
 have collisions.
 Note that if different modules have colliding commands, they'll not be
 able to work in Redis at the same time, since the function
 `RedisModule_CreateCommand` will fail in one of the modules, so the module
 loading will abort returning an error condition.
 # Module initialization
 The above example shows the usage of the function `RedisModule_Init()`.
 It should be the first function called by the module `OnLoad` function.
 The following is the function prototype:
    int RedisModule_Init(RedisModuleCtx *ctx, const char *modulename,
                         int module_version, int api_version);
 The `Init` function announces the Redis core that the module has a given
 name, its version (that is reported by `MODULE LIST`), and that is willing
 to use a specific version of the API.
 If the API version is wrong, the name is already taken, or there are other
 similar errors, the function will return `REDISMODULE_ERR`, and the module
 `OnLoad` function should return ASAP with an error.
 Before the `Init` function is called, no other API function can be called,
 otherwise the module will segfault and the Redis instance will crash.
 The second function called, `RedisModule_CreateCommand`, is used in order
 to register commands into the Redis core. The following is the prototype:
    int RedisModule_CreateCommand(RedisModuleCtx *ctx, const char *cmdname,
                                  RedisModuleCmdFunc cmdfunc);
 As you can see, most Redis modules API calls all take as first argument
 the `context` of the module, so that they have a reference to the module
 calling it, to the command and client executing a given command, and so forth.
 To create a new command, the above function needs the context, the command
 name, and the function pointer of the function implementing the command,
 which must have the following prototype:
    int mycommand(RedisModuleCtx *ctx, RedisModuleString **argv, int argc);
 The command function arguments are just the context, that will be passed
 to all the other API calls, the command argument vector, and total number
 of arguments, as passed by the user.
 As you can see, the arguments are provided as pointers to a specific data
 type, the `RedisModuleString`. This is an opaque data type you have API
 functions to access and use, direct access to its fields is never needed.
 Zooming into the example command implementation, we can find another call:
    int RedisModule_ReplyWithLongLong(RedisModuleCtx *ctx, long long integer);
 This function returns an integer to the client that invoked the command,
 exactly like other Redis commands do, like for example `INCR` or `SCARD`.
 # Setup and dependencies of a Redis module
 Redis modules don't depend on Redis or some other library, nor they
 need to be compiled with a specific `redismodule.h` file. In order
 to create a new module, just copy a recent version of `redismodule.h`
 in your source tree, link all the libraries you want, and create
 a dynamic library having the `RedisModule_OnLoad()` function symbol
 exported.
 The module will be able to load into different versions of Redis.
 # Passing configuration parameters to Redis modules
 When the module is loaded with the `MODULE LOAD` command, or using the
 `loadmodule` directive in the `redis.conf` file, the user is able to pass
 configuration parameters to the module by adding arguments after the module
 file name:
    loadmodule mymodule.so foo bar 1234
 In the above example the strings `foo`, `bar` and `123` will be passed
 to the module `OnLoad()` function in the `argv` argument as an array
 of RedisModuleString pointers. The number of arguments passed is into `argc`.
 The way you can access those strings will be explained in the rest of this
 document. Normally the module will store the module configuration parameters
 in some `static` global variable that can be accessed module wide, so that
 the configuration can change the behavior of different commands.
 # Working with RedisModuleString objects
 The command argument vector `argv` passed to module commands, and the
 return value of other module APIs functions, are of type `RedisModuleString`.
 Usually you directly pass module strings to other API calls, however sometimes
 you may need to directly access the string object.
 There are a few functions in order to work with string objects:
    const char *RedisModule_StringPtrLen(RedisModuleString *string, size_t *len);
 The above function accesses a string by returning its pointer and setting its
 length in `len`.
 You should never write to a string object pointer, as you can see from the
 `const` pointer qualifier.
 However, if you want, you can create new string objects using the following
 API:
    RedisModuleString *RedisModule_CreateString(RedisModuleCtx *ctx, const char *ptr, size_t len);
 The string returned by the above command must be freed using a corresponding
 call to `RedisModule_FreeString()`:
    void RedisModule_FreeString(RedisModuleString *str);
 However if you want to avoid having to free strings, the automatic memory
 management, covered later in this document, can be a good alternative, by
 doing it for you.
 Note that the strings provided via the argument vector `argv` never need
 to be freed. You only need to free new strings you create, or new strings
 returned by other APIs, where it is specified that the returned string must
 be freed.
 ## Creating strings from numbers or parsing strings as numbers
 Creating a new string from an integer is a very common operation, so there
 is a function to do this:
    RedisModuleString *mystr = RedisModule_CreateStringFromLongLong(ctx,10);
 Similarly in order to parse a string as a number:
    long long myval;
    if (RedisModule_StringToLongLong(argv[1],&myval) == REDISMODULE_OK) {
        /* Do something with 'myval' */
    }
 ## Accessing Redis keys from modules
 Most Redis modules, in order to be useful, have to interact with the Redis
 data space (this is not always true, for example an ID generator may
 never touch Redis keys). Redis modules have two different APIs in order to
 access the Redis data space, one is a low level API that provides very
 fast access and a set of functions to manipulate Redis data structures.
 The other API is more high level, and allows to call Redis commands and
 fetch the result, similarly to how Lua scripts access Redis.
 The high level API is also useful in order to access Redis functionalities
 that are not available as APIs.
 In general modules developers should prefer the low level API, because commands
 implemented using the low level API run at a speed comparable to the speed
 of native Redis commands. However there are definitely use cases for the
 higher level API. For example often the bottleneck could be processing the
 data and not accessing it.
 Also note that sometimes using the low level API is not harder compared to
 the higher level one.
 # Calling Redis commands
 The high level API to access Redis is the sum of the `RedisModule_Call()`
 function, together with the functions needed in order to access the
 reply object returned by `Call()`.
 `RedisModule_Call` uses a special calling convention, with a format specifier
 that is used to specify what kind of objects you are passing as arguments
 to the function.
 Redis commands are invoked just using a command name and a list of arguments.
 However when calling commands, the arguments may originate from different
 kind of strings: null-terminated C strings, RedisModuleString objects as
 received from the `argv` parameter in the command implementation, binary
 safe C buffers with a pointer and a length, and so forth.
 For example if I want to call `INCRBY` using a first argument (the key)
 a string received in the argument vector `argv`, which is an array
 of RedisModuleString object pointers, and a C string representing the
 number "10" as second argument (the increment), I'll use the following
 function call:
    RedisModuleCallReply *reply;
    reply = RedisModule_Call(ctx,"INCR","sc",argv[1],"10");
 The first argument is the context, and the second is always a null terminated
 C string with the command name. The third argument is the format specifier
 where each character corresponds to the type of the arguments that will follow.
 In the above case `"sc"` means a RedisModuleString object, and a null
 terminated C string. The other arguments are just the two arguments as
 specified. In fact `argv[1]` is a RedisModuleString and `"10"` is a null
 terminated C string.
 This is the full list of format specifiers:
 * **c** -- Null terminated C string pointer.
 * **b** -- C buffer, two arguments needed: C string pointer and `size_t` length.
 * **s** -- RedisModuleString as received in `argv` or by other Redis module APIs returning a RedisModuleString object.
 * **l** -- Long long integer.
 * **v** -- Array of RedisModuleString objects.
 * **!** -- This modifier just tells the function to replicate the command to slaves and AOF. It is ignored from the point of view of arguments parsing.
 The function returns a `RedisModuleCallReply` object on success, on
 error NULL is returned.
 NULL is returned when the command name is invalid, the format specifier uses
 characters that are not recognized, or when the command is called with the
 wrong number of arguments. In the above cases the `errno` var is set to `EINVAL`. NULL is also returned when, in an instance with Cluster enabled, the target
 keys are about non local hash slots. In this case `errno` is set to `EPERM`.
 ## Working with RedisModuleCallReply objects.
 `RedisModuleCall` returns reply objects that can be accessed using the
 `RedisModule_CallReply*` family of functions.
 In order to obtain the type or reply (corresponding to one of the data types
 supported by the Redis protocol), the function `RedisModule_CallReplyType()`
 is used:
    reply = RedisModule_Call(ctx,"INCR","sc",argv[1],"10");
    if (RedisModule_CallReplyType(reply) == REDISMODULE_REPLY_INTEGER) {
        long long myval = RedisModule_CallReplyInteger(reply);
        /* Do something with myval. */
    }
 Valid reply types are:
 * `REDISMODULE_REPLY_STRING` Bulk string or status replies.
 * `REDISMODULE_REPLY_ERROR` Errors.
 * `REDISMODULE_REPLY_INTEGER` Signed 64 bit integers.
 * `REDISMODULE_REPLY_ARRAY` Array of replies.
 * `REDISMODULE_REPLY_NULL` NULL reply.
 Strings, errors and arrays have an associated length. For strings and errors
 the length corresponds to the length of the string. For arrays the length
 is the number of elements. To obtain the reply length the following function
 is used:
    size_t reply_len = RedisModule_CallReplyLength(reply);
 In order to obtain the value of an integer reply, the following function is used, as already shown in the example above:
    long long reply_integer_val = RedisModule_CallReplyInteger(reply);
 Called with a reply object of the wrong type, the above function always
 returns `LLONG_MIN`.
 Sub elements of array replies are accessed this way:
    RedisModuleCallReply *subreply;
    subreply = RedisModule_CallReplyArrayElement(reply,idx);
 The above function returns NULL if you try to access out of range elements.
 Strings and errors (which are like strings but with a different type) can
 be accessed using in the following way, making sure to never write to
 the resulting pointer (that is returned as as `const` pointer so that
 misusing must be pretty explicit):
    size_t len;
    char *ptr = RedisModule_CallReplyStringPtr(reply,&len);
 If the reply type is not a string or an error, NULL is returned.
 RedisCallReply objects are not the same as module string objects
 (RedisModuleString types). However sometimes you may need to pass replies
 of type string or integer, to API functions expecting a module string.
 When this is the case, you may want to evaluate if using the low level
 API could be a simpler way to implement your command, or you can use
 the following function in order to create a new string object from a
 call reply of type string, error or integer:
    RedisModuleString *mystr = RedisModule_CreateStringFromCallReply(myreply);
 If the reply is not of the right type, NULL is returned.
 The returned string object should be released with `RedisModule_FreeString()`
 as usually, or by enabling automatic memory management (see corresponding
 section).
 # Releasing call reply objects
 Reply objects must be freed using `RedisModule_FreeCallReply`. For arrays,
 you need to free only the top level reply, not the nested replies.
 Currently the module implementation provides a protection in order to avoid
 crashing if you free a nested reply object for error, however this feature
 is not guaranteed to be here forever, so should not be considered part
 of the API.
 If you use automatic memory management (explained later in this document)
 you don't need to free replies (but you still could if you wish to release
 memory ASAP).
 ## Returning values from Redis commands
 Like normal Redis commands, new commands implemented via modules must be
 able to return values to the caller. The API exports a set of functions for
 this goal, in order to return the usual types of the Redis protocol, and
 arrays of such types as elemented. Also errors can be returned with any
 error string and code (the error code is the initial uppercase letters in
 the error message, like the "BUSY" string in the "BUSY the sever is busy" error
 message).
 All the functions to send a reply to the client are called
 `RedisModule_ReplyWith<something>`.
 To return an error, use:
    RedisModule_ReplyWithError(RedisModuleCtx *ctx, const char *err);
 There is a predefined error string for key of wrong type errors:
    REDISMODULE_ERRORMSG_WRONGTYPE
 Example usage:
    RedisModule_ReplyWithError(ctx,"ERR invalid arguments");
 We already saw how to reply with a long long in the examples above:
    RedisModule_ReplyWithLongLong(ctx,12345);
 To reply with a simple string, that can't contain binary values or newlines,
 (so it's suitable to send small words, like "OK") we use:
    RedisModule_ReplyWithSimpleString(ctx,"OK");
 It's possible to reply with "bulk strings" that are binary safe, using
 two different functions:
    int RedisModule_ReplyWithStringBuffer(RedisModuleCtx *ctx, const char *buf, size_t len);
    int RedisModule_ReplyWithString(RedisModuleCtx *ctx, RedisModuleString *str);
 The first function gets a C pointer and length. The second a RedisMoudleString
 object. Use one or the other depending on the source type you have at hand.
 In order to reply with an array, you just need to use a function to emit the
 array length, followed by as many calls to the above functions as the number
 of elements of the array are:
    RedisModule_ReplyWithArray(ctx,2);
    RedisModule_ReplyWithStringBuffer(ctx,"age",3);
    RedisModule_ReplyWithLongLong(ctx,22);
 To return nested arrays is easy, your nested array element just uses another
 call to `RedisModule_ReplyWithArray()` followed by the calls to emit the
 sub array elements.
 ## Returning arrays with dynamic length
 Sometimes it is not possible to know beforehand the number of items of
 an array. As an example, think of a Redis module implementing a FACTOR
 command that given a number outputs the prime factors. Instead of
 factorializing the number, storing the prime factors into an array, and
 later produce the command reply, a better solution is to start an array
 reply where the length is not known, and set it later. This is accomplished
 with a special argument to `RedisModule_ReplyWithArray()`:
    RedisModule_ReplyWithArray(ctx, REDISMODULE_POSTPONED_ARRAY_LEN);
 The above call starts an array reply so we can use other `ReplyWith` calls
 in order to produce the array items. Finally in order to set the length
 se use the following call:
    RedisModule_ReplySetArrayLength(ctx, number_of_items);
 In the case of the FACTOR command, this translates to some code similar
 to this:
    RedisModule_ReplyWithArray(ctx, REDISMODULE_POSTPONED_ARRAY_LEN);
    number_of_factors = 0;
    while(still_factors) {
        RedisModule_ReplyWithLongLong(ctx, some_factor);
        number_of_factors++;
    }
    RedisModule_ReplySetArrayLength(ctx, number_of_factors);
 Another common use case for this feature is iterating over the arrays of
 some collection and only returning the ones passing some kind of filtering.
 It is possible to have multiple nested arrays with postponed reply.
 Each call to `SetArray()` will set the length of the latest corresponding
 call to `ReplyWithArray()`:
    RedisModule_ReplyWithArray(ctx, REDISMODULE_POSTPONED_ARRAY_LEN);
    ... generate 100 elements ...
    RedisModule_ReplyWithArray(ctx, REDISMODULE_POSTPONED_ARRAY_LEN);
    ... generate 10 elements ...
    RedisModule_ReplySetArrayLength(ctx, 10);
    RedisModule_ReplySetArrayLength(ctx, 100);
 This creates a 100 items array having as last element a 10 items array.
 # Arity and type checks
 Often commands need to check that the number of arguments and type of the key
 is correct. In order to report a wrong arity, there is a specific function
 called `RedisModule_WrongArity()`. The usage is trivial:
    if (argc != 2) return RedisModule_WrongArity(ctx);
 Checking for the wrong type involves opening the key and checking the type:
    RedisModuleKey *key = RedisModule_OpenKey(ctx,argv[1],
        REDISMODULE_READ|REDISMODULE_WRITE);
    int keytype = RedisModule_KeyType(key);
    if (keytype != REDISMODULE_KEYTYPE_STRING &&
        keytype != REDISMODULE_KEYTYPE_EMPTY)
    {
        RedisModule_CloseKey(key);
        return RedisModule_ReplyWithError(ctx,REDISMODULE_ERRORMSG_WRONGTYPE);
    }
 Note that you often want to proceed with a command both if the key
 is of the expected type, or if it's empty.
 ## Low level access to keys
 Low level access to keys allow to perform operations on value objects associated
 to keys directly, with a speed similar to what Redis uses internally to
 implement the built-in commands.
 Once a key is opened, a key pointer is returned that will be used with all the
 other low level API calls in order to perform operations on the key or its
 associated value.
 Because the API is meant to be very fast, it cannot do too many run-time
 checks, so the user must be aware of certain rules to follow:
 * Opening the same key multiple times where at least one instance is opened for writing, is undefined and may lead to crashes.
 * While a key is open, it should only be accessed via the low level key API. For example opening a key, then calling DEL on the same key using the `RedisModule_Call()` API will result into a crash. However it is safe to open a key, perform some operation with the low level API, closing it, then using other APIs to manage the same key, and later opening it again to do some more work.
 In order to open a key the `RedisModule_OpenKey` function is used. It returns
 a key pointer, that we'll use with all the next calls to access and modify
 the value:
    RedisModuleKey *key;
    key = RedisModule_OpenKey(ctx,argv[1],REDISMODULE_READ);
 The second argument is the key name, that must be a `RedisModuleString` object.
 The third argument is the mode: `REDISMODULE_READ` or `REDISMODULE_WRITE`.
 It is possible to use `|` to bitwise OR the two modes to open the key in
 both modes. Currently a key opened for writing can also be accessed for reading
 but this is to be considered an implementation detail. The right mode should
 be used in sane modules.
 You can open non exisitng keys for writing, since the keys will be created
 when an attempt to write to the key is performed. However when opening keys
 just for reading, `RedisModule_OpenKey` will return NULL if the key does not
 exist.
 Once you are done using a key, you can close it with:
    RedisModule_CloseKey(key);
 Note that if automatic memory management is enabled, you are not forced to
 close keys. When the module function returns, Redis will take care to close
 all the keys which are still open.
 ## Getting the key type
 In order to obtain the value of a key, use the `RedisModule_KeyType()` function:
    int keytype = RedisModule_KeyType(key);
 It returns one of the following values:
    REDISMODULE_KEYTYPE_EMPTY
    REDISMODULE_KEYTYPE_STRING
    REDISMODULE_KEYTYPE_LIST
    REDISMODULE_KEYTYPE_HASH
    REDISMODULE_KEYTYPE_SET
    REDISMODULE_KEYTYPE_ZSET
 The above are just the usual Redis key types, with the addition of an empty
 type, that signals the key pointer is associated with an empty key that
 does not yet exists.
 ## Creating new keys
 To create a new key, open it for writing and then write to it using one
 of the key writing functions. Example:
    RedisModuleKey *key;
    key = RedisModule_OpenKey(ctx,argv[1],REDISMODULE_READ);
    if (RedisModule_KeyType(key) == REDISMODULE_KEYTYPE_EMPTY) {
        RedisModule_StringSet(key,argv[2]);
    }
 ## Deleting keys
 Just use:
    RedisModule_DeleteKey(key);
 The function returns `REDISMODULE_ERR` if the key is not open for writing.
 Note that after a key gets deleted, it is setup in order to be targeted
 by new key commands. For example `RedisModule_KeyType()` will return it is
 an empty key, and writing to it will create a new key, possibly of another
 type (depending on the API used).
 ## Managing key expires (TTLs)
 To control key expires two functions are provided, that are able to set,
 modify, get, and unset the time to live associated with a key.
 One function is used in order to query the current expire of an open key:
    mstime_t RedisModule_GetExpire(RedisModuleKey *key);
 The function returns the time to live of the key in milliseconds, or
 `REDISMODULE_NO_EXPIRE` as a special value to signal the key has no associated
 expire or does not exist at all (you can differentiate the two cases checking
 if the key type is `REDISMODULE_KEYTYPE_EMPTY`).
 In order to change the expire of a key the following function is used instead:
    int RedisModule_SetExpire(RedisModuleKey *key, mstime_t expire);
 When called on a non existing key, `REDISMODULE_ERR` is returned, because
 the function can only associate expires to existing open keys (non existing
 open keys are only useful in order to create new values with data type
 specific write operations).
 Again the `expire` time is specified in milliseconds. If the key has currently
 no expire, a new expire is set. If the key already have an expire, it is
 replaced with the new value.
 If the key has an expire, and the special value `REDISMODULE_NO_EXPIRE` is
 used as a new expire, the expire is removed, similarly to the Redis
 `PERSIST` command. In case the key was already persistent, no operation is
 performed.
 ## Obtaining the length of values
 There is a single function in order to retrieve the length of the value
 associated to an open key. The returned length is value-specific, and is
 the string length for strings, and the number of elements for the aggregated
 data types (how many elements there is in a list, set, sorted set, hash).
    size_t len = RedisModule_ValueLength(key);
 If the key does not exist, 0 is returned by the function:
 ## String type API
 Setting a new string value, like the Redis `SET` command does, is performed
 using:
    int RedisModule_StringSet(RedisModuleKey *key, RedisModuleString *str);
 The function works exactly like the Redis `SET` command itself, that is, if
 there is a prior value (of any type) it will be deleted.
 Accessing existing string values is performed using DMA (direct memory
 access) for speed. The API will return a pointer and a length, so that's
 possible to access and, if needed, modify the string directly.
    size_t len, j;
    char *myptr = RedisModule_StringDMA(key,&len,REDISMODULE_WRITE);
    for (j = 0; j < len; j++) myptr[j] = 'A';
 In the above example we write directly on the string. Note that if you want
 to write, you must be sure to ask for `WRITE` mode.
 DMA pointers are only valid if no other operations are performed with the key
 before using the pointer, after the DMA call.
 Sometimes when we want to manipulate strings directly, we need to change
 their size as well. For this scope, the `RedisModule_StringTruncate` function
 is used. Example:
    RedisModule_StringTruncate(mykey,1024);
 The function truncates, or enlarges the string as needed, padding it with
 zero bytes if the previos length is smaller than the new length we request.
 If the string does not exist since `key` is associated to an open empty key,
 a string value is created and associated to the key.
 Note that every time `StringTruncate()` is called, we need to re-obtain
 the DMA pointer again, since the old may be invalid.
 ## List type API
 It's possible to push and pop values from list values:
    int RedisModule_ListPush(RedisModuleKey *key, int where, RedisModuleString *ele);
    RedisModuleString *RedisModule_ListPop(RedisModuleKey *key, int where);
 In both the APIs the `where` argument specifies if to push or pop from tail
 or head, using the following macros:
    REDISMODULE_LIST_HEAD
    REDISMODULE_LIST_TAIL
 Elements returned by `RedisModule_ListPop()` are like strings craeted with
 `RedisModule_CreateString()`, they must be released with
 `RedisModule_FreeString()` or by enabling automatic memory management.
 ## Set type API
 Work in progress.
 ## Sorted set type API
 Documentation missing, please refer to the top comments inside `module.c`
 for the following functions:
 * `RedisModule_ZsetAdd`
 * `RedisModule_ZsetIncrby`
 * `RedisModule_ZsetScore`
 * `RedisModule_ZsetRem`
 And for the sorted set iterator:
 * `RedisModule_ZsetRangeStop`
 * `RedisModule_ZsetFirstInScoreRange`
 * `RedisModule_ZsetLastInScoreRange`
 * `RedisModule_ZsetFirstInLexRange`
 * `RedisModule_ZsetLastInLexRange`
 * `RedisModule_ZsetRangeCurrentElement`
 * `RedisModule_ZsetRangeNext`
 * `RedisModule_ZsetRangePrev`
 * `RedisModule_ZsetRangeEndReached`
 ## Hash type API
 Documentation missing, please refer to the top comments inside `module.c`
 for the following functions:
 * `RedisModule_HashSet`
 * `RedisModule_HashGet`
 ## Iterating aggregated values
 Work in progress.
 # Replicating commands
 If you want to use module commands exactly like normal Redis commands, in the
 context of replicated Redis instances, or using the AOF file for persistence,
 it is important for module commands to handle their replication in a consistent
 way.
 When using the higher level APIs to invoke commands, replication happens
 automatically if you use the "!" modifier in the format string of
 `RedisModule_Call()` as in the following example:
    reply = RedisModule_Call(ctx,"INCR","!sc",argv[1],"10");
 As you can see the format specifier is `"!sc"`. The bang is not parsed as a
 format specifier, but it internally flags the command as "must replicate".
 If you use the above programming style, there are no problems.
 However sometimes things are more complex than that, and you use the low level
 API. In this case, if there are no side effects in the command execution, and
 it consistently always performs the same work, what is possible to do is to
 replicate the command verbatim as the user executed it. To do that, you just
 need to call the following function:
    RedisModule_ReplicateVerbatim(ctx);
 When you use the above API, you should not use any other replication function
 since they are not guaranteed to mix well.
 However this is not the only option. It's also possible to exactly tell
 Redis what commands to replicate as the effect of the command execution, using
 an API similar to `RedisModule_Call()` but that instead of calling the command
 sends it to the AOF / slaves stream. Example:
    RedisModule_Replicate(ctx,"INCRBY","cl","foo",my_increment);
 It's possible to call `RedisModule_Replicate` multiple times, and each
 will emit a command. All the sequence emitted is wrapped between a
 `MULTI/EXEC` transaction, so that the AOF and replication effects are the
 same as executing a single command.
 Note that `Call()` replication and `Replicate()` replication have a rule,
 in case you want to mix both forms of replication (not necessarily a good
 idea if there are simpler approaches). Commands replicated with `Call()`
 are always the first emitted in the final `MULTI/EXEC` block, while all
 the commands emitted with `Replicate()` will follow.
 # Automatic memory management
 Normally when writing programs in the C language, programmers need to manage
 memory manually. This is why the Redis modules API has functions to release
 strings, close open keys, free replies, and so forth.
 However given that commands are executed in a contained environment and
 with a set of strict APIs, Redis is able to provide automatic memory management
 to modules, at the cost of some performance (most of the time, a very low
 cost).
 When automatic memory management is enabled:
 1. You don't need to close open keys.
 2. You don't need to free replies.
 3. You don't need to free RedisModuleString objects.
 However you can still do it, if you want. For example, automatic memory
 management may be active, but inside a loop allocating a lot of strings,
 you may still want to free strings no longer used.
 In order to enable automatic memory management, just call the following
 function at the start of the command implementation:
    RedisModule_AutoMemory(ctx);
 Automatic memory management is usually the way to go, however experienced
 C programmers may not use it in order to gain some speed and memory usage
 benefit.
 # Allocating memory into modules
 Normal C programs use `malloc()` and `free()` in order to allocate and
 release memory dynamically. While in Redis modules the use of malloc is
 not technically forbidden, it is a lot better to use the Redis Modules
 specific functions, that are exact replacements for `malloc`, `free`,
 `realloc` and `strdup`. These functions are:
    void *RedisModule_Alloc(size_t bytes);
    void* RedisModule_Realloc(void *ptr, size_t bytes);
    void RedisModule_Free(void *ptr);
    void RedisModule_Calloc(size_t nmemb, size_t size);
    char *RedisModule_Strdup(const char *str);
 They work exactly like their `libc` equivalent calls, however they use
 the same allocator Redis uses, and the memory allocated using these
 functions is reported by the `INFO` command in the memory section, is
 accounted when enforcing the `maxmemory` policy, and in general is
 a first citizen of the Redis executable. On the contrar, the method
 allocated inside modules with libc `malloc()` is transparent to Redis.
 Another reason to use the modules functions in order to allocate memory
 is that, when creating native data types inside modules, the RDB loading
 functions can return deserialized strings (from the RDB file) directly
 as `RedisModule_Alloc()` allocations, so they can be used directly to
 populate data structures after loading, instead of having to copy them
 to the data structure.
 ## Pool allocator
 Sometimes in commands implementations, it is required to perform many
 small allocations that will be not retained at the end of the command
 execution, but are just functional to execute the command itself.
 This work can be more easily accomplished using the Redis pool allocator:
    void *RedisModule_PoolAlloc(RedisModuleCtx *ctx, size_t bytes);
 It works similarly to `malloc()`, and returns memory aligned to the
 next power of two of greater or equal to `bytes` (for a maximum alignment
 of 8 bytes). However it allocates memory in blocks, so it the overhead
 of the allocations is small, and more important, the memory allocated
 is automatically released when the command returns.
 So in general short living allocations are a good candidates for the pool
 allocator.
 # Writing commands compatible with Redis Cluster
 Documentation missing, please check the following functions inside `module.c`:
    RedisModule_IsKeysPositionRequest(ctx);
    RedisModule_KeyAtPos(ctx,pos);
--- a/BLOCK.md
+++ b/BLOCK.md
@ -1,265 +0,0 @@
 Blocking commands in Redis modules
 ===
 Redis has a few blocking commands among the built-in set of commands.
 One of the most used is `BLPOP` (or the symmetric `BRPOP`) which blocks
 waiting for elements arriving in a list.
 The interesting fact about blocking commands is that they do not block
 the whole server, but just the client calling them. Usually the reason to
 block is that we expect some external event to happen: this can be
 some change in the Redis data structures like in the `BLPOP` case, a
 long computation happening in a thread, to receive some data from the
 network, and so forth.
 Redis modules have the ability to implement blocking commands as well,
 this documentation shows how the API works and describes a few patterns
 that can be used in order to model blocking commands.
 How blocking and resuming works.
 ---
 _Note: You may want to check the `helloblock.c` example in the Redis source tree
 inside the `src/modules` directory, for a simple to understand example
 on how the blocking API is applied._
 In Redis modules, commands are implemented by callback functions that
 are invoked by the Redis core when the specific command is called
 by the user. Normally the callback terminates its execution sending
 some reply to the client. Using the following function instead, the
 function implementing the module command may request that the client
 is put into the blocked state:
    RedisModuleBlockedClient *RedisModule_BlockClient(RedisModuleCtx *ctx, RedisModuleCmdFunc reply_callback, RedisModuleCmdFunc timeout_callback, void (*free_privdata)(void*), long long timeout_ms);
 The function returns a `RedisModuleBlockedClient` object, which is later
 used in order to unblock the client. The arguments have the following
 meaning:
 * `ctx` is the command execution context as usually in the rest of the API.
 * `reply_callback` is the callback, having the same prototype of a normal command function, that is called when the client is unblocked in order to return a reply to the client.
 * `timeout_callback` is the callback, having the same prototype of a normal command function that is called when the client reached the `ms` timeout.
 * `free_privdata` is the callback that is called in order to free the private data. Private data is a pointer to some data that is passed between the API used to unblock the client, to the callback that will send the reply to the client. We'll see how this mechanism works later in this document.
 * `ms` is the timeout in milliseconds. When the timeout is reached, the timeout callback is called and the client is automatically aborted.
 Once a client is blocked, it can be unblocked with the following API:
    int RedisModule_UnblockClient(RedisModuleBlockedClient *bc, void *privdata);
 The function takes as argument the blocked client object returned by
 the previous call to `RedisModule_BlockClient()`, and unblock the client.
 Immediately before the client gets unblocked, the `reply_callback` function
 specified when the client was blocked is called: this function will
 have access to the `privdata` pointer used here.
 IMPORTANT: The above function is thread safe, and can be called from within
 a thread doing some work in order to implement the command that blocked
 the client.
 The `privdata` data will be freed automatically using the `free_privdata`
 callback when the client is unblocked. This is useful **since the reply
 callback may never be called** in case the client timeouts or disconnects
 from the server, so it's important that it's up to an external function
 to have the responsibility to free the data passed if needed.
 To better understand how the API works, we can imagine writing a command
 that blocks a client for one second, and then send as reply "Hello!".
 Note: arity checks and other non important things are not implemented
 int his command, in order to take the example simple.
    int Example_RedisCommand(RedisModuleCtx *ctx, RedisModuleString **argv,
                             int argc)
    {
        RedisModuleBlockedClient *bc =
            RedisModule_BlockClient(ctx,reply_func,timeout_func,NULL,0);
        pthread_t tid;
        pthread_create(&tid,NULL,threadmain,bc);
        return REDISMODULE_OK;
    }
    void *threadmain(void *arg) {
        RedisModuleBlockedClient *bc = arg;
        sleep(1); /* Wait one second and unblock. */
        RedisModule_UnblockClient(bc,NULL);
    }
 The above command blocks the client ASAP, spawining a thread that will
 wait a second and will unblock the client. Let's check the reply and
 timeout callbacks, which are in our case very similar, since they
 just reply the client with a different reply type.
    int reply_func(RedisModuleCtx *ctx, RedisModuleString **argv,
                   int argc)
    {
        return RedisModule_ReplyWithSimpleString(ctx,"Hello!");
    }
    int timeout_func(RedisModuleCtx *ctx, RedisModuleString **argv,
                   int argc)
    {
        return RedisModule_ReplyWithNull(ctx);
    }
 The reply callback just sends the "Hello!" string to the client.
 The important bit here is that the reply callback is called when the
 client is unblocked from the thread.
 The timeout command returns `NULL`, as it often happens with actual
 Redis blocking commands timing out.
 Passing reply data when unblocking
 ---
 The above example is simple to understand but lacks an important
 real world aspect of an actual blocking command implementation: often
 the reply function will need to know what to reply to the client,
 and this information is often provided as the client is unblocked.
 We could modify the above example so that the thread generates a
 random number after waiting one second. You can think at it as an
 actually expansive operation of some kind. Then this random number
 can be passed to the reply function so that we return it to the command
 caller. In order to make this working, we modify the functions as follow:
    void *threadmain(void *arg) {
        RedisModuleBlockedClient *bc = arg;
        sleep(1); /* Wait one second and unblock. */
        long *mynumber = RedisModule_Alloc(sizeof(long));
        *mynumber = rand();
        RedisModule_UnblockClient(bc,mynumber);
    }
 As you can see, now the unblocking call is passing some private data,
 that is the `mynumber` pointer, to the reply callback. In order to
 obtain this private data, the reply callback will use the following
 fnuction:
    void *RedisModule_GetBlockedClientPrivateData(RedisModuleCtx *ctx);
 So our reply callback is modified like that:
    int reply_func(RedisModuleCtx *ctx, RedisModuleString **argv,
                   int argc)
    {
        long *mynumber = RedisModule_GetBlockedClientPrivateData(ctx);
        /* IMPORTANT: don't free mynumber here, but in the
         * free privdata callback. */
        return RedisModule_ReplyWithLongLong(ctx,mynumber);
    }
 Note that we also need to pass a `free_privdata` function when blocking
 the client with `RedisModule_BlockClient()`, since the allocated
 long value must be freed. Our callback will look like the following:
    void free_privdata(void *privdata) {
        RedisModule_Free(privdata);
    }
 NOTE: It is important to stress that the private data is best freed in the
 `free_privdata` callback becaues the reply function may not be called
 if the client disconnects or timeout.
 Also note that the private data is also accessible from the timeout
 callback, always using the `GetBlockedClientPrivateData()` API.
 Aborting the blocking of a client
 ---
 One problem that sometimes arises is that we need to allocate resources
 in order to implement the non blocking command. So we block the client,
 then, for example, try to create a thread, but the thread creation function
 returns an error. What to do in such a condition in order to recover? We
 don't want to take the client blocked, nor we want to call `UnblockClient()`
 because this will trigger the reply callback to be called.
 In this case the best thing to do is to use the following function:
    int RedisModule_AbortBlock(RedisModuleBlockedClient *bc);
 Practically this is how to use it:
    int Example_RedisCommand(RedisModuleCtx *ctx, RedisModuleString **argv,
                             int argc)
    {
        RedisModuleBlockedClient *bc =
            RedisModule_BlockClient(ctx,reply_func,timeout_func,NULL,0);
        pthread_t tid;
        if (pthread_create(&tid,NULL,threadmain,bc) != 0) {
            RedisModule_AbortBlock(bc);
            RedisModule_ReplyWithError(ctx,"Sorry can't create a thread");
        }
        return REDISMODULE_OK;
    }
 The client will be unblocked but the reply callback will not be called.
 Implementing the command, reply and timeout callback using a single function
 ---
 The following functions can be used in order to implement the reply and
 callback with the same function that implements the primary command
 function:
    int RedisModule_IsBlockedReplyRequest(RedisModuleCtx *ctx);
    int RedisModule_IsBlockedTimeoutRequest(RedisModuleCtx *ctx);
 So I could rewrite the example command without using a separated
 reply and timeout callback:
    int Example_RedisCommand(RedisModuleCtx *ctx, RedisModuleString **argv,
                             int argc)
    {
        if (RedisModule_IsBlockedReplyRequest(ctx)) {
            long *mynumber = RedisModule_GetBlockedClientPrivateData(ctx);
            return RedisModule_ReplyWithLongLong(ctx,mynumber);
        } else if (RedisModule_IsBlockedTimeoutRequest) {
            return RedisModule_ReplyWithNull(ctx);
        }
        RedisModuleBlockedClient *bc =
            RedisModule_BlockClient(ctx,reply_func,timeout_func,NULL,0);
        pthread_t tid;
        if (pthread_create(&tid,NULL,threadmain,bc) != 0) {
            RedisModule_AbortBlock(bc);
            RedisModule_ReplyWithError(ctx,"Sorry can't create a thread");
        }
        return REDISMODULE_OK;
    }
 Functionally is the same but there are people that will prefer the less
 verbose implementation that concentrates most of the command logic in a
 single function.
 Working on copies of data inside a thread
 ---
 An interesting pattern in order to work with threads implementing the
 slow part of a command, is to work with a copy of the data, so that
 while some operation is performed in a key, the user continues to see
 the old version. However when the thread terminated its work, the
 representations are swapped and the new, processed version, is used.
 An example of this approach is the
 [Neural Redis module](https://github.com/antirez/neural-redis)
 where neural networks are trained in different threads while the
 user can still execute and inspect their older versions.
 Future work
 ---
 An API is work in progress right now in order to allow Redis modules APIs
 to be called in a safe way from threads, so that the threaded command
 can access the data space and do incremental operations.
 There is no ETA for this feature but it may appear in the course of the
 Redis 4.0 release at some point.
--- a/FUNCTIONS.md
+++ b/FUNCTIONS.md
--- a/2
+++ b/2
@ -8,7 +8,7 @@ ifndef RMUTIL_LIBDIR
 endif
 ifndef SRC_DIR
-	SRC_DIR=example
+	SRC_DIR=src
 endif
--- a/TYPES.md
+++ b/TYPES.md
@ -1,379 +0,0 @@
 Native types in Redis modules
 ===
 Redis modules can access Redis built-in data structures both at high level,
 by calling Redis commands, and at low level, by manipulating the data structures
 directly.
 By using these capabilities in order to build new abstractions on top of existing
 Redis data structures, or by using strings DMA in order to encode modules
 data structures into Redis strings, it is possible to create modules that
 *feel like* they are exporting new data types. However, for more complex
 problems, this is not enough, and the implementation of new data structures
 inside the module is needed.
 We call the ability of Redis modules to implement new data structures that
 feel like native Redis ones **native types support**. This document describes
 the API exported by the Redis modules system in order to create new data
 structures and handle the serialization in RDB files, the rewriting process
 in AOF, the type reporting via the `TYPE` command, and so forth.
 Overview of native types
 ---
 A module exporting a native type is composed of the following main parts:
 * The implementation of some kind of new data structure and of commands operating on the new data structure.
 * A set of callbacks that handle: RDB saving, RDB loading, AOF rewriting, releasing of a value associated with a key, calculation of a value digest (hash) to be used with the `DEBUG DIGEST` command.
 * A 9 characters name that is unique to each module native data type.
 * An encoding version, used to persist into RDB files a module-specific data version, so that a module will be able to load older representations from RDB files.
 While to handle RDB loading, saving and AOF rewriting may look complex as a first glance, the modules API provide very high level function for handling all this, without requiring the user to handle read/write errors, so in practical terms, writing a new data structure for Redis is a simple task.
 A **very easy** to understand but complete example of native type implementation
 is available inside the Redis distribution in the `/modules/hellotype.c` file.
 The reader is encouraged to read the documentation by looking at this example
 implementation to see how things are applied in the practice.
 Registering a new data type
 ===
 In order to register a new native type into the Redis core, the module needs
 to declare a global variable that will hold a reference to the data type.
 The API to register the data type will return a data type reference that will
 be stored in the global variable.
    static RedisModuleType *MyType;
    #define MYTYPE_ENCODING_VERSION 0
    int RedisModule_OnLoad(RedisModuleCtx *ctx) {
 	RedisModuleTypeMethods tm = {
 	    .version = REDISMODULE_TYPE_METHOD_VERSION,
 	    .rdb_load = MyTypeRDBLoad,
 	    .rdb_save = MyTypeRDBSave,
 	    .aof_rewrite = MyTypeAOFRewrite,
 	    .free = MyTypeFree
 	};
        MyType = RedisModule_CreateDataType("MyType-AZ",
 		MYTYPE_ENCODING_VERSION, &tm);
        if (MyType == NULL) return REDISMODULE_ERR;
    }
 As you can see from the example above, a single API call is needed in order to
 register the new type. However a number of function pointers are passed as
 arguments. Certain are optionals while some are mandatory. The above set
 of methods *must* be passed, while `.digest` and `.mem_usage` are optional
 and are currently not actually supported by the modules internals, so for
 now you can just ignore them.
 The `ctx` argument is the context that we receive in the `OnLoad` function.
 The type `name` is a 9 character name in the character set that includes
 from `A-Z`, `a-z`, `0-9`, plus the underscore `_` and minus `-` characters.
 Note that **this name must be unique** for each data type in the Redis
 ecosystem, so be creative, use both lower-case and upper case if it makes
 sense, and try to use the convention of mixing the type name with the name
 of the author of the module, to create a 9 character unique name.
 **NOTE:** It is very important that the name is exactly 9 chars or the
 registration of the type will fail. Read more to understand why.
 For example if I'm building a *b-tree* data structure and my name is *antirez*
 I'll call my type **btree1-az**. The name, converted to a 64 bit integer,
 is stored inside the RDB file when saving the type, and will be used when the
 RDB data is loaded in order to resolve what module can load the data. If Redis
 finds no matching module, the integer is converted back to a name in order to
 provide some clue to the user about what module is missing in order to load
 the data.
 The type name is also used as a reply for the `TYPE` command when called
 with a key holding the registered type.
 The `encver` argument is the encoding version used by the module to store data
 inside the RDB file. For example I can start with an encoding version of 0,
 but later when I release version 2.0 of my module, I can switch encoding to
 something better. The new module will register with an encoding version of 1,
 so when it saves new RDB files, the new version will be stored on disk. However
 when loading RDB files, the module `rdb_load` method will be called even if
 there is data found for a different encoding version (and the encoding version
 is passed as argument to `rdb_load`), so that the module can still load old
 RDB files.
 The last argument is a structure used in order to pass the type methods to the
 registration function: `rdb_load`, `rdb_save`, `aof_rewrite`, `digest` and
 `free` and `mem_usage` are all callbacks with the following prototypes and uses:
    typedef void *(*RedisModuleTypeLoadFunc)(RedisModuleIO *rdb, int encver);
    typedef void (*RedisModuleTypeSaveFunc)(RedisModuleIO *rdb, void *value);
    typedef void (*RedisModuleTypeRewriteFunc)(RedisModuleIO *aof, RedisModuleString *key, void *value);
    typedef size_t (*RedisModuleTypeMemUsageFunc)(void *value);
    typedef void (*RedisModuleTypeDigestFunc)(RedisModuleDigest *digest, void *value);
    typedef void (*RedisModuleTypeFreeFunc)(void *value);
 * `rdb_load` is called when loading data from the RDB file. It loads data in the same format as `rdb_save` produces.
 * `rdb_save` is called when saving data to the RDB file.
 * `aof_rewrite` is called when the AOF is being rewritten, and the module needs to tell Redis what is the sequence of commands to recreate the content of a given key.
 * `digest` is called when `DEBUG DIGEST` is executed and a key holding this module type is found. Currently this is not yet implemented so the function ca be left empty.
 * `mem_usage` is called when the `MEMORY` command ask for the total memory consumed by a specific key, and is used in order to get the amount of bytes used by the module value.
 * `free` is called when a key with the module native type is deleted via `DEL` or in any other mean, in order to let the module reclaim the memory associated with such a value.
 Ok, but *why* modules types require a 9 characters name?
 ---
 Oh, I understand you need to understand this, so here is a very specific
 explanation.
 When Redis persists to RDB files, modules specific data types require to
 be persisted as well. Now RDB files are sequences of key-value pairs
 like the following:
    [1 byte type] [key] [a type specific value]
 The 1 byte type identifies strings, lists, sets, and so forth. In the case
 of modules data, it is set to a special value of `module data`, but of
 course this is not enough, we need the information needed to link a specific
 value with a specific module type that is able to load and handle it.
 So when we save a `type specific value` about a module, we prefix it with
 a 64 bit integer. 64 bits is large enough to store the informations needed
 in order to lookup the module that can handle that specific type, but is
 short enough that we can prefix each module value we store inside the RDB
 without making the final RDB file too big. At the same time, this solution
 of prefixing the value with a 64 bit *signature* does not require to do
 strange things like defining in the RDB header a list of modules specific
 types. Everything is pretty simple.
 So, what you can store in 64 bits in order to identify a given module in
 a reliable way? Well if you build a character set of 64 symbols, you can
 easily store 9 characters of 6 bits, and you are left with 10 bits, that
 are used in order to store the *encoding version* of the type, so that
 the same type can evolve in the future and provide a different and more
 efficient or updated serialization format for RDB files.
 So the 64 bit prefix stored before each module value is like the following:
    6|6|6|6|6|6|6|6|6|10
 The first 9 elements are 6-bits characters, the final 10 bits is the
 encoding version.
 When the RDB file is loaded back, it reads the 64 bit value, masks the final
 10 bits, and searches for a matching module in the modules types cache.
 When a matching one is found, the method to load the RDB file value is called
 with the 10 bits encoding version as argument, so that the module knows
 what version of the data layout to load, if it can support multiple versions.
 Now the interesting thing about all this is that, if instead the module type
 cannot be resolved, since there is no loaded module having this signature,
 we can convert back the 64 bit value into a 9 characters name, and print
 an error to the user that includes the module type name! So that she or he
 immediately realizes what's wrong.
 Setting and getting keys
 ---
 After registering our new data type in the `RedisModule_OnLoad()` function,
 we also need to be able to set Redis keys having as value our native type.
 This normally happens in the context of commands that write data to a key.
 The native types API allow to set and get keys to module native data types,
 and to test if a given key is already associated to a value of a specific data
 type.
 The API uses the normal modules `RedisModule_OpenKey()` low level key access
 interface in order to deal with this. This is an eaxmple of setting a
 native type private data structure to a Redis key:
    RedisModuleKey *key = RedisModule_OpenKey(ctx,keyname,REDISMODULE_WRITE);
    struct some_private_struct *data = createMyDataStructure();
    RedisModule_ModuleTypeSetValue(key,MyType,data);
 The function `RedisModule_ModuleTypeSetValue()` is used with a key handle open
 for writing, and gets three arguments: the key handle, the reference to the
 native type, as obtained during the type registration, and finally a `void*`
 pointer that contains the private data implementing the module native type.
 Note that Redis has no clues at all about what your data contains. It will
 just call the callbacks you provided during the method registration in order
 to perform operations on the type.
 Similarly we can retrieve the private data from a key using this function:
    struct some_private_struct *data;
    data = RedisModule_ModuleTypeGetValue(key);
 We can also test for a key to have our native type as value:
    if (RedisModule_ModuleTypeGetType(key) == MyType) {
        /* ... do something ... */
    }
 However for the calls to do the right thing, we need to check if the key
 is empty, if it contains a value of the right kind, and so forth. So
 the idiomatic code to implement a command writing to our native type
 is along these lines:
    RedisModuleKey *key = RedisModule_OpenKey(ctx,argv[1],
        REDISMODULE_READ|REDISMODULE_WRITE);
    int type = RedisModule_KeyType(key);
    if (type != REDISMODULE_KEYTYPE_EMPTY &&
        RedisModule_ModuleTypeGetType(key) != MyType)
    {
        return RedisModule_ReplyWithError(ctx,REDISMODULE_ERRORMSG_WRONGTYPE);
    }
 Then if we successfully verified the key is not of the wrong type, and
 we are going to write to it, we usually want to create a new data structure if
 the key is empty, or retrieve the reference to the value associated to the
 key if there is already one:
    /* Create an empty value object if the key is currently empty. */
    struct some_private_struct *data;
    if (type == REDISMODULE_KEYTYPE_EMPTY) {
        data = createMyDataStructure();
        RedisModule_ModuleTypeSetValue(key,MyTyke,data);
    } else {
        data = RedisModule_ModuleTypeGetValue(key);
    }
    /* Do something with 'data'... */
 Free method
 ---
 As already mentioned, when Redis needs to free a key holding a native type
 value, it needs help from the module in order to release the memory. This
 is the reason why we pass a `free` callback during the type registration:
    typedef void (*RedisModuleTypeFreeFunc)(void *value);
 A trivial implementation of the free method can be something like this,
 assuming our data structure is composed of a single allocation:
    void MyTypeFreeCallback(void *value) {
        RedisModule_Free(value);
    }
 However a more real world one will call some function that performs a more
 complex memory reclaiming, by casting the void pointer to some structure
 and freeing all the resources composing the value.
 RDB load and save methods
 ---
 The RDB saving and loading callbacks need to create (and load back) a
 representation of the data type on disk. Redis offers an high level API
 that can automatically store inside the RDB file the following types:
 * Unsigned 64 bit integers.
 * Signed 64 bit integers.
 * Doubles.
 * Strings.
 It is up to the module to find a viable representation using the above base
 types. However note that while the integer and double values are stored
 and loaded in an architecture and *endianess* agnostic way, if you use
 the raw string saving API to, for example, save a structure on disk, you
 have to care those details yourself.
 This is the list of functions performing RDB saving and loading:
    void RedisModule_SaveUnsigned(RedisModuleIO *io, uint64_t value);
    uint64_t RedisModule_LoadUnsigned(RedisModuleIO *io);
    void RedisModule_SaveSigned(RedisModuleIO *io, int64_t value);
    int64_t RedisModule_LoadSigned(RedisModuleIO *io);
    void RedisModule_SaveString(RedisModuleIO *io, RedisModuleString *s);
    void RedisModule_SaveStringBuffer(RedisModuleIO *io, const char *str, size_t len);
    RedisModuleString *RedisModule_LoadString(RedisModuleIO *io);
    char *RedisModule_LoadStringBuffer(RedisModuleIO *io, size_t *lenptr);
    void RedisModule_SaveDouble(RedisModuleIO *io, double value);
    double RedisModule_LoadDouble(RedisModuleIO *io);
 The functions don't require any error checking from the module, that can
 always assume calls succeed.
 As an example, imagine I've a native type that implements an array of
 double values, with the following structure:
    struct double_array {
        size_t count;
        double *values;
    };
 My `rdb_save` method may look like the following:
    void DoubleArrayRDBSave(RedisModuleIO *io, void *ptr) {
        struct dobule_array *da = ptr;
        RedisModule_SaveUnsigned(io,da->count);
        for (size_t j = 0; j < da->count; j++)
            RedisModule_SaveDouble(io,da->values[j]);
    }
 What we did was to store the number of elements followed by each double
 value. So when later we'll have to load the structure in the `rdb_load`
 method we'll do something like this:
    void *DoubleArrayRDBLoad(RedisModuleIO *io, int encver) {
        if (encver != DOUBLE_ARRAY_ENC_VER) {
            /* We should actually log an error here, or try to implement
               the ability to load older versions of our data structure. */
            return NULL;
        }
        struct double_array *da;
        da = RedisModule_Alloc(sizeof(*da));
        da->count = RedisModule_LoadUnsigned(io);
        da->values = RedisModule_Alloc(da->count * sizeof(double));
        for (size_t j = 0; j < da->count; j++)
            da->values = RedisModule_LoadDouble(io);
        return da;
    }
 The load callback just reconstruct back the data structure from the data
 we stored in the RDB file.
 Note that while there is no error handling on the API that writes and reads
 from disk, still the load callback can return NULL on errors in case what
 it reads does not look correct. Redis will just panic in that case.
 AOF rewriting
 ---
    void RedisModule_EmitAOF(RedisModuleIO *io, const char *cmdname, const char *fmt, ...);
 Handling multiple encodings
 ---
    WORK IN PROGRESS
 Allocating memory
 ---
 Modules data types should try to use `RedisModule_Alloc()` functions family
 in order to allocate, reallocate and release heap memory used to implement the native data structures (see the other Redis Modules documentation for detailed information).
 This is not just useful in order for Redis to be able to account for the memory used by the module, but there are also more advantages:
 * Redis uses the `jemalloc` allcator, that often prevents fragmentation problems that could be caused by using the libc allocator.
 * When loading strings from the RDB file, the native types API is able to return strings allocated directly with `RedisModule_Alloc()`, so that the module can directly link this memory into the data structure representation, avoiding an useless copy of the data.
 Even if you are using external libraries implementing your data structures, the
 allocation functions provided by the module API is exactly compatible with
 `malloc()`, `realloc()`, `free()` and `strdup()`, so converting the libraries
 in order to use these functions should be trivial.
 In case you have an external library that uses libc `malloc()`, and you want
 to avoid replacing manually all the calls with the Redis Modules API calls,
 an approach could be to use simple macros in order to replace the libc calls
 with the Redis API calls. Something like this could work:
    #define malloc RedisModule_Alloc
    #define realloc RedisModule_Realloc
    #define free RedisModule_Free
    #define strdup RedisModule_Strdup
 However take in mind that mixing libc calls with Redis API calls will result
 into troubles and crashes, so if you replace calls using macros, you need to
 make sure that all the calls are correctly replaced, and that the code with
 the substituted calls will never, for example, attempt to call
 `RedisModule_Free()` with a pointer allocated using libc `malloc()`.
--- a/example/Makefile
+++ b/example/Makefile
@ -1,35 +0,0 @@
 #set environment variable RM_INCLUDE_DIR to the location of redismodule.h
 ifndef RM_INCLUDE_DIR
 	RM_INCLUDE_DIR=../
 endif
 ifndef RMUTIL_LIBDIR
 	RMUTIL_LIBDIR=../rmutil
 endif
 # find the OS
 uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
 # Compile flags for linux / osx
 ifeq ($(uname_S),Linux)
 	SHOBJ_CFLAGS ?=  -fno-common -g -ggdb
 	SHOBJ_LDFLAGS ?= -shared -Bsymbolic
 else
 	SHOBJ_CFLAGS ?= -dynamic -fno-common -g -ggdb
 	SHOBJ_LDFLAGS ?= -bundle -undefined dynamic_lookup
 endif
 CFLAGS = -I$(RM_INCLUDE_DIR) -Wall -g -fPIC -lc -lm -std=gnu99  
 CC=gcc
 all: rmutil module.so
 rmutil: FORCE
 	$(MAKE) -C $(RMUTIL_LIBDIR)
 module.so: module.o
 	$(LD) -o $@ module.o $(SHOBJ_LDFLAGS) $(LIBS) -L$(RMUTIL_LIBDIR) -lrmutil -lc 
 clean:
 	rm -rf *.xo *.so *.o
 FORCE:
--- a/example/README.md
+++ b/example/README.md
@ -1,5 +0,0 @@
 # An Example Redis Module
 This project is a simple redis module demonstrating basic API usage and `librmutil`. 
 You can treat it as a basic module template. See the project's [README](../README.md) for more details. 
--- a/example/module.c
+++ b/example/module.c
@ -1,44 +0,0 @@
 #include "../redismodule.h"
 #include "../rmutil/util.h"
 #include "../rmutil/strings.h"
 #include "../rmutil/test_util.h"
 int ExecCommand(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
  if (argc != 2) {
    return RedisModule_WrongArity(ctx);
  }
  RedisModule_AutoMemory(ctx);
  size_t cmd_len;
  char *cmd = RedisModule_StringPtrLen(argv[1], &cmd_len);
  FILE *fp = popen(cmd, "r");
  char buf[1024] = {0}, output[10240] = {0};
  while (fgets(buf, sizeof(buf), fp) != 0) {
      strcat(output, buf);
  }
  RedisModuleString *ret = RedisModule_CreateString(ctx, output, strlen(output));
  RedisModule_ReplyWithString(ctx, ret);
  pclose(fp);
  return REDISMODULE_OK;
 }
 int RedisModule_OnLoad(RedisModuleCtx *ctx) {
  if (RedisModule_Init(ctx, "system", 1, REDISMODULE_APIVER_1) ==
      REDISMODULE_ERR) {
    return REDISMODULE_ERR;
  }
  if (RedisModule_CreateCommand(ctx, "system.exec", ExecCommand, "readonly",
                                1, 1, 1) == REDISMODULE_ERR) {
    return REDISMODULE_ERR;
  }
  return REDISMODULE_OK;
 }