00:23:21 rme [~rme@50.43.190.179] has joined #ccl 00:27:59 -!- DataLinkDroid [~DataLinkD@1.145.237.140] has quit [Quit: Bye] 00:31:21 -!- [1]Skrylar [HydraIRC@cpe-70-113-115-100.austin.res.rr.com] has quit [Ping timeout: 256 seconds] 00:56:05 -!- ipmonger [~ipmonger@c-68-81-244-69.hsd1.pa.comcast.net] has quit [Quit: ipmonger] 03:03:03 -!- rme [rme@6D10F4DD.4CC8819B.699BA7A6.IP] has quit [Quit: rme] 03:03:03 -!- rme [~rme@50.43.190.179] has quit [Quit: rme] 03:05:46 [1]Skrylar [HydraIRC@cpe-70-113-115-100.austin.res.rr.com] has joined #ccl 03:06:10 -!- [1]Skrylar [HydraIRC@cpe-70-113-115-100.austin.res.rr.com] has quit [Client Quit] 03:29:59 rme [~rme@50.43.190.179] has joined #ccl 04:30:23 -!- rme [rme@6D10F4DD.4CC8819B.699BA7A6.IP] has quit [Quit: rme] 04:30:23 -!- rme [~rme@50.43.190.179] has quit [Quit: rme] 07:05:34 rsriniva [~rsriniva@117.192.108.5] has joined #ccl 07:05:51 -!- rsriniva [~rsriniva@117.192.108.5] has quit [Client Quit] 08:22:00 -!- Blkt [~user@82.84.159.26] has quit [Remote host closed the connection] 13:35:18 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 13:53:15 pjb: that works for me. Are you sure you didn't print population-contents in the listener before doing that (gc)? That stores it in * and /. To clear that cache, I usually evaluate three forms, 1, 2, & 3, before doing the (gc) 13:54:18 That clears *, **, ***, /, //, & /// of previous contents 14:21:42 billstclair: Of course, if hes using SLIME + presentations, it might still stick around  I think. 14:21:50 yes 14:22:08 Though my standard slime doesn't keep it around. Guess I don't have presentations enabled 14:22:52 Ah, theres M-x slime-clear-presentations (and M-x slime-clear-repl-variables) 15:02:00 rme [~rme@50.43.190.179] has joined #ccl 15:36:02 value # is not of the expected type (OR (OR CCL::NUMERIC-CTYPE CCL::NAMED-CTYPE CCL::MEMBER-CTYPE CCL::ARRAY-CTYPE CCL::CONS-CTYPE) CCL::CLASS-CTYPE CCL::UNION-CTYPE CCL::INTERSECTION-CTYPE CCL::FUNCTION-CTYPE CCL::UNKNOWN-CTYPE CCL::FOREIGN-CTYPE CCL::NEGATION-CTYPE CCL::HAIRY-CTYPE). 15:36:07 is that memory corruption? 15:52:21 Often means that you used a dynamic-extent object after exiting its dynamic extent 15:52:24 fare 15:52:28 Fare 15:53:14 oh. Dynamic extent. I haven't touched anything about it, but I may have broken an assumption or two. 15:53:19 thanks 15:53:52 how do lambda ... closures interact with make-thread ? 15:54:15 Don't understand the question. Why would they interact? 15:54:37 Fare: IIRC lexically bound variables are global shared state 15:54:47 I mean, if the lambda is being stack-allocated and used in another thread... boom 15:54:54 oh 15:54:55 Yes. Boom 15:55:17 how do I ensure the lambda won't be stack-allocated? 15:55:20 That would only happen with explicit dynamic-extent declarations. 15:55:25 ok 15:55:40 I'll look for such declarations, then 15:55:58 none in my own code, but I might be pushing someone else's buttons. 15:59:00 any other source of such corruption besides dynamic-extent? 16:02:49 Fare: none I know of besides memory corruption. 16:03:10 Fare: there was a bug in CCL's pclusering for compare-and-swap until very recently. That could cause strange errors. 16:03:23 I'm using chanl for interthread communication. 16:03:34 could that be related? 16:03:40 no idea 16:42:00 What about Stack overflow on temp stack. -- does that suggest anything? 16:42:24 I just updated my bordeaux-threads, too 16:54:22 The LAP code in https://github.com/sykopomp/chanl/blob/master/src/trivial-cas.lisp is not gc safe. 17:00:56 ok, the stack overflow is just the error handler looping while checking the type of the error against my *break-on-signals* 17:02:41 rme: is there an easy way to fix it? 17:14:04 I rather suspect my update of bordeaux-threads, or of cl-unicode, because the error is happening somewhere low-level in our object system. 17:14:22 I'm apparently not using the CAS feature of chanl 17:14:48 btw, I'm still using the same old proven CCL 1.8 (and will until CCL 1.9 backports 1070) 17:39:28 -!- sellout- is now known as sellout 17:42:06 nothing changed in bordeaux-threads/impl-clozure, though 18:03:49 gbyers [~gb@c-68-35-55-248.hsd1.nm.comcast.net] has joined #ccl 19:06:44 just to be sure -- ` wouldn't allocate stuff on the stack, would it? 19:42:04 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Quit: trivial-irc-0.0.4] 21:01:14 backquote generally doesn't allocate stuff; it generates calls to functions that allocate stuff. (LET* ((A `(,X . ,Y))) (DECLARE (DYNAMIC-EXTENT A)) ...) 21:03:16 or (LET* ((A (CONS X Y))) (DECLARE (DYNAMIC-EXTENT A)) ...) 21:08:44 is there a way to globally disable dynamic-extent? 21:10:22 I was hoping it was a bug in my code that SBCL would find, but SBCL ain't seeing the bug :-/ 21:10:57 so I'm falling back to thinking about a bad interaction w/ CCL specifically 21:11:19 If SBCL supports DYNAMIC-EXTENT, that'd be new. 21:12:45 AFAIK SBCL's dynamix-extent can stack-allocate closures, simple-arrays and structs 21:14:10 I wonder if it's a bug fixed in 1.9 -- has 1070 been backported? will it? what about 1069? 21:21:48 -!- Fare [fare@nat/google/x-mjgyaraosnywtaoj] has quit [Ping timeout: 264 seconds] 21:21:53 I have no idea what the bug is. Neither of the fixes for 1069 or 1070 have been backported; they've only been in the trunk for a couple of days. 21:37:10 Fare [fare@nat/google/x-jxzoropvsaghyqhn] has joined #ccl 21:50:24 I looked at the channel log. The address of the "bogus object" in the error message isn't on a stack, so that's not likely to be a direct effect of stack-allocation. 22:19:23 ok, thanks. 23:20:29 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #ccl