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

More fallout from TBOOLEAN change - hidden3d broken

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

Is there a tool (or gcc compile option) that will
double check for illegal operations on our TBOOLEANs? 

In stepping through the demos to check 3.8k.3 I found
that something very ugly has happened to hidden3d.
See "surface2.dem".

Reverting to the previous version of src/syscfg.h
made the problem go away, so this was another
bit of fallout from the TBOOLEAN change.

hidden3d.c line 817:
        casenumber = (plist[new_poly].frontfacing != 0)
            + 2 * (plist[old_poly].frontfacing != 0);

frontfacing is a TBOOLEAN.

Even worse:
            TBOOLEAN v1_inside_p, v2_inside_p;
             unsigned int classification[]
-- 
            v1_inside_p = ~ (classification[0]
                             | classification[1]
                             | classification[2]);
--
            v2_inside_p = (v1_inside_p >> 1) & 0x1;
            v1_inside_p = v1_inside_p & 0x1;

I have corrected the syntax involving frontfacing,
and changed v?_inside_p to be (unsigned int).
This fixes surface2.dem, but other problems may lurk.

           

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

Re: [Fwd: Re: V4 -final touches]

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

> >No, the FAQ location is OK -- so maybe now it is time to redirect
> >www.gnuplot.info to gnuplot.sf.net
> 
> I'd be more inclined to get the mirroring right.  If we need to
> establish different mirror than from Lars's, then we should work on
> that.  The sf site was intended for developer use, not end-user use.

 And the UCC site was intended as a stop-gap, until someone finds the
 time to set up something better at www.gnuplot.info.

[Fwd: Re: V4 -final touches]

[Clark G. <ga...@di...>]

-------- Original Message --------
Subject: Re: V4 -final touches
Date: Mon, 29 Mar 2004 13:39:51 -0500
From: Clark Gaylord <ga...@di...>
To: Petr Mikulik <mi...@ph...>

Petr Mikulik wrote:
>>        The gnuplot FAQ is available from
>>                http://www.gnuplot.info/faq/
>>
>>Maybe the FAQ source should also list
>>		http://gnuplot.sourceforge.net/faq/index.html
> 
> 
> No, the FAQ location is OK -- so maybe now it is time to redirect
> www.gnuplot.info to gnuplot.sf.net

I'd be more inclined to get the mirroring right.  If we need to
establish different mirror than from Lars's, then we should work on
that.  The sf site was intended for developer use, not end-user use.

--ckg

Re: V4 -final touches

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

>         The gnuplot FAQ is available from
>                 http://www.gnuplot.info/faq/
>
> Maybe the FAQ source should also list
> 		http://gnuplot.sourceforge.net/faq/index.html

No, the FAQ location is OK -- so maybe now it is time to redirect
www.gnuplot.info to gnuplot.sf.net

> Or better yet maybe this should be replaced with a reference to
> 		<http:///sourceforge.net/projects/gnuplot>

This page refers to the newsgroup, thus add reference to
news://comp.graphics.apps.gnuplot

---
PM

Re: V4 -final touches

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

--- Ethan Merritt <merritt@u.washington.edu> wrote:
> This is the banner message currently printed out by
> 3.8k.3
> 
>         G N U P L O T
>         Version 3.8k patchlevel 3
>         last modified Mon Mar 29 15:17:53 CEST 2004
>         System: Linux 2.4.22-26mdk
> 
>         Copyright(C) 1986 - 1993, 1999 - 2003
>         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.
> 
>         Type `help` to access the on-line reference
> manual
>         The gnuplot FAQ is available from
>                 http://www.gnuplot.info/faq/
> 
>         Send comments and requests for help to
> <inf...@da...>
>         Send bugs, suggestions and mods to
> <inf...@da...>

On Win2k you also get the following, two lines below
Send... and indented one additional space.

          Send...

           warning: no HOME found

I suspect most win users find that disquieting.

    --jab

=====
John Bollinger, CFA, CMT
www.BollingerBands.com

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

__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

V4 -final touches

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

This is the banner message currently printed out by 3.8k.3

        G N U P L O T
        Version 3.8k patchlevel 3
        last modified Mon Mar 29 15:17:53 CEST 2004
        System: Linux 2.4.22-26mdk

        Copyright(C) 1986 - 1993, 1999 - 2003
        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.

        Type `help` to access the on-line reference manual
        The gnuplot FAQ is available from
                http://www.gnuplot.info/faq/

        Send comments and requests for help to <inf...@da...>
        Send bugs, suggestions and mods to <inf...@da...>


Maybe the the copyright should be updated to include 2004?

Maybe the FAQ source should also list
		http://gnuplot.sourceforge.net/faq/index.html

Maybe <inf...@da...> should be updated to
		<gnu...@li...>
Or better yet maybe this should be replaced with a reference to 
		<http:///sourceforge.net/projects/gnuplot>

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

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