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}
(36) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

From: Philipp K. Janert <janert@ie...>  20150126 03:57:46

1) The inline nohidden3d seems to have no effect set isosamples 30; set hidden3d splot exp((x**2+y**2)), 0.5 nohidden3d The plane should be transparent; it isn't. 2) Line types in key off by one in contour plots with hidden3d set isosamples 30; set hidden3d set contour both splot [2:2][2:2] exp((x**2+y**2)) If you look closely, you realize that the colors of the linesamples in the key are off by one, because the color that's used for the underside of the surface is not taken into account. If you do set hidden3d offset 0 then everything is fine (but the underside of the surface is the same color as the top). 3) set ticscale vs set xyplane with save command The "set ticscale" option is deprecated in favor of "set xyplane". However, upon "save", gnuplot saves only a "set ticscale" entry to the command file, not a "set xyscale" entry. It works, but it is confusing. Best, Ph. 
From: Philipp K. Janert <janert@ie...>  20150122 16:54:50

Gnuplot 5 was released earlier this year. I am taking this opportunity to update my book "Gnuplot in Action". The second edition will be completely revised to reflect the new features of Gnuplot 5, but it will also include many other improvements and learnings that have come up since the first edition. A preview version of the first few chapters is now available from the publisher: http://www.manning.com/janert2 This is a good time to make suggestions for the new edition, and also to point out typos or errors in the first edition. Please email me directly, or post your comments to the book's forum: https://forums.manning.com/forums/gnuplotinactionsecondedition The publisher is giving out a limited number of preview copies  if you are interested, contact me or the publisher. The final book is expected later this year. Best, Ph. 
From: Philipp K. Janert <janert@ie...>  20150118 05:34:51

On Fri, 16 Jan 2015 22:00:27 0800 sfeam <sfeam@...> wrote: > On Wednesday, 07 January 2015 04:08:50 PM Philipp K. Janert wrote: > > > > I seem to have observed three minor bugs in gp5: > > > > > > 1) Filledcurve above/below > > [snip] > > 2) Enhanced text, key, and cairo > > [snip] > > 3) set xmtics, save, load > > [snip] > > These are now fixed. Awesome! ;) 
From: sfeam <sfeam@us...>  20150117 06:04:10

On Wednesday, 07 January 2015 04:08:50 PM Philipp K. Janert wrote: > > I seem to have observed three minor bugs in gp5: > > > 1) Filledcurve above/below > [snip] > 2) Enhanced text, key, and cairo > [snip] > 3) set xmtics, save, load > [snip] These are now fixed. Ethan 
From: Ethan A Merritt <sfeam@us...>  20150115 17:40:17

On Thursday, 15 January, 2015 22:13:14 Jun T. wrote: > > On 2015/01/09, at 10:36, sfeam <sfeam@...> wrote: > > > On Wednesday, 07 January 2015 04:08:50 PM Philipp K. Janert wrote: > >> > >> I seem to have observed three minor bugs in gp5: > >> > >> 2) Enhanced text, key, and cairo > > > > That odd, because wxt _is_ one of the cairo terminals. > > > (I know a patch is already in CVS) > > In cairotrm_put_text(), enhanced_recursion() is used only if the string > contains markup characters "{}^_@&~"; otherwise gp_cairo_draw_text() is used. > [snip] > In wxt_put_text() (wxt_gui.cpp), on the other hand, enhanced_recursion() > is used always; thus wxt does not have this problem. Thank you. Yes, that indeed explains the difference. Ethan 
From: Jun T. <takimotoj@kb...>  20150115 13:57:21

On 2015/01/09, at 10:36, sfeam <sfeam@...> wrote: > On Wednesday, 07 January 2015 04:08:50 PM Philipp K. Janert wrote: >> >> I seem to have observed three minor bugs in gp5: >> >> 2) Enhanced text, key, and cairo > > That odd, because wxt _is_ one of the cairo terminals. (I know a patch is already in CVS) In cairotrm_put_text(), enhanced_recursion() is used only if the string contains markup characters "{}^_@&~"; otherwise gp_cairo_draw_text() is used. When drawing "{/:Bold Hello}", enhanced_recursion() calls gp_cairo_enhanced_open(), which calls gp_cairo_set_font(), which sets plot>fontweight (gp_cairo.cpp:line 324): plot>fontweight = PANGO_WEIGHT_BOLD; But this fontweight is not reset to the original value after drawing the string. When drawing "World", gp_cairo_draw_text() uses the plot>fontweight (gp_cairo.cpp:line 867), which still has the value PANGO_WEIGHT_BOLD: pango_font_description_set_weight (desc, plot>fontweight); In wxt_put_text() (wxt_gui.cpp), on the other hand, enhanced_recursion() is used always; thus wxt does not have this problem. Jun 
From: Achim Gratz <Stromeko@NexGo.DE>  20150113 12:28:56

