Erlkönig: Z (ζωιον) Past Status Entries

2004-12-29 C++ N-Tree[trapezoidal] Class

Currently entangled in the process of writing an STL-like NTree class. It's a bit frustrating that although there are reasonable overviews of writing STL extensions, it seems to be nearly impossible to dig up a good canonical example upon which to base a new template. Grrr. Regardless of the trauma factor however, moving the implementation of the Zones' tree structures into a generic class allows the mechanism to be tested in relative isolation, which is clearly worthwhile.

Part of the quirkiness of the implementation I'm working has to do with the search for LISP-like tree instantiation. With some clever use of + and an auxilliary class, one should be able to generate reasonably efficient code for creating trees with code similar to that used for static initializations. In the example below, copies are made of the original nodes by the + and / operators, with this floating copy, once linked together, assigned to the tree.

It doesn't help, of course, that C++ wants all the happy temporaries in such an expression to be constant, dramatically interfering with the whole goal of linking them without generating gobs of sub-copies.

    typedef NtreeNode_t<std::string> N;
    N tree = (N("a1") / (N("b1") / (N("c1") +
                                    N("c2") ) +
                         N("b2") / (N("d1") +
                                    N("d2") )));

2004-01-21 Morphable X Servers

Substantial tweaking has produced a version of xvfbtex with full tracking of the textured X server's cursor by user control of the pointer across the scene. Basically this means that when you move the mouse across a scene of objects, your path across the object with an X server framebuffer textured across the side will be tracked by that X server's pointer.

Currently pointer tracking is a special case, and has not yet been encapsulated in a form suitable for reuse, but that encapsulation will provide, among other things, a straightforward approach to interactive painting onto 3d surfaces.

2003-10 Ah, threads.

(Download the threaded life project)

I knew that writing the classic life cellular automaton as a orgy of gratuitous threads, one per cell, plus threads for input and display, would expose some limitations; that was the point. But I was surprised to discover just how much misinformation is out there about limits on the maximum number of threads in a process. So, to help anyone else trying to run a few thousand threads in one program: the cumulative stack size in all your threads is probably the problem. You can test this as easily as using the ulimit shell builtin to reduce your default stack size, and then seeing if suddenly your program can create more threads than before. The same reduction can be coded using pthread_attr_{get/set}stacksize(). With this method, I reduced the stack sizes for the cell threads in the test code from 1 MB to 1 KB for all but 3 threads, and now it works fine at 7103 threads instead of the earlier 234. The file /proc/sys/kernel/threads-max on my machine contains the value of 14336, suggesting a maximum of about twice what I'm seeing, but I don't see a need for anywhere near even what my testcase is using (although, I wonder if you could overlap the stacks if your threads used no variables or function calls...hehe). Good luck :-)