More work on Boodle; mysterious Boo bugs.

Some more work on Boodle has been done - its mostly under the hood stuff, like an SQL-based back-end for project support. Hopefully this means project support in general once a user interface can be hooked up to it.

In doing a project the "size" of Boodle I've noticed what appear to be deep, lurking bugs in Boo that I'm unable to reproduce as simple test cases: many of them appear to be caused by the interaction between the modules that Boo generates. I've been trying to keep track of them by marking them as "BOOBUG," but I've only been doing that sparingly - when I'm pretty sure that it isn't just part of my bad code.

Here's one of the more annoying one that crops up occasionally (across two or three seperate projects):

for item in input:
#BOOBUG: Another one I can't reproduce.
#Accessing anything in "item" causes null ref exception.
print item.LexicalInfo

Its not that LexicalInfo is null and I'm trying to manipulate it; its that accessing any member of "item" causes an abrupt null reference exception. I believe I worked around it last time by simply declaring item as duck, but its still a pretty disconcerting thing. In the case of Boodle it wasn't necessary because that code block is obsoleted - I never got around to checking it into SVN 0 but its still there so I can keep track of those BOOBUGs in case I ever figure out what's going on.

#BOOBUG - something to do with interacting with other classes that use private stuff.
#Can't track it down right now, sorry.
buffer = main.GetBufferInfo(main.GetSelectedTextControl()) as BoodleBufferInfo

This one bothers me quite a bit, because its a situation where Boo's type inference fails completely: instead of assigning "System.Object" to buffer it actually assigned a type of "unknown" to buffer, which is a mystery that is beyond me. The cast apparently makes things work, so its nothing impassable, but it is annoying.

The hard part about debugging these kinds of problems is the way the compiler fails - there's not enough detail in the exception, like where it occured, or what kind of node it occured on, or where in the *BOO* source code the exception was emitted. If you *really* want to debug it you have to start sliding Console.WriteLines everywhere in the main Boo source. Well, that's what I do, considering I've never gotten dbgclr to load up the Boo assemblies and show its source code properly.

I'm just kind of hoping most of these issues "magically" go away, and that metaboo has a stronger foundation than the current Boo implementation.