gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Quick refresh [was: q for quit in plot windows]

[Ethan M. <merritt@u.washington.edu>]

On Monday 04 June 2007 13:53, Daniel J Sebald wrote:
>  > - There should be some way to turn off the quick refresh if you really do
>  > want to re-read the data during a zoom operation. Maybe a new command
>  > set mouse zoom {replot|refresh}
> 
> If this is a necessary option, I might prefer this to be an option for the 
> replot command, i.e., "set datafile reread/noreread" or something like that.

It's not tied to a datafile, so that doesn't work.
 
> To have a "refresh" command and then have "refresh" an option somewhere is 
> getting along the lines of the "hidden3d" and "pm3d hidden3d" option confusion.

Huh?  What option?

There would be two commands.  I am not wedded to calling the new one "refresh",
but let's go with that for the moment.
replot	= re-read the data and plot all over again
refresh	= don't reread the data, but update the plot with new limits+labels+etc

If you're typing from the command line, no problem.
You just pick whichever of the two commands you want.
The issue is what happens under the hood when a mouse operation,
in particular zooming, needs to redraw the plot.  
Does it use "refresh" or does it use "replot"?
You've got to be able to tell it that somehow, and that's kind of
hard to do without mention the name of the command you want it to use.

-- 
Ethan A Merritt

Re: Patches item #1729825 ready to go.

[Ethan M. <merritt@u.washington.edu>]

On Monday 04 June 2007 13:31, Daniel J Sebald wrote:
> 1) Help now resolves keywords individually as opposed to a whole line of text 
> (i.e., things like "help se ter post" are understood).  The algorithm goes with 
> most matching characters as the "winning" help line, and if there is a tie then 
> it is the most number of whole matches.

Sounds good. Let's see if it survives stress-testing.
 
> 2) History is much more robust to recursion detection.  I went with an algorithm 
> that will complain if every a command off the history stack is run more than 
> once in a series of history recalls.  For example
> 
> plot x; hist !plot
> plot x; hist !plot

I cannot imagine anyone having a legitimate reason for issuing such a command.
Can't we just forbid commands of the form "hist !command" unless they are the
first and only thing on the line?

In fact, I can't think of a reason to ever allow a "hist" command except
at the beginning of a line.  Why would you want to do this? 

> 3) History now has recall by number, e.g., "hist !123".  A bit tricky to 
> implement given the shuffling behavior we have, but I think I've got it.  (No 
> sense in numbering the stack if we can't recall by number.)

Does that number stay constant?  I.e., if I go to the trouble of figuring
out that some complicated upstream command was "!123",  will that still be
true 10 minutes later after various intervening commands?   If not, then
this option is a non-starter.  

> Note, as far as shuffling it would be easy to make an option for that.  I point 
> this out because if someone is using recall by number, shuffling of the stack 
> can cause a problem.

Er, why are we shuffling the stack?

-- 
Ethan A Merritt

Re: Quick refresh [was: q for quit in plot windows]

[Daniel J S. <dan...@ie...>]

 > - There should be some way to turn off the quick refresh if you really do
 > want to re-read the data during a zoom operation. Maybe a new command
 > set zoom {replot|refresh}
 > or
 > set mouse zoom {replot|refresh}

If this is a necessary option, I might prefer this to be an option for the 
replot command, i.e., "set datafile reread/noreread" or something like that.

To have a "refresh" command and then have "refresh" an option somewhere is 
getting along the lines of the "hidden3d" and "pm3d hidden3d" option confusion.

Dan

Re: Segfaults on exit - something has messed up recent CVS

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> For the last week or so I've been getting a double-free warning
> message from glibc every time I exit gnuplot with the current driver
> set to wxt.  This was non-fatal, although it did mean
> that the history file was not updated.
> 
> As of today this has gotten much worse. It no longer happens every
> time I exit, but if it does happen then it causes a core dump:
> 
> (<unknown>:1881): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `-g-type-private--GTypeFlags'
> 
> (<unknown>:1881): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
> 
> (<unknown>:1881): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `-g-type-private--GTypeFlags'
> 
> (<unknown>:1881): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
> Segmentation fault
> 
> 
> The only recent patch I see is:
> 2007-06-03  Petr Mikulik  <mi...@ph...>
> * src/history.c (write_history_n): Cannot use int_error() when exiting gnuplot.
> 
> I don't understand how this would make things worse than before,
> but I don't see any other candidate patches.
> 
> Is anyone else seeing this?   Any ideas why?

I'm not running under wxt, but if the original problem was of the segfault 
variety (e.g., bad pointer), almost anything can move the code around a bit so 
that the problem manifests itself as something worse/better.

Dan

Patches item #1729825 ready to go.

[Daniel J S. <dan...@ie...>]

I consolidated all help/history patches into one patch #1729825 and it is ready 
to go.  Give it a try.  I guess the following would be the improvements:

1) Help now resolves keywords individually as opposed to a whole line of text 
(i.e., things like "help se ter post" are understood).  The algorithm goes with 
most matching characters as the "winning" help line, and if there is a tie then 
it is the most number of whole matches.

2) History is much more robust to recursion detection.  I went with an algorithm 
that will complain if every a command off the history stack is run more than 
once in a series of history recalls.  For example

plot x; hist !plot
plot x; hist !plot

is recursive on the second implementation because it will come back to the same 
line.  This uses dynarray to keep track of the recalled history, which actually 
turns out to be less code.

