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 :-)

Thanks,
Paulo



_______________________________________________
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel

Reply via email to