Menu
▾
▴
gnuplot-beta — Developers and beta testers of new gnuplot code
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(83) |
Nov
(57) |
Dec
(111) |
| 2004 |
Jan
(38) |
Feb
(121) |
Mar
(107) |
Apr
(241) |
May
(102) |
Jun
(190) |
Jul
(239) |
Aug
(158) |
Sep
(184) |
Oct
(193) |
Nov
(47) |
Dec
(68) |
| 2005 |
Jan
(190) |
Feb
(105) |
Mar
(99) |
Apr
(65) |
May
(92) |
Jun
(250) |
Jul
(197) |
Aug
(128) |
Sep
(101) |
Oct
(183) |
Nov
(186) |
Dec
(42) |
| 2006 |
Jan
(102) |
Feb
(122) |
Mar
(154) |
Apr
(196) |
May
(181) |
Jun
(281) |
Jul
(310) |
Aug
(198) |
Sep
(145) |
Oct
(188) |
Nov
(134) |
Dec
(90) |
| 2007 |
Jan
(134) |
Feb
(181) |
Mar
(157) |
Apr
(57) |
May
(81) |
Jun
(204) |
Jul
(60) |
Aug
(37) |
Sep
(17) |
Oct
(90) |
Nov
(122) |
Dec
(72) |
| 2008 |
Jan
(130) |
Feb
(108) |
Mar
(160) |
Apr
(38) |
May
(83) |
Jun
(42) |
Jul
(75) |
Aug
(16) |
Sep
(71) |
Oct
(57) |
Nov
(59) |
Dec
(152) |
| 2009 |
Jan
(73) |
Feb
(213) |
Mar
(67) |
Apr
(40) |
May
(46) |
Jun
(82) |
Jul
(73) |
Aug
(57) |
Sep
(108) |
Oct
(36) |
Nov
(153) |
Dec
(77) |
| 2010 |
Jan
(42) |
Feb
(171) |
Mar
(150) |
Apr
(6) |
May
(22) |
Jun
(34) |
Jul
(31) |
Aug
(38) |
Sep
(32) |
Oct
(59) |
Nov
(13) |
Dec
(62) |
| 2011 |
Jan
(114) |
Feb
(139) |
Mar
(126) |
Apr
(51) |
May
(53) |
Jun
(29) |
Jul
(41) |
Aug
(29) |
Sep
(35) |
Oct
(87) |
Nov
(42) |
Dec
(20) |
| 2012 |
Jan
(111) |
Feb
(66) |
Mar
(35) |
Apr
(59) |
May
(71) |
Jun
(32) |
Jul
(11) |
Aug
(48) |
Sep
(60) |
Oct
(87) |
Nov
(16) |
Dec
(38) |
| 2013 |
Jan
(5) |
Feb
(19) |
Mar
(41) |
Apr
(47) |
May
(14) |
Jun
(32) |
Jul
(18) |
Aug
(68) |
Sep
(9) |
Oct
(42) |
Nov
(12) |
Dec
(10) |
| 2014 |
Jan
(14) |
Feb
(139) |
Mar
(137) |
Apr
(66) |
May
(72) |
Jun
(142) |
Jul
(70) |
Aug
(31) |
Sep
(39) |
Oct
(98) |
Nov
(133) |
Dec
(44) |
| 2015 |
Jan
(70) |
Feb
(27) |
Mar
(36) |
Apr
(11) |
May
(15) |
Jun
(70) |
Jul
(30) |
Aug
(63) |
Sep
(18) |
Oct
(15) |
Nov
(42) |
Dec
(29) |
| 2016 |
Jan
(37) |
Feb
(48) |
Mar
(59) |
Apr
(28) |
May
(30) |
Jun
(43) |
Jul
(47) |
Aug
(14) |
Sep
(21) |
Oct
(26) |
Nov
(10) |
Dec
(2) |
| 2017 |
Jan
(26) |
Feb
(27) |
Mar
(44) |
Apr
(11) |
May
(32) |
Jun
(28) |
Jul
(75) |
Aug
(45) |
Sep
(35) |
Oct
(285) |
Nov
(99) |
Dec
(16) |
| 2018 |
Jan
(8) |
Feb
(8) |
Mar
(42) |
Apr
(35) |
May
(23) |
Jun
(12) |
Jul
(16) |
Aug
(11) |
Sep
(8) |
Oct
(16) |
Nov
(5) |
Dec
(8) |
| 2019 |
Jan
(9) |
Feb
(28) |
Mar
(4) |
Apr
(10) |
May
(7) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(23) |
Dec
(3) |
| 2020 |
Jan
(19) |
Feb
(3) |
Mar
(22) |
Apr
(17) |
May
(10) |
Jun
(69) |
Jul
(18) |
Aug
(23) |
Sep
(25) |
Oct
(11) |
Nov
(20) |
Dec
(9) |
| 2021 |
Jan
(1) |
Feb
(7) |
Mar
(9) |
Apr
|
May
(1) |
Jun
(8) |
Jul
(6) |
Aug
(8) |
Sep
(7) |
Oct
|
Nov
(2) |
Dec
(23) |
| 2022 |
Jan
(23) |
Feb
(9) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(1) |
Jul
(6) |
Aug
(8) |
Sep
(30) |
Oct
(5) |
Nov
(4) |
Dec
(6) |
| 2023 |
Jan
(2) |
Feb
(5) |
Mar
(7) |
Apr
(3) |
May
(8) |
Jun
(45) |
Jul
(8) |
Aug
|
Sep
(2) |
Oct
(14) |
Nov
(7) |
Dec
(2) |
| 2024 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
(7) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
(4) |
Dec
(14) |
| 2025 |
Jan
(22) |
Feb
(6) |
Mar
(5) |
Apr
(14) |
May
(6) |
Jun
(11) |
Jul
(19) |
Aug
|
Sep
(17) |
Oct
(1) |
Nov
(1) |
Dec
|
|
From: m s. <mw...@us...> - 2021-02-05 00:39:45
|
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I was checking out v5.4.1 on centos 7.2 with gdlib 2.3.0. I
simplified the problem down to this script.</p>
<blockquote>
<p>unset grid<br>
set nokey<br>
set clip two<br>
<br>
set title "GD Line Bug"<br>
set size 1,1<br>
set term png small truecolor butt size 500,400 <br>
unset border<br>
unset tics<br>
set output 'mike.png'<br>
set xr [0:6];</p>
set yr [0:2]<br>
<br>
plot '-' u 1:2 notitle w l lt 1 lw 9<br>
2.0 1.0<br>
5.0 1.0<br>
e<br>
</blockquote>
<p>I get a small, but noticeable dash at the beginning of the
plotted line. The larger the linewidth the more noticeable it
becomes.</p>
<p>I inserted a print statement in the PNG_vector function in
gd.trm. What I see are two calls to PNG_vector. The first call
tries to plot a line of zero length. The second call plots the
correct line. <br>
</p>
<p>So why is the zero length line plotted?</p>
<p>MikeS</p>
<p><br>
</p>
</body>
</html>
|
|
From: Ethan A M. <me...@uw...> - 2021-01-14 07:55:55
|
Probably not a big deal, but...
I believe this commit to be incorrect.
It is not true that passing the negative of an unsigned int requires a cast.
Or if it is true, then something is wrong with the compiler.
If the function has a prototype (now required!) then arguments are promoted to
match the prototype.
fprintf() is a weird special case because it is a variadic function but nevertheless
anything given a format specifier %d will be promoted to integer.
This is covered in section 6.5.2.2 of the ISO C standard (checked in draft dated 2007)
If for some reason there is a real problem here I would prefer to understand
what it is. Did you get a compiler warning? What compiler?
Do you have a test case where this commit actually makes a difference to the output?
If a change is necessary for some reason, I would rather consider
all of these structure fields to int rather than unsigned.
*diff --git a/src/term_api.h b/src/term_api.h*
*index c836e19cd..f8898c0b5 100644*
*--- a/src/term_api.h*
*+++ b/src/term_api.h*
@@ -290,7 +290,7 @@ typedef enum t_imagecolor { IC_PALETTE, IC_RGB, IC_RGBA }
- unsigned int xmax,ymax,v_char,h_char,v_tic,h_tic;
+ int xmax,ymax,v_char,h_char,v_tic,h_tic;
best,
Ethan
%% commit c407e30e
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -410,11 +410,11 @@ TEXDRAW_graphics()
/* enforce bounding box */
fprintf(gpoutfile, "\\move (0 0) \\rmove (%d %d)\n",
term->xmax, term->ymax);
} else {
fprintf(gpoutfile, "\\move (0 0) \\rlvec (%d 0) \\rlvec (0 %d) \\rlvec (%d 0) \\ifill f:%0.2f\n",
- term->xmax, term->ymax, -term->xmax,
+ term->xmax, term->ymax, - (int) term->xmax,
TEXDRAW_background);
}
TEXDRAW_last_type = 0;
TEXDRAW_type = 0;
@@ -814,11 +814,11 @@ TEXDRAW_fillbox(int style,
// outline box using relative moves
fprintf(gpoutfile, "\\move (%d %d)", x1, y1);
fprintf(gpoutfile, "\\rlvec (%d %d)", width, 0);
fprintf(gpoutfile, "\\rlvec (%d %d)", 0, height);
- fprintf(gpoutfile, "\\rlvec (%d %d)", -width, 0);
+ fprintf(gpoutfile, "\\rlvec (%d %d)", - (int) width, 0);
// the polygon is closed automatically by fill
fprintf(gpoutfile, "\\ifill f:%0.2f\n", gray);
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
From: Bastian M. <bma...@we...> - 2020-12-22 16:33:53
|
Another somewhat simplified variant of the code is now in the master branch.
It's been tested with MSVC, MinGW-w64, and OpenWatcom for console gnuplot
and wgnuplot.
We still translate the complete command line to UTF-8. I now think this is a
desirable step, which enables using Unicode also for -e commands. As a next
step, we should probably change the default encoding to UTF-8. This
backwards-incompatible change should have been made with 5.4 already.
Bastian
> Gesendet: Freitag, 04. Dezember 2020 um 14:04 Uhr
> Von: "Allin Cottrell" <cot...@wf...>
> An: "Bastian Märkisch" <bma...@we...>
> Cc: "gnuplot-beta" <gnu...@li...>
> Betreff: Re: Aw: filenames on MS Windows: follow-up
>
> On Thu, 3 Dec 2020, Bastian Märkisch wrote:
>
> > Dear Allin,
> >
> > sorry for being slow to work on this. There is a fundamental issue with
> > the approach, which I am working on how to resolve best. Translating all
> > the command line arguments to UTF-8 is a great step forward and the
> > loading of files works fine as you point out. But this change also
> > affects and potentially breaks the -e option (try e.g.
> > -d -e "print 'öäü'").
>
> OK, I take your point: any non-ASCII stuff in a "-e" clause on the
> command line is going to get mangled.
>
> > The best step in my opinion might be to just change gnuplot's default
> > encoding to utf8. This will break backward compatibility, though. A
> > remedy could be new command line options -a/-u which choose the system's
> > default encoding ("ANSI") or the utf8 encoding.
>
> I have one other thought, and I'll try experimenting. Besides
> setting argv to the UTF-8 recoded argument array in winmain.c, we
> could define (say) aargv to the "ANSI" version:
>
> #define aargv __argv
>
> then when iterating over the args in the test for interactivity
> (around line 630 in winmain.c) add a clause such as:
>
> if ((argv[i][0] == '-') && (argv[i][1] == 'e')) {
> if (i < argc - 1) {
> argv[i+1] = aargv[i+1];
> }
> }
>
> This would (I think) replace the UTF-8 follow-up to -e with the
> original locale version, for passing to gnumain().
>
> > Please find attached a simplified version of your patch, which also
> > works for console mode gnuplot and other compilers than MinGW.
>
> Thanks.
>
> Allin Cottrell
|
|
From: Bastian M. <bma...@we...> - 2020-12-19 16:22:15
|
Binary releases for OS/2/eComStation/ArchaOS, as well as for DOS (DJGPP) are now available. Bastian |
|
From: Bastian M. <bma...@we...> - 2020-12-19 13:44:34
|
Dear gnuplotters, Windows binary packages of version 5.4.1 as installer and in 7zip format are now available on SF. Best, Bastian |
|
From: Ethan A M. <me...@uw...> - 2020-12-17 19:00:33
|
On Wednesday, 16 December 2020 22:35:17 PST ASSI wrote: > Ethan A Merritt writes: > > Since I envisioned it as a histogramming tool, it did not occur to > > me that users would want to plot "with lines" rather than using > > boxes or impulses. Therefore I did not think about or test the > > clipping behaviour. > > That fix has rippled through to openSUSE now, the y axis clipping now > works, but the x axis clipping has stopped getting applied… oops Ethan |
|
From: ASSI <Str...@ne...> - 2020-12-17 06:51:13
|
Ethan A Merritt writes: > Since I envisioned it as a histogramming tool, it did not occur to > me that users would want to plot "with lines" rather than using > boxes or impulses. Therefore I did not think about or test the > clipping behaviour. That fix has rippled through to openSUSE now, the y axis clipping now works, but the x axis clipping has stopped getting applied… Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds |
|
From: Uwe S. <uwe...@un...> - 2020-12-05 06:01:38
|
Hi, for the current stable version 5.41, there is a message on https://sourceforge.net/projects/gnuplot/files/gnuplot/5.4.1/ "Binary packages for Windows to appear here eventually." i tried the 5.4 windows testing version of gnuplot 5.4 (gp540-win64-mingw.exe, 2020-09-19, 34.7 MB) from https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/ on an older computer with windows10 and it works well. Particularly, the spider plots are a nice feature of 5.4. Is this version the best, I can use on windows? Thanks, Uwe https://github.com/uwe-schneider/gnuplotxyz |
|
From: Allin C. <cot...@wf...> - 2020-12-04 13:57:57
|
On Thu, 3 Dec 2020, Bastian Märkisch wrote:
> Dear Allin,
>
> sorry for being slow to work on this. There is a fundamental issue with
> the approach, which I am working on how to resolve best. Translating all
> the command line arguments to UTF-8 is a great step forward and the
> loading of files works fine as you point out. But this change also
> affects and potentially breaks the -e option (try e.g.
> -d -e "print 'öäü'").
OK, I take your point: any non-ASCII stuff in a "-e" clause on the
command line is going to get mangled.
> The best step in my opinion might be to just change gnuplot's default
> encoding to utf8. This will break backward compatibility, though. A
> remedy could be new command line options -a/-u which choose the system's
> default encoding ("ANSI") or the utf8 encoding.
I have one other thought, and I'll try experimenting. Besides
setting argv to the UTF-8 recoded argument array in winmain.c, we
could define (say) aargv to the "ANSI" version:
#define aargv __argv
then when iterating over the args in the test for interactivity
(around line 630 in winmain.c) add a clause such as:
if ((argv[i][0] == '-') && (argv[i][1] == 'e')) {
if (i < argc - 1) {
argv[i+1] = aargv[i+1];
}
}
This would (I think) replace the UTF-8 follow-up to -e with the
original locale version, for passing to gnumain().
> Please find attached a simplified version of your patch, which also
> works for console mode gnuplot and other compilers than MinGW.
Thanks.
Allin Cottrell |
|
From: Bastian M. <bma...@we...> - 2020-12-03 09:49:58
|
Dear Allin,
sorry for being slow to work on this. There is a fundamental issue with
the approach, which I am working on how to resolve best. Translating all
the command line arguments to UTF-8 is a great step forward and the
loading of files works fine as you point out. But this change also
affects and potentially breaks the -e option (try e.g.
-d -e "print 'öäü'").
The best step in my opinion might be to just change gnuplot's default
encoding to utf8. This will break backward compatibility, though. A
remedy could be new command line options -a/-u which choose the system's
default encoding ("ANSI") or the utf8 encoding.
Please find attached a simplified version of your patch, which also
works for console mode gnuplot and other compilers than MinGW. It does
not yet address the issue discussed above, though.
Bastian
> Gesendet: Samstag, 14. November 2020 um 22:41 Uhr
> Von: "Allin Cottrell" <cot...@wf...>
> An: "gnuplot-beta" <gnu...@li...>
> Betreff: filenames on MS Windows: follow-up
>
> I'm attaching a patch against gnuplot git master which does what I
> mentioned in
> https://sourceforge.net/p/gnuplot/mailman/message/37141539/ That is,
> it allows wgnuplot.exe to accept via the Windows command-line
> unicode filenames that cannot be represented in the user's "system
> codepage", and to successfully to open such files.
>
> This iteration of my patch uses native win32 APIs to perform the
> necessary recoding of filenames, as opposed to the previous
> iteration which used GLib.
>
> I gave evidence in
> https://sourceforge.net/p/gnuplot/mailman/message/37143153/
> that the patch is not disruptive of gnuplot's ability to open files
> named via the "load" command, in which case the encoding specified
> in the gnuplot script must be respected.
>
> The patch is activated only when compiling the program for Windows,
> and then only when the symbol WIDE_ARGS is defined.
>
> --
> Allin Cottrell
> Department of Economics
> Wake Forest University_______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> |
|
From: Ethan A M. <me...@uw...> - 2020-12-01 04:12:05
|
Gnuplot version 5.4.1 This release contains bug-fixes and a few changes back-ported from the development version. The most notable fix is for a regression in the handling of parameters to "call", either from a script or on the command line (Bugs #2298 #2368) Many of the other fixes are for error handling of odd input streams found by fuzzing. I have placed a source tarball for 5.4.1 on SourceForge https://sf.net/projects/gnuplot/files/gnuplot/5.4.1/gnuplot-5.4.1.tar.gz Release Notes with new feature list http://gnuplot.info/ReleaseNotes_5_4_1.html cheers, and happy plotting Ethan |
|
From: Dima K. <gn...@di...> - 2020-11-16 20:09:56
|
Yeah, I think I agree. It's really unfortunate that browsers can't agree on this, but here we are. For my use case drawing each cell independently as a rectangle is a bit much, so I'll just move to .png figures. Thanks for talking through this. |
|
From: Ethan A M. <me...@uw...> - 2020-11-14 22:56:24
|
On Saturday, 14 November 2020 12:21:40 PST Dima Kogan wrote:
> Hi.
>
> I'm seeing that currently our svg output produces blurred images. I'm
> attaching a patch to (sorta) fix this.
>
> Demo script:
>
> set terminal svg standalone
> set output "/tmp/tst.svg"
> set view map
> splot [0:10][0:10] '++' using 1:2:($1+$2) with image
>
> The images before and after the patch are attached. Using firefox, you
> can see the before-patch image containing smoothed pixels, while the
> after-patch image contains pixels with crisp edges, which is what we
> want I think.
My feeling is that we should not even try to track browser-specific quirks.
We already have an options to guarantee those crisp edges that so
far as I know works on all platforms and viewers:
gnuplot> help pixels
Some terminals use device- or library-specific optimizations to render image
data within a rectangular 2D area. This sometimes produces undesirable output,
e.g. bad clipping or scaling, missing edges. The `pixels` keyword tells
gnuplot to use generic code that renders the image pixel-by-pixel instead.
This rendering mode is slower and may result in much larger output files, but
should produce a consistent rendered view on all terminals.
Example:
plot 'data' with image pixels
See also the 4th plot in
http://gnuplot.sourceforge.net/demo_svg/heatmaps.html
> Unfortunate caveat: apparently firefox and chrome can't agree on what to
> call this property. Firefox wants "crisp-edges" to do this, while Chrome
> wants "pixelated". So today, this patch will do the right thing on
> Firefox, but not on Chrome. Anybody know how to make this work on both
> (and the others, I guess)?
>
> I'm on the fence about whether patching gnuplot to work with just one of
> the two is better than keeping them both blurry in the same way.
Better to fix it at the stage of image generation than to try to
figure out browser-specific fixes. And it could well be that for
some applications the smoothed version is preferable to the pixelated one.
You have the choice of adding the "pixels" keyword or not.
Ethan
|
|
From: Allin C. <cot...@wf...> - 2020-11-14 21:41:36
|
I'm attaching a patch against gnuplot git master which does what I mentioned in https://sourceforge.net/p/gnuplot/mailman/message/37141539/ That is, it allows wgnuplot.exe to accept via the Windows command-line unicode filenames that cannot be represented in the user's "system codepage", and to successfully to open such files. This iteration of my patch uses native win32 APIs to perform the necessary recoding of filenames, as opposed to the previous iteration which used GLib. I gave evidence in https://sourceforge.net/p/gnuplot/mailman/message/37143153/ that the patch is not disruptive of gnuplot's ability to open files named via the "load" command, in which case the encoding specified in the gnuplot script must be respected. The patch is activated only when compiling the program for Windows, and then only when the symbol WIDE_ARGS is defined. -- Allin Cottrell Department of Economics Wake Forest University |
|
From: Dima K. <gn...@di...> - 2020-11-14 20:22:04
|
Hi. I'm seeing that currently our svg output produces blurred images. I'm attaching a patch to (sorta) fix this. Demo script: set terminal svg standalone set output "/tmp/tst.svg" set view map splot [0:10][0:10] '++' using 1:2:($1+$2) with image The images before and after the patch are attached. Using firefox, you can see the before-patch image containing smoothed pixels, while the after-patch image contains pixels with crisp edges, which is what we want I think. Unfortunate caveat: apparently firefox and chrome can't agree on what to call this property. Firefox wants "crisp-edges" to do this, while Chrome wants "pixelated". So today, this patch will do the right thing on Firefox, but not on Chrome. Anybody know how to make this work on both (and the others, I guess)? I'm on the fence about whether patching gnuplot to work with just one of the two is better than keeping them both blurry in the same way. |
|
From: Ethan A M. <me...@uw...> - 2020-11-14 00:55:37
|
I can see the the gnuplot 5.4 Windows executables from the distribution site provide "help" via a set of html files generated by .../docs/windows/doc2html But I am also seeing reports or queries (E.g. Bug #2353) implying that the Windows build process needs a texinfo version produced by doc2texi.el Is that correct? I thought we had deprecated texinfo output and that the *.el file was not being maintained. The copy in the repository looks to be out of date with respect to supported terminals and recently added keys in the *.doc file. Does the Windows build use it anyhow, or does it assume a more up-to-date copy obtained elsewhere? If it isn't used, should we move it to .../docs/old/ and remove the texinfo target from the Makefile? Ethan |
|
From: Ethan A M. <me...@uw...> - 2020-11-10 21:35:31
|
On Monday, 9 November 2020 15:24:19 PST Tait wrote:
>
> Datablocks seem like a great way to avoid running slow commands
> multiple times, as in:
> plot $data using ..., '' using ..., '' using ...
>
> instead of
> plot '<cmd' using ..., '' using ..., '' using ...
>
> But $data << '<cmd' obviously doesn't work, and the workaround
> using load '<cmd' is hard to discover and requires modifying
> cmd. Would it be straighttforward to add a way to populate a
> datablock from a command the way '<' works for plot and load?
Two existing mechanisms come to mind.
Neither is a perfect match to what you ask but might serve
well enough either as-is or with a straightforward extension.
The first is the "volatile" keyword, which tells the program
not to reread the data file if the previously read values are
still available internally. As of now it is only relevant to
"replot", but it might conceivably be extended to cover the
use of '' in a plot command.
The second works already, subject to some issues like loss of
precision and appropriate choice of string formats and/or
field separators:
set table $DATA
plot "< some complicated command" using 1:2:3:4:5:(strcol(6)) with table
unset table
plot for [i=1:4] $DATA using 1:i with points, \
$DATA using 1:5:6 with labels
Does that work for your case?
If not, can you suggest ways in which the "with table" might be extended?
cheers,
Ethan
|
|
From: Tait <gnu...@t4...> - 2020-11-09 23:50:13
|
Datablocks seem like a great way to avoid running slow commands multiple times, as in: plot $data using ..., '' using ..., '' using ... instead of plot '<cmd' using ..., '' using ..., '' using ... But $data << '<cmd' obviously doesn't work, and the workaround using load '<cmd' is hard to discover and requires modifying cmd. Would it be straighttforward to add a way to populate a datablock from a command the way '<' works for plot and load? (Inspired by https://stackoverflow.com/questions/54600172/gnuplot-load-datafile-11-into-datablock and several similar questions. Using system() doesn't work the way you'd think either, as https://stackoverflow.com/a/60366832/11777995 mentions.) |
|
From: Daniel J S. <dan...@ie...> - 2020-11-08 20:55:25
|
On 11/8/20 4:27 AM, Dima Kogan wrote: > Hi. Is anybody here familiar with the qt terminal init sequence? I'm > observing that if you try to plot anything without DISPLAY defined, the > qt terminal throws an error and hangs. It does NOT give us the prompt > back. This confuses tools that use gnuplot to make plots. > > There was a commit that changed the way this works: > > https://sourceforge.net/p/gnuplot/gnuplot-main/ci/c415285c230 > > Reverting that makes gnuplot give up after a few seconds. The x11 and > wxt terminals figure it out immediately, but even a wait of several > seconds is better than a forever hang we currently get. Is there a > better way to handle errors in qt? > > Thanks! > https://doc.qt.io/qt-5/qlocalsocket.html#waitForConnected https://doc.qt.io/qt-5/qlocalsocket.html#error https://doc.qt.io/qt-5/qlocalsocket.html#LocalSocketError-enum That polling loop approach isn't really what should be done. By doing so it kind of obviates the error test. In the least, what this polling loop should be doing checking the error() after the failure to connect and going to sleep to determine if the error was a QLocalSocket::SocketTimeoutError. If it was some other type of error, don't continue waiting. QLocalSocket::LocalSocketError err = qt->socket.error(); if (err != QLocalSocket::SocketTimeoutError) break; and of course don't wait forever. As for the comment: // The QLocalSocket::waitForConnected does not respect the time out argument when // the gnuplot_qt application is not yet started or has not yet self-initialized. // To wait for it, we need to implement the timeout ourselves one just needs to figure out how to put this in the context of an event loop, i.e., start an event loop. That could be done with threading and the exec() routine. Dan |
|
From: Dima K. <gn...@di...> - 2020-11-08 09:28:03
|
Hi. Is anybody here familiar with the qt terminal init sequence? I'm observing that if you try to plot anything without DISPLAY defined, the qt terminal throws an error and hangs. It does NOT give us the prompt back. This confuses tools that use gnuplot to make plots. There was a commit that changed the way this works: https://sourceforge.net/p/gnuplot/gnuplot-main/ci/c415285c230 Reverting that makes gnuplot give up after a few seconds. The x11 and wxt terminals figure it out immediately, but even a wait of several seconds is better than a forever hang we currently get. Is there a better way to handle errors in qt? Thanks! |
|
From: Bastian M. <bma...@we...> - 2020-11-03 15:57:31
|
> Gesendet: Montag, 02. November 2020 um 21:37 Uhr > Von: "Allin Cottrell" <cot...@wf...> > An: "Ethan A Merritt" <me...@uw...> > Cc: "Bastian Märkisch" <bma...@we...>, "gnuplot-beta" <gnu...@li...> > Betreff: Re: AW: filenames on MS Windows > > On Mon, 2 Nov 2020, Ethan A Merritt wrote: > > > On Monday, 2 November 2020 01:48:42 PST Bastian Märkisch wrote: > >> Right now, gnuplot is able to "load" file names with Unicode encoded names, i.e. the sequence > >> set encoding utf8 > >> load 'абвгдежзийклмнопрстуфхцчшщъыьэюяѐёђѓєѕіїјљњћќѝўџ.plt' > >> will work just fine. > > > > But only if the encoding is set to utf8, right? > > Which is a bit counter-intuitive since on Windows the > > filename is not actually utf8. > > Counter-intuitive maybe, but it's very convenient. "set encoding > utf8" announces that filenames in the gnuplot script will be UTF-8 > encoded (and the script will be readable cross-platform), but thanks > to Bastian gnuplot knows they need to be recoded in the background > to UTF-16 for reading from disk on Windows. Windows mostly uses UTF16 to support Unicode. gnuplot uses char-based (byte) encodings only and - as many other programs from the *nix world - uses UTF-8 for Unicode. Internally, gnuplot will use whatever encoding it is told to use by the user via "set encoding". The translation from and to UTF16 for input, output, file names, pipes, clipboard interaction etc. is transparent to the user. This translation is not done for command line arguments yet as pointed out by Allin. The scheme itself is common practise to "port" applications and was introduced in 2016. (Note that as of now, file _content_ cannot be read or written in UTF16 encoding.) Bastian |
|
From: Allin C. <cot...@wf...> - 2020-11-03 15:42:24
|
On Mon, 2 Nov 2020, Allin Cottrell wrote: > On Mon, 2 Nov 2020, Bastian Märkisch wrote: [...] > >> That really poses the question if we should change the default >> internal encoding from "ANSI" (whatever that may be depends on >> the Windows locale) to UTF-8. I agree with that (and in fact my >> personal gnuplot.ini includes "set encoding utf8" since a long >> time). >> >> But how do we make this backward compatible since that will >> inevitably break load commands in old "ANSI" encoded user >> scripts? (as does your current patch btw) > > Are you sure about that breakage, Bastian? [...] I'm not sure I've understood the circumstances under which you reckon my patch would break load commands, but I just tried an experiment which I think is relevant. This is on Windows 10 with system codepage 1252, using my patched wgnuplot.exe. I placed a gnuplot script in a directory named with Cyrillic characters (so not representable in CP1252), reading as follows: # loader script set encoding cp1252 load '<CP1252 filename>' where <CP1252 filename> is the full path to a second script, in a directory with a non-ASCII name representable in CP1252. (It contains an o-circumflex.) The second script reads thus: # plot script set term pngcairo set output '<CP1252 output>' plot sin(x) where <CP1252 output> is again a full path including the non-ASCII but CP-friendly directory name. I then called wgnuplot.exe on the "loader" script, passing its filename as UTF-16, and it all went fine: the loader was read OK, from its Cyrillic location; the load command worked; and the PNG was written successfully. -- Allin Cottrell Department of Economics Wake Forest University |
|
From: Allin C. <cot...@wf...> - 2020-11-02 20:37:43
|
On Mon, 2 Nov 2020, Ethan A Merritt wrote: > On Monday, 2 November 2020 01:48:42 PST Bastian Märkisch wrote: >> Right now, gnuplot is able to "load" file names with Unicode encoded names, i.e. the sequence >> set encoding utf8 >> load 'абвгдежзийклмнопрстуфхцчшщъыьэюяѐёђѓєѕіїјљњћќѝўџ.plt' >> will work just fine. > > But only if the encoding is set to utf8, right? > Which is a bit counter-intuitive since on Windows the > filename is not actually utf8. Counter-intuitive maybe, but it's very convenient. "set encoding utf8" announces that filenames in the gnuplot script will be UTF-8 encoded (and the script will be readable cross-platform), but thanks to Bastian gnuplot knows they need to be recoded in the background to UTF-16 for reading from disk on Windows. -- Allin Cottrell Department of Economics Wake Forest University |
|
From: Ethan A M. <me...@uw...> - 2020-11-02 19:04:43
|
On Monday, 2 November 2020 01:48:42 PST Bastian Märkisch wrote: > Right now, gnuplot is able to "load" file names with Unicode encoded names, i.e. the sequence > set encoding utf8 > load 'абвгдежзийклмнопрстуфхцчшщъыьэюяѐёђѓєѕіїјљњћќѝўџ.plt' > will work just fine. But only if the encoding is set to utf8, right? Which is a bit counter-intuitive since on Windows the filename is not actually utf8. I had not realized before this that the encoding could affect how files are opened. The documentation under "encoding" and/or "utf8" could be expanded. Maybe also "set print|out|table" or add some general statement about filenames? Ethan > Only loading via the command line does not work and that should indeed be improved. (I don't agree to use glib for that purpose - but that is easy to change). > > Bastian > > > -----Ursprüngliche Nachricht----- > > Von: Allin Cottrell <cot...@wf...> > > Gesendet: Sonntag, 1. November 2020 21:24 > > An: Ethan A Merritt <me...@uw...> > > Cc: gnuplot-beta <gnu...@li...> > > Betreff: Re: filenames on MS Windows > > > > On Sun, 1 Nov 2020, Ethan A Merritt wrote: > > > > > On Saturday, 31 October 2020 17:36:03 PST Allin Cottrell wrote: > > >> On Sun, 25 Oct 2020, Allin Cottrell wrote: > > >> > > >>> I tried googling this but didn't find an answer -- sorry if I should > > >>> have just tried harder! My question is: can gnuplot on Windows > > >>> handle a unicode filename argument passed in UTF-16? As in > > >>> > > >>> path/to/wgnuplot.exe <UTF-16 input filename> > > >> > > >> OK, that question was under-researched, but now I've done my > > >> homework. Sorry, this is a bit long but I hope I can arouse some > > >> interest in the topic. > > > > > > I don't have any direct insight into this issue other than to note > > > that the filesytem itself may be an issue. > > > > In some contexts, no doubt. But if we set aside exotica such as surrogate pairs, > > NTFS filenames are UTF-16 to a very good approximation. As such they are > > easily converted to UTF-8 to permit handling with good old C char * APIs, and > > easily converted back to > > UTF-16 for _wfopen() if required. > > > > > The following entry from the R developer blog is of interest > > > > > > > > > https://developer.r-project.org/Blog/public/2020/05/02/utf-8-support-o > > > n-windows/ > > > > > > I gather from the discussion there that Windows-10 can be made to > > > support UTF-8 as a native encoding, calling it "extended ASCII". > > > > Interesting, yes, but at this point kinda science fiction. The practical issue at > > present is whether gnuplot wants to support out-of-codepage UTF-16 > > filenames on the Windows command line. It's not terribly difficult, as I tried to > > show. > > > > Sorry if I'm being repetitive, but right now if a create, say, a Russian-language > > filename on Windows and pass it as command-line argument to gnuplot, > > gnuplot will not be able to open the file because its name cannot be > > represented in my "system codepage". A program that reads the command line > > as UTF-16, however, will have no problem opening the file. > > > > Allin Cottrell > > -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg MS 357742, University of Washington, Seattle 98195-7742 |
|
From: Allin C. <cot...@wf...> - 2020-11-02 13:30:59
|
On Mon, 2 Nov 2020, Bastian Märkisch wrote: > Allin, > > Thank you for this nice contribution. On Windows, we already replace > fopen() (and many other functions), though. In particular, win_fopen() in > winmain.c already handles encodings, including UTF-8. There are also two > functions AnsiText() and UnicodeText() to convert to/from UTF16 according to > gnuplot's encoding. Yes, I'm aware of that and it's a very nice feature. > They use the simple-to-use Windows functions > WideCharToMultiByte() MultiByteToWideChar(), so no need for glib. Ah, OK. > That really poses the question if we should change the default internal > encoding from "ANSI" (whatever that may be depends on the Windows locale) to > UTF-8. I agree with that (and in fact my personal gnuplot.ini includes "set > encoding utf8" since a long time). > > But how do we make this backward compatible since that will inevitably break > load commands in old "ANSI" encoded user scripts? (as does your current > patch btw) Are you sure about that breakage, Bastian? I may be missing something, but here's my thinking: (1) I convert UTF-16 -> UTF-8 only for filenames coming off the Windows command-line in winmain.c, and (2) in my modified loadpath_fopen() I first try fopen() on the filename as-is, converting UTF-8 -> UTF-16 and calling _wfopen() only if fopen() fails and the filename validates as UTF-8. So I don't _think_ my patch is going to touch filenames read via the load command in a gnuplot script. Allin Cottrell |
28 messages has been excluded from this view by a project administrator.
