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

Re: An observation in animate demo.

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

Hans-Bernhard Broeker wrote:

>On Fri, 7 May 2004, Daniel J Sebald wrote:
>
>  
>
>>gnuplot> load 'animate.dem'
>>    
>>
>[...]
>  
>
>>Then at that point hit return and the demo starts... and zooms by 
>>quickly.  But if I hit return once again in the middle of the demo it 
>>will slow down its redraw rate significantly.
>>    
>>
>
>What platform?  Unix/X11 I presume?
>

Right.

>I think that's the same old X11 multiple-stream handling problem again.
>

Oh.  I wasn't aware of that one.  But that sounds about right.

Dan

Re: Making demo programs more evident...

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

On Sunday 09 May 2004 04:19 pm, Daniel J Sebald wrote:
> >>	Who knows about "make install-strip", and who actually use it?
> >
> >OTOH, HD space is less than 0.01 USD or EUR per MB these days...
>
> Well, that kind of thinking only promotes sloppy computer usage... like
> putting an extraneously high resolution image on a web site. 

My $.02 worth:

I dislike having stripped executables, because if something goes
wrong you get essentially zero information to help you report or
fix the problem.  The small increase in disk space is a minor price
to pay for having debuggable programs.  

Anyone who want to run 'make install-strip' is free to do so, of course,
but I would not like to see it made the default.


-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: Making demo programs more evident...

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

Hans-Bernhard Broeker wrote:

>On Sun, 9 May 2004, Petr Mikulik wrote:
>  
>
>>=> ordinary people (who do just "make install" have no demos avaible).
>>    
>>
>
>  
>
>>INSTALL writes ./configure does not want to decide where to put demos --
>>why not?
>>    
>>
>
>INSTALL says so, and it's written in there for said "ordinary people" to
>see.  So they'll know there are demos they may want to install, at a place
>of their choosing.  
>
>We can't do anything to help people who won't read README and INSTALL
>files, and there's really no point trying.
>
>>/usr/local/share/gnuplot/... gnuplot is already writing there, why not use
>>it for demo?
>>    
>>
>
>That would be the right place for them to go for a non-RPM local
>installation from sources.  I.e. if we make a "install-demos" target, or
>have the default 'install' put them up anywhere, $(pkgdatadir)/demo is 
>where that'll be.  
>
>But it's not the place the existing binary packages made by third parties
>put them.  SuSE Linux, e.g., puts such files below
>/usr/share/docs/packages/<name>, not /usr/share/<package>, and they may
>prefer to keep it that way.  But since there's no
>/usr/local/share/docs/packages in a Linux system, we can't easily
>duplicate that, and probably we shouldn't.
>
>And remember that as soon as we put a pointer to the locally installed
>copy of the demos into the online help, odds are distributors will manage
>to break it.  But it'll likely be us who get the complaints about it.
>

I was going to say that the distributor/packager or whatever can move 
them to where ever they want.  But point taken.

I think the additional method requiring installing demos isn't so bad. 
 That is, a separate "make install-demos" which would require some 
interaction (i.e., specifying the exact directory, the "make 
install-demos" would automagically define GNUPLOT_LIB and add the demo 
directory to it) would be something only run by the distributors.  The, 
eh-hem, "non informed people" could then still type "make, make install" 
and hope for the best, i.e., watch the pretty glowing characters wiz by. 
 Then at the very end of the "make install" after the message indicating 
everything is hunky-dory, there could be a message noting the existence 
of demo scripts that can be installed.

Well, in any case, if a message in the INSTALL file were to do, perhaps 
add a GNUPLOT_LIB comment.

   The gnuplot demo files are not installed by default, mainly because
there is no universally agreed place where such files should go.
If desired, they should be copied manually to a location of choice.
(add this) Including the chosen demo directory in the global variable path
GNUPLOT_LIB (see below) will allow easy access for all users
to the demo script files.


>>BTW, "make install" installs big unstriped binaries, even for the final
>>gnuplot 4.0.0. It's not polite for harddisks of our users. I hope no other
>>app do that!
>>	Who knows about "make install-strip", and who actually use it?
>>    
>>
>
>Those people who care, know.  Those who build RPMs at distributors
>included.  OTOH, HD space is less than 0.01 USD or EUR per MB these
>days...
>

Well, that kind of thinking only promotes sloppy computer usage... like 
putting an extraneously high resolution image on a web site.  I will use 
"install-strip" from now on if I remember.

