Re: Octave on Windows

[Benjamin Lindner]

> On Wed, Jan 27, 2010 at 6:46 AM, LUK ShunTim <address@hidden> wrote:
> > Benjamin Lindner wrote:
> >> Ying-Foon Chow wrote:
> >>> Sorry for the "typo" in my previous message, and the attached gif file
> >>> actually shows the output of gnuplot_binary() after I started Octave
> is:
> >>>
> >>> ans = C:\Octave\3.2.3_gcc-4.4.0\bin\gnuplot.exe
> >>>
> >>> Then, I am not getting anything by typing:
> >>>
> >>> gnuplot_binary('C:\Octave\3.2.3_gcc-4.4.0\bin\gnuplot.exe')
> >>>
> >>> Is this expected? Again, any pointers on the error message shown in
> the
> >>> previously attached screen shot is much appreciated.
> >>>
> >>
> >> Hmm, line 33 in __gnuplot_version__ reads
> >> [status, output] = system (sprintf ("\"%s\" --version", gnuplot_binary
> ()));
> >>
> >> and the error indicates that the call to system() does not return a
> >> defined value (if I interpret this correctly).
> >> I don't really have a good idea, so I am staring guessing around.
> >>
> >> What does
> >>    system("exit 2")
> >> return?
> >>
> >> And
> >>    system("gnuplot --version")
> >> ?
> >>
> >> And what does
> >>    [foo,bar] = system("echo bla & exit 2")
> >> return?
> >
> > I also encounter this problem on a Win XP SP2 running as a virtual
> > machine under virtualbox. Tried all 3.2.x installers on sourceforge.
> >
> > This is what I got:
> >
> > octave:1:C:\> system (sprintf ("\"%s\" --version", gnuplot_binary ()))
> > gnuplot 4.3.0-2009-07-08 CVS patchlevel 0 octave-mingw32
> > ans = 0
> > octave:2:C:\> [status, output] = system (sprintf ("\"%s\" --version",
> > gnuplot_binary ()))
> > error: value on right hand side of assignment is undefined
> >
> > I do *not* have such problems on my laptop with win XP SP2 running on
> > real hardware. Very strange!
> >
> 
> This is a bug in system (), it should have given an "unable to start
> subprocess" error.
> I checked in a fix:
> http://hg.savannah.gnu.org/hgweb/octave/rev/56f7734f5448
> 
> Still, I don't understand why the second version is unable to run for
> you; both calls work for me (on GNU/Linux).
> I suppose the difference somehow lies with the fact that on Windows,
> the first version is handled using CreateProcess, whereas the second
> boils down to _popen. I have too little Windows knowledge to be of any
> further help.

It looks like the implementation of pipes is faulty in the virtual 
machine environment??
To further debug this one would possibly need to step down and try to 
build native code using popen/Createprocess and see what errors
are returned.

benjamin
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01