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
Palm tools stuff
A compatibility bug in PilRC's parser has been bugging me
INTEGER 1000 10
got unilaterally changed to
INTEGER 1000 VALUE 10
back then. There was some value in this new VALUE
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
again (yay!), and on Friday I made a fix to make the
optional that was better than my original fix that hadn't
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
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
the Cygwin users sometime over the next few days.
I did something a bit naughty in the RPMs: I created a new
for them, instead of using one of the standard ones from Red
groups file. I'm in two minds about this; I've previously used
Development/Tools for my prc-tools RPMs and resisted
new group. But the fact is everybody else does it, and it's
to the users if they can find the Palm OS-related tools in
rather than having to hunt through the 800 other packages in
After the next time rpmfind crawls through Sourceforge,
will be able to find Palm OS-related tools in
Pretty soon I'll be making POSE
putting them there,
and the RPMs of the next prc-tools
month now :-(,
really) will be moving there from
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.