I know that some person had troubles with Mac OS X 10.5. After some investigations, I found the problem. It seems that in get-class-ordered-list, which is responsible to gather all classes, it was entering an infinite loop. The loop was there because it was trying to load a class "Protocol", which has "Protocol" class as Protocol. So, loading "Protocol" class caused to load again "Protocol", which didn't had been registered yet. I just delayed the initialization of :protocols.
The other problem was related to coersing some pointers. However I don't know why it was needed, and it seems to go well without it. There's an another latent problem where I get all those messages:
_NSAutoreleaseNoPool(): Object 0x142c60 of class NSCFArray autoreleased with no pool in place - just leaking
I'm looking into that.
BTW, I'm a newcomer to lisp so, you might want to edit the patch to make it "cleaner"
Yeah, that would be me, if not someone else as well. I had kinda given up on it, since I hadn't heard anything in months. I didn't know where to look really to try and fix it as I'm really new to lisp myself. Thanks for working on it. I'll have to take a look at it again when I can get the chance to take a break and play with it again.
Thanks Jeremy Shoemaker
On Tue, May 6, 2008 at 6:28 PM, Jean-Philippe Barette-LaPierre < jpbarrette@gmail.com> wrote:
I know that some person had troubles with Mac OS X 10.5. After some investigations, I found the problem.
"Jean-Philippe Barette-LaPierre" jpbarrette@gmail.com writes:
I know that some person had troubles with Mac OS X 10.5. After some investigations, I found the problem. It seems that in get-class-ordered-list, which is responsible to gather all classes, it was entering an infinite loop. The loop was there because it was trying to load a class "Protocol", which has "Protocol" class as Protocol. So, loading "Protocol" class caused to load again "Protocol", which didn't had been registered yet. I just delayed the initialization of :protocols.
Cool! Applied.
As the patch broke the support of Tiger :-( i created another repository named cl-objc-leopard. I also added you to the list of author on the website
I also created another repository named cl-objc-libffi with my last patches and the support of libffi, a little step forward the integration with objective-cl.
The other problem was related to coersing some pointers. However I don't know why it was needed, and it seems to go well without it. There's an another latent problem where I get all those messages:
_NSAutoreleaseNoPool(): Object 0x142c60 of class NSCFArray autoreleased with no pool in place - just leaking
I know this issue, but I think it is good to let the user to choose the release policy to adopt. Maybe It would be better to show the different uses in an example.
On Tue, May 20, 2008 at 12:06 PM, Luigi Panzeri matley@muppetslab.org wrote:
"Jean-Philippe Barette-LaPierre" jpbarrette@gmail.com writes:
I know that some person had troubles with Mac OS X 10.5. After some investigations, I found the problem. It seems that in get-class-ordered-list, which is responsible to gather
all
classes, it was entering an infinite loop. The loop was there because it was trying to load a class "Protocol",
which
has "Protocol" class as Protocol. So, loading "Protocol" class caused to load again "Protocol", which
didn't
had been registered yet. I just delayed the initialization of :protocols.
Cool! Applied.
As the patch broke the support of Tiger :-( i created another repository named cl-objc-leopard. I also added you to the list of author on the website
I also created another repository named cl-objc-libffi with my last patches and the support of libffi, a little step forward the integration with objective-cl.
The other problem was related to coersing some pointers. However I don't know why it was needed, and it seems to go well without it. There's an another latent problem where I get all those messages:
_NSAutoreleaseNoPool(): Object 0x142c60 of class NSCFArray autoreleased
with
no pool in place - just leaking
I know this issue, but I think it is good to let the user to choose the release policy to adopt. Maybe It would be better to show the different uses in an example.
Well the problem occurs when generating frameworks. So it means that when we are "asdf-intall"ing it leaks and we end up with HUGE amount of memory usage (1 or 2 gigs or resident memory). I patched generate-frameworks to use a memory pool. I'll send the patch as soon as I get home.
-- Luigi Panzeri aka Matley
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Quotes on Lisp: http://lispers.org/ _______________________________________________ cl-objc-devel mailing list cl-objc-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-objc-devel
On Tue, May 20, 2008 at 12:06 PM, Luigi Panzeri matley@muppetslab.org wrote:
"Jean-Philippe Barette-LaPierre" jpbarrette@gmail.com writes:
I know that some person had troubles with Mac OS X 10.5. After some investigations, I found the problem. It seems that in get-class-ordered-list, which is responsible to gather
all
classes, it was entering an infinite loop. The loop was there because it was trying to load a class "Protocol",
which
has "Protocol" class as Protocol. So, loading "Protocol" class caused to load again "Protocol", which
didn't
had been registered yet. I just delayed the initialization of :protocols.
Cool! Applied.
As the patch broke the support of Tiger :-( i created another repository named cl-objc-leopard. I also added you to the list of author on the website
Thanks! Can you put jpb(at)rrette(dot)com instead?
I also created another repository named cl-objc-libffi with my last patches and the support of libffi, a little step forward the integration with objective-cl.
The other problem was related to coersing some pointers. However I don't know why it was needed, and it seems to go well without it. There's an another latent problem where I get all those messages:
_NSAutoreleaseNoPool(): Object 0x142c60 of class NSCFArray autoreleased
with
no pool in place - just leaking
I know this issue, but I think it is good to let the user to choose the release policy to adopt. Maybe It would be better to show the different uses in an example.
-- Luigi Panzeri aka Matley
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Quotes on Lisp: http://lispers.org/ _______________________________________________ cl-objc-devel mailing list cl-objc-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-objc-devel
-
Jean-Philippe Barette-LaPierre -
Jeremy Shoemaker -
Luigi Panzeri