I've been back home from New Zealand and PalmSource for a couple of weeks now. It's great to be back, especially since we've had a nice sprinkling of snow over the last few days: the frozen lake near my house is looking really really good. It's a beautiful place for a (very flat) walk at the moment.
Palm tools stuff
A compatibility bug in PilRC's parser has been bugging me for almost a year:
INTEGER 1000 10got unilaterally changed to
INTEGER 1000 VALUE 10back then. There was some value in this new VALUE keyword because it was a way of specifying negative numbers, but it should have been made optional so as not to break people's old source code.
Aaron is back motivated to make releases again (yay!), and on Friday I made a fix to make the VALUE optional that was better than my original fix that hadn't been integrated. It was a nightmare btw: every time I do anything in the PilRC source code I swear that I'm never going to touch it ever again.
So there's now a 2.9p2 PilRC release, and I can finally put new binaries up on the Sourceforge site. (I refused to update them until the source code compatibility bug was fixed.) I've put up x86 Linux RPMs tonight, and will make packages for the Cygwin users sometime over the next few days.
I did something a bit naughty in the RPMs: I created a new Group for them, instead of using one of the standard ones from Red Hat's RPM groups file. I'm in two minds about this; I've previously used Development/Tools for my prc-tools RPMs and resisted creating a new group. But the fact is everybody else does it, and it's helpful to the users if they can find the Palm OS-related tools in one place rather than having to hunt through the 800 other packages in Development/Tools.
After the next time rpmfind crawls through Sourceforge, hopefully people will be able to find Palm OS-related tools inPOSE RPMs and putting them there, and the RPMs of the next prc-tools release (any month now :-(, really) will be moving there from Development/Tools too.
Describing builds as a lazy functional program. Wow. That is just a gorgeous idea!
skipping the compilation if it's already been done (in a previous invocation)Do you mean in a previous compiler invocation (in a different part of the calculation) during the same build, or possibly a (memoized :-)) compile of the same thing during a previous full build? (Or maybe the question is meaningless in a functional context. :-))
The latter is similar to compilercache, which was recently featured on sweetcode, and which I've just started using. It caches object files based on the compiler flags and preprocessed source used to produce them, and just spits back the cached object instead of calling the compiler if sees that the exact same compilation has already been done. It's working wonders on testing POSE RPM builds: each full build takes a few minutes instead of twenty or more.