00:09:54 -!- jhao [~junhao@pool-72-76-190-214.nwrknj.fios.verizon.net] has quit [Quit: jhao] 00:12:00 jhao [~junhao@pool-72-76-190-214.nwrknj.fios.verizon.net] has joined #sbcl 00:18:07 -!- ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has quit [Quit: Computer has gone to sleep.] 00:43:45 -!- oleo [~oleo@xdsl-78-35-159-149.netcologne.de] has quit [Read error: Operation timed out] 00:44:39 oleo [~oleo@xdsl-78-35-133-173.netcologne.de] has joined #sbcl 02:41:07 -!- jhao [~junhao@pool-72-76-190-214.nwrknj.fios.verizon.net] has quit [Quit: jhao] 02:42:35 jhao [~junhao@pool-72-76-190-214.nwrknj.fios.verizon.net] has joined #sbcl 02:56:45 -!- scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has quit [Ping timeout: 272 seconds] 03:16:43 edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has joined #sbcl 03:34:23 -!- nyef [~nyef@pool-64-222-145-64.man.east.myfairpoint.net] has quit [Quit: G'night all.] 03:37:33 ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has joined #sbcl 03:38:53 -!- christoph_debian [~christoph@ppp-88-217-34-18.dynamic.mnet-online.de] has quit [Ping timeout: 252 seconds] 03:47:43 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 03:52:13 christoph_debian [~christoph@ppp-88-217-55-224.dynamic.mnet-online.de] has joined #sbcl 04:09:06 yacks [~py@103.6.159.103] has joined #sbcl 04:29:56 -!- ASau` is now known as ASau 04:38:38 -!- ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has quit [Quit: Computer has gone to sleep.] 05:02:15 -!- jhao [~junhao@pool-72-76-190-214.nwrknj.fios.verizon.net] has quit [Quit: jhao] 05:04:57 ltbarcly [~textual@pool-108-42-99-156.snfcca.fios.verizon.net] has joined #sbcl 05:21:11 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 252 seconds] 05:22:33 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 05:25:55 dto [~user@pool-100-0-107-54.bstnma.fios.verizon.net] has joined #sbcl 05:26:17 pkhuong: i followed u on twitter :) 05:30:29 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 240 seconds] 05:31:53 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 05:37:26 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 264 seconds] 05:43:58 -!- ubii [~ubii@unaffiliated/ubii] has quit [Quit: Leaving] 05:44:12 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 05:57:44 -!- oleo [~oleo@xdsl-78-35-133-173.netcologne.de] has quit [Quit: Leaving] 06:48:35 -!- yacks [~py@103.6.159.103] has quit [Read error: Connection reset by peer] 06:50:13 prxq [~mommer@x2f69d81.dyn.telefonica.de] has joined #sbcl 07:26:25 yacks [~py@122.179.86.89] has joined #sbcl 07:47:15 werebutt [~buttbutt@46.165.251.66] has joined #sbcl 07:47:17 -!- werebutt [~buttbutt@46.165.251.66] has left #sbcl 08:56:13 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 265 seconds] 08:56:48 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:46:10 -!- ASau [~user@p54AFF70F.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 09:46:26 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 264 seconds] 09:46:47 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:47:53 ASau [~user@p54AFF70F.dip0.t-ipconnect.de] has joined #sbcl 10:26:09 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Quit: Lost terminal] 10:33:14 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 264 seconds] 10:36:38 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 10:49:49 -!- dto [~user@pool-100-0-107-54.bstnma.fios.verizon.net] has quit [Remote host closed the connection] 11:37:08 stassats [~stassats@wikipedia/stassats] has joined #sbcl 11:43:33 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 252 seconds] 11:53:33 michael_lee [~michael_l@1.80.7.170] has joined #sbcl 12:56:06 -!- yacks [~py@122.179.86.89] has quit [Remote host closed the connection] 13:05:35 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 260 seconds] 13:12:58 nyef [~nyef@pool-64-222-145-64.man.east.myfairpoint.net] has joined #sbcl 13:13:07 G'morning all. 13:36:29 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 13:41:30 okay 13:41:33 ups sry 13:54:41 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 14:03:56 yacks [~py@103.6.159.103] has joined #sbcl 14:33:15 oleo [~oleo@xdsl-87-78-78-198.netcologne.de] has joined #sbcl 14:33:38 -!- oleo [~oleo@xdsl-87-78-78-198.netcologne.de] has quit [Max SendQ exceeded] 14:36:04 drmeister [~drmeister@155.247.96.196] has joined #sbcl 14:48:04 oleo [~oleo@xdsl-87-78-78-198.netcologne.de] has joined #sbcl 14:56:02 -!- drmeister [~drmeister@155.247.96.196] has quit [Read error: Connection reset by peer] 14:56:23 drmeister [~drmeister@155.247.96.196] has joined #sbcl 15:05:58 stassats [~stassats@wikipedia/stassats] has joined #sbcl 15:20:58 -!- michael_lee [~michael_l@1.80.7.170] has quit [Remote host closed the connection] 15:34:44 Is there any SBCL code that implements access to the CPU's "find first bit set" and similar instructions? 15:35:19 VOPs 15:35:22 there are bitops yes 15:35:38 reb`: don't listen to oleo 15:36:19 -!- ASau [~user@p54AFF70F.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 15:38:41 I know of VOPs. Do VOPs currently exist for ffs, clz, ... ? If not, is adding a contrib, something along the lines of sb-rotate-byte, the right way to add the functionality to SBCL? 15:39:32 ASau [~user@p54AFF70F.dip0.t-ipconnect.de] has joined #sbcl 15:42:19 If you want it in SBCL, rather than as a separate library, then a contrib is probably appropriate. 15:43:00 Also note that we'd want "generic" versions for when a CPU-specific version hasn't been implemented. 15:43:14 And that "find-leftmost set bit" is integer-length. 15:43:42 Ideally, there would be a library, something like nibbles, that implements the operations for other CL systems too. 15:43:58 reb`: https://github.com/sionescu/swap-bytes is a way to add such functionality 15:45:54 Thanks! 15:46:18 Oh, and for the record, I'm currently thinking that I'm unlikely to find and fix whatever's breaking the SPARC backend before Wednesday. 15:47:07 reb`: something like (integer-length (logxor x (1- x))) is portable, in the meantime? 15:47:45 Or maybe (logand x (- x))? (ok, first, coffee) 15:48:10 Ooh. Coffee. Great idea, I hope that there's still some left. 15:49:37 nyef: #-sparc the pack changes? 15:50:35 -!- oleo [~oleo@xdsl-87-78-78-198.netcologne.de] has quit [Remote host closed the connection] 15:51:12 And this is just the backends that we're able to at least somewhat check. Has anyone done a MIPS build recently? 15:51:38 oleo [~oleo@xdsl-87-78-78-198.netcologne.de] has joined #sbcl 15:51:44 pkhuong: Thanks ... http://en.wikipedia.org/wiki/Find_first_set lists several identities that may be helpful. 15:52:35 great, things for me to write about in the release notes 15:52:42 nyef: if you have disassembly for a couple interesting functions, I can look into it. 15:53:36 I have three trace files, one of which probably contains at least one lifetime error. Five trace files if we count the ones from before I killed the instruction scheduler. 15:54:03 how many KB is? 15:54:41 12M for the unscheduled files, 6.1M for the scheduled files. 15:55:14 ow 15:55:24 too bad it's on single float. 15:55:45 doubles, I would have checked for partial overwrites. 15:56:25 And while I have an idea for a tool to try and at least track down possible lifetime issues, I don't have the time right now to sit down and work out the actual code to do so. 15:56:54 or #+(or ppc x86 x86-64) them 15:59:50 nyef: what kind of stuff would you have in stack component TNs? 15:59:54 on sparc? 16:00:25 Component-live stack TNs? 16:00:38 yeah 16:01:12 Component-live, so it's probably on the control stack rather than the number stack... 16:02:47 Got nothing, I'm afraid. 16:03:27 NFP, LRA, and OCFP are about the only things that come to mind as possibilities. 16:03:34 NFP would work. 16:03:52 NFP corruption -> read a nan. 16:04:55 but nfp save is wired. 16:04:55 Mmm. But typically it'd be the save location that's on the stack, and the frame pointer normally be in a register. 16:06:58 senj [~senj@unaffiliated/senj] has joined #sbcl 16:07:17 ... Component-live, so it's probably a variable under high DEBUG? 16:09:12 -!- oleo [~oleo@xdsl-87-78-78-198.netcologne.de] has quit [Remote host closed the connection] 16:09:27 it's a weak hunch anyway. It just seems to me like that commit might affect implicit ordering accidents for component-live TNs more than normal ones. 16:09:56 Component-live TNs, by definition, don't die, so aren't subject to lifetime issues? 16:10:18 oleo [~oleo@xdsl-87-78-78-198.netcologne.de] has joined #sbcl 16:10:39 but the commit changes the order in which they're allocated on the stack. 16:12:11 It also changes the ordering for normal TNs when there has been a loop-analysis phase? 16:13:06 it does, but that was already a shuffled before the commit 16:13:22 do we insert fixup code somewhere to align nfp? 16:13:42 because otherwise, I don't see how we can guarantee the alignment needed by doubles 16:14:16 Yeah, bytes-needed-for-non-descriptor-stack-frame in sparc/call.lisp. 16:16:45 You know, that's a far, far better explanation for that requirement than just "required for PMAX". 16:17:05 heh 16:21:18 also, do we initialise nsp with enough initial padding for number-stack-displacement? 16:22:00 I have no idea? 16:25:25 I can't think about this. 16:26:13 Yeah, and while I have a couple of angles for nailing it down programmatically, I don't have time right now to follow through. 16:28:29 -!- oleo [~oleo@xdsl-87-78-78-198.netcologne.de] has quit [Remote host closed the connection] 16:32:52 -!- yacks [~py@103.6.159.103] has quit [Quit: Leaving] 16:34:35 -!- drmeister [~drmeister@155.247.96.196] has quit [Ping timeout: 252 seconds] 16:42:26 crixus [~Rob@69.77.176.98] has joined #sbcl 16:48:38 drmeister [~drmeister@155.247.96.196] has joined #sbcl 16:56:37 -!- crixus [~Rob@69.77.176.98] has quit [Ping timeout: 248 seconds] 17:00:53 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 248 seconds] 17:12:38 -!- jdz [~jdz@212.36.34.246] has quit [Quit: Leaving] 17:15:01 oleo [~oleo@xdsl-87-78-78-198.netcologne.de] has joined #sbcl 17:18:46 jdz [~jdz@212.36.34.246] has joined #sbcl 17:19:45 -!- edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has quit [Quit: memory access discontinued by timeout after 8569196249388701693955738 seconds] 17:26:25 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 17:29:51 slyrus [~chatzilla@107.201.5.56] has joined #sbcl 17:30:50 -!- jdz [~jdz@212.36.34.246] has quit [Ping timeout: 245 seconds] 17:31:01 crixus [~Rob@69.77.176.98] has joined #sbcl 17:31:14 jdz [~jdz@mail.prosperitycapital.com] has joined #sbcl 17:51:16 -!- crixus [~Rob@69.77.176.98] has quit [Ping timeout: 265 seconds] 18:09:22 jdz_ [~jdz@212.36.34.246] has joined #sbcl 18:12:49 -!- jdz [~jdz@mail.prosperitycapital.com] has quit [Ping timeout: 272 seconds] 18:22:07 fiveop [~fiveop@p5DDC458B.dip0.t-ipconnect.de] has joined #sbcl 18:22:37 hi 18:23:22 Hello. 18:23:24 nyef: I pushed my changes from last week 18:23:41 Okay. I got started on my bit and then got sideswiped by a few different things. 18:24:01 My next step is STILL doing the floaty instruction definitions. 18:24:04 your bit being floating point stuff? 18:24:08 Yeah. 18:24:31 I commented out some more floating point related stuff, which might cause merge conflicts, other than that we should be fine 18:24:33 I at least want the SCs in place, the instructions defined, and the basic MOVE stuff done. 18:24:58 If you tell me which instructions you plan to offer, I can have a look at that as well. 18:25:04 After I have that much done, I'll let you fix up the actual operations... 18:25:06 Defining instructions did not look to difficult 18:25:47 Sure, but that was my second attempt at writing instruction definitions for ARM, IIRC. 18:27:18 I can just continue to go down the build order list. 18:27:36 I'm also trying to make sure that we can cover the... six or seven different FP architectures for ARM, or at least leave hooks for them. 18:27:49 I made some progress, but when you have no internet access, you hit points where you have to guess what the instructions of other ARCHs actually do 18:28:11 isn't there something loke platform specific features? 18:28:14 like 18:28:31 Yeah, there are a few options for platform-specific features. 18:28:57 The reason that I keep looking to PPC to crib code is because the architecture is similar, but I keep looking to MIPS to figure out how the code works because I'm more familiar with how the MIPS architecture works. 18:29:24 I look at mips first, because its instruction set is simpler :) 18:29:45 Well, that too. 18:30:10 But I've actually tried to write a MIPS CPU simulator before, so I still have some background on what various bits do. 18:33:20 Anyway, I've sortof gotten sideswiped by trying to debug the SPARC build failure on HEAD, which led to coming up with a great idea for a debugging tool for a specific class of problems that we run into, but I haven't managed to write the tool yet (and it took me most of a day to realize how massively obnoxious the incidental problem space is, let alone the actual debugging issue)... 18:49:33 delayed slot is always a pita 18:51:18 stassats [~stassats@wikipedia/stassats] has joined #sbcl 18:59:01 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 19:04:14 crixus [~Rob@69.77.176.98] has joined #sbcl 19:16:36 H4ns [hans@netzhansa.com] has joined #sbcl 19:17:24 did anyone recently notice with amazon linux and large dynamic space sizes? i'm using --dynamic-space-size 15000 on an instance with 30gb ram and it fails. 19:20:46 define "fails" 19:20:50 -!- drmeister [~drmeister@155.247.96.196] has quit [Remote host closed the connection] 19:22:04 mmap: Cannot allocate memory 19:22:04 ensure_space: failed to validate 15728640000 bytes at 0x1000000000 19:22:43 /proc/sys/vm/max_map_count ? 19:22:51 -!- crixus [~Rob@69.77.176.98] has quit [Ping timeout: 272 seconds] 19:22:59 65530 19:23:46 ulimit? 19:23:52 unlimited 19:24:48 overcommit? 19:25:54 nyef: how'd i find out? 19:26:11 It's some option in /proc/sys/vm/, IIRC. 19:26:42 /proc/sys/vm/overcommit_memory is set to 2 19:26:48 but there is enough memory available 19:27:03 Conflicting address space? 19:27:20 hm. 19:27:32 setting overcommit_memory to 0 fixes the problem for me. thanks, nyef! 19:27:33 1.1.9.xx: * (sb-ext:dynamic-space-size) => 15728640000 19:28:22 what about 1? 19:29:03 there's /proc/sys/vm/overcommit_ratio when it comes to 2 19:29:08 stassats: 0 seems good. or 2 and some other setting for overcommit_ratio 19:29:09 I have 1, here. 19:30:08 1 is "always overcommit" 19:30:15 0 is "use some heuristic" 19:31:16 seems silly that i even have to worry, as i have enough friggin ram 19:31:24 but whatever, thanks! :) 19:32:05 "ensure_space: failed to validate" can probably mention overcommitting 19:39:39 crixus [~Rob@69.77.176.98] has joined #sbcl 20:12:13 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 245 seconds] 20:23:07 Here is a problem I have, that I do not understand: 2^32-1 does not fit into a fixnum and I still get it as Y in a VOP based on this 'base VOP': http://paste.lisp.org/display/141049 20:27:07 documentation says ":CONSTANT specifies that the argument must be a compile-time constant of the specified Lisp type." 20:27:25 I guess it means lisp type of target, right? 20:27:43 Oh! You said FIXNUM, but it's doing the type-test on the host. 20:28:15 :) 20:29:21 Hrm. Maybe. 20:30:28 Yeah, that's my best guess, but I'm not sure if it's supported by customary usage. 20:30:56 what's your guess? 20:31:01 One way to find out is to use a 32-bit build host. 20:31:27 I can do that, once we got it running on arm ;) 20:31:27 drmeister [~drmeister@155.247.96.196] has joined #sbcl 20:31:43 You're on an x86-64, aren't you? 20:32:04 If you've got a multilib host, you should be able to run a 32-bit SBCL binary. 20:32:48 Meanwhile, (:constant (signed-byte #.n-fixnum-bits)) might work. 20:34:45 that's probably more readable than (integer -2something8 2something7) 20:45:30 sb!xc:fixnum 20:46:13 or (sb!int:fixnump x) if that's how you're testing 20:47:24 Its for a arg-type field of a VOP of type (:constant ...) 20:47:33 so the first one looks right 20:50:55 ;;; This is used by the debugger. 20:51:00 That's an awesome comment 20:51:12 (for single-value-return-byte-offset) 20:52:24 -!- oleo [~oleo@xdsl-87-78-78-198.netcologne.de] has quit [Quit: Leaving] 20:56:29 oleo [~oleo@xdsl-87-78-78-198.netcologne.de] has joined #sbcl 20:57:35 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 21:06:37 Ah, right. So, SINGLE-VALUE-RETURN-BYTE-OFFSET doesn't apply to x86oids or ARM. 21:07:26 Everywhere else, it's typically either one or two instructions wide. 21:11:33 lra-offset is also missing (since we have no such register) but it's only used in an error message 21:12:11 (and single-step-before-trap, which seems to occur in an enum of trap constants starting at 8 for other arches) 21:13:03 Yeah, like on x86, LRA is passed on-stack. Unlike on x86, it's a proper boxed LRA. 21:13:21 As far as the single-step trap goes, you could just add that if you wanted. 21:14:39 the whole bunch of trap constants? 21:22:43 Which ones are missing, and which ones need to be handled specially? 21:23:46 Noting that some platforms (including ARM) do clever things in the runtime to pick out special conventions for certain traps. 21:24:24 -!- oleo [~oleo@xdsl-87-78-78-198.netcologne.de] has quit [Ping timeout: 265 seconds] 21:24:31 What do the values of these constants represent? (I answer with a counter question, because I don't understand what you are saying.) 21:24:57 (I just added single-step-before-trap and single-step-after-trap) 21:25:32 ... single-step-after-trap? That's not familiar-looking? 21:26:13 around 21:26:14 sorry 21:28:50 There's some specific magic for SPARC pseudo-atomic-trap in genesis... 21:29:58 Wait, there's a hook in the runtime such that the single-step traps aren't required. 21:30:14 And it doesn't look like something that I added, so we might have lost flexibility somewhere... 21:34:06 If you get as far as trying to figure out the fun_end_breakpoint_guts thing, the PPC version has the best explanation. 21:39:05 I'm working to improve my backtraces - here's a backtrace from sbcl: https://gist.github.com/anonymous/e33d2f62e027df9b1781 21:40:17 The forms that are generated for frames 1-11, how are they stored in SBCL? Are they s-expressions tied to the frames? If so how much of the S-exp is stored? Or are they strings embedded in the compiled code? If so - how many characters are stored? 21:41:12 (c) neither of the above? 21:41:25 functions have names; the debugger knows where arguments are passed in function calls 21:41:33 I love neither of the above! How are they stored? 21:41:58 so it can print function calls out by knowing the name of the function, the number of arguments that were passed, and where those arguments were 21:42:42 But frame 6, 10 and 11 are not function calls - they are a lambda, an flet and a labels respectively. 21:43:08 those are the "debug names" of the respective function objects 21:43:13 they don't have global names 21:43:29 -!- Krystof_ is now known as Krystof 21:43:37 -!- ChanServ has set mode +o Krystof 21:43:44 I see what you mean - they aren't properly formed flet and labels expressions. 21:45:37 Come to think of it I don't find the SBCL backtraces very readable. Do you know of any Common Lisp implementations with beautiful backtraces? 21:46:02 http://jsnell.iki.fi/blog/archive/2007-12-19-pretty-sbcl-backtraces.html # make your own backtraces 21:46:55 -!- drmeister [~drmeister@155.247.96.196] has quit [Read error: Connection reset by peer] 21:47:00 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 21:47:54 (the comments on that are even more hilarious than I remembered) 21:49:02 Sorry for the dropout - I loose my wireless sometimes. 21:49:07 Thanks for that link. 21:50:41 Hmmm, I was tying myself up in knots trying to create more informative backtraces and now it's pretty clear - that's a really hard problem. 21:50:52 -!- drmeiste_ is now known as drmeister 21:52:40 oleo [~oleo@xdsl-78-35-159-175.netcologne.de] has joined #sbcl 21:52:56 stassats [~stassats@wikipedia/stassats] has joined #sbcl 22:04:29 Can "no warm symbol" errors come from me not compiling and 'linking' all the files in build-order before that file? 22:06:32 Where does the error show up? 22:06:59 Ah, genesis. 22:07:03 code/external-format/enc-basic 22:08:58 I'm not sure how that happens. 22:11:33 stacktrace is cold-fop-fdefinition -> cold-fdefinition-object -> warm-fun-name -> warm-symbol 22:11:42 that's where my guess comes from 22:13:35 Yeah, it's been a while since I dug into this part of the system. 22:13:59 as for the fun_end_breakpoint_trap stuff 22:14:21 before I can do stuff like that I have to know the calling conventions 22:18:25 Port-log-2, 2012-Oct-07, 2012-Oct-09, 2012-Oct-12, 2012-Oct-15, 2012-Oct-19... That's about when I was nailing down the calling-convention stuff. 22:18:41 Also doc/internals/calling-convention.texinfo. 22:20:17 Worst-case scenario, just put the symbol definitions into arm-assem.S and leave out the actual code. It won't work, but the debugger can at least build that way. 22:26:54 put that in my notes for tomorrow 22:26:57 good night 22:27:01 -!- fiveop [~fiveop@p5DDC458B.dip0.t-ipconnect.de] has quit [] 22:58:09 -!- drmeister [~drmeister@155.247.96.196] has quit [Remote host closed the connection] 23:06:29 drmeister [~drmeister@166.170.22.208] has joined #sbcl 23:14:38 -!- slyrus [~chatzilla@107.201.5.56] has quit [Ping timeout: 264 seconds] 23:15:14 -!- crixus [~Rob@69.77.176.98] has quit [Ping timeout: 264 seconds] 23:20:04 crixus [~Rob@69.77.176.98] has joined #sbcl 23:22:54 slyrus [~chatzilla@137.164.119.50] has joined #sbcl 23:23:40 davazp [~user@14.Red-79-152-116.dynamicIP.rima-tde.net] has joined #sbcl 23:34:26 -!- H4ns [hans@netzhansa.com] has left #sbcl 23:36:57 -!- prxq [~mommer@x2f69d81.dyn.telefonica.de] has quit [Quit: Leaving] 23:41:58 -!- drmeister [~drmeister@166.170.22.208] has quit [Read error: Connection reset by peer] 23:45:19 faheem_ [~faheem@bulldog.duhs.duke.edu] has joined #sbcl 23:46:47 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Quit: trivial-irc-0.0.4] 23:48:45 -!- slyrus [~chatzilla@137.164.119.50] has quit [Ping timeout: 272 seconds] 23:48:46 -!- faheem [~faheem@bulldog.duhs.duke.edu] has quit [Ping timeout: 272 seconds] 23:48:47 -!- nicdev [~user@kilimanjaro.rafpepa.com] has quit [Ping timeout: 272 seconds] 23:48:55 nicdev` [~user@kilimanjaro.rafpepa.com] has joined #sbcl 23:54:19 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 23:54:36 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 23:55:03 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 23:56:19 ASau` [~user@p5083D1F6.dip0.t-ipconnect.de] has joined #sbcl