[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: hacked gnuplot for octave-2.0.5-i386-pc-cygwin32
From: |
Mumit Khan |
Subject: |
Re: hacked gnuplot for octave-2.0.5-i386-pc-cygwin32 |
Date: |
Fri, 16 May 1997 11:35:57 -0500 |
"John W. Eaton" <address@hidden> writes:
> On 15-May-1997, Mumit Khan <address@hidden> wrote:
>
> | What works?
> | Very basic "gplot" commands seem to work as advertised. Have NOT tried
> | the Matlab style "plot" commands.
>
> The Matlab-style plot commands should also work, because they are all
> implemented in M-files using gplot commands.
Actually, I just found out that "sprintf" fails (and possibly some other
builtins that use the libg++ string streams) possibly due to a problem
in libg++ (octave stream looks ok to me), so lots of scripts wouldn't
work for the cygwin32 port. The problem seems to be deep inside of libg++
stream classes, and it'll probably take quite a bit of work to figure it
out.
gnu-win32 uses gcc ss-970404 snapshot, and I'm not sure how much testing
libg++ has had with that particular one.
>
> | What's broken?
> | [gshow and anything that gnuplot outputs]
> | I haven't figured out how to grab the standard output yet, so
> | commands like "gshow" will not work.
>
> This doesn't really work with Octave on other systems either, because
> the communication with gnuplot is via a one-way pipe. If you type
> `gshow', the output from gnuplot is just send to stdout, which is
> usually connected to the same terminal that Octave is running in, so
> you can see the output. But Octave isn't reading it, and it doesn't
> go through the pager.
Actually, gnuplot writes to stderr, which makes it even worse. Here's the
fix:
gnuplot_binary = "gnuplot 2>&1 | cat"
It's fixed in the binaries now (the wrapper script does this for you).
Mumit