Achim Gratz <Stromeko <at> nexgo.de> writes: > Other than that things seem to work well although we'll have to change a > number of scripts that got caught in the changes w.r.t. to the linetype > command and some tightened syntax rules. On the upside it looks we can > drop a patch that gave us more linetypes and dash patterns and just > define them in the defaults instead. We've adapted the scripts now. It was mostly that in many places an "offset" is now required instead of simply the two coordinates. Some observations that need further investigation ("before" refers to gnuplot 4.6.6 and we're using the cairopdf terminal unless otherwise noted): The linetype 1 is no longer working as it did before at least when you try to change the linewidth and/or the dash type. The positioning of the plot area is different than before. There's more space below the title than there was before and less space below the plot area if you have the legend below the plot. The ticks and grid lines are much thicker than before. The Cairo PDF output is about 50% larger than before. Going through PS and ghostscript doesn't produce noticeably larger files. Regards, Achim. 
From: Jouke Witteveen <j.witteveen@gm...>  20150110 12:27:57

On Wed, Jan 7, 2015 at 2:02 AM, Ethan A Merritt <sfeam@...> wrote: > On Saturday, 03 January, 2015 12:39:14 Jouke Witteveen wrote: > >> The xvalue of individual boxplots is ignored when placing tics for > >> multiple boxplots. > >> > >> This patch fixes that issue. > > [snip] > > > > Bug tracker item: https://sourceforge.net/p/gnuplot/bugs/1532/ > > > > Example problem case adapted from the Bug Tracker > > (Example uses only a single point per boxplot) > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > $DATA << EOD > > 2 1 > > 3 2 > > 5 3 > > EOD > > > > set style boxplot separation 0 > > plot 'data' using 1:2:(0):(strcol(1)) with boxplot > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > > > There is a conflict between applying the first using spec (column 1) > > as a coordinate and applying the style parameter "separation". > > > > Currently the numeric column 1 values win for placing the > > boxplots themselves (a single point each in the example). > > So there are plots at x=2, x=3, and x=5. > > > > But the separation spec wins for placing the labels, > > which means the numeric values in column 1 are ignored and > > their string representations all placed as labels at x=2. > > > > Documentation: > > "The first and third columns (x coordinate and width) are normally > > provided as constants rather than as data columns." > > > > Question: > > Is it ever correct to provide a nonconstant x coordinate as > > in the example? How would the program deal with a mismatch > > between the xcoordinate (column 1) and the "discrete levels of > > of factor variable" in column 4? That can't happen in the > > example above because the same data column is used for both > > but that wouldn't normally be true. > > > > In other words  is this really a bug? > There is a possible mismatch between the factor level (column 4) and the width (column 3) too. The situation is far from pretty, but the proposed patch in the bugreport adds to the usability without breaking compatibility. What are the gnuplot conventions regarding interface breakage? I'd say a cleaner interface for boxplots would be a using spec where the first column is the xcoordinate and the second the ycoordinate. Grouping then takes place based on the xcoordinate and labeling can be implemented via an additional xticlabels column, as is used in other plot types already. The width still needs a solution. We could go with a third column in the using spec, as is currently done, or with a user specified function which takes an x coordinate as input and yields a width. The latter approach would lead to unambiguous widths. These are just some thoughts, nothing more. Regards,  Jouke 
From: sfeam <sfeam@us...>  20150109 01:40:12

On Wednesday, 07 January 2015 04:08:50 PM Philipp K. Janert wrote: > > I seem to have observed three minor bugs in gp5: > > 2) Enhanced text, key, and cairo > > set key title "{/:Bold Hello}" > plot sin(x) t "World" > > I'd expect the title of the key to be bold, > but the title entry for the curve to be > normal weight. That's also what it does in > wxt, but for any of the cairo terminals, all > key entries are bold. That odd, because wxt _is_ one of the cairo terminals. It seems the specific bug is that the final curly bracket in the key title doesn't take effect if it is the last character in the string. The problem goes away if you add a blank, or anything else, after the closing bracket. That must be a big clue, but at the moment I don't see where it points. Most of the code involved is shared by all terminals, so why does the problem only show up in a couple of them? Ethan 
From: Philipp K. Janert <janert@ie...>  20150108 22:03:31

On Thu, 8 Jan 2015 13:56:29 +0100 (CET) Petr Mikulik <mikulik@...> wrote: > > I seem to have observed three minor bugs in gp5: > > > > 1) Filledcurve above/below > > > > My understanding is that > > plot sin(x) w filledc above y1=0 > > should fill only the area between y=0 and > > the sine curve. What I observe is that it > > does not fill at all. With > > plot sin(x) w filledc below y1=0 > > gnuplot fills both above and below. > > > > The plot is sensitive to the value supplied, > > but above/below do not seem to be interpreted > > properly. > > I see, the above/below keywords work correctly in 4.6 but not in 5.0. > I think it was not spotted because fillcrvs.dem does not test them. Interestingly, it works if the limiting line is provided as "data". This command works as advertised: plot "+" u 1:(sin($1)):(0) w filledc above > >  > PM 
From: Petr Mikulik <mikulik@ph...>  20150108 12:57:22

> I seem to have observed three minor bugs in gp5: > > 1) Filledcurve above/below > > My understanding is that > plot sin(x) w filledc above y1=0 > should fill only the area between y=0 and > the sine curve. What I observe is that it > does not fill at all. With > plot sin(x) w filledc below y1=0 > gnuplot fills both above and below. > > The plot is sensitive to the value supplied, > but above/below do not seem to be interpreted > properly. I see, the above/below keywords work correctly in 4.6 but not in 5.0. I think it was not spotted because fillcrvs.dem does not test them.  PM 
From: Philipp K. Janert <janert@ie...>  20150108 00:09:02

I seem to have observed three minor bugs in gp5: 1) Filledcurve above/below My understanding is that plot sin(x) w filledc above y1=0 should fill only the area between y=0 and the sine curve. What I observe is that it does not fill at all. With plot sin(x) w filledc below y1=0 gnuplot fills both above and below. The plot is sensitive to the value supplied, but above/below do not seem to be interpreted properly. 2) Enhanced text, key, and cairo set key title "{/:Bold Hello}" plot sin(x) t "World" I'd expect the title of the key to be bold, but the title entry for the curve to be normal weight. That's also what it does in wxt, but for any of the cairo terminals, all key entries are bold. 3) set xmtics, save, load (I agree, a truly dusty corner!) set xmtics plot "data" u 1:2 w l save "foobar.gp" load "foobar.gp" This produces an error: set xmtics norangelimit unexpected or unrecognized token No biggy all three, but I'd thought I'd point them out. Maybe worth a remark in the release notes. 
From: Ethan A Merritt <sfeam@us...>  20150107 23:28:09

On Wednesday, 07 January, 2015 14:25:53 Philipp K. Janert wrote: > > Consider the following commands: > > set view map > set isosamples 10 > splot [0:1][0:1] "++" u 1:2:(1) w p > > I would have expected to get a graph > of 10x10 points on a grid. > > Instead, I get 10 horizontal lines of > densely packed points. I thought there had been a discussion of this on gnuplotbeta with reference to whether it should be changed for version 5. But now I can't seem to find it. Anyhow, it wasn't changed and '++' acts just like any other input source to 3D sampling. The x sampling is controlled by "set sample" (default = 100) The y sampling is controlled by "set isosample" (default = 10) It says exactly this in the documentation gnuplot> help specialfilenames [snip] Similarly the pseudofile '++' returns 2 columns of data forming a regular grid of [x,y] coordinates with the number of points along x controlled by `set samples` and the number of points along y controlled by `set isosamples`. Ethan > > When I do this: > > set view map > set isosamples 10 > unset samples > splot [0:1][0:1] "++" u 1:2:(1) w p > > I get 10 horizontal lines of less > densely packed points  but still > no 10x10 grid. > > Am I misunderstanding what "++" does, > or is this a bug? > > Best, > > Ph. 
From: Philipp K. Janert <janert@ie...>  20150107 22:26:00

