Re: misfeatures in openmcl found while porting cl-launch

On Thu, 8 Sep 2005, [ISO-8859-1] Faré wrote:

> 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 lists here get anywhere from a few dozen to a few hundred spam
messages a day (and all of those spam messages are from non-subscribers
and are therefore "held for approval" in the same moderation queue as
on-topic messages from non-subscribers.)  Unless I know that there are
one or more on-topic messages in the queue, I tend to "process the queue"
by emptying it; I found about 8 messages - including this one - that
were sent a few months ago on a backup disk, more or less by accident.
Sorry.


>
> 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 general idea is that one would extend or alter the set of
command-line arguments that an application understands by defining a
subclass of the CCL:APPLICATION class and defining appropriate
argument-handling methods for that class, then saving an image that
used an instance of that application subclass.  That mechanism isn't
particulary well-documented, and is certainly more heavyweight than
what you're looking for.

I don't have any objection to using "--" to terminate the processing
of standard arguments.  I'd be a little reluctant to claim that this
follows "the" Unix convention - there tend to be lots of conventions
for this and for other things -- but you're right that there should
be some lightweight way of doing this.

>
> 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!

OpenMCL uses a background thread (which happens to also be the initial
thread, i.e., the one created by the OS when the program is executed)
to periodically FORCE-OUTPUT to the standard output stream.  The same
thread also handles shutting things down in response to CCL:QUIT, and
it can't do both things at the same time ...

This has been reported before; I'd thought that I'd fixed it in 1.0,
but (at best) I just improved the likelyhood of buffered output being
flushed, and it's still not reliable.  I think that it will be in the
next release.

>
> NB: I made my cl-launch tests with 0.14.2-p1 on a PB3500c running Linux 2.6.13.

It happens to be the case that all of the problems that you describe 
are present in 0.14.3 (which was current when you reported them) as well,
and some were present in 1.0.

In general, that might not be the case.

> 	./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.

EOF on /dev/null wasn't recognized prior to 1.0.
In 1.0, EOF on a TTY device didn't terminate the REPL if --batch is
in effect, and it should have.

>
> 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
>
> _______________________________________________
> Bug-openmcl mailing list
> [email protected]
> http://clozure.com/mailman/listinfo/bug-openmcl
>
>

_______________________________________________
Bug-openmcl mailing list
[email protected]
http://clozure.com/mailman/listinfo/bug-openmcl