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

FYI: Web ViewCVS broken *again*...

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

Hello, everyone,

I just noticed that again (at least for the third time, now),
our CVS repository causes that ViewCVS Python exception if you try
to look at the main gnuplot directory.

Again, the troublesome lines appear to be in install-sh,v.

Support Request to the SF.net team is under way.

-- 
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...]

[Lars H. <lhe...@us...>]

Hans-Bernhard Broeker writes:
> On Fri, 26 Mar 2004, Lars Hecking wrote:
> 
> > 
> > > OK, then I'd say go for the new driver.
> > > That way I could retire the old driver sooner than expected.
> >  
> >  Ok, that's fine by me.
> 
> Done.  Per Persson is now a member of the gnuplot project at SF.net, and
> will be considered responsible for every aspect of it involving Mac OS X.
> 
> Per: you have write access to the CVS.  Use it with care, please.
 
 Welcome to the club, Per!

 You may find it useful to subscribe to the gnuplot-cvs mailing list to
 get a feel for the commit activities.

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

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

On Sun, 28 Mar 2004, Per Persson wrote:

> 
> On Mar 26, 2004, at 17:41, Hans-Bernhard Broeker wrote:
> 
> > Per: you have write access to the CVS.  Use it with care, please.
> 
> Thanks,
> speaking of care - are there any guidelines for commits (comments, 
> ChangeLog entries etc.)?

We've been keeping commit logs short, usually one-liners, while ChangeLog
entries essentially follow GNU coding standards ("info standard
Documentation 'change logs'" on any self-respecting GNU installation).

The easiest way of generating such ChangeLog entries is to be using
Emacs and type "C-x 4 a" while at the place changed.  It'll find the 
ChangeLog file, and enter all the required fields, so you only have to
type the description of what the change is about.

Be sure to read the "CodeStyle" file, too.

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

Re: Mac OS X driver.

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

On Sun, 28 Mar 2004, Per Persson wrote:

> During configure:
> -----------------
> Can't find malloc.h

Don't worry -- it's not needed.  <malloc.h> is a non-standard header,
not required to be found.  Some pre-standard and/or standard-ignoring 
compilers kept malloc() there.

> During make:
> ------------
> A warning unrelated to aquaterm/OS X I think:
> 	../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:817: warning: comparison is always false due to 
> limited range of data type

I'll take care of that.

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

Re: Mac OS X driver.

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

On Sun, 28 Mar 2004, Ethan A Merritt wrote:

> On Sunday 28 March 2004 13:35, Per Persson wrote:
> > A warning unrelated to aquaterm/OS X I think:
> > 	../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:817: warning: comparison is always false due to
> > limited range of data type
> 
> Yes, that's the same bug I reported a few days ago.
> It is due to an improper use of TBOOLEAN for one of the
> term->arrow parameters that wants to take on numical
> values.  Hans, are you working on that one?

I have a patched version ready to commit, but am a bit hesitant to do so.
This is a fundamental change to the definition of the terminal API,
something I've been opposing for a while now when others suggested
anything like that.  But then, the actual change to the API has already
been done a while ago, when this abuse of a boolean argument was 
introduced.  I.e. this change just adapts the formal type to what the
code actually has been doing for quite a while.

Ah heck, I'll just check it in and package up a new snapshot, then.


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

Re: Mac OS X driver.

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

On Sunday 28 March 2004 13:35, Per Persson wrote:
> A warning unrelated to aquaterm/OS X I think:
> 	../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:817: warning: comparison is always false due to
> limited range of data type

Yes, that's the same bug I reported a few days ago.
It is due to an improper use of TBOOLEAN for one of the
term->arrow parameters that wants to take on numical
values.  Hans, are you working on that one?

> Built products:
> ---------------
> gnuplot.info doesn't contain info on aquaterm, even though
> gnuplot.pdf does.

That's easily fixed. You need to add it to the list of terminals
in doc2texi.el

-- 
Ethan A Merritt
Dept of Biochemistry K428b
University of Washington - Seattle

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

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

On Mar 26, 2004, at 17:41, Hans-Bernhard Broeker wrote:

> Per: you have write access to the CVS.  Use it with care, please.

Thanks,
speaking of care - are there any guidelines for commits (comments, 
ChangeLog entries etc.)?

/Per

Re: Mac OS X driver.

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

On Mar 28, 2004, at 13:50, Hans-Bernhard Broeker wrote:
>
> Anyway: not knowing what these memory pools are, and why they require 
> this
> strange amount of extra book-keeping, I guess we'll have to trust your
> judgement on this issue.  So do whatever you think makes most sense.

I think I have it right in the driver right now, so I'll let it stay 
there for now.
I'll take some time to explain how the book-keeping stuff works etc. 
when things have settled down.

I'm about to commit my changes, but before I do, there are some things 
I noticed during building/testing that I might as well bring up:
(haven't looked into any of the following yet, hoping that someone 
would have quick answers)

During configure:
-----------------
Can't find malloc.h
	malloc is defined in stdlib.h, but there is a sys/malloc.h for 
compatibility
	Will gnuplot recognize HAVE_STDLIB_H and disregard the undefined 
HAVE_MALLOC_H?
	Should a search for sys/malloc.h be added?

During make:
------------
A warning unrelated to aquaterm/OS X I think:
	../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:817: warning: comparison is always false due to 
limited range of data type

Built products:
---------------
gnuplot.info doesn't contain info on aquaterm, even though gnuplot.pdf 
does.

/Per

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

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

On Sat, 27 Mar 2004, Per Persson wrote:
> 
> Well, it turned out in testing that there was at least one place where 
> a driver call came from outside command() in command.c:
> #7  0x000650a0 in term_suspend () at term.c:560
> #8  0x00009854 in com_line () at command.c:266
> #9  0x0003f408 in main (argc=1, argv=0xbffffc1c) at plot.c:626

Then perhaps com_line() would be the right place to move that machinery
to.  It's the only caller of command(), after all, as far as I can see.

Anyway: not knowing what these memory pools are, and why they require this
strange amount of extra book-keeping, I guess we'll have to trust your
judgement on this issue.  So do whatever you think makes most sense.

-- 
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 Mar 26, 2004, at 12:59, Hans-Bernhard Broeker wrote:

>
>> 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.

Well, it turned out in testing that there was at least one place where 
a driver call came from outside command() in command.c:
#7  0x000650a0 in term_suspend () at term.c:560
#8  0x00009854 in com_line () at command.c:266
#9  0x0003f408 in main (argc=1, argv=0xbffffc1c) at plot.c:626

So, I'll leave command.c alone (for now at least) and handle these 
things in the driver.

/Per

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

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

On Fri, 26 Mar 2004, Lars Hecking wrote:

> 
> > OK, then I'd say go for the new driver.
> > That way I could retire the old driver sooner than expected.
>  
>  Ok, that's fine by me.

Done.  Per Persson is now a member of the gnuplot project at SF.net, and
will be considered responsible for every aspect of it involving Mac OS X.

Per: you have write access to the CVS.  Use it with care, please.

-- 
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...]

