[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[nrdo-list] nrdo weekly news: 2003/05/13
From: |
Stuart Ballard |
Subject: |
[nrdo-list] nrdo weekly news: 2003/05/13 |
Date: |
Tue, 13 May 2003 13:49:44 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [nrdo-list] nrdo weekly news: 2003/05/13,
Stuart Ballard <=