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

Re: wxWidgets terminal : XPM cursors and icons

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

Ethan Merritt wrote:
> I would rather the plot filled the window.
> Another option is to honor the setting of "set ratio", if any,
> but otherwise fill the window.  This has been suggested for=20
> x11 also, but nobody has offered a patch :-)
>  =20
>
I am afraid there's a confusion here. The wxWidgets terminal always=20
honor the settings of "set size ratio <r>" when you plot something. The=20
question only affects what happens immediately when you resize a window.

gnuplot> plot x    =3D> the plot window is filled, let's say it is 600x40=
0
[you resize the window to 200x200]   =3D> the plot will be scaled to=20
200x133, (font sizes and linewidths rescaled)
gnuplot> plot x    =3D> the plot window is filled again, the plot is=20
200x200, the font sizes and linewidths are back to original.

I like this behaviour because gnuplot has carefully taken the font sizes=20
into account to draw something with a good layout, so this layout should=20
not be messed up when you resize your window (remember that we can't=20
call 'replot' automatically as it is not compatible with multiplot).

I admit that linewidths could not be scaled, I don't really mind. But=20
font sizes seem more important to me as they are the base of gnuplot=20
layout computations.

Petr Mikulik wrote:
>> By the way, the wxWidgets terminal differs from others in the fact
>> that it keeps the aspect ratio (width/height) of the plot
>>
>> Now that several of you have tried it, can you tell me how you feel
>> about that behaviour ?
>
> OS/2 PM terminal has a check menu item where you can set which=20
> behaviour you like at the moment. I preferred non-aspect ratio for=20
> most plots, and aspect ratio for maps. Now, with other terminals, I=20
> prefer the x11 way -- the ration can be set by 'set size ratio -1'.
Same remark as above : "set size ratio <r>" is relevant to the time when=20
gnuplot computes the plot, not when you resize your window between two=20
different "plot <something>". Anyway, I think that the x11 way doesn't=20
respect "set size ratio -1" (for example) :

gnuplot> set term x11
gnuplot> set size ratio -1
gnuplot> plot x    =3D> the plot window is is 600x400, the axes are a squ=
are
[you resize the window to 200x200]   =3D> the plot is scaled to 200x200,=20
(font sizes and linewidths not rescaled), it loses its square aspect,=20
whereas you explicitely asked for it
gnuplot> plot x    =3D> nothing changes

With the wxWidgets terminal :

gnuplot> set term wxt
gnuplot> set size ratio -1
gnuplot> plot x    =3D> the plot window is is 600x400, the axes are a squ=
are
[you resize the window to 200x200]   =3D> the plot is scaled to 200x133,=20
(font sizes and linewidths rescaled), it keeps its square aspect
gnuplot> plot x    =3D> gnuplot recomputes the plot, it profits better=20
from the new window size, the axes are still square

With the wxWidgets terminal, the plot is always square, whereas it's not=20
with the x11 terminal !

>
>> it scales the font sizes and linewidths when you resize the window.
>
> I prefer fixed sizes; you can still read&monitor the plot in a small=20
> window.
In any case, as soon as you hit 'replot' (via the icon, the key, or in=20
the command line), gnuplot computes the plot again and take the default=20
sizes.
I was thinking exactly the same as you ... but in favor of the rescaling=20
: "I prefer to rescale font sizes, so that you can still have a clean=20
plot in a small window, without the labels and the lines overlapping=20
each other".

Best regards,

Timoth=E9e

Re: discontinuity feature worthwhile?

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

