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

_graphics() calls are not consistent here

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

Hi !

While working on my wxwidgets terminal, I have found the following
strange behaviour :

Terminals have two commands _graphics and _text which are designed to
begin and to finish plot commands :

    _graphics
       _move
       _vector
       ...
    _text

This scheme is adapted to mouse so that you can hit <B2> to annotate the
graph, without redrawing it entirely :

    _graphics
       _move
       _vector
       ...
    _text
<B2> clicked
       _move
       _vector
       _put_text
    _text

As you can see, _graphics is not called when <B2> is clicked. The
commands following the click are only drawing a cross and its
coordinates. I conclude that _graphics should clear the plot, and if
_graphics is not called, the plot is completed.

However, when I rotate a pm3d plot with the mouse in my wxwidgets
terminal, and in particular when samples are numerous (tried with set
isosamples 200; splot x**2*y**2 with pm3d), it seems that _graphics is
not always called. Here is what I get by echoing "text" and "graphics"
when the corresponding functions are called when rotating the former
surface :

Graphics
Text
Graphics
Text
Text
Graphics
Text
Graphics
Text
Graphics
Text
Text

And, as a consequence, I can see two plots in the window.
Here is a screenshot to illustrate it : http://tipote.free.fr/wxt10.png

I have digged into the code to see what can trigger such a problem, but
can't find anything suspect... term_start_plot() in term.c is always
started properly, but sometimes doesn't call *term->graphics(). It
implies that term_graphics has not been set to true, which should have
been done right after the last *term->text() call... All those calls are
synchronous, done by a unique thread... How can this happen ?

Can somebody give me a piece of help ? ;-)

Thanks !

Timoth=E9e Lecomte

Suggestions needed for a new command

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

I am still struggling to create 3D plots with properly labeled
axes that intersect at the origin (Bug #1293118).
I have a patchset that mostly fixes things, but there a few missing pieces.

It adds a "zeroaxis" option for the Z axis, an option which has been
inexplicably limited to X and Y. It also tries to avoid printing tics and
labels in a different place from the axis they are supposed to label.

What I am missing is a clean way to do the following:

	set border 0	# turn off border, we'll draw axes instead
	set xzeroaxis
	set yzeroaxis
	set zzeroaxis      <== new command
	set xtics axis nomirror
	set ytics axis nomirror
	set ztics axis nomirror
	set ticslevel YMIN/(YMAX-YMIN)       <== problematic

There are two problems with the "set ticslevel" command.
1) It isn't easy to do in a script, since you don't necessarily
know in advance what are the values of YMIN and YMAX
2) It breaks anyhow if you later change zrange.

I want a new command that does the equivalent of the 8 commands above,
except that it bypasses the existing "set ticslevel" mechanism in
favor of pinning the X/Y plane at Z=0.

It's not clear to me whether this would fit in as a variant of
some existing command, or whether it would need a new one of its own.
Possibilities include

	set view axes
	set zeroaxis {something}
	set axes {<linetype>}

Other suggestions?


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: How about a fresh release ?

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

On Saturday 17 September 2005 09:02 am, Hans-Bernhard Broeker wrote:

> Timoth=E9e Lecomte wrote:
> > I was wondering if it wasn't the good moment to do a fresh release of
> > gnuplot, I mean "gnuplot 4.1".

> The most we could usefully do right now is a general review of open=20
> patches and feature requests, with a view towards making a three-way=20
> decision for each and every one of them:
>=20
> 1) outdated ---> tag as such, and close.
> 2) keeper --> tag 'release-critical', integrate in good time, then close
> 3) later --> tag 'later', keep open

That would be valuable in any case. =20
Should we do this by adding comments to the tracker page, or by starting
a thread here on the mailing list, or maintaining a separate status file,
or what?


I seems to me that the major blobs of post-4.0 code have already gone
into cvs.  We could declare a moratorium on major new stuff, and enter
a stabilization/bugfix mode starting now.  Following the model of the
4.0 release, that would mean

 - making a development snapshot available for use in more wide-spread
   testing and bug spotting.  Last time it was the "3.8j" snapshot.

 - triage of the current list of bug reports and feature requests

 - policy decisions on which if any of the current patchsets would be
   acceptable for inclusion in the next release. Anything that doesn't
   make the cut will still remain active as a patchset; it just won't
   go out as part of 4.2

 - some months of fielding bug-reports and platform-specific problems

 - when those seem to have tapered off, a push to the actual release