[Lars H. <lhe...@us...>]

> OK, then I'd say go for the new driver.
> That way I could retire the old driver sooner than expected.
 
 Ok, that's fine by me.

> This is the scary part...
> 
> I don't recall the exact release plan for gnuplot 4.0, but IIRC it is 
> more or less right away, no?
> 
> I'm really busy until mid April, but if someone whos is familiar with 
> gnuplot could bootstrap things and get the necessary changes(*) into 
> CVS, then I could find time to test them on OS X _before_ the next 
> release candidate.
 
 I can do that next week, and will get in touch to hammer out the details.

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

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

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

> 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?

Yes.

>
> 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.

OK, then I'd say go for the new driver.
That way I could retire the old driver sooner than expected.

> 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

No problem, I'd have to do that anyhow.

> and all other MacOS X related issues.

This is the scary part...

I don't recall the exact release plan for gnuplot 4.0, but IIRC it is 
more or less right away, no?

I'm really busy until mid April, but if someone whos is familiar with 
gnuplot could bootstrap things and get the necessary changes(*) into 
CVS, then I could find time to test them on OS X _before_ the next 
release candidate.

 From the end of April, I can commit more time to these things so, if 
these reservations are OK with you, then I accept.

>
> 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.

I like this. The __ObjC__ should probably be __HAVE_LIBAQUATERM__ since 
this stuff is for the aquaterm driver, not OS X/ObjC in general.

I'll whip up the above solution, test it and come back with a patch.

/Per

* The necessary changes is to test for Mac OS X in configure (as is 
done now)
and then check for libaquaterm
and only then set (if it is found)
LIBS="$LIBS -laquaterm -framework Foundation"
CFLAGS="$CFLAGS -ObjC"
and set a #define to be used in command.c and term.h

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.