00:39:38 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 00:40:42 -!- milanj [~milanj_@178-223-191-12.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 03:06:37 -!- saschakb_ [~saschakb@p4FEA0D01.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 03:10:36 saschakb_ [~saschakb@p4FEA1284.dip0.t-ipconnect.de] has joined #sbcl 03:17:55 -!- saschakb_ [~saschakb@p4FEA1284.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds] 03:23:15 saschakb_ [~saschakb@p4FEA111E.dip0.t-ipconnect.de] has joined #sbcl 03:28:11 -!- saschakb_ [~saschakb@p4FEA111E.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds] 03:30:11 saschakb_ [~saschakb@p4FEA1095.dip0.t-ipconnect.de] has joined #sbcl 03:36:08 -!- saschakb_ [~saschakb@p4FEA1095.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 03:40:00 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 03:49:06 saschakb_ [~saschakb@p4FEA0E0F.dip0.t-ipconnect.de] has joined #sbcl 03:57:20 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:02:18 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 04:03:27 drl [~lat@110.139.229.172] has joined #sbcl 04:07:55 -!- saschakb_ [~saschakb@p4FEA0E0F.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 04:42:13 -!- drl [~lat@110.139.229.172] has quit [Quit: Leaving] 04:43:44 -!- drl__ [~lat@110.139.229.172] has quit [Read error: Connection reset by peer] 04:57:39 -!- mensch [~mensch@c-67-189-241-178.hsd1.ma.comcast.net] has quit [Quit: Lost terminal] 05:46:31 Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has joined #sbcl 05:59:53 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 06:49:53 nikodemus [~nikodemus@188-67-206-250.bb.dnainternet.fi] has joined #sbcl 06:49:53 -!- ChanServ has set mode +o nikodemus 07:18:28 sdemarre [~serge@91.176.40.160] has joined #sbcl 07:20:49 anyone interested in a ETYPECASE with mailboxes? 07:20:51 http://paste.lisp.org/display/126346 07:25:39 flip214: not on 1.0.53 07:26:11 1.0.54 has been released, and that bit of code has changed. (actually there are relevant changes even after 1.0.54) 07:26:21 ok, trying from git 07:28:26 flip214: is your code intended to loop forever? 07:28:32 this test, yes. 07:28:41 ok 07:28:52 my normal code injects a end-of-file message ... you can use :end for this one 07:28:57 still building sbcl 07:29:27 -!- sdemarre [~serge@91.176.40.160] has quit [Ping timeout: 240 seconds] 07:32:31 still building sbcl ... 07:49:33 nikodemus: no crash with 1.0.54.48-c1fa54f, but still not satisfied ... 07:49:50 http://paste.lisp.org/+2PHM/1 07:49:56 WARNING: No sampling progress; possibly a profiler bug. 07:49:56 Number of samples: 0 07:51:05 only a bit of modification, so that it terminates, and counts processed elements .. 07:51:19 0.7 sec, so there should have been time for a few measurements 07:52:27 -!- Kryztof [~user@77-58-246-74.dclient.hispeed.ch] has quit [Ping timeout: 240 seconds] 08:00:18 flip214: what platform? 08:00:32 amd64, debian 08:08:25 pon1980 [~pon@195-67-88-105.customer.telia.com] has joined #sbcl 08:12:33 Well SBCL represent struct slots with type (or null (integer 0 *)) efficiently? 08:13:39 what do you mean, efficiently? with no upper bound it'll (eventually) need a bignum anyway ... 08:14:25 Well I suppose a level of indirection for accessing the slot can be removed if it's known it's null (which is a type with one element), or a bignum 08:22:04 do you need bignums here? even on 64bit machines? 08:26:46 flip214, yes 08:27:06 then I believe the (or null) doesn't matter anyway 08:29:13 Kryztof [~user@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 08:29:13 -!- ChanServ has set mode +o Kryztof 08:32:27 flip214: that's funny 08:32:35 in what way? 08:32:48 did it never work? 08:33:02 with-profiling doesn't get anything, but if i use start-profiling and stop-profiling it works fine 08:33:41 perhaps it uses per-thread special variables? 08:33:51 I don't know, just guessing 08:34:10 but I'm always happy if I can show bugs ;) 08:37:15 aha. :threads :all works, something funny with :threads 08:38:57 but :all means that I get the swank-threads, too - right? 08:39:40 flip214: yes 08:40:03 run in a bare repl if you want to avoid that -- or just ignore stuff that obviously belongs to swank 08:40:09 i'll see if i can find the bug 08:42:35 thanks 08:46:02 uh, duh. i need to get on linux for this 08:46:35 plutoid [~pluto@218.206.101.179] has joined #sbcl 08:47:21 hi! any more details about "--dynamic-space-size 200 --dynamic-space-reserve 150 --dynamic-space-limit 400 --dynamic-space-hard-limit 500 " on site http://sbcl.org ? THX! 08:47:27 -!- Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has quit [Quit: Cryotank2011] 08:54:26 if you use slime-sprof, it has an option to hide swank-stuff 08:54:37 and it's nicer all around 08:55:12 plutoid: only --dynamic-space-size exists at the moment 08:55:26 the rest is still work in progress 08:55:35 with luck landing in the repository within this month 08:55:47 hahahahah 08:56:13 flip214's profiling problem gave me handle on the bogus darwin segfaults, it seems 08:56:20 nikodemus I need to control memory allocate size at runtime, it seems "--dynamic-space-size " arguments no use. 08:56:26 hooray! 08:56:40 plutoid: what do you need to do, exactly 08:56:59 (i can now provoke them on will, which makes debugging a bit more feasible...) 08:59:36 total of my vps server mem size is 768M ,I need to limit sbcl's allocation mem size up to 300M ,I don't know how to do with it. 09:00:15 nikodemus I try all these arguments seem it doesn't work. 09:00:56 plutoid: what sbcl version? 09:02:06 SBCL 1.0.53.0.debian, 09:02:57 should work. do you use any other command-line options besides --dynamic-space-size ? 09:03:44 --dynamic-space-size 100 \ 09:03:44 --dynamic-space-reserve 150 \ 09:03:44 --dynamic-space-limit 100 \ 09:03:44 --dynamic-space-hard-limit 100 \ 09:03:44 --no-userinit 09:04:51 plutoid: remove reserve, limit, and hard-limit -- they don't exist. try just "sbcl --dynamic-space-size 300 --no-userinit" 09:05:49 (you need to pass --dynamic-space-size before any command-line arguments handled by the lisp code: so if you have eg. --load foo.lisp there as well, --dynamic-space-size needs to come before it) 09:16:44 nikodemus THX very much! seems it work find. 09:16:46 fine! 09:28:11 this is really weird. it's almost as if _reading_ the sigmask on darwin changes the way signals get delivered... 10:11:03 nikodemus this should be an attention on manual book!:) 10:12:12 bye! 10:12:16 -!- plutoid [~pluto@218.206.101.179] has quit [Quit: Leaving] 10:20:10 abeaumont [~abeaumont@90.165.165.246] has joined #sbcl 11:16:37 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 248 seconds] 12:51:57 nikodemus: Re: [Sbcl-devel] Threads Stable on Darwin? Maybe! 12:52:34 how does the darwin OS problem relate to the :threads :all/:threads thread-list problem that I have/had? 12:59:03 homie [~levgue@xdsl-78-35-138-95.netcologne.de] has joined #sbcl 13:06:13 flip214: it does not 13:06:28 oh, ok 13:06:32 except that your code proved to provoke the problem i've been hunting for a couple of days 13:06:43 well, that's something 13:07:45 flip214: also, i'm not sure what your problem was. when i said about :all vs threads, i forgot that darwin has misbehaviour there 13:07:59 I'm on debian amd64 ... 13:08:06 i know 13:08:10 ok 13:08:18 i've been working on darwin today, and haven't gotten to a linux box yet 13:18:34 no problem ... I'll wait for the next debian package anyway, I believe 13:51:53 aaargh, now the bug stopped appearing 13:51:59 *nikodemus* hates heisenbugs 13:52:25 good news, it fixed itself 13:52:50 aaah, there it is again 13:52:59 And now it's back .... 13:53:09 to show _you_ how to really shake 'em down. 14:18:07 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 14:30:13 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 14:30:20 G'morning all. 14:35:31 saschakb [~saschakb@p4FEA043C.dip0.t-ipconnect.de] has joined #sbcl 14:58:54 hi 14:59:39 hi nikodemus 14:59:53 nikodemus: So, you have a bit of a lead on OSX threading issues again? 15:00:29 ... you know we're bypassing the POSIX signal emulation for SIGSEGV, right? 15:01:47 i do know 15:02:10 i've tried at looking at the exception, but the ones that are bogus are apparently completely normal 15:02:49 Is there anything specifically bogus about them, or do they just trip some weird code path? 15:03:37 they occur on allocated boxed pages that are not protected at all, and have been last unprotected by the GC 15:04:05 ... not protected at all, yet we still catch a SIGSEGV? 15:04:10 yes 15:04:30 vmmap says the page is writable, readable, and executable 15:05:08 b 15:05:09 oops 15:05:14 From the core, or from /dev/null? 15:07:39 You know, the "simple" thing is to just add a check to the mach exception handler to see if the page is suitably accessible, and restart the instruction if it is. 15:07:56 Maybe on a one-shot, so things don't get caught in a loop... 15:11:22 i tried getting the protection flags using vm_region, but it block on some lock 15:11:32 ... Typical. 15:12:15 Maybe it works from the faulting thread rather than the mach exception handler thread? 15:12:16 ok, i have a fresly provoked instance of it here in LDB 15:12:42 hm, actually i tried it in the faulting thread 15:12:59 maybe it needs to be done in the mach handler... 15:14:00 now let me find that in vmmaps... http://paste.lisp.org/display/126349 15:15:05 Might also try disassembling the faulting instruction, make sure it's a LOCK CMPXCHG or whatever. 15:16:38 Hrm. The AMD documentation for CMPXCHG isn't particularly scary in terms of exceptions. 15:17:05 Although I have no idea what a "non-canonical" memory address might be. 15:18:12 here it is: VM_ALLOCATE 000000100f6e8000-000000100f6f0000 [ 32K/ 32K] rwx/rwx SM=COW 15:21:01 oh, and it's not a code page that the fault address is on 15:22:00 The address of the fault, or the address of the faulting instruction? 15:22:44 Because, AIUI, if the faulting instruction isn't on a code page, that just means it's in a page originally mapped from the core file. 15:22:52 antgreen [user@nat/redhat/x-xapqqqvggwxogcvb] has joined #sbcl 15:23:26 fault address, right 15:23:44 Intel documentation for CMPXCHG isn't any scarier for exceptions, really, it's just got a more comprehensive description... 15:25:56 hmph, were do i find the address of the faulting instruction? 15:26:49 Signal context. 15:27:06 It'll be the program counter. 15:27:16 Instruction pointer. Whichever. 15:28:31 i was thinking about the mach, side, but actually this is better : 15:28:43 Should probably be F0 0F Bx or so, maybe with an REX prefix somewhere. 15:37:51 found it 15:38:04 it's just writing NIL into memory 15:41:25 It's just an uncontested write? 15:41:56 yes 15:41:58 -!- saschakb [~saschakb@p4FEA043C.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 15:42:50 saschakb [~saschakb@p4FEA043C.dip0.t-ipconnect.de] has joined #sbcl 15:43:22 it follows right on the heels of a succesfull CAS 15:44:39 *nyef* is gone for a bit. 15:47:22 http://paste.lisp.org/display/126349#1 15:50:57 sometimes signal handlers are bad at giving the faulting instruction 15:51:12 that location makes perfect sense, though 15:51:13 often the instruction pointer is pointing to the instruction following the faulting instruction 15:51:40 the instruction before that is part of an inline type error trap 15:52:53 it's lock:cmpxchg, mov, cmp, jmp -> mov nil reg, mov reg mem <-- and we fault here 15:53:08 it looks perfectly sensible all around 16:08:34 -!- akovalenko [~akovalenk@95.72.42.228] has quit [Quit: rcirc on GNU Emacs 24.0.92.1] 16:10:01 akovalenko [~akovalenk@95.72.42.228] has joined #sbcl 16:13:13 -!- antgreen [user@nat/redhat/x-xapqqqvggwxogcvb] has quit [Ping timeout: 255 seconds] 16:21:00 Kryztof: for protection? a bad address would break a lot of things. 16:24:01 -!- brown```` is now known as reb` 16:24:17 -!- pon1980 [~pon@195-67-88-105.customer.telia.com] has left #sbcl 16:25:41 attila_lendvai [~attila_le@87.247.47.73] has joined #sbcl 16:25:41 -!- attila_lendvai [~attila_le@87.247.47.73] has quit [Changing host] 16:25:41 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:34:20 nikodemus: is that on a multicore/socket system? Does it still happen if you pin the program on a single core? 16:35:37 antgreen [user@nat/redhat/x-mzpbzplilxxsovoz] has joined #sbcl 16:36:01 single Core 2 Duo 16:37:54 I'll try and replicate on my air. For once, I'll probably be relieved if I can't, and it looks hardware-specific ;) 16:42:45 it also turns out that i can't replicate it /all/ the time reliably, even with that test case 16:43:07 i think if the machine runs a little too hot it doesn't happen... 16:44:07 -!- antgreen [user@nat/redhat/x-mzpbzplilxxsovoz] has quit [Ping timeout: 240 seconds] 16:56:27 http://stackoverflow.com/questions/2824105/handling-mach-exceptions-in-64bit-os-x-application # what fun, do we need to play with MIG next? 16:57:02 not relevant here though, since my address space fits in the low 32 bits 17:09:46 I can't believe an exploitation guide might be the best resource on darwin/mach 17:11:24 -!- Kryztof [~user@178-83-229-138.dynamic.hispeed.ch] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 17:16:22 nikodemus: well, mine fails with heap exhaustion (: 17:16:28 I'll try again with a larger heap. 17:16:57 pkhuong: 1gb is enough, really 17:17:12 try with '(20) in the :initial-contents 17:17:39 (those lockless queues are really conservative-gc poison) 17:26:54 pkhuong: oh, wait 17:27:24 i have a couple of patches in the tree that clear page_protection_cleared when the page is re-protected 17:27:43 ...which might be why you're having harder time reproducing this 17:28:30 pushed to pending branch on my github treee 17:49:37 milanj [~milanj_@178-223-191-12.dynamic.isp.telekom.rs] has joined #sbcl 18:06:40 Qworkescence [~quad@75-166-82-248.hlrn.qwest.net] has joined #sbcl 18:06:48 -!- Qworkescence [~quad@75-166-82-248.hlrn.qwest.net] has quit [Changing host] 18:06:48 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 18:16:24 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 244 seconds] 18:19:01 slyrus [~chatzilla@63-150-7-120.dia.static.qwest.net] has joined #sbcl 18:20:39 -!- nikodemus [~nikodemus@188-67-206-250.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 18:26:55 homie` [~levgue@xdsl-84-44-209-14.netcologne.de] has joined #sbcl 18:29:04 -!- homie [~levgue@xdsl-78-35-138-95.netcologne.de] has quit [Ping timeout: 240 seconds] 18:30:44 -!- homie` [~levgue@xdsl-84-44-209-14.netcologne.de] has quit [Client Quit] 18:32:56 homie [~levgue@xdsl-84-44-209-14.netcologne.de] has joined #sbcl 18:42:44 nikodemus [~nikodemus@188-67-206-250.bb.dnainternet.fi] has joined #sbcl 18:42:44 -!- ChanServ has set mode +o nikodemus 18:43:19 -!- saschakb [~saschakb@p4FEA043C.dip0.t-ipconnect.de] has quit [Quit: Verlassend] 18:43:50 can it my fault? internal error #26 (An attempt was made to use an undefined SYMBOL-VALUE.) 18:44:48 saschakb [~saschakb@p4FEA043C.dip0.t-ipconnect.de] has joined #sbcl 18:50:40 s/it my/it be my/ 18:51:27 where? 18:51:50 don't know, when my usual system starts up, but with my recently rebased/merged patches 18:52:09 p $1 in ldb, etc, will enable you to find out which symbol 18:55:48 I go bedwards, will try tomorrow. thanks! 18:58:03 ok :) 18:58:10 i'm about done for today too 18:59:58 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Operation timed out] 19:06:40 Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has joined #sbcl 19:08:59 more yay nikodemus! 19:09:28 Hrm. Is anyone else seeing an invalid exit status from hash.impure.lisp? 19:10:06 nope 19:10:15 -!- borkman [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Remote host closed the connection] 19:10:41 Oh, never mind. Bloody oom killer. 19:11:08 borkman [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 19:11:13 hahaha 19:12:07 Reliably kills sbcl in the middle of hash.impure.lisp, but lets the rest of the test suite run to completion. 19:12:55 *akovalenko* came to think that 12Mb nursery was just right 19:25:53 antgreen [user@nat/redhat/x-picubuexdngfkimq] has joined #sbcl 19:40:09 -!- Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has quit [Quit: Cryotank2011] 19:50:21 nikodemus: the sprof thingy works fine here (HEAD) 19:55:23 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Read error: Operation timed out] 19:57:23 pkhuong: can you try with https://github.com/nikodemus/SBCL/commit/77df0d0820afd6f8aea41e2095a029b317ea2d28 applied? 20:03:02 building. 20:03:20 thanks 20:19:58 nope, still. 20:24:46 lion? 20:25:27 nope, 10.6 20:26:39 re safe points, how much less portable would it be to single step threads until it gets to a known good point? 20:28:12 oh wow, ptracing yourself would be such a hack. 20:28:43 ... self-ptrace()? How would that even work? 20:29:05 presumably you'd spawn another process to control the ptrace on you. 20:29:07 mach supports it pretty directly. 20:29:17 you can interrupt a thread, set the single step flag and resume 20:30:16 pkhuong: safepoints (as currently implemented) are widely portable /in principle/, anywhere with mprotect and synchronous sigsegv 20:30:57 that's an interesting idea 20:32:44 interrupting/suspending threads, hmm (foreign threads with strange ACLs would break it on Windows). 20:34:40 on most linux distros, you can't ptrace processes that aren't your children anymore by default 20:34:51 so doing that would be pretty tricky 20:35:22 What was that song...? "I am my own grandpa"? 20:36:11 another thing I'm considering for a completely independent runtime system: double-mmap the heap from tmpfs. 20:36:28 ..or from posix shm 20:36:45 double-mmap is interesting, indeed. 20:36:45 Does shm interact well with mprotect? 20:37:52 There are a lot of interesting GC ideas I played around with that wouldn't work on windows because they required double-mmap with varying permissions, and I couldn't find an API that allowed it without also requiring that the memory all be page-locked. 20:38:53 nyef: VirtualProtect works well with double mappings (tested) 20:39:17 How do you create the double mapping, though? 20:39:26 There's also the kernel module here http://www.managedruntime.org/downloads for linux that lets you do things like that I think. 20:39:29 (for linux) 20:39:35 The documentation fairly explicitly says that you can't use VirtualFoo calls with MapViewOfFile. 20:39:43 nyef: call MapViewOfFile twice. 20:39:56 nyef: for the same file mapping object if you want coherency 20:40:10 Wait, VirtualProtect() works with MapViewOfFile()?!? 20:40:10 *coherence 20:40:12 Since when? 20:40:30 always? 20:40:44 foom: sbcl could run always as two processes, the parent being the supervisor 20:40:56 nyef: VirtualAlloc and VirtualFree doesn't 20:41:06 fe[nl]ix: dude. no. 20:41:13 Hunh. 20:41:18 fe[nl]ix: yea, it could, but, I'm gonna go out on a limb and say OMG please no no please. 20:41:20 nyef: and I can't recall, but maybe it works for anonymous mappings only 20:41:35 Okay, that might make more sense. 20:41:45 And the core file isn't an anonymous mapping? 20:41:49 (that is, mapping object backed by pagefile) 20:42:10 foom, pkhuong: why ? 20:42:30 I know that one of the reasons the core loader jumps through so many hoops on windows is that the VirtualFoo functions didn't work (or were documented to not work) on mappings. 20:43:05 fe[nl]ix: because it's too complicated and I'm 100% sure it will not work right always, and fail in strange ways. 20:43:22 nyef: it might be a theoretical reason, but more immediate thing was probably a 64k allocation unit (bigger than a 4k "page") 20:43:26 fe[nl]ix: because I think we should strive to look as much as possible like a C program from the outside. 20:43:35 That might also have been the reason. 20:44:28 it is also unnecessary because we can set the single-stepping flag easy enough 20:45:02 nikodemus: posixly, how? 20:45:13 nikodemus: not with the ptrace API you can't. 20:45:19 pkhuong: we do it already 20:45:21 nyef: I was wrong, VirtualProtect works on *any* mapping 20:45:35 how did you think non-encap trace works? 20:45:36 nyef: and it's documented, e.g. http://msdn.microsoft.com/en-us/library/windows/desktop/aa366556(v=VS.85).aspx 20:45:44 nikodemus: ah, nice. 20:46:06 akovalenko: Hunh. Then why are we doing that crazy bit with not mapping the core file directly? I'm fairly sure there was a reason for it... 20:46:37 (1) it's very easy to misread MSDN, generally, and (2) 64k page probably seemed too big back then :) 20:47:23 foom: Setting the single-step flag via ptrace should be fairly easy, as it's part of the thread context. 20:47:39 *akovalenko* uses 32k pages, with core sections aligned by 64k, btw 20:47:45 foom: Grab registers, twit EFLAGS about a bit, shove them back, resume. 20:50:25 nyef: what's interesting here is that I have mmapped core on windows for ~1 year. And while I constantly bragged about it, I've never got any question on how it's possible, what's hard about it, etc :) 20:51:31 Over about the same time period, almost the only windows machine I've had to interact with belongs to my mother. I REALLY haven't been paying attention. 20:52:31 the one windows machine I have only runs The Sims 3 (roommate). 20:53:07 and the one windows machine I have is virtual :) 21:01:36 nikodemus: so... not reproducible here, on 10.6 :\ 21:06:41 hunh 21:11:05 i'll put in on launchpad and forget about it for a while 21:11:08 PLAN 21:15:30 -!- scymtym [~user@azurit.TechFak.Uni-Bielefeld.DE] has quit [Remote host closed the connection] 21:42:01 Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has joined #sbcl 21:53:11 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 21:54:36 -!- nikodemus [~nikodemus@188-67-206-250.bb.dnainternet.fi] has quit [Quit: Leaving] 21:56:27 -!- antgreen [user@nat/redhat/x-picubuexdngfkimq] has quit [Read error: Connection reset by peer] 22:05:35 sdemarre [~serge@91.176.114.38] has joined #sbcl 22:25:57 -!- sdemarre [~serge@91.176.114.38] has quit [Ping timeout: 244 seconds] 22:41:20 -!- akovalenko [~akovalenk@95.72.42.228] has quit [Ping timeout: 244 seconds] 22:54:19 akovalenko [~akovalenk@95.73.124.217] has joined #sbcl 23:08:06 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 23:26:45 -!- Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has quit [Quit: Cryotank2011] 23:27:41 -!- homie [~levgue@xdsl-84-44-209-14.netcologne.de] has quit [Remote host closed the connection] 23:29:39 homie [~levgue@xdsl-84-44-209-14.netcologne.de] has joined #sbcl 23:51:59 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 23:54:16 -!- milanj [~milanj_@178-223-191-12.dynamic.isp.telekom.rs] has quit [Quit: Leaving]