Menu
▾
▴
gnuplot-bugs — Place to submit bug reports on gnuplot
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(1) |
Feb
(2) |
Mar
(2) |
Apr
(22) |
May
(14) |
Jun
(18) |
Jul
(19) |
Aug
(7) |
Sep
(4) |
Oct
(6) |
Nov
(12) |
Dec
(14) |
| 2005 |
Jan
(15) |
Feb
(11) |
Mar
(11) |
Apr
(9) |
May
(119) |
Jun
(25) |
Jul
(16) |
Aug
(19) |
Sep
(26) |
Oct
(14) |
Nov
(7) |
Dec
(45) |
| 2006 |
Jan
(22) |
Feb
(7) |
Mar
(11) |
Apr
(11) |
May
(12) |
Jun
(19) |
Jul
(12) |
Aug
(5) |
Sep
(21) |
Oct
(33) |
Nov
(42) |
Dec
(34) |
| 2007 |
Jan
(26) |
Feb
(27) |
Mar
(54) |
Apr
(37) |
May
(68) |
Jun
(81) |
Jul
(55) |
Aug
(86) |
Sep
(60) |
Oct
(33) |
Nov
(33) |
Dec
(47) |
| 2008 |
Jan
(37) |
Feb
(37) |
Mar
(52) |
Apr
(63) |
May
(98) |
Jun
(70) |
Jul
(61) |
Aug
(38) |
Sep
(64) |
Oct
(55) |
Nov
(48) |
Dec
(111) |
| 2009 |
Jan
(68) |
Feb
(83) |
Mar
(102) |
Apr
(140) |
May
(156) |
Jun
(65) |
Jul
(75) |
Aug
(26) |
Sep
(28) |
Oct
(31) |
Nov
(38) |
Dec
(78) |
| 2010 |
Jan
(53) |
Feb
(33) |
Mar
(87) |
Apr
(94) |
May
(77) |
Jun
(84) |
Jul
(66) |
Aug
(74) |
Sep
(53) |
Oct
(40) |
Nov
(38) |
Dec
(31) |
| 2011 |
Jan
(19) |
Feb
(17) |
Mar
(43) |
Apr
(53) |
May
(42) |
Jun
(35) |
Jul
(19) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
|
| 2012 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2017 |
Jan
(1) |
Feb
(3) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
(1) |
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lutz M. <lu...@go...> - 2004-04-25 19:18:28
|
[This is the third time I'm sending this email. I sent it to gnuplot-beta and gnuplot-bugs before, but I didn't get any replies. This alone wouldn't be suspicious, but I also didn't receive a copy of my email, which makes me think that there might be something strange going on with the list configuration. This time I'm posting from my subscription address. If this is required to post to a list, it should be stated on the SF page.] I noticed the following behavior of gnuplot 4.0, see the attached file: the command cat test.gp | gnuplot -persist aborts with the error message "invalid character", but running this script from within gnuplot with the "load" command works just fine. Under gnuplot 3.7.1, both methods produce the desired result. I'm sorry for the very strange looking testcase, I couldn't reduce it any more and still trigger this behavior. Even deleting a single space in front of the "plot" command cures this problem. Lutz |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-04-22 11:41:11
|
On Thu, 22 Apr 2004, Hans-Bernhard Broeker wrote: > That suggests two possible reasons: > > 1) Command line length > 2) Timing > > I suspect the latter, since running this on Linux with a different > terminal than X11, like this: > > cat test.gp | env GNUTERM=dumb gnuplot -persist > > gave me a plot instead of any error message. I'll eat those words and claim the opposite: it *is* about line length, and I've found out why. The crucial bit is that one of your backslashes from line continuations falls exactly onto the border where the input_line buffer is extended by another KiB, i.e. when read_line() calls extend_input_line() in line 2476 of command.c. The problem is the 'continue' that follows this call --- it jumps across the handling of backslash-newline. Patch is under construction. The reason this doesn't happen if you 'load' this same script, I think, is that the gnuplot prompt is formally part of the input line, i.e. your critical point gets shifted by a couple of charactes, and the problem disappears. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-04-22 00:46:52
|
On Wed, 21 Apr 2004, Lutz Maibaum wrote: > I noticed the following behavior of gnuplot 4.0, see the attached file: the > command > cat test.gp | gnuplot -persist > aborts with the error message "invalid character", but running this script > from within gnuplot with the "load" command works just fine. Under gnuplot > 3.7.1, both methods produce the desired result. Which platform? > I'm sorry for the very strange looking testcase, I couldn't reduce any more > and still trigger this behavior. Even deleting a single space in front of the > "plot" command cures this problem. That suggests two possible reasons: 1) Command line length 2) Timing I suspect the latter, since running this on Linux with a different terminal than X11, like this: cat test.gp | env GNUTERM=dumb gnuplot -persist gave me a plot instead of any error message. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Lutz M. <ma...@uc...> - 2004-04-21 22:18:40
|
I noticed the following behavior of gnuplot 4.0, see the attached file: the command cat test.gp | gnuplot -persist aborts with the error message "invalid character", but running this script from within gnuplot with the "load" command works just fine. Under gnuplot 3.7.1, both methods produce the desired result. I'm sorry for the very strange looking testcase, I couldn't reduce any more and still trigger this behavior. Even deleting a single space in front of the "plot" command cures this problem. Lutz |
|
From: Harald A. <an...@he...> - 2004-04-21 13:11:08
|
Hi, with gnuplot 4.0 do: > set size square; set pm3d map; splot exp(-(x-y)**2) > set xrange [-10:10]; set yrange [-10:10]; replot In the second plot, i.e. in the replot the y axis is upside down. This did not happen with Version 3.8j patchlevel 0. Cheers, -ha |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-04-21 11:55:00
|
On Wed, 21 Apr 2004, Harald Anlauf wrote: > Hi, > > when running "make check" after a successful build of gnuplot 4.0 I > encounter the following problem: [...] > It may be a problem with the PATH variable. I modified demo/Makefile > so that it reads [...] Formatting was a little botched, but I see what you actually changed: you kept the old $PATH at the end of the newly set one. Yes, that makes sense. I'll check in a change like that unless someone objects (quickly). Thanks for taking the time to dig into this. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Harald A. <an...@he...> - 2004-04-21 09:45:42
|
Hi, when running "make check" after a successful build of gnuplot 4.0 I encounter the following problem: [...] Making check in demo /usr/local/src/packages/gnuplot-4.0.0/demo make[1]: Entering directory `/usr/local/src/packages/gnuplot-4.0.0/demo' make check-local make[2]: Entering directory `/usr/local/src/packages/gnuplot-4.0.0/demo' make[2]: *** [check-noninteractive] Error 128 make[2]: Leaving directory `/usr/local/src/packages/gnuplot-4.0.0/demo' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/usr/local/src/packages/gnuplot-4.0.0/demo' make: *** [check-recursive] Error 1 A window pops up that it cannot find cygwin1.dll . Since the installed gnuplot appears to work, I looked for a quick fix. It may be a problem with the PATH variable. I modified demo/Makefile so that it reads check-noninteractive: $(BINARY_FILES) @if test -z "$(GNUTERM)" ; then \ ( bdir=`pwd` ; PATH=$$bdir/../src:$$PATH GNUPLOT_DRIVER_DIR=$$bdir/../src \ GNUPLOT_LIB=$(srcdir) $(GNUPLOT) $(DEMO) </dev/null ); \ else \ ( bdir=`pwd` ; PATH=$$bdir/../src:$$PATH GNUPLOT_DRIVER_DIR=$$bdir/../src \ GNUTERM=$(GNUTERM) GNUPLOT_LIB=$(srcdir) $(GNUPLOT) $(DEMO) </dev/null ); \ fi to make the check succeed. Keep up the good work! Cheers, -ha |
|
From: <su...@am...> - 2004-04-18 02:19:20
|
$BFMA3$N%a!<%k$GBgJQ62=L$G$9!#;d$O7HBS@lMQ%3%_%e%K%#%F%#!<%5%$(B $B%H!V(BClubD$B!W$N%U%i%s%A%c%$%:$r1?1D$9$k%"%a!<%8%s%0%W%i%s$NNk(B $BLZ$H?=$7$^$9!#(B $B$<$R$H$b;d$I$b$N9T$C$F$k%U%i%s%A%c%$%:%7%9%F%`$K;22C$7$FD:$-(B $B$?$/;W$$!"$4O"Mm$5$;$FD:$$$?<!Bh$G$9!#$3$N$h$&$J9-9p$K$O@5D>(B $B$&$s$6$j$5$l$F$$$k$3$H$H;W$$$^$9$,!"=P8}$N8+$($J$$8=:_$NIT67(B $B$K$"$C$FIT0B$r2r>C$7F@$k%S%8%M%9$G$9$N$G!"$4LLE]$G$b!"$<$R:G(B $B8e$^$G$40lFI2<$5$$!#(B $B!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B ClubD$B%U%i%s%A%c%$%:%7%9%F%`$H$O!)(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y(B $B%j%9%/(I$$B0l@Z$NHqMQ$rH<$J$o$:(I$$B%3%_%e%K%F%#%5%$%H(B(Jsky(I$(Bi-mode$B!"(B $B#E#ZBP1~(B)$B$,1?1D$G$-(I$$BB?$/$N<}F~$r3MF@$G$-$k5!2q$rDs6!$9$k(B $B%7%9%F%`$G$9!#(B $B!z(,(,(,(,(,(,(,(,(,(,(,>\:Y$O(Bhttp://www.amazing-plan.com/$B$X(B $B!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B $B2CLA6b!"1?1DHq$J$I$O0l@ZITMW!*(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y(B $B4JC1$JEPO?$N$_$GL5NA$G%5%$%H%*!<%J!<$K$J$l$^$9!#2?$i%j%9%/$r(B $BIi$&$3$H$J$/!"4JC1$J<jB3$-$N$_$G%5%$%H%*!<%J!<$K$J$l$^$9!#$7(B $B$+$b!"%9%?!<%H;~$GB??t$N2q0w$,EPO?:Q$_$J$N$G%5%$%H$r?7$?$KN)(B $B$A>e$2$k$H$$$&O+NO$,MW$j$^$;$s!#(B $B!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B $BLLE]$J%a%s%F%J%s%9!"2q0w4IM}$OITMW!*(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y(B $B%a%s%F%J%s%9!"2q0w4IM}$,0l@ZITMW$J$N$G0B?4$7$F1?1D$,$G$-$^$9!#(B $B!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B $B7QB3$7$?0BDj<}F~$,F@$i$l$k!#Js=7$O(B3$B<oN`$G6H3&%H%C%W%/%i%9!*(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y(B $B"!CK@-2q0wGd>eJs=7"*CK@-%f!<%6!<$NAmGd>e$N(B30%$B$,Js=7$K$J$j$^$9!*(B $B"!=w@-2q0wGd>eJs=7"*=w@-2q0w(B1$BL>$K$D$-(B30$B1_$NJs=7$K$J$j$^$9!*(B $B"!BeM}E9<h<!$.Js=7"*<+?H$N%5%$%H$h$j?7$?$KBeM}E9$KEPO?$5$l$?%5%$(B $B%H$+$i$NGd>e$,$"$C$?>l9g!"$=$NGd>e$KBP$7$F$N(B10%$B$,Js=7$K$J$j$^$9!*(B $B!z(,(,(,(,(,(,(,(,(,(,(,(,(,>\:Y$O(Bhttp://www.amazing-plan.com/$B$X(B $B!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B $BB>$K??;w$,$G$-$J$$;B?7$J%3%s%F%s%D$N?t!9!*(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y(B $B%j%"%k$J;w4i3(:n@.5!G=$d9b2;<A$NCe%a%m$J$IB>$K4JC1$K??;w$G$-$J$$(B $BL%NOE*$J%3%s%F%s%D$,K~:\$GC1$J$k(B1$B%3%_%e%K%#%F%#!<%5%$%H$N?h$r1[$(!"(B $BI}9-$$5RAX$N<h$j9~$`$3$H$,2DG=$G$9!#(B $B!y(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B $B%P%J!<9-9pBeM}E9$bF1;~Jg=8!*(B $B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!!y(B $B8=:_1?1D$5$l$F$$$k%5%$%H$N0lIt$K9-9p%P%J!]$rE=$C$F$$$?$@$/$@$1$G(B $B0BDj$7$?<}F~$,F@$i$l$^$9!#Js=73[$O%3%_%e%K%#%F%#!<BeM}E9$HF1MM$G(B $B$9!"4{B8$N%P%J!]9-9pNA(I"(B1$B%/%j%C%/2?1_(I#$B$H$O(I$$BA4$/0[$J$j!"Js=73[$O(I$$B%P(B $B%J!]9-9p$+$i(BClubD$B$KEPO?$7$?%f!<%6!<$,%]%$%s%H9XF~$K$h$kGd>e$,H/@8(B $B$9$k$H(I$$BBeM}E9Js=7$H$7$F0lDj3[$,%5%$%H%*!<%J!<$K%P%C%/$5$l$k%7%9%F(B $B%`$G$9(I!$B0J8e$b$=$N%f!<%6!<$+$iGd>e$,H/@8$9$k$H7QB3$7$FBeM}E9Js=7$,(B $BH/@8$$$?$7$^$9$N$G0BDj$7$?<}F~$,F@$i$l!"C1$K(B1$B%/%j%C%/2?1_$N9-9pNA(B $B$H$OL@$i$+$K0c$$$^$9(I!(B $B!z(,(,(,(,(,(,(,(,(,(,(,(,(,(,>\:Y$O(Bhttp://www.amazing-plan.com/$B$X(B $B:G8e$^$G$*FI$_D:$-$^$7$F@?$K$"$j$,$H$&$4$6$$$^$7$?!#(B $B$*K;$7$$Cf!"BgJQ62=L$G$O$4$6$$$^$9$,!":#2s$4>R2p$5$;$F$$$?$@$$$?(B $B%7%9%F%`$OC1$J$k>R2p$K$H$I$^$k$b$N$G$O$J$/!"I,$:$d$*Lr$KN)$F$k$b$N(B $B$H3N?.$r$7$F$*$j$^$9!#(B $B$3$N%7%9%F%`$K$D$$$F$N$4ITL@$JE@!"$4<ALd$J$I$,$4$6$$$^$7$?$i$*5$7Z(B $B$K2<5-$^$G$*Ld9g$;2<$5$$!#(B $B$=$l$G$O!"2?B4$48!F$$N$[$I$h$m$7$/$*4j$$?=$7>e$2$^$9!#(B $BJ@<R$+$i$N%a!<%k$,ITMW$JJ}$d%a!<%k$,=EJ#$7$F$$$?>l9g$O$4LBOG$r$*3]$1(B $BCW$7$?;v$r?<$/$*OM$SCW$7$^$9!#(B $B:#8e!"J@<R$+$i$N$40FFb$,ITMW$J>l9g$O!"$*<j?t$G$9$,2<5-$N%"%I%l%9$^$G(B $BITMW$N;]!"$45-F~D:$-DLCNJV?.$r$*4j$$$7$^$9!#%a!<%k$r$*Aw$j$7$?$3$H$K(B $B$h$jITL{2w$J;W$$$r$5$;$F$7$^$$?=$7Lu$4$6$$$^$;$s!#(B $B4k2h!&1?1D(B $B%"%a!<%8%s%0%W%i%s(B $BC4Ev!'NkLZ(B E$B!](BMail: su...@am... |
|
From: <ti...@co...> - 2004-04-16 20:11:21
|
http://www.gnuplot.info/docs/gpcard.pdf file has been saved in PORTRAIT mode. It needs to be saved in LANDSCAPE mode. |
|
From: Isao S. <sa...@bi...> - 2004-04-05 04:38:51
|
Dear maintainers of gnuplot.
In fit.c: The covar matrix is calculated base on err_data if given by a
user. Thus, scaling of parameter errors occurs twice and cancels out
each other if err_data are explicitly given.
For example, if you fit the data,
# fit data (data.dat)
0 1.1 100
1 1.9 100
2 5.1 100
3 9.9 100
4 17.1 100
With the function f(x) = a * x**2 + b, results of fitting from "fit f(x)
'data.dat' using 1:2 via a, b" and "fit f(x) 'data.dat' using 1:2:3 via
a, b" are identical (except for sum of squares of residuals). However,
"Asymptotic Standard Error" of parameters should increase as errors
increase.
I think this bug can be resolved with a patch attached below.
I don't subscribe this mailing list. Please inform me if there is
something with this patch.
Regards.
----
Isao Sakane <sa...@bi...>
Tottori University, Faculty of Engineering, Dept. of Biotechnology,
Koyamacyo-minami 4-101, Tottori-city, Tottori, Japan. ZIP:680-8552
----
Hear is a patch.
--- fit.c.old 2004-04-05 09:22:07.000000000 +0900
+++ fit.c 2004-04-05 12:09:29.000000000 +0900
@@ -745,7 +745,17 @@
covar = C + num_data;
Invert_RtR(C, covar, num_params);
- /* calculate unscaled parameter errors in dpar[]: */
+ if (columns <= 2) {
+ /* scale covar matrix based on chisq */
+ chisq /= (num_data - num_params);
+ for (i = 0; i < num_params; i++) {
+ /* only lower triangle needs to be handled */
+ for (j = 0; j <= i; j++)
+ covar[i][j] *= chisq;
+ }
+ }
+
+ /* calculate parameter errors in dpar[]: */
dpar = vec(num_params);
for (i = 0; i < num_params; i++) {
/* FIXME: can this still happen ? */
@@ -761,11 +771,6 @@
covar[i][j] /= dpar[i] * dpar[j];
}
- /* scale parameter errors based on chisq */
- chisq = sqrt(chisq / (num_data - num_params));
- for (i = 0; i < num_params; i++)
- dpar[i] *= chisq;
-
Dblf("Final set of parameters Asymptotic Standard
Error\n");
Dblf("======================= =======================
===\n\n");
|
|
From: <gle...@ke...> - 2004-03-30 08:31:28
|
Got the latest version of gnuplot for windows=2E When doing this function plot sin(x) it plot it perfectly then when I do set xrange[0:100] and do replot, the graph is no longer a pe= rfect sinewave=2E Is this a bug ? To correct the problem one have to close the pro= gram, i=2Ee=2E the set xrange[0:10] and replot those not fix this problem=2E= Hope to hear from you=2E Thanks=2E Best Regards, Glenn=2E |
|
From: <Mai...@no...> - 2004-03-24 09:20:47
|
--- The message cannot be delivered to the following address. --- 13...@no... Mailbox unknown or not accepting mail. 550 <13...@no...>... User unknown |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-02-23 12:18:13
|
On Mon, 23 Feb 2004, Eric Gullichsen wrote: > > There appears to be a bug related to filledcurve. > > I believe: > > plot [0:1000] [-10:10] \ > (x>=400 && x<600 ? 2 : 1/0) with filledcurve y1=0 lt 1, \ > (x>600 && x<650 ? 2 : 1/0) with filledcurve y1=0 lt 2 > > should result in the colored rectangles being adjacent at x=600. Not as you wrote it. Note that for x==600, *both* plotted functions are undefined, and that gnuplot doesn't have infinite resolution. Functions are sampled at a finite number of points (--> "set samples"). If there doesn't happen to be a sample at exactly x==600, this can't work as you wanted it to. So: make those comparision x<=600 and x>=600, and set samples to a value that guarantees a sample at x==600, and you might be getting somewhere. (set samples 101 works). -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: <egu...@co...> - 2004-02-23 02:44:01
|
There appears to be a bug related to filledcurve. I believe: plot [0:1000] [-10:10] (x>=400 && x<600 ? 2 : 1/0) with filledcurve y1=0 lt 1,(x>600 && x<650 ? 2 : 1/0) with filledcurve y1=0 lt 2 should result in the colored rectangles being adjacent at x=600. However, the x extents of both filledcurves seem to be smaller than specified. It does not appear to be display driver related, as both X11 and PostScript output have the same problem. It appears in 3.8j.0, and the latest 3.8k.1 version. I an unfamiliar with the gnuplot source, so thanks in advance for any suggestions as to where I should start looking to try to fix this. - Eric Gullichsen egullich@...NOSPAMPLEASE...colo.to |
|
From: Harald K. <ko...@sc...> - 2004-01-23 17:36:28
|
Hi,
I'm now using gnuplot 3.8.0j for quite a while (and older versions for ages)
mostly for data visualisation, data fits, automated measurement analysis etc.
yesterday I picked your latest CVS version. here are a few bugs/problems
which I've found (most of them exist in 3.8.0j too), and realizing that
4.0 seems to be not too far away, it's high time to report some
(for me obvious) problems/bugs:
1) pdf driver: that's a great new driver -- I really love that addition!
the pdf rendering looks good, but the PDF file is missing some information/hint/...
that the (default) plot size is _landscape_. acroread displays the the diagrams
just fine, but when trying to print them to postscript file/printer with it's
default page setup "portrait", I get a small landscape diagram on a portrait page
with lots of white space above and below the plot.
when I switch the acroread page setup to "landscape", printout is ok.
somehow, other pdf tools can inform acroread to set the page setup to "landscape",
so printing is ok without twiddling with page setup settings first.
2) readline(?), SIGTSTP, and gnuplot_x11 communication (and libreadline?)
I'm building gnuplot on various Linux plattforms (and hpux/aix/solaris/osf1/*bsd)
using the following setup
./configure --without-linux-vga --without-gd --without-lisp-files --without-tutorial --with-readline=gnu
some tests quite a while ago with gnuplot 3.8h.0 and 3.8j.0
seemed to show that some/all of the following suspend/resume problems
showhow relate to the use of "--with-readline=gnu" (both
libreadline 4.2 and 4.3), because the minimal builtin readline support
is far from being sufficient when working a lot "online" with
gnuplot while trying to analyze new data sets and twiddling
with best displays/data filters/fits/..., so not using
--with-readline=gnu is not an option:(
a) when suspending gnuplot with CTRL-Z or sending SIGTSTP (not SIGSTOP,
that's working fine!) while no X11 plot window is open/active,
gnuplot exits silently. try:
gnuplot
CTRL-Z
fg
now gnuplot exits without error (strace shows regular rundown).
gnuplot
plot sin(x)
CTRL-Z
fg
replot
is no problem, but
gnuplot
plot x
set term postscript
CTRL-Z
fg
again kills gnuplot (tried on various Linux versions with recent kernels).
b) if gnuplot with "active" x11 display (no other "set term ...")
gets suspended with CTRL-Z and while being stopped, you move
the mouse a bit over the gnuplot_x11 window, the gnuplot_x11
(and X server) start to suck all CPU time until gnuplots
gets resumed (and sometimes (not always), one has to move
the mouse across the gnuplot_x11 window againon)
strace on gnuplot_x11 shows the following sequence while looping:
18:18:01.409522 select(4, [0 1 3], NULL, NULL, NULL) = 1 (in [1])
18:18:01.413039 write(3, "\177\30\1\0", 4) = 4
18:18:01.420691 ioctl(3, FIONREAD, [0]) = 0
18:18:01.421109 write(1, "\0\0\0\0\t\1\0\0&\1\0\0\0\0\0\0\0\0\0\0P\376\5\10\320\356"..., 120) = -1 EAGAIN (Resource temporarily unavailable)
just an idea:
strace shows that gnuplot_x11 gets both SIGTSTP and SIGCONT,
maybe this can be used to disable/enable the mouse support ?
c) another related problem is that after suspend/resume of gnuplot
with hanging X11 display (can also happen when gnuplot_x11 gets
redraw events because it was hidden/uncovered by other windows)
is that the gnuplot user terminal/command interface hangs (no input possible)
after resume until the mouse pointer got moved over the gnuplot_x11
window. only after "touching" gnuplot_x11 unlocks the gnuplot
command interface.
3) I'm just starting to use gnuplot on M$ Win-XY for my first time.
obviously it's great too, but by default I'm hardly missing the
possibility to use shell commands in plot "datafile" using
plot "< some command"
but by default PIPES config is not set for windows builds :-(
I've read your comments about PIPES in config/makefile.mgw
but for me (Windows novice) it's unclear if this is a problem
for _all_ windows versions (e.g. would WinXP be any better?).
any chance that you'll change that to PIPES=1 for windows
by default, or to supply two win32 binaries with both settings ?
right now I still hope (dream?) that it'll be possible to use MSYS
to allow "real" shell commands in plot "< ..."
I'll be happy to give more details if necessary or test whatever
patches/changes you'd like being tested...
anyway, thanks for your great work and the wonderful tool gnuplot !!
Harald Koenig
--
"I hope to die ___ _____
before I *have* to use Microsoft Word.", 0--,| /OOOOOOO\
Donald E. Knuth, 02-Oct-2001 in Tuebingen. <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig \/\/\/\/\/\/\/\/\/
science+computing ag // / \\ \
ko...@sc... ^^^^^ ^^^^^
|
|
From: Hans-Bernhard B. <br...@ph...> - 2003-12-29 01:22:08
|
On Thu, 25 Dec 2003, Richard B. Gilbert wrote: > My C compiler (DECC V6.5 under OpenVMS/Alpha V7.3-1) produced the > following informational message: > > if (xmin_hl < 0 || xmax_hl > XREDUCE(xright) - XREDUCE(xleft)) > ........^ [...] > Since since the expression "xmin_hl<0" must always evaluate to FALSE and > since there are simpler and clearer ways to express a NOOP, it seems to > me that this must be a bug. No, it's a documented feature of the source code. Look at the comment by me, directly above that line of code... -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Richard B. G. <rgi...@co...> - 2003-12-25 22:55:07
|
Gentlemen:
My C compiler (DECC V6.5 under OpenVMS/Alpha V7.3-1) produced the
following informational message:
if (xmin_hl < 0 || xmax_hl > XREDUCE(xright) - XREDUCE(xleft))
........^
%CC-I-QUESTCOMPARE, In this statement, the unsigned expression "xmin_hl"
is being compared with a relational operator to a constant whose
value is not greater than zero. This might not be what you intended.
at line number 2664 in file SYS$SYSDEVICE:[DRAGON.UTILS.GNUPLOT-3_7_3]HI
DDEN3D.C;1
xmin_hl is declared as "static unsigned int".
Since since the expression "xmin_hl<0" must always evaluate to FALSE and
since there are simpler and clearer ways to express a NOOP, it seems to
me that this must be a bug.
Thank you.
|
2173 messages has been excluded from this view by a project administrator.
