ECHO Setting Visual Studio environment
CALL "c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" amd64
set BASE=%CD%

if __name__ == '__main__':
sys.exit(main())


# configure for fast writes
lite_cur = lite_con.cursor()
lite_cur.execute('PRAGMA synchronous = 0')
lite_cur.execute('PRAGMA cache_size = 64000')
lite_cur.execute('PRAGMA fullfsync = 0')
lite_cur.execute('PRAGMA journal_mode = OFF')
lite_cur.arraysize = 30000


The fastest web crawler in the galaxy

Get it from github.

I usually work in the following way, the default branch is the trunk/master branch. Then we create named feature branches such as ‘feat_[featurename]‘, release branches as ‘release_[version]‘ and also branches for tickets with the same name as the ticket name, the name inside braces is a placeholder. The named branches are not a problem in mercurial since as long as they are not needed we close them with hg ci --close-branch.

Most common development loop:

hg branch feat_somenicething
...hack...
hg commit -m "hack"
...good?... integrate into default
hg up default
hg merge feat_somenicething


To get the branching point from default:

hg log -r 'ancestor(default,.)'


And to check the full patch of your feature against default:

hg up feat_somenicething
hg diff -r 'ancestor(default,.)'


Sometimes I rebase some changes (x) onto (y) to make the history more linear, when for example pulling brings (y) that has parent (z) and I commited (x) with parent (z):
z—-y
\—x

hg rebase -s x -d y

z—-y—-x

Shelve does the same as git stash, ‘shelves’ away your local changes. You can also use it to move the patch to another branch.

hg shelve


To view the history graphicaly I use tortoise hg, there’s also hgview:

thg


And that’s mostly it. It’s pretty straightforward and easy.

cat .xbindkeysrc
# Mouse Buttons:
# next page
"xvkbd -xsendevent -text "\[XF86Back]""
m:0x0 + b:8
# previous page
"xvkbd -xsendevent -text "\[XF86Forward]""
m:0x0 + b:9
# Switch tab on thumb
"xvkbd -xsendevent -text "\[Control_L]\[Tab]""
b:10
# Close tab on thumb
"xvkbd -xsendevent -text "\[Control_L]w""
b:13


Libuv is claimed to work on Linux, MacOS, Windows (MinGW, VS) and Solaris. They have abstracted platform detail for event based IO not only for networking, but even for filesystem operations you can code callbacks to perform actions asynchronously when they finish. It’s being used also in other interesting projects such as Node Native, which is similar to node.js in spirit but done instead in C++11.

Evented IO is good, it’s not difficult to program since usually you make small callbacks that responds to reading or writing a buffer, or to an event in a file or a socket. They are much better alternative to spawning threads just to let them block waiting for IO for the following reasons:

• It’s inefficient: thread creation is not so cheap
• It doesn’t scale
• It’s using the wrong tool for the job, threads should be used to exploit processing parallelism.
• It exposes your program to potential concurrency pitfalls, which are very costly to debug.

Build system:
Libuv uses Makefiles and GYP as a meta-buildsystem to generate Makefiles, VS projects and XCode projects. The build system is on the small side of things, so although I’m not a big fan of Make, I prefer better tooks like SCons. But I wouldn’t say it’s a big deal for this project. Then supposedly, as per GYP you should be able to generate project files for the more clickety tools and OSes. So as per keeping the Makefiles simple and using a more modern tool such as GYP the balance on this point is positive.

Code and capabilities:
The library is programmed in vanilla C. For this task I think it’s the right tool for the job, ensuring portability and easy mantainability. I’d say the quality of the code is in general good. The interface is well abstracted and consistent. On unix variants it abstracts libev for evented IO. And in Windows it abstracts completion ports. It also uses c-ares library under the hood to do asynchronous DNS queries.

I find very interesting that the library takes the asynchronous paradigm fully radical up to the point that you can even create a directory asynchronously. You might not think that it’s so important to create a directory non-blocking, but if your IO system is under heavy load, just creating a dir might suspend the application for several seconds!

It also has a very basic interface for creating a joining threads:

int uv_thread_create(uv_thread_t *tid, void (*entry)(void *arg), void *arg);
int uv_thread_join(uv_thread_t *tid);

Also supports mutexes and locks.

It has also dynamic symbol loading capabilities.

License:
The library is dual MIT / GPL, and two clause BSD license for some parts.

Valoration:
In all, a very nice, useful library which facilitates the right programming pattern for IO. Strongly recommended. Rating: 8.5/10