Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2004-08-18 08:12:13
|
On Wed, 18 Aug 2004, Daniel J Sebald wrote: > Some observations about demos: > > borders.dem isn't very useful. Too fast to see what is on the page. > Plus requires CNTRL-C to exit. > > The following demos are not in all.dem: > borders.dem You've just given the main reason why, I think. I guess the demo should be changed along the lines of animate.dem, i.e. limit the reread loops by a counter, and possibly introduce a pause to make it possible to see something. > candlesticks.dem > charset.dem > enhancedtext.dem > multiplt.dem (such a nice demo) > starmap.dem (another nice demo) > vector.dem (another nice demo) > > mousevariables.dem, fontfile.dem and fontfile_latex.dem aren't in > all.dem, but on purpose I think. I suspect the same applies to enhancedtext.dem --- they test features that are not known to either be available or fail seamlessly, on all terminals. Ethan, these were introduced by you: any comments? > Not finding the font files will cause gnuplot to error out. Maybe they > could be put at the very end of all.dem so that if they do crash, > nothing will be missed. We've discussed this, but never reached a conclusion. all.dem should probably be generated by 'configure' anyway. But putting unrealiable stuff doesn't really work, not as long as 'make check' expects to run all.dem on the default terminal and expects it to succeed. I.e. at the very least, we'ld have to have two copies of all.dem: one for feature demonstration, the other to be used by "make check". The latter would have to make sure it only uses features that don't cause gnuplot to error out. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-08-18 17:29:59
|
On Wednesday 18 August 2004 01:12 am, Hans-Bernhard Broeker wrote: > > The following demos are not in all.dem: > > borders.dem No opinion > > candlesticks.dem That's a clear oversight. It should go in. > > charset.dem > > enhancedtext.dem Charset.dem is not so much a demo as it is a means of testing particular settings for terminal, character encoding and choice of font. It makes no sense to automate this. Enhancedtext.dem only works on terminal types supporting the enhanced text mode, and only makes sense if the current terminal is in enhanced text mode. We don't have a general command inside gnuplot to turn on enhanced text mode for the current terminal. Maybe we should. Anyhow there is not currently a way to make this work from inside all.dem > > fontfile.dem and fontfile_latex.dem aren't in > > all.dem, but on purpose I think. fontfile and fontfile_latex are both terminal-specific. So these are in the same category as charset.dem. They do not belong in an automated terminal-independent test. > > multiplt.dem (such a nice demo) > > vector.dem (another nice demo) I don't know if there is a reason for these being omitted. I agree that they should probably be added to all.dem > > starmap.dem (another nice demo) This one is already there; it's called from inside datastrings.dem, > > mousevariables.dem, mousevariables.dem only makes sense interactively, so I don't think it can go into all.dem > > Not finding the font files will cause gnuplot to error out. Maybe they > > could be put at the very end of all.dem so that if they do crash, > > nothing will be missed. If the idea is to confirm that the font commands work, then we could include a test font in the demo directory and use that for the test. But I think the bigger issue is that all of the font exercising demos require customization of the terminal, which is inconsistent with the current mechanism of 'make check'. You can do 'setenv GNUTERM <foo>', but I don't know of any way to pass parameters like font selection or enhanced text mode. Now that the issue has been raised, I do think it might be nice to have a command something on order of set textmode enhanced This would instruct gnuplot to use enhanced text mode for any terminal that supports it. I run into this all the time, because I routinely preview scripts in x11 and then re-run them to produce png or eps files. As it is I have to either do this interactively or write explicit terminal selections into the script. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-08-18 18:22:39
|
On Wednesday 18 August 2004 10:29 am, Ethan Merritt wrote:
> You can do 'setenv GNUTERM <foo>',
> but I don't know of any way to pass parameters like font selection or
> enhanced text mode.
But there seems to be something broken with this mechanism for
some terminals. For example, simple.dem runs fine for both png and tgif
terminals if you do an explicit 'set term <foo>'; but it segfaults if you
set the terminal type via GNUTERM.
Works:
x11 post dumb emf mif svg
Broken:
png tgif
brogar [65] setenv GNUTERM png
brogar [66] gnuplot simple.dem
Segmentation fault
brogar [67] setenv GNUTERM tgif
brogar [68] gnuplot simple.dem
%TGIF 2.15-p7
state(0,30,0,0,0,0,16,1,9,1,1,0,0,0,0,1,0,'',0,0,0,0,1,10,0,0,1,1,0,16,0,0,1,1,1).
%
% @(#)$Header: /cvsroot/gnuplot/gnuplot/term/tgif.trm,v 1.25 2004/07/01 17:10:34 broeker Exp $
% %W%
%
page(1,"").
Floating exception
brogar [69] setenv GNUTERM dumb
brogar [70] gnuplot simple.dem
1.5 ++----------------+----------------+-----------------+------###########
++-----sin(x)-******+ + ############# +
|| atan(x) ######| ##### |
1 +cos(atan(x)) $$$$**| $$$ *# ** ++
|+---------------*--* $$ $$*#** * * |
| * * $ *# * * * |
* * * $ * $ * * * |
0.5 *+ * * $$$ * $$$* * * ++
|* * $$$*$$$ * $*$$$$$ * * |
$*$$$$$$$$$$$$*$$$$$ * * * $$$$$$$*$$$$$$$$$*$$
0 ++* * * * * * *++
| * * * * * * *|
| * * * * * * *|
-0.5 ++ * * * * * * +*
| * * * #* * * *
| * * ** #* * * |
| * ** *#* * ** |
-1 ++ * ##* * ++
| #### |
+ ############# + + +
-1.5 ###########-------+----------------+-----------------+---------------++
-10 -5 0 5 10
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Hans-Bernhard B. <br...@ph...> - 2004-08-19 08:32:06
|
Ethan Merritt wrote: > But there seems to be something broken with this mechanism for > some terminals. For example, simple.dem runs fine for both png and tgif > terminals if you do an explicit 'set term <foo>'; but it segfaults if you > set the terminal type via GNUTERM. That would be caused by the GNUTERM method never actually going through the process of calling term->init() and/or term->options() for that terminal, I think. Or maybe the affected terminals fail to initialize things correctly, and that was never noticed because they're never usually the startup default terminal. I'm slightly off base currently (moved for a job, and haven't fully settled in yet), so it may take a while before I can get a closer look. |
|
From: <mi...@ph...> - 2004-08-19 06:08:38
|
> Now that the issue has been raised, I do think it might be nice to have
> a command something on order of
> set textmode enhanced
There is a command (undocumented?)
set termoptions
which could do this.
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-08-19 15:53:25
|
On Wednesday 18 August 2004 11:08 pm, mi...@ph... wrote:
> > Now that the issue has been raised, I do think it might be nice to have
> > a command something on order of
> > set textmode enhanced
>
> There is a command (undocumented?)
> set termoptions
>
> which could do this.
The command whose body reads like this?
/* process 'set termoptions' command */
static void
set_termoptions()
{
int_error(c_token,"Command not yet supported");
}
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Daniel J S. <dan...@ie...> - 2004-08-19 17:52:57
|
Ethan Merritt wrote:
>On Wednesday 18 August 2004 11:08 pm, mi...@ph... wrote:
>
>
>>>Now that the issue has been raised, I do think it might be nice to have
>>>a command something on order of
>>> set textmode enhanced
>>>
>>>
>>There is a command (undocumented?)
>> set termoptions
>>
>>which could do this.
>>
>>
>
>The command whose body reads like this?
>
>/* process 'set termoptions' command */
>static void
>set_termoptions()
>{
> int_error(c_token,"Command not yet supported");
>}
>
:-)
|
|
From: Daniel J S. <dan...@ie...> - 2004-08-19 18:47:58
|
In attempting to make both plot3d.c use only df_readline(), even for
matrix data, I think I've uncovered a bug, or perhaps more than one.
One of the plots following a use of PM3D with four user specs was
failing. Here is some code to illustrate the problem.
Launch gnuplot and type
splot 'binary2' binary u 1:2:3:($2+($1+$2)/10) w pm3d
splot sin(x) w l
The first plot shows a blank 3d plot because the palette isn't set.
However, the second plot should still work fine because it doesn't
require the palette. But it fails because inside of plot3d.c is a test
#ifdef PM3D
if (df_no_use_specs==4 &&
!(this_plot->lp_properties.use_palette ||
pm3d.where[0] || this_plot->pm3d_where[0] ||
this_plot->plot_style & PM3DSURFACE))
int_error(c_token, "`using` with 4 parameters but surface
without `pm3d` or `palette`");
#endif
Notice that the first test is whether dn_no_use_specs==4, which it does.
The use specs were set by the 'binary2' command to be 4 inside
df_open(). However, for the second plot, df_no_use_specs is still equal
to 4 because df_open() was not called because a file is not being
plotted in the second example. [This is an argument for not using
global variables in such a way... but I'll not press that issue.]
OK. I think there are multiple bugs there because try the following:
set pm3d at s explicit solid
splot 'binary2' binary u 1:2:3:($2+($1+$2)/10) w pm3d
splot sin(x) w l
In this case the second plot works. The above test fails because
this_plot->lp_properties.use_palette is TRUE. But notice, the second
plot is a line plot. There shouldn't be a color box for such a plot.
These problems aren't connected to "binary". Any file read with 4 user
specs would cause the same problems.
If someone else wants to tackle that one, fine. I'm just going to fix
it in the "image/binary" stuff so that it works for a single
"df_readline()". I should be done with this patch today some time. It
looks like I'm headed in the direction of weeding out the
"df_3dmatrix()" routine and instead just using the df_readline() routine
[which internally uses df_readascii() or df_readbinary()]. That then
would be consistent usage throughout, and as far as I'd like to take the
binary stuff.
I'll let people know when the patch is ready.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2004-08-19 18:59:28
|
Attempting to get latest CVS: # cvs -d:pserver:ano...@cv...:/cvsroot/gnuplot login (Logging in to ano...@cv...) CVS password: cvs [login aborted]: unrecognized auth response from cvs.sourceforge.net: M PserverBackend::PserverBackend() Connect (Connection refused) |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-08-20 07:38:19
|
Daniel J Sebald wrote: > Attempting to get latest CVS: > > # cvs -d:pserver:ano...@cv...:/cvsroot/gnuplot login > (Logging in to ano...@cv...) > CVS password: > cvs [login aborted]: unrecognized auth response from > cvs.sourceforge.net: M PserverBackend::PserverBackend() Connect > (Connection refused) gnuplot is affected by a problem with one of SF's CVS servers which has been with us for almost a week now. None of the public/anonymous access methods to our CVS currently work. It's documented on their 'site status' page: https://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1 |
|
From: Daniel J S. <dan...@ie...> - 2004-08-19 19:19:50
|
Daniel J Sebald wrote:
> In attempting to make both plot3d.c use only df_readline(), even for
> matrix data, I think I've uncovered a bug, or perhaps more than one.
<snip>
> If someone else wants to tackle that one, fine. I'm just going to fix
> it in the "image/binary" stuff so that it works for a single
> "df_readline()".
On second thought, I'll leave it unfixed in the patch. There are too
many instances of df_no_use_specs being used in strange ways. Here's a
problem note:
/* FIXME EAM - as it stands we cannot have LABELPOINTS */
/* with pm3d colors, because they don't agree on columns */
and right near that is
if (df_no_use_specs==4) {
/* getting color from an explicitly given 4th column */
pm3d_color_from_column = TRUE;
x = v[0];
y = v[1];
z = v[2];
color = v[3];
break;
}
I think what has happened here is because matrix data is currently read
by df_3dmatrix(), which doesn't return the number of columns, there is a
tendency inside plot3d.c to use "df_no_use_spec" as the number of
columns of available data. That works under the condition the data came
from df_3dmatrix. But if it didn't, like in the example I've shown
previous, problems arise.
My feeling on this is that if df_readline() is only used to bring in
data, the "df_no_use_specs" can be removed from "datafile.h". That will
force things to be reorganized ever so slightly in plot3d.c so that
strange behavior doesn't creep in.
Dan
|
|
From: <mi...@ph...> - 2004-08-20 07:15:18
|
> splot 'binary2' binary u 1:2:3:($2+($1+$2)/10) w pm3d > splot sin(x) w l > > The first plot shows a blank 3d plot because the palette isn't set. > However, the second plot should still work fine because it doesn't > require the palette. > > being plotted in the second example. [This is an argument for not > using global variables in such a way... Does this mean that the bug could be fixed by reseting the global variable to the default value somewhere at the beginning of the "splot" command? --- PM |
|
From: Daniel J S. <dan...@ie...> - 2004-08-20 07:00:08
|
mi...@ph... wrote: >>splot 'binary2' binary u 1:2:3:($2+($1+$2)/10) w pm3d >>splot sin(x) w l >> >>The first plot shows a blank 3d plot because the palette isn't set. >>However, the second plot should still work fine because it doesn't >>require the palette. >> >>being plotted in the second example. [This is an argument for not >>using global variables in such a way... >> >> > >Does this mean that the bug could be fixed by reseting the global variable >to the default value somewhere at the beginning of the "splot" command? > Sure, probably. Maybe initialize the variable before the df_open() call. It would need some verification. But that is bad coding practice; I'd say do that only as a quick fix for 4.0 errata. Otherwise let it linger for a while as a reminder to reorganize that portion of plot3d.c. I personally think that if df_no_use_specs is kept hidden to within datafile.c, it will force programmers to come up with better program flow and organization. That is usually what I find. (Wait a couple weeks on that one.) I'm not sure that initializing of the variable will remove the color box from the line-only plot. That is another issue. Dan |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-08-20 07:46:54
|
Daniel J Sebald wrote: >>> splot 'binary2' binary u 1:2:3:($2+($1+$2)/10) w pm3d >>> splot sin(x) w l [...] > Sure, probably. Maybe initialize the variable before the df_open() > call. No. The problem with the second plot is much simpler: this is a *function* plot, and that means there's simply *no* justification whatsoever to even look at df_no_use_specs. Remember: 'df_' stands for "data file" here. |
|
From: <mi...@ph...> - 2004-08-20 05:55:38
|
>> There is a command (undocumented?)
>> set termoptions
>>
>> which could do this.
>
> The command whose body reads like this?
>
> /* process 'set termoptions' command */
> static void
> set_termoptions()
> {
> int_error(c_token,"Command not yet supported");
> }
Exactly. Setting "enhanced" could be the first candidate of its use.
Second could be "font 'Helvetica' 12".
---
PM
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2004-08-20 06:12:16
|
On Thursday 19 August 2004 10:55 pm, mi...@ph... wrote: > Exactly. Setting "enhanced" could be the first candidate of its use. > Second could be "font 'Helvetica' 12". I'm right with you. I added both these, and updated enhancedtext.dem to use the new command. It's in CVS already, although it is possible that more error-checking is needed. There really aren't that many options that currently apply to multiple terminal types. For instance, I think "set term <foo> linewidth <n>" would be nice in general, but so far it only works for PostScript. -- Ethan A Merritt Department of Biochemistry & Biomolecular Structure Center University of Washington, Seattle |
|
From: <mi...@ph...> - 2004-08-20 06:43:35
|
> On Thursday 19 August 2004 10:55 pm, mi...@ph... wrote: >> Exactly. Setting "enhanced" could be the first candidate of its use. >> Second could be "font 'Helvetica' 12". > > I'm right with you. I added both these, and updated enhancedtext.dem > to use the new command. It's in CVS already, although it is possible > that more error-checking is needed. It would be cool if it is supports changing fontsize during multiplot, e.g. set term post set multiplot set termoptions fsize 12 set size 1,1 plot x set size 0.5,0.5 set origin _somewhere_ set termoptions fsize 9 plot 1-x unset multiplot Does this work? > There really aren't that many options that currently apply to multiple > terminal types. For instance, I think "set term <foo> linewidth <n>" > would be nice in general, but so far it only works for PostScript. I've just found that fig terminal calls it "thickness". That could be unified to "lw|linewidth". Maybe "color" and "monochrome" could be other options. --- PM |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-08-20 07:51:38
|
mi...@ph... wrote: > It would be cool if it is supports changing fontsize during multiplot, e.g. Unfortunately, that's almost guaranteed not to be possible. Not by means of the 'set termoptions' command, anyway. That almost invariably has to go through term->options(), which I'm quite sure most terminals will fail on if you try it between term->graphics() and term->text(), i.e. while the graphics is open. For this to work, we'd have to add another terminal API call, term->default_font(), and map that to a new user-visible 'set font' command. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2004-08-20 18:06:56
|
On Friday 20 August 2004 12:50 am, Hans-Bernhard Broeker wrote: > That almost invariably > has to go through term->options(), which I'm quite sure most terminals > will fail on if you try it between term->graphics() and term->text(), > i.e. while the graphics is open. Where do you see a problem? term->option() does not actually *do* anything; it just loads some fields in the terminal data structures. The only driver I am a little uneasy about is svg, which clears a pointer to embedded fonts via SVG_local_reset. I need to test whether this matters or not. Now whether changing the default font actually works inside a multiplot is another question. For some terminals it does, but others that I tried do not recheck the default font setting soon enough for it to affect the subsequent plot. Instead it gets applied to the one after that. I'm not sure how much work it would be to fix this. -- Ethan A Merritt Department of Biochemistry & Biomolecular Structure Center University of Washington, Seattle |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-08-21 08:18:50
|
Ethan A Merritt wrote: > On Friday 20 August 2004 12:50 am, Hans-Bernhard Broeker wrote: > >>That almost invariably >>has to go through term->options(), which I'm quite sure most terminals >>will fail on if you try it between term->graphics() and term->text(), >>i.e. while the graphics is open. > > > Where do you see a problem? That calling term->option() in any other place in the terminal API usage than right at the start of a terminal's usage. It's almost sure that at least some of the drivers have hardwired in the assumption that the call order given in term/README is fixed, and thus hardwired assumptions about call order into the driver. term->option() was never designed to be used like this, so it *will* break, in rather interesting fashions. E.g.: those drivers that keep a polyline open between drawing operations will almost certainly not have thought of closing that properly at the start of their term->option() implementation, because it was never needed before. > term->option() does not actually *do* > anything; it just loads some fields in the terminal data structures. Which term->option() in particular are you speaking of? There are dozens of them, each a bit different. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-08-21 17:30:06
|
On Saturday 21 August 2004 01:23 am, you wrote:
> > term->option() does not actually *do*
> > anything; it just loads some fields in the terminal data structures.
>
> Which term->option() in particular are you speaking of? There are
> dozens of them, each a bit different.
I looked at all of them, and saw a potential problem only in svg.trm.
But I freely admit that it's possible I missed something; that's why I
asked if you had a particular terminal type or bit of code in mind as
a problem area.
All the critical (order-dependent) code seems to be in term->init(),
rather than term->options(). If this wasn't intentional, then it's a
lucky coincidence. Either way, calling term->options looks safe to me.
Furthermore, I have modified the code in set_termoptions() to call
only those terminal drivers that actually support the option in
question ('set term font ..' or 'set term {no}enhanced').
So the term->options() of most drivers will not be called even if
you do issue a 'set termoption' command.
Nevertheless, if there is indeed a fundamental problem with
this approach I can back off to some other mechanism that is
specific to enabling enhanced text mode.
--
Ethan A Merritt
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X