As I mentioned on a previous post, I was annoyed by the following message (about thousands of them):
*** _NSAutoreleaseNoPool(): Object 0xa00545d0 of class NSCFString autoreleased with no pool in place - just leaking
It seems that for hello-world example just using:
(defparameter *pool* (invoke (invoke 'ns-autorelease-pool alloc) init))
at the beginning is sufficient. I suspect that it would *considerably* affect the rapidity the first run. Currently it takes about 10 minutes to do it, spending 75% or more of its time to print log errors. I'm neither a lisp or an objective-C expert, so I don't know what would be the better practice. objective-cl project seems to have some guidelines for this. I'll check this week if I could be inspired by it.
Hi,
2008/5/7 Jean-Philippe Barette-LaPierre jpbarrette@gmail.com:
It seems that for hello-world example just using:
(defparameter *pool* (invoke (invoke 'ns-autorelease-pool alloc) init))
at the beginning is sufficient.
Yes, that should do the trick. Memory-management-wise, it's probably not much better than letting all top-level objects leak, but I'm not aware of any better way, either.
objective-cl project seems to have some guidelines for this.
Objective-CL does essentially the same thing as above (albeit very early on at initialisation time, as should be done; see Objective-C/libobjcl.m, function objcl_initialise_runtime), but it also automatically releases objects that are no longer used from the Lisp side (that is, it integrates the Lisp GC with Objective-C's reference counting scheme). Still, if you're writing a console app using the Foundation framework, you'll need to manage autorelease pools yourself, just as in Objective-C. There's no way around that, as far as I can tell. On the other hand, if you're writing GUI applications, AppKit is supposed to manage autorelease pools for you.
For details see: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concept...
Hope this helps, Matthias (Objective-CL maintainer)