James R. Van Zandt wrote:
> Daniel J Sebald <dan...@ie...> wrote:
> 
>>  why shouldn't a plotting program be able to leave out the line
>>  connecting the left and right limits of a discontinuity?
> 
> 
> We could implement an optional threshold on the maximum slope of the
> line.  For example:
> 
>   set maxstepy {<fraction>}
>   
>   If the difference between successive y values exceeds <fraction> of
>   the graph height, then that line segment is omitted.  <fraction> is
>   a number between 0 and 1.  For "set maxstepy" with no number,
>   <fraction> defaults to 1/3.
>   
>   set maxstepx {<fraction>}
>   
>   If the difference between successive x values exceeds <fraction> of
>   the graph width, then that line segment is omitted.  <fraction> is a
>   number between 0 and 1.  For "set maxstepx" with no number,
>   <fraction> defaults to 1/3.
>   
>   unset maxstepy
>   unset maxstepx
>   
>   Return to the default condition, in which all line segments are
>   drawn, regardless of the change in y (resp. x) values.


It's an idea that makes sense, but I wonder if it wouldn't cause unexpected problems.  It's difficult to pick a value of 1/3 for the slope because taking into consideration the scale of x compared to y a slope of 1/3 could be just fine; as could 3e5 depending upon circumstances.

Checking for successive samples where the slope changes drastically probably isn't a solution either because if one plots noise from the random number generator, that will have sets of three points where the slope changes drastically from one pair of points to the next.

I think the only way to deal with a discontinuity in a general way is for a point in the data set to be 1/0.  That would require picking data points right on the discontinuity to ensure it is treated correctly.  But then that requires some form of non-uniform sampling, and so on.  Hans pointed out some problems with defining discontinuities.

...

I've put together a patch on SourceForge cleaning up the probability density and distribution demos.  The functions are properly defined for all of the real line or set of integers.  Parameters are range checked.

This should give a variety of examples of discontinuities and how to deal with them:

  o Choosing sampling so that the discontinuity is part of the plotted points.

  o Plotting two different ranges, one on each side of the discontinuity, very near the discontinuity if not on the discontinuity.

  o Casting float values to integers when appropriate.

  o Using the histeps (steps, fsteps) style when appropriate.

For example, below are plots for just one of the many CDFs.  In this case a discrete random variable.  (Technically, the discrete r.v. should be either a probability mass function or delta functions, but I figured I'd leave the histograms as is for prob2.dem.)  In the first plot (before patch) the idea is to use a high enough sampling to make the discrete steps look marginally good.  But gnuplot has a histeps feature, so rather than do that, histeps are used in the second plot and all the points of the sample range are cast to an int because now the pdf for a binomial random variable requires the input value be an int.  All those points in between the integers are simply extraneous.

Of course, it would be nice to not have those points in between, but it isn't possible to have multiple plotting ranges and samplings.  I personally think that would be a nice gnuplot feature, e.g.,

  plot [0:1-eps] funcwithdiscontinuity(x) lt 1, [1:5] funcwithdiscontinuity(x) lt 1
  plot [-2:1:12] binom(x,1,0.5), [-2:12] normal(x,0,1)

so that one can plot multiple portions of functions, or individual functions.  As for the syntax, I don't know how one would specify what the number of samples should be, as opposed to the sampling interval.  The examples I've given in the revamped demo work, but it isn't the most convenient.  Anyway...

People will have preference to whether a line should be connecting a discontinuity, but if one desires the line be present I think the preference is for the line connecting the right and left limits of a discontinuity to be vertical as opposed to the slightly sloped line that comes about from uniform sampling.  "with steps" gives us that, but in many cases the steps appearance isn't always appropriate where parts of the function are continuous.

Regarding this, it might be nice for steps to have a version where the vertical lines are not plotted, just the horizontal lines.  Mathematically that is more appropriate, and an analog oscilloscope trace often looks to have no vertical lines with unfiltered reconstructed signals.

Also note in this example plots that after the patch, the definition for the distribution is correct for all of x.  So the negative values of the PDF, after the patch, look correct.

Dan

PS:  fsteps/histeps/steps might have worked syntactically better as lsteps/csteps/rsteps.  (I'm guessing "fsteps" means forward steps or front steps.)

Re: wxWidgets terminal : XPM cursors and icons

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

> By the way, the wxWidgets terminal differs from others in the fact
> that it keeps the aspect ratio (width/height) of the plot
>
> Now that several of you have tried it, can you tell me how you feel
> about that behaviour ?

OS/2 PM terminal has a check menu item where you can set which behaviour you 
like at the moment. I preferred non-aspect ratio for most plots, and aspect 
ratio for maps. Now, with other terminals, I prefer the x11 way -- the 
ration can be set by 'set size ratio -1'.

> it scales the font sizes and linewidths when you resize the window.

I prefer fixed sizes; you can still read&monitor the plot in a small window.

---
PM

Re: wxWidgets terminal : XPM cursors and icons

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

On Tuesday 06 June 2006 03:16 pm, you wrote:
> By the way, the wxWidgets terminal differs from others in the fact
> that it keeps the aspect ratio (width/height) of the plot 

> Now that several of you have tried it, can you tell me how you feel
> about that behaviour ?

I would rather the plot filled the window.
Another option is to honor the setting of "set ratio", if any,
but otherwise fill the window.  This has been suggested for 
x11 also, but nobody has offered a patch :-)

	Ethan

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: wxWidgets terminal : XPM cursors and icons

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

Ethan Merritt wrote:
> On Friday 02 June 2006 05:34 pm, Timoth=E9e Lecomte wrote:
>  =20
>> 1) This is the default cursor [...] is supposed to be a black cross=20
>> surrounded by a white border so that it is visible on a dark
>> background, with a transparent "hole" in the center.
>>    =20
>
>  =20
>> (by the way, how many of you actually tried it or use it ?)
>>    =20
>
> I have been using it routinely.
> The only problems I notice are that=20
> (1) You must do a manual replot after resizing the terminal
>     (else the mouse coords are wrong among other things)
>  =20
I reproduced the problem with the mouse coords (y-axis) that are wrong=20
when you resize the wxWidgets terminal. I will commit a patch soon. Do=20
you see any other problem with the resizing behaviour ?