Consider the following commands: set view map set isosamples 10 splot [0:1][0:1] "++" u 1:2:(1) w p I would have expected to get a graph of 10x10 points on a grid. Instead, I get 10 horizontal lines of densely packed points. When I do this: set view map set isosamples 10 unset samples splot [0:1][0:1] "++" u 1:2:(1) w p I get 10 horizontal lines of less densely packed points  but still no 10x10 grid. Am I misunderstanding what "++" does, or is this a bug? Best, Ph. 
From: Enrico Forestieri <forenr@ly...>  20150107 14:22:37

On Tue, Jan 06, 2015 at 12:11:56PM 0800, Ethan A Merritt wrote: > On Tuesday, 06 January, 2015 19:25:17 Achim Gratz wrote: > > Ethan A Merritt writes: > > > Gnuplot version 5.0 is now available. > > > > Thanks. I've compiled on Cygwin (with cygport/autotools and both on > > 64bit and 32bit) and see the following issues: > > Thanks for testing. > > > 1. The Qt terminal still doesn't work. No plot window ever shows up and > > each invocation of plot will produce another qt_terminal process. > > gnuplot itself seems to hang, but recovers after about 20s with a > > message about "font initialisation" taking too long. > > I'm afraid I have no insight into what might be causing that problem. > IIRC the initial testers on OSX reported a similar problem but in > that case it really was font initialisation and the problem went > away after the first run. On Cygwin, this is due to the fact that nonblocking named pipes do not work. See: http://thread.gmane.org/gmane.os.cygwin/113787/focus=114321 However, patching both Qt and gnuplot sources, I am able to get a working Qt terminal on Cygwin. I am attaching the patches I use. > > 3. The demo plugin doesn't link, I haven't yet investigated why > > (probably some of the hardcoded linker flags don't make much sense on > > Cygwin). I didn't find a way to tell configure that it should not > > compile the demo plugin other than removing the plugin support > > completely. > > ./configure disableplugins > is supposed to work. Does it not? I found that replacing "so" with "dll" in demo/plugin/Makefile.am does produce a plugin, even if it is named demo_plugin.dll.exe, i.e., with an extra .exe suffix... HTH  Enrico 
From: Ethan A Merritt <sfeam@us...>  20150107 01:46:16

On Saturday, 03 January, 2015 12:39:14 Jouke Witteveen wrote: > The xvalue of individual boxplots is ignored when placing tics for > multiple boxplots. > > This patch fixes that issue. [snip] Bug tracker item: https://sourceforge.net/p/gnuplot/bugs/1532/ Example problem case adapted from the Bug Tracker (Example uses only a single point per boxplot) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% $DATA << EOD 2 1 3 2 5 3 EOD set style boxplot separation 0 plot 'data' using 1:2:(0):(strcol(1)) with boxplot %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% There is a conflict between applying the first using spec (column 1) as a coordinate and applying the style parameter "separation". Currently the numeric column 1 values win for placing the boxplots themselves (a single point each in the example). So there are plots at x=2, x=3, and x=5. But the separation spec wins for placing the labels, which means the numeric values in column 1 are ignored and their string representations all placed as labels at x=2. Documentation: "The first and third columns (x coordinate and width) are normally provided as constants rather than as data columns." Question: Is it ever correct to provide a nonconstant x coordinate as in the example? How would the program deal with a mismatch between the xcoordinate (column 1) and the "discrete levels of of factor variable" in column 4? That can't happen in the example above because the same data column is used for both but that wouldn't normally be true. In other words  is this really a bug? 
From: Achim Gratz <S<tromeko@ne...>  20150106 20:40:04

Ethan A Merritt writes: > Can you point to some documentation or policy about when that > pkgconfig field is relevant or necessary? It's used in both Cygwin and openSUSE, but instead of looking at the .pc file please try pkgconfig variable=host_bins QT5Core as there may be some fallback rules to fill in empty slots (I'm not overly familiar with how the .pc files are put together). If not, then the configure rule in question should probably be rewritten using the PKG_CHECK_VAR autoconf macro to provide a fallback specific to gnuplot. In any case using exec_prefix is clearly wrong (it works on some installations purely by accident) and host_bins is what Qt5 introduced as a repleacement for the tool variables in Qt4. https://qt.gitorious.org/qt/qtbase/source/3fed060b94ff04131de603d4d668ae7853e50a53:dist/changes5.0.0 8<cut herestart>8 * moc_dir, rcc_dir and some other tool variables are not defined in Qt's .pc files any more; the generic host_bins is defined instead. 8<cut hereend>8 > ./configure disableplugins > is supposed to work. Does it not? Yes (I've been using that), but AFAICS that disables plugin support completely. I just wanted to find a way to not compile the demo plugin until I can figure out why it doesn't link and there doesn't seem to be any. > If you don't mind my asking, who is the "we" in this case? My colleagues and myself at work. Regards, Achim.  +<[Q+ Matrix12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds 
From: Ethan A Merritt <sfeam@us...>  20150106 20:12:12

On Tuesday, 06 January, 2015 19:25:17 Achim Gratz wrote: > Ethan A Merritt writes: > > Gnuplot version 5.0 is now available. > > Thanks. I've compiled on Cygwin (with cygport/autotools and both on > 64bit and 32bit) and see the following issues: Thanks for testing. > 1. The Qt terminal still doesn't work. No plot window ever shows up and > each invocation of plot will produce another qt_terminal process. > gnuplot itself seems to hang, but recovers after about 20s with a > message about "font initialisation" taking too long. I'm afraid I have no insight into what might be causing that problem. IIRC the initial testers on OSX reported a similar problem but in that case it really was font initialisation and the problem went away after the first run. > 2. Configuring with Qt5 need changes to configure.in to work. The > configure script tries to determine the path to uic et.al. via a > pkgconfig query for exec_bin. The correct variable to query is > actually host_bins. Hmm. On my linux systems the host_bins field in Qt5Core.pc is empty, so I am not sure this convention is universal. On the other hand, the linux Qt5 package also sets the correct path via /etc/profile.d/qt5.sh so that in practice the gnuplot autoconfigure script would work anyhow. Can you point to some documentation or policy about when that pkgconfig field is relevant or necessary? > 8<cut herestart>8 > QT5LOC=`$PKG_CONFIG variable=exec_prefix Qt5Core` > UIC=${QT5LOC}/bin/uic > MOC=${QT5LOC}/bin/moc > RCC=${QT5LOC}/bin/rcc > LRELEASE=${QT5LOC}/bin/lrelease >  > QT5LOC=`$PKG_CONFIG variable=host_bins Qt5Core` > UIC=${QT5LOC}/uic > MOC=${QT5LOC}/moc > RCC=${QT5LOC}/rcc > LRELEASE=${QT5LOC}/lrelease > > 8<cut hereend>8 > > 3. The demo plugin doesn't link, I haven't yet investigated why > (probably some of the hardcoded linker flags don't make much sense on > Cygwin). I didn't find a way to tell configure that it should not > compile the demo plugin other than removing the plugin support > completely. ./configure disableplugins is supposed to work. Does it not? > Other than that things seem to work well although we'll have to change a > number of scripts that got caught in the changes w.r.t. to the linetype > command and some tightened syntax rules. On the upside it looks we can > drop a patch that gave us more linetypes and dash patterns and just > define them in the defaults instead. If you don't mind my asking, who is the "we" in this case? > > Regards, > Achim. Ethan 
From: Achim Gratz <S<tromeko@ne...>  20150106 18:27:49

