[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: Error messages to stderr instead of stdout in interactiv
Paulo César Pereira de Andrade
[Gcl-devel] Re: Error messages to stderr instead of stdout in interactive mode?
Wed, 17 Mar 2010 23:50:09 -0300 (BRT)
Paulo César Pereira de Andrade wrote:
> Paulo César Pereira de Andrade wrote:
>> Is it possible to somehow force error messages to be printed
>> to stderr?
>> My question is because it is the only problem I found when
>> using maxima-runtime-gcl in Mandriva's sagemath package.
>> Sagemath uses a python interface, that actually allocates
>> a pty, and that apparently causes gcl to print messages to
>> *terminal-io*, but it is actually running in a pipe.
>> Since there is an initialization lisp file, I managed to
>> correct it for clisp with:
>> *error-output* (open "/dev/stderr" :direction :output)
>> *standard-input* (open "/dev/stdin" :direction :input)
>> *standard-output* (open "/dev/stdout" :direction :output))
>> But that is not enough for gcl.
>> I made some experiments with (si:readline-off), (si:close-fd ...),
>> (make-synonymous-stream), si:*IGNORE-EOF-ON-TERMINAL-IO*, etc. But,
>> cannot change *terminal-io* ...
>> The reason of this, is because the python interface expects that
>> error messages be printed to stderr.
> I looked at it again today, (in the hope of making maxima gcl
> backend work exactly as other lisp backends in sagemath mandriva
> If I use the same approach I used for clisp, it actually should
> print messages to stderr, otherwise, in
> maxima-source/src/nparse.lisp:mread-synerr() the predicate
> (output-stream-p *standard-input*) will be true, and it will confuse
> the python expect parser due to different error output from maxima.
> But now I believe the problem is that, in my version of gcl (basically
> fedora version, major contribution I did was the patch to properly
> read linker map with newer binutils, so that axiom builds and works...),
> but the problem is, suppose I type 'T' in gcl prompt, I would see
> something like:
> while in other lisps I see:
> And this appears to be the reason of the python parser getting
> Any hint in how to change this behavior? (without the need to rebuild
> either maxima or gcl hopefully :-)
Just for information, and sorry for using gcl-devel to somewhat
document/record the steps to correct this issue.
I added a patch and comments to
(#8439: maxima interface hangs gcl and/or clisp backends)
Now at least all the doctests pass with either gcl, sbcl, clisp
or ecl (the Mandriva supported/enabled maxima lisp backends).
The main problem was that, for some reason, the state set in the
"init" lisp file used by maxima was not kept;
(output-stream-p *standard-input*) was still true when reporting an
error, what for some reason confused the python pexpect interface, so,
it now sets the state using the ":lisp <form>" maxima construct.