>It might make sense to mention install-strip in the INSTALL document.
>

I assume that non-stripped is the default because developers want to do 
debugging?  And they don't want to have to be constantly typing the 
"make install-debug" or something similar.  How about a global variable 
for controlling this?  That is,

install-stripped:  same as current "install-stripped" behavior
install-debug:  same as current "install" behavior
install:  Include debugging information according to a global variable 
GNUPLOT_DEBUG; i.e., defined then include debug info, if not (default) 
then don't include debug info.  For developers, define GNUPLOT_DEBUG 
once and that is it.

Dan

Re: An observation in animate demo.

[Hans-Bernhard B. <br...@ph...>]

On Fri, 7 May 2004, Daniel J Sebald wrote:

> gnuplot> load 'animate.dem'
[...]
> Then at that point hit return and the demo starts... and zooms by 
> quickly.  But if I hit return once again in the middle of the demo it 
> will slow down its redraw rate significantly.

What platform?  Unix/X11 I presume?

I think that's the same old X11 multiple-stream handling problem again.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Making demo programs more evident...

[Hans-Bernhard B. <br...@ph...>]

On Sun, 9 May 2004, Petr Mikulik wrote:

> Hmm on "unix" .. "make install" does not install demos, so there is not
> "properly" installed unix. 

As far as I'm aware, none of our makefiles installs the demos anywhere.  
Nor did any of them, ever.

> Using a rpm package for gnuplot ... turns you to demos for an old
> gnuplot.

Huh? That only applies if you look at an old, now outdated RPM, obviously.  
There'll be only *one* binary RPM of gnuplot installed in any given box.  
So far, that'll be the one of 3.7.3 made by the distributor, so yes, it
will have the old version of the demos.

> => ordinary people (who do just "make install" have no demos avaible).

> INSTALL writes ./configure does not want to decide where to put demos --
> why not?

INSTALL says so, and it's written in there for said "ordinary people" to
see.  So they'll know there are demos they may want to install, at a place
of their choosing.  

We can't do anything to help people who won't read README and INSTALL
files, and there's really no point trying.

> /usr/local/share/gnuplot/... gnuplot is already writing there, why not use
> it for demo?

That would be the right place for them to go for a non-RPM local
installation from sources.  I.e. if we make a "install-demos" target, or
have the default 'install' put them up anywhere, $(pkgdatadir)/demo is 
where that'll be.  

But it's not the place the existing binary packages made by third parties
put them.  SuSE Linux, e.g., puts such files below
/usr/share/docs/packages/<name>, not /usr/share/<package>, and they may
prefer to keep it that way.  But since there's no
/usr/local/share/docs/packages in a Linux system, we can't easily
duplicate that, and probably we shouldn't.

And remember that as soon as we put a pointer to the locally installed
copy of the demos into the online help, odds are distributors will manage
to break it.  But it'll likely be us who get the complaints about it.

> BTW, "make install" installs big unstriped binaries, even for the final
> gnuplot 4.0.0. It's not polite for harddisks of our users. I hope no other
> app do that!
> 	Who knows about "make install-strip", and who actually use it?

Those people who care, know.  Those who build RPMs at distributors
included.  OTOH, HD space is less than 0.01 USD or EUR per MB these
days...

It might make sense to mention install-strip in the INSTALL document.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: mouse big cross cursor and hotkeys in "pause mouse"

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

> > As I use the new ginput.m for accessing gnuplot mousing events from
> > Octave, I can see some current "inconvencies". In principle, we would be
> > of advantage to get ginput(n) functionality of Matlab.
>
> I've never used Matlab.  Perhaps you could cut-and-paste a man page
> description of ginput(n) so that I know what you have in mind?

See
http://www.mathworks.com/access/helpdesk/help/techdoc/ref/ginput.html


In summary, it returns mouse position (x,y) and which mouse button was
clicked (1, 2, 3 from left) or ASCII number if key on the keyboard was hit,
at that position.


> > B. Mousing hotkeys (including those "hardcoded" to x11 like "q" and
> > "space") should be disabled during "pause mouse".
>
> Why would you want to do that?

From Octave, I run 3 instances of gnuplot. The main one draws a map. I do
"infinitely" 'pause mouse' and analyze key or mouse: if 'h' pressed => draw
horizontal section through the map in 2nd gnuplot, 'v' for vertical in 3rd
gnuplot, 'q' get off the loop.

