A Complete About-Face?

Good news and mixed-blessings. After several weeks of attempting to wrap C for Python using Boost, I gave up. I deleted everything Boost related and started searching for an alternative. Even after switching to MSVC9.0 Express, using different releases of Python, and rebuilding Boost multiple times with different flags (all of which were recommended in the Boost documentation), it still failed to function as intended. Whatever. Boost has, without a doubt, been the single most un-user friendly library I've dealt with.

So what am I to do? If I can't rely on other people to make it easy on me, I'll just do it myself. I'll preface this by saying I have had zero experience writing dynamic linked libraries, but I felt the simplest and most elegant solution would be to define the set of block classes in a .dll, expose functions to instantiate the blocks into memory and pass the pointer to each block to Python. Of course Python has no clue what this pointer thing is, but if the pointer is passed back to the .dll through other exposed functions, then the block in memory can be manipulated with ease. This can all be accomplished using the ctypes library of Python to return the exposed functions and make calls to the .dll.

This has been finished and tested in much less time than all of the fiddling with Boost.

Currently, I can create a Diagram class in memory, add Block classes to the Diagram, neighbor the Blocks within the Diagram, step the Diagram to pass outputs to inputs of neighbored Blocks, and print out the state of the Diagram (including the state of each Block contained therein). It's pretty sweet, in my opinion. Unfortunately, I forgot about an important detail. The linked library is now kernel32 dependent (though I make no calls to kernel32 or ntdll). We intended to write the source to be cross-platform and using my solution would deny that possibility. In the meantime, Nik has programmed an equivalent set of Blocks in Python to handle parsing the Diagram. It works, but I'm still nervous that once we start including complex diagrams and many cells simultaneously the reliance on Python might bog the game down. We'll see.

I, personally, want to try my hand at writing a Shared Object to fix the cross-platform issue, but seeing as Nik already has working code, my time could be better spent elsewhere to get a working beta out the door. In that light, I've started coding a tab interface to switch between the block diagrams of the different cells currently in the field. Other interface additions will be the next priority.