[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: Error messages to stderr instead of stdout in interactiv

From: Paulo César Pereira de Andrade
Subject: [Gcl-devel] Re: Error messages to stderr instead of stdout in interactive mode?
Date: Wed, 17 Mar 2010 23:50:09 -0300 (BRT)
User-agent: SquirrelMail/1.4.17

Paulo César Pereira de Andrade wrote:
> Paulo César Pereira de Andrade wrote:
>>   Hi,
>>   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:
>> #+clisp
>> (setf
>>   *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
> package).
>   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:
> -%<-
> <prompt>t
> T
> <prompt>
> -%<-
> while in other lisps I see:
> -%<-
> <prompt>t
> T
> <prompt>
> -%<-
>   And this appears to be the reason of the python parser getting
> confused.
>   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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]