Ethan A Merritt writes: > Gnuplot version 5.0 is now available. Thanks. I've compiled on Cygwin (with cygport/autotools and both on 64bit and 32bit) and see the following issues: 1. The Qt terminal still doesn't work. No plot window ever shows up and each invocation of plot will produce another qt_terminal process. gnuplot itself seems to hang, but recovers after about 20s with a message about "font initialisation" taking too long. 2. Configuring with Qt5 need changes to configure.in to work. The configure script tries to determine the path to uic et.al. via a pkgconfig query for exec_bin. The correct variable to query is actually host_bins. 8<cut herestart>8 QT5LOC=`$PKG_CONFIG variable=exec_prefix Qt5Core` UIC=${QT5LOC}/bin/uic MOC=${QT5LOC}/bin/moc RCC=${QT5LOC}/bin/rcc LRELEASE=${QT5LOC}/bin/lrelease  QT5LOC=`$PKG_CONFIG variable=host_bins Qt5Core` UIC=${QT5LOC}/uic MOC=${QT5LOC}/moc RCC=${QT5LOC}/rcc LRELEASE=${QT5LOC}/lrelease 8<cut hereend>8 3. The demo plugin doesn't link, I haven't yet investigated why (probably some of the hardcoded linker flags don't make much sense on Cygwin). I didn't find a way to tell configure that it should not compile the demo plugin other than removing the plugin support completely. Other than that things seem to work well although we'll have to change a number of scripts that got caught in the changes w.r.t. to the linetype command and some tightened syntax rules. On the upside it looks we can drop a patch that gave us more linetypes and dash patterns and just define them in the defaults instead. Regards, Achim.  +<[Q+ Matrix12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables 
From: Petr Mikulik <mikulik@ph...>  20150106 14:27:25

> Gnuplot version 5.0 is now available. Really great achievement! I noticed a small bug  the "test" command on x11 shows dashed rectangle around the central numbers instead of a solid one. I miss a note in "help newfeatures" why the linetype colour sequence has changed and how to revert it back. (The most strange is red at position 7.) I remember the discussion about colour blind people but at the same time there are millions of old graphs rendered in the "traditional colour sequence" and most users are used to the first 34 colours. Actually, "help linetype" says: ... For example, linetypes one and two default to red and green. ... which is no longer valid.  Petr 
From: sfeam <sfeam@us...>  20150105 00:54:34

On Saturday, 03 January 2015 06:25:29 PM sfeam wrote: > On Saturday, 03 January 2015 12:35:27 PM Jouke Witteveen wrote: > > When a row in the datafile contains no factor, its yvalue is stored in > > place of the factor identifier, leading to ambiguities. > > If the datafile contains > > 0 0 0 foo > > 0 1 > > The second row will be marked as part of the 'foo' boxplot. > > > > This patch fixes that issue. > >  > > diff Naur gnuplot5.0.0.orig/src/gadgets.h gnuplot5.0.0/src/gadgets.h > >  gnuplot5.0.0.orig/src/gadgets.h 20150102 22:06:25.488402227 +0100 > > +++ gnuplot5.0.0/src/gadgets.h 20150102 22:06:25.458403577 +0100 > > @@ 279,6 +279,8 @@ > > BOXPLOT_FACTOR_LABELS_X2 > > } t_boxplot_factor_labels; > > > > +#define DEFAULT_BOXPLOT_FACTOR 1 > > + > > typedef struct boxplot_style { > > int limit_type; /* 0 = multiple of interquartile 1 = fraction of points */ > > double limit_value; > > diff Naur gnuplot5.0.0.orig/src/plot2d.c gnuplot5.0.0/src/plot2d.c > >  gnuplot5.0.0.orig/src/plot2d.c 20150102 22:06:25.488402227 +0100 > > +++ gnuplot5.0.0/src/plot2d.c 20150102 22:08:57.411693594 +0100 > > @@ 910,19 +910,22 @@ > > store2d_point(current_plot, i++, v[0], v[1], v[0], v[0], > > v[1]  v[2], v[1] + v[2], 1.0); > > } else { > >  double w; > > + double ylow, w; > > if (current_plot>plot_style == CANDLESTICKS > >  current_plot>plot_style == FINANCEBARS) { > > int_warn(storetoken, "This plot style does not work with 1 or 2 cols. Setting to points"); > > current_plot>plot_style = POINTSTYLE; > >  } > > + } else if (current_plot>plot_style == BOXPLOT) > > + ylow = DEFAULT_BOXPLOT_FACTOR; > > + else > > + ylow = v[1]; > > if (current_plot>plot_smooth == SMOOTH_ACSPLINES) > > w = 1.0; /* Unit weights */ > > else > > w = 1.0; /* Autowidth boxes in some styles */ > > /* Set x/y high/low to exactly [x,y] */ > > store2d_point(current_plot, i++, v[0], v[1], > >  v[0], v[0], v[1], v[1], w); > > + v[0], v[0], ylow, v[1], w); > > } > > break; > > > > @@ 1004,7 +1007,7 @@ > > > > case BOXPLOT: /* x, y, width */ > > store2d_point(current_plot, i++, v[0], v[1], v[0]v[2]/2., v[0]+v[2]/2., > >  v[1], v[1], v[2]); > > + DEFAULT_BOXPLOT_FACTOR, v[1], v[2]); > > break; > > > > #ifdef EAM_OBJECTS > > @@ 1513,7 +1516,7 @@ > > /* This can happen if the user specifies a nonexistent column: > > * fall back to singleboxplot mode */ > > if (!string) > >  return 0; > > + return DEFAULT_BOXPLOT_FACTOR; > > > > /* Remove the trailing garbage, quotes etc. from the string */ > > trimmed_string = df_parse_string_field(string); > > Bug #2 > I agree there may be a bug here, but I can't reproduce exactly > what you describe. Could you please provide a full example with > both the input and the command used to plot? > > If I understand the problem case correctly, a missing column in > the input data is a failure in its own right and the point should > be discarded before ever reaching your new code. > The actual result seems to depend on additional factors like > "set datafile separator". But in cases where the point is not > discarded I don't see it incorrectly added to some other category >  instead the plot contains an extra boxplot column with a blank > label into which the problem points are placed. > That's arguably a correct result, although it's not what I expected. I've applied this patch with 2 modifications. 1) It handles the case of the factor column being present but empty (e.g. in a *.csv file) as well as the case of the column being missing altogether. 2) The factor is now stored in the z/w/misc slot of the point structure rather than misusing ylow. For the moment it is *also* stored in ylow in the case of true 4column input since that is expected by the sorting and drawing routines. But this can go away later, as shown by your patch #4. Disregarding patch #3 for now since it addressing a slightly different issue, it would be nice if you would revise patch #4 so that it (1) does not refer to or use the changes in patch #3 (2) gets rid of all the y value mangling, which is no longer necessary. Instead of temporarily replacing y with VERYLARGE / UNDEFINED so that the point count can be based on y, simply step past any points for with the factor (now stored in z) doesn't match. 
From: sfeam <sfeam@us...>  20150104 02:28:16

