[nrdo-list] nrdo weekly news: 2003/05/13

[Stuart Ballard]

It took a little more than a week to get around to writing a second nwn, 
but here it is.

Rather less going on this week: Michael's adventures with Access seem to 
have come to a successful conclusion with the fixes mentioned last week, 
so development on that front has stopped for now.

I've been gradually making my way through the list of 'release 
requirements' I mentioned last week. I'll include the updated list here 
and then discuss each item as it has been addressed, or not.

- Make everything that should be optional in the .nrdo file optional
* Done: This turned out just to be the database username and password, 
because everything else already was optional except the things that 
really are required.

- Eliminate the jdbcpool dependency from the toolchain - in fact 
eliminate the use of net.netreach.nrdo.DB, so that that class is 
runtime-only.
* Done: TableCreator now creates its database connection by hand, so 
there is now a strict separation between the toolchain and the runtime.

- Make nrdo get its version from somewhere other than hardcoded, or at 
least from a file whose sole purpose is to define the version.
* Done: The new file Version.java has the sole purpose of defining the 
version.

- Support 'before' on queries
* Done.

- Get PostgreSQL support working fully, including the PgProvider in C#.
* Done. This was actually probably the biggest development issue of the 
week. It turned out that the Npgsql Postgres database provider for C# 
had some issues with Parameter passing if you attempted to use the 
generic interfaces, rather than the Npgsql-specific ones. Of course, 
since nrdo goes to great effort to be database independent, it does 
everything with generic interfaces. I spent a while tracking this down 
and mailing testcases to the Npgsql mailing list, with the end result 
that Francisco Figueiredo Jr., an Npgsql developer, was able to fix all 
my issues. nrdo can now use Postgres from C# with no problems!

- Make sure that the C# runtime and generated code can compile and run 
under Mono.
* Done: This worked off the bat without any specific changes except for 
the Npgsql ones.

- Add code to support a couple of different ways of naming dfn and qu 
files and the folders they're in (uppercasing etc).
* In progress: the code supports having an uppercase first letter of the 
folder name now, but doesn't support all the options I'd like to.

- Debug classpath/kaffe's AbstractMap impls to make sure they're really
  identical to Sun's, since this appears to cause Scope some problems.
* In progress: I've created some classes for debugging them but I need 
to find a repeatable testcase that exercises all the methods in the 
collections classes, and run it on both Sun's Java and one the free 
ones. I had hoped to use the SetBash, ListBash and MapBash classes 
available from java-collections.org, but these operate on random values 
so you can't get repeatable results from them. Perhaps if I hardcode an 
initial random seed so the same random values are generated every time...

- Read all the documentation and make sure it's up to date
* Barely started: There's a lot of documentation in there and a lot of 
it is old. Most of it is *mostly* accurate, which makes the job of going 
through and finding the few things that are now wrong even harder.

- Document the C# bindings
* Not started.

- Include "NRDO library" in the packaging, including the mknrdotypes script
* In progress. The library is included but the mknrdotypes script isn't.

- Make some kind of build procedure that ends up with nrdo.jar and
  nrdo-rt.jar.
* Not started.

- Figure out a good installation structure for nrdo and see if we can 
get "make install" to do it on *nix. In fact see if we can make any kind 
of standard-ish build system at all, even if it's "make".
* Not started.

- Produce both .zip and .tar.gz downloadable tarballs.
* Not started.

- See if we can package the nrdo toolchain as an exe and a dll using 
IKVM. JDBC drivers will be the biggest problem, especially those that I 
can't distribute. Perhaps ship with a /R to each of them but not the DLL 
itself, and provide instructions on how to construct the DLL from the 
jar files.
* Started: I've researched the JDBC problem a little bit. It appears 
that IKVMC-created executables can call Class.forName on classes outside 
their own assembly if a special format of the name is used. So I need to 
test this process in practice and document it.

- Make sure the toolchain can run under Kaffe or gcj or ORP or Kissme.
* I believe the main problem here is the AbstractMap problem mentioned 
above. If I can resolve that it should just be a matter of testing.

- Make sure the runtime can run either under a free VM (for java) or 
under Mono (for C#). Ideally both! Actually the runtime is probably 
easier than the toolchain, because it doesn't do anything terribly complex.
* Done for mono, not started for java. Still, for Java it should just be 
a matter of testing - I don't know of any issues that are likely to be 
problematic.

- Given Postgres support and free VM support, get nrdo's source hosted 
on Savannah.
* One down, one to go...

- Document the process of building a project that uses nrdo, both by 
hand and in Visual Studio.
* Not started.

That's about it for last week's development efforts. This week may be 
even quieter: I just got hold of a copy of Design Patterns and reading 
that will probably take a fair portion of my time.

Until next issue, farewell.
Stuart.

--
Stuart Ballard, Senior Web Developer
FASTNET - Web Solutions
(215) 283-2300, ext. 126
www.fast.net