misfeatures in openmcl found while porting cl-launch

Faré <[email protected]> Thu, 8 Sep 2005 21:04:19 -0400
Newsgroups gmane.lisp.openmcl.bugs,gmane.lisp.openmcl.devel
Message-ID <[email protected]>
Dear OpenMCL developers,

I've tried porting cl-launch to openmcl, but have hit two nasty
misfeatures, on which I wasted some time until I found proper
workarounds. I wrote before about these issues earlier, but it looks
like my message didn't gather moderator approval, and since I did find
workarounds since, I'm reposting.

The first misfeature is the impossibility to call the openmcl with
user arguments. The standard unix convention is that -- separates
interpreter options from user options, and bash, cmucl clisp and gcl
deal with it. sbcl has --end-toplevel-options instead, to distinguish
between several levels of options. openmcl has none of that. It's a
pain. In cl-launch, I kluge around that by generating a defvar form
for the argument list, which involves expensive calls to sed and grep
from the wrapping shell script to properly quote the strings. Yuck.

The second misfeature was a race condition by which openmcl was most
usually unable to output anything to its standard output while
evaluating forms provided through --eval or --load arguments, except
that it worked almost every other time with the cpu under heavy load.
Wrapping the forms in a (with-open-file (*standard-output* "/dev/tty"
:direction :output :if-exists :append) ...) made it work always.
Eventually, I found that the cause was *standard-output* being
buffered and openmcl not flushing the output when exiting, either due
to (ccl:quit) or to reaching the end of forms to evaluate. Now I exit
with (progn (finish-output) (ccl:quit)). It was a pain to figure out
-- all the other lisps I tried did flush before a normal quit. I
suppose you should document this kind of things better, and/or have an
option for (ccl:quit) to flush the output (the default being T). My!

NB: I made my cl-launch tests with 0.14.2-p1 on a PB3500c running Linux 2.6.13.
	./cl-launch.sh -B test

PS: in a third bug, --batch seems not to exit openmcl when it hits a
Ctrl-D or is run < /dev/null, but exits if I subsequently type (quit)
at the console. It looks like openmcl is trying much too hard to do
some terminal opening magic despite being called with --batch.

Regards,

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
A computer is like an Old Testament god, with a lot of rules and no mercy.
        -- Joseph Campbell