> I should think it would be useful to be able to zoom, unzoom, and rotate
> during mouse mode.  Same for the space key.

Sometimes yes, sometimes not => that's why my proposal for
	pause mouse key

will pause until mouse click or key press, with gnuplot default hotkeys
being switched off.


> If you want character input rather than mouse coordinates, then
> why are you issuing a 'pause mouse' command in the first place?

I want to know the key pressed in x11 graph.


> You want a way to back out of a 'pause mouse' command without
> actually sending mouse coordinates, is that right?

No, I want them too.

> Would it be sufficient to activate a SIGINT handling routine for the
> plot window during pause mouse, so that you can type ctrl-C in it?

Obviously no.


> > - x11_set_cursor(), pm_set_cursor() etc. should be changed from
> >
> > 	term_set_cursor(int type, int x, int y)
> > to
> > 	term_set_special(int what, int option, int x, int y)
>
> Those are functionally equivalent, aren't they?

Currently only for what==TERM_SPECIAL_SETCURSOR

> Your first pair of examples below use an extra parameter, but it doesn't
> gain anything other the second pair.
> > term->set_special(TERM_SPECIAL_HOTKEYS, 1, 0, 0)  // enable hotkeys
> > term->set_special(TERM_SPECIAL_HOTKEYS, 0, 0, 0)  // disable
> > term->set_special(TERM_SPECIAL_RAISE, 0, 0, 0)  // used by "raise" and
> > term->set_special(TERM_SPECIAL_LOWER, 0, 0, 0)  // "lower" commands

The main idea is to avoid plenty of new x11/pm/win API functions in x11.trm,
pm.trm, win.trm, rather than adding a new integer (command) into a table of
interactive terminal functions.

=> support for commands "raise", "lower", "setcursor", "switch hotkeys" etc.
would be done without touching x11.trm, pm.trm etc -- just add one #define
TERM_SPECIAL_BLA into a common .h file, and implement the catch for this
TERM_SPECIAL_BLA in gclient.c, gplt_x11.c or ... (and if not implemented,
then it is silently ignored).


I hope I made it more clear now.

---
PM

Re: Making demo programs more evident...

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

> It may be nice to make more apparent the existence of the demo programs.
> The demos are on the web page now, which is great.  However, I'm
> thinking from the perspective of a new user like a student in an
> academic environment.  The demos are an eye-opener when it comes to the
> initially arcane command line interface, yet I think a new user who
> doesn't have super user privilege may never realize there are some nice
> demos that would really help in the learning curve.  Maybe a "help demo"
> or "help demos" would be nice to explain how to access the scripts.

That's good idea. Put 'help demo' into gnuplot docs, with link to web, and
to how to running from a properly installed gnuplot.

Hmm on "unix" .. "make install" does not install demos, so there is not
"properly" installed unix. Using a rpm package for gnuplot ... turns you to
demos for an old gnuplot.
=> ordinary people (who do just "make install" have no demos avaible).

INSTALL writes ./configure does not want to decide where to put demos -- why
not?

/usr/local/share/gnuplot/... gnuplot is already writing there, why not use
it for demo?


BTW, "make install" installs big unstriped binaries, even for the final
gnuplot 4.0.0. It's not polite for harddisks of our users. I hope no other
app do that!
	Who knows about "make install-strip", and who actually use it?

---
PM

timefmt does not have provision for milliseconds

[Vijayaraj AK <vij...@ya...>]

Dear Sir/Madam,

I was using GNU for plotting function and I wanted to
plot time in hour:min:sec:millisecond format. I
searched extensively for this kind of format. If this
is not defined it would be incredibly useful to have
such a format in future release.

Thanks!
Vijay

=====
Vijayaraj A.K.          
#304, Creekside Apartments,            \\\|///     o00o   
505, 27th WAY,                       \\  - -  //   (  )  
Boulder, CO 80305,                   (   0 0   )  (  )   
USA                             ***oOOo--(_)--*******  
Phone : (R) 303 499 1818
        (O) 303 247 5061                Hello!!


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

Re: cvs version

[Hans-Bernhard B. <br...@ph...>]

On Sat, 8 May 2004, Daniel J Sebald wrote:

> I'm not sure if any changes have been made to CVS since 4.0 release, 

There have.  For now, they're all bugfixes.  