3) History now has recall by number, e.g., "hist !123".  A bit tricky to 
implement given the shuffling behavior we have, but I think I've got it.  (No 
sense in numbering the stack if we can't recall by number.)

Note, as far as shuffling it would be easy to make an option for that.  I point 
this out because if someone is using recall by number, shuffling of the stack 
can cause a problem.

Dan

Touchup of history.c

[Daniel J S. <dan...@ie...>]

The other day Petr made a change to rid the int_error() function.  Rather than 
putting "Warning:" in the printf, could the int_warn() function be used as in 
the attached patch instead?

Dan

Re: Segfaults on exit - something has messed up recent CVS

[Petr M. <mi...@ph...>]

> For the last week or so I've been getting a double-free warning
> message from glibc every time I exit gnuplot with the current driver
> set to wxt.  This was non-fatal, although it did mean
> that the history file was not updated.

I don't see it.

> The only recent patch I see is:
> 2007-06-03  Petr Mikulik  <mi...@ph...>
> * src/history.c (write_history_n): Cannot use int_error() when exiting gnuplot.

I have found this bug when compiling 4.2 under DOS by DJGPP. It was possible 
to reproduce it on Linux:  compile gnuplot with built-in readline, and start 
gnuplot with HOME undefined (or pointing to a non-sense).

I'll submit the patches for DJGPP shortly. I wanted to have gnuplot 4.2 on 
an old experimental machine.

---
PM

Re: gnuplot-beta Digest, Vol 12, Issue 10

[Ethan M. <merritt@u.washington.edu>]

On Sunday 03 June 2007 19:48, m sutton wrote:
> I would like a couple of my patches to be considered for inclusion into CVS:
> 
>  1659135  	  dashed grid for GD term to accept linewidths

OK, that's better than the earlier version.
I'll try to exercise it, and add it to CVS if I don't
find any problems.

-- 
Ethan A Merritt

Segfaults on exit - something has messed up recent CVS

[Ethan M. <merritt@u.washington.edu>]

For the last week or so I've been getting a double-free warning
message from glibc every time I exit gnuplot with the current driver
set to wxt.  This was non-fatal, although it did mean
that the history file was not updated.

As of today this has gotten much worse. It no longer happens every
time I exit, but if it does happen then it causes a core dump:

(<unknown>:1881): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `-g-type-private--GTypeFlags'

(<unknown>:1881): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

(<unknown>:1881): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `-g-type-private--GTypeFlags'

(<unknown>:1881): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
Segmentation fault


The only recent patch I see is:
2007-06-03  Petr Mikulik  <mi...@ph...>
* src/history.c (write_history_n): Cannot use int_error() when exiting gnuplot.

I don't understand how this would make things worse than before,
but I don't see any other candidate patches.

Is anyone else seeing this?   Any ideas why?

-- 
Ethan A Merritt

Re: [PATCH] plot.c, setjmp question

[<tim...@en...>]

>> On Saturday 02 June 2007 14:00, Timothée Lecomte wrote:
>>>
>>> So, I conclude that any code executed conditionally to !setjmp(...), if
>>> not changing the stack, could be put before the call to setjmp and give
>>> exactly the same behaviour. In other words:
>>>
>>> if(!setjmp(...))
>>> {
>>>     /* setjmp returns direclty */
>>>     code_that_does_not_change_the_stack();
>>> }
>>> else
>>> {
>>>     /* coming back from longjmp */
>>> }
>>>
>>> is strictly equivalent to:
>>>
>>> code_that_does_not_change_the_stack();
>>> if(setjmp(...))
>>> {
>>>     /* coming back from longjmp */
>>> }
>>>
>>> Am I right ?
>>
>> I'm not certain, but I don't think this is correct.
>>
>> For one thing, SETJMP actually translates to sigsetjmp(env,
>> save_signals).
>> So both the stack and the signal state must remain unchanged.
>>
>
> More precisely, it's the signal mask, i.e.signals that we may have chosen
> to block using sigprocmask. There's no such call in interrupt_setup().
>
>
>> For another, consider what happens if there is an error return from
>> the initialization code.
>>
>> Here's the actual code:
>>
>>     if (!SETJMP(command_line_env, 1)) {
>>         /* first time */
>>         interrupt_setup();
>>         get_user_env();
>>         init_loadpath();
>> 	...
>>     } else {
>>         /* come back here from int_error() */
>>
>> But interrupt_setup() presumably changes the signal-handling state,
>> so it cannot be moved ahead of SETJMP without changing the environment
>> restored after longjmp().
>
> Well, no, it doesn't change the signal _mask_, so it can be moved ahead of
> setjmp.
>
>
>>
>> And if something inside init_loadpath() attempted an error return
>> via longjmp() then you would get an infinite loop if you move the
>> call ahead of SETJMP.  I don't think init_loadpath() in fact can
>> trigger this, but it's something you have to worry about in general.
>>
>
> You're right, I missed that part: I have to verify that the calls I move
> are not calling int_error() or bail_to_command_line, which would trigger a
> longjmp.

I've gone through the calls that I was going to move.
The following calls for sure do not call int_error() or
bail_to_command_line():

interrupt_setup()
get_user_env()
init_loadpath()
init_locale()
reset_command()
init_color()
init_fit()
history code including read_history()


I've not gone through the whole reset_command() calls, because it's quite
big, but I am going to assume that it doesn't call int_error(), otherwise
it sounds like a serious coding error ! 'reset' should obviously always
succeed.


There is one offender in these initialization calls that may use
int_error(): it's load_rcfile(). It parses '.gnuplot' (or 'gnuplot.ini',
depending on the platform). Obviously this should only be done once, and I
guess it's a good thing that it doesn't make gnuplot exit if there's an
error in this file.