We followed approximately this sequence last time around:

 Discussion started about June 2003.

 Snapshot 3.8j was put out in Aug 2003; we agreed at that time to
 institute a feature-freeze, with the major pending patchsets held for
 post-V4 inclusion. Amazingly enough, we actually stuck to that.
 The histograms, datastrings, and image mode patchsets were held back
 even though in they were arguably ready to go.

 A lot of debugging followed, with x11 and script interaction needing
 the most attention.  I *hope* nothing is equivalently problematic
 this time around, but we won't know until we try.

 Snapshot 3.8k, labelled "release candidate" was put out in Feb 2004.

 Official release of 4.0 was April 2004, or 7 months after the=20
 feature freeze.

If we agree on a major feature freeze now, put up a snapshot soon-ish,
and things play out as before, that would mean a 4.2 release in the
May/June 2006 timeframe.  Does that sound reasonable to everyone?

> I'd have to be the one to do it, and I don't see where I could
> steal the time for that right now. Last time took about us 6 weeks
> of preparation, the last two of them nearly full-time on my end of things.

Understood. But the front end of the process is primarily a matter
of discussion and agreement of what goes in and what doesn't.=20
That 6-week marathon is way off in the cloudy future of next year :-)

Also, wasn't a good bit of your effort at that time devoted to some
last-minute coding issues like TBOOLEAN and ANSIfication? If we do
this right, we should get any such issues out of the way *before* any
last minute push for release.


=2D-=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: gnuplot cvs source bug

[BBands <bb...@ya...>]