> but the latest I've checked out still is labeled as:
> 
> gnuplot 4.0 patchlevel 0
> 
> It might be wise to change the version to some beta number right away so 
> that the only version that prints out 4.0 is the one tagged 4.0.

I don't quite agree.  People working off CVS sources should know what
they're doing without us needing to remind them by playing with version
numbers.  We'll can crank up the patchlevel immediately before releasing a
new tarball.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

cvs version

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

I'm not sure if any changes have been made to CVS since 4.0 release, but 
the latest I've checked out still is labeled as:

gnuplot 4.0 patchlevel 0

It might be wise to change the version to some beta number right away so 
that the only version that prints out 4.0 is the one tagged 4.0.

Dan

Re: Making demo programs more evident...

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

>
>
>You don't need su for that --- you just need the demo directory itself
>kept somewhere.  And thanks to the GNUPLOT_LIB variable, you don't
>actually have to cd there, either.
>

Yes, GNUPLOT_LIB works nicely.

Dan

Re: demos

[Hans-Bernhard B. <br...@ph...>]

On Fri, 7 May 2004, Daniel J Sebald wrote:

> I notice that the first demo in 'all.dem' is 'simple.dem'.  There is no 
> "reset" at the start of 'simple.dem', 

Actually, most demos have the 'reset' at their end, not their start.
And that's good, because it lets you try some effects by running
them with some settings pre-changed.  

Arguable, the individual demos themselves shouldn't have a 'reset' at all,
but leave it to 'all.dem' to reset betweeen any two of them.

> Is this an issue?  Should demos all have "reset" at the start? 

No. 

> (I think Ethan brought this up once before.)  I suppose that may change
> any setup the user has.

The demos change the setup anyway, so there's really no point being subtle
about it.  Until we get around to implementing a 'push / pop' or other
method of keeping an internal copy of the entire collection of settings,
that is.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

demos

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

I notice that the first demo in 'all.dem' is 'simple.dem'.  There is no 
"reset" at the start of 'simple.dem', so if one types

set parametric
load 'all.dem'

the result is

******************** file simple.dem ********************
         "simple.dem", line 11: parametric function not fully specified

Is this an issue?  Should demos all have "reset" at the start?  (I think 
Ethan brought this up once before.)  I suppose that may change any setup 
the user has.  (Perhaps Hans' idea of capturing the "state" of the 
variables then restoring them after the demos.  That is, each demo would 
have "save state; reset" at the start and "restore state" at the 
beginning.  That may have drawbacks though too, if the demo escapes 
during its run.)

Dan

An observation in animate demo.

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

This is not top priority, but I observe in the animate.dem demo that 
inadvertently typing a <cr> multiple times will cause the screens to 
redraw at two second intervals instead of almost imediately if only one 
<cr> is typed.  That is, type "load 'animate.dem'" and get:

gnuplot> load 'animate.dem'
On some screen terminal drivers for PC screens, you'll have
to hit a key to get to the next frame
Press a key to start the rotation...

Then at that point hit return and the demo starts... and zooms by 
quickly.  But if I hit return once again in the middle of the demo it 
will slow down its redraw rate significantly.

Is this an undocumented feature?  Or is something strange happening?

Dan

Re: mouse big cross cursor and hotkeys in "pause mouse"

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

On Friday 07 May 2004 01:25 am, Petr Mikulik wrote:
> As I use the new ginput.m for accessing gnuplot mousing events from
> Octave, I can see some current "inconvencies". In principle, we would be
> of advantage to get ginput(n) functionality of Matlab.

I've never used Matlab.  Perhaps you could cut-and-paste a man page
description of ginput(n) so that I know what you have in mind?


> B. Mousing hotkeys (including those "hardcoded" to x11 like "q" and
> "space") should be disabled during "pause mouse".

Why would you want to do that?
I should think it would be useful to be able to zoom, unzoom, and rotate
during mouse mode.  Same for the space key.  

> Solution and functionality: If a hotkey is pressed during "pause mouse",
> then it stops pausing, and set MOUSE_BUTTON=0 and MOUSE_HOTKEY=keycode
> for the key pressed.

I am still not understanding why an application would want to do this.
If you want character input rather than mouse coordinates, then
why are you issuing a 'pause mouse' command in the first place?

Also, if you make 'pause mouse' terminate on key press then you will
become sensitive to the mouse focus settings of your window manager.

