From: Koen v. d. D. <kvd...@ea...> - 2005-11-06 12:07:08
|
Hi, How can I enable the aquaterm driver for plplot on Mac OS X, maybe something like --enable-aquaterm ? thanks, - Koen. |
From: Per P. <per...@ma...> - 2005-11-06 14:02:38
|
Hi Koen, AquaTerm should be automatically detected by configure and enabled if found, see output from configure below: [snip] checking for libgdi32 header files... not found configure: WARNING: libgdi32 header files not found, setting enable_wingcc=no checking for AquaTerm header files... found in default checking for aqtInit in -laquaterm... yes checking for dirname... dirname checking for perl... found [snip] I've noticed that Fink has split AquaTerm in several packages, and you need the headers to be installed for this to work. IIRC, you'll also need AquaTerm 1.0.0 (a.k.a latest release) since PLplot relies on shearing transforms to correct 3d-text perspectives. HTH, Per On Nov 6, 2005, at 13:07, Koen van der Drift wrote: > Hi, > > How can I enable the aquaterm driver for plplot on Mac OS X, maybe > something like --enable-aquaterm ? > > > thanks, > > - Koen. > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Koen v. d. D. <kvd...@ea...> - 2005-11-06 15:29:00
|
On Nov 6, 2005, at 9:02 AM, Per Persson wrote: > Hi Koen, > > AquaTerm should be automatically detected by configure and enabled > if found, see output from configure below: > > [snip] > checking for libgdi32 header files... not found > configure: WARNING: libgdi32 header files not found, setting > enable_wingcc=no > checking for AquaTerm header files... found in default > checking for aqtInit in -laquaterm... yes > checking for dirname... dirname > checking for perl... found > [snip] > > I've noticed that Fink has split AquaTerm in several packages, and > you need the headers to be installed for this to work. IIRC, you'll > also need AquaTerm 1.0.0 (a.k.a latest release) since PLplot relies > on shearing transforms to correct 3d-text perspectives. Thanks Per, This does only work with plplot 5.5.3, not with the current (in fink) version 5.3.1. I have been holding off to commit 5.5.3, because it doesn't compile for octave. I guess for now I will disable octave and add the aquaterm driver (which was requested by a user). cheers, - Koen. |
From: Per P. <per...@ma...> - 2005-11-06 16:23:46
|
There used to be a patch for PLplot-5.3.1 supplied with the corresponding adapter for aquaterm. In case you'd like to support AquaTerm with an older version of PLplot you can check it out from CVS by: cvs -d:pserver:ano...@cv...:/cvsroot/aquaterm login cvs -z3 -d:pserver:ano...@cv...:/cvsroot/aquaterm co -P -D "2005-07-01" adapters BTW, I've noticed that there is a (slow) memory leak in the aquaterm driver in PLplot, so you might wan't to add that to known featu^H^H^H^H^H issues in the info section. Best, Per On Nov 6, 2005, at 16:28, Koen van der Drift wrote: > > On Nov 6, 2005, at 9:02 AM, Per Persson wrote: > >> Hi Koen, >> >> AquaTerm should be automatically detected by configure and enabled >> if found, see output from configure below: >> >> [snip] >> checking for libgdi32 header files... not found >> configure: WARNING: libgdi32 header files not found, setting >> enable_wingcc=no >> checking for AquaTerm header files... found in default >> checking for aqtInit in -laquaterm... yes >> checking for dirname... dirname >> checking for perl... found >> [snip] >> >> I've noticed that Fink has split AquaTerm in several packages, and >> you need the headers to be installed for this to work. IIRC, >> you'll also need AquaTerm 1.0.0 (a.k.a latest release) since >> PLplot relies on shearing transforms to correct 3d-text perspectives. > > Thanks Per, > > This does only work with plplot 5.5.3, not with the current (in > fink) version 5.3.1. I have been holding off to commit 5.5.3, > because it doesn't compile for octave. I guess for now I will > disable octave and add the aquaterm driver (which was requested by > a user). > > > cheers, > > - Koen. > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Per P. <per...@ma...> - 2005-11-06 21:34:40
|
On Nov 6, 2005, at 19:02, Hazen Babcock wrote: > > Memory leak! Any idea what is causing it? Yes :-) I've ment to tell you, but since I only have time to work on these things quite infrequently this has slipped my mind every time... The background involves gory details of the Objective-C Foundation framework, but it is conceptually quite easy to grasp. Basically, when one creates *temporary* objects (i.e. not using alloc/ init explicitly) they belong to an "autorelease pool" and should (in theory) be released automagically when the pool is cleaned at certain intervals (the end of every event cycle). This doesn't for us work since PLplot doesn't have a "runloop" as its core, which every Cocoa app would have had since they contain an NSApplication object to handle all of this. The solution to the problem is easy. There can be any number of autorelease pools and when a new one is created it is pushed onto the top of a stack of pools. This effectively means that, from the time of its creation up until it is destroyed and popped off the stack, the most recently created pool is the owner of every temporary object instantiated. Thus, by creating our own instance of an NSAutoreleasePool, we can stop the leak. (The obvious solution to not create temporary objects isn't completely safe, since there *may* be temporary objects created implicitly, outside our control.) The implementation may howeve be a little tricky, and depends on the particular situation. Since the pools are stacked, the creation and destruction of pools must be balanced, e.g. it is not possible to have code that would lead to the following situation: pool1 = [[NSAutoreleasePool alloc] init]; ... pool2 = [[NSAutoreleasePool alloc] init]; ... [pool1 release]; // Most likely to cause a crash ... [pool2 release]; There are two typical situations with different solutions, and I'll start by examplifying the (really) easy one, which was the case with PGPLOT and a slightly more complicated strategy used in gnuplot. 1) Single point of entry There exists a *single* point of entry (and return) for the driver calls, foo(). In this case we just add a pool first thing when entering foo: void foo(...) { NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init]; // now, dispatch calls to drawing primitives ... [localPool release]; return; } 2) No single point of entry, but an init function preceeding any plotting, and a particular function call, bar(), known to preceed any new plot. In this case we just create a new pool before any new plot, after destroying the old one. static NSAutoreleasePool *globalPool; ... void init(...) { globalPool = [[NSAutoreleasePool alloc] init]; // Perform inits as usual ... return; } void bar(...) { [globalPool release]; globalPool = [[NSAutoreleasePool alloc] init]; // Now do whatever we usually do in bar() ... return; } There is no real need to release (destroy) the last pool since that will be destroyed when the application exits. It is my belief that PLplot would fall into the second category, but since I've never really looked inside PLplot, I had to find for sure out before settling on a solution, which I never got around to... Looking through the aquaterm driver, these are the places where objects are placed in the pool (which is never cleaned) Line: ----- 287: [adapter waitNextEvent] 513: [NSString stringWithCString:str] 517: [NSString stringWithCString:ofont] 538: [NSString stringWithCharacters:Greek+char_ind length:1] 547: [NSNumber numberWithInt:updown[i]] For all of these, except [adapter waitNextEvent], using the corresponding -initXXX methods, paired with a proper release, would stop the leaking, i.e.: [NSString stringWithCString:x] --> [[NSString alloc] initWithCString:x] [NSString stringWithCharacters:x length:n] --> [[NSString alloc] initWithCharacters:x length:n] [NSNumber numberWithInt:x] --> [[NSNumber alloc] initWithInt:x] Even so, I still think that the proper thing to do is to make sure the pool gets cleaned every now and then ;-) Hope this makes sense... Per PS. I'm cc:ing the PLplot list just in case anyone wonders about this... PPS. The reason this leak passed unnoticed is probably because Objective-C objects are lightweight, about the size of the string/ number + approx 20 bytes IIRC, and it would take a while before it hurts a computer with some 100MB of memory. PPPS. The NSPoint/NSRange/NSSize and others are, despite their names, not objects but simple C-structs and thus not affected. > > -Hazen > > On Nov 6, 2005, at 11:23 AM, Per Persson wrote: > >> There used to be a patch for PLplot-5.3.1 supplied with the >> corresponding adapter for aquaterm. In case you'd like to support >> AquaTerm with an older version of PLplot you can check it out from >> CVS by: >> >> cvs -d:pserver:ano...@cv...:/cvsroot/aquaterm login >> cvs -z3 -d:pserver:ano...@cv...:/cvsroot/aquaterm >> co -P -D "2005-07-01" adapters >> >> BTW, I've noticed that there is a (slow) memory leak in the >> aquaterm driver in PLplot, so you might wan't to add that to known >> featu^H^H^H^H^H issues in the info section. >> >> Best, >> Per >> >> >> On Nov 6, 2005, at 16:28, Koen van der Drift wrote: >> >>> >>> On Nov 6, 2005, at 9:02 AM, Per Persson wrote: >>> >>>> Hi Koen, >>>> >>>> AquaTerm should be automatically detected by configure and >>>> enabled if found, see output from configure below: >>>> >>>> [snip] >>>> checking for libgdi32 header files... not found >>>> configure: WARNING: libgdi32 header files not found, setting >>>> enable_wingcc=no >>>> checking for AquaTerm header files... found in default >>>> checking for aqtInit in -laquaterm... yes >>>> checking for dirname... dirname >>>> checking for perl... found >>>> [snip] >>>> >>>> I've noticed that Fink has split AquaTerm in several packages, >>>> and you need the headers to be installed for this to work. IIRC, >>>> you'll also need AquaTerm 1.0.0 (a.k.a latest release) since >>>> PLplot relies on shearing transforms to correct 3d-text >>>> perspectives. >>> >>> Thanks Per, >>> >>> This does only work with plplot 5.5.3, not with the current (in >>> fink) version 5.3.1. I have been holding off to commit 5.5.3, >>> because it doesn't compile for octave. I guess for now I will >>> disable octave and add the aquaterm driver (which was requested >>> by a user). >>> >>> >>> cheers, >>> >>> - Koen. >>> >>> >>> ------------------------------------------------------- >>> SF.Net email is sponsored by: >>> Tame your development challenges with Apache's Geronimo App >>> Server. Download >>> it for free - -and be entered to win a 42" plasma tv or your very >>> own >>> Sony(tm)PSP. Click here to play: http://sourceforge.net/ >>> geronimo.php >>> _______________________________________________ >>> Plplot-devel mailing list >>> Plp...@li... >>> https://lists.sourceforge.net/lists/listinfo/plplot-devel >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: >> Tame your development challenges with Apache's Geronimo App >> Server. Download >> it for free - -and be entered to win a 42" plasma tv or your very own >> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: <hba...@ma...> - 2005-11-13 19:42:08
|
Ok, I think that I fixed the problem using approach (2). The auto-release pool is now released and re-initialized after every new plot. Could you check this for me when you get a chance? What are you using to measure memory usage anyway? -Hazen On Sunday, November 06, 2005, at 01:34PM, Per Persson <per...@ma...> wrote: >On Nov 6, 2005, at 19:02, Hazen Babcock wrote: >> >> Memory leak! Any idea what is causing it? > >Yes :-) >I've ment to tell you, but since I only have time to work on these >things quite infrequently this has slipped my mind every time... > >The background >involves gory details of the Objective-C Foundation framework, but it >is conceptually quite easy to grasp. >Basically, when one creates *temporary* objects (i.e. not using alloc/ >init explicitly) they belong to an "autorelease pool" and should (in >theory) be released automagically when the pool is cleaned at certain >intervals (the end of every event cycle). This doesn't for us work >since PLplot doesn't have a "runloop" as its core, which every Cocoa >app would have had since they contain an NSApplication object to >handle all of this. > >The solution >to the problem is easy. There can be any number of autorelease pools >and when a new one is created it is pushed onto the top of a stack of >pools. This effectively means that, from the time of its creation up >until it is destroyed and popped off the stack, the most recently >created pool is the owner of every temporary object instantiated. >Thus, by creating our own instance of an NSAutoreleasePool, we can >stop the leak. (The obvious solution to not create temporary objects >isn't completely safe, since there *may* be temporary objects created >implicitly, outside our control.) > >The implementation >may howeve be a little tricky, and depends on the particular >situation. Since the pools are stacked, the creation and destruction >of pools must be balanced, e.g. it is not possible to have code that >would lead to the following situation: > >pool1 = [[NSAutoreleasePool alloc] init]; >... >pool2 = [[NSAutoreleasePool alloc] init]; >... >[pool1 release]; // Most likely to cause a crash >... >[pool2 release]; > >There are two typical situations with different solutions, and I'll >start by examplifying the (really) easy one, which was the case with >PGPLOT and a slightly more complicated strategy used in gnuplot. >1) Single point of entry >There exists a *single* point of entry (and return) for the driver >calls, foo(). In this case we just add a pool first thing when >entering foo: > >void foo(...) { > NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init]; > // now, dispatch calls to drawing primitives > ... > [localPool release]; > return; >} > >2) No single point of entry, but an init function preceeding any >plotting, and a particular function call, bar(), known to preceed any >new plot. In this case we just create a new pool before any new plot, >after destroying the old one. > >static NSAutoreleasePool *globalPool; >... >void init(...) { > globalPool = [[NSAutoreleasePool alloc] init]; > // Perform inits as usual > ... > return; >} > >void bar(...) { > [globalPool release]; > globalPool = [[NSAutoreleasePool alloc] init]; > // Now do whatever we usually do in bar() > ... > return; >} > >There is no real need to release (destroy) the last pool since that >will be destroyed when the application exits. > >It is my belief that PLplot would fall into the second category, but >since I've never really looked inside PLplot, I had to find for sure >out before settling on a solution, which I never got around to... > >Looking through the aquaterm driver, these are the places where >objects are placed in the pool (which is never cleaned) >Line: >----- >287: [adapter waitNextEvent] >513: [NSString stringWithCString:str] >517: [NSString stringWithCString:ofont] >538: [NSString stringWithCharacters:Greek+char_ind length:1] >547: [NSNumber numberWithInt:updown[i]] > >For all of these, except [adapter waitNextEvent], using the >corresponding -initXXX methods, paired with a proper release, would >stop the leaking, i.e.: >[NSString stringWithCString:x] --> [[NSString alloc] initWithCString:x] >[NSString stringWithCharacters:x length:n] --> [[NSString alloc] >initWithCharacters:x length:n] >[NSNumber numberWithInt:x] --> [[NSNumber alloc] initWithInt:x] > >Even so, I still think that the proper thing to do is to make sure >the pool gets cleaned every now and then ;-) > >Hope this makes sense... >Per > >PS. I'm cc:ing the PLplot list just in case anyone wonders about this... >PPS. The reason this leak passed unnoticed is probably because >Objective-C objects are lightweight, about the size of the string/ >number + approx 20 bytes IIRC, and it would take a while before it >hurts a computer with some 100MB of memory. >PPPS. The NSPoint/NSRange/NSSize and others are, despite their names, >not objects but simple C-structs and thus not affected. > |
From: Per P. <per...@ma...> - 2005-11-13 20:08:25
|
On Nov 13, 2005, at 20:42, hba...@ma... wrote: > > > Ok, I think that I fixed the problem using approach (2). The auto- > release pool is now released and re-initialized after every new plot. > Could you check this for me when you get a chance? Excellent! I'll have a look things later this week. > What are you using to measure memory usage anyway? As a first measure, I use "top", see "man top". Run PLplot in a loop producing plots and keep an eye on memory usage. Then, there are som undocumented methods in NSAutoreleasePool: [NSAutoreleasePool autoreleasedObjectCount] [NSAutoreleasePool topAutoreleasePoolCount] which are pretty handy. Googling should provide some more info on them. There are a number of system settings to debug stuff too, like (quoting from the link below) > NSZombieEnabled > If set to YES, deallocated objects are 'zombified'; this allows you > to quickly debug problems where you send a message to an object > that has already been freed; see below for details > > NSEnableAutoreleasePool > If set to NO, autorelease pools do not release objects in the pool > when the pool is released > > NSAutoreleaseHighWaterMark > If set to X, autorelease pools will print a message if more than X > objects accumulate in the pool These are documented in NSDebug.h See e.g. http://developer.apple.com/technotes/tn2004/tn2124.html for an overview of debugging aids. Thanks, Per > > -Hazen > > On Sunday, November 06, 2005, at 01:34PM, Per Persson > <per...@ma...> wrote: > >> On Nov 6, 2005, at 19:02, Hazen Babcock wrote: >>> >>> Memory leak! Any idea what is causing it? >> >> Yes :-) >> I've ment to tell you, but since I only have time to work on these >> things quite infrequently this has slipped my mind every time... >> >> The background >> involves gory details of the Objective-C Foundation framework, but it >> is conceptually quite easy to grasp. >> Basically, when one creates *temporary* objects (i.e. not using >> alloc/ >> init explicitly) they belong to an "autorelease pool" and should (in >> theory) be released automagically when the pool is cleaned at certain >> intervals (the end of every event cycle). This doesn't for us work >> since PLplot doesn't have a "runloop" as its core, which every Cocoa >> app would have had since they contain an NSApplication object to >> handle all of this. >> >> The solution >> to the problem is easy. There can be any number of autorelease pools >> and when a new one is created it is pushed onto the top of a stack of >> pools. This effectively means that, from the time of its creation up >> until it is destroyed and popped off the stack, the most recently >> created pool is the owner of every temporary object instantiated. >> Thus, by creating our own instance of an NSAutoreleasePool, we can >> stop the leak. (The obvious solution to not create temporary objects >> isn't completely safe, since there *may* be temporary objects created >> implicitly, outside our control.) >> >> The implementation >> may howeve be a little tricky, and depends on the particular >> situation. Since the pools are stacked, the creation and destruction >> of pools must be balanced, e.g. it is not possible to have code that >> would lead to the following situation: >> >> pool1 = [[NSAutoreleasePool alloc] init]; >> ... >> pool2 = [[NSAutoreleasePool alloc] init]; >> ... >> [pool1 release]; // Most likely to cause a crash >> ... >> [pool2 release]; >> >> There are two typical situations with different solutions, and I'll >> start by examplifying the (really) easy one, which was the case with >> PGPLOT and a slightly more complicated strategy used in gnuplot. >> 1) Single point of entry >> There exists a *single* point of entry (and return) for the driver >> calls, foo(). In this case we just add a pool first thing when >> entering foo: >> >> void foo(...) { >> NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init]; >> // now, dispatch calls to drawing primitives >> ... >> [localPool release]; >> return; >> } >> >> 2) No single point of entry, but an init function preceeding any >> plotting, and a particular function call, bar(), known to preceed any >> new plot. In this case we just create a new pool before any new plot, >> after destroying the old one. >> >> static NSAutoreleasePool *globalPool; >> ... >> void init(...) { >> globalPool = [[NSAutoreleasePool alloc] init]; >> // Perform inits as usual >> ... >> return; >> } >> >> void bar(...) { >> [globalPool release]; >> globalPool = [[NSAutoreleasePool alloc] init]; >> // Now do whatever we usually do in bar() >> ... >> return; >> } >> >> There is no real need to release (destroy) the last pool since that >> will be destroyed when the application exits. >> >> It is my belief that PLplot would fall into the second category, but >> since I've never really looked inside PLplot, I had to find for sure >> out before settling on a solution, which I never got around to... >> >> Looking through the aquaterm driver, these are the places where >> objects are placed in the pool (which is never cleaned) >> Line: >> ----- >> 287: [adapter waitNextEvent] >> 513: [NSString stringWithCString:str] >> 517: [NSString stringWithCString:ofont] >> 538: [NSString stringWithCharacters:Greek+char_ind length:1] >> 547: [NSNumber numberWithInt:updown[i]] >> >> For all of these, except [adapter waitNextEvent], using the >> corresponding -initXXX methods, paired with a proper release, would >> stop the leaking, i.e.: >> [NSString stringWithCString:x] --> [[NSString alloc] >> initWithCString:x] >> [NSString stringWithCharacters:x length:n] --> [[NSString alloc] >> initWithCharacters:x length:n] >> [NSNumber numberWithInt:x] --> [[NSNumber alloc] initWithInt:x] >> >> Even so, I still think that the proper thing to do is to make sure >> the pool gets cleaned every now and then ;-) >> >> Hope this makes sense... >> Per >> >> PS. I'm cc:ing the PLplot list just in case anyone wonders about >> this... >> PPS. The reason this leak passed unnoticed is probably because >> Objective-C objects are lightweight, about the size of the string/ >> number + approx 20 bytes IIRC, and it would take a while before it >> hurts a computer with some 100MB of memory. >> PPPS. The NSPoint/NSRange/NSSize and others are, despite their names, >> not objects but simple C-structs and thus not affected. >> > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Koen v. d. D. <kvd...@ea...> - 2005-11-06 23:28:19
|
On Nov 6, 2005, at 11:23 AM, Per Persson wrote: > There used to be a patch for PLplot-5.3.1 supplied with the > corresponding adapter for aquaterm. In case you'd like to support > AquaTerm with an older version of PLplot you can check it out from > CVS by: > > cvs -d:pserver:ano...@cv...:/cvsroot/aquaterm login > cvs -z3 -d:pserver:ano...@cv...:/cvsroot/aquaterm > co -P -D "2005-07-01" adapters > Hi Per, Thanks for the help. I already got a user report that the device gives the following error: Everything compiled/built fine but I got an error when I tried to use the device: <14> aqt AquaTerm (Mac OS X) Enter device number or keyword: 14 plLibOpenPdfstr: Found file /opt/fink/share/plplot5.5.3/plxtnd5.fnt 2005-11-06 17:15:17.737 PHY380 (Rosa) Homework n[7935] *** - [AQTAdapter addLabel:atPoint:angle:shearAngle:align:]: selector not recognized [self = 0x604810] 2005-11-06 17:15:17.739 PHY380 (Rosa) Homework n[7935] *** Uncaught exception: <NSInvalidArgumentException> *** -[AQTAdapter addLabel:atPoint:angle:shearAngle:align:]: selector not recognized [self = 0x604810] Trace/BPT trap Any idea what could be the problem? thanks, - Koen. |
From: Per P. <per...@ma...> - 2005-11-07 06:03:54
|
On Nov 7, 2005, at 00:28, Koen van der Drift wrote: > [AQTAdapter addLabel:atPoint:angle:shearAngle:align:]: selector not > recognized [self = 0x604810] > 2005-11-06 17:15:17.739 PHY380 (Rosa) Homework n[7935] *** > Uncaught exception: <NSInvalidArgumentException> *** -[AQTAdapter > addLabel:atPoint:angle:shearAngle:align:]: selector not recognized > [self > = 0x604810] > Trace/BPT trap > > > Any idea what could be the problem? Yes, you need a more recent version of AquaTerm than the one Fink supplies. You need the 1.0.0 release, not any of the alpha/beta versions. I did point that out in my first reply, but I now realize that I could have said it more clearly. /Per |