On Saturday, 03 January 2015 12:35:27 PM Jouke Witteveen wrote: > When a row in the datafile contains no factor, its yvalue is stored in > place of the factor identifier, leading to ambiguities. > If the datafile contains > 0 0 0 foo > 0 1 > The second row will be marked as part of the 'foo' boxplot. > > This patch fixes that issue. >  > diff Naur gnuplot5.0.0.orig/src/gadgets.h gnuplot5.0.0/src/gadgets.h >  gnuplot5.0.0.orig/src/gadgets.h 20150102 22:06:25.488402227 +0100 > +++ gnuplot5.0.0/src/gadgets.h 20150102 22:06:25.458403577 +0100 > @@ 279,6 +279,8 @@ > BOXPLOT_FACTOR_LABELS_X2 > } t_boxplot_factor_labels; > > +#define DEFAULT_BOXPLOT_FACTOR 1 > + > typedef struct boxplot_style { > int limit_type; /* 0 = multiple of interquartile 1 = fraction of points */ > double limit_value; > diff Naur gnuplot5.0.0.orig/src/plot2d.c gnuplot5.0.0/src/plot2d.c >  gnuplot5.0.0.orig/src/plot2d.c 20150102 22:06:25.488402227 +0100 > +++ gnuplot5.0.0/src/plot2d.c 20150102 22:08:57.411693594 +0100 > @@ 910,19 +910,22 @@ > store2d_point(current_plot, i++, v[0], v[1], v[0], v[0], > v[1]  v[2], v[1] + v[2], 1.0); > } else { >  double w; > + double ylow, w; > if (current_plot>plot_style == CANDLESTICKS >  current_plot>plot_style == FINANCEBARS) { > int_warn(storetoken, "This plot style does not work with 1 or 2 cols. Setting to points"); > current_plot>plot_style = POINTSTYLE; >  } > + } else if (current_plot>plot_style == BOXPLOT) > + ylow = DEFAULT_BOXPLOT_FACTOR; > + else > + ylow = v[1]; > if (current_plot>plot_smooth == SMOOTH_ACSPLINES) > w = 1.0; /* Unit weights */ > else > w = 1.0; /* Autowidth boxes in some styles */ > /* Set x/y high/low to exactly [x,y] */ > store2d_point(current_plot, i++, v[0], v[1], >  v[0], v[0], v[1], v[1], w); > + v[0], v[0], ylow, v[1], w); > } > break; > > @@ 1004,7 +1007,7 @@ > > case BOXPLOT: /* x, y, width */ > store2d_point(current_plot, i++, v[0], v[1], v[0]v[2]/2., v[0]+v[2]/2., >  v[1], v[1], v[2]); > + DEFAULT_BOXPLOT_FACTOR, v[1], v[2]); > break; > > #ifdef EAM_OBJECTS > @@ 1513,7 +1516,7 @@ > /* This can happen if the user specifies a nonexistent column: > * fall back to singleboxplot mode */ > if (!string) >  return 0; > + return DEFAULT_BOXPLOT_FACTOR; > > /* Remove the trailing garbage, quotes etc. from the string */ > trimmed_string = df_parse_string_field(string); Bug #2 I agree there may be a bug here, but I can't reproduce exactly what you describe. Could you please provide a full example with both the input and the command used to plot? If I understand the problem case correctly, a missing column in the input data is a failure in its own right and the point should be discarded before ever reaching your new code. The actual result seems to depend on additional factors like "set datafile separator". But in cases where the point is not discarded I don't see it incorrectly added to some other category  instead the plot contains an extra boxplot column with a blank label into which the problem points are placed. That's arguably a correct result, although it's not what I expected. 
From: sfeam <sfeam@us...>  20150104 02:24:11

On Saturday, 03 January 2015 12:32:20 PM Jouke Witteveen wrote: > When a factor name is a prefix of another, gnuplot treats them as the same. > Hence a datafile with > 0 0 0 foobar > 0 1 0 foo > will lead to only one boxplot. > > This patch fixes that issue. >  > diff Naur gnuplot5.0.0.orig/src/plot2d.c gnuplot5.0.0/src/plot2d.c >  gnuplot5.0.0.orig/src/plot2d.c 20150102 21:57:32.551558965 +0100 > +++ gnuplot5.0.0/src/plot2d.c 20150102 21:58:13.929255645 +0100 > @@ 1520,7 +1520,7 @@ > len = strlen(trimmed_string); > for (label = plot>labels; label; label = label>next) { > /* check if string is the same as the ith factor */ >  if (label>text && !strncmp(trimmed_string, label>text, len)) > + if (label>text && !strncmp(trimmed_string, label>text, len + 1)) > break; > } I've created a Bug tracker entry for these issues https://sourceforge.net/p/gnuplot/bugs/1532/ Patch 1: applied to CVS for 5.0 and 5.1 
From: Jouke Witteveen <j.witteveen@gm...>  20150103 11:42:13

