Bill Roper's Journal

I added another new helper class to the parser -- actually to the Parseable helper class. This will fetch a function call and any / all of its arguments and store them in the class, which allows the code to be much simpler and more consistent. So you call the getFunction() method on a Parseable object and, if the Parseable object is a function call, it passes back a FunctionInfo object with the correct Function enum member and an array of arguments to the function as Argument objects (which extend Parseable, so any of them can be parsed themselves).

Then I just pick off the Function enum and route the FunctionInfo object to the specific parser method that generates the correct byte codes for the function and its arguments.

Patching all of this in is a bit tedious, but I suspect it will greatly improve my debugging and testing later. :)

Last week, I started browsing through the source code for the Apache POI library, because the examples and documentation that I'd been finding were woefully inadequate for the task I was working on. Today, everything finally clicked when I came to realize that there just doesn't seem to be a way to use POI to write a compound document back out into the original file. (Maybe there's something that will do it there, but I haven't found it yet.)

So I've now managed to recode everything to write the changed streams out to a new file, along with all of the unchanged streams from the old file. And that seems to be working fine now.

On to the next little bit... :)

After getting the Java code to compile, I started trying to use some of the 48,000 lines of code that I'd ported for something other than serialization in and back out. This started showing up the places where I'd stopped the port and stubbed things out and where there are differences between the Java and C++ basic architecture that I'd planned when I started this many months ago.

I can now locate members of the Account and Time dimensions. I can't actually retrieve data yet, because that runs into a stub in the Account class, but I think I will refactor and delegate that problem to the data storage class that the Accounts contain.

And then all of this will start doing something hypothetically useful. :)

Katie and Julie piled into the van with us and were dropped off at school this morning, resuming normal schedules. :)

In other news, I have been cleaning out the compilation errors in my Java port. The end is in sight, although the nasty tendency of JDeveloper to hide vast tracts of errors until something else has been cleaned up makes estimating how far I am from the end just a bit more difficult.

*sigh*

Well, I thought that Apache MINA was going to solve my problem of wanting an expandable ByteBuffer. However, when I read another bit of the documentation, it seems they've decided that trying to solve their particular problem with an expandable ByteBuffer was a bad idea, so they'll be taking it out of the next major release of the project. *sigh*

So I will roll my own. It's not inherently that complex. It's just tedious.

Because I needed to be writing some more tedious code right now...

So I'm still working on porting my code from C++ to Java. I'm over the 40,000 line mark now, which is good, but there is still a lot of stuff left to port. I've been working through the Var class for several days and am nearing the 6000 line mark there. (It's a large and important class with many methods.) And as I work down through it, I run into many other classes that aren't completed where I either go "I'll fix that later" or "I should go fix that now".

So I needed to copy an object that held an array of other complex objects that held still more complex objects along with a metric ton of ordinary data. And I was about to swear and write yet another copy constructor (because I am a recalcitrant C++ programmer apparently) when I suddenly realized that I was about to do way too much work.

If I implement the Cloneable interface and the clone() method on these objects, then I get a free bitwise copy of everything that they contain. So for that object with a metric ton of ordinary data, I just call super.clone() and I have now copied the metric ton of ordinary data and only need to fix up and clone the complex objects that I want to have new copies of, since my intent is to do a deep copy when calling clone().

So I ran around and implemented all of the necessary clone functions for half a dozen classes.

And the code base got 47 lines longer. Instead of a whole lot more lines of mechanical copying which would have pumped up the line count, but not actually done any more work.

Oh.

OK. I guess I'm not yet too old to learn some new tricks. :)

I can now read -- to a first approximation! -- the old binary format for our data in Java.

Next is to be able to write the format successfully, which will take a little bit longer, because some of the code that I copied in from the previous version of this didn't implement writing. I will need to add the necessary logic there.

And there are some classes that are missing in the test data that I'm working with that I'll have to test with some different data.

Later.

I can now read many of the classes in my binary file, but I stopped somewhere over 300 variables in due to a serialization error of some kind.

Tomorrow, I'll figure out which class has the bum instruction in it and see what fails next...

(The previous failure was because I forgot to declare one of my variables as static. *oops*)

I am coding up Java classes at what seems like a tremendous pace. It is not a fast enough pace, but I am making progress.

The problem is that it's very hard to see the progress until everything is done.

*sigh*

Everyone appears to have a different idea about what well-formatted XML looks like. This makes life entertaining.