By the way, the wxWidgets terminal differs from others in the fact that=20
it keeps the aspect ratio (width/height) of the plot and that it scales=20
the font sizes and linewidths when you resize the window. We discussed=20
that a little before the commit. Now that several of you (at least Ethan=20
and Petr) have tried it, can you tell me how you feel about that behaviou=
r ?

Best regards,

Timoth=E9e

Re: no duplicated lines for GNU readline history

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

Petr Mikulik wrote:
> Fine, this patch is in cvs now.
>
> I have yet another proposal. Most command line tools with a readline=20
> (octave, bash, ipython, ...) store their command history by default. In=
=20
> gnuplot, this feature has to be explicitly set during ./configure:
>  	./configure --enable-history-file
>
> This feature is very useful. Thus, I propose to change the default stat=
us of=20
> this feature from "disabled" to "enabled", so that you should disable i=
t if=20
> you really don't want it.
>
> Any objections?
>  =20

No, I was thinking the same thing a few days ago, tired of having to add=20
--enable-history-file for each ./configure

Best regards,

Timoth=E9e

Re: no duplicated lines for GNU readline history

[Juergen W. <wie...@fr...>]

Petr Mikulik wrote:
> ...
>
> I have yet another proposal. Most command line tools 
> with a readline ...
> ...

Yet another proposal, while in it: the bash also has a feature of
incremental search within the history with C-r.  AFAICS, this is
enabled by default in GNU readline.  Can this easily be enabled
while using the alternative interface to the readline library?  I
think this would be very convenient.

Juergen

Re: no duplicated lines for GNU readline history

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

Fine, this patch is in cvs now.

I have yet another proposal. Most command line tools with a readline 
(octave, bash, ipython, ...) store their command history by default. In 
gnuplot, this feature has to be explicitly set during ./configure:
 	./configure --enable-history-file

This feature is very useful. Thus, I propose to change the default status of 
this feature from "disabled" to "enabled", so that you should disable it if 
you really don't want it.

