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

Re: Mac OS X driver. [Was: Please check new TBOOLEAN...]

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

On Fri, 26 Mar 2004, Per Persson wrote:

> I'd say that the most important that aquaterm.trm no longer relies on 
> the AppKit framework which would cause a crash if a Quartz 
> window-server wasn't running for the logged in user (e.g. running 
> gnuplot remotely).

Hmm... all put together, this feels like the aquaterm.trm is essentially
a rewrite from scratch, right?

I guess we'll have to leave this decision up to you, then.  The crucial
issues to keep in mind would be: maturity of the new driver, and
responsibility for possible bugs found in whatever driver we end up having
in the gnuplot source tree.  

As nobody on the gnuplot development team seems to have access to a MacOS
box for testing, we'll have to rely on external experience for this.  At
the moment, that external experience would appear to have to be you.

So here's my proposal: you become a member of the gnuplot project team at
SourceForge.net, and take over responsibility for the aquaterm.trm and all
other MacOS X related issues.

> Yeah, I used to have them there, but I didn't feel entirely comfortable 
> with not creating/destroying in the same scope.

You'll have to resolve that one on your own, then.  I don't think anyone
but you even knows what these memory pools _are_, let alone what the
details of their usage might be.

> > It'd also have the benefit of placing these Chunks in a place
> > that already is out of sight of non-Objective-C compilations.
> 
> Hmm, the ObjC compilation is done by adding -ObjC to _all_ 
> compilations, so in a sense placing the stuff in command.c with #ifdefs 
> places the code on the same visibility level as aquaterm.trm in term.h.

The problem is not the ObjC compilation, it's plain C compilation on
platforms that have never so much as heard of ObjC.  Non-C preprocessor
instructions like #import can wreak all kinds of havoc in such setups, so
it'd be best to make sure they won't even be seen by C compilations.  
Hiding them in a separate file #include'd only conditionally should
provide the necessary isolation.

E.g. something like this:

in command.c:

	/* This whole chunk may better go to syscfg.h... */
	#ifdef __ObjC__   /* or whatever... */
	# include "gp_objc.h"
	#endif
	#ifndef GP_OBJC_INIT_MEMPOOL
	# define GP_OBJC_INIT_MEMPOOL /* nothing */
	#endif
	#ifndef GP_OBJC_FREE_MEMPOOL
	# define GP_OBJC_FREE_MEMPOOL /* nothing */
	#endif

	command() 
	{
	   GP_OBJC_INIT_MEMPOOL;

	   /* body of function */

	   GP_OBJC_FREE_MEMPOOL;
	}

gp_objc.h would then contain the #import statement, and #define the two
macros to whatever they have to do on ObjC.

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

Re: Mac OS X driver. [Was: Please check new TBOOLEAN...]

[Per P. <per...@ma...>]

On 2004-03-26, at 12.59, Hans-Bernhard Broeker wrote:

> On Fri, 26 Mar 2004, Per Persson wrote:
>
>> It is currently in alpha testing and I discussed the subject with Lars
>> Hecking and it was decided to wait until after the 4.0 release. 
>> However,
>> the new driver has matured rapidly and is much cleaner than the old
>> driver and supports more gnuplot features.
>
> It's hard to make a decision on such imprecise information.  Maybe you
> should post the current state of that driver somewhere, including an
> explanation why you think it's better, what new features it supports, 
> and
> so on.  Otherwise, we'll leave just stick with Lars' decision to 
> postpone
> it.

Of course, these are the major changes that affect the gnuplot driver:

AquaTerm::ReleaseNotes

