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

2012-02-19 Fast per-X-Window Texture Mapping

xwins - On a more upbeat side than the I-miss-LISP woes, a new xwins program I wrote couple of weeks ago to allow the manipulation (with a Spaceball or whatever) of live X windows mapped onto textures in OpenGL has turned out to be useful, especially for magnification, and is much faster than the X-server to texture approach used in xvbftex experiment from a while back. It's essentially a quick hack to test a few things:

• XCompositeRedirectWindow - render X windows as texture.
• Quaternions - finally an end to gimble lock.
• 3dconnexion controller lib - no longer using my old serial Spaceball driver.
• CPP-based list mixins - add Push/Pop/Extract/Count to an arbitrary structure.

Zooming with the spaceball is more entertaining than xmag, especially when you point the application at its own output window. The mapped Emacs window in the sample image is fully active, even in its many recursing views. Adding the pointer tracking and input from xvbftex would yield yet another OpenGL window manager.

As usual, though, implementing anything in GLUT runs into a wall before long (crippled callbacks, and sadly, GLFW has the same problem), and xwins become independent of that curséd subsystem a few days later.

2012-02-18 Single Inheritance in C

Implementing single inheritance in C is an interesting exercise, with a number of approaches from the one used in the X widgets, to heavy reliance on the C preprocessor for structure member copying, to using obscure GCC options to allow the same thing through anonymous substructures (using -std=gnu99 -fplan9-extensions is pretty convenient for this approach). Add to this a year-long break while buried in Python coding, and the result is a deep disaffection with not having easy containers in C, yet horror at what's required to write such in STL-style code in C++. (Oh, LISP, why have we forsaken thee?) Reinvention of containers is basically a time-sucking detour, but a certain popular container library for C instantly suicides upon memory exhaustion, and another doesn't but has a really annoying usage model (from my utterly subjective perspective). Wanting to base a set of containers upon an incomplete inheritance model is a bit like creating three new problems, all squarely in the way of starting the Real Work.

An interesting, simple abuse of CPP (used in xwins, q.v.) yields a mixin-like approach to ornamenting arbitrary data structures with fifo or list-like attributes and methods.

Dynamic reloading of object types has been dropped in favor of focussing on stressing inter-Zone synchronization purely through Z protocol. Synchronizing between two Zones at versions N and N+1 is much more robust than updating types within a given Zone on the fly. Since either approach allows a developer to maintain an existing session during the upgrade-or-switchover, only a performance grail lies on the dynamic loading path, rarely a wise objective when prototyping. Simple dynamic loading, on the other hand, is a nearly free side effect of the in-dev inheritance model, lacking only C++-like namespaces to be tidy. If it's too untidy, I may fall back to static inheritance.

2011-01-22 In C, Reloaded

There's been a hiatus of a several years. In that time, I've experienced C++ syntax changes that invalidated large chunks of code, been blocked in sharing programs due to C++'s lower portability, and seen the fundamental truth in the Linux kernel developer attitude that C++ is simply a poor solution to demands for long-term development where the eventual deployments sites' compiler versions can't be controlled. This has been a troubling realization, since despite C++'s ridiculously complicated syntax, it offers a number of nice features I've been loath to abandon.

But it's time.

So I've been exploring rewriting the whole thing in an object-oriented C style, which provides a perfect opportunity to try integrating dynamic loading, which although perfectly usable in C++, wasn't added to the older Z code due to coding paradigm inertia. I'd really like to see a server than can dynamically change the type of objects, so that a developer can often inject improvements without leaving the 3D environment. If a restart is required, it would be nice for the client library to offer transparent reconnect to the Zone (Z server) after the restart, if the Zone succeeded in carrying its state forward through persistant storage.

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 :-)