Any objections?

---
PM

Re: wxWidgets terminal : XPM cursors and icons

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

Ethan, your message arrived as I was sending mine, it is nice to see=20
that our ideas are not so different.
Here are some thoughts :

Ethan A Merritt wrote:
> On Sunday 04 June 2006 08:54 am, Ethan A Merritt wrote:
>  =20
>> It's the same old problem: gnuplot mixes the input streams from the
>> keyboard and the current terminal into a single queue.  Thus both
>> terminal events and keyboard input are read via term->waitforinput().
>> If you change the terminal, you change the input routine and no longer
>> read events from the previous terminal. =20
>>    =20
>
> On the other hand, the only terminals that implement term->waitforinput
> seem to be x11, wxt, and ggi.  I think we can ignore ggi, if not delete
> it from the tree altogether.  And other than for debugging/comparison, =
I=20
> can't think why you would routinely be switching back and forth between
> x11 and wxt.
>  =20
Agreed, but supporting several waitforinput() should not be that hard,=20
see my previous message.
> So the real issue is when you are using either x11 or wxt, but shift
> temporarily to a different terminal for printing.  Perhaps the answer
> is that in such a case gnuplot could continue to channel input through
> the previous driver's waitforinput() routine.  I think maybe this can
> be done in two steps:
>
>  - When a new terminal is set, we conditionally set a new variable
> 	if (term->waitforinput)
> 		current_waitforinput =3D term->waitforinput;
>
>  - Replace existing references to term->waitforinput() by the new
>    pointer current_waitforinput. I found 3 occurrances in command.c
>    and another 3 in readline.c
>  =20
That's indeed the first step of the simplest approach... The value of=20
"term" has to be changed too when calling current_wiaitforinput() so=20
that the event system calls the right term->puttmptext() and friends.
> I have placed a small patch on SourceForge that does this.
> It seems to work for x11, with a few glitches that appear minor but
> may turn out to be profound. However, if the terminal is set to wxt and
> than to something else, this patch causes a lot of binary junk to spew
> back to the console terminal window.  I don't understand this at all.
> Timoth=E9e, can you have a look to see why this happens?
>  =20
I see exactly the same binary junk with the X11 terminal ! What you see=20
is the binary PNG output sent to stdout, I think. If you try with the=20
postscript terminal, you see the ascii output of the postscript commands=20
instead...

Regards,

Timoth=E9e

Re: wxWidgets terminal : XPM cursors and icons

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

Ethan A Merritt wrote:
> On Sunday 04 June 2006 02:31 am, Petr Mikulik wrote:
>  =20
>> I would prefer that this hotkey works always. Could this be organized?
>>    =20
>
> So far no one has suggested how this can be done.
>  =20

Let's suggest something...
>  =20
>> Are not the messages from gnuplot_x11 delivered always to gnuplot?=20
>>    =20
>
> Yes, but not immediately.
> It's the same old problem: gnuplot mixes the input streams from the
> keyboard and the current terminal into a single queue.  Thus both
> terminal events and keyboard input are read via term->waitforinput().
> If you change the terminal, you change the input routine and no longer
> read events from the previous terminal. =20
>  =20
As far as I can tell, term->waitforinput() could be replaced by=20
something like term->processevents(), which would process any pending=20
events and return. Then, this would be called repeatedly by the core=20
after a select() timeout on stdin, or the equivalent functions on=20
different platforms.
Until now, nothing different from what is done currently.

Then, several *term*->processevents() could be called, for each=20
interactive terminal previously initialized. If "term" is the current=20
terminal, all the events
will be processed. Otherwise, only events like "raise" (ie "spacebar=20
pressed" in the default setting) or "close terminal" (ie "q pressed" in=20
the default setting) would be processed.

To sum up : the getc() wrapper is a loop on :
    select(...STDIN,TIMEOUT...) on Unix,  GetMessage(...) on Windows,=20
