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.