Re: broken gnuplot pipe with coloured scatter3 from octave

[lynx . abraxas]

On 30/05/09 22:43:35, Hans-Bernhard Bröker wrote:
> address@hidden wrote:
>
>> I don't get the errors due to an empty color spec though.
>> Strangely on a different computer I sometimes still get the gnuplot errors.
>
> Did you check that you're using the same versions of everything (OS,
> octave, gnuplot) on those two different computers?

It's not LFS (Linux from scratch) there but Suse 10.3 octave 3.0.5 and gnuplot
4.2.


>>  It  would  be nice if the gnuplot error were more meaningfull to help find
the
>> cause for it.
>
> There really can't be.  For starters, we're talking about three separate
> issues with different likely reasons.  So there's no "the" cause for
> gnuplot to inform you about.

Well within gnuplot:
gnuplot> load "octave.gp"
"octave.gp", line 3088: duplicated arguments in style specification

wc -l octave.gp
1275 octave.gp

I can find style only two times and that  seems  not  corrupted  to  me.  Even
commenting them out does not help.

> The first error being described most probably is caused by an I/O buffer
> limitation being hit somewhere between octave and the main gnuplot
> executable (pipe buffer, Windows message queue).  In effect, some of the
> data are getting garbled or lost on the way, and gnuplot tries to interpret
> remaining inline data (input lines containing of just numbers) as commands,
> which it rather obviously can't.  Given those circumstances, there really
> can't be a meaningful error message. There's no context left to reconstruct
> possible meaning from.

I  agree if there's garbage comming in the error messages will be problematic.
But so far it's only gnuplot/octave that has problems with my 2.6.22.7 kernel-
pipe. Is there any way to monitor what happens there?
I've  piped  loads of stuff so far even mplayer pcm data of more than 100MB to
oggenc and there was never a problem. The kernel  nicely  made  mplayer  sleep
while the pipe was full and oggenc was bussy encoding.

> The broken pipe issue with binary data is probably either the same problem
> in a different disguise, or a generic incapability of the communication
> channel to handle binary data.  Hard to tell without at least knowing the
> OS platform and gnuplot version.
>
> The third issue could be anything --- we gnuplot people don't generally
> know what those octave commands actually end up sending to gnuplot. Without
> that, there's nothing we can do to help.

That's why I attached octave.gp.bz2 ;-)

>
>> I couldn't get the hg sources compile because my autoconf is 2.59
>
> So what's keeping you from upgrading it?  2.61 has been around for well
> over two years now!

Yes I know. It's another story. LFS is not so easy to upgrade...

As far as I understand the problems here:
It is up to octave to make sure it puts proper code into the pipe and tell the
user if it can't because of wrong sized arrays or such.
The kernel is supposed to pass correctly what comes into the pipe to  gnuplot.
If gnuplot does not get proper code, it should complain as best as it can.


Thanks for looking into this.


Regards,
Lynx