AquaTerm 1.0a1
   Breaking backwards compatibility.
   Complete rewrite with better possibilities for future optimization.
   Supports mouse and key events (events in general actually). (#538268, 
#586499)
   Respects window size when updating. (#650938)
   Make window front when updated. (#651911)
   Added debug menu including "Refresh view", a test view and feedback 
options.

aquaterm.trm::ReleaseNotes

AquaTerm 1.0a2
     Process a lot more options. Currently supported options are:
     <n> title "theTitle" size <x> <y> fname "fontface" fsize <fontsize>
     Points and boxfill Implemented.
     Autoreleasepools should be handled in command() in 
gnuplot/src/command.c,
     leave a last line of defense in the driver.

AquaTerm 1.0a1
     Moved all common code into libaquaterm.dylib, all adapters link 
with this.
     Complete rewrite of common code, no reliance on AppKit (#605549)
     Increased resolution (#783895)
--------------

There are more details at the sourceforge site:
http://aquaterm.sourceforge.net/
http://cvs.sourceforge.net/viewcvs.py/aquaterm/adapters/gnuplot/

I'd say that the most important that aquaterm.trm no longer relies on 
the AppKit framework which would cause a crash if a Quartz 
window-server wasn't running for the logged in user (e.g. running 
gnuplot remotely).

My personal favourite is that all core functionality lives in a lib 
rather than the driver(s).  Drivers are now simple enough that most 
bugs should occur somewhere else and can be fixed without recompiling 
clients such gnuplot.

The new set of options might also make some users happy.

>
>> I'd also like to patch command.c to fix a problem with the
>> semi-automatic garbage collection in Objective-C that could lead to
>> excessive memory use during long running sessions.
>
> ObjC code in the middle of the native C stuff might be bad news.  At
> minimum, I'ld like to see this isolate to a separate source file, which
> a plain C compiler won't even look at.

OK

>
>> What it does is to set up and tear down an "object pool"  for every
>> loop through the event cycle. Placing it here is based on the
>> assumption that all calls to the driver is guaranteed to be made
>> through this single function.
>
> "Through" this function: almost certainly.  But I would think this 
> could
> more sensibly be put into your term->graphics() and term->text(). Those
> are called once per plot generated, which really should be sufficient 
> for
> your needs.

Yeah, I used to have them there, but I didn't feel entirely comfortable 
with not creating/destroying in the same scope.

> It'd also have the benefit of placing these Chunks in a place
> that already is out of sight of non-Objective-C compilations.

Hmm, the ObjC compilation is done by adding -ObjC to _all_ 
compilations, so in a sense placing the stuff in command.c with #ifdefs 
places the code on the same visibility level as aquaterm.trm in term.h.

Anyhow, you are probably right that we should keep C and ObjC separate.

/Per

Re: Please check new TBOOLEAN...

[Nigel N. <nN...@au...>]

In case no one else is still using VC6, 3.8k2 compiled fine 
and "all.dem" ran to completion on the following system: 
 
  Version 3.8k patchlevel 2 
  Visual Studio 6 /SP5 
  Windows 2000 
 
thanks, 
Nigel 
 
 

***********************************************************************************
The 2004 Ausport Awards are about to close! Don't forget to get your nomination in 
by 31 March 2004 for recognition of your organisations commitment to the Australian 
sport system. For more information and a nomination kit visit the website 
www.ausport.gov.au/events/ausportawards2004/ or call 1800 000 685.

**********************************************************************************
This message is intended for the addressee named and may contain confidential and 
privileged information. If you are not the intended recipient please note that 
any form of distribution, copying or use of this communication or the information
in it is strictly prohibited and may be unlawful. 
If you receive this message in error, please delete it and notify the sender.

Keep up to date with what's happening in Australian sport.
Visit http://www.ausport.gov.au
**********************************************************************************

Re: Mac OS X driver. [Was: Please check new TBOOLEAN...]

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

On Fri, 26 Mar 2004, Per Persson wrote:

> It is currently in alpha testing and I discussed the subject with Lars
> Hecking and it was decided to wait until after the 4.0 release. However,
> the new driver has matured rapidly and is much cleaner than the old
> driver and supports more gnuplot features.

It's hard to make a decision on such imprecise information.  Maybe you
should post the current state of that driver somewhere, including an
explanation why you think it's better, what new features it supports, and
so on.  Otherwise, we'll leave just stick with Lars' decision to postpone
it.

> I'd also like to patch command.c to fix a problem with the 
> semi-automatic garbage collection in Objective-C that could lead to 
> excessive memory use during long running sessions.

ObjC code in the middle of the native C stuff might be bad news.  At 
minimum, I'ld like to see this isolate to a separate source file, which
a plain C compiler won't even look at.

> What it does is to set up and tear down an "object pool"  for every 
> loop through the event cycle. Placing it here is based on the 
> assumption that all calls to the driver is guaranteed to be made 
> through this single function. 

"Through" this function: almost certainly.  But I would think this could
more sensibly be put into your term->graphics() and term->text(). Those
are called once per plot generated, which really should be sufficient for
your needs.  It'd also have the benefit of placing these Chunks in a place
that already is out of sight of non-Objective-C compilations.

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

Mac OS X driver. [Was: Please check new TBOOLEAN...]

[Per P. <per...@ma...>]

On 2004-03-25, at 14.09, Hans-Bernhard Broeker wrote:

> We may have to prepare another (hopefully the last!)  release candidate
> tarball because of the possible consequences of this change.  Sorry 
> about
> that, but this seemed the only reasonable way we would ever get out of
> that mess with MacOS X.

Hi,
maybe this is reason enough to switch to the new aquaterm.trm driver 
for OS X.
It is currently in alpha testing and I discussed the subject with Lars 
Hecking and it was decided to wait until after the 4.0 release.
However, the new driver has matured rapidly and is much cleaner than 
the old driver and supports more gnuplot features.

The new driver depends on a shared lib (libaquaterm), which would have 
to be checked for by configure.
It also needs a patch for apple.m4 (previously posted here).

I'd also like to patch command.c to fix a problem with the 
semi-automatic garbage collection in Objective-C that could lead to 
excessive memory use during long running sessions.
Patch below (it will have to be conditioned on libaquaterm (or Mac OS 
X) presence).
What it does is to set up and tear down an "object pool"  for every 
loop through the event cycle. Placing it here is based on the 
assumption that all calls to the driver is guaranteed to be made 
through this single function. If it is not, then I'll have to invent 
some other solution, but that could take some time since I'm very busy 
at the moment.

So, what do you all think?

/Per

--- src/command.c.old   Thu Feb 19 23:43:14 2004
+++ src/command.c       Fri Mar 26 10:55:02 2004
@@ -63,6 +63,8 @@
   *
   */

+#import <Foundation/NSAutoreleasePool.h>
+
  #include "command.h"

  #include "alloc.h"
@@ -500,6 +502,7 @@
  static void
  command()
  {
+  NSAutoreleasePool *arpool = [[NSAutoreleasePool alloc] init];
      int i;

      for (i = 0; i < MAX_NUM_VAR; i++)
@@ -509,7 +512,7 @@
         define();
      else
         (*lookup_ftable(&command_ftbl[0],c_token))();
-
+  [arpool release];
      return;
  }

Re: x11 persist under OS/2

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

> > then gnuplot does not quit but waits until I "q" in the x11 terminal or
> > I kill it. Somebody knows where to find this problem?
>
> It must be something specific to OS/2.

Maybe, or there is some "wait for input" or some similar "foreign" code not
surrounded by #ifdef PIPE_IPC.

> I've never seen that happen.

I've also tried it for the first time, to test your recent patches.

> Does it make any difference which readline() option is used?

I have only gnuplot's readline.

---
PM

Re: Please check new TBOOLEAN definition on all platforms.

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

> So, please, everyone who's building gnuplot on one of the relevant
> platforms (cygwin, MinGW, Amiga, OS/2 and MSVC++), check that this is
> indeed the case.

I've tested it for OS/2, Mingw and Cyg.

> We may have to prepare another (hopefully the last!)  release candidate
> tarball because of the possible consequences of this change.

No problem to have a new release candidate (now it's two weeks before the
release).

---
PM

Re: x11 persist under OS/2

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

On Thursday 25 March 2004 10:24 am, Petr Mikulik wrote:
> There is yet another bug in x11 terminal, and it looks like to be there
> since at least 2000. Under OS/2, if I do
>
> set terminal x11 persist
> plot x
> quit
>
> then gnuplot does not quit but waits until I "q" in the x11 terminal or
> I kill it. Somebody knows where to find this problem?

It must be something specific to OS/2.  I've never seen that happen.
Does it make any difference which readline() option is used?

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

x11 persist under OS/2

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

There is yet another bug in x11 terminal, and it looks like to be there
since at least 2000. Under OS/2, if I do

set terminal x11 persist
plot x
quit

then gnuplot does not quit but waits until I "q" in the x11 terminal or I
kill it. Somebody knows where to find this problem?


Also, I've noticed that OS/2 has obviously never passed command line
arguments to gnuplot_x11. In x11.trm, routine X11_args() is launching
executable of gnuplot_x11, and there is an OS/2 code with
popen(X11_command), while others have execvpe(X11_command, optvec).
Strange, optvec contains garbage under OS/2. I couldn't find why.

---
Petr Mikulik

Re: NEW BUG: filled arrowheads not working

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

On Thu, 25 Mar 2004, Hans-Bernhard Broeker wrote:

> Aargh.  The reason for that is of course, that do_arrow() will become
> term->arrow(), so it *must* match the prototype for that in struct
> TERMENTRY.  OTOH, I don't see any real need to touch that argument of
> do_arrow().  

But in the meantime, I did find it.  The head argument of term->arrow() is
indeed used to pass a literal '2'.  This really is bad, for at least two
reasons.

1) It clearly breaks the entire idea behind having a TBOOLEAN.

2) That '2' should be a named constant.  We don't want magic numbers.

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

Please check new TBOOLEAN definition on all platforms.

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

Hello, everyone,

as Ethan just found out, the new way TBOOLEAN is defined I checked in on
Tuesday exposed some lurking bugs.  I've now added the relevant #define's
for HAVE_STDBOOL_H and HAVE__BOOL to all the preset config.h files.  I've 
assumed that both of these conditions are true, on all those platforms.

So, please, everyone who's building gnuplot on one of the relevant
platforms (cygwin, MinGW, Amiga, OS/2 and MSVC++), check that this is
indeed the case.  With both defaulting to true, you'll get solid compiler
errors if you have to toggle them.

We may have to prepare another (hopefully the last!)  release candidate
tarball because of the possible consequences of this change.  Sorry about
that, but this seemed the only reasonable way we would ever get out of
that mess with MacOS X.

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

Re: NEW BUG: filled arrowheads not working

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

On Wed, 24 Mar 2004, Ethan Merritt wrote:

> Did this just break recently?  I don't recall getting these errors before.

I probably broke it on Tuesday, when I turned TBOOLEAN into an actual
C99-like bool, on those platforms that have this.  This was needed for the
benefit of Mac OS X, which ran into redefinition problems with bool.

> The problem is that curr_arrow_headfilled is a TBOOLEAN but then we find
> code like the following in term.c:
> 
> 	curr_arrow_headfilled = arrow_properties->head_filled
> 	...
> 	if (curr_arrow_headfilled == 2) {
> 		...

Which is, of course, plainly wrong.  Are we really getting this sloppy?

> I tried the simple fix of changing curr_arrow_headfilled to be an int
> rather than a TBOOLEAN, and similarly the last parameter to do_arrow(),
> but this just made things worse (hundreds of incompatible pointer
> warnings).

Aargh.  The reason for that is of course, that do_arrow() will become
term->arrow(), so it *must* match the prototype for that in struct
TERMENTRY.  OTOH, I don't see any real need to touch that argument of
do_arrow().  I'm checking in the change to curr_arrow_headfilled right
away.

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

NEW BUG: filled arrowheads not working

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

Did this just break recently?  I don't recall getting these errors before.

[1] rm term.o; make

gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/3.8k\" -DCONTACT=\"gnu...@li...\" -DHELPFILE=\"/usr/local/share/gnuplot/3.8k/gnuplot.gih\" -I/usr/X11R6/include -I/usr/local/include   -g -O2 -Wall -c term.c
term.c: In function `do_arrow':
term.c:930: warning: comparison is always false due to limited range of data type
term.c:957: warning: comparison is always false due to limited range of data type
term.c:959: warning: comparison is always false due to limited range of data type
term.c:989: warning: comparison is always false due to limited range of data type
In file included from term.h:300,
                 from term.c:1054:
../term/fig.trm: In function `FIG_arrow':
../term/fig.trm:785: warning: comparison is always false due to limited range of data type
../term/fig.trm:807: warning: comparison is always false due to limited range of data type
../term/fig.trm:817: warning: comparison is always false due to limited range of data type


The problem is that curr_arrow_headfilled is a TBOOLEAN but then we find
code like the following in term.c:

	curr_arrow_headfilled = arrow_properties->head_filled
	...
	if (curr_arrow_headfilled == 2) {
		...

which tries to set it to an (int) and then test for values other than TRUE or FALSE.
The same problem arises elsewhere in term.c and in fig.trm
I tried the simple fix of changing curr_arrow_headfilled to be an int rather than
a TBOOLEAN, and similarly the last parameter to do_arrow(),
but this just made things worse (hundreds of incompatible pointer warnings).

Anyhow, the result is that filled arrowheads are not working.



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

Re: (un)set mouse, x11 persist and gplt_x11.c: MOUSE_ALL_WINDOWS

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

> But there is a related case for which I am not sure of the
> correct behaviour:
>
> set term x11 1 persist
> plot sin(x)
> set term dumb
>
> At this point the connection between gnuplot and gnuplot_x11 is
> still present but, since the current terminal is no longer x11, mouse
> events are ignored.  Should we explicitly turn mousing over to
> gnuplot_x11 in this case even though the connection is still active?
> Should gnuplot itself continue to handle X-events even though the
> current terminal is now something other than x11?

No, it should not -- e.g. pressing "l" for "set log y" in X11 would change
this property globally, thus also for the other terminal, which is probably
not desired.

> > set mouse
> > set term x11 1 persist
> > plot sin(x)
> > set term x11 2 persist
> > plot x
> > set term x11 3 persist
> > plot tan(x)
> > unset mouse
> >
> > unsets mouse only in terminal 3, and not in all terminals. Also a bug.
>
> Not fixable.  Or at least not fixable in the general case, although the
> specific simple example you give could be changed.   But why is it a
> bug?  If you ask for a persistent X11 window, don't you expect it to
> operate on its own without further input from gnuplot?

This should not depend on whether window is persistent or not.

Question is whether "unset mouse" operates on the current or on all
mouseable terminals. Currently only on the selected one. We can keep this
feature, and then it is not bug.


> > I think gplt_x11.c should react to "m" hotkey to switch the mousing bar on/off.
>
> Good idea.  I will add it to CVS when SourceForge comes back online.

Works nice, just a small annoyance: you have to move your mouse so that the
window resizes itself to adopt space for the mouse bar. Could the resize be
called automatically when mouse gets on/off?


> > Finally, there is some funny behaviour of mousing ruler, when "set x11
> > <another>; replot" -- it would be nicer to position the ruler to its x,y
> > coordinates.
>
> Please explain in more detail.  Do you mean that the new window should
> not inherit the state of the ruler from the previous window?  Or do you
> mean that it *should* inherit the ruler, but the ruler should be re-positioned?

It should inherit the ruler at its x,y position so that the ruler propagates
at the same x,y for all subsequent plots.
Could you please patch it?

---
Petr Mikulik

Re: (un)set mouse, x11 persist and gplt_x11.c: MOUSE_ALL_WINDOWS

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

On Tuesday 23 March 2004 08:04 am, Petr Mikulik wrote:
> According to the bug report "[ 921033 ] pipe+mouse+x11", the following
>
> set mouse
> set term x11 1 persist
> plot sin(x)
> set term x11 2 persist
> plot x
> set term x11 3 persist
> plot tan(x)
> quit
>
> let terminals 1 and 2 mouseable, while not 3. There seems to be a bug
> that does not notify terminal 3 to be active for post-quit mousing.

Fixed in CVS.  If the connection between gnuplot and gnuplot_x11 is
broken (e.g. by 'quit') then gnuplot_x11 will take over the mousing.

But there is a related case for which I am not sure of the 
correct behaviour:

set term x11 1 persist
plot sin(x)
set term dumb

At this point the connection between gnuplot and gnuplot_x11 is
still present but, since the current terminal is no longer x11, mouse
events are ignored.  Should we explicitly turn mousing over to
gnuplot_x11 in this case even though the connection is still active?
Should gnuplot itself continue to handle X-events even though the
current terminal is now something other than x11?


> set mouse
> set term x11 1 persist
> plot sin(x)
> set term x11 2 persist
> plot x
> set term x11 3 persist
> plot tan(x)
> unset mouse
>
> unsets mouse only in terminal 3, and not in all terminals. Also a bug.

Not fixable.  Or at least not fixable in the general case, although the
specific simple example you give could be changed.   But why is it a
bug?  If you ask for a persistent X11 window, don't you expect it to
operate on its own without further input from gnuplot?

In fact, now that I think about it - I consider it a bug that if you type
'set term x11 nopersist; exit' at this point then all the previous windows
are closed even though they were individually opened with "persist".
I think that persist/nopersist should be a per-window property, not a
global one.

> I think gplt_x11.c should react to "m" hotkey to switch the mousing bar on/off.

Good idea.  I will add it to CVS when SourceForge comes back online.

> Finally, there is some funny behaviour of mousing ruler, when "set x11
> <another>; replot" -- it would be nicer to position the ruler to its x,y
> coordinates.

Please explain in more detail.  Do you mean that the new window should
not inherit the state of the ruler from the previous window?  Or do you
mean that it *should* inherit the ruler, but the ruler should be re-positioned?

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

Re: Time/date autoticking --- showstopper?

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

Chr...@ha... wrote:

>Dan :
>
>  
>
>>Well, actually after your discussion and examples, I think what you have 
>>done is better than what is shown.  It seems what you have done is made 
>>things so that the major ticks always lie along the bottom and top 
>>borders.  (Is that correct?)  
>>    
>>
>
>I'm not exactly sure what you're saying here.  All ticks, major or minor,
>should be on the axis, and not 'off the top of the X11 window', as you
>mentioned in the first e-mail.  Perhaps you are referring to the fact
>that the 'test1.ps' has apparent interval of one hour between ticks, so
>that the implied '01:00' tick is out of the X11 window.
>

Yes.  I said that backward; I meant top and bottom borders aligning with 
a major y-axis tic.

Dan

Re: [ gnuplot-Bugs-906056 ] enh-ps: @-aligned string does not work with font change

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

I have patched this bug in CVS.  The fix is conceptually simple,
but I had to add a couple of lines to the already-complicated
PostScript routine MFshow.  Please exercise it thoroughly to
confirm how robust it is (or isn't :-).

This should fix the reported problem for all terminals supporting
enhanced text mode. 


On Thursday 18 March 2004 02:30 pm, SourceForge.net wrote:
> Submitted By: Harald Harders (harders)
> Assigned to: Ethan Merritt (sfeam)
> Summary: enh-ps: @-aligned string does not work with font change
>
> Initial Comment:
> If I align a string with @ to use no space and change the
> font inside this string part, the formatting is broken.
> For example
> try
>
> set xlabel 'A@{^{Times{/Helvetica Helv}Times}}_{bye}'
>
> "Times", "Helvetica", and "Times" again are plotted
> at the same position instead of one after another. In my
> opinion, "TimesHelveticaTimes" should be written, using
> no space for the complete string.

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

Re: Time/date autoticking --- showstopper?

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

Christopher Roth wrote:

>Dan/Hans :
>
>  
>
>>I'm not totally sure what the problem is with this one.  Is it that 
>>there are only the major tics and so few of them that it is difficult to 
>>judge the values?  Are you saying there should be more minor tics here?
>>
>>For example
>>
>>    p [-10 : 36*59] x
>>
>>looks pretty good, aside from the fact that the top tic annotation lies 
>>off the top of the X11 window.  There is a major tic spacing of 3 
>>minutes and minor tic spacing at every minute.
>>    
>>
>
>This first example is looks ok.
>

Well, actually after your discussion and examples, I think what you have 
done is better than what is shown.  It seems what you have done is made 
things so that the major ticks always lie along the bottom and top 
borders.  (Is that correct?)  What I don't like about "test1.ps" is that 
the middle/top major tic is about two thirds the way up the left border 
instead of halfway up the left border.  With that setup it is difficult 
to get a precise guesstimate of values in between the tics.  It's as 
though your eyes can't get a handle on just exactly what the proportions 
are there.

So the more major tics in test1_fixed.ps are helpful and also the tics 
starting and stopping on borders is helpful.  It is certainly nicer and 
what you have is close if not correct.  However, could there be a minor 
tic in "test1_fixed.ps"?  Or are minor tics at fractional units not 
allowed (e.g., 2.5 minutes)?  I think you are saying they are not 
allowed, right?

>>But for
>>
>>    p [-10 : 36*60] x
>>
>>the scale seems to jump to the hourly dynamic range, or mode, or 
>>whatever you want to call it.  So all of a sudden there is only one or 
>>possibly two major tics and no minor tics.  So that tells me the 
>>algorithm in quantize_time_tics() may need some adjustment.  You may 
>>want to stay in the minute mode just a little while longer, say twenty 
>>percent more.  Or it may be that you just want some minor tics in there 
>>to fill things out a little better.  Or, you could put major tics at 
>>every half hour instead of hour when in this region (i.e., just a little 
>>bit beyond an hours time).  Anyway, choosing the better major tic 
>>spacing doesn't seem like a huge issue.  (Is the "guide" parameter meant 
>>to be roughly the number of tics that should be?)  Perhaps you need to 
>>introduce a few more "ranges" inside the enumeration, e.g., 
>>TIMELEVEL_THIRDMINUTES, TIMELEVEL_THIRDHOURS, etc., and then add the 
>>appropriate cases inside the routines.
>>    
>>
>
>I have to say that Hans has great work in quantize_time_ticks(), and it
>does NOT need any adjustment.  The results from this are just fine - 
>it's just that the results are being OVERRIDDEN by this unneccesary
>'zero reset' in the time_tic_just() routine.  My proposed fix averts
>this reset until it is really needed.
>
>Take a look at the both the plot produced and contents of the 'test1.ps'
>and 'test1_fixed.ps' files in the attached tar file.  The important 
>thing to note is the number of time each of the unique time labels are 
>being drawn - the 'test1.ps' shows the '31/12/1999 23:00' label being
>drawn *12* times, and all at the _same_ place, making it look like only
>one label.  Had the minutes not been forced to 0 in the time_tic_just()
>routine, there would have been a nice set of 5-minute interval major 
>time ticks.  The '01/01/2000 00:00' label is drawn *9* times, which
>continues the 5-minute intervals, making the intended top label being 
>'00:40', which exactly correlates with the length of the axis.
>The 'test1_fixed.ps' file shows the same plot, but generated using my
>proposed fix of adding the three pairs of braces in time_tic_just().
>Since the minutes are not being forced to zero, the starting time is 
>at 23:55, rather than 23:00.  The same intended 5-minute interval is
>present, and each time label is drawn only once.
>

test2_fixed.ps looks correct to me.

>>However, this example:
>>
>>    p [-10 : 36*300] x
>>
>>reveals a more sever problem.  Now the hourly major tics seem pretty 
>>good, perhaps still a bit too spaced apart.  But the minor tics aren't 
>>evenly spaced.  It looks as though the minor tic spacing starts out such 
>>that there should be 6 minor tics between major tics, but only the first 
>>two minor tics are displayed.  I would say this one is a bug of the typo 
>>kind, i.e., and "oops, didn't mean to type that" sort of thing, rather 
>>than a conceptual thoughto.
>>
>>    
>>
>
>This is the error that drove me to track this bug down.  From looking at
>the 'test2.ps' plot, it appears that every other major tic, and its
>associated minor tics are missing.  Again, the postscript file reveals
>that these labels are not lost, but are drawn on top of the previous
>one.  The first label, '23:00' is drawn twice - first for 23:00, then 
>for 23:30, except that the minutes are being forced to zero -> so it 
>goes to 23:00.  The same thing happens to all other major ticks at 
>'**:30' - they are forced to be '**:00'.
>The plot in 'test2_fixed.ps' shows the way it was intended by the 
>quantize_time_ticks() routine.  Because the minutes are not being forced
>to zero, the starting time is allowed to be at 23:30, and all the other
>major ticks at **:30 now show up where they should.
>

Well, certainly Hans wouldn't have intended to have zero spacing tics...

Anyway, it looks like the bug is near fixed, if not fixed.  Nice work.

Dan

(un)set mouse, x11 persist and gplt_x11.c: MOUSE_ALL_WINDOWS

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

According to the bug report "[ 921033 ] pipe+mouse+x11", the following
commands

set mouse
set term x11 1 persist
plot sin(x)
set term x11 2 persist
plot x
set term x11 3 persist
plot tan(x)
quit

let terminals 1 and 2 mouseable, while not 3. There seems to be a bug that
does not notify terminal 3 to be active for post-quit mousing.

Further,

set mouse
set term x11 1 persist
plot sin(x)
set term x11 2 persist
plot x
set term x11 3 persist
plot tan(x)
unset mouse

unsets mouse only in terminal 3, and not in all terminals. Also a bug.


Actually, I thought that mousing is stopped when quitting gnuplot: this
feature was available in 1998--1999 in OS/2 and later in X11, then removed
due to mousing implementation rewrite. Well, now it is back in X11 -- so,
let's keep it there, but then I think gplt_x11.c should react to "m" hotkey
to switch the mousing bar on/off.

Can somebody fix these things?

Finally, there is some funny behaviour of mousing ruler, when "set x11
<another>; replot" -- it would be nicer to position the ruler to its x,y
coordinates.


---
PM

Re: Time/date autoticking --- showstopper?

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

On Mon, 22 Mar 2004, Daniel J Sebald wrote:

> You didn't get much feedback on this one.  I think it is because it is 
> somewhat obsure for most to follow without working with it closely.  

That's why I suggested to go play with it a bit --- the shortcomings
are pretty obvious once you start looking for them.

But with Petr on vacation, and Ethan occupied with the generalization of
postscript enhanced to other terminals, it looks like I'll have to do this
on my own.

I'll just check in my current fix then.  It works different from the one
suggested by the bug's original reporter, in several ways.

> But for
> 
>     p [-10 : 36*60] x
> 
> the scale seems to jump to the hourly dynamic range, or mode, or 
> whatever you want to call it.  

Exactly that's the problem.  To be more precise, timelevel[FIRST_Y_AXIS] 
is TIMELEVEL_HOURS in this case, and that's where the proverbial brown 
stuff hits the fan.  time_tic_just interprets this fact as meaning that 
*all* tics have to lie on integer multiples of hours, whereas 
quantize_time_tics wants it to mean that the tic interval is 1/12th of an 
hour.

> that there should be 6 minor tics between major tics, but only the first 
> two minor tics are displayed.  I would say this one is a bug of the typo 
> kind, i.e., and "oops, didn't mean to type that" sort of thing, rather 
> than a conceptual thoughto.

Trust me, it is a "thoughto" alright. 

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

Re: Time/date autoticking --- showstopper?

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

  Hans-Bernhard Broeker wrote:

>Gents,
>
>it seems we may have found ourselves a show-stopping bug:
>
> [ 918276 ] Irregularly spaced labels on time axis in v 3.8k.2
>
>Thanks to Chistopher Roth (cc'ed) for spotting this one.
>
>The culprit who committed the code in question is myself, but given the
>schedule of the planned release, I think we'll need all attention we can
>muster focussed on that one.  I for one won't consider the program to be
>release-worthy until we fix it.  (It's marked as release_critical for that
>reason.)
>

You didn't get much feedback on this one.  I think it is because it is 
somewhat obsure for most to follow without working with it closely.  I 
briefly looked through the code for the routines you mention and 
although I can't pinpoint things without really getting into it, maybe a 
dialogue can lead to the problem...

First, let me say that the code looks fairly well organized and logical 
so that if you find the problem, fixing for the 4.0 release wouldn't be 
shaking the tree too much.  The solution is probably just some minor 
adjustment, I would think.

>
>To easily see what the problem is, try the following script:
>
>	reset
>	set ydata time
>	set mytics
>	p [-10 : 36*60] x
>


I'm not totally sure what the problem is with this one.  Is it that 
there are only the major tics and so few of them that it is difficult to 
judge the values?  Are you saying there should be more minor tics here?

For example

    p [-10 : 36*59] x

looks pretty good, aside from the fact that the top tic annotation lies 
off the top of the X11 window.  There is a major tic spacing of 3 
minutes and minor tic spacing at every minute.

But for

    p [-10 : 36*60] x

the scale seems to jump to the hourly dynamic range, or mode, or 
whatever you want to call it.  So all of a sudden there is only one or 
possibly two major tics and no minor tics.  So that tells me the 
algorithm in quantize_time_tics() may need some adjustment.  You may 
want to stay in the minute mode just a little while longer, say twenty 
percent more.  Or it may be that you just want some minor tics in there 
to fill things out a little better.  Or, you could put major tics at 
every half hour instead of hour when in this region (i.e., just a little 
bit beyond an hours time).  Anyway, choosing the better major tic 
spacing doesn't seem like a huge issue.  (Is the "guide" parameter meant 
to be roughly the number of tics that should be?)  Perhaps you need to 
introduce a few more "ranges" inside the enumeration, e.g., 
TIMELEVEL_THIRDMINUTES, TIMELEVEL_THIRDHOURS, etc., and then add the 
appropriate cases inside the routines.

However, this example:

    p [-10 : 36*300] x

reveals a more sever problem.  Now the hourly major tics seem pretty 
good, perhaps still a bit too spaced apart.  But the minor tics aren't 
evenly spaced.  It looks as though the minor tic spacing starts out such 
that there should be 6 minor tics between major tics, but only the first 
two minor tics are displayed.  I would say this one is a bug of the typo 
kind, i.e., and "oops, didn't mean to type that" sort of thing, rather 
than a conceptual thoughto.


>Replace the numbers by whatever you like, and watch the y tics.  
>Optionally set the ytics or mytics to some explicit interval.
>
>There's a *lot* of funny things going on there.  The minitics are
>seriously ill, but the major tics aren't exactly perfect either.  The
>functions and data to inspect are all in axis.c:
>
>	t_timelevel timelevel[];
>	AXIS axis_array[];
>
>	quantize_duodecimal_tics()
>	quantize_time_tics()
>	make_auto_time_minitics()
>	time_tic_just()
>
>The main problems seem to be that interpretation of timelevel[] is
>somewhat different between quantize_time_tics() and time_tic_just().
>
>Since I invented quantize_duodecimal_tics(), timelevel[] is set by
>quantize_time_tics() to be the unit the major tic spacing it's *based* on.  
>In particular, that unit is quite often *larger* than the actual tic step,
>i.e. a tick step of 10 minutes is seen as "1/6th of an hour", so
>timelevel[] will be TIMELEVEL_HOURS.  time_tic_just() does quite a number
>of wrong things if tics are spaced as fractions of a timelevel[] unit. In
>particular it moves tics around by zeroing out fields in a time struct,
>causing them to often end up all in the same place. Christopher posted a
>patch for this, but IMHO that's not exactly correct either.
>
>Time axes are actually not all that bad, even --- the strange factor of
>twelve is tricky, but quantize_duodecimal_tics() can handle it.  The real
>bugger is with date axes.  These are (slightly, but significantly)
>irregular by definition, and that's not something the usual auto-ticking
>algorithm can do. In trying to get those right, it's very easy to break
>other aspects, and we did.
>

Well, there seems to be a large amount of code for Gnuplot implementing 
its own form of gmtime().  Yes, that is going to be involved, various 
month lengths, leap year algorithm, etc.  Too bad there isn't some way 
of translating the time values and using the existing gmtime() routine. 
 However, I don't see this as the issue for the major/minor tics.  A 
problem with this routine would only mess up the contents of the tic 
labels, e.g., wrong dates, mainly.

Are we on the same wavelength here?

Dan

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

Time/date autoticking --- showstopper?

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

Gents,

it seems we may have found ourselves a show-stopping bug:

 [ 918276 ] Irregularly spaced labels on time axis in v 3.8k.2

Thanks to Chistopher Roth (cc'ed) for spotting this one.

The culprit who committed the code in question is myself, but given the
schedule of the planned release, I think we'll need all attention we can
muster focussed on that one.  I for one won't consider the program to be
release-worthy until we fix it.  (It's marked as release_critical for that
reason.)

To easily see what the problem is, try the following script:

	reset
	set ydata time
	set mytics
	p [-10 : 36*60] x

Replace the numbers by whatever you like, and watch the y tics.  
Optionally set the ytics or mytics to some explicit interval.

There's a *lot* of funny things going on there.  The minitics are
seriously ill, but the major tics aren't exactly perfect either.  The
functions and data to inspect are all in axis.c:

	t_timelevel timelevel[];
	AXIS axis_array[];

	quantize_duodecimal_tics()
	quantize_time_tics()
	make_auto_time_minitics()
	time_tic_just()

The main problems seem to be that interpretation of timelevel[] is
somewhat different between quantize_time_tics() and time_tic_just().

Since I invented quantize_duodecimal_tics(), timelevel[] is set by
quantize_time_tics() to be the unit the major tic spacing it's *based* on.  
In particular, that unit is quite often *larger* than the actual tic step,
i.e. a tick step of 10 minutes is seen as "1/6th of an hour", so
timelevel[] will be TIMELEVEL_HOURS.  time_tic_just() does quite a number
of wrong things if tics are spaced as fractions of a timelevel[] unit. In
particular it moves tics around by zeroing out fields in a time struct,
causing them to often end up all in the same place. Christopher posted a
patch for this, but IMHO that's not exactly correct either.

Time axes are actually not all that bad, even --- the strange factor of
twelve is tricky, but quantize_duodecimal_tics() can handle it.  The real
bugger is with date axes.  These are (slightly, but significantly)
irregular by definition, and that's not something the usual auto-ticking
algorithm can do. In trying to get those right, it's very easy to break
other aspects, and we did.

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

Re: Somebody check my patch for SF bug 905651, please

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

> I'm not convinced this can go into CVS before the 4.0 release.  It's a
> pretty serious bug, but I suspect the risk that my patch breaks something
> else is considerable.  I see three ways out of this dilemma:
>
> 1) Put it in CVS, then release yet another release candidate to the
> general public right away, to give this patch as much exposure as
> possible.
>
> 2) Some of us (Petr, most importantly...) test this rigorously before it
> goes in.  Then it goes into CVS for 4.0
>
> 3) Delay this patch until after the release.

It would be worth to submit the patch if it passes "demo/pm3d.dem" as well
... try to run the current and patched gnuplot versions with this file and
compare results. Currently, the new patch does not pass.


> I tried not to affect its operation in PM3D mode, but Petr or someone will
> have to check this.

> Petr: I you should do something about this FIXME comment of yours:
> (graph3d.c:2268 after this patch):
>
> 	if (*X_AXIS.label.text) {
> 	    /* label at xaxis_y + 1/4 of (xaxis_y-other_y) */
> #ifdef USE_GRID_LAYERS /* FIXME: still needed??? what for? */
> 	    if ((surface_rot_x <= 90 && BACKGRID != whichgrid) ||
> 		(surface_rot_x > 90 && FRONTGRID != whichgrid)) {
> #endif

With a simple
	set pm3d; set border 4095
	splot sin(x*y/4)/(x*y)

and rotation by mouse all around, it looks like your patch does sometimes
hide wrong bar of the border, e.g. for view: 146, 37, 1, 1 -- I think these
rot_x >=90 and <=90 conditions are just about this.


> Actually, since the tick labels are defined to always be outside the graph
> box, it shouldn't matter at all, as long as you make sure they're only
> output once.

I see these tics a major trouble here. Immediately the 1st three plots in
pm3d.dem look strange ... as well as all others. Even those splot with "pm3d
solid" are affected -- you see spurious tics without border's label. So
there is something out of proper order.

And "set grid back" is completely broken in the new patch.

Could you please fix it?

Petr

Somebody check my patch for SF bug 905651, please

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

Hello, everyone,

I've just filed a patch for this SF bug report:

[ 905651 ] splot: grid and border overlap the plot

The fix, unfortunately, is a pretty massive one:

gnuplot/src> wc graph3d_grid_layers.diff
    386    1791   12707 graph3d_grid_layers.diff

I'm not convinced this can go into CVS before the 4.0 release.  It's a
pretty serious bug, but I suspect the risk that my patch breaks something
else is considerable.  I see three ways out of this dilemma:

1) Put it in CVS, then release yet another release candidate to the
general public right away, to give this patch as much exposure as
possible.

2) Some of us (Petr, most importantly...) test this rigorously before it
goes in.  Then it goes into CVS for 4.0

3) Delay this patch until after the release.

I built it by generalizing Petr's existing PM3D-only hack "whichgrid" to
be usable in all circumstances I could imagine.  I tried not to affect its
operation in PM3D mode, but Petr or someone will have to check this.

Petr: I you should do something about this FIXME comment of yours:
(graph3d.c:2268 after this patch):

	if (*X_AXIS.label.text) {
	    /* label at xaxis_y + 1/4 of (xaxis_y-other_y) */
#ifdef USE_GRID_LAYERS /* FIXME: still needed??? what for? */
	    if ((surface_rot_x <= 90 && BACKGRID != whichgrid) ||
		(surface_rot_x > 90 && FRONTGRID != whichgrid)) {
#endif

I removed several similar if's of that kind from [xyz]tick_callback(),
because they really didn't make much sense.  Whether or not to draw those
tick labels is a question of 'whichgrid' alone.  The surface_rot_x status
almost certainly should not have to be consulted here.  Actually, since
the tick labels are defined to always be outside the graph box, it
shouldn't matter at all, as long as you make sure they're only output
once.  So

	if (FRONTGRID != whichgrid) {

should suffice.  That's what my patch does.

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

Re: Necessary Libraries

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

> > Thank you all for your answers. But shouldn't we really prepare a file
> > requirements.txt or a section Requirements in the README where all
> > needed third-party libraries are listed?
>
> Yes, but not in README.  This belongs into INSTALL.

You are right of course.

> They already are
> listed there, but not in all the necessary detail, and the text is
> outdated, and that's where it belongs.  INSTALL is where people building
> the program from sources are supposed to look --- README is for users, not
> builders.

Yes, the library names can be found there. But the information is well
hidden. I think it could be worth adding a section "Third-party libraries"
where all eventually needed libraries are listed with a link to the part
where is written how to switch on and off parts of gnuplot.

> > PS: I have tried to avoid all Umlauts. I hope this mail will be sent as it
> > is, now.
>
> It works.

Okay, then I will try that as workaround in future.

Yours
Harald

-- 
Harald Harders                           Langer Kamp 8
Technische Universitaet Braunschweig     D-38106 Braunschweig
Institut fuer Werkstoffe                 Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.ifw.tu-bs.de          Fax: +49 (5 31) 3 91-3058