> Usage - example: Pressing "q" in gnuplot's terminal window will pass the
> "q" to the caller by MOUSE_HOTKEY, and it may quit mouse tracking and
> evaluation functionality.

You want a way to back out of a 'pause mouse' command without
actually sending mouse coordinates, is that right?
This makes sense to me. Normally you could do this by hitting ctrl-C
in the terminal window, but in a scripted environment that may be
inconvenient. As a matter of ergonomics I wouldn't choose 'q' for this,
however. If people get used to typing 'q' in the plot window they are
going to regret it eventually.

Would it be sufficient to activate a SIGINT handling routine for the
plot window during pause mouse, so that you can type ctrl-C in it?



> - x11_set_cursor(), pm_set_cursor() etc. should be changed from
>
> 	term_set_cursor(int type, int x, int y)
> to
> 	term_set_special(int what, int option, int x, int y)

Those are functionally equivalent, aren't they?  
Your first pair of examples below use an extra parameter, but it doesn't
gain anything other the second pair.
> term->set_special(TERM_SPECIAL_HOTKEYS, 1, 0, 0)  // enable hotkeys
> term->set_special(TERM_SPECIAL_HOTKEYS, 0, 0, 0)  // disable
> term->set_special(TERM_SPECIAL_RAISE, 0, 0, 0)  // used by "raise" and
> term->set_special(TERM_SPECIAL_LOWER, 0, 0, 0)  // "lower" commands


> Could somebody start to implement this?

It does not sound difficult, but I am far from understanding the
the design goal or intended application.  Are you really asking
for a way to type character input into the plot window?

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

Re: Making demo programs more evident...

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

Ethan Merritt wrote:

>On Friday 07 May 2004 11:57 am, Daniel J Sebald wrote:
>
>Dan, 
>
>I assume you are talking about unix-like systems.
>

Yes.

>> But someone who hasn't installed the program, but rather just logs into
>>an account and types "gnuplot" will not know where to go for the demos.
>>    
>>
>
>Surely that is an issue of proper installation.  If the system is properly
>configured, then default the when a user logs in the environmental
>variable GNUPLOT_LIB is set to the demo dir and everything should
>work transparently.    Now admittedly we leave this up to the packagers
>of specific gnuplot variants rather than making it part of gnuplot's own
>"make install" command.  The linux rpms I have seen put the demos
>in /usr/share/doc/gnuplot-VERSION/demo/ so I would expect that 
>when a new user logs in that is what he gets as GNUPLOT_LIB.
>

Oh yes, I see that is where they are.  I've a 3.7 version still hanging 
around.  In any case, GNUPLOT_LIB environment variable is the proper way.

>> Neither will he or she be able to run the complete set of demos if, in
>>fact, they are found... unless they are smart enough to copy the demos
>>to their own account.
>>    
>>
>
>This just isn't true.  Yes, someone with write privilege has to run "make"
>in the demo directory in order to generate some of the data files,
>but that should already have happened at install time.
>

I simply meant that one or two of the demos require gnuplot be launched 
from a directory for which there is write privilege.

>>If a person without su privilege goes to the 
>>directory where the demos are and loads them, at least one demo requires
>>the creation of a file, which will bomb because the user doesn't have
>>privilege to create a file in that directory.
>>    
>>
>
>"Don't do that".   Set your current directory to something normal,
>and set GNUPLOT_LIB to be the directory where the demos are.
>

Right, that is the proper way.  I should have read the INSTALL file all 
the way through.

Thanks,

Dan

Re: Making demo programs more evident...

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

On Friday 07 May 2004 11:57 am, Daniel J Sebald wrote:

Dan, 

I assume you are talking about unix-like systems.

> Here is the thing.  If I have su privilege I can just change to the
> "demo" directory, run "gnuplot", type "load 'all.dem'" and away we go.

I don't understand this.  Why would you have to be superuser to
run the demos?

>  But someone who hasn't installed the program, but rather just logs into
> an account and types "gnuplot" will not know where to go for the demos.

Surely that is an issue of proper installation.  If the system is properly
configured, then default the when a user logs in the environmental
variable GNUPLOT_LIB is set to the demo dir and everything should
work transparently.    Now admittedly we leave this up to the packagers
of specific gnuplot variants rather than making it part of gnuplot's own
"make install" command.  The linux rpms I have seen put the demos
in /usr/share/doc/gnuplot-VERSION/demo/ so I would expect that 
when a new user logs in that is what he gets as GNUPLOT_LIB.