In order to achieve the cleanup I've looking for, I can move load_rcfile
below in the code, and add a static TBOOLEAN in it so that it only gets
executed once.

Modified patch attached.

Best regards,

Timothée

Re: gnuplot-beta Digest, Vol 12, Issue 10

[m s. <mw...@us...>]

I would like a couple of my patches to be considered for inclusion into CVS:

 1659135  	  dashed grid for GD term to accept linewidths
 1553072  	  set term x11 geometry option

The first one fixes a bug for GD and wide dashed grid lines.  The seconds j=
ust adds some flexibility to the X11 term.

Thanks

Mike Sutton

> Message: 7
> Date: Wed, 30 May 2007 13:38:10 -0500
> From: Daniel J Sebald <dan...@ie...>
> Subject: accumulated patches
> Cc: gnu...@li...
> Message-ID: <465...@ie...>
> Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed
>=20
> There are a number of patches on SourceForge ready for=20
> consideration in CVS.  If
> someone wants to review them they can.  Or, if you want me to move=20
> them in, give
> me a password (or temporary password if S.F. has such a thing).
>=20
>=20
> [ gnuplot-Bugs-1534367 ] too much expansion in FindHelp
> [ gnuplot-Bugs-1525665 ] help has problems with
>=20
> Fixes issues such as a help line longer than the space reserved in=20
> memory for a
> command line.
>=20
>=20
> [ gnuplot-Patches-1566782 ] use tgamma for GAMMA() and lgamma for LNGAMMA=
()
>=20
> I think it is correct, others may not.  It appears to work on Linux=20
> and Mac and
> I'm fairly confident it won't cause any problems.
>=20
>=20
> [ gnuplot-Bugs-1488168 ] z_floor and z_ceiling based on xyplane.absolute
>=20
> This is an outright bug fix.  Should have gone in 4.2.
>=20
>=20
> [ gnuplot-Patches-1523316 ] improved CLIPBOARD and PRIMARY per X conventi=
ons
>=20
> Full implementation of mouse/clipboard behavior consistent with the vast
> majority of X applications.
>=20
>=20
> [ gnuplot-Bugs-1004754 ] Tics and grid slightly outside border
>=20
> Do something like
>=20
> if (i_tic =3D=3D i_end) {
>     if (last_tic < end_range)
>       draw_tic;
> }
>=20
> instead of
>=20
> while (first_tic + delta_tic + delta_tic + ... + delta_tic < end_range)
>     draw_tic;
>=20
> The second approach is susceptible to rounding, the first isn't.
>=20
>=20
> [ gnuplot-Patches-1027032 ] Connect gnuplot_x11 to exterior application
> window
>=20
> Works as far as I know.  X11 has an issue whereby two resources both
> controlling the mouse in a window will cause an error.  Will X ever=20
> change this?
>    I doubt it.  The most I could offer is to somehow check if the outside
> application has relenquished the mouse and if not issue an error.
>=20
>=20
> [ gnuplot-Patches-1531560 ] recursive history warning instead of error
>=20
> Issue a warning rather than an error so that the rest of the line may be
> executed, e.g.,
>=20
> gnuplot> history !his; show style;
> ^
> warning: ignoring recursive history command
> Data are plotted with points...
>=20
>=20
> [ gnuplot-Patches-1723798 ] Multiplot palette X11, bug [ 1447277 ]
>=20
> Allows multiple palettes on a multiplot X11 window, a long desired fix.
>=20
>=20
> [ gnuplot-Patches-1725993 ] Alternate Hidden3d Edge Segmentation
>=20
> Fixes a bug reported on SourceForge.  Very big patch.  No noticable chang=
e in
> speed.  If someone wants to fix the bug another way, feel free.
>=20
>=20
> [ 1727198 ] Hidden lines: Degenerate polygons creating problems
>=20
> Fixes a bug reported on SourceForge.  User reported hidden lines=20
> appearing on a
> globe.  The lines were part of the north pole in which four sided=20
> polygons were
> degenerate as triangles.  Hence internally triangles with two sides the s=
ame
> were the problem spot.  The patch simply tosses out such polygons.
>=20
>=20
> [ gnuplot-Bugs-1728063 ] hidden lines, scale assertion failure
>=20
> Replace an assertion statement in the QUADTREE version with a simple range
> limit.  Hidden line removal slows down if user pushes surface out=20
> past the plot
> view, but that is a minor consequence.  (Better than your program=20
> quitting on you.)
>=20
>=20
> [ gnuplot-Patches-1508316 ] Allow multiple strings to signify "missing"
>=20
> This one isn't ready to go, but we should address this at some point.  An
> interesting side note is that Octave considered storing its stem=20
> plot data as a
> series of data for which a "missing" value is used to create a discontinu=
ous
> space.  That is, there is three ways of doing this:
>=20
> 1) Use gnuplot's "stem".
> 2) Draw a bunch of individual lines with "plot" for each line.
> 3) Draw a series of data with every third entry "missing" thus=20
> leaving the third
> line blank.
>=20
> Turns out that 3 sort of fits the way Octave stores data.
>=20
>=20
> Dan
>=20
>=20
>=20
> ------------------------------
>=20
> Message: 8
> Date: Wed, 30 May 2007 12:41:14 -0700
> From: Ethan Merritt <merritt@u.washington.edu>
> Subject: Re: accumulated patches
> To: gnu...@li...
> Cc: Daniel J Sebald <dan...@ie...>
> Message-ID: <200705301241.14984.merritt@u.washington.edu>
> Content-Type: text/plain;  charset=3D"iso-8859-1"
>=20
> On Wednesday 30 May 2007 11:38, Daniel J Sebald wrote:
> >
> > [ gnuplot-Bugs-1534367 ] too much expansion in FindHelp
> > [ gnuplot-Bugs-1525665 ] help has problems with
> > [ gnuplot-Patches-1531560 ] recursive history warning instead of error
>=20
> I agree these are relatively high priority.
> They almost went into 4.2, but were held out because bugs
> turned up at the last minute.  IOW they are not quite working yet.
> I would very much like to see them cleaned up, thoroughly tested,
> and added to CVS.
>=20
> Please combine them into a single patch set against current source
> and let's give them a workout to shake out any remaining bugs.
>=20
> > [ gnuplot-Patches-1566782 ] use tgamma for GAMMA() and lgamma for LNGAM=
MA()
> >
> > I think it is correct, others may not.  It appears to work on=20
> > Linux and Mac and I'm fairly confident it won't cause any=20
> > problems.
>=20
> It was never broken on linux, and I believe it is no longer needed
> on OSX either.  So the risk of breaking some minor platform seems larger
> than the benefit to any known system.  Please correct me if I'm wrong.
>=20
> > [ gnuplot-Bugs-1488168 ] z_floor and z_ceiling based on=20
> > xyplane.absolute This is an outright bug fix.  Should have gone=20
> > in 4.2.
>=20
> Do you want to take this one Petr?
> You had said earlier you would move it into CVS.
>=20
> > [ gnuplot-Patches-1523316 ] improved CLIPBOARD and PRIMARY per X conven=
tions
> >
> > Full implementation of mouse/clipboard behavior consistent with the vast
> > majority of X applications.
>=20
> ???  Not as seen here.  I have had no problems with the current=20
> implementation.
> That doesn't make your fix wrong, but I don't understand what=20
> problem is fixing.
>=20
> > [ gnuplot-Bugs-1004754 ] Tics and grid slightly outside border
>=20
> I think this is a non-issue, and we should drop this one entirely.
>=20
> > [ gnuplot-Patches-1027032 ] Connect gnuplot_x11 to exterior application
> > window
> >
> > Works as far as I know.
>=20
> Doesn't work here.  I'd like it if it *did* work, but it doesn't.
> My recollection is that it tripped over some contradictory requirements
> for window management by Tk/Tcl, GTK, etc.
>=20
> > [ gnuplot-Patches-1723798 ] Multiplot palette X11, bug [ 1447277 ]
> > Allows multiple palettes on a multiplot X11 window, a long desired fix.
>=20
> Sorry, I haven't had time to look at this one yet.
>=20
> > [ gnuplot-Patches-1725993 ] Alternate Hidden3d Edge Segmentation
> > [ 1727198 ] Hidden lines: Degenerate polygons creating problems
> > [ gnuplot-Bugs-1728063 ] hidden lines, scale assertion failure
>=20
> I'll leave these to Hans-Bernhard, since he's far more familiar
> with the code.  I will comment that gnuplat's hidden-line removal
> plots have very different properties than solid rendering.  When you
> render solids, omitting a facet is just about the worst thing you can do.
> The missing facet is far more jarring than a mis-aligned edge.
> But in the case of gnuplot, it is exactly the mis-aligned edges that
> are noticeable.  We don't care if a facet is dropped.  So although
> I have not delved into the code, I suspect that the most useful fix
> is simply to increase the slop margin, and deliberately omit any
> edges that are in the slop area.
>=20
> > [ gnuplot-Patches-1508316 ] Allow multiple strings to signify "missing"
>=20
> Veto.
> There are more reasonable options.
> 1) Clean up your data files
> 2) Run it through general string handling:
>      filter(x) =3D   (x eq "?") ? NaN : (x eq "junk") ? NaN : x
>      plot "foo" using 1:(filter($2))
> 3) Clean up your data files
>=20
> Consider the case where you have multiple data files,
> each with its own idea of what is or is not a missing data flag.
> You want the fix to be per-file, not global.
>=20
> --
> Ethan A Merritt
>=20
>=20
>=20
> ------------------------------
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
>=20
> ------------------------------
>=20
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>=20
>=20
> End of gnuplot-beta Digest, Vol 12, Issue 10
> ********************************************

