00:35:06 akovalen` [~user@95.72.98.221] has joined #sbcl 00:37:18 -!- akovalenko [~user@195.18.46.21] has quit [Ping timeout: 264 seconds] 00:52:17 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 00:56:40 -!- foom [jknight@nat/google/x-jvglobsudijbeyxu] has quit [Read error: Operation timed out] 01:05:05 -!- Thra11 [~thrall@87.114.6.186] has quit [Ping timeout: 258 seconds] 01:11:06 foom [jknight@nat/google/x-snhpiofdoabljylo] has joined #sbcl 01:15:35 ASau` [~user@46.115.44.212] has joined #sbcl 01:18:53 -!- ASau [~user@46.115.38.154] has quit [Ping timeout: 258 seconds] 02:34:46 -!- Fare [fare@nat/google/x-tuydzdqsqahuhdxt] has quit [Ping timeout: 258 seconds] 03:31:07 yacks [~yacks@180.151.36.168] has joined #sbcl 03:48:03 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 03:52:05 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 04:22:55 hlavaty` [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 04:24:48 -!- hlavaty [~user@friedrichstrasse.knowledgetools.de] has quit [Ping timeout: 264 seconds] 04:44:08 attila_lendvai [~attila_le@92.46.11.102] has joined #sbcl 04:44:09 -!- attila_lendvai [~attila_le@92.46.11.102] has quit [Changing host] 04:44:09 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:53:45 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 260 seconds] 05:06:51 Fare [fare@nat/google/x-ddvuyfxiuptowwkm] has joined #sbcl 05:19:13 -!- Fare [fare@nat/google/x-ddvuyfxiuptowwkm] has quit [Ping timeout: 258 seconds] 05:24:44 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 05:58:30 -!- akovalen` [~user@95.72.98.221] has quit [Ping timeout: 260 seconds] 06:10:49 sdemarre [~serge@109.134.133.85] has joined #sbcl 06:31:27 -!- sdemarre [~serge@109.134.133.85] has left #sbcl 06:45:01 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 07:42:38 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 07:52:39 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 08:23:26 prxq [~mommer@mnhm-590c0ef8.pool.mediaWays.net] has joined #sbcl 08:24:46 very weird, (describe #'sb-c::bound-func) shows Lambda-list: (F X STRICT), while it's actually just (F X) 08:26:59 oh damn, had bad HEAD due to bisecting 08:31:05 -!- ASau` [~user@46.115.44.212] has quit [Ping timeout: 255 seconds] 09:22:02 wbooze [~wbooze@xdsl-78-35-145-60.netcologne.de] has joined #sbcl 09:23:34 akovalenko [~user@195.18.46.21] has joined #sbcl 09:31:43 -!- yacks [~yacks@180.151.36.168] has quit [Ping timeout: 260 seconds] 09:39:06 yacks [~yacks@180.151.36.168] has joined #sbcl 09:44:20 I was wondering if this could be relatively easily adapted to sbcl: http://luajit.org/ext_ffi.html 09:44:20 it's a totally dynamic ffi (in lua). you can throw C definitions at it at runtime, and in its JIT it compiles it when needed, so it's not even too slow... 09:49:23 attila_lendvai: I don't think ext_fii was easy to develop ;) 09:50:47 pkhuong: me neither, but the ideas are there, and the implementation strategy is also. 09:51:18 I once wrote the FFI of slate, and I remember that it was relatively fun 09:52:25 If I were going in that area, I'd wrap clang and get C++ interop, cpp macros and all. 09:54:48 pkhuong: +1 09:56:17 yeah, good point 09:56:19 pkhuong: for <>, we have something that parses C headers now  but I'm slowly making it have multiple type providers so that I can replace the current C parser with libclang  but also gobject-introspection and probably BridgeSupport. 09:56:44 (and then let that generate the bindings as we currently do) 09:57:33 brucem: I was thinking of exploiting cling to get LLVM to perform codegen. 09:57:35 -!- milosn_ is now known as milosn 09:57:59 pkhuong: where this gets to be painful is in building a distribution for people to download. 09:59:05 pkhuong: do you let them try to use their existing stuff? do you require that they build it? do you try to pull and build your own copy?  and depending on what you're doing and on what platforms, it is a total mess as things may or may not work with, say, the 3.1 or 3.2 releases (vs ToT or what is bundled with XCode). 10:00:19 pkhuong: Julia builds their own specific version. emscripten requires that the user install the right version (3.2) and only works with a single blessed version at once. I don't know what a good answer is for what I work on (nor for sbcl or others). :/ 10:05:19 pkhuong: I look forward to 5 years from now when some of this has settled down some. :) 10:06:38 right... 10:08:02 pkhuong: I'm doing some contract work on emscripten for a game company at the moment  we have a pile of LLVM bugs that have either been reported or that we're trying to minimize enough to report  10:08:20 That's actually what I'm doing at the moment, trying to track down a crazy optimization result in LLVM. 10:23:08 *attila_lendvai* cheers brucem to help him bring down that 5 years to something lower... :) 10:23:29 brucem: turn everything off ;) 10:24:33 pkhuong: in the case I'm looking at now, I just have to run an extra simplifycfg at the end. :) 10:40:39 (I've become a bit suspicous wrt fancy optimisations that only work on SPEC ;) 10:48:14 pkhuong: oh  this is a bug somewhere rather than a mis-optimization. in http://pastebin.com/LtueSAVy  lines 3-25 are all dead (and also invalid) IR. 10:49:00 brucem: right, but no fancy optimisations -> fewer bugs! 11:34:40 fewer bugs -> less contract work! 11:34:50 *Krystof* contemplates adding some bugs 11:35:20 Write some code to make random non-trivial mutations. 11:37:56 *stassats`* reduced the test-case to (defun test (a) (declare (unsigned-byte a)) (float a)) 11:38:53 and float is (if (floatp n) n (%single-float n)), and (declare (unsigned-byte a)) causes the type of whole thing to change, and it somehow goes into a conflict 11:39:47 the n in the first leg is dervied to be float, but then it's declared unsigned-byte, why that causes a problem, no idea 11:42:01 well, that branch is dead, so maybe it's similar to yesterday's case? 11:42:10 derivation happening on code that should be flushed? 11:42:17 maybe 11:42:34 ok. Unicode normalization forms. I'm going to write some Lisp code. Cheer me on, folks 11:42:50 *stassats`* did indeed had a dream in the morning which featured IR1, but i didn't wake up with a sudden solution 11:51:01 now to figure where dead branch elimination happens 11:52:10 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 12:05:04 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 12:06:50 -!- danlentz [~danlentz@2601:c:3680:1c:18e2:aa6a:790:d3bc] has quit [Remote host closed the connection] 12:07:51 danlentz [~danlentz@2601:c:3680:1c:7c33:cc1b:83a0:4e82] has joined #sbcl 12:17:50 did I say I would write code? Still drawing pictures on paper... 12:37:48 Fare [fare@nat/google/x-tfbalawyclldgihv] has joined #sbcl 12:38:08 so, that happens in ir1-optimize-if, but in this case it doesn't do anything 12:39:20 -!- wbooze [~wbooze@xdsl-78-35-145-60.netcologne.de] has quit [Ping timeout: 252 seconds] 12:40:35 maybe it's just a bogus consistency check 12:42:40 and it's the same in CMUCL 12:43:05 that's no guarantee of anything :/ 12:43:26 well, it doesn't seem to break anything, as opposed to the values one 12:47:19 well the values one didn't break anything until you added smarts 12:50:17 -!- hlavaty` [~user@friedrichstrasse.knowledgetools.de] has quit [Ping timeout: 246 seconds] 12:55:14 hlavaty [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 13:00:50 -!- yacks [~yacks@180.151.36.168] has quit [Ping timeout: 260 seconds] 13:05:48 Thra11 [~thrall@87.112.163.103] has joined #sbcl 13:08:13 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 13:10:10 -!- hlavaty [~user@friedrichstrasse.knowledgetools.de] has quit [Ping timeout: 260 seconds] 13:15:04 (let ((lvar (node-lvar node))) (declare (ignore lvar)) ....) is puzzling 13:17:54 stassats`, maybe a copied code pattern? /me doesn't know. 13:18:28 and node-lvar is just a structure accessor, so i don't expect any side-effects 13:20:17 and that ignore was added by Krystof 13:20:37 just shy of 9 years ago 13:25:16 wbooze [~wbooze@xdsl-78-35-175-189.netcologne.de] has joined #sbcl 13:31:03 drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has joined #sbcl 13:31:20 hlavaty [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 13:32:21 drmeiste_ [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 13:33:26 attila_lendvai [~attila_le@92.46.11.102] has joined #sbcl 13:33:26 -!- attila_lendvai [~attila_le@92.46.11.102] has quit [Changing host] 13:33:26 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:35:26 -!- drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has quit [Ping timeout: 252 seconds] 13:35:40 yacks [~yacks@180.151.36.168] has joined #sbcl 13:57:42 that's right, blame me 13:58:04 probably in an effort to make things compile under clisp with minimal effort 13:58:18 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 14:18:31 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 14:28:08 llvm is passé. Clearly we should develop an asm.js backend 14:29:01 [18:34:40] <@Krystof> fewer bugs -> less contract work! 14:29:19 Krystof: there are plenty of bugs to fuel many hours of contract work. :) 14:29:59 Krystof: and I'll assume you were kidding about asm.js, but if you aren't, let me know. I work regularly with those people. 14:30:50 Krystof: I also have large parts of the MPS GC from Ravenbrook (formerly the Harlequin work) running under emscripten (but not asm.js since setjmp isn't supported yet in asm.js) 14:39:46 neat. I'm only half-kidding; we need some cool projects for bored grad students to do 14:39:46 -!- drmeiste_ [~drmeister@farnsworth.chem.temple.edu] has quit [Read error: Connection reset by peer] 14:40:02 where is the next generation of developers / maintainers? pkhuong might graduate soon, and then where will we be? 14:43:08 You're still in far better shape than I am. :) 14:50:31 drmeister [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 14:56:46 how's your bootstrap process? 14:58:58 Mine? Actually fairly smooth after the last 2 years. 15:00:46 Grab current release, grab GC sources, grab actual sources, PATH=:$PATH ./autogen.sh && ./configure --with- && make 3-stage-bootstrap. Wait a while. 15:12:32 are there ever changes that can break that? I don't know opendylan's implementation strategy 15:16:12 some time ago nikodemus expressed interest in adding MPS to sbcl but he didn't like its licence 15:16:12 Krystof: in theory, that should *always* be safe. (the first stage has a strange build pattern to try to keep things working even should the compiler/runtime interface change) 15:16:35 fe[nl]ix: We have a custom license exception from Ravenbrook and they're happy to talk about it with others. 15:17:08 fe[nl]ix: but that wasn't the case years ago when Nikodemus was interested  I invested a lot of effort into talking to them. 15:17:25 (CURSES. My cunning plan for adding decomposition information is defeated by cliini's cunning data structure. Back to the drawing board) 15:17:51 fe[nl]ix: the next release has documentation. Perhaps the best GC documentation that I've seen: http://www.ravenbrook.com/project/mps/master/manual/html/ 15:18:55 Krystof: in practice, we have had few world-shaking runtime/compiler interface changes  so who knows. :) I've done minor changes, and I've seen evidence that they occasionally kept code around to make bootstrapping easier with a note to delete it after a while. (I removed some of that 10-12 years later ) 15:20:33 brucem: the kind of thing I'm thinking about is inserting a field into whatever the dylan equivalent of defstruct-description is 15:21:16 (I broke a couple of cmucl maintainers' brains by suggesting that they do that) 15:21:49 Krystof: ahh, okay. I did something like that recently (to support a language header on our source records as someone's slowly working towards having an s-expression Dylan reader). It is a bit painful, but it seems possible. What should happen is a bit more explicit versioning, but I barely understand how that serialization system works, so I haven't tried yet. 15:22:13 Krystof: I'm guessing you know what it is like to work on a codebase where there isn't anyone left alive that understands portions of it. 15:22:29 sometimes I think that no-one ever understood some portions of sbcl :) 15:22:42 I call it software archaeology, fwiw 15:22:46 I've emailed some people out of the blue on occasion. 15:22:47 -!- wbooze [~wbooze@xdsl-78-35-175-189.netcologne.de] has quit [Remote host closed the connection] 15:22:48 me too! 15:23:03 "Hey, I know you probably forgot, but I saw you were doing this work 15 years ago " 15:24:01 Krystof: i thought about submitting a software archeology talk to one of the Lisp conferences. 15:24:38 there's still jwz code in hemlock 15:25:54 fe[nl]ix: we have 2 or 3 different multimethod dispatch systems in OD and we're not sure exactly how some of it works. (This is an active subject of investigation, I was figuring out call-site caches earlier today.) 15:27:38 hahaha 15:30:15 oh you should see some of the optimized pcl dispatch functions 15:31:51 admittedly we don't really have call-site caches 15:32:36 I thought someone said the other day that there are in SBCL. 15:32:45 huh 15:33:11 I don't *think* that there are, though they're not hard to implement -- maybe someone pointed at nikodemus' load-time-value blog posts? 15:33:28 it's possible to implement them in "userspace" 15:34:28 Krystof: ours are apparently only used when the method is 1) sealed and 2) it has 2 args or more, 3) it would otherwise be a full generic dispatch.  there's a disabled "partial dispatch" system that may or may not work (it was the next gen work) and it improves on that some. The sealed limitation can be dealt with and removed. I'm honestly not sure why there's a limit on # of args. 15:35:29 Krystof: Since for us, everything goes through generic dispatch, including element indexing and setters for vectors  when the compiler can't get a narrow enough type, that makes for painful loops and since call sites are only for sealed, 2 arg methods, it won't help much there. 15:39:32 maybe the thinking was that dispatch for a 1-arg method is trivial enough that it wasn't worthwhile? 15:42:22 foom: I suspect that is close  the cache node does a type check and that might be similar to the typecheck that the normal dispatch would do. but we have fairly strong evidence from profiling that it is costly. 15:42:39 foom: you're the foom that worked on goo with jrb? 15:43:16 brucem: yup! 15:43:31 gko [~user@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 15:44:00 foom: ahh, I did some stuff on Twisted around the time that you did as well (late 2003, early 2004). 15:44:13 foom: I dropped jrb an email today asking for some 12 year old code. :) 15:45:47 hah 15:45:52 wbooze [~wbooze@xdsl-78-35-175-189.netcologne.de] has joined #sbcl 15:45:53 what were you looking for? 15:46:29 foom: He has a presentation on "turbocharging" dispatch via code generation and application of some predicate dispatch work. In there, he claims it is running code ... 15:46:56 foom: this one: http://people.csail.mit.edu/jrb/Projects/dylan-dispatch.htm 15:48:34 foom: It is too bad how much stuff just disappears. 15:49:14 Krystof asked earlier where the next generation of people are  but they don't know much at all about who we are or where we came from or what we did. :( 15:53:34 %PRIMITIVE HALT called; the party is over. 15:53:43 Oh, how I've missed you, %PRIMITIVE HALT 16:03:50 kmb [~kmb@rrcs-50-75-221-94.nyc.biz.rr.com] has joined #sbcl 16:22:45 it's impressive how much breaks if upper-case-p is wrong 16:24:39 strange, slime inspector inspecting some ir1 nodes works only the first time, when i refresh, i get lots of <> 16:24:59 -!- yacks [~yacks@180.151.36.168] has quit [Quit: Leaving] 16:29:44 yacks [~yacks@180.151.36.168] has joined #sbcl 16:32:19 attila_lendvai [~attila_le@92.46.11.102] has joined #sbcl 16:32:19 -!- attila_lendvai [~attila_le@92.46.11.102] has quit [Changing host] 16:32:19 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:33:34 we could do inline caches on GFs that are declared inline (: 16:42:45 what if instead of inlining we just had specialized versions of functions, so you would have ash, ash-bignum-fixnum, ash-fixnum-fixnum and so on? 16:43:33 that would be most useful 16:43:56 although, for ash fixnum-fixnum, an assembly routine in static space would probably be more apropriate. 16:44:08 ash is just an example 16:44:58 anyway, that's not a novel idea and i don't know how to implement it easily 16:45:14 expand into code that l-t-vs to get a specialised routine. 16:45:47 The specialised routine is still compiled (except for a few baked-in cases), but only one is kept around. 16:46:20 SBCL is not really conductive to quick experiments 16:46:57 and the specialised routine is simply generated via our pre-existing transforms, that are now less aggressively enabled. 16:50:39 and arguments to those specialized routines can also be unboxed 16:50:56 that's a lot more work (: 16:53:36 or maybe some entry points for unboxed args 16:55:08 Right. There was some talk wrt that on cmucl. 16:55:31 (some code as well) 17:20:04 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 17:26:54 -!- drmeister [~drmeister@farnsworth.chem.temple.edu] has quit [Remote host closed the connection] 17:38:17 *stassats`* becomes increasingly convinced that the type mismatch in this case is harmless and that the consistency warning is wrong here 17:38:53 stassats`: make sure DCE is run before consistency checking? 17:39:25 otherwise it'll need to reevaluate things whenever it changes something in a CIF test 17:40:16 DCE? 17:41:43 dead code elimination. 17:41:43 though, discarding an IF branch immediately may result in some speed ups 17:42:23 myeha. IF nodes are special, there's a lot of implicit invariants between the different passes. 17:44:15 the code becomes dead during derive-node-type, where the consistency check happens, so eliminating it on each pass may be expensive 17:45:03 attila_lendvai [~attila_le@92.46.11.102] has joined #sbcl 17:45:03 -!- attila_lendvai [~attila_le@92.46.11.102] has quit [Changing host] 17:45:03 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:45:45 ASau [~user@46.115.86.86] has joined #sbcl 17:49:26 it appears that it does ir1 optimization on the inline code first, and then on the whole code, if it did that only for the whole code, then maybe that situation will be avoided 17:50:57 I'd expect compilation passes to go up if we don't ir1-optimise newly-inlined code 17:51:35 -> slower compilation and worse code; potentially bad code if the inlined code contains hairy stuff like make-array. 17:52:33 anyway, i'll abandon this, but learned something anyway 17:53:00 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: mental deadlock] 18:03:40 -!- Thra11 [~thrall@87.112.163.103] has quit [Quit: kthxbai] 18:18:40 Thra11 [~thrall@87.112.163.103] has joined #sbcl 18:48:16 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 18:56:20 -!- yacks [~yacks@180.151.36.168] has quit [Quit: Leaving] 18:57:38 do we want debug source information to be pretty printed? 18:57:44 because it takes quite an amount of time 18:57:52 lp #521153 18:57:52 https://bugs.launchpad.net/bugs/521153 18:58:00 but s/debug 2/debug 3/ 19:01:22 1.017 seconds without pretty, 17.6 seconds with pretty 19:02:47 and 0.391 without *print-circle*, but that's less safe 19:05:17 I wonder why our pretty-printing is /so/ slow 19:05:51 *stassats`* commented on the bug-report with the timings 19:09:35 now, that's weird: The second argument is a SIMPLE-STRING, not a (SIMPLE-ARRAY CHARACTER (*)). 19:11:26 ah, that's because of NIL arrays 19:13:41 by adding the (simple-array character (*)) to the second REPLACE argument in pretty-print's output-line, i get time from 17 seconds, to 10 seconds 19:14:00 i wonder what will happen if i replace simple-string declarations in the pretty-stream structure 19:14:13 need to recompile sbcl to test that, though 19:15:25 -!- Thra11 [~thrall@87.112.163.103] has quit [Ping timeout: 245 seconds] 19:15:31 or maybe REPLACE should just be smarter 19:16:22 Thra11 [~thrall@46.208.141.244] has joined #sbcl 19:17:24 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 260 seconds] 19:25:55 yep, 10 seconds with that type change in pprint defstruct 19:27:34 wait, declaring something 'simple-string' doesn't get you fast code? 19:27:45 that seems pretty bogus! 19:28:37 right, because(sb-kernel::union-type-types (sb-kernel::specifier-type 'simple-string)) => (# # #) 19:29:38 oh, right, simple-base-string. 19:30:08 *stassats`* adds a (deftype simple-sane-string (&optional n) `(or (simple-base-string ,n) (simple-array character (,n)))) 19:30:22 even discarding NIL, you still have at least a base-char and a char to worry about. 19:31:10 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 19:33:08 for pprint, it's know that it's simple-character-string 19:35:56 -!- Thra11 [~thrall@46.208.141.244] has quit [Ping timeout: 246 seconds] 19:36:51 is sbcl the only impl which has (simple-array nil (*)) as a subtype of simple-string? 19:37:30 ABCL as well 19:38:23 and clisp 19:50:54 Thra11 [~thrall@46.208.141.244] has joined #sbcl 19:51:12 somehow, i can't construct a test-case which does not use the compiler and which demonstrates the speed-up 19:57:02 that's due to a lot of (+ (+ (+ (+ ....)))), because sbcl transforms (+ a b c d e f) to it 19:59:31 will commit the (simple-array character (*)) change tomorrow, now printing super-nested lists twice as fast! 19:59:36 very useful 20:16:41 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 255 seconds] 20:36:25 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 20:53:06 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 21:11:56 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Ping timeout: 240 seconds] 21:25:39 -!- wbooze [~wbooze@xdsl-78-35-175-189.netcologne.de] has quit [Quit: none] 21:27:35 wbooze [~wbooze@xdsl-78-35-175-189.netcologne.de] has joined #sbcl 21:50:59 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 22:37:59 foreignFunction [~niksaak@94.27.88.33] has joined #sbcl 23:25:54 -!- prxq [~mommer@mnhm-590c0ef8.pool.mediaWays.net] has quit [Quit: Leaving] 23:26:16 -!- kmb [~kmb@rrcs-50-75-221-94.nyc.biz.rr.com] has quit [Quit: kmb]