[Ecls-list] ecl-standalone *feature* or similar?

[Matthew Mondor]

On Fri, 14 Aug 2009 11:07:50 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> Matthew, if you need a "standalone" feature, then why do yo not cook
> it for your own project?

Thanks, this worked fine and was indeed easy to add to the build script :)

> But the real and elegant way, is to use :epilogue...
> 
> > So I tried writing an arguments processing function (standalone-main)
> > and passing '(socket-test:standalone-main) as :epilogue-code to
> > c::build-program, but this doesn't seem to work well (it appears that
> > the exceptions system is not yet initialized when the function is
> > invoked, so "Connected" gets printed even if an exception should occur
> > when attempting to connect to an unbound port, for instance).  Is this
> > expected?
> 
> There is no such thing as an installed exception system. Conditions do
> not have handlers by default, except if you launch the toplevel, which
> then installs a default handler that calls the debugger. If you want
> to catch errors in the epilogue code you will have to include in
> standalone-main a handler-bind or handler-case statement that captures
> all uncaught exceptions.
> 
> Please do not ask me to include a default handler for exceptions,
> because that would break people's code. If I do something like
>     (handler-bind ((error #'my-error-handler)) ...)
> this may have priority over other people's installed handlers. This is
> indeed what broke the original condition handling code in ECL's
> compiler: top-level installed its own handlers for all conditions and
> the debugger was never invoked.

Oh, this explains a lot.  Thanks again for the explanation.

I decided to add a custom handler-case, but unfortunately I am getting
odd results.  Whenever an exception happens in the custom epilogue with
a custom handler:

Internal or unrecoverable error in:
Cannot grow stack size.

Which happens before the handler has the opportunity to print the error.
This even happens when no error is supposed to occur.

If using the top level with for instance +mm-ecl-standalone then the
program works better, but if interrupted with ctrl-C then ends up in an
endless run loop upon SIGINT reception (a SIGTERM can then kill it).

When I have more time I'll have to look more closely into these problems.
I also should look at the handler code around the top level loop which
invokes the debugger.
Thanks,
-- 
Matt