2015-02-09T00:03:25Z milosn quit (Ping timeout: 264 seconds)
2015-02-09T00:32:48Z eudoxia joined #sbcl
2015-02-09T00:35:35Z nyef: Can a DX allocation made within a loop survive to outside of said loop?
2015-02-09T00:36:32Z nyef: It certainly doesn't seem likely, at least.
2015-02-09T00:38:53Z nyef: I might posit that the only way such a thing could happen would be a tail-recursive LABELS form that tail-calls some other local function.
2015-02-09T00:39:18Z nyef: And that the mere fact of DX allocation would prevent LET-conversion from turning it into a loop.
2015-02-09T00:53:35Z pkhuong: yeah. if we mess up TR analysis and convert a non-tail call to a loop despite DX, that'd be bad
2015-02-09T00:53:47Z pkhuong: that's the main thing that worries me about the loop hack.
2015-02-09T00:53:57Z nyef: "the loop hack"?
2015-02-09T00:55:18Z pkhuong: depend on loop analysis to approximate dominators with the most deeply nested loop that contains all the refs to the DX lambda var.
2015-02-09T00:55:56Z pkhuong: disable DX allocation if that's a strange loop. otherwise, insert cleanups at loop exits.
2015-02-09T00:56:26Z nyef: Hrm.
2015-02-09T00:58:01Z scymtym__ quit (Ping timeout: 256 seconds)
2015-02-09T00:59:39Z nyef: So, post-STACK-analysis constraint: Any DX or UV LVAR (that is, a "stack packet") that is created on some control flow must be destroyed before reaching the tail block, and any such LVAR that is destroyed must be created before reaching the head block.
2015-02-09T00:59:42Z nyef: Sound about right?
2015-02-09T00:59:43Z pkhuong: * exists and loop back.
2015-02-09T01:00:35Z pkhuong: head and tail block as in the special blocks for functions?
2015-02-09T01:01:15Z nyef: Yes.
2015-02-09T01:01:38Z nyef: Additionally, no such LVAR may be re-created while it already exists, or re-destroyed while it does not exist.
2015-02-09T01:01:46Z pkhuong: and they're always empty, so yes, that's definitely correct.
2015-02-09T01:03:50Z nyef: One additional constraint: No stack packet beneath an MV LVAR may be destroyed.
2015-02-09T01:04:17Z pkhuong: argh, unknown multiple values :'(
2015-02-09T01:04:22Z pkhuong: I give up.
2015-02-09T01:04:33Z nyef: Err... Sorry, not an MV LVAR, a DX LVAR.
2015-02-09T01:04:44Z nyef: We can NIP packets out from under an MV LVAR easily enough.
2015-02-09T01:04:52Z nyef: It's the DX LVARs that we can't move.
2015-02-09T01:08:56Z nyef: ... we get to a control-flow join. Branch A has dv27. Branch B has dv8 and dv27. dv8 may be presumed to be "deeper" than dv27.
2015-02-09T01:09:25Z pkhuong: ok, but we can merge cleanups
2015-02-09T01:09:34Z nyef: Yes, not at issue.
2015-02-09T01:09:51Z nyef: The issue is that we have two different stack depths coming into a join.
2015-02-09T01:09:55Z pkhuong: if dv8 and dv27 are always cleaned up at the same time, we don't need to order them.
2015-02-09T01:10:11Z nyef: Hrm.
2015-02-09T01:10:34Z pkhuong: that's why the loop thing is interesting: stash SP upon entry, and reset it on exit/loop back.
2015-02-09T01:10:35Z nyef: That... makes things tricker.
2015-02-09T01:11:25Z nyef: So, because dv8 is used in CREATING dv27 on one branch, they are in some way "the same"?
2015-02-09T01:13:26Z nyef: Hrm. There's a definite idea there involving more explicit use of stack depth for DX cleanups.
2015-02-09T01:13:44Z pkhuong: is there a way to map DX lvars to the DX lambda var that (initially) received them?
2015-02-09T01:14:05Z pkhuong: it should be many lvars to 1 lambda var, right?
2015-02-09T01:14:39Z nyef: Yeah... I have no idea.
2015-02-09T01:15:42Z nyef: ... And the reason that UV LVARs don't have this problem is because they are far more atomic than a nested DX allocation.
2015-02-09T01:18:12Z stassats joined #sbcl
2015-02-09T01:18:29Z stassats quit (Changing host)
2015-02-09T01:18:29Z stassats joined #sbcl
2015-02-09T01:18:30Z stassats: do they not have it or nobody just managed to trip them up?
2015-02-09T01:18:56Z nyef: Good question.
2015-02-09T01:20:17Z nyef: Any assignment to a UV LVAR assigns the entire thing. You can have multiple such LVARs "in flight", as it were, but...
2015-02-09T01:20:44Z nyef: At this point I no longer have any idea what's going on.
2015-02-09T01:39:37Z cojy_ quit (Ping timeout: 250 seconds)
2015-02-09T01:46:09Z psy_ joined #sbcl
2015-02-09T01:46:37Z stassats: there's also https://bugs.launchpad.net/sbcl/+bug/1255782
2015-02-09T01:47:14Z stassats: happily goes to SB-C::DISCARD-UNUSED-VALUES never to be seen again
2015-02-09T01:47:35Z nyef: Yeah... no. Try with my DCE branch.
2015-02-09T01:47:48Z fe[nl]ix: I don't suppose anybody here would like to move the stativ-vectors code into SBCL proper ?
2015-02-09T01:48:48Z stassats: fe[nl]ix: is that needed?
2015-02-09T01:48:57Z stassats: can we export something useful instead?
2015-02-09T01:49:30Z fe[nl]ix: AFAIK there's no way to tell the GC never to move a piece of memory
2015-02-09T01:49:57Z stassats: outside of dynamic-extent of with-pinned-objects?
2015-02-09T01:50:02Z fe[nl]ix: I'm not saying the current approach is the best possible, but something similar would need to be added
2015-02-09T01:51:01Z fe[nl]ix: stassats: yes, what's needed here is something that marks the memory as unmovable on creation
2015-02-09T01:51:22Z stassats: |3b| discovered that lisp objects in foreign space do not play well with the debugger
2015-02-09T01:51:28Z cojy_ joined #sbcl
2015-02-09T01:52:03Z stassats: so there needs to be dedicated static space, beside the one we already have
2015-02-09T01:52:35Z fe[nl]ix: I'm pretty satisfied with the current code because I only use it for I/O stream buffers where I do my own bounds checking
2015-02-09T01:52:36Z |3b|: does the debugger care about the actual storage for the array?
2015-02-09T01:53:07Z fe[nl]ix: but others might actually need the debugger
2015-02-09T01:53:15Z fe[nl]ix: like |3b|
2015-02-09T01:53:15Z stassats: |3b|: it cares about not crashing by looking at the protected memory
2015-02-09T01:53:41Z nyef: Can we force something to be allocated in a large-object area?
2015-02-09T01:53:56Z |3b|: also, if the debugger is supposed to not like that memory, something else might be wrong, since it will print the array in other contexts
2015-02-09T01:53:56Z stassats: that can get moved, can't it?
2015-02-09T01:54:08Z pkhuong: stassats: yes, if they're too small
2015-02-09T01:54:30Z stassats: |3b|: in which contexts?
2015-02-09T01:54:40Z pkhuong: |3b|: the bound checking handler is special because it has to reconstruct a lisp pointer from the context
2015-02-09T01:54:42Z |3b|: if i pass it to a function and BREAK
2015-02-09T01:54:46Z pkhuong: that part could go wrong.
2015-02-09T01:54:53Z stassats: |3b|: that's not from the debugger
2015-02-09T01:55:16Z |3b| is confused about which parts are doing what
2015-02-09T01:55:40Z nyef: |3b|: If the system "knows" that it's looking at a lisp object, then it "works" fine. If it's starting from an integer that MAY be a lisp object, then it does the extra verification.
2015-02-09T01:56:37Z |3b|: so am i understanding correctly that there could be a lisp object that points to foreign memory for the actual data? or are they supposed to be together
2015-02-09T01:57:42Z nyef: |3b|: I could mmap() a chunk of /dev/zero, slap an unboxed array header in the space, use sb-kernel:%make-lisp-obj to create a suitable pointer, and it would all work.
2015-02-09T01:58:01Z nyef: As soon as there's boxed data in that region, however, things get messy.
2015-02-09T01:58:18Z pkhuong: except that the debugger can't tell that the pointer should be treated as legit.
2015-02-09T01:58:27Z |3b|: static-vectors only deals with unboxed data though, right?
2015-02-09T01:58:31Z nyef: Or if the internal-error traps or the debugger try to obtain the value from an interrupt or stack context.
2015-02-09T01:59:17Z fe[nl]ix: |3b|: right
2015-02-09T02:00:04Z |3b|: also, in regards to needing the debugger or not, the problem was that i passed the bounds instead of the index, so validating the index would have helped :)
2015-02-09T02:00:12Z |3b|: *wouldn't have helped
2015-02-09T02:03:54Z fe[nl]ix: nyef: that's pretty much what static-vectors does, just using malloc() instead
2015-02-09T02:03:55Z stassats: and it only uses make-lisp-obj for escaped registers, not for stack values
2015-02-09T02:04:59Z stassats: at least on x86, can we check that memory is readable?
2015-02-09T02:05:16Z stassats: easily, that is
2015-02-09T02:05:48Z pkhuong: even if it is, it could be garbage :\
2015-02-09T02:06:47Z fe[nl]ix: |3b|: I think you're better off doing your own bounds checking, at least for the moment
2015-02-09T02:06:48Z stassats: well, checking for the array unboxed widetag and we don't care if it's garbage
2015-02-09T02:07:05Z pkhuong: n.b., the bound checking works
2015-02-09T02:07:12Z pkhuong: it's only the error reporting that's overly conservative
2015-02-09T02:07:14Z nyef: Being able to register extra-heap spaces with the GC might be interesting.
2015-02-09T02:07:27Z pkhuong: nyef: I have a branch ;)
2015-02-09T02:07:37Z pkhuong: foreign-mark-sweep on github
2015-02-09T02:07:50Z stassats: stack-ref already constructs lisp objects
2015-02-09T02:08:03Z stassats: are registers that much more susceptible to garbage data?
2015-02-09T02:08:12Z fe[nl]ix -> sleep
2015-02-09T02:08:17Z stassats: or is that just accidental?
2015-02-09T02:08:30Z nyef: x86oid registers certainly are.
2015-02-09T02:11:09Z stassats: nyef: but they are still marked properly in the debug map
2015-02-09T02:11:17Z stassats: we don't just print any old registers
2015-02-09T02:11:56Z |3b|: fe[nl]ix: my point is that bounds checking doesn't help if i pass the wrong variable
2015-02-09T02:12:03Z stassats: now, if you managed to get into a CC with following bits coinciding with trap data, things are already pretty bad
2015-02-09T02:12:08Z |3b|: the index was perfectly valid, i just used the wrong variable
2015-02-09T02:12:19Z pkhuong: |3b|: so, bound checking worked.
2015-02-09T02:12:29Z |3b|: pkhuong: that too
2015-02-09T02:12:49Z |3b|: i'm
2015-02-09T02:13:04Z |3b|: i'm just saying that even if it hadn't, doing it myself wouldn't have helped :)
2015-02-09T02:13:45Z ASau quit (Remote host closed the connection)
2015-02-09T02:15:38Z stassats: maybe stack values should get the same treatment, because recently there was a problem with that
2015-02-09T02:15:51Z stassats: but a CONS pointing to garbage data won't be caught
2015-02-09T02:16:43Z pkhuong: can't be perfect.
2015-02-09T02:17:15Z stassats: two directions: make stack access use make-lisp-obj or stop using make-lisp-obj for registers
2015-02-09T02:17:41Z ASau joined #sbcl
2015-02-09T02:18:54Z nyef: cheneygc MAKE-LISP-OBJ used to be an almost pure bounds-check against the heap spaces, rather than the more sophisticated analysis used by gencgc.
2015-02-09T02:19:44Z stassats: when was the last time you've seen such an invalid object?
2015-02-09T02:20:16Z nyef: Haven't been paying attention, TBH.
2015-02-09T02:20:59Z stassats: i think i've seen it after some memory corruption
2015-02-09T02:21:42Z stassats: maybe the debugger should treat any pointer as dangerous
2015-02-09T02:21:54Z stassats: even inside aggregate objects
2015-02-09T02:22:11Z stassats: probably not worth it, though
2015-02-09T02:34:18Z stassats has his weekly "let's tear everything down and write a compiler from scratch"
2015-02-09T02:34:34Z stassats: followed by "nah, too much effort"
2015-02-09T02:34:49Z nyef: Heh. I'm at that point right now, too.
2015-02-09T02:35:13Z |3b| is always at that point :( too many fun targets with annoying 'native' languages
2015-02-09T02:36:22Z stassats: too much embedded tribal knowledge in the compiler hurts
2015-02-09T02:36:38Z ASau quit (Remote host closed the connection)
2015-02-09T02:37:59Z nyef: Which just leads to my theory of legacy code: All code is legacy code.
2015-02-09T02:38:05Z stassats: so, writing a new one should somehow guarantee that it's really well documented
2015-02-09T02:38:40Z stassats: the hard part is "how"
2015-02-09T02:39:38Z stassats: i think i will eventually go that road, using SBCL just to gain some experience
2015-02-09T02:39:42Z stassats: to avoid repeating its mistakes
2015-02-09T02:40:49Z |3b|: stassats: involve academics who will document it for papers?
2015-02-09T02:42:13Z stassats: documenting post facto doesn't usually end well
2015-02-09T02:43:01Z nyef: I find that the best way to document is before-hand, with updates made while and immediately after the code is written.
2015-02-09T02:43:25Z stassats: maybe proving that the thing actually does what you think it does may help
2015-02-09T02:44:17Z nyef: I'm hoping so. Also, having a clear delineation between parts of the compiler.
2015-02-09T02:47:05Z stassats: i think sbcl could use some heavy rewriting of some parts, but the implicit knowledge prevents that
2015-02-09T02:50:48Z pkhuong: I'd rather work on !CL ;)
2015-02-09T02:51:35Z ehaliewicz quit (Remote host closed the connection)
2015-02-09T02:52:07Z ehaliewicz joined #sbcl
2015-02-09T02:59:29Z eudoxia quit (Quit: Leaving)
2015-02-09T03:05:39Z ASau joined #sbcl
2015-02-09T03:12:44Z ehaliewicz quit (Ping timeout: 245 seconds)
2015-02-09T03:26:02Z stassats: errors in assembly routines now can properly locate themselves
2015-02-09T03:29:05Z stassats: but symbol macros and special vars still point to the wrong thing
2015-02-09T03:29:15Z stassats: but that's a different issue
2015-02-09T03:32:34Z ehaliewicz joined #sbcl
2015-02-09T03:33:27Z nyef: Okay, time I got some sleep. Work to do in the morning. /-:
2015-02-09T03:33:34Z nyef quit (Quit: G'night all.)
2015-02-09T03:39:12Z christoph_debian quit (Ping timeout: 252 seconds)
2015-02-09T03:52:47Z christoph_debian joined #sbcl
2015-02-09T04:12:50Z LiamH quit (Quit: Leaving.)
2015-02-09T04:29:55Z selat quit (Quit: Lost terminal)
2015-02-09T04:34:49Z stassats` quit (Ping timeout: 245 seconds)
2015-02-09T04:35:06Z stassats quit (Ping timeout: 245 seconds)
2015-02-09T05:17:10Z pranavrc joined #sbcl
2015-02-09T05:23:35Z ehaliewicz quit (Remote host closed the connection)
2015-02-09T05:28:08Z pranavrc_ joined #sbcl
2015-02-09T05:31:37Z pranavrc quit (Ping timeout: 264 seconds)
2015-02-09T05:56:44Z pranavrc_ quit
2015-02-09T05:57:04Z pranavrc joined #sbcl
2015-02-09T05:57:05Z pranavrc quit (Changing host)
2015-02-09T05:57:05Z pranavrc joined #sbcl
2015-02-09T06:12:55Z DeadTrickster joined #sbcl
2015-02-09T07:10:10Z milosn joined #sbcl
2015-02-09T07:21:43Z pranavrc quit (Remote host closed the connection)
2015-02-09T07:23:04Z pranavrc joined #sbcl
2015-02-09T07:30:55Z gingerale joined #sbcl
2015-02-09T07:32:01Z psy_ quit (Quit: Leaving)
2015-02-09T07:35:50Z Shinmera joined #sbcl
2015-02-09T07:37:16Z oleo is now known as Guest3301
2015-02-09T07:38:08Z oleo__ joined #sbcl
2015-02-09T07:40:55Z Guest3301 quit (Ping timeout: 256 seconds)
2015-02-09T07:45:31Z milosn quit (Remote host closed the connection)
2015-02-09T07:54:30Z psy_ joined #sbcl
2015-02-09T08:09:53Z minion quit (Remote host closed the connection)
2015-02-09T08:09:59Z minion joined #sbcl
2015-02-09T08:12:57Z akkad quit (Ping timeout: 252 seconds)
2015-02-09T08:13:41Z soggybread quit (Ping timeout: 252 seconds)
2015-02-09T08:14:43Z soggybread joined #sbcl
2015-02-09T08:19:17Z akkad joined #sbcl
2015-02-09T08:36:54Z Quadrescence quit (Quit: This computer has gone to sleep)
2015-02-09T08:37:15Z Quadrescence joined #sbcl
2015-02-09T08:39:40Z angavrilov joined #sbcl
2015-02-09T08:42:40Z Xof quit (Remote host closed the connection)
2015-02-09T08:47:15Z milosn joined #sbcl
2015-02-09T09:02:07Z Cymew quit (Quit: Konversation terminated!)
2015-02-09T09:35:57Z Quadrescence quit (Quit: This computer has gone to sleep)
2015-02-09T09:39:30Z scymtym_ joined #sbcl
2015-02-09T09:45:34Z milosn quit (Ping timeout: 255 seconds)
2015-02-09T09:47:15Z milosn joined #sbcl
2015-02-09T10:31:38Z oleo__ is now known as oleo
2015-02-09T10:37:39Z pranavrc quit (Remote host closed the connection)
2015-02-09T10:39:34Z pranavrc joined #sbcl
2015-02-09T10:41:44Z gabriel_laddel quit (Ping timeout: 246 seconds)
2015-02-09T10:57:03Z alchemis7 quit (Ping timeout: 245 seconds)
2015-02-09T10:57:54Z psy_ quit (Read error: No route to host)
2015-02-09T11:00:55Z selat joined #sbcl
2015-02-09T11:01:58Z |3b| quit (Excess Flood)
2015-02-09T11:02:04Z dustinm` quit (Ping timeout: 245 seconds)
2015-02-09T11:02:13Z psy_ joined #sbcl
2015-02-09T11:03:03Z dustinm` joined #sbcl
2015-02-09T11:03:38Z |3b| joined #sbcl
2015-02-09T11:13:56Z eudoxia joined #sbcl
2015-02-09T11:50:34Z karswell quit (Read error: Connection reset by peer)
2015-02-09T11:50:48Z karswell joined #sbcl
2015-02-09T12:02:20Z fridim_ joined #sbcl
2015-02-09T12:07:59Z Cymew joined #sbcl
2015-02-09T12:08:11Z scymtym_ quit (Ping timeout: 246 seconds)
2015-02-09T13:13:37Z attila_lendvai joined #sbcl
2015-02-09T13:13:37Z attila_lendvai quit (Changing host)
2015-02-09T13:13:37Z attila_lendvai joined #sbcl
2015-02-09T13:17:25Z psy_ quit (Ping timeout: 250 seconds)
2015-02-09T13:20:11Z Adlai joined #sbcl
2015-02-09T13:24:42Z pranavrc quit
2015-02-09T13:27:17Z psy_ joined #sbcl
2015-02-09T13:44:28Z ASau` joined #sbcl
2015-02-09T13:47:56Z ASau quit (Ping timeout: 246 seconds)
2015-02-09T13:48:01Z ASau` is now known as ASau
2015-02-09T13:53:36Z stassats` joined #sbcl
2015-02-09T13:53:53Z stassats joined #sbcl
2015-02-09T13:57:02Z psilord1 quit (Quit: Leaving.)
2015-02-09T14:00:30Z stassats`: oops, something bad happens with debug-dump after my assembly routine change
2015-02-09T14:07:43Z Adlai quit (*.net *.split)
2015-02-09T14:13:22Z stassats quit (Remote host closed the connection)
2015-02-09T14:13:43Z stassats joined #sbcl
2015-02-09T14:50:38Z alchemis7 joined #sbcl
2015-02-09T14:52:11Z salva quit (Ping timeout: 250 seconds)
2015-02-09T15:07:00Z salva joined #sbcl
2015-02-09T15:07:44Z psilord1 joined #sbcl
2015-02-09T15:29:30Z eudoxia quit (Quit: Leaving)
2015-02-09T15:38:20Z Shinmera- joined #sbcl
2015-02-09T15:39:45Z Shinmera quit (Ping timeout: 256 seconds)
2015-02-09T16:04:52Z stassats`: throw and elswhere errors get confused
2015-02-09T16:06:38Z stassats`: looks like a by one error
2015-02-09T16:13:15Z stassats`: for some reason, throw errors show that it was called from a XEP
2015-02-09T16:17:53Z stassats`: what do we use single-value-return locations kind for?
2015-02-09T16:18:42Z stassats`: ... for breakpoints
2015-02-09T16:23:33Z ShinmerARGH joined #sbcl
2015-02-09T16:23:45Z ShinmerARGH is now known as Shinmera
2015-02-09T16:24:43Z Shinmera- quit (Ping timeout: 255 seconds)
2015-02-09T16:49:17Z ASau quit (Remote host closed the connection)
2015-02-09T16:50:09Z ASau joined #sbcl
2015-02-09T17:01:40Z milosn quit (Ping timeout: 244 seconds)
2015-02-09T17:14:40Z psy_ quit (Ping timeout: 252 seconds)
2015-02-09T17:37:37Z selat quit (Ping timeout: 255 seconds)
2015-02-09T17:52:58Z psy_ joined #sbcl
2015-02-09T18:16:26Z milosn joined #sbcl
2015-02-09T18:33:59Z milosn quit (Ping timeout: 245 seconds)
2015-02-09T18:45:57Z milosn joined #sbcl
2015-02-09T18:54:57Z selat joined #sbcl
2015-02-09T19:28:10Z Adlai joined #sbcl
2015-02-09T19:28:33Z Adlai quit (Remote host closed the connection)
2015-02-09T19:52:53Z scymtym_ joined #sbcl
2015-02-09T19:54:44Z selat quit (Quit: Lost terminal)
2015-02-09T20:11:53Z oleo is now known as Guest22276
2015-02-09T20:12:46Z oleo__ joined #sbcl
2015-02-09T20:12:49Z karswell quit (Read error: Connection reset by peer)
2015-02-09T20:13:05Z karswell joined #sbcl
2015-02-09T20:14:52Z Guest22276 quit (Ping timeout: 245 seconds)
2015-02-09T20:20:36Z fiveop joined #sbcl
2015-02-09T20:26:00Z nicdev quit (Remote host closed the connection)
2015-02-09T20:26:17Z nicdev` joined #sbcl
2015-02-09T20:35:36Z fiveop quit (Quit: bye)
2015-02-09T20:36:00Z akkad quit (Remote host closed the connection)
2015-02-09T20:50:00Z oleo__ is now known as oleo
2015-02-09T20:55:49Z akkad joined #sbcl
2015-02-09T21:04:50Z Shinmera quit (Quit: しつれいしなければならないんです。)
2015-02-09T21:13:46Z Bicyclidine joined #sbcl
2015-02-09T21:21:15Z angavrilov quit (Remote host closed the connection)
2015-02-09T21:21:53Z gingerale quit (Ping timeout: 250 seconds)
2015-02-09T21:22:31Z White_Flame joined #sbcl
2015-02-09T22:08:12Z mega1 quit (Ping timeout: 245 seconds)
2015-02-09T22:36:10Z karswell quit (Read error: Connection reset by peer)
2015-02-09T22:36:13Z fridim_ quit (Ping timeout: 245 seconds)
2015-02-09T22:36:25Z karswell joined #sbcl
2015-02-09T22:48:56Z Bicyclidine quit (Quit: leaving)
2015-02-09T22:57:27Z karswell quit (Read error: Connection reset by peer)
2015-02-09T22:57:39Z karswell joined #sbcl
2015-02-09T23:01:34Z psilord1 quit (Quit: Leaving.)
2015-02-09T23:03:44Z irsol quit (Ping timeout: 246 seconds)
2015-02-09T23:06:52Z drmeister quit (Read error: Connection reset by peer)
2015-02-09T23:07:06Z irsol joined #sbcl
2015-02-09T23:10:07Z Bicyclidine joined #sbcl
2015-02-09T23:10:15Z eudoxia joined #sbcl
2015-02-09T23:12:05Z irsol quit (Ping timeout: 246 seconds)
2015-02-09T23:13:58Z irsol joined #sbcl
2015-02-09T23:25:19Z eudoxia quit (Quit: Leaving)
2015-02-09T23:26:25Z ASau quit (Remote host closed the connection)
2015-02-09T23:52:45Z Bicyclidine quit (Quit: leaving)