SomeEquivalent(...) on OS/2
    first_interactive_term->processevents()
    second_interactive_term->processevents()
    ...

Regards,

Timoth=E9e

Re: wxWidgets terminal : XPM cursors and icons

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

On Sunday 04 June 2006 08:54 am, Ethan A Merritt wrote:
> It's the same old problem: gnuplot mixes the input streams from the
> keyboard and the current terminal into a single queue.  Thus both
> terminal events and keyboard input are read via term->waitforinput().
> If you change the terminal, you change the input routine and no longer
> read events from the previous terminal. =20

On the other hand, the only terminals that implement term->waitforinput
seem to be x11, wxt, and ggi.  I think we can ignore ggi, if not delete
it from the tree altogether.  And other than for debugging/comparison, I=20
can't think why you would routinely be switching back and forth between
x11 and wxt.

So the real issue is when you are using either x11 or wxt, but shift
temporarily to a different terminal for printing.  Perhaps the answer
is that in such a case gnuplot could continue to channel input through
the previous driver's waitforinput() routine.  I think maybe this can
be done in two steps:

 - When a new terminal is set, we conditionally set a new variable
	if (term->waitforinput)
		current_waitforinput =3D term->waitforinput;

 - Replace existing references to term->waitforinput() by the new
   pointer current_waitforinput. I found 3 occurrances in command.c
   and another 3 in readline.c

I have placed a small patch on SourceForge that does this.
It seems to work for x11, with a few glitches that appear minor but
may turn out to be profound.  However, if the terminal is set to wxt and
than to something else, this patch causes a lot of binary junk to spew
back to the console terminal window.  I don't understand this at all.
Timoth=E9e, can you have a look to see why this happens?


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: wxWidgets terminal : XPM cursors and icons

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

On Sunday 04 June 2006 02:31 am, Petr Mikulik wrote:
> 
> I would prefer that this hotkey works always. Could this be organized?

So far no one has suggested how this can be done.

> Are not the messages from gnuplot_x11 delivered always to gnuplot? 

Yes, but not immediately.
It's the same old problem: gnuplot mixes the input streams from the
keyboard and the current terminal into a single queue.  Thus both
terminal events and keyboard input are read via term->waitforinput().
If you change the terminal, you change the input routine and no longer
read events from the previous terminal.  

The events are not lost; they are delivered eventually when the terminal
is set back to the original type and term->waitforinput() is next called.

> Considering 'q' hotkey: I propose to allow its rebounding, and in this case 
> gnuplot_x11 to close itself, without dispatching this message to gnuplot. 

The problem for 'q' is slightly different.  Key bindings are handled
by gnuplot itself; the terminal drivers do not know about them.
So then the problem is how do you tell gnuplot_x11 that it should send
'q' as an event to the main program rather than exiting?

> When binding 'q' or init of terminal, gnuplot should  write to terminal 'use 
> key "x" to quit'.

In the case of x11, gnuplot does not know this.
gnuplot_x11 reads it from an X resource.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: wxWidgets terminal : XPM cursors and icons

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

> plot x
> <press space in the x11 window> => nothing happens
> <press space in the wxt window> => the gnuplot console is raised
> set term png
> <press space in the x11 window> => nothing happens
> <press space in the wxt window> => nothing happens
>
> Without the patch, in any case the gnuplot console is raised.
> If this is acceptable, then the patch should be committed.

I would prefer that this hotkey works always. Could this be organized?
Are not the messages from gnuplot_x11 delivered always to gnuplot? 
Executation of this code does not depend on current terminal.

Considering 'q' hotkey: I propose to allow its rebounding, and in this case 
gnuplot_x11 to close itself, without dispatching this message to gnuplot. 
When binding 'q' or init of terminal, gnuplot should  write to terminal 'use 
key "x" to quit'.

---
PM

Re: wxWidgets terminal : XPM cursors and icons

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