>


=3D
Restaurant POS Equipment
Touch screen restaurant POS systems starting at $1500.00 (computer, monitor=
, printers, cash drawer, software) . Restaurant gift cards, wireless hand-h=
eld PCs for table orders.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3D06c471ac1b8714f8c5107=
3e62aaeb0cf

Re: [PATCH] plot.c, setjmp question

[<tim...@en...>]

> On Saturday 02 June 2007 14:00, Timothée Lecomte wrote:
>>
>> So, I conclude that any code executed conditionally to !setjmp(...), if
>> not changing the stack, could be put before the call to setjmp and give
>> exactly the same behaviour. In other words:
>>
>> if(!setjmp(...))
>> {
>>     /* setjmp returns direclty */
>>     code_that_does_not_change_the_stack();
>> }
>> else
>> {
>>     /* coming back from longjmp */
>> }
>>
>> is strictly equivalent to:
>>
>> code_that_does_not_change_the_stack();
>> if(setjmp(...))
>> {
>>     /* coming back from longjmp */
>> }
>>
>> Am I right ?
>
> I'm not certain, but I don't think this is correct.
>
> For one thing, SETJMP actually translates to sigsetjmp(env, save_signals).
> So both the stack and the signal state must remain unchanged.
>

More precisely, it's the signal mask, i.e.signals that we may have chosen
to block using sigprocmask. There's no such call in interrupt_setup().