--- Petr Mikulik <mi...@ph...> wrote:
> Python works like gnuplot:
> 
> Python 2.3.4 (#1, Feb  7 2005, 15:50:45)
> [GCC 3.3.4 (pre 3.3.5 20040809)] on linux2
> Type "help", "copyright", "credits" or "license" for
> more information.
> >>> print 5/2
> 2
> >>> print 5//2
> 2

It does now, but look at this:

C:\Python24>python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> 5/2
2
>>> 5//2
2
>>> from __future__ import division
>>> 5/2
2.5
>>> 5//2
2
>>>

This behavior will become the default with 3.0.

     jab


John Bollinger, CFA, CMT
www.BollingerBands.com

If you advance far enough, you arrive at the beginning.


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: gnuplot cvs source bug

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

Petr Mikulik wrote:
> Python works like gnuplot:
>
> Python 2.3.4 (#1, Feb  7 2005, 15:50:45)
> [GCC 3.3.4 (pre 3.3.5 20040809)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>
> >>> print 5/2
>
> 2
>
> >>> print 5//2
>
> 2

Yes, but AFAIK this behaviour will change with 3.0.  Try:

>>> from __future__ import division
>>> print 5/2
2.5


Juergen

Re: gnuplot cvs source bug

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

> One factor you might want to consider in this regard
> is the increasing use of gnuplot driven by scripts of
> dynamically-typed languages--Python, Perl, Tcl, Ruby,
> PHP... In such cases unexpected results can arise as a
> result of integer division being the default. Perhaps
> adopting a Python-like approach (// for integer
> division) initially driven by a switch (set division
> true|integer) and eventually defaulting to true might
> help.

Python works like gnuplot:

Python 2.3.4 (#1, Feb  7 2005, 15:50:45)
[GCC 3.3.4 (pre 3.3.5 20040809)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print 5/2
2
>>> print 5//2
2

---
PM

Re: gnuplot cvs source bug

[BBands <bb...@ya...>]

Dear Plotters,

One factor you might want to consider in this regard
is the increasing use of gnuplot driven by scripts of
dynamically-typed languages--Python, Perl, Tcl, Ruby,
PHP... In such cases unexpected results can arise as a
result of integer division being the default. Perhaps
adopting a Python-like approach (// for integer
division) initially driven by a switch (set division
true|integer) and eventually defaulting to true might
help.

Best regards,

     jab

John Bollinger, CFA, CMT
www.BollingerBands.com

If you advance far enough, you arrive at the beginning.


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: wxWidgets terminal : locale "C" ?

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

> I also found such a "feature" as I was implementing the same for my
> wxwidgets terminal. When I was playing with double-click, the X11 plot
> appeared in klipper, the kde clipboard handler ! I think that it's a
> feature of the window manager (kwin), but I'm not sure at all...

I've tried to open Konsole and Kate in Blackbox. It behaves as in KDE.

---
PM

Re: wxWidgets terminal : locale "C" ?

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

Petr Mikulik wrote:

>>>> P.S. : by the way, I realised that the "coords to clipboard with
>>>> 2*<B1>"
>>>> doesn't work with the x11 terminal. Is it normal ?
>>>
>>>
>>> Copying to xterm, nedit, gedit works.
>>>
>>> Copying to anything using Qt (thus, any Qt/KDE application) does not
>>> work.
>>> How can this be allowed?
>>
>>
>> You're right, I was pasting to Konsole... but unfortunately I can't he=
lp
>> you to allow this in Qt. (In my wxwidgets terminal, I use the clipboar=
d
>> object, and it just works)
>
>
> I've just filled in a bug report so that "someone" could search for a
> solution.

"Someone" could look in gtk code, to see where's the trick...

>
> Accidentaly, I've found this amazing feature: having double-clicked
> MB1, sequent MB2 copied the cursor position into gvim, but into
> OpenOffice.org it copied png image of the graph! What's the magics
> behind??
>
> ---
> PM

I also found such a "feature" as I was implementing the same for my
wxwidgets terminal. When I was playing with double-click, the X11 plot
appeared in klipper, the kde clipboard handler ! I think that it's a
feature of the window manager (kwin), but I'm not sure at all...

Timoth=E9e

Re: wxWidgets terminal : locale "C" ?

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

>>> P.S. : by the way, I realised that the "coords to clipboard with 2*<B1>"
>>> doesn't work with the x11 terminal. Is it normal ?
>>
>> Copying to xterm, nedit, gedit works.
>>
>> Copying to anything using Qt (thus, any Qt/KDE application) does not
>> work.
>> How can this be allowed?
>
> You're right, I was pasting to Konsole... but unfortunately I can't help
> you to allow this in Qt. (In my wxwidgets terminal, I use the clipboard
> object, and it just works)

I've just filled in a bug report so that "someone" could search for a 
solution.

Accidentaly, I've found this amazing feature: having double-clicked MB1, 
sequent MB2 copied the cursor position into gvim, but into OpenOffice.org it 
copied png image of the graph! What's the magics behind??

---
PM

Re: with image test images

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

> Could somebody send me some more test images for
> gnuplot's 'with image'? The tux image is
> somewhat 'too optimal' for real testing of a
> terminal's image code since its dimensions
> are square and divisible by 8 (128x128).

I'm enclosing one.
There is also another .edf in demo/, but 256x256.

Petr

with image test images

[Bastian M. <bma...@we...>]

Could somebody send me some more test images for
gnuplot's 'with image'? The tux image is
somewhat 'too optimal' for real testing of a
terminal's image code since its dimensions
are square and divisible by 8 (128x128).
Thanks, Bastian

--=20
Bastian M=E4rkisch
Physikalisches Institut, Universit=E4t Heidelberg

Re: plot perspective

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

> On Wed, Sep 14, 2005 at 09:23:51AM -0700, William Estrada wrote:
> >  How can I make gnuplot produce a 3D plot with true prespective.  By
> > that I mean that X, Y and Z
> > all relate to each other.  The scale of X, Y and Z are the same.
>
>     I am not sure what you mean. If you simply want to change the aspect
> ratio of the plot, you should have a look at the "help size"
> documentation page. If you are looking for a true perspective view
> (parallel lines meet at the horizon), then this is not currently
> implemented. We are working on enhancing the 3D engine of Gnuplot so
> this might happen one day, but currently the work isn't happening very
> quickly.

Actually, there is a patch at SourceForge doing exactly that.  But I
don't think this is what the OP asked for.


Juergen

Re: plot perspective

[V. <gae...@no...>]

On Wed, Sep 14, 2005 at 09:23:51AM -0700, William Estrada wrote:
>  How can I make gnuplot produce a 3D plot with true prespective.  By=20
> that I mean that X, Y and Z
> all relate to each other.  The scale of X, Y and Z are the same. =20

    I am not sure what you mean. If you simply want to change the aspect
ratio of the plot, you should have a look at the "help size"
documentation page. If you are looking for a true perspective view
(parallel lines meet at the horizon), then this is not currently
implemented. We are working on enhancing the 3D engine of Gnuplot so
this might happen one day, but currently the work isn't happening very
quickly.

--
    Ga=EBl

Re: wxWidgets terminal grows up

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

Ethan A Merritt wrote:

>On Saturday 24 September 2005 02:14 pm, Timoth=E9e Lecomte wrote:
> =20
>
>>I have just sent a new patch which implements a wxwidgets terminal for
>>gnuplot.
>>Hope you will have fun with this release, and thanks for your interest.
>>   =20
>>
>I'm just trying this out for the first time.
>I'll type in my thoughts as I go....
> =20
>
Thanks for testing it !

>- Configures and builds with no problem.
>
>- Unfortunately, the x11 terminal doesn't work unless I "unset mouse".
>  Something in the new code must conflict with the x11 mousing protocol.
> =20
>
Ok I read your next mail and I feel better now as it's not my fault ;-)

>- "set term wx" works
>
>- "test" looks good, except:
>	+ polygon is not colored
> =20
>
I know it, but have not digged much to know where it comes from. The
command _set_color() does its job quite well for a pm3d plot, but
doesn't seem to be called in "test". Maybe _linetype should also affect
polygon color.

>	+ rotated text is illegible
> =20
>
Could you provide a screenshot ? On my box I find it far more legible
than the way x11 renders it. Make your own opinion here :

http://tipote.free.fr/wxt4.png (taken some weeks ago, but rotated text
didn't changed)
http://tipote.free.fr/x11-1.png

>	+ text width is not accurately estimated
> =20
>
It's true, and I don't understand yet why. The string I use to test font
width is exactly the one drawn here : 12345678901234567890

>	+ Point styles 6 + 7 really should be an open and closed
>	  circle, respectively
> =20
>
Points are drawn thanks to the generic do_point() provided by gnuplot.
Do I lack something else ?
The term/README says it is enough, but obviously it doesn't draw filled
symbols.

>- "simple.dem" looks good
> =20
>
Ok.

>- "rgb_variable.dem"
>	+ Cannot rotate 3D plot using mouse or cursor keys while
>	  the main program is in "pause -1"
>
You're right. The main thread is waiting for input from the user, and doe=
sn't process gui events sent by the terminal. I need to rework it.

>	+ Requested point style (filled circle) not available
> =20
>
It's related to "test" above.

>	+ Text and points are not colored.
> =20
>
Indeed, I should look at it.

>- after "Control-C" to return control to the main terminal window,
>  it's dead.
>	+ Full terminal reset doesn't help
>	+ Closing the wxterm window doesn't help
>	+ Control-Z doesn't work
>	+ I had to issue "kill -9" from another window in order to
>	  recover use of the original terminal session
> =20
>
I also faced a case where hitting "ctrl-c" makes me lose keyboard input
in the gnuplot command line, and "kill [gnuplot pid]" closes gnuplot
cleanly. Maybe ctrl-c means somethings particular for the wxwidgets
toolkit. I will note it in my bug list !

>- "surface1.dem"
>	+ looks good, but still cannot rotate the plot interactively
>	+ PM3D surface looks good
>	+ the very last plot of the demo looks fine to begin with
>	+ now that control has returned to the main window I can rotate
>	  interactively, but as soon as I do the plotted figure degrades
>	  to some low-resolution grid.  I can't think what would cause this.
> =20
>
'surface1.dem' ends with 'reset', which seems to reset isosamples to its
default value. If you hit 'set isosamples 60' you'll get back the full
resolution plot. The same happens with the x11 terminal.

>- "surface2.dem"
>	+ looks fine up to the last plot, but if I hit "Ctrl-C" at that
>	  point the program segfaults
> =20
>
Indeed, I also get glibc errors when hitting ctrl-c... Strange...

>- "rainbow.dem"
>	+ The lines are colored, but the colors are wrong. Looks like
>	  explicit color settings are ignored
> =20
>
Right. It uses linetype colors. Will fix it.

>- "polar.dem"
>	+ Oops, I forgot to say "reset". Hit control-C to return to command
>	  line.  Terminal is dead again, and session has to be externally
>	  "kill -9"ed.  This is an annoying bug.
> =20
>
Ok, I face exactly the same bug.

>	+ Start again. Works fine.
>
>- "enhancedtext.dem"
>	+ Works nicely except that it doesn't find a Symbol font.
>	  How/where does the wx terminal find its fonts?
> =20
>
In fact, at least on my box, it finds the Symbol font, but refuses to
show characters > 127, as I get "mu" and "pi" correctly drawn but not
"infinite" and "sum". I think it's a wxwidgets bug, as the wxwidgets
font sample has the same problem. The recent 2.6.2 release contains a
line about fonts and gtk on its changelog, so it may have been solved,
but I have not tested yet.

>- "fillstyle.dem"
>	+ Uh oh. Problems here. Aside from the fact that the boxes are
>	  all black, the lower bound of each rectangle is incorrect.
>	  The must be a bug or two in the fillbox and/or filled_polygon
>	  driver routines.
> =20
>
I saw it but completely forgot to fix it. It comes from some changes
regarding the way I handle coordinates between gnuplot and wxwidgets.

>- "test"
>	+ Hey! This time I get a red polygon. It was black before.
>	  (It's supposed to be blue :-).  Repeated trials turn up pink
>	  and purple, also.  Random colors?
> =20
>
Not random ;-) probably based on the last _set_color() call in a
previous plot...

>- "image.dem"
>	+ OK
>
>- "set term wxt 2"
>	+ I thought maybe I could get a second window. But no, instead the
>	  program hangs.
> =20
>
I have not implemented it yet. However, the program does not hang for
me, but just gives 'unrecognized terminal option'.

>General comments:
>
>- Looks very promising.=20
>
>- The incompatibility with x11 is obviously a problem, but I assume it's
>  fixable.
>
And you've fixed it ;-)

>The failure to handle control-C properly is quite annoying, as
>  is the inability to rotate 3D plots while in a "pause" command.
> =20
>
Right, those are really problems. I will try to isolate the problems.

>- The "zoom" and "unzoom" icons are totally non-intuitive, at least to
>  me.  They look like the "cancel last edit" and "redo last edit" icons
>  from some word processing programs.
>
I admit this. Maybe it could be more intuitive with comprehensive zoom
icons. In all cases I will rework those with a magnifier.

>Also the clipboard icon looks like
>  a "new document" icon - how about using a little clipboard?
> =20
>
In fact, the 'two pages' icon is the standard for 'copy', and the one
with a clipboard is often used for 'paste', but as we only have one of
these, the second one is clearer.

>- What are the possibilities for multiple plot windows?
>
In my opinion, it's just a matter of coding ;-) but there is no
limitation from wxwidgets.

I'm really pleased that you tried it and took the time to report me all
these problems. I will try to fix them, and to implement things that are
lacking.

Regards,

Timoth=E9e Lecomte

Re: wxWidgets terminal grows up

[<ds...@ch...>]

> From: Timoth=E9e Lecomte <tim...@en...>
>
> I have just sent a new patch which implements a wxwidgets terminal for
> gnuplot.
>
> This new version adds image support, and you can find a screenshot at
> this adress :
> http://tipote.free.fr/wxt9.png

Cool!  :-)

> Finally, I wrote a menu entry and a dialog to set the ranges. I would b=
e
> pleased to have your point of view regarding such dialogs. I'm not sure
> it's really a good idea as it hides some interesting and powerful
> options that are available with the command line.

One tester found several bugs.  Before adding long lists of menu options,=
 making the code robust would be a better endeavor.

Dan

Re: wxWidgets terminal grows up

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

On Saturday 24 September 2005 04:46 pm, Ethan A Merritt wrote:
>
> - Unfortunately, the x11 terminal doesn't work unless I "unset mouse".
>   Something in the new code must conflict with the x11 mousing protocol.

Never mind. Entirely my mistake. I must have mistyped my usual test
command  "setenv GNUPLOT_DRIVER_DIR ."  
The patched version has no problem with x11 and mousing if
properly configured.

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

Re: wxWidgets terminal grows up

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

On Saturday 24 September 2005 02:14 pm, Timoth=E9e Lecomte wrote:
> I have just sent a new patch which implements a wxwidgets terminal for
> gnuplot.
> Hope you will have fun with this release, and thanks for your interest.

I'm just trying this out for the first time.
I'll type in my thoughts as I go....

=2D Configures and builds with no problem.

=2D Unfortunately, the x11 terminal doesn't work unless I "unset mouse".
  Something in the new code must conflict with the x11 mousing protocol.

=2D "set term wx" works

=2D "test" looks good, except:
	+ polygon is not colored
	+ rotated text is illegible
	+ text width is not accurately estimated
	+ Point styles 6 + 7 really should be an open and closed
	  circle, respectively

=2D "simple.dem" looks good

=2D "rgb_variable.dem"
	+ Cannot rotate 3D plot using mouse or cursor keys while
	  the main program is in "pause -1"
	+ Requested point style (filled circle) not available
	+ Text and points are not colored.

=2D after "Control-C" to return control to the main terminal window,
  it's dead. =20
	+ Full terminal reset doesn't help
	+ Closing the wxterm window doesn't help
	+ Control-Z doesn't work
	+ I had to issue "kill -9" from another window in order to
	  recover use of the original terminal session

=2D "surface1.dem"
	+ looks good, but still cannot rotate the plot interactively
	+ PM3D surface looks good
	+ the very last plot of the demo looks fine to begin with
	+ now that control has returned to the main window I can rotate
	  interactively, but as soon as I do the plotted figure degrades
	  to some low-resolution grid.  I can't think what would cause this.

=2D "surface2.dem"
	+ looks fine up to the last plot, but if I hit "Ctrl-C" at that
	  point the program segfaults

=2D "rainbow.dem"
	+ The lines are colored, but the colors are wrong. Looks like
	  explicit color settings are ignored

=2D "polar.dem"
	+ Oops, I forgot to say "reset". Hit control-C to return to command
	  line.  Terminal is dead again, and session has to be externally
	  "kill -9"ed.  This is an annoying bug.
	+ Start again. Works fine.

=2D "enhancedtext.dem"
	+ Works nicely except that it doesn't find a Symbol font.
	  How/where does the wx terminal find its fonts?

=2D "fillstyle.dem"
	+ Uh oh. Problems here. Aside from the fact that the boxes are
	  all black, the lower bound of each rectangle is incorrect.
	  The must be a bug or two in the fillbox and/or filled_polygon
	  driver routines.

=2D "test"
	+ Hey! This time I get a red polygon. It was black before.
	  (It's supposed to be blue :-).  Repeated trials turn up pink
	  and purple, also.  Random colors?

=2D "image.dem"
	+ OK

=2D "set term wxt 2"
	+ I thought maybe I could get a second window. But no, instead the
	  program hangs.

General comments:

=2D Looks very promising.=20

=2D The incompatibility with x11 is obviously a problem, but I assume it's
  fixable.  The failure to handle control-C properly is quite annoying, as
  is the inability to rotate 3D plots while in a "pause" command.

=2D The "zoom" and "unzoom" icons are totally non-intuitive, at least to
  me.  They look like the "cancel last edit" and "redo last edit" icons
  from some word processing programs.  Also the clipboard icon looks like
  a "new document" icon - how about using a little clipboard?

=2D What are the possibilities for multiple plot windows?

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

wxWidgets terminal grows up

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

Hello !

I have just sent a new patch which implements a wxwidgets terminal for
gnuplot. Here's the url of the developpement page :

http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1267434&grou=
p_id=3D2055&atid=3D302055

This new version adds image support, and you can find a screenshot at
this adress :
http://tipote.free.fr/wxt9.png

It also gets 4 functional icons on the toolbar :
- three of them corresponds to already existing hotkeys (toggle grid,
previous and next zoom),
- the fourth copies the plot to the clipboard.

Finally, I wrote a menu entry and a dialog to set the ranges. I would be
pleased to have your point of view regarding such dialogs. I'm not sure
it's really a good idea as it hides some interesting and powerful
options that are available with the command line.

Hope you will have fun with this release, and thanks for your interest.

Timoth=E9e Lecomte

Re: Re: gnuplot cvs source bug

[<ds...@ch...>]

> On Fri, 2005-09-23 at 17:24 -0400, ds...@ch... wrote:
> 
> > But yeah, int(...) of this and float(...) of that scatter about the scripts is nasty and unnecessary.
> 
> You say "scatter about the scripts" like there are lots of occasions
> that an integer result would be required. 

Scattered doesn't mean a lot, it means occassional occurrence here and there--rare to the point of easily overlooking.  (In principle no different than having decimal points scattered about.)

> This seems to be a matter of personal taste,

Not taste, but convenience.  I admit I don't use integer math in gnuplot right now, but I do work in a field where integer math is common, e.g., sample rates, filtering, etc.

What I'm saying is don't toss out the integer math behavior.  I could imagine someone using it...

> but I think being explicit
> like that is much more obvious than going with the presence/absence of
> a .0 after a numeric literal.

... but I agree that treating all numbers as floats is probably more common.

My vote would be to keep the integer mechanism with the option of casting everything to floats via "treat_all_numbers_as_floats" variable, which is on by default.

Dan

Re: gnuplot cvs source bug

[Harald H. <h.h...@tu...>]

On Sat, 24 Sep 2005, Ga=EBl Varoquaux wrote:

>     So far I haven't expressed my opinion on that subject, and I don't
> what to add wood to the flame, but I must say that I am strongly opposed
> to 1/2 !=3D 1/2.0 . This just make gnuplot hermetic to non coders. It als=
o
> makes it behave differently then octave and matlab, and most scientific
> programs.

I am a coder, but I also think that 1/2 should be equal to 1/2.0. Since
gnuplot does not provide explicit variable types you always have to use
hacks to make sure that you use floats, e.g. f(a,b)=3Da/(1.0*b). This often
leads to bugs in gnuplot scripts. What about Pascal syntax:

float =3D a/b
int =3D a div b

Best regards
Harald

--=20
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: gnuplot cvs source bug

[V. <gae...@no...>]

    So far I haven't expressed my opinion on that subject, and I don't
what to add wood to the flame, but I must say that I am strongly opposed
to 1/2 !=3D 1/2.0 . This just make gnuplot hermetic to non coders. It als=
o
makes it behave differently then octave and matlab, and most scientific
programs.

--
    Ga=EBl

Re: gnuplot cvs source bug

[Robert H. <en...@no...>]

On Fri, 2005-09-23 at 11:34 -0700, Ethan Merritt wrote:
> On Friday 23 September 2005 07:19 am, Robert Hart wrote:
> > 
> > Yes, but we are talking about a situation where floats *do* apply.
> > Surely it is more logical to treat numbers as floats *unless* they are
> > used in a context where only integers apply. For any ambiguous case
> > (division and exponentiation), anybody who wants the integer math
> > *knows* they want it and can use int()
> 
> I happen to disagree.  Integer arithmetic is quite useful in many
> contexts, and it is a standard part of programming languages and
> natural languages.  Adding peculiar arithmetic operators to indicate
> that a number is an integer strikes me as being an obfuscation, not
> a clarification.  Sure, sometimes even an experienced user will 
> forget, and mistype  (n/2) where it should have been (n/2.0).
> But also people type "if (a = b)" where it should have been
> "if (a == b)" or "if (a eq b)". Hiding this useful distinction
> in a choice of operators is not likely to reduce the number of
> mistakes.

Firstly gnuplot is not a programming language, it is a scientific
plotting utility. I think that is an important distinction in itself.

Secondly, the typical user is neither a programmer or "experienced",
they are simply somebody who wants to create plots with the minimum
fuss. If they are experienced in something, it may well be spreadsheets
- in fact a spreadsheet may be the last application they used before
switching to gnuplot.

I realise at the end of a day this is a issue of background, and that
people like me who are used to basic, perl and excel think differently
to the FORTRAN, C, and bash people in the world, but if the situation
were reversed I don't think you'd get people reporting it as a bug that
1/2=0.5, because they'd just say "oh uh, I meant int(1/2) then"

Just my $0.02.
-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: Re: gnuplot cvs source bug

[Robert H. <en...@no...>]

On Fri, 2005-09-23 at 17:24 -0400, ds...@ch... wrote:

> But yeah, int(...) of this and float(...) of that scatter about the scripts is nasty and unnecessary.

You say "scatter about the scripts" like there are lots of occasions
that an integer result would be required. 
This seems to be a matter of personal taste, but I think being explicit
like that is much more obvious than going with the presence/absence of
a .0 after a numeric literal.

Rob

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: gnuplot cvs source bug

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

On Friday 23 September 2005 23:24 ds...@ch... wrote:
> Nothing Ethan said seems to rule out the "treat all numbers as
> floats"/"treat non-decimal point numbers as ints" variable that someone
> else suggested.  It is something that could be put in the gnuplot startup
> file for those who want gnuplot always to treat numbers as floats even
> immediately after launch.

Such settings tend to be forgotten.  So scripts get unportable for
nonobvious reasons.  And---probably worse---support in these
questions becomes more difficult.

> But yeah, int(...) of this and float(...) of that scatter about the scripts
> is nasty and unnecessary.

ACK.


Juergen