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 10
got unilaterally changed to
INTEGER 1000 VALUE 10
back 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 in
Development/Palm
OS
Pretty soon I'll be making
POSE 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.
raph's rebar
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.