help-octave
[Top][All Lists]
Advanced

[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


reply via email to

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