Menu
▾
▴
gnuplot-info
|
From: <lyn...@fr...> - 2009-05-30 11:59:12
|
On 29/05/09 20:52:07, Ben Abbott wrote: > On May 29, 2009, at 4:39 PM, lyn...@fr... wrote: > >> Hello! >> >> Because the thread below says it's a gnuplot issue I post this here as >> well: >> >> In octave I'm having troubles with coloured sactter3. If I do: >> >> x=rand(100,1) >> y=rand(100,1) >> z=rand(100,1) >> >> scatter3 (x, y, z); >> scatter3 (x, y, z, [], 'b'); >> scatter3 (x, y, z, z); >> scatter3 (x, y, z, 50); >> all is fine (just the spotsize is not changed) but with: >> >> scatter3 (x, y, z, 50, [], 's'); >> scatter3 (x, y, z, 50, []); > > The developers sources did not produce the same errors, but the two > examples you gave did produce errors due to an empty color spec. Thanks for the hint with the color. In my script I had concatenated x, y, z in the wrong direction such that size(color,1) was not the same as size(x,1). 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. Could it be there is some check missing about the color vector fitting to the data? It would be nice if the gnuplot error were more meaningfull to help find the cause for it. I couldn't get the hg sources compile because my autoconf is 2.59 and lowering the requirement in configure.in caused configure to be unhappy about my g77. Since I for now I don't need them I'll wait for a new release including a configure already. Thanks for the help Lynx > > A trivial changeset with new demos has been pushed. > > http://hg.savannah.gnu.org/hgweb/octave/rev/d8becc6d0a18 > > This change might work for 3.0.5, but I haven't tried. > > Ben > |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2009-05-30 20:44:40
|
lyn...@fr... 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 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. 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. 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. > 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! |
|
From: <lyn...@fr...> - 2009-05-31 18:52:14
|
On 30/05/09 22:43:35, Hans-Bernhard Bröker wrote: > lyn...@fr... 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 |