>  Neither will he or she be able to run the complete set of demos if, in
> fact, they are found... unless they are smart enough to copy the demos
> to their own account.

This just isn't true.  Yes, someone with write privilege has to run "make"
in the demo directory in order to generate some of the data files,
but that should already have happened at install time.

> If a person without su privilege goes to the 
> directory where the demos are and loads them, at least one demo requires
> the creation of a file, which will bomb because the user doesn't have
> privilege to create a file in that directory.

"Don't do that".   Set your current directory to something normal,
and set GNUPLOT_LIB to be the directory where the demos are.

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

Making demo programs more evident...

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

It may be nice to make more apparent the existence of the demo programs. 
 The demos are on the web page now, which is great.  However, I'm 
thinking from the perspective of a new user like a student in an 
academic environment.  The demos are an eye-opener when it comes to the 
initially arcane command line interface, yet I think a new user who 
doesn't have super user privilege may never realize there are some nice 
demos that would really help in the learning curve.  Maybe a "help demo" 
or "help demos" would be nice to explain how to access the scripts.

Here is the thing.  If I have su privilege I can just change to the 
"demo" directory, run "gnuplot", type "load 'all.dem'" and away we go. 
 But someone who hasn't installed the program, but rather just logs into 
an account and types "gnuplot" will not know where to go for the demos. 
 Neither will he or she be able to run the complete set of demos if, in 
fact, they are found... unless they are smart enough to copy the demos 
to their own account.  If a person without su privilege goes to the 
directory where the demos are and loads them, at least one demo requires 
the creation of a file, which will bomb because the user doesn't have 
privilege to create a file in that directory.

Dan

(No subject)

[<sch...@me...>]

I would be very grateful if you could help me
with a gnuplot problem. Using splot to plot
a data file with hidden line removal is
very slow.  I am using the following
Cygwin version.  It works fine with 'unset hidd'
and it does work with 'set hidd' but takes very
much longer than than gnuplot 3.7 under either
Linux or MSWindows.  Very much longer
means close to 1 minute when 3.7 takes 1 second.
Is it fixable or is there a Cygwin version of 3.7?

Thanks a lot.

Len Schwartz
Prof. of Mech. Engrg.
Univ. Delaware
        G N U P L O T
        Version 3.8j patchlevel 0
        last modified Wed Nov 27 20:49:08 GMT 2002
        System: CYGWIN_NT-5.1 1.5.9(0.112/4/2)

        Copyright(C) 1986 - 1993, 1999 - 2002
        Thomas Williams, Colin Kelley and many others

        This is a pre-version of gnuplot 4.0. Please refer to the documentation
        for command syntax changes. The old syntax will be accepted throughout
        the 4.0 series, but all save files use the new syntax.

mouse big cross cursor and hotkeys in "pause mouse"

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

As I use the new ginput.m for accessing gnuplot mousing events from Octave,
I can see some current "inconvencies". In principle, we would be of
advantage to get ginput(n) functionality of Matlab.

Thus:

A. Currently, there is no indication in the terminal windows that it is
doing "pause mouse".

Solution: change cursor to big cross -- ie like a ruler after "r", but the
cross follows mouse until "pause mouse" stops.


B. Mousing hotkeys (including those "hardcoded" to x11 like "q" and "space")
should be disabled during "pause mouse".

Solution and functionality: If a hotkey is pressed during "pause mouse",
then it stops pausing, and set MOUSE_BUTTON=0 and MOUSE_HOTKEY=keycode for
the key pressed.

Usage - example: Pressing "q" in gnuplot's terminal window will pass the "q"
to the caller by MOUSE_HOTKEY, and it may quit mouse tracking and evaluation
functionality.

Question:

- Should the command be "pause mouse hotkey" or "pause mouse nohotkeys"?

- x11_set_cursor(), pm_set_cursor() etc. should be changed from

	term_set_cursor(int type, int x, int y)
to
	term_set_special(int what, int option, int x, int y)

Then, this API will be general enough to send mousing events without adding
new term functions. E.g.