On Friday 02 June 2006 06:27 pm, Timoth=E9e Lecomte wrote:
> > On a related topic, are you happy with the state of the
> > "Bind <space> to builtin_raise in mouse.c" patchset?
> > If so, let's commit it to CVS.
>=20
> *I* am happy with it, but I aknowledge a regression of this approach : the
> events from the terminal have to be processed to be taken into account.
> set term png
> <press space in the x11 window> =3D> nothing happens
> <press space in the wxt window> =3D> nothing happens
> Without the patch, in any case the gnuplot console is raised.
> If this is acceptable, then the patch should be committed.

It's acceptable to me, but then I intend to turn this behavior off anyhow.
The question is whether it is acceptable to people who actually use it.
Petr?

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: wxWidgets terminal : XPM cursors and icons

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

> The only problems I notice are that
> (1) You must do a manual replot after resizing the terminal
>     (else the mouse coords are wrong among other things)
> (2) I have to hack the source to make it ignore 'q'
>     We've got to come up with an equivalent to the ctrlq X-resource

In the spirit of the patch for the spacebar, we could bind 'q' to a new
mechanism in mouse.c based on the codes for "set <term> close" and the
"winid" field in the gp_event_t structure. See below for limitations of
this approach.

> On a related topic, are you happy with the state of the
> "Bind <space> to builtin_raise in mouse.c" patchset?
> If so, let's commit it to CVS.

*I* am happy with it, but I aknowledge a regression of this approach : th=
e
events from the terminal have to be processed to be taken into account.
For example :

set term wxt
plot x
<press space> =3D> the gnuplot console is raised
set term x11
plot x
<press space in the wxt window> =3D> nothing happens
<press space in the x11 window> =3D> the gnuplot console is raised
set term wxt
plot x
<press space in the x11 window> =3D> nothing happens
<press space in the wxt window> =3D> the gnuplot console is raised
set term png
<press space in the x11 window> =3D> nothing happens
<press space in the wxt window> =3D> nothing happens

Without the patch, in any case the gnuplot console is raised.
If this is acceptable, then the patch should be committed.

>> 2) Lars Hecking reported that 'make check' before 'make install' will
>> complain (just a warning) because it doesn't find the PNG icons used
>> in the toolbar. Indeed they have to be installed in
>> PREFIX/share/gnuplot/4.1/png before they can be used. I proposed to
>> replace the PNG icons by XPM icons included at compile time.
>
> I'd rather keep the PNG icons, and think about generalizing the
> mechanism so that users can configure their own new buttons and
> supply an icon to go with it.

The both solutions are not mutually exclusive. The point is that dealing
with hard-coded paths is quite a nightmare to make it work in every
situation.

Timoth=E9e

Re: discontinuity feature worthwhile?

[James R. V. Z. <jr...@co...>]

Daniel J Sebald <dan...@ie...> wrote:
>   why shouldn't a plotting program be able to leave out the line
>   connecting the left and right limits of a discontinuity?

We could implement an optional threshold on the maximum slope of the
line.  For example:

  set maxstepy {<fraction>}
  
  If the difference between successive y values exceeds <fraction> of
  the graph height, then that line segment is omitted.  <fraction> is
  a number between 0 and 1.  For "set maxstepy" with no number,
  <fraction> defaults to 1/3.
  
  set maxstepx {<fraction>}
  
  If the difference between successive x values exceeds <fraction> of
  the graph width, then that line segment is omitted.  <fraction> is a
  number between 0 and 1.  For "set maxstepx" with no number,
  <fraction> defaults to 1/3.
  
  unset maxstepy
  unset maxstepx
  
  Return to the default condition, in which all line segments are
  drawn, regardless of the change in y (resp. x) values.

                   - Jim Van Zandt

Re: wxWidgets terminal : XPM cursors and icons

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

On Friday 02 June 2006 05:34 pm, Timoth=E9e Lecomte wrote:
>
> 1) This is the default cursor [...] is supposed to be a black cross=20
> surrounded by a white border so that it is visible on a dark
> background, with a transparent "hole" in the center.

