00:00:08 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 00:05:37 -!- senj [~senj@unaffiliated/senj] has quit [Quit: Textual IRC Client: www.textualapp.com] 00:09:54 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 00:29:23 -!- crixus [~Rob@69.77.176.98] has quit [Ping timeout: 260 seconds] 00:34:01 -!- Fare [~fare@cpe-72-229-109-116.nyc.res.rr.com] has quit [Ping timeout: 272 seconds] 00:53:18 jhao [~junhao@pool-72-76-190-214.nwrknj.fios.verizon.net] has joined #sbcl 01:04:48 crixus [~Rob@135-23-80-105.cpe.pppoe.ca] has joined #sbcl 01:11:07 Fare [~fare@cpe-72-229-109-116.nyc.res.rr.com] has joined #sbcl 01:16:38 -!- crixus [~Rob@135-23-80-105.cpe.pppoe.ca] has quit [Quit: Leaving] 01:44:49 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 01:49:55 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 01:54:27 -!- Fare [~fare@cpe-72-229-109-116.nyc.res.rr.com] has quit [Ping timeout: 252 seconds] 02:12:32 Fare [~fare@cpe-72-229-109-116.nyc.res.rr.com] has joined #sbcl 02:50:11 -!- slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 272 seconds] 02:51:40 VOP parameters tell the compiler (and us) approximately what the lifetimes of various bits of data are. The scheduler annotations to the assembler tell the compiler which instructions use and kill various bits of data. There's a disconnect involving flow-control and the elsewhere segment, but there's almost enough information available in the system as-is to produce a precise register and stack map of live boxed data and to flag life 02:51:40 time errors in VOP definitions. 02:52:34 Now, if I could just figure out how to use this information properly. /-: 02:56:47 -!- Fare [~fare@cpe-72-229-109-116.nyc.res.rr.com] has quit [Ping timeout: 272 seconds] 03:06:58 ... I have a question. I know that there's been talk about an x86oid peephole optimizer, but would most of that be covered by enabling the instruction scheduler? 03:07:21 (That is, does the instruction scheduler count as a peephole optimizer anyway?) 03:08:35 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 03:13:33 -!- scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has quit [Read error: Operation timed out] 03:19:10 frankbutt [~frankbutt@66.172.11.32] has joined #sbcl 03:19:12 -!- frankbutt [~frankbutt@66.172.11.32] has left #sbcl 03:35:05 Oh, hell. Because almost any ARM instruction can write to r15 (the program counter), almost any instruction can be a branch, which means that I'm going to have to hack the assembler if we want scheduling for the ARM backend. 03:36:12 Well, it probably means that. I have yet to get a full picture of how the scheduler works. 03:39:19 -!- christoph_debian [~christoph@ppp-46-244-228-136.dynamic.mnet-online.de] has quit [Ping timeout: 260 seconds] 03:43:32 yacks [~py@103.6.159.103] has joined #sbcl 03:52:24 christoph_debian [~christoph@ppp-88-217-40-162.dynamic.mnet-online.de] has joined #sbcl 04:02:48 _8hzp` [~user@188-67-114-161.bb.dnainternet.fi] has joined #sbcl 04:06:11 -!- _8hzp [~user@87-93-43-83.bb.dnainternet.fi] has quit [Ping timeout: 252 seconds] 04:25:41 -!- ASau` is now known as ASau 04:30:14 -!- nyef [~nyef@pool-64-222-145-64.man.east.myfairpoint.net] has quit [Quit: G'night all.] 04:59:47 -!- jhao [~junhao@pool-72-76-190-214.nwrknj.fios.verizon.net] has quit [Quit: jhao] 05:13:32 -!- stassats [~stassats@wikipedia/stassats] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 05:31:47 zRecursive [~czsq888@183.12.92.133] has joined #sbcl 06:02:35 -!- oleo [~oleo@xdsl-78-35-158-30.netcologne.de] has quit [Quit: Leaving] 06:06:51 slyrus [~chatzilla@107.201.5.56] has joined #sbcl 06:46:05 -!- yacks [~py@103.6.159.103] has quit [Quit: Leaving] 07:00:58 -!- Labrit [tribal@rcfreak0.com] has quit [Ping timeout: 245 seconds] 07:04:00 -!- zRecursive [~czsq888@183.12.92.133] has left #sbcl 07:10:46 yacks [~py@122.179.86.89] has joined #sbcl 09:00:56 Tribal [~Tribal@rcfreak0.com] has joined #sbcl 09:03:40 -!- Tribal [~Tribal@rcfreak0.com] has quit [Client Quit] 09:10:41 Tribal [tribal@rcfreak0.com] has joined #sbcl 10:26:25 michael_lee [~michael_l@117.35.188.160] has joined #sbcl 10:31:03 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 252 seconds] 10:37:04 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 10:47:41 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 252 seconds] 11:01:43 -!- michael_lee [~michael_l@117.35.188.160] has quit [Ping timeout: 260 seconds] 11:05:03 michael_lee [~michael_l@117.35.188.160] has joined #sbcl 11:07:19 -!- jdz [~jdz@212.36.34.246] has quit [Quit: Leaving] 11:20:01 abunchofdollarsi [~abunchofd@l33t.csail.mit.edu] has joined #sbcl 11:21:11 In this piece of code, I would like the debugger to have information about ga at the breakpoint; is it going to be unreasonable trying to get sbcl to support this because of such and such reason? Or maybe it's totally unclear. 11:21:14 https://gist.github.com/anonymous/8686035 12:31:54 -!- flip214 [~marek@unaffiliated/flip214] has quit [Ping timeout: 252 seconds] 12:33:38 -!- yacks [~py@122.179.86.89] has quit [Remote host closed the connection] 13:02:26 abunchofdollarsi: FYI, I've reported that: https://bugs.launchpad.net/sbcl/+bug/1274103 13:02:34 with a simpler example 13:03:11 it's been bugging me for years, every once in a while 13:03:28 attila_lendvai, I'm doing this for now https://groups.google.com/forum/#!topic/comp.lang.lisp/tWD_xSMBVaM 13:14:09 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 13:23:40 yacks [~py@103.6.159.103] has joined #sbcl 13:28:12 -!- yacks [~py@103.6.159.103] has quit [Max SendQ exceeded] 13:29:01 yacks [~py@103.6.159.103] has joined #sbcl 13:51:33 flip214 [~marek@86.59.100.100] has joined #sbcl 13:51:33 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 13:51:33 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 13:57:07 drmeister [~drmeister@166.170.20.65] has joined #sbcl 13:58:55 Fare [~fare@cpe-72-229-109-116.nyc.res.rr.com] has joined #sbcl 13:59:16 -!- Fare [~fare@cpe-72-229-109-116.nyc.res.rr.com] has quit [Client Quit] 14:04:44 hlavaty [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 14:11:16 stassats [~stassats@wikipedia/stassats] has joined #sbcl 14:19:40 -!- drmeister [~drmeister@166.170.20.65] has quit [Read error: Connection reset by peer] 14:34:28 drmeister [~drmeister@155.247.96.196] has joined #sbcl 14:38:53 -!- drmeister [~drmeister@155.247.96.196] has quit [Read error: Connection reset by peer] 14:39:44 scymtym: a hideous idea -- we could put the pattern specializer information in the environment argument to make-method-lambda 14:40:39 oleo [~oleo@xdsl-87-79-196-18.netcologne.de] has joined #sbcl 14:41:37 sounds almost reasonable. Ship it! 14:42:14 pro: (a) no new protocol functions (b) backwards-compatible (c) interface can be normal-looking functions 14:42:14 Krystof: sounds reasonable since the additional generic function could dispatch on qualifiers or specialiers anyway 14:42:26 could not 14:42:32 con: (a) totally unprecedented 14:43:35 the perils of reading my own blog posts, and thinking "there must be another answer" 14:43:36 yes, main argument against the idea would be that everything else in the mop is done via generic functions 14:44:50 segv- [~mb@95-91-241-43-dynip.superkabel.de] has joined #sbcl 14:45:31 would m-m-l-using-specializers trampolining to m-m-l require changes in user code or "just" in PCL code? 14:46:02 if i understand correctly, the main problem is that PCL optimization rely on m-m-l operating in a certain way 14:52:36 well, there's "just", but there's also the composability of the two 14:53:13 if something overrides make-method-lambda, and something else needs make-method-lambda-using-specializers, it's very hard to write something that inherits from both 14:53:51 that may not be a real concern 14:54:18 prxq [~mommer@x2f6d376.dyn.telefonica.de] has joined #sbcl 15:02:26 i'm not sure, i understand the problem 15:03:26 when two generic-function subclasses override make-method-lambda, they can only compose properly if call-next-method is used, even now 15:17:30 Krystof: i prepared a patch for Vivitron's INVOKE-RESTART-INTERACTIVELY report; should i file a lp bug or can i just send the patch somewhere? 16:10:07 I think just mail sbcl-devel is probably easiest 16:10:55 uh oh, Eric Marsden's bug is a regression 16:11:02 so much for testing before the release 16:11:42 that's OK, this release is not very high-quality anyway 16:11:42 wait, i can't reproduce it on the current sbcl either 16:11:46 too much Christmas pudding 16:11:48 senj [~senj@unaffiliated/senj] has joined #sbcl 16:12:28 drmeister [~drmeister@155.247.96.196] has joined #sbcl 16:14:12 ok, i have the regalloc disabled normally, ./run-sbcl.sh can reproduce it 16:17:19 -!- drmeister [~drmeister@155.247.96.196] has quit [Read error: Connection reset by peer] 16:17:29 drmeister [~drmeister@155.247.96.196] has joined #sbcl 16:17:31 -!- yacks [~py@103.6.159.103] has quit [Quit: Leaving] 16:23:22 it's a new-regalloc bug? Yay! 16:34:18 even non with regalloc disable, register allocation looks weird 16:34:42 RCX is moved into RSI before being checked for arg count 16:34:59 that didn't happen before on that code 16:35:42 why does it perform any moves at all, i don't get, why not use RDX RDI as they are, not move them into RBX and RCX 16:36:48 that's probably spilling before a call to GENERIC-EQL 16:37:18 but, it spills onto the stack anyhow 16:39:50 -!- drmeister [~drmeister@155.247.96.196] has quit [Read error: Connection reset by peer] 16:39:51 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 16:40:28 a call to generic-eql seems to be necessary to trigger it 16:44:47 any call to a static function 16:52:47 -!- michael_lee [~michael_l@117.35.188.160] has quit [Quit: Ex-Chat] 16:54:54 -!- senj [~senj@unaffiliated/senj] has quit [Quit: Sleep Now] 16:55:35 senj [~senj@unaffiliated/senj] has joined #sbcl 16:56:01 what are our caller save registers? 17:03:20 -!- loke_ [~loke@203.127.16.194] has quit [Ping timeout: 245 seconds] 17:05:16 can regalloc replace emitted instructions with nops? 17:06:17 or what can cause an instruction (xchg) to be replaced with a nop? 17:07:12 maybe xchg can't work with r8? 17:07:22 loke_ [~loke@203.127.16.194] has joined #sbcl 17:08:02 encoding error. 17:09:12 yep, xchg rax, r8 => NOP 17:09:32 (why is there xchg used in the first place is a question too) 17:10:21 FP comparisons are negated 17:10:33 the comparison is true if neither of two condition is true 17:10:51 i mean instead of something elese, XCHG is a bit expensive, IIRC 17:10:56 not for registers 17:11:13 the problem is that xchg has an implicit LOCK prefix when it involves memory 17:11:39 reg-reg is fine, and I expect MOV-style 0-cycle performance soon: it's used by SSA regalloc. 17:22:16 (reg-tn-encoding r8-tn) => 0 17:23:16 4C rex prefix should make it 38, maybe the prefix is wrong 17:23:20 r8 17:24:07 64 bit xchg needs rex.w 17:24:42 it's raining bugs! alleluia! 17:24:55 good news: it's an olde bug :\ 17:25:12 this one is 10 years old 17:30:58 seriously. REX.W + 90+rd 17:32:01 no, this doesn't mean that the compact encoding only works for r0-r7, does it? 17:33:06 leuler [~user@p548FBD99.dip0.t-ipconnect.de] has joined #sbcl 17:34:59 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Ping timeout: 240 seconds] 17:35:27 no, it's 48 for r0-r7, 49 for r8... 17:35:58 sbcl gets 48 right, but 4C instead of 49 17:36:00 drmeister [~drmeister@155.247.96.196] has joined #sbcl 17:37:56 I see. we swapped the thing and reg arguments in maybe-emit-rex-prefix 17:38:12 we need rex.b but set rex.r :\ 17:39:28 now we'd also need to fix the disassembler 17:39:49 in xchg-acc-with-something, we need (maybe-emit-rex-for-ea segment something acc) 17:39:56 and now I get ; 551: 4990 NOP 17:40:10 correct machine code, wrong disassembly. 17:40:16 i hate dealing with disassembly 17:40:36 *pkhuong* considers not emitting the short form for rax/r8 (: 17:41:33 -!- drmeister [~drmeister@155.247.96.196] has quit [Read error: Connection reset by peer] 17:44:32 that fixes the bug, disassembly can be dealt with later 17:44:56 regaloc seems eager to use 64-bit registers 17:46:20 yeah. the greedy allocator tries to reuse popular registers. 17:46:29 drmeister [~drmeister@155.247.96.196] has joined #sbcl 17:46:36 graph colouring just tries not to spill. 17:47:25 riscs don't care about such things 17:49:26 because they pessimise the encoding ;) 17:57:10 stassats: will you push? Otherwise I'll do it in ~2 hours. 17:57:32 i will, soonish 17:57:40 ok, thank you. 17:57:49 (day job has bugs too) 18:30:12 i sometimes get hangs in :backtrace 18:30:18 in interface.xpure 18:31:12 (not today, it has been for a while) 18:37:39 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 260 seconds] 18:43:40 make clean genera&&sudo ./genera -w Genera-8-5-103.vlod 18:43:43 blech .. sorry . 18:48:27 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 18:50:09 I don't hate dealing with disassembly. I'd like to offer to fix the XCHG disassembly but I won't have time for it in the next few days. 18:54:50 Vivitron: i sent a patch to sbcl-devel for the problem you reported. can you have a look and confirm that is does what you want? 19:04:16 -!- fikusz [~fikusz@catv-89-132-137-62.catv.broadband.hu] has quit [Quit: Leaving] 19:07:35 fikusz [~fikusz@catv-89-132-137-62.catv.broadband.hu] has joined #sbcl 19:10:50 snamich [~snamich@eduroam-230-69.ucsc.edu] has joined #sbcl 19:19:57 stassats [~stassats@wikipedia/stassats] has joined #sbcl 19:21:18 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 19:28:24 hi everyone, I'm planning on beginning to work on a peephole optimization pass for SBCL as part of a school project and wanted to make sure no one was already working on it 19:36:41 -!- slyrus [~chatzilla@107.201.5.56] has quit [Quit: ChatZilla 0.9.90.1 [SeaMonkey 2.26a1/20140106090522]] 19:37:29 -!- snamich [~snamich@eduroam-230-69.ucsc.edu] has quit [Remote host closed the connection] 19:42:43 fiveop [~fiveop@p5DDC458B.dip0.t-ipconnect.de] has joined #sbcl 19:52:31 minion: memo for snamich: ask douglas katzman. 19:52:31 Remembered. I'll tell snamich when he/she/it next speaks. 19:56:01 pnpuff [~harmonic@unaffiliated/pnpuff] has joined #sbcl 20:11:29 ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has joined #sbcl 20:14:49 -!- oleo [~oleo@xdsl-87-79-196-18.netcologne.de] has quit [Remote host closed the connection] 20:32:11 -!- ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has quit [Quit: Computer has gone to sleep.] 20:40:50 ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has joined #sbcl 20:40:52 scymtym: The news entry is spot on. It will be a few hours before I have a chance to apply it locally and try it. Thanks for making the patch:) 20:41:48 -!- pnpuff [~harmonic@unaffiliated/pnpuff] has quit [] 20:44:22 What's the difference between a local call and a full call? 20:44:56 local calls know their destination and usually benefit from specialised calling conventions 20:46:21 Does know there destination mean, that there is no style-warning about an undefined function? 20:46:43 no, it means that you get a label 20:47:10 (instead of a fdefn object that points to a function) 20:47:57 basically, local call is for FLET/LABELS 20:47:59 So this might happen with flets? 20:48:59 nyef [~nyef@pool-64-222-145-64.man.east.myfairpoint.net] has joined #sbcl 20:49:04 for local functions 20:49:07 Hello all. 20:49:08 A local call has to always go to something that doesnt have its own fdefn object, since the latter might be moved by the GC. <- is this correct? 20:49:26 hi nyef 20:49:34 Calling conventions and local calls? 20:50:08 pkhuong and stassats told me the difference between local and full calls 20:50:27 local calls are usually able to use position independent code, unless it's x86 20:50:27 And I ask questions, to ensure that my conculsions are correct :) 20:50:42 no, x86 would be position independent too 20:51:18 there may be issues on riscy platforms and too-short immediate displacements. 20:52:30 fdefn object is just away to achieve indirection needed for redefinitions 20:52:51 Redefinitions and forward-definitions. 20:53:11 (Something like that.) 20:53:21 ok 20:53:31 static functions doesn't need fdefn, since they have a reference in the static space and it's always stays there 20:53:57 (but they can still be redefined, it's still an indirection) 20:54:03 assembly routines are static and cannot be redefined 20:55:14 well, in theory if your new definition takes the same amount of space and you flush the instruction caches, you can 20:57:38 So, I had a bit of a thought recently. Would setting up the instruction scheduler provide the x86oid backends with any of the advantages of a peephole optimizer? 20:58:56 better VOP selection would help 20:59:34 because the cost parameter does not really work, it often results in selecting a worse VOP with an additional move 21:00:28 But better VOP selection logic would also benefit the other backends, right? 21:00:38 sure 21:01:03 dougk had a fairly advanced prototype for peephole 21:01:12 What was the C in CFP? 21:01:18 current 21:01:26 i stopped doing microptimizations because VOP selections selects bad versions anyhow 21:01:27 or control 21:01:27 so OCFP is old current :) 21:01:40 right, control versus old 21:02:09 CFP has to be control, because we also have NFP. 21:02:52 dougk has a fairly advanced peephole pass, but it depends on per-instruction analysis 21:03:23 do the Googly lispers all still live in Boston/Cambridge, Mass? 21:03:58 I'm not too comfortable with that. Matching sequences of VOPs + instruction template seems like a better idea to me than to try and recover lifetime info. 21:04:14 -!- prxq [~mommer@x2f6d376.dyn.telefonica.de] has quit [Remote host closed the connection] 21:04:36 prxq [~mommer@x2f6d376.dyn.telefonica.de] has joined #sbcl 21:05:23 nyef: do we not pass arguments by register on arm? 21:05:43 We pass three parameters in registers. 21:05:57 for full calls 21:06:04 Well, yes. 21:06:04 then allocate-full-call-frame confuses me 21:06:20 How so? 21:06:26 scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has joined #sbcl 21:06:32 *pkhuong* bets it's the magic three slots. 21:06:45 Yeah, probably. 21:07:23 other platforms only do something, if nargs exeeds register-arg-count. I get that we store the OCFP on the stack in this vop unlike other VOPS so we have to do something, but we allocated (max 1 nargs) words on CS 21:08:16 Oh, hell. That needs to be at least a two or three, doesn't it? 21:08:17 (another thing is, shouldn't that be (1+ nargs) because we always put ocfp at csp (before we increase it) 21:08:32 ) 21:08:55 No, the unmodified nargs term is correct. 21:09:44 So, what's going on here is that the compiler stores the first $n$ (three, on ARM) parameters in registers and the rest on the stack. 21:10:05 nargs is the 'rest'? 21:10:23 The arguments passed on the stack are stored at a position in the new stack frame based on their position in the argument list. 21:10:35 ... parameter list, sorry. 21:11:11 no I mean suppose I have a call with 7 parameters, what value does nargs have in allocate-full-call-frame? 21:11:21 seven. 21:11:44 why do we increase csp by (max 1 7) then? 21:11:52 aren't 3 arguments in registers? 21:11:57 28! 21:12:14 We use the first three stack slots for the LRA, the OCFP, and the NFP-save. 21:12:14 let's say 7 words :) 21:12:28 magic :) 21:12:34 and other platforms don't do that? 21:12:40 And at least the LRA and OCFP are set up (in the case of the ARM) on the caller side. 21:12:57 Most other platforms do it callee side, but most other platforms have more than fifteen registers. 21:13:34 then shouldn't it be (max 3 nargs)? 21:14:34 As I said, the one is wrong and it should be a two or three... And I think we can get away with it being a two but I'm not sure. 21:14:42 (Or for people like me who have no clue (+ 3 (max 0 (- nargs 3))) ) 21:14:47 ok 21:15:02 thank you 21:15:20 Looking into either static-fn magic or full-call assembly-routine magic? 21:16:46 I'm reading your port log again. And the part about calling conventions first mentions the allocate-full-call-frame vop. 21:18:03 Ahh. 21:32:45 One more question. Why do you say you think we get away with 2, if OCFP, LRA, and NFP are three things? 21:52:22 NFP doesn't get passed from function to function, but it does have a designated save slot. 21:53:50 -!- senj [~senj@unaffiliated/senj] has quit [Quit: Sleep Now] 21:55:02 still a little bit confused, but I 21:55:10 'll just continue reading 21:57:31 senj [~senj@unaffiliated/senj] has joined #sbcl 22:06:08 -!- fiveop [~fiveop@p5DDC458B.dip0.t-ipconnect.de] has quit [] 22:12:02 -!- prxq [~mommer@x2f6d376.dyn.telefonica.de] has quit [Quit: Leaving] 22:17:36 -!- ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has quit [Quit: Computer has gone to sleep.] 22:31:10 -!- leuler [~user@p548FBD99.dip0.t-ipconnect.de] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 22:49:28 davazp [~user@14.Red-79-152-116.dynamicIP.rima-tde.net] has joined #sbcl 22:57:12 -!- drmeister [~drmeister@155.247.96.196] has quit [Remote host closed the connection] 23:12:06 drmeister [~drmeister@166.170.20.21] has joined #sbcl 23:21:11 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 23:34:54 -!- drmeister [~drmeister@166.170.20.21] has quit [Read error: Connection reset by peer] 23:43:00 slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 23:50:41 snamich [~snamich@50-1-50-233.dsl.dynamic.fusionbroadband.com] has joined #sbcl 23:52:37 slyrus_ [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 23:54:57 -!- slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 272 seconds] 23:55:12 -!- slyrus_ is now known as slyrus 23:56:26 ASau` [~user@p54AFFBA8.dip0.t-ipconnect.de] has joined #sbcl