term->set_special(TERM_SPECIAL_RULER, ruler_type, x, y)
term->set_special(TERM_SPECIAL_HOTKEYS, 1, 0, 0)  // enable hotkeys
term->set_special(TERM_SPECIAL_HOTKEYS, 0, 0, 0)  // disable
term->set_special(TERM_SPECIAL_RAISE, 0, 0, 0)  // used by "raise" and
term->set_special(TERM_SPECIAL_LOWER, 0, 0, 0)  // "lower" commands


What do you think?

Could somebody start to implement this?

--
PM

Re: Fun with VMS, TBOOLEAN, macro definitions and DECC

[<ha...@on...>]

On Tue, May 04, 2004 at 01:18:17PM +0200, Hans-Bernhard Broeker wrote:
> On Mon, 3 May 2004, Lucas Hart wrote:
> > On Mon, May 03, 2004 at 05:48:58PM -0700, Ethan Merritt wrote:
> 
> > > %%%%%%%%% Unhappy TBOOLEANs
> > > 
> > > $ cc /DEFINE=(NO_GIH,HAVE_CONFIG_H,DECCRTL)/INCLUDE=[-]/PREFIX=ALL axis.c
> > > 
> > >     TBOOLEAN checkrange;
> > > .............^
> > > %CC-W-PROMOTMATCHW, In the definition of the function "axis_unlog_interval",
> > > the promoted type of checkrange is incompatible with the type of the corresponding
> > > parameter in a prior declaration.
> 
> I never used VMS to build any programs, but I take it this is a warning,
> not an error message, right?  Do we have reason to believe it actually
> breaks anything?
> 

(I no longer have access to a DEC Unix/Tru64 system - wouldn't be 
surprised to get the same warning messages with the DEC/Compaq C 
compiler there as well.)

The TBOOLEAN PROMOTMATCHW warnings are just warnings about a 
difference between the default promoted type for a parameter 
in the old-style function definition (int in this case) and 
its type in the new style function prototype (here TBOOLEAN)
which overrides the former. Innocuous, so I now disable the 
warning, e.g.   CC/WARN=DISABLE=(PROMOTMATCHW)

> 
> > My understanding is that C99 types _Bool as unsigned int, 
> > which DECC appears to expect.
> 
> C99 types it as a new atomic data type.  It's an integer data type, 
> but there's no particular reason whatsoever to assume it should be 
> as large as an entire int.  That would be quite wasteful, after all.
> 
> I'm quite sure DECC expects neither unsigned int nor char here --- 
> C99 is a non-existant concept in its view of the world.
> 

Depends on the version (equating Compaq C and DECC); v6.4, in 2001,
added support for C99 including an 8-bit _Bool data type and a 
/STANDARD=C99 flag.

However, I misinterpreted the reason for a lack of PROMOTMATCHW
when TBOOLEAN was declared as unsigned int;  unrelated to _Bool
but rather to the default promotion of the respective function 
parameters to int.

> [Function-like macro missing do { } while(0) bracket]
> > A simpler fix is 
> >   if (something) {
> >     PRINT0(...); 
> >   } else if (something) {
> >     PRINT1(...);
> >   }
> 
> That's not exactly a fix, but rather a kludgy workaround for a broken
> macro.  Since the macro is our own, we don't need that --- we can fix 
> the real problem.
> 

Agreed - the macro can be fixed; my point was intended to be that 
a simple kludge is sufficient for the one instance that the long-
established macro fails in the current source, without any functional
changes which might require more extensive testing.

-- Lucas Hart                         <ha...@on...>

Re: unexpected "replot" in "pause mouse"

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

On Tuesday 04 May 2004 01:14 am, Petr Mikulik wrote:
> [pasted from clipboard] this eats one character:
>
> plot x
> pause -1
> plot 1-x

So far as I recall that problem has always been there.
I tried before to fix it, but with no success.  This is not a
good time to mess with it, since even if you fix it for one
X11 configuration it may well break others.  The X
clipboard is implemented differently by different programs
and different desktop environments.


-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: Whats up with SourceForge (again)

[Hans-Bernhard B. <br...@ph...>]

On Tue, 4 May 2004, Hans-Bernhard Broeker wrote:

> On Mon, 3 May 2004, Lucas Hart wrote:

> > - archives of the gnuplot-beta and gnuplot-bugs mail lists are not 
> >   current
> 
> Hmmm... I thought they were just lagging behind a little, but yes, 
> it seems they haven't archived a single mail since April 3rd or so.
> gnuplot-developers and gnuplot-info are affected, too.