> (by the way, how many of you actually tried it or use it ?)

I have been using it routinely.
The only problems I notice are that=20
(1) You must do a manual replot after resizing the terminal
    (else the mouse coords are wrong among other things)
(2) I have to hack the source to make it ignore 'q'
    We've got to come up with an equivalent to the ctrlq X-resource

On a related topic, are you happy with the state of the
"Bind <space> to builtin_raise in mouse.c" patchset?
If so, let's commit it to CVS.
 =20

> 2) Lars Hecking reported that 'make check' before 'make install' will
> complain (just a warning) because it doesn't find the PNG icons used
> in the toolbar. Indeed they have to be installed in
> PREFIX/share/gnuplot/4.1/png before they can be used. I proposed to
> replace the PNG icons by XPM icons included at compile time.

I'd rather keep the PNG icons, and think about generalizing the
mechanism so that users can configure their own new buttons and
supply an icon to go with it.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

wxWidgets terminal : XPM cursors and icons

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

Dear all,

I have several questions regarding the use of cursors and icons in the
wxWidgets terminal :

1) Petr Mikulik reported that the cross cursor was not working properly
for him. This is the default cursor when the mouse is on the graph. It is
supposed to be a black cross surrounded by a white border so that it is
visible on a dark background, with a transparent "hole" in the center. On
Petr's machine, the cross is all white. Have the other people that have
tried the wxWidgets terminal seen this ?
(by the way, how many of you actually tried it or use it ?)

2) Lars Hecking reported that 'make check' before 'make install' will
complain (just a warning) because it doesn't find the PNG icons used in
the toolbar. Indeed they have to be installed in
PREFIX/share/gnuplot/4.1/png before they can be used. I proposed to
replace the PNG icons by XPM icons included at compile time. Then the
problem of finding the icons vanishes, but the executable's size grows.

As I said to Lars :

"A 16x16 PNG file is ~700 Bytes.
A 16x16 XPM file is ~2.5 kBytes, plus a second XPM file for the alpha
channel (so that the icons look good), ~700 Bytes.

There are 9 icons in the terminal's toolbar, so using XPM icons would
include ~30 kBytes into the source files. I don't really know if these 30
kBytes are somewhat compressed into the final binary, but at worst we add
30 kBytes."

What do you think about this ?

Timoth=E9e

Re: factorial for float complaint

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

Ethan Merritt wrote:
> On Friday 02 June 2006 10:24 am, Daniel J Sebald wrote:
> 
>>Should gnuplot be giving this kind of result?
>>
>>gnuplot> print -3!
>>-6.0
> 
> 
> operator precedence.  factorial trumps negation.

Oh yeah.  Err... What was I thinking?

Re: factorial for float complaint

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

On Friday 02 June 2006 10:24 am, Daniel J Sebald wrote:
> Should gnuplot be giving this kind of result?
>
> gnuplot> print -3!
> -6.0

operator precedence.  factorial trumps negation.

gnuplot> print (-3)!
1.0

which is still a bit unexpected, but shows that
negative input is treated as being zero.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

factorial for float complaint

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

Just wondering if the complaint

gnuplot> print 3.0!
         factorial (!) argument must be an integer

is necessary or whether gnuplot could be programmed to check if the float is a whole number first and then go forward with the computation, if not then complain.

It would be a simple matter of convenience so that rather than doing this

gnuplot> set samples 101
gnuplot> plot [0:100] log(floor(x+0.5)!)

one could type the following and not get a complaint

gnuplot> plot [0:100] log(x!)
         factorial (!) argument must be an integer

[Note, if there is some rounding error from an internal computation of the sample points, e.g., 1.0000000001 gnuplot should still complain, but in most reasonable limit choices I doubt that will happen.]

...

Also, just curious.  I'm not familiar with any type of factorial for negative integers.  If there is, I've not heard of it.  (There's the gamma function and all, but that technically isn't the definition of factorial for negative integers.)  Should gnuplot be giving this kind of result?