With a default factor identifier, the expensive filter_boxplot_factor routine can be made obsolete. This leads to more efficient plotting of boxplots.  diff Naur gnuplot5.0.0.orig/src/graphics.c gnuplot5.0.0/src/graphics.c  gnuplot5.0.0.orig/src/graphics.c 20141122 05:12:53.000000000 +0100 +++ gnuplot5.0.0/src/graphics.c 20150103 01:24:35.787529832 +0100 @@ 107,7 +107,6 @@ static void plot_c_bars __PROTO((struct curve_points * plot)); static int compare_ypoints __PROTO((SORTFUNC_ARGS arg1, SORTFUNC_ARGS arg2)); static void plot_boxplot __PROTO((struct curve_points * plot)); static int filter_boxplot_factor __PROTO((struct curve_points *plot, int level)); static void place_labels __PROTO((struct text_label * listhead, int layer, TBOOLEAN clip)); static void place_arrows __PROTO((int layer)); @@ 2682,110 +2681,57 @@ } } int filter_boxplot(struct curve_points *plot) {  int i;  int N = plot>p_count;   /* Force any undefined points to the end of the list */  for (i=0; i<N; i++)  if (plot>points[i].type == UNDEFINED)  plot>points[i].y = VERYLARGE;   /* Sort the points to find median and quartiles */  qsort(plot>points, N, sizeof(struct coordinate), compare_ypoints);   /* Remove any undefined points */  while (plot>points[N1].type == UNDEFINED)  N;  plot>p_count = N;   return N; }  static int filter_boxplot_factor(struct curve_points *plot, int level) {  int i, real_level;  int N = plot>p_count;   /* Do we have to show the boxplots in alphabetical order of factors? */  if (boxplot_opts.sort_factors && plot>boxplot_factor_order)  real_level = plot>boxplot_factor_order[level];  else  real_level = level;   /* If the factor doesn't match,  * change the point to undefined and force it to the end of the list */  for (i=0; i<N; i++) {  plot>points[i].y = plot>points[i].yhigh;  plot>points[i].type = INRANGE;  if (plot>points[i].ylow != real_level) {  plot>points[i].type = UNDEFINED;  plot>points[i].y = VERYLARGE;  FPRINTF((stderr, "filter_boxplot_factor: rejecting point: level %d, factor %g, i %d\n", level, plot>points[i].ylow, i));  }  }   /* Sort the points to find median and quartiles */  qsort(plot>points, N, sizeof(struct coordinate), compare_ypoints);   /* Remove any undefined points */  while (plot>points[N1].type == UNDEFINED)  N;  plot>p_count = N;   return N; }  static void plot_boxplot(struct curve_points *plot) { int N;  int saved_p_count;  struct coordinate *save_points = plot>points; + int remaining = plot>p_count; + int saved_p_count = plot>p_count; + struct coordinate GPHUGE *current_points = plot>points; + struct coordinate GPHUGE *saved_points = plot>points; struct coordinate candle; + double delta_x = 0; double median, quartile1, quartile3; double whisker_top, whisker_bot;  int level;  int levels = plot>boxplot_factors;  if (levels == 0)  levels = 1;  saved_p_count = plot>p_count;   for (level=0; level<levels; level++) {  /* Sort the points and get rid of any that are undefined */  /* EAM Feb 2011: Move this to boxplot_range_fiddling() */  /* N = filter_boxplot(plot); */  /* but we need filtering to make factored boxplots work: */  if (levels > 1) {  plot>p_count = saved_p_count;  N = filter_boxplot_factor(plot, level);  }  else  N = plot>p_count; + + /* set N to the distance towards the first boxplot to plot */ + N = 0; + if (plot>boxplot_factors > 0) + while (N<remaining && current_points[N].ylow < 0) N++; + + do { + /* move to the next boxplot and count the number of its points */ + remaining = N; + if (remaining == 0) + break; + current_points += N; + for (N = 0; + N < remaining && current_points[N].ylow == current_points>ylow; + N++); + + /* Sort the points to find median and quartiles */ + qsort(current_points, N, sizeof(struct coordinate), compare_ypoints); /* Not enough points left to make a boxplot */ if (N < 4) {  candle.x = plot>points>x + boxplot_opts.separation * level; + candle.x = current_points>x + delta_x; candle.yhigh = VERYLARGE; candle.ylow = VERYLARGE; goto outliers; } if ((N & 0x1) == 0)  median = 0.5 * (plot>points[N/2  1].y + plot>points[N/2].y); + median = 0.5 * (current_points[N/2  1].y + current_points[N/2].y); else  median = plot>points[(N1)/2].y; + median = current_points[(N1)/2].y; if ((N & 0x3) == 0)  quartile1 = 0.5 * (plot>points[N/4  1].y + plot>points[N/4].y); + quartile1 = 0.5 * (current_points[N/4  1].y + current_points[N/4].y); else  quartile1 = plot>points[(N+3)/4  1].y; + quartile1 = current_points[(N+3)/4  1].y; if ((N & 0x3) == 0)  quartile3 = 0.5 * (plot>points[N  N/4].y + plot>points[N  N/4  1].y); + quartile3 = 0.5 * (current_points[N  N/4].y + current_points[N  N/4  1].y); else  quartile3 = plot>points[N  (N+3)/4].y; + quartile3 = current_points[N  (N+3)/4].y; FPRINTF((stderr,"Boxplot: quartile boundaries for %d points: %g %g %g\n", N, quartile1, median, quartile3)); @@ 2797,14 +2743,14 @@ int i; whisker_bot = quartile1  whisker_len; for (i=0; i<N; i++)  if (plot>points[i].y >= whisker_bot) {  whisker_bot = plot>points[i].y; + if (current_points[i].y >= whisker_bot) { + whisker_bot = current_points[i].y; break; } whisker_top = quartile3 + whisker_len; for (i=N1; i>= 0; i)  if (plot>points[i].y <= whisker_top) {  whisker_top = plot>points[i].y; + if (current_points[i].y <= whisker_top) { + whisker_top = current_points[i].y; break; } @@ 2815,16 +2761,16 @@ int top = N1; int bot = 0; while ((double)(topbot+1)/(double)(N) >= boxplot_opts.limit_value) {  whisker_top = plot>points[top].y;  whisker_bot = plot>points[bot].y; + whisker_top = current_points[top].y; + whisker_bot = current_points[bot].y; if (whisker_top  median >= median  whisker_bot) { top;  while ((top > 0) && (plot>points[top].y == plot>points[top1].y)) + while ((top > 0) && (current_points[top].y == current_points[top1].y)) top; } if (whisker_top  median <= median  whisker_bot) { bot++;  while ((bot < top) && (plot>points[bot].y == plot>points[bot+1].y)) + while ((bot < top) && (current_points[bot].y == current_points[bot+1].y)) bot++; } } @@ 2833,14 +2779,14 @@ /* Dummy up a singlepoint candlesticks plot using these limiting values */ candle.type = INRANGE; if (plot>plot_type == FUNC)  candle.x = (plot>points[0].x + plot>points[N1].x) / 2.; + candle.x = (current_points[0].x + current_points[N1].x) / 2.; else  candle.x = plot>points>x + boxplot_opts.separation * level; + candle.x = current_points>x + delta_x; candle.y = quartile1; candle.z = quartile3; candle.ylow = whisker_bot; candle.yhigh = whisker_top;  candle.xlow = plot>points>xlow + boxplot_opts.separation * level; + candle.xlow = current_points>xlow + delta_x; candle.xhigh = median; /* Crazy order of candlestick parameters! */ plot>points = &candle; plot>p_count = 1; @@ 2850,26 +2796,23 @@ else plot_c_bars( plot );  plot>points = save_points;  plot>p_count = N;  /* Now draw individual points for the outliers */ outliers: if (boxplot_opts.outliers) { int i,j,x,y; p_width = plot>lp_properties.p_size * term>h_tic;  for (i = 0; i < plot>p_count; i++) { + for (i = 0; i < N; i++) {  if (plot>points[i].y >= candle.ylow  && plot>points[i].y <= candle.yhigh) + if (current_points[i].y >= candle.ylow + && current_points[i].y <= candle.yhigh) continue;  if (plot>points[i].type != INRANGE) + if (current_points[i].type != INRANGE) continue; x = map_x(candle.x);  y = map_y(plot>points[i].y); + y = map_y(current_points[i].y); /* do clipping if necessary */ if (clip_points && (x < plot_bounds.xleft + p_width @@ 2880,13 +2823,16 @@ } /* Separate any duplicate outliers */  for (j=1; (i >= j) && (plot>points[i].y == plot>points[ij].y); j++) + for (j=1; (i >= j) && (current_points[i].y == current_points[ij].y); j++) x += p_width * ((j & 1) == 0 ? j : j);; (term>point) (x, y, plot>lp_properties.p_type); } }  } + delta_x += boxplot_opts.separation; + } while (current_points>ylow + 1 < plot>boxplot_factors); + plot>points = saved_points; + plot>p_count = saved_p_count; } diff Naur gnuplot5.0.0.orig/src/graphics.h gnuplot5.0.0/src/graphics.h  gnuplot5.0.0.orig/src/graphics.h 20131226 19:52:27.000000000 +0100 +++ gnuplot5.0.0/src/graphics.h 20150102 22:54:00.944166721 +0100 @@ 71,7 +71,6 @@ enum PLOT_SMOOTH plot_smooth; /* which "smooth" method to be used? */ double smooth_parameter; /* e.g. optional bandwidth for smooth kdensity */ int boxplot_factors; /* Only used if plot_style == BOXPLOT */  int *boxplot_factor_order; /* Only used if plot_style == BOXPLOT */ int p_max; /* how many points are allocated */ int p_count; /* count of points in points */ int x_axis; /* FIRST_X_AXIS or SECOND_X_AXIS */ @@ 112,6 +111,4 @@ #define place_objects(listhead,layer,dimensions) /* void() */ #endif int filter_boxplot __PROTO((struct curve_points *));  #endif /* GNUPLOT_GRAPHICS_H */ diff Naur gnuplot5.0.0.orig/src/plot2d.c gnuplot5.0.0/src/plot2d.c  gnuplot5.0.0.orig/src/plot2d.c 20150103 01:34:10.374844052 +0100 +++ gnuplot5.0.0/src/plot2d.c 20150103 02:41:33.675309714 +0100 @@ 77,6 +77,8 @@ static void add_tics_boxplot_factors __PROTO((struct curve_points *plot)); static void sort_boxplot_factors __PROTO((struct curve_points *plot)); static int compare_boxplot_factors __PROTO((SORTFUNC_ARGS arg1, SORTFUNC_ARGS arg2)); +static int filter_boxplot_factor __PROTO((struct curve_points *plot, int level)); +static int compare_ylow __PROTO((SORTFUNC_ARGS arg1, SORTFUNC_ARGS arg2)); /* internal and external variables */ @@ 187,8 +189,6 @@ if (cp>labels) free_labels(cp>labels); cp>labels = NULL;  free(cp>boxplot_factor_order);  cp>boxplot_factor_order = NULL; if (cp>z_n) { int i; for (i = 0; i < cp>n_par_axes; i++) @@ 1587,9 +1587,7 @@ * in the order they were found in the file, and these numbers were written into the * plot>points structure. To change the order in which they will be plotted, * we have to sort the factor strings (which are stored in plot>labels), then  * fill plot>boxplot_factor_order with the order we've found. This is essentially  * a permutation of the sequence 0:N1 where N is the number of levels the factor  * variable has (plot>boxplot_factors). */ + * update all the factor levels in plot>points. */ static void sort_boxplot_factors(struct curve_points *plot) { @@ 1602,7 +1600,7 @@ if (plot>boxplot_factors < 2  !plot>labels  !plot>labels>next) return;  temp_labels = gp_alloc(plot>boxplot_factors * sizeof(temp_labels), "boxplot labels array"); + temp_labels = gp_alloc(plot>boxplot_factors * sizeof(text_label *), "boxplot labels array"); permutation = gp_alloc(plot>boxplot_factors * sizeof(int), "boxplot permutations array"); /* fill pointer array by walking the linked list */ @@ 1615,23 +1613,70 @@ } /* sort pointer array */ qsort(temp_labels, plot>boxplot_factors, sizeof(text_label *), compare_boxplot_factors);   /* read out the tags from the text_labels from the  now sorted  pointer array,  * and write them into the permutation array in order */ + + /* update the tags from the text_labels of the  now sorted  pointer array, + * and construct a translation pemutation */ for (i=0; i<plot>boxplot_factors; i++) {  permutation[i] = temp_labels[i]>tag; + permutation[temp_labels[i]>tag] = i; + temp_labels[i]>tag = i; + } + + /* update all factors */ + /* this simplifies the plotting routine, as all boxplots end up in order */ + for (i=0; i<plot>p_count; i++) { + struct coordinate *point = &plot>points[i]; + if (point>type == UNDEFINED  point>ylow < 0  point>ylow >= plot>boxplot_factors) + continue; + point>ylow = permutation[(int)point>ylow]; } /* and also relink the list in sorted order for the tics */ this_label = plot>labels>next = temp_labels[0];  for (i=0; i<plot>boxplot_factors1; i++) {  this_label>next = temp_labels[i+1]; + for (i=1; i<plot>boxplot_factors; i++) { + this_label>next = temp_labels[i]; this_label = this_label>next; } this_label>next = NULL; free(temp_labels);  plot>boxplot_factor_order = permutation; + free(permutation); +} + +static int +compare_ylow(SORTFUNC_ARGS arg1, SORTFUNC_ARGS arg2) +{ + struct coordinate const *p1 = arg1; + struct coordinate const *p2 = arg2; + + if (p1>ylow > p2>ylow) + return (1); + if (p1>ylow < p2>ylow) + return (1); + return (0); +} + +static int +filter_boxplot(struct curve_points *plot) +{ + int i; + int N = plot>p_count; + + /* Force any undefined points to the end of the list */ + for (i=0; i<N; i++) + if (plot>points[i].type == UNDEFINED) + plot>points[i].ylow = VERYLARGE; + + /* Group by the levels of the boxplot factors */ + if (plot>boxplot_factors > 1 && boxplot_opts.sort_factors) + sort_boxplot_factors(plot); + qsort(plot>points, N, sizeof(struct coordinate), compare_ylow); + + /* Remove any undefined points */ + while (plot>points[N1].type == UNDEFINED) + N; + plot>p_count = N; + + return N; } /* Autoscaling of box plots cuts off half of the box on each end. */ @@ 2821,12 +2866,10 @@ } /* if needed, sort boxplot factors and assign tic labels to them */  if (this_plot>plot_style == BOXPLOT && this_plot>boxplot_factors > 0) {  if (boxplot_opts.sort_factors)  sort_boxplot_factors(this_plot);  if (boxplot_opts.labels != BOXPLOT_FACTOR_LABELS_OFF)  add_tics_boxplot_factors(this_plot);  } + if (this_plot>plot_style == BOXPLOT + && this_plot>boxplot_factors > 0 + && boxplot_opts.labels != BOXPLOT_FACTOR_LABELS_OFF) + add_tics_boxplot_factors(this_plot); /* sort */ switch (this_plot>plot_smooth) { diff Naur gnuplot5.0.0.orig/src/set.c gnuplot5.0.0/src/set.c  gnuplot5.0.0.orig/src/set.c 20141123 19:29:17.000000000 +0100 +++ gnuplot5.0.0/src/set.c 20150102 19:42:41.906236781 +0100 @@ 1032,7 +1032,7 @@ c_token++; boxplot_opts.separation = real_expression(); if (boxplot_opts.separation < 0)  int_error(c_token1,"separation must be > 0"); + int_error(c_token1,"separation must be nonnegative"); } else if (almost_equals(c_token,"lab$els")) { c_token++; 
From: Jouke Witteveen <j.witteveen@gm...>  20150103 11:39:23

The xvalue of individual boxplots is ignored when placing tics for multiple boxplots. This patch fixes that issue. It requires the previous patch, which introduces default factor identifiers. With this patch in place, there is a case for changing the default separation value for the boxplot style to 0.  diff Naur gnuplot5.0.0.orig/src/plot2d.c gnuplot5.0.0/src/plot2d.c  gnuplot5.0.0.orig/src/plot2d.c 20150103 01:34:55.149743745 +0100 +++ gnuplot5.0.0/src/plot2d.c 20150103 01:34:10.374844052 +0100 @@ 73,7 +73,7 @@ static void boxplot_range_fiddling __PROTO((struct curve_points *plot)); static void histogram_range_fiddling __PROTO((struct curve_points *plot)); static void impulse_range_fiddling __PROTO((struct curve_points *plot)); static int check_or_add_boxplot_factor __PROTO((struct curve_points *plot, char* string, double x)); +static int check_or_add_boxplot_factor __PROTO((struct curve_points *plot, char* string, struct coordinate *cp)); static void add_tics_boxplot_factors __PROTO((struct curve_points *plot)); static void sort_boxplot_factors __PROTO((struct curve_points *plot)); static int compare_boxplot_factors __PROTO((SORTFUNC_ARGS arg1, SORTFUNC_ARGS arg2)); @@ 1085,9 +1085,13 @@ case BOXPLOT: /* x, y, width, factor */ /* Load the coords just as we would have for 3argument boxplot, * index of factor in ylow , yhigh is the same as y */  store2d_point(current_plot, i++, v[0], v[1], v[0]v[2]/2., v[0]+v[2]/2.,  check_or_add_boxplot_factor(current_plot, df_tokens[3], v[0]),  v[1], v[2]); + store2d_point(current_plot, i, v[0], v[1], v[0]v[2]/2., v[0]+v[2]/2., + DEFAULT_BOXPLOT_FACTOR, v[1], v[2]); + if (current_plot>points[i].type != UNDEFINED) + current_plot>points[i].ylow = check_or_add_boxplot_factor( + current_plot, df_tokens[3], + &(current_plot>points[i])); + i++; break; @@ 1506,7 +1510,7 @@ /* Check if <string> is already among the known factors, if not, add it to the list */ static int check_or_add_boxplot_factor(struct curve_points *plot, char* string, double x) +check_or_add_boxplot_factor(struct curve_points *plot, char* string, struct coordinate *cp) { int len; char * trimmed_string; @@ 1527,10 +1531,14 @@ break; }  /* not found, so we add it now */  if (!label)  label = store_label(plot>labels, &(plot>points[0]),  plot>boxplot_factors++, trimmed_string, 0.0); + if (label) { + /* for consistency, we store the position corresponding to the smallest y */ + if (cp>y < label>place.y) { + label>place.x = cp>x; + label>place.y = cp>y; + } + } else /* not found, so we add it now */ + label = store_label(plot>labels, cp, plot>boxplot_factors++, trimmed_string, 0.0); free(trimmed_string); return label>tag; @@ 1556,7 +1564,7 @@ add_tic_user( boxplot_labels_axis, this_label>text,  plot>points>x + i * boxplot_opts.separation, + this_label>place.x + i * boxplot_opts.separation, 1); i++; this_label = this_label>next; 