02:10:03 -!- ruru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Read error: Operation timed out] 02:12:01 kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #ccl 02:49:59 -!- milanj [~milanj_@93-87-117-61.dynamic.isp.telekom.rs] has quit [Ping timeout: 252 seconds] 03:12:43 milanj [~milanj_@93-87-117-61.dynamic.isp.telekom.rs] has joined #ccl 04:49:20 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Ping timeout: 268 seconds] 04:53:02 kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #ccl 04:58:12 Jey_ [~Jey@114.245.187.242] has joined #ccl 05:54:42 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Ping timeout: 268 seconds] 05:58:32 kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #ccl 06:40:11 -!- ddp [~ddp@93.182.131.6] has quit [Quit: ddp] 06:41:21 ddp [~ddp@93.182.131.6] has joined #ccl 07:30:48 -!- rme [rme@A955740.5174A474.699BA7A6.IP] has quit [Quit: rme] 07:30:48 -!- rme [~rme@50.43.147.52] has quit [Quit: rme] 08:31:38 -!- milanj [~milanj_@93-87-117-61.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 08:35:51 jdz [~jdz@193.206.22.97] has joined #ccl 10:59:29 -!- Jey_ [~Jey@114.245.187.242] has quit [Ping timeout: 252 seconds] 12:22:13 -!- jdz [~jdz@193.206.22.97] has quit [Ping timeout: 248 seconds] 14:48:44 milanj [~milanj_@109-93-196-193.dynamic.isp.telekom.rs] has joined #ccl 15:18:40 kilon [~kilon@ppp-94-64-180-118.home.otenet.gr] has joined #ccl 16:04:46 rme [~rme@50.43.147.52] has joined #ccl 18:41:34 -!- ddp [~ddp@93.182.131.6] has quit [Quit: ddp] 18:41:51 ddp [~ddp@93.182.131.6] has joined #ccl 19:25:27 er 19:26:20 i'm seeing a value freed that's in a finalizer, before the finalizer runs .. NOT the thing being finalized of course .. is that correct? 19:26:32 no closure? 19:28:01 Sorry, I don't understand. 19:29:55 ok so i'm wrapping freetype2 with CFFI .. i have LIBRARY and OUTLINE. if i (tg:finalize outline (lambda () .. (ft-done-outline library ptr) ..)) 19:30:17 library gets finalized before that runs 19:32:22 library is likewise finalized by (tg:finalize library () (lambda () .. (free-fn ptr) ..)) 19:33:33 (and ptr is literally different from library; i allocate a foreign object and make a wrapper, then assign the wrapper's pointer to the pointer, and reference only the pointer in the lambda) 19:40:50 I'm afraid I can't even make a guess. I don't know how tg:finalize uses ccl's termination mechanism. 19:41:05 (I assume that's what it does, anyway.) 19:41:09 oh right, was looking into that 19:42:32 (ccl:terminate-when-unreachable object (lambda (object) (declare (ignore obj)) (funcall function)) ...) 19:44:08 i'll see if i can build a simple test case in "pure" ccl 19:50:21 ddp_ [~ddp@216.243.111.165] has joined #ccl 19:51:47 -!- ddp [~ddp@93.182.131.6] has quit [Read error: Connection reset by peer] 19:51:51 -!- ddp_ is now known as ddp 19:53:24 -!- ddp [~ddp@216.243.111.165] has quit [Client Quit] 19:54:05 ddp [~ddp@216.243.111.165] has joined #ccl 19:56:49 I don't know if this is relevant, but TERMINATE-WHEN-UNREACHABLE can be called when a particular (as compared via EQ) lisp object isn't strongly referenced. Two pointers to the same address are EQL in CCL, but generally not EQ. 19:57:27 i think this problem may be due to arbitrary ordering of finalizer calls 19:57:37 which is a problem, but 19:59:21 http://pastie.org/private/okzv7urlwgrczeaclvuz5w 20:06:16 er, i could have cleaned that up a bit more, but it was transformed a bit from an initial breaking example heh 20:06:19 The GC just puts things that're eligible for finalization on a queue in the order that it finds them; lisp code wakes up after GC and processes that queue in whatever order's convenient. What order are you expecting, and why do you expect that ? 20:07:16 gbyers: i'd expect bar's finalizer first, then foo's, because foo is still referenced in bar's finalizer closure 20:08:03 ddp_ [~ddp@216.243.111.165] has joined #ccl 20:08:04 -!- ddp [~ddp@216.243.111.165] has quit [Quit: ddp] 20:08:56 -!- ddp_ is now known as ddp 20:26:16 heh 20:26:56 it's a hack, but strongly referencing the finalizer function and making it dereference itself seems to work 20:27:09 Referening a terminatable object from its or another object's termination function can't work in CCL's GC; we don't consider that to be a strong reference. Yes, that's the problem. 20:27:12 must only be ref'd by the object 20:27:59 ReferenCing, even. 20:31:11 You should be able to do what you're trying to do, I think. Referencing an object from its own termination function or creating a cycle can't work, but imposing a dependency should. 20:31:27 well 20:32:25 er .. CCL's finalizers appear to let you reference an object from its own finalizer .. it doesn't appear you can re-liven it a la smalltalk, but .. i may be misunderstanding what you mean 20:32:33 Could you open a ticket ? I'm busy with something else at the moment, but I think that this is a fairly simple change. 20:33:08 the problem seems that the closure itself is only ref'd by the object, therefore nothing the LAMBDA references is considered strongly-referenced if the OBJECT isn't...? 20:33:26 sure! 20:35:54 -!- ddp [~ddp@216.243.111.165] has quit [Read error: Connection reset by peer] 20:36:04 ddp [~ddp@216.243.111.165] has joined #ccl 20:58:08 -!- ddp [~ddp@216.243.111.165] has quit [Quit: ddp] 20:58:16 ddp [~ddp@216.243.111.165] has joined #ccl 22:19:41 -!- kilon [~kilon@ppp-94-64-180-118.home.otenet.gr] has quit [Remote host closed the connection] 22:46:06 kilon [~kilon@ppp-94-64-180-118.home.otenet.gr] has joined #ccl