gnuplot> print -3!
-6.0

Dan

Re: no duplicated lines for GNU readline history

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

>> The patch needs one more improvement: if the "line" is found in the command
>> history, it must be moved from its old location in the history into the head
>> ... to be immediately available by a single press of the "up arrow" key.
>> Can you please update it?
>
> Not sure if attachments get through to the list, but to be sure to keep
> tabs this time I attached the new patch to the sf.net patch tracker
> instead, #1498727 or
> http://sf.net/tracker/index.php?func=detail&aid=1498727&group_id=2055&atid=302055

Thanks, it works well -- now, both gnuplot and GNU readline behave 
similarly. I've put to sf an updated patch (diff -u) because there were 
still troubles with blanks.

I'll submit the patch to cvs, unless there are some other comments.

---
PM

Re: no duplicated lines for GNU readline history

[Peter W. <pe...@we...>]

Petr Mikulik wrote:
>> the change required is really simple (I think), see the small patch below.
>> However, this might confuse some people who are used to different
>> behavior in their normal command line shell. Is there a way to let the
>> user choose the behavior in gnuplot?
> 
> I would let only the new behaviour, as gnuplot history.
> 
>> --- src/command.c.orig  2006-05-31 19:05:57.000000000 +0200
>> +++ src/command.c       2006-05-31 19:05:46.000000000 +0200
>> @@ -2380,16 +2380,12 @@
> 
> Thanks ... but for some reason, it gets rejected (tabs vs spaces?)

Yeah, that's why tabs are bad... :-)

> The patch needs one more improvement: if the "line" is found in the command 
> history, it must be moved from its old location in the history into the head 
> ... to be immediately available by a single press of the "up arrow" key.
> Can you please update it?

Done.

Not sure if attachments get through to the list, but to be sure to keep
tabs this time I attached the new patch to the sf.net patch tracker
instead, #1498727 or
http://sf.net/tracker/index.php?func=detail&aid=1498727&group_id=2055&atid=302055

   Peter.

Re: no duplicated lines for GNU readline history

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

> the change required is really simple (I think), see the small patch below.
> However, this might confuse some people who are used to different
> behavior in their normal command line shell. Is there a way to let the
> user choose the behavior in gnuplot?

I would let only the new behaviour, as gnuplot history.

> --- src/command.c.orig  2006-05-31 19:05:57.000000000 +0200
> +++ src/command.c       2006-05-31 19:05:46.000000000 +0200
> @@ -2380,16 +2380,12 @@

Thanks ... but for some reason, it gets rejected (tabs vs spaces?)

The patch needs one more improvement: if the "line" is found in the command 
history, it must be moved from its old location in the history into the head 
... to be immediately available by a single press of the "up arrow" key.
Can you please update it?

---
PM

Re: defined

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

On Wednesday 31 May 2006 12:24 am, you wrote:
> 
> In the code is a redundant a.type = 0;

Noted.  It's a debugging patch, not a final version.
 
> The one issue is if somewhere an argument is passed in for 
> which a.type was never set to INTGR CMPLX or STRINGS but 
> neither is it a variable that had gone through PUSHV.

That cannot happen. The expression evaluation code screams
loudly if any type other than those 3 is set.

> Is this the strange case you are talking about?
> gnuplot> print defined(cos(x))
>          unknown type in real()

Yeah. That is what happens if a type other than INTGR/CMPLX/STRING
makes it through to the expression evaluation code.

> [proposal to add BOOLVAR as an enum DATA_TYPE
The problem with this is that it requires changing every single
routine in the expression evaluation chain, or at least confirming
that a correct default case has been set.  I had to do this when
I added the STRING type, and it's a pain.

> I see it is possible to have a function and variable of the same name.

That has always been true.  I don't think we can change it now
without eliciting complaints from HBB about breaking backwards
compatibility :-) 


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742