Hi,
I just got those bugs out of XBlockFile. It does now correctly handle
blocks and sub-blocks, including reading and writing them, and only loading
maps when blocks in them are accessed. I still have to re-write the
compacting function, but this shouldn't be too hard (though this certainly
won't get any faster).
Things left to do then:
-> pre-flight check for available memory to ensure everything fits on disk,
or recovery if it doesn't fit
-> Add an API for writing a struct to a block (this needs to be
special-cased a bit to make sure endian conversion will work)
-> Write the docs for which I can heavily rely on those huge comment chunks
throughout the code I like so much. I hope nobody minds if I start with the
descriptions of the inner workings first, and then write the API docs.
-> Write a cute wrapper class that uses XBlockFile to create a stack file,
which will take care of mapping e.g. a stack's block data to its first sub
block's data transparently (so it can have both data and sub blocks) or
does something along that line. I'll probably call that XStackFile for now.
Then I can move on to another part of the components needed for FreeCard.
Will be some time, but I can't wait to get started with the HAL :-)
BTW, Anthony: We'll need to come up with a nice convention for our error
messages. Exceptions, I guess, but we'll need to define classes for them. I
suggest we require __FILE and the function name are passed to every
exception, so we can locate errors easier during the debugging phase. Your
interpreter will probably have to have an exception that also contains the
object name, line number and handler name of the location of a parse or
execution error. If we don't standardize that now we'll have a lot of
find/replace to do later on :-(
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
