00:23:59 Fare [~Fare@24-176-255-130.static.reno.nv.charter.com] has joined #sbcl 00:27:54 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 00:52:48 Blkt` [~user@dynamic-adsl-94-34-45-254.clienti.tiscali.it] has joined #sbcl 00:52:49 -!- rbarraud [~rbarraud@118-93-187-24.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 265 seconds] 00:54:45 -!- Blkt [~user@dynamic-adsl-94-34-40-93.clienti.tiscali.it] has quit [Ping timeout: 265 seconds] 01:17:41 -!- Fare [~Fare@24-176-255-130.static.reno.nv.charter.com] has quit [Quit: Leaving] 01:23:16 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 01:29:19 -!- nyef [~nyef@pool-64-222-178-106.man.east.myfairpoint.net] has quit [Quit: G'night all.] 01:40:15 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 01:40:29 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has left #sbcl 01:43:24 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 02:11:24 -!- jweiss [~weissj@cpe-069-134-025-078.nc.res.rr.com] has quit [Read error: Operation timed out] 02:16:31 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 03:38:36 -!- Blkt` [~user@dynamic-adsl-94-34-45-254.clienti.tiscali.it] has quit [Quit: Error: do not makunbound t please!] 03:46:03 joekarma [~joekarma@S0106001b63ab3433.vc.shawcable.net] has joined #sbcl 03:59:51 -!- ignotus [~ignotus@unaffiliated/ignotus] has quit [Quit: Coyote finally caught me] 04:52:29 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 04:52:29 -!- ChanServ has set mode +o nikodemus 05:20:31 -!- ASau`` is now known as ASau 05:24:37 -!- ebzzry [~ebzzry@203.213.202.186] has quit [Quit: Leaving] 05:31:31 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 05:31:49 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has left #sbcl 05:46:13 stassats [~stassats@wikipedia/stassats] has joined #sbcl 05:54:22 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 05:59:22 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 05:59:22 -!- ChanServ has set mode +o nikodemus 06:48:19 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 07:01:49 -!- tmi [~tmi@198.80-202-113.nextgentel.com] has quit [Read error: Operation timed out] 07:08:51 -!- cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has quit [Ping timeout: 265 seconds] 07:09:18 cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has joined #sbcl 07:25:12 tmi [~tmi@213.166.184.138] has joined #sbcl 07:37:40 oh great, unknown LOOP keyword: OF-TYPE current LOOP context: OF-TYPE FIXNUM. 07:46:49 -!- Krystof [~csr21@csrhodes.plus.com] has quit [Ping timeout: 252 seconds] 08:06:23 http://paste.lisp.org/display/115684 08:06:43 Yet another memory fault; I'm still sitting in the debugger in case everyone wants me to do something 08:14:49 tcr: memory fault during gc is a virtually certain sign of heap corruption. while looking at the memory in detail may help identify the issue, whatever broke it is already in the past 08:15:23 sorry for not being able to help more right now 08:16:11 nikodemus: the recent loop change broke it, i had to reopen the ticket 08:18:46 nikodemus: How can I look at the memory in detail? 08:19:57 And why is address different in the corruption warning and the error handler? What triggers the corruption warning? 08:20:45 sigsegv? 08:21:58 tcr: gdb 08:22:38 tcr: the address is likely different because the way it is passed from C to lisp is ... really, really stupid 08:22:54 so I should chase up the one reported in the corruption warning? 08:23:08 tcr: that is one option 08:23:45 what else? 08:23:52 but hard work, and requires you to figure out what lisp object a stuff of random bytes in memory might be, what might be wrong with it, and how it might have happened 08:24:06 i would rather not do that if i can avoid it :) 08:25:15 i would start by trying to reduce the test-case. spending half a day doing that is likely more productive -- foreign calls and places with (safety 0) are the likely culprits, so removing those from your app are a start 08:25:57 how quick is the bug to reproduce? 08:26:17 and how consistent? (address & time of occurrance) 08:26:20 takes about an hour or something like that 08:26:38 this particular one I saw for the first time, but I saw memory faults on different data sets 08:26:49 are you using threads? 08:27:05 the funny thing is that it's more easily reproducible if I worked interactively and run the stuff from the repl 08:27:34 than if invoked from scratch, compiled anew 08:27:58 No we don't use threads although the sbcl is built with threads 08:28:59 ok, that's good. one complication less :) 08:29:38 first try to find a way to trigger it as quickly as possible 08:30:03 <1 minute is good, <10 minutes a must 08:32:18 Well, I will give it a try. The process can easily become i/o bound. 08:33:27 because the way i'd prefer to debug this would be by disabling parts of the code path that it occurs on, and seeing what makes a difference -- bisection on source, essentially 08:33:39 which requires a fast turnaround 08:35:40 dynamic usage 560mb, but RES in top shows 780mb  where's the difference hidden? 08:36:44 i don't understand the question. what's strange about that? 08:37:09 you have bunch of pages mapped and resident, but not currently used by live data 08:38:05 memory consumption is a big mystery to me 08:39:19 what does "used by live data" mean? mmap works lazily? 08:40:53 -!- stassats [~stassats@wikipedia/stassats] has quit [Remote host closed the connection] 08:41:07 live data in the sense of "pages SBCL thinks may hold live data" as opposed to "free pages" 08:43:55 So what's a good way to test whether we're running out of memory? Where "having enough memory" means, enough memory for a gc not to die. 09:03:29 tcr: if you don't get heap exhaustion you have enough memory? 09:03:56 i seriously doubt what you're seeing has to do with running out of memory 09:04:29 regressions, regressions, regressions :/ 09:08:29 No that was an unrelated question :-) 09:09:26 If I'm close to out of heap space, I just want to stop processing incomming connections and wait until enough of the currently being processed ones have finished 09:10:00 our stuff has to run for years without being touched :-) 09:13:40 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 09:14:43 tcr: when (dynamic-usage) > dynamic-space-size/2 the next GC might not have enough space to complete 09:14:53 I wonder if these are sensible names for predicate intrinsics: http://github.com/angavrilov/cl-simd/commit/9837681fb25475f039bd05dc13f08088b5541055#diff-4 09:14:56 -!- angavrilov_ is now known as angavrilov 09:21:26 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 09:49:54 -!- ASau [~user@77.246.230.250] has quit [*.net *.split] 09:49:55 -!- slyrus__ [~chatzilla@dsl092-019-253.sfo1.dsl.speakeasy.net] has quit [*.net *.split] 09:50:10 ASau [~user@77.246.230.250] has joined #sbcl 09:51:06 slyrus [~chatzilla@dsl092-019-253.sfo1.dsl.speakeasy.net] has joined #sbcl 09:59:31 tcr [~tcr@89-251-198-185.chess.managedbroadband.co.uk] has joined #sbcl 10:20:14 Krystof [~csr21@cpc2-dals3-0-0-cust1263.hari.cable.virginmedia.com] has joined #sbcl 10:20:14 -!- ChanServ has set mode +o Krystof 10:41:04 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 10:44:43 rbarraud [~rbarraud@118-93-187-24.dsl.dyn.ihug.co.nz] has joined #sbcl 11:21:39 nyef [~nyef@pool-64-222-178-106.man.east.myfairpoint.net] has joined #sbcl 11:21:47 G'morning all. 11:27:28 stassats [~stassats@wikipedia/stassats] has joined #sbcl 11:46:43 hi nyef 12:10:01 -!- tcr [~tcr@89-251-198-185.chess.managedbroadband.co.uk] has quit [Read error: Connection reset by peer] 12:11:31 tcr [~tcr@89-251-198-185.chess.managedbroadband.co.uk] has joined #sbcl 12:17:46 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 12:18:23 -!- _3b`` [foobar@cpe-72-179-19-4.austin.res.rr.com] has quit [Read error: Connection reset by peer] 12:18:24 _3b``` [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 12:24:33 Blkt [~user@dynamic-adsl-94-34-45-254.clienti.tiscali.it] has joined #sbcl 13:01:36 nikodemus [~nikodemus@cs181058025.pp.htv.fi] has joined #sbcl 13:01:36 -!- ChanServ has set mode +o nikodemus 13:05:03 jweiss [~weissj@cpe-069-134-025-078.nc.res.rr.com] has joined #sbcl 13:33:27 heh, lp#663260 13:34:03 lp 663260 13:34:04 https://bugs.launchpad.net/bugs/663260 13:35:23 More fun would be to document how to slam under such circumstances, even if it is fairly obvious once you're at the point that you find slam to be useful. 13:41:59 -!- tcr [~tcr@89-251-198-185.chess.managedbroadband.co.uk] has quit [Read error: No route to host] 13:42:32 nikodemus pasted "umm..." at http://paste.lisp.org/display/115697 13:42:37 tcr [~tcr@89-251-198-185.chess.managedbroadband.co.uk] has joined #sbcl 13:43:23 oh wait. i'm stupid 13:43:29 of course the second one has to be T, T 13:44:11 -!- tcr [~tcr@89-251-198-185.chess.managedbroadband.co.uk] has quit [Client Quit] 13:46:29 nothing like reporting a bug to make you realize your wetware is the buggy component :) 13:47:00 i hereby declare today The Regression Day 13:47:32 In what sense? A good day to commit stuff that might cause problems? 13:48:01 i'm caught in an infinite loop of regressions. fix one, cause another 13:48:31 my second to last commit is buggy -- it should have used PROPAGATE-FROM-SETS, not -TO-REFS 13:48:32 Welcome to hell, here's your regression-test framework. 13:50:29 i wonder if we should instate a rule "first half of release cycle" for adventurous stuff. i mean, often things end up that way anyways, but making it a rule might be helpful (in making me moderate myself -- i'm not blaming anyone else here) 13:50:57 Heck, you could instate such a rule just for your own practice. 13:51:12 I certainly don't like committing adventurous stuff late in the cycle. 13:51:58 i'm very good at convincing myself of lots of things 13:52:11 "cannot possibly fail" :-) 13:52:13 "that couldn't possibly break anything" :) 13:52:32 one way is to make a note of how many regressions you cause from patches that could not possibly go wrong 13:52:50 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 276 seconds] 13:53:25 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 13:58:08 I almost have my value-cell changes ready for review. 14:21:28 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Read error: Operation timed out] 14:21:32 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 14:25:57 Is the "cannot stack allocate value cell" notification (IR2TRAN / EMIT-MAKE-VALUE-CELL) still important if value-cells are no longer to be stack-allocated? 14:30:13 nyef: no 14:30:25 Oh, good. 14:30:39 Would you happen to know what the DEFEVENT bit is for? 14:30:50 doesn't ring a bell 14:30:58 I've seen such things in a couple of places, but never tracked down what the mechanism actually does. 14:31:31 it's just a statistics gathering thingy 14:31:34 oh right. i don't remember the details, but there's an event mechanism hidden in the compiler: "now this happened" kind of thing 14:31:38 Blkt` [~user@dynamic-adsl-78-13-250-45.clienti.tiscali.it] has joined #sbcl 14:32:53 Okay, guess I'll leave it, especially given lp 563793. 14:34:43 -!- Blkt [~user@dynamic-adsl-94-34-45-254.clienti.tiscali.it] has quit [Read error: Operation timed out] 14:37:25 tcr [~tcr@89-251-198-185.chess.managedbroadband.co.uk] has joined #sbcl 14:37:52 *froydnj* sees kcachegrind doesn't play nicely with a 1.6GB data file 14:41:10 -!- stassats [~stassats@wikipedia/stassats] has quit [Remote host closed the connection] 14:50:05 Hey, if there's a bug in Fix Released state that turns out to have only been fixed for, say, mach-based targets, is the right thing to reopen that bug, or to open a new bug? 14:51:23 no such state. reopen or make a new one -- whatever you feel is most descriptive and least hassle 14:54:57 Okay, you're clued in on the "fixed" bug, I'll just let you deal with it. :-P 14:55:09 *nyef* goes looking for coffee. 14:56:57 what fixed bug? 14:57:54 the fork() 14:58:52 ah 15:04:00 How do I get the size of the heap? 15:05:28 -!- Krystof [~csr21@cpc2-dals3-0-0-cust1263.hari.cable.virginmedia.com] has quit [Ping timeout: 252 seconds] 15:07:37 What's the difference between PHYSENV-LIVE-TN and PHYSENV-DEBUG-LIVE-TN? 15:07:51 i don't know 15:08:01 Fair enough. 15:08:15 nyef: looks like TNs that are kept live only for the debugger (elided variables, etc)? 15:09:21 And I guess the next question is, where is the difference significant? 15:13:57 Hey, is lp 520692 still valid/wanted/unfulfilled? 15:16:04 stassats [~stassats@wikipedia/stassats] has joined #sbcl 15:18:53 ... Oh. The default value for :ENCAPSULATE isn't :DEFAULT, is it? 15:19:00 How utterly confusing. 15:23:14 yeah, 520692 is still live 15:24:14 (native-namestring "*") => "*" (native-namestring #p"*") =| error 15:25:42 that doesn't feel right. native-namestring should be pathname -> native namestring, not "[ native namestring -> ] pathname -> native namestring" 15:26:07 oh, well, i'll leave it for now 15:26:22 So, I convinced myself that I didn't need to set the SC of a closed-over indirect TN that doesn't require a value-cell... Which caused the build to fail because, very occasionally, the SC /does/ need to be set. :-/ 15:29:00 Anyone? (how to get the dynamic space size) 15:30:14 (apropos "dynamic-space-start") ;; and -end 15:31:05 these lead to constants, but the dynamic space size is settable at runtime; so how does that work? 15:31:08 jsnell: doesn't take --dynamic-space-size into account, does that? 15:32:43 (define-alien-variable dynamic-space-size unsigned-long) 15:32:49 indeed, that seems to be the case 15:33:08 we should really expose that, i guess 15:44:47 -!- Blkt` [~user@dynamic-adsl-78-13-250-45.clienti.tiscali.it] has quit [Ping timeout: 276 seconds] 15:54:13 -!- tmi [~tmi@213.166.184.138] has quit [Quit: .] 15:55:48 what, i never merged lvar-typep? 15:55:50 insanity 15:56:07 (defun lvar-typep (lvar type) (csubtypep (lvar-type lvar) (if (ctype-p type) type (specifier-type type)))) 15:56:25 handy 15:57:49 except it will cause a ton of conflicts because the patch also replaces all (or at least most) of (csubtypep (lvar-type x) ...) with lvar-typep 15:58:22 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 250 seconds] 15:58:33 hm. or maybe people aren't sitting on top of deftransform and defoptimizer patches so much 16:09:11 I'm getting very hard to reproduce maximum interrupt nesting depth errors with sbcl 1.0.11. Do you remember if one possible cause was closing a standard stream? 16:38:20 sounds plausible -- but i can't say i remember 16:38:42 mega1: are saved core involved? 16:38:56 nikodemus: yes 16:39:17 were we already using FINALIZE :DONT-SAVE then? 16:39:33 we _had_ it then, but did we use it? 16:40:23 because i remember a bug caused by an fd being closed by stale finalizer 16:40:41 hmm, that's interesting 16:40:43 Okay, this time for sure on fixing up ASSIGN-LAMBDA-VAR-TNS. :-/ 16:43:05 from "git show afb56ab2865fdb72102a9bb6b2c846b7b5a6ad7e" it looks like we did 16:44:07 weelll... lookee here. sockets.lisp: (sb-ext:finalize socket (lambda () (sockint::close fd))) 16:44:16 we still have that :/ 16:44:20 heh 16:44:41 no sockets involved here 16:44:49 maybe it's sigpipe 16:44:53 I'll check 16:45:29 mega1: alien memory freed by a stale finalizer is always fun too -- especially if malloc does randomization so it's not consistent 16:46:29 it's for the google ai contest and I'm not using much code 16:46:35 no alien 16:49:32 mega1: wait. max interrupts or infinite error protector? 16:49:39 max interrupts 16:49:41 ok 16:50:08 type-errors during printing, maybe? 16:50:23 try to report the error, hit the same type-error again, etc 16:50:57 no, that should be caught by infinite-error stuff 16:51:02 That'd hit the error-prote... yeah. 16:53:57 I seem to recall being bitten by this but alas forgot the everything else. 16:54:31 how do I storm the leaderboard when it keeps forfeiting games? :-) 16:56:09 is source-size limited? could you sneakily build a fresh sbcl as part of your setup? :P 16:57:22 there is an open issue for them to upgrade sbcl 16:57:48 I doubt they'll get around to it given all the problems they have with the servers. 16:58:09 plus, they had thought that compilation need not be sandboxed ... 16:58:56 now they now that lisp has compile time eval and even told me that "it had to be fixed" 16:59:06 ... Can you hot-patch the system to do the right thing? 16:59:27 heh 17:00:25 Over the past few days, I've gained a new appreciation for just going in and recompiling parts of the compiler at runtime... And an appreciation for how /bad/ our debugging support can be at times. 17:00:26 I'll resubmit as white-hat. 17:00:51 (Yes gods is TRACE a nightmare.) 17:01:52 Krystof [~csr21@csrhodes.plus.com] has joined #sbcl 17:01:52 -!- ChanServ has set mode +o Krystof 17:03:43 1.0.26 seems to have had a slew of interrupt fixes -- your, of course :) 17:15:44 Okay, http://repo.or.cz/w/sbcl/nyef.git/shortlog/refs/heads/implicit-closure-value-cells is ready for review. I'm not entirely convinced about the change to locall, but the rest should be good. 17:16:25 Fixes bugs 586103 and 308934. 17:18:09 nyef: so, DX closures also get a pointer to the parent's FP? 17:18:55 Actually, one pointer per mutable closure variable. 17:19:15 But that's an optimization to fix later. 17:19:27 And it's instead of having a pointer to a VALUE-CELL object. 17:19:47 ok, so if I were to refer to a binding in the parent and in the grand parent, it wouldn't traverse a chain of two pointers. 17:19:57 cool. Much nicer than a DX value cell. 17:20:06 Right, you'd have two different frame pointers to use in your closure environment. 17:21:12 In a way, it's treating the originating frame as the DX value cell. 17:21:58 ... And I learned an awful lot about IR1 while doing this, which is nice. 17:22:33 that's pretty awesome. 17:22:58 course, that makes future plans to change the GC a bit more complex. 17:23:16 Heh. How so? 17:23:29 you have random pointers into the stack. 17:23:43 Yes, but they appear to the GC as fixnums. 17:24:04 Or were you planning to GC away some stack frames? 17:24:13 ouch. right (: 17:24:31 -!- tcr [~tcr@89-251-198-185.chess.managedbroadband.co.uk] has quit [Quit: Leaving.] 17:25:04 Not only do they look like fixnums, but they match up with frame-pointers that can be found via backtracing. 17:30:40 https://bugs.launchpad.net/sbcl/+bug/601576/comments/4 # whee 17:33:03 Ouch. 17:33:09 Good luck with that. 17:34:18 So, should I commit this branch (less the locall patch) nowish, or is it sufficiently adventurous that it should wait until after the next release? 17:35:38 nyef: i'm looking at it right now. so far it looks good, and there is still half a month to go almost.. 17:36:38 one tidbit so far: s/do-lifetime-analysis/lifetime-alalyze-p/ or lifetime-analyze -- i thought it was a macro for a second :) 17:37:22 Okay, fair enough on the variable name... But wouldn't it suddenly look like a predicate? 17:38:19 doesn't matter greatly, really. these days my personal perference would probably be lifetime-analyze 17:38:27 or needs-lifefime-analysis 17:39:12 nyef: actually, that spot is a bit odd 17:39:46 is there another place with an equivalent set of policy tests that decides if lifetime-analysis is needed? 17:40:43 I wouldn't expect so, TBH. 17:42:00 It's the sort of really weird combination of things that wouldn't have been documented in the comment if it wasn't unique. 17:43:41 i don't understand then. let and low-debug or zero debug or top speed -> do-lifetime-analysis. (not do-lifetime-analysis) -> physenv-debug-live-tn 17:44:24 oh, wait. so physenv-debug-live-tn says "keep this bloody well alive for debugging"? 17:44:28 Yup. 17:44:56 Although it's more "keep this alive enough for debugging", and the physenv-live-tn says "keep this bloody well alive". 17:45:23 ah. maybe call the variable keep-alive-for-debug then :) 17:47:02 Also a possibility. I've already worked out the inverted condition test. 17:48:30 i've looked it quickly through now, and i think it looks pretty good 17:49:07 the only thing that really springs to mind is a test-case :) 17:49:29 Bug 308934 might be a good start. 17:50:14 And maybe something that measures consing over the use of a local closure. 17:50:29 I'll see what I can come up with. 17:52:12 nikodemus pasted "does it make this non-consing?" at http://paste.lisp.org/display/115710 17:53:15 0 bytes consed? 17:53:27 ... Wait, 300.00% CPU? 17:53:29 wheee! congrats! 17:54:29 make n=1000000 if you want times to make sense 17:54:43 but that is _very_ good news 17:55:28 Yup, 0 bytes consed on the most recent version, too. 17:55:35 prior to your work it's 2 words per iteration, so... 17:55:41 Heh. I see. 17:55:49 For the value-cell, I expect. 17:55:53 yep 17:56:00 How bad is that, really? 17:56:19 did you notice the value cells we allocate for block & return-from? 17:56:20 nyef: and it works with unboxed values? 17:56:30 pkhuong: No, it doesn't. 17:56:37 pkhuong: I /did/ see that bug, though. 17:57:42 nyef: consider that lock acquisition follows that pattern, so yes, 2 words matters 17:57:58 Right, fair enough. 17:58:26 Of course, the whole "interrupt safety" of lock acquisition is still /stupid/, but whatever. 17:59:38 --> home 17:59:47 (seriously neat work!) 18:00:58 -!- nikodemus [~nikodemus@cs181058025.pp.htv.fi] has quit [Quit: Leaving] 18:06:22 ... no, I didn't notice value-cells involved in BLOCK and RETURN-FROM. 18:13:05 -!- cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has quit [Ping timeout: 272 seconds] 18:13:44 cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has joined #sbcl 18:21:44 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 18:23:40 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Client Quit] 18:24:29 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 18:44:50 Heh. There's a pile of crap involving DX-LET in order to stack-allocate value-cells that can die now. 18:50:21 attila_lendvai [~attila_le@adsl-89-135-205-142.monradsl.monornet.hu] has joined #sbcl 18:51:55 hooray for deleting code 19:30:11 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 276 seconds] 19:31:10 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 22:03:59 -!- attila_lendvai [~attila_le@adsl-89-135-205-142.monradsl.monornet.hu] has quit [Ping timeout: 265 seconds] 22:06:43 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 240 seconds] 22:17:11 attila_lendvai [~attila_le@adsl-89-135-205-56.monradsl.monornet.hu] has joined #sbcl 22:27:12 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 23:03:56 -!- attila_lendvai [~attila_le@adsl-89-135-205-56.monradsl.monornet.hu] has quit [Ping timeout: 265 seconds]