01:35:28 -!- antifuchs [~foobar@boots.boinkor.net] has quit [Ping timeout: 260 seconds] 01:36:55 antifuchs [~foobar@boots.boinkor.net] has joined #sbcl 01:37:44 -!- cracauer [cracauer@nat/google/x-qmvdpucxapklstws] has quit [*.net *.split] 01:42:23 cracauer [cracauer@nat/google/x-qmvdpucxapklstws] has joined #sbcl 01:52:56 -!- cracauer [cracauer@nat/google/x-qmvdpucxapklstws] has quit [*.net *.split] 01:58:05 cracauer [cracauer@nat/google/x-qmvdpucxapklstws] has joined #sbcl 04:20:31 -!- tsuru [~charlie@adsl-74-179-198-26.bna.bellsouth.net] has quit [Remote host closed the connection] 04:54:09 -!- homie [~levgue@xdsl-84-44-211-239.netcologne.de] has quit [Ping timeout: 244 seconds] 04:54:39 -!- wbooze [~wbooze@xdsl-84-44-211-239.netcologne.de] has quit [Ping timeout: 260 seconds] 06:07:48 sdemarre [~serge@91.176.179.236] has joined #sbcl 06:59:39 attila_lendvai [~attila_le@176.222.169.147] has joined #sbcl 06:59:39 -!- attila_lendvai [~attila_le@176.222.169.147] has quit [Changing host] 06:59:39 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:21:38 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 07:22:02 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 07:29:59 ^pnpuff [~aeiou@unaffiliated/pnpuff] has joined #sbcl 08:07:23 Indecipherable [~Indeciphe@41.30.67.68] has joined #sbcl 08:08:03 Cymew [~Cymew@c83-253-250-67.bredband.comhem.se] has joined #sbcl 08:09:02 INSTALL_ROOT=/opt/sbcl sh install.sh 08:09:02 .: 13: Can't open output/prefix.def 08:09:12 Damn this stupid client! 08:09:45 ok. I'm trying to build sbcl from the official tar ball and from git and both give me the error above. Any idea? 08:10:49 <^pnpuff> have you installed sbcl from sources? 08:12:40 I have a 1.0.37 installed, built from the src and the ubuntu package and then I removed the package. Now I'm trying to build 1.0.57 or 58 with that 1.0.37 08:13:49 If I was unclear, the lisp I have was built with the ubuntu package binary from source, and then the binary was removed when I had bootstrapped the source. 08:23:53 -!- Indecipherable [~Indeciphe@41.30.67.68] has quit [Quit: used jmIrc] 08:29:42 <^pnpuff> Cymew: if you're installing sbcl from sources what other ANSI-compliant Common Lisp implementation are you using to compile it? ( have you read this : http://www.sbcl.org/getting.html ) . otherwise try to install a binary. 08:30:23 <^pnpuff> see here: http://ccl.clozure.com/irc-logs/lisp/2011-01/lisp-2011.01.23.txt 08:38:12 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 08:45:12 -!- Cymew [~Cymew@c83-253-250-67.bredband.comhem.se] has quit [Remote host closed the connection] 09:12:26 Cymew [~Cymew@c83-253-250-67.bredband.comhem.se] has joined #sbcl 09:13:51 Hi again. I lot my network connectivity, so if anyone had any input on my sbcl build problems, I'll have to beg you to repeat yourself. Sorry. 09:18:52 is there a reason why you want to build it using 1.0.37? 09:31:13 Well, it's what I have. I got that last time I upgraded. 09:32:03 I realized it was a while and probably time to do it. Now I'm leaning towards using a binary distro. But, it will feel like failure. 09:46:48 lichtblau [~user@port-92-195-127-233.dynamic.qsc.de] has joined #sbcl 09:48:19 attila_lendvai [~attila_le@176.222.169.147] has joined #sbcl 09:48:20 -!- attila_lendvai [~attila_le@176.222.169.147] has quit [Changing host] 09:48:20 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:07:55 Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has joined #sbcl 10:09:56 The error you're getting doesn't look related to the vintage of the host lisp 10:11:31 make-config.sh writes an output/prefix.def file 10:11:42 (make-config.sh runs as part of the overall build) 10:12:04 if you don't have an output/prefix.def file, then maybe the build didn't in fact work 10:12:20 if you do, and root can't read it, maybe you have an exotic (or maybe default :) selinux profile? 10:12:32 Cymew: that lot was for you, in case you're not sure 10:14:54 -!- Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has quit [Read error: Connection reset by peer] 10:49:24 Krystof: Thanks. I'll see if SElinux have been turned on. That one usually causes odd problems. 10:51:42 -!- ^pnpuff [~aeiou@unaffiliated/pnpuff] has left #sbcl 11:00:59 |3b|: Patch attached to launchpad. Please test! 11:02:00 I'm leaving the test case running over breakfast just in case, but it definitely fails less quickly than before. 11:06:25 Now I feel like a fool. I read the instructions for a binary install, not how to compile from source. After compiling install.sh works just fine. 11:07:04 Thanks for leading me on the right way Krystof, with the mention of how output/prefix.def gets built. 11:07:55 Now I only have the problem that the install ran in the wrong environment and installed sbcl in /usr/local where I don't want it. Any way to do a uninstall? 11:08:25 Minor problem, though. I guess I need to compile sbcl more often so I remember how to do it... 11:31:56 bah. Too bad this fix doesn't pass the rest of the test suite though. 11:32:10 nikodemus [~nikodemus@89.27.127.210] has joined #sbcl 11:32:10 -!- ChanServ has set mode +o nikodemus 11:38:02 OK, testing attempt #2. 11:42:32 homie [~levgue@xdsl-87-79-197-170.netcologne.de] has joined #sbcl 11:43:03 wbooze [~wbooze@xdsl-87-79-197-170.netcologne.de] has joined #sbcl 11:45:15 Hi nikodemus. 11:57:23 <|3b|> threads.impure.lisp with :deferrables-unblocked-by-lock commented has been running all night without :notify-multiple breaking, so i guess it probably was related 11:57:59 <|3b|> checking patch for gc/threads stuff now 11:58:52 |3b|: thanks. Please make sure to use the second patch though, not the first. Or wait for me to push. 12:09:02 <|3b|> hmm, ran out of heap that time 12:12:50 <|3b|> on slightly different version of the gc/thread test case 12:12:52 Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has joined #sbcl 12:15:09 -!- Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has quit [Read error: Connection reset by peer] 12:21:30 -!- Cymew [~Cymew@c83-253-250-67.bredband.comhem.se] has quit [Quit: KVIrc Insomnia 4.0.0, revision: 3900, sources date: 20100125, built on: 2011-03-15 15:32:22 UTC http://www.kvirc.net/] 12:21:41 <|3b|> (sleep 1) at the end of :deferrables-unblocked-by-lock seems to make it less likely to fail 12:23:16 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 12:24:10 |3b|: pushed a "real" fix for that, too 12:25:07 <|3b|> yeah, joining instead of killing sounds reasonable too 12:32:23 <|3b|> hmm, with patch, if 2nd thread doesn't GC, it tends to leak memory and eventually run out of heap (though oddly with RES quite a bit lower than heap size in top) 12:33:21 <|3b|> not sure if something broke, or if it s just bad luck with conservative gc 12:38:20 LiamH [~healy@pool-173-73-125-152.washdc.east.verizon.net] has joined #sbcl 12:38:26 well, if it doesn't GC, it's almost a no-op, so you're creating threads as quickly as they can start, and without joining them. 12:38:41 That's _not_ "as quickly as you can" (which would lead into an mprotect error on Linux) but still very fast, meaning that there will be many threads running simultaneously. Right? 12:39:28 And what those threads will be doing there is "thread exit stuff", during which GC might not be done (?). 12:41:03 <|3b|> shouldn't be simultaneous, since it doesn't start a new one until previous sets a flag 12:42:07 until the previous one sets a flag, but not: until the previous one has exited. (Or so my thinking.) 12:43:11 <|3b|> well, it still prints the \ from the GC thread, so presumably it does GC pretty regularly 12:44:49 <|3b|> still less of a problem than the previous bug, since this is more clearly doing something silly as opposed to just being really unlucky :) 12:46:40 I really need to stop doing (or talking about) SBCL stuff for today. But how do we stand on the sb-concurrency (or missing write-protection) issues? Has anyone seen those on non-Darwin? Are they still happening? 12:46:59 *|3b|* should probably be doing 'real work' too :/ 12:49:17 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 12:49:48 <|3b|> RES is growing with (join-thread (make-thread ...)) too 12:50:07 <|3b|> and eventually out of heap 12:59:53 the problem goes away when the first thread does a :full gc instead of a normal one. It's also sufficient if every Nth thread does a GC instead of a no-op (e.g. with N = a few hundred). 13:00:53 So the non-global GC doesn't realize it's not doing anything. Maybe all the allocation regions from those fresh threads aren't being recognized as garbage and end up in older generations, and then... Well, I don't really know what I'm talking about. :-) 13:02:27 leuler [~user@p548FBB1A.dip.t-dialin.net] has joined #sbcl 13:47:47 lichtblau: thanks for cleaning up my mess. much obliged 13:48:27 lichtblau: protection issues are only on darwin as far as i know 13:48:54 as near as i've been able to tell the whole protection error is bogus 13:49:02 Silly Mac OS users. Demand a functional SBCL on their shiny devices; refuse to bisect the resulting bugs during their Sunday afternoon. 13:49:03 but i'm not 100% sure 13:51:19 there are ignore_memoryfault_on_unprotected_pages and continue_after_memoryfault_on_unprotected_pages in the c runtime to adjust behaviour in response to those 13:52:11 next thing to do to debug it would probably to add a protect/unprotect log, and see how the page state changes over time 13:52:27 I saw those variables, but can't see how it's not a bug when it happens. 13:53:00 right -- unless it's a kernel bug 13:53:43 or us doing something hinky in our mach handlers 13:53:56 (which would be a bug, of course) 13:54:37 in my case iirc i can only reproduce it when my macbook is running hot 13:58:05 last time i tried to narrow it down (and added those variables), adding almost any instrumentation made me unable to reproduce it 13:58:27 90% of the credit for the make-thread fix must go to 3b for reproducing the failure in the first place. So who's going to be the |3b| of the Mac OS bug? 13:58:59 reproducing and bisecting, I should say 14:14:05 Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has joined #sbcl 14:16:19 -!- Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has quit [Read error: Connection reset by peer] 14:27:53 ooh! 14:28:04 i have a possibly related bug in sight 14:29:46 no, wait, it's ok 14:56:43 i'm now blocked on the sb-concurrency problem on os x. is there anything i can do to help? 15:04:48 can you reproduce it reliably? 15:04:50 I don't think a single instance of the crash is too helpful. The thing to do is really to copy&paste it into a stand-alone test case (sbcl --load testcase.lisp), and then to make it fail repeatably (loop forever) and as quickly as possible. 15:05:22 i've been trying for the past hour, and could not reproduce it even once 15:05:42 Once a simple test case like that is available, either bisect down to the commit which broke it, or if it's not an SBCL change but a Mac OS 10.8.2 issue, add systematic debugging. 15:05:43 ok, what's the exciting variable? is H4ns on a scarily new OS X? 15:05:55 Krystof: yeah, on 10.8.2 15:05:57 it happens reliably here, as far as i can tell. 15:05:58 also, I like the "freeze" 15:06:20 Krystof: this is the latest osx with all patches applied. don't know if that is scary. 15:06:40 how do i run one of the test suites individually? 15:06:48 it's lucky I don't intend "1.1" to mean anything other than "we spent a bit longer looking at bugs over the last week" ... :-) 15:06:59 H4ns: sh ./run-tests.sh name-of-test-file.lisp 15:07:08 Krystof: it's a contrib test 15:07:12 :sh make-target-contrib.sh sb-concurrency" builds and tests just it 15:07:18 s/" 15:07:28 aahah. s/:/"/ 15:07:52 H4ns: can you lisppaste a few instances of the error message for reference? 15:08:11 nikodemus: sure. give me a few minutes to rebuild sbcl and then run the tests. 15:08:15 thanks 15:08:21 H4ns: If you're rebuilding anyway... 15:08:38 can you add :sb-qshow to customize-target-features.lisp? 15:08:45 'course 15:09:00 will that file be overwritten by --fancy? 15:09:47 and what precisely do i need to put in there? 15:10:28 oops, sorry 15:10:36 echo '(lambda (x) (adjoin :sb-qshow x))' >customize-target-features.lisp 15:11:27 customize-target-features.lisp is incompatible with --fancy 15:11:41 sh make.sh --with-sb-qshow --fancy 15:12:00 rebuilding now. 15:12:56 then check if the test still fails with SBCL_DYNDEBUG=fshow_signal 15:13:05 We would expect / hope for something trivial like two write protection segfaults on the same page quickly after each other or so. 15:17:53 hm. no tests failed with this new build. 15:19:00 problem solved! 15:19:03 heh 15:19:24 i guess i'll try again without the qshow feautr 15:19:27 feature 15:19:36 like i said, it's notoriously elusive the moment any instrumentation is added 15:20:47 hmm, overhead from sb-qshow is really minimal. I was (am still) tempted to enable that feature unconditionally even on non-windows. 15:21:21 It's an inline global variable access and branch that should be predicted away if the CPU knows what it's doing. 15:22:43 is it in any hot loop? 15:22:58 extern variable access is pretty slow. 15:23:34 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 15:23:35 so, what do you want me to do? rebuild with just --fancy and paste some test results? loop with qshow and hope that the error occurs with it? something else? 15:23:53 sure, it's in hot loops, but none that seemed problematic. sniff_code_object, for example. 15:24:00 attila_lendvai [~attila_le@176.222.169.147] has joined #sbcl 15:24:00 -!- attila_lendvai [~attila_le@176.222.169.147] has quit [Changing host] 15:24:00 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 15:24:23 rebuild with --fancy and paste a couple of errors for starters 15:25:04 k. 15:25:11 H4ns: have you looped often enough that crashing with qshow (without SBCL_DYNDEBUG) seems hopeless as a strategy? If so, what nikodemus says. 15:25:59 (I still think someone needs to copy&paste the test into a standalone file. But... back to R for me.) 15:26:07 lichtblau: a dozen invocations maybe, but i've already started the new build now. i'll first provide a few more crash logs, then leave it running in a loop with qshow. 15:26:20 hm. gc_stop_thread doesn't grab free_pages lock. can we end up running gc while one thread is in gencgc_handle_wp_violation? 15:28:09 yay R 15:28:13 software that I am totally not responsible for 15:28:17 (darwin's mach stuff vs. signals elsewhere could also explain why it's darwin-only if this is related) 15:31:10 nikodemus: maybe we should directly handle those in the event loop. 15:31:31 nikodemus: you mean the SIGSEGV handler doesn't defer SIG_STOP_FOR_GC? 15:32:12 Surely even Mac OS isn't so broken that sigaction doesn't work at all? 15:33:09 s/SIGSEGV/SIGBUS/ 15:33:37 the test failures occur reliably only from make.sh. 15:33:59 with make-target-contrib.sh, i don't see them. 15:34:45 here is the output from the failure when coming from make.sh right now: 15:34:46 http://paste.lisp.org/display/132185 15:38:09 stack_allocation_recover... 15:38:54 Is that an artifact in the stacktrace, or are we actually sitting at the popl %ebp? 15:39:24 (gdb?) 15:43:49 the problem does not reliably occur from make.sh either 15:43:50 H4ns: As a C++ programmer, I'm guessing that it would be fun for you to dig around in gdb for us a little? :-) 15:44:18 i can't say that i'm very keen on that. 15:44:35 but if you provide me with specific instructions, i'll do it. 15:45:27 Well, just the disassembly from the instruction that gets hit by the SIGBUS would be nice. Basically crash SBCL, run gdb --pid $(pidof sbcl), see what frame 4 (or so) looks like. 15:46:07 by "crash sbcl", what do you mean? 15:46:27 Well, the pid 4493 from the paste isn't running any more, is it? 15:47:45 Not that I have any idea what that function does or whether it's in the stack trace for a reason. But it's clearly Darwin-specific, so... 15:47:58 nyef would know... 15:48:22 *lichtblau* was about to blame slyrus :-) 15:48:22 but to keep sbcl alive after crash make-target-contrib.sh needs to be edited a bit 15:48:26 it the workaround for our mmap leak 15:49:51 H4ns: if you open contrib/sb-concurrency/sb-concurrency.asd, and stick say (loop repeat 100 do ...) around (asdf:oos 'asdf:test-op :sb-concurrency-tests), can you then reproduce it without doing a full build? 15:50:19 nikodemus: Well, DYNDEBUG=sleep_when_lost would take care of that, but that's only with :SB-QSHOW. 15:51:01 or even just "sh run-sbcl.sh --eval '(require :sb-concurrency)' --eval '(loop (asdf:test-system :sb-concurrency))'", maybe? 15:51:57 i got that started now. 15:52:14 i guess i'll comment out all tests except the one that causes the failure 15:54:09 ok, that's running 15:59:17 -!- leuler [~user@p548FBB1A.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 16:01:44 apparently not failing yet? 16:01:49 no 16:02:52 is each of the contrib tests run in a separate, fresh sbcl? 16:03:09 (when using make.sh) 16:04:34 yes 16:05:22 ok, so maybe i should just run the failing test and all tests before that in a loop. 16:05:30 probably 16:06:28 but since it might depend on some strange whole-system timing issue, you can also try building and testing all the contribs with "sh make-target-contrib.sh" 16:06:31 is the contrib compiled within the same lisp that runs it? 16:06:37 yes 16:07:50 compiling the controbs alone does not trigger the problem either. 16:07:55 nice one :( 16:08:34 aaarg 16:08:45 oh, but actually, this is interesting: page.allocated: 1 16:09:46 which looks bogus to me 16:10:26 ??1 = open region 16:10:59 high bits should be zero only for free pages, which should not IIRC happen for open regions 16:15:14 Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has joined #sbcl 16:16:52 i'm running build/test of sb-concurrency in a loop in the same lisp now. has not crashed for the last 5 minutes either. 16:18:20 is the computer running notably hotter or colder than when it kept failing? 16:19:03 i don't think so - when i saw it fail, it just ran the sbcl build before. 16:19:17 (i.e. no other activity) 16:21:53 and last clean rebuild didn't cause it to fail either? 16:22:02 no. 16:22:19 -!- sdemarre [~serge@91.176.179.236] has quit [Ping timeout: 246 seconds] 16:22:29 but i can certainly rebuild again just to verify that the problem indeed does still occur. 16:22:40 that would be good 16:22:45 if you want me to. i've been running this compile/test loop for 10 minutes now without any failures. 16:23:28 humour me, and let the system cool down for a few minutes, and then try it again 16:23:51 i'll finish this one, then let it cool down. 16:23:57 sure 16:24:14 are you trying to say that my machine is broken? *waives fist* 16:24:50 i'm saying that last i tried to pin this (when i was able to reproduce it myself) it seemed sensitive to temperature 16:25:17 maybe just because a couple of Hz drop in real speed makes something interesting occur that doesn't occur otherwise 16:25:23 sure. and besides, how would a mac not be broken 16:25:28 hah 16:30:47 -!- Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has quit [Read error: Connection reset by peer] 16:32:40 I liked the olden days 16:32:48 when computers executed instructions, in order, one at a time 16:34:44 no failures on this box run hot 16:35:55 cre ~~.~ 16:51:41 -!- gko [~user@114-34-168-13.HINET-IP.hinet.net] has quit [Remote host closed the connection] 16:59:04 *sigh* 16:59:16 what part of my setup is so broken that ptsname() returns NULL? 17:01:17 (this is in my squeeze chroot, which is giving run-program failures) 17:02:05 pty stuff is something i need read up on each time i run into it. it just won't stick 17:03:07 it'll be something like the terminal is external to the chroot 17:03:12 but I have no clue what or how to fix it 17:03:37 it does occur to me that I don't need to run tests within the chroot, so let's try that 17:08:47 Krystof: you need to mount -t devpts devpts chroot/dev/pts/ 17:09:37 or share the system instance, by mount -o bind /dev/pts chroot/dev/pts 17:10:39 -!- LiamH [~healy@pool-173-73-125-152.washdc.east.verizon.net] has quit [Quit: Leaving.] 17:16:12 -!- wbooze [~wbooze@xdsl-87-79-197-170.netcologne.de] has quit [Read error: Operation timed out] 17:16:13 homie` [~levgue@xdsl-78-35-137-122.netcologne.de] has joined #sbcl 17:18:53 -!- homie [~levgue@xdsl-87-79-197-170.netcologne.de] has quit [Ping timeout: 245 seconds] 17:29:34 blkt [~user@82.84.170.179] has joined #sbcl 17:31:14 good evening everyone 17:39:02 https://github.com/nikodemus/SBCL/commit/cbd8748644083eed3121e6e887155eb9e1e20af6 17:39:47 H4ns: i don't really think that's the issue, but on the offchance that you're able to reproduce it semi-reliably once more, that patch may be of interest 17:45:50 wbooze [~wbooze@xdsl-78-35-137-122.netcologne.de] has joined #sbcl 17:45:53 (not everything on that branch, mind!) 18:05:01 clearly H4ns needs to overnight his laptop to finland for further reproduction attempts 18:05:50 thing is, i need to run some long-running processes right now, so i cannot let the machine cool down. 18:06:01 i'm going to continue investigating tomorrow. sorry about that. 18:06:44 is there really nobody else on 10.8.2 with this problem? 18:07:20 Haven't upgraped yet. 18:07:22 somewhere between sbcl-devel, #lisp, and r/lisp there ought to be people who'd love to work on reproducing this 18:09:09 LiamH [~healy@pool-173-73-125-152.washdc.east.verizon.net] has joined #sbcl 18:11:49 -!- nikodemus [~nikodemus@89.27.127.210] has quit [Quit: This computer has gone to sleep] 18:17:31 fe[nl]ix: thank you 18:29:22 Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has joined #sbcl 18:30:06 leuler [~user@p548FBF69.dip.t-dialin.net] has joined #sbcl 18:33:47 -!- Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has quit [Read error: Connection reset by peer] 18:58:21 nikodemus [~nikodemus@cs27127210.pp.htv.fi] has joined #sbcl 18:58:21 -!- ChanServ has set mode +o nikodemus 19:14:48 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 19:19:38 so, um, yeah, release probably not happening this weekend. Out of time 19:19:47 please carry on testing; I'll try to do it tomorrow 19:49:03 Well, I've done my part and asked on twitter and #lisp for help. Not that the crowd on #lisp makes a particularly helpful impression on me. 19:49:48 i'm going to try my other mac in a moment 20:00:35 sdemarre [~serge@91.176.179.236] has joined #sbcl 20:01:00 not reproduced on the mac mini :( 20:02:03 but a new failure for sb-posix 20:02:57 that's an old one, actually. non-ascii character in name of file in / 20:17:47 Fare [~fare@c-68-81-138-209.hsd1.pa.comcast.net] has joined #sbcl 20:18:03 no dice on the mac mini 20:25:21 i blame phase of the moon 20:25:44 but next time it happens, it would be interesting to see the printout again 20:26:02 sure 20:32:19 Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has joined #sbcl 20:47:58 -!- sdemarre [~serge@91.176.179.236] has quit [Ping timeout: 246 seconds] 20:58:22 -!- nikodemus [~nikodemus@cs27127210.pp.htv.fi] has quit [Quit: Leaving] 21:22:38 -!- Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has quit [Read error: Connection reset by peer] 21:31:48 -!- leuler [~user@p548FBF69.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 22:04:14 -!- LiamH [~healy@pool-173-73-125-152.washdc.east.verizon.net] has quit [Quit: Leaving.] 22:18:52 -!- Mazingaro [~Tetsuja@host45-237-dynamic.6-87-r.retail.telecomitalia.it] has quit [Quit: Leaving] 23:20:49 Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has joined #sbcl 23:22:59 -!- Phoodus [~foo@ip68-98-92-29.ph.ph.cox.net] has quit [Read error: Connection reset by peer]