> For another, consider what happens if there is an error return from
> the initialization code.
>
> Here's the actual code:
>
>     if (!SETJMP(command_line_env, 1)) {
>         /* first time */
>         interrupt_setup();
>         get_user_env();
>         init_loadpath();
> 	...
>     } else {
>         /* come back here from int_error() */
>
> But interrupt_setup() presumably changes the signal-handling state,
> so it cannot be moved ahead of SETJMP without changing the environment
> restored after longjmp().

Well, no, it doesn't change the signal _mask_, so it can be moved ahead of
setjmp.


>
> And if something inside init_loadpath() attempted an error return
> via longjmp() then you would get an infinite loop if you move the
> call ahead of SETJMP.  I don't think init_loadpath() in fact can
> trigger this, but it's something you have to worry about in general.
>

You're right, I missed that part: I have to verify that the calls I move
are not calling int_error() or bail_to_command_line, which would trigger a
longjmp.

Thank you very much for answering !

Best regards,

Timothée


>
> --
> Ethan A Merritt
>

Re: Version 4.0&4.2 ---terminal PDF, JPEG not be accessible in WinXP environment

[Petr M. <mi...@ph...>]

> > I would be really glad to know how to do that properly, but I tried at
> > least four different ways:
> > 
> > - compiling with MS Visual Studio -> declared unsupported
> > - cross-compiling from mac/linux -> you're on your own
> > - compiling with MinGW on Windows with pdflib from source -> no
> > success compiling the library
> > - compiling with MinGW on Windows with pdflib dll -> gnuplot crashes
> > when writing to file
> > (similar for gd)
> > 
> > and none of them worked. I'm no expert in compiling, but it's not fair
> > to say that "compiling is really easy". After all: it would be really
> > great to have the official windows binary with GD and PDF (and wxt?)
> > support built in.

The PDF terminal cannot be distributed in the executable for license 
reasons of PDFlib Lite.

The gif and png terminals are included in the official distribution; 
however, jpeg generation was not switched on by default. I've just change 
this in cvs. It compiles fine.

(BTW, I compile the windows executable by Mingw via wine on OpenSUSE Linux.)

---
PM

Re: [PATCH] plot.c, setjmp question

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 02 June 2007 14:00, Timoth=C3=A9e Lecomte wrote:
>=20
> So, I conclude that any code executed conditionally to !setjmp(...), if
> not changing the stack, could be put before the call to setjmp and give
> exactly the same behaviour. In other words:
>=20
> if(!setjmp(...))
> {
>     /* setjmp returns direclty */
>     code_that_does_not_change_the_stack();
> }
> else
> {
>     /* coming back from longjmp */
> }
>=20
> is strictly equivalent to:
>=20
> code_that_does_not_change_the_stack();
> if(setjmp(...))
> {
>     /* coming back from longjmp */
> }
>=20
> Am I right ?

I'm not certain, but I don't think this is correct.

=46or one thing, SETJMP actually translates to sigsetjmp(env, save_signals).
So both the stack and the signal state must remain unchanged.

=46or another, consider what happens if there is an error return from=20
the initialization code.

Here's the actual code:

    if (!SETJMP(command_line_env, 1)) {
        /* first time */
        interrupt_setup();
        get_user_env();
        init_loadpath();
	...
    } else {
        /* come back here from int_error() */

But interrupt_setup() presumably changes the signal-handling state,
so it cannot be moved ahead of SETJMP without changing the environment
restored after longjmp().

And if something inside init_loadpath() attempted an error return
via longjmp() then you would get an infinite loop if you move the
call ahead of SETJMP.  I don't think init_loadpath() in fact can=20
trigger this, but it's something you have to worry about in general.


=2D-=20
Ethan A Merritt

[PATCH] plot.c, setjmp question

[<tim...@en...>]

Hi!

I've been working on some code to rework some parts of gnuplot main loop
and initialization (mostly to address
wxt-on-mac-is-better-when-singlethreaded and the issues with handling
events from multiple interactive terminal at the same time).

I've come to think about the setjmp/longjmp mechanism for error handling.
It works perfectly fine in its current state, but I was wondering if there
could be some cleanup in plot.c:main(). In particular, from 'man setjmp':

NAME
       setjmp, sigsetjmp - save stack context for non-local goto
RETURN VALUE
       setjmp() and sigsetjmp() return 0 if returning directly, and
non-zero when returning from longjmp(3)  using  the  saved context.


So, I conclude that any code executed conditionally to !setjmp(...), if
not changing the stack, could be put before the call to setjmp and give
exactly the same behaviour. In other words:

if(!setjmp(...))
{
    /* setjmp returns direclty */
    code_that_does_not_change_the_stack();
}
else
{
    /* coming back from longjmp */
}

is strictly equivalent to:

code_that_does_not_change_the_stack();
if(setjmp(...))
{
    /* coming back from longjmp */
}

Am I right ?

If yes, is the attached patch correct and ok for CVS ? (it would allow
more generalization of the error mechanism)

Thanks for your comments.
Best regards,

Timothée

Re: Version 4.0&4.2 ---terminal PDF, JPEG not be accessible in WinXP environment

[Mojca M. <moj...@gm...>]

T24gNi8xLzA3LCBFdGhhbiBNZXJyaXR0IHdyb3RlOgo+IE9uIFRodXJzZGF5IDMxIE1heSAyMDA3
IDIxOjQ4LCDL77Pnsqggd3JvdGU6Cj4KPiBNYW55IGdudXBsb3QgdGVybWluYWxzIHJlcXVpcmUg
ZXh0ZXJuYWwgbGlicmFyaWVzIHRvIHN1cHBvcnQgdGhlbS4KPiBJZiB0aGVzZSBsaWJyYXJpZXMg
YXJlIGZvdW5kIG9uIHlvdXIgc3lzdGVtIGF0IHRoZSB0aW1lIGdudXBsb3QgaXMKPiBidWlsdCwg
dGhlbiBpdCB3aWxsIGF1dG9tYXRpY2FsbHkgaW5jbHVkZSBzdXBwb3J0LiAgSWYgdGhleSBhcmUg
bm90Cj4gZm91bmQsIGl0IHdpbGwgYnVpbGQgYSBnbnVwbG90IGV4ZWN1dGFibGUgdGhhdCBkb2Vz
IG5vdCBzdXBwb3J0Cj4gdGhlIHRlcm1pbmFscyB3aG9zZSBzdXBwb3J0IGxpYnJhcmllcyBhcmUg
bWlzc2luZy4KPgo+IEFwcGFyZW50bHkgdGhlIHN5c3RlbSB3aGVyZSB5b3VyIGNvcHkgb2YgZ251
cGxvdCB3YXMgYnVpbHQgZGlkIG5vdAo+IGhhdmUgdGhlIGdkIGxpYnJhcnkgKG5lZWRlZCBmb3Ig
anBlZyBzdXBwb3J0ICkgb3IgdGhlIFBERmxpYiBsaWJyYXJ5Cj4gKG5lZWRlZCBmb3IgcGRmIHN1
cHBvcnQpLiAgWW91IHdpbGwgbmVlZCB0byBpbnN0YWxsIHRoZXNlIGxpYnJhcmllcwo+IGZpcnN0
LCBhbmQgdGhlbiByZWJ1aWxkIGdudXBsb3QgZnJvbSBzb3VyY2UuCgpJIHdvdWxkIGJlIHJlYWxs
eSBnbGFkIHRvIGtub3cgaG93IHRvIGRvIHRoYXQgcHJvcGVybHksIGJ1dCBJIHRyaWVkIGF0Cmxl
YXN0IGZvdXIgZGlmZmVyZW50IHdheXM6CgotIGNvbXBpbGluZyB3aXRoIE1TIFZpc3VhbCBTdHVk
aW8gLT4gZGVjbGFyZWQgdW5zdXBwb3J0ZWQKLSBjcm9zcy1jb21waWxpbmcgZnJvbSBtYWMvbGlu
dXggLT4geW91J3JlIG9uIHlvdXIgb3duCi0gY29tcGlsaW5nIHdpdGggTWluR1cgb24gV2luZG93
cyB3aXRoIHBkZmxpYiBmcm9tIHNvdXJjZSAtPiBubwpzdWNjZXNzIGNvbXBpbGluZyB0aGUgbGli
cmFyeQotIGNvbXBpbGluZyB3aXRoIE1pbkdXIG9uIFdpbmRvd3Mgd2l0aCBwZGZsaWIgZGxsIC0+
IGdudXBsb3QgY3Jhc2hlcwp3aGVuIHdyaXRpbmcgdG8gZmlsZQooc2ltaWxhciBmb3IgZ2QpCgph
bmQgbm9uZSBvZiB0aGVtIHdvcmtlZC4gSSdtIG5vIGV4cGVydCBpbiBjb21waWxpbmcsIGJ1dCBp
dCdzIG5vdCBmYWlyCnRvIHNheSB0aGF0ICJjb21waWxpbmcgaXMgcmVhbGx5IGVhc3kiLiBBZnRl
ciBhbGw6IGl0IHdvdWxkIGJlIHJlYWxseQpncmVhdCB0byBoYXZlIHRoZSBvZmZpY2lhbCB3aW5k
b3dzIGJpbmFyeSB3aXRoIEdEIGFuZCBQREYgKGFuZCB3eHQ/KQpzdXBwb3J0IGJ1aWx0IGluLgoK
TW9qY2EKCgo+ID4gSGVsbG8sCj4gPgo+ID4gV2hlbiBJIHNldCB0aGF0IHR3byB0ZXJtaW5hbHMs
IGl0IHNob3dlZDoKPiA+Cj4gPiAqZ251cGxvdD4gc2V0IHRlcm0ganBlZwo+ID4gICAgICAgICAg
ICAgICAgICAgXgo+ID4gICAgICAgICAgdW5rbm93biBvciBhbWJpZ3VvdXMgdGVybWluYWwgdHlw
ZTsgdHlwZSBqdXN0ICdzZXQgdGVybWluYWwnIGZvciBhCj4gPiBsaXN0Kgo+ID4gKioKPiA+ICpn
bnVwbG90PiBzZXQgdGVybSBwZGYKPiA+ICAgICAgICAgICAgICAgICAgIF4KPiA+ICAgICAgICAg
IHVua25vd24gb3IgYW1iaWd1b3VzIHRlcm1pbmFsIHR5cGU7IHR5cGUganVzdCAnc2V0IHRlcm1p
bmFsJyBmb3IgYQo+ID4gbGlzdCoKPiA+ICoqCj4gPiBhbmQgSSB0eXBlZCAqc2V0IHRlcm06Kgo+
ID4gdGhlcmUgYXJlIG5vIEpwZWcgYW5kIHBkZiBpbiB0aGUqICBBdmFpbGFibGUgdGVybWluYWwg
dHlwZXMuKgo+ID4gKioKPiA+IElzIHRoZXJlIHNvbWV0aGluZyBJIG5lZWQgdG8gaW5zdGFsbCB0
byBhY2Nlc3MgdGhlc2UgdHdvIHRlcm1pbmFscz8KPiA+IEkgaGF2ZSB0cmllZCBib3RoIHZlcnNp
b24gNC4wIGFuZCA0LjIsIHNhbWUgcHJvYmxlbS4KPiA+Cj4gPiBUaGFua3MhCj4gPiBUb2RkIFN1
bgo+ID4gKioKPiA+ICoqCj4gPgo+Cj4gLS0KPiBFdGhhbiBBIE1lcnJpdHQgICAgICAgICAgICBD
b3VyaWVyIERlbGl2ZXJpZXM6IDE5NTkgTkUgUGFjaWZpYwo+IERlcHQgb2YgQmlvY2hlbWlzdHJ5
Cj4gSGVhbHRoIFNjaWVuY2VzIEJ1aWxkaW5nCj4gVW5pdmVyc2l0eSBvZiBXYXNoaW5ndG9uIC0g
U2VhdHRsZSBXQSA5ODE5NS03NzQyCj4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVGhpcyBTRi5uZXQg
ZW1haWwgaXMgc3BvbnNvcmVkIGJ5IERCMiBFeHByZXNzCj4gRG93bmxvYWQgREIyIEV4cHJlc3Mg
QyAtIHRoZSBGUkVFIHZlcnNpb24gb2YgREIyIGV4cHJlc3MgYW5kIHRha2UKPiBjb250cm9sIG9m
IHlvdXIgWE1MLiBObyBsaW1pdHMuIEp1c3QgZGF0YS4gQ2xpY2sgdG8gZ2V0IGl0IG5vdy4KPiBo
dHRwOi8vc291cmNlZm9yZ2UubmV0L3Bvd2VyYmFyL2RiMi8KPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IGdudXBsb3QtYmV0YSBtYWlsaW5nIGxpc3QK
PiBnbnVwbG90LWJldGFAbGlzdHMuc291cmNlZm9yZ2UubmV0Cj4gaHR0cHM6Ly9saXN0cy5zb3Vy
Y2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vZ251cGxvdC1iZXRhCj4K

Re: Version 4.0&4.2 ---terminal PDF, JPEG not be accessible in WinXP environment

[Ethan M. <merritt@u.washington.edu>]

On Thursday 31 May 2007 21:48, =E5=AD=99=E5=B4=87=E6=B3=A2 wrote:

Many gnuplot terminals require external libraries to support them.
If these libraries are found on your system at the time gnuplot is
built, then it will automatically include support.  If they are not
found, it will build a gnuplot executable that does not support
the terminals whose support libraries are missing.

Apparently the system where your copy of gnuplot was built did not
have the gd library (needed for jpeg support ) or the PDFlib library
(needed for pdf support).  You will need to install these libraries
first, and then rebuild gnuplot from source.



> Hello,
>=20
> When I set that two terminals, it showed:
>=20
> *gnuplot> set term jpeg
>                   ^
>          unknown or ambiguous terminal type; type just 'set terminal' for=
 a
> list*
> **
> *gnuplot> set term pdf
>                   ^
>          unknown or ambiguous terminal type; type just 'set terminal' for=
 a
> list*
> **
> and I typed *set term:*
> there are no Jpeg and pdf in the*  Available terminal types.*
> **
> Is there something I need to install to access these two terminals?
> I have tried both version 4.0 and 4.2, same problem.
>=20
> Thanks!
> Todd Sun
> **
> **
>=20

=2D-=20
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

default size of wxt terminal

[Dmitri A. S. <das...@gm...>]

How do I change the defaults of wxt terminal window?

gnuplot -geometry 1024x768

works for x11 terminal, but not for wxt

Sincerely,

Dmitri.
--

Re: q for quit in plot windows

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Friday 01 June 2007 10:39, Petr Mikulik wrote:
> 
>>No, let us keep the <space> hotkey, and if somebody does not find it 
>>convenient, he can rebind it. There was no complain or report on this issue 
>>from any user.
> 
> 
> This is just wrong. You cannot rebind it.
> 
> As I keep trying to point out, the current implementation of
> 'q' and ' ' bypasses the "bind" mechanism altogether, and cannot be
> changed by the user.  This is bad. 
> 
> And people *do* complain. My work-around was to introduce the -ctrlq
> option, which returns both ' ' and 'q' to being processed like any 
> other key.

This is what I have in mind.

   This is what you proposed with your "on/off" idea, right?
> Let's make *that* the default.  No special treatment for the 'q' and
> ' ' keys unless the user specifically requests it.

Not even user specified.  If gnuplot launches with a working mouse, simply send 
a code (as yet not implemented) to gnuplot_x11 to indicate it shouldn't handle 
any keys itself, but pass them all on.  It's a legacy thing; if there's no 
mouse, you'd still have the 'q' and ' ' to fall back on.  The on/off isn't for 
the user.

   There are several
> patchsets on SourceForge exploring how the "raise console" operation
> could be made a user option.

If one goes that route, then all that need be done is bind ' ' to the raise 
console command.  I'd even like it if the command line window didn't lose focus 
when a new plot comes up.  (That'd be a gnuplot_x11 thing I guess.)

Dan

Re: Quick refresh [was: q for quit in plot windows]

[Daniel J S. <dan...@ie...>]

 >   - refresh of "with image" styles produces garbage
 >     So far I can't figure out why.
 >     Daniel, maybe you can see what I'm overlooking?

I'll look when I get the chance.  Will be gone this weekend.

Quick refresh [was: q for quit in plot windows]

[Ethan M. <merritt@u.washington.edu>]

On Friday 01 June 2007 10:39, Petr Mikulik wrote:
> I have noticed a recent release of octave 2.9.12. 
> Could we get the "replot" for inlined files working? 
> This feature will be very welcome. 

I continue to chip away at the pieces that are not working yet.
Known issues:

  - refresh of "with image" styles produces garbage
    So far I can't figure out why.
    Daniel, maybe you can see what I'm overlooking?

  - The default key bindings must be examined one by one and
    re-written to choose between "refresh" and "replot" as
    appropriate.

  - Doesn't yet handle splot. In particular, it doesn't
    handle zooming the 2D plots produced by "set view map; splot..."

  - General lack of testing.  It is highly likely that there
    are cases that are not handled properly; I just haven't noticed
    them yet.

More testers, and more eyes trying to debug the image code
would help speed things up.

-- 
Ethan A Merritt

Re: q for quit in plot windows

[Ethan M. <merritt@u.washington.edu>]

On Friday 01 June 2007 10:39, Petr Mikulik wrote:
> 
> No, let us keep the <space> hotkey, and if somebody does not find it 
> convenient, he can rebind it. There was no complain or report on this issue 
> from any user.

This is just wrong. You cannot rebind it.

As I keep trying to point out, the current implementation of
'q' and ' ' bypasses the "bind" mechanism altogether, and cannot be
changed by the user.  This is bad. 

And people *do* complain. My work-around was to introduce the -ctrlq
option, which returns both ' ' and 'q' to being processed like any 
other key.  This is what you proposed with your "on/off" idea, right?
Let's make *that* the default.  No special treatment for the 'q' and
' ' keys unless the user specifically requests it.  There are several
patchsets on SourceForge exploring how the "raise console" operation
could be made a user option.


-- 
Ethan A Merritt

Re: q for quit in plot windows

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Friday 01 June 2007 10:23, Daniel J Sebald wrote:
> 
>>>But the "raise console" mechanism doesn't operate via key bindings.
>>>That's the whole point of this discussion.
>>
>>I thought you were proposing to make close and raise part of key bindings, not 
>>get rid of the actions.
> 
> 
> I want to get rid of them altogether. 
> Petr wants to keep the "raise" action, but it is not clear what 
> it would be triggered by.
>  
> 
>>>Switching it to use key bindings would be a major change,
>>
>>Why?  I thought the difficult part was handling all events from all terminals at 
>>the same time.  (And it is, I looked at the code and saw some global term-> 
>>pointer and that's as far as I want to look.)
> 
> 
> I have tried to explain this about 4 times now.
> I give up.

There are all these entries in the term table

#ifdef USE_MOUSE
     int (*waitforinput) __PROTO((void));     /* used for mouse input */
     void (*put_tmptext) __PROTO((int, const char []));   /* draws temporary 
text; int determines where: 0=statusline, 1,2: at corners of zoom box, with \r 
separating text above and below the point */
     void (*set_ruler) __PROTO((int, int));    /* set ruler location; x<0 
switches ruler off */
     void (*set_cursor) __PROTO((int, int, int));   /* set cursor style and 
corner of rubber band */
     void (*set_clipboard) __PROTO((const char[]));  /* write text into 
cut&paste buffer (clipboard) */
#endif

why would adding something like (*reposition_window) not work?

Dan

Re: q for quit in plot windows

[Petr M. <mi...@ph...>]

> > Why not 'ctrl-i' ? Sounds like 'interactive' or 'interface', and if I
> > recall correctly it's the key to be pressed to edit in vim.
> 
> We should not re-invent key mappings, since so many people are
> used to a particular set of mappings.  I think it safer to have
> no default at all, and require the user to explicitly choose a
> hotkey if he wants one.

No, let us keep the <space> hotkey, and if somebody does not find it 
convenient, he can rebind it. There was no complain or report on this issue 
from any user.

> Petr wants to keep the "raise" action, but it is not clear what
> it would be triggered by.

As it works currently.

> I have tried to explain this about 4 times now.
> I give up.

I agree. Let it as is now.


***

I have noticed a recent release of octave 2.9.12. Could we get the "replot" 
for inlined files working? This feature will be very welcome.


---
PM

Re: q for quit in plot windows

[<tim...@en...>]

> On Friday 01 June 2007 10:04, Timothée Lecomte wrote:
>> Why not 'ctrl-i' ? Sounds like 'interactive' or 'interface', and if I
>> recall correctly it's the key to be pressed to edit in vim.
>
> ctrl-i is the <tab> key, and is a normal thing to type in a text
> string.  Remember that ctrl-a through ctrl-z are all normal ASCII
> single-byte characters, and have a long history of specific use.
>

Oh, ok. I now understand why so many apps use a key plus two modifiers for
their bindings.


> We should not re-invent key mappings, since so many people are
> used to a particular set of mappings.  I think it safer to have
> no default at all, and require the user to explicitly choose a
> hotkey if he wants one.
>

Agreed.