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