Support Request about this is filed.  Let's see what happens.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Fun with VMS, TBOOLEAN, macro definitions and DECC

[Hans-Bernhard B. <br...@ph...>]

On Mon, 3 May 2004, Lucas Hart wrote:

> On Mon, May 03, 2004 at 05:48:58PM -0700, Ethan Merritt wrote:
> > Disclaimer:
> > I had never built, nor run, gnuplot under VMS until today.
> > I was just curious, and this is what I found.
> 
> I'm working on updating CONFIGURE.VMS to gnuplot v4.0.0 and have
> encountered the same behaviour that you report.  

Sigh... Guys, what do you think I put out 4 weeks' worth of
release-candidate tarballs for?  Didn't it occur to anyone that _then_
would have been the right time to run this kind of test, and report any
problems, rather than now, after the release?

> > %%%%%%%%% Unhappy TBOOLEANs
> > 
> > $ cc /DEFINE=(NO_GIH,HAVE_CONFIG_H,DECCRTL)/INCLUDE=[-]/PREFIX=ALL axis.c
> > 
> >     TBOOLEAN checkrange;
> > .............^
> > %CC-W-PROMOTMATCHW, In the definition of the function "axis_unlog_interval",
> > the promoted type of checkrange is incompatible with the type of the corresponding
> > parameter in a prior declaration.

I never used VMS to build any programs, but I take it this is a warning,
not an error message, right?  Do we have reason to believe it actually
breaks anything?

> > at line number 188 in file $DISK1:[MERRITT.GNUPLOT.SRC]AXIS.C;1
> > 
> 
> Do you have stdbool.h?  If so, define HAVE_STDBOOL in config.h
> 
> Question: why is _Bool defined as unsigned char in syscfg.h? 

Because that's what GNU autoconf suggests it to be defined as in absence
of both <stdbool.h> and a predefined _Bool type, and because that's what
makes the most sense.  And because some other platforms objected
when we defined it as (unsigned) int, before.

> My understanding is that C99 types it as unsigned int, which DECC
> appears to expect.

C99 types it as a new atomic data type.  It's an integer data type, but
there's no particular reason whatsoever to assume it should be as large as
an entire int.  That would be quite wasteful, after all.

I'm quite sure DECC expects neither unsigned int nor char here --- C99 is
a non-existant concept in its view of the world.

[Function-like macro missing do { } while(0) bracket]
> A simpler fix is 
>   if (something) {
>     PRINT0(...); 
>   } else if (something) {
>     PRINT1(...);
>   }

That's not exactly a fix, but rather a kludgy workaround for a broken
macro.  Since the macro is our own, we don't need that --- we can fix the
real problem.

> > Sure enough - both show.c and unset.c try to call strdup() directly
> > rather than going through gp_strdup().  That fails if the system does
> > not provide strdup().
> > 
> 
> Yes - presumably an oversight.

In the case of show and unset: yes.  And it's exactly the kind of
oversight the pre-release cycle with its candidate tarballs was supposed
to expose, so they could be fixed before the release.

But there's one more use of strdup, this time in gplt_x11.  Since
gnuplot_x11 isn't linked against util.c, where gp_strup() is defined,
gplt_x11.c can't use gp_strdup().  So that has to be fixed separately,
by removing the use of strdup() from gplt_x11.c altogether.

(The calls to strdup() in src/win/wgraph.c are OK --- all Windows
compilers must have strdup anyway).

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Whats up with SourceForge (again)

[Hans-Bernhard B. <br...@ph...>]

On Mon, 3 May 2004, Lucas Hart wrote:

> - Using ViewCVS to access the gnuplot branch gives a Python error 
>   (the faq banch is OK)

I know.  SF.net staff has been alerted to this --- again.  The root of the
problem, and a solution are known.  But the solution has to be applied by
SF.net staff, and the problem appears to re-create itself each time we
touch the culprit file, 'install-sh', by CVS.

Ultimately, it's an incompatibility between our repository, the version
of CVS running at SF.net, and the version of RCS used by the ViewCVS
script.  In particular, their 'rcslog' barfs on a line CVS overwrites in 
install-sh,v each time it works on it.

> - archives of the gnuplot-beta and gnuplot-bugs mail lists are not 
>   current

Hmmm... I thought they were just lagging behind a little, but yes, 
it seems they haven't archived a single mail since April 3rd or so.
gnuplot-developers and gnuplot-info are affected, too.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.