Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2004-03-26 12:00:29
|
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. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-03-26 13:12:09
|
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. |
|
From: Per P. <per...@ma...> - 2004-03-26 15:42:19
|
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 |
|
From: Lars H. <lhe...@us...> - 2004-03-26 16:08:39
|
> 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. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-03-26 16:51:09
|
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. |
|
From: Per P. <per...@ma...> - 2004-03-28 21:36:11
|
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 |
|
From: Lars H. <lhe...@us...> - 2004-03-29 11:56:53
|
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. |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-03-31 00:22:46
|
On Tuesday 30 March 2004 01:17 pm, Per Persson wrote: > > I was a little curious about the reason for the overlap between > filled_polygon() and boxfill(), any particular reason? Two parallel projects that got incompletely merged. The boxfill() routine was added as part of Ule Gruenebaum's work to allow solid-fill and pattern-fill boxes in the existing plot styles. The filled_polygon() routine was part of Petr Mikulik's large PM3D code block that does 3D surface-plots and allows color-mapping a Z-range to a color palette. Both of these code blocks were marked as EXPERIMENTAL during much of the version 3.8 development, and were worked on by different people. In retrospect they probably should have been merged earlier, but they weren't. If nobody else tackles the job, I'll probably do it as part of general code cleanup eventually. This sort of thing can happen in particular because new features tend to get implemented first for a restricted set of terminal drivers. It is only when they are later expanded to a more complete set, or get abstracted to a higher layer of the code, that they collide. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-03-28 11:53:36
|
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. |
|
From: Per P. <per...@ma...> - 2004-03-28 21:35:59
|
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 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2004-03-29 00:17:40
|
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 |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-03-29 10:40:18
|
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.
|
|
From: Per P. <per...@ma...> - 2004-03-26 12:48:43
|
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
|
|
From: Per P. <per...@ma...> - 2004-03-27 21:50:25
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X