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 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]