00:27:10 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 00:33:33 tsuru``` [~charlie@adsl-98-87-25-103.bna.bellsouth.net] has joined #sbcl 00:35:29 -!- tsuru`` [~charlie@adsl-98-87-48-186.bna.bellsouth.net] has quit [Ping timeout: 258 seconds] 00:43:46 tsuru```` [~charlie@adsl-98-87-50-6.bna.bellsouth.net] has joined #sbcl 00:45:27 -!- tsuru``` [~charlie@adsl-98-87-25-103.bna.bellsouth.net] has quit [Ping timeout: 258 seconds] 00:55:56 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 00:56:19 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 01:02:30 -!- slyrus [~chatzilla@adsl-99-183-240-66.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 264 seconds] 01:28:45 milosn [~milosn@user-5af50443.broadband.tesco.net] has joined #sbcl 01:31:29 -!- milosn_ [~milosn@user-5af50378.broadband.tesco.net] has quit [Ping timeout: 252 seconds] 01:55:08 slyrus [~chatzilla@adsl-99-183-240-66.dsl.pltn13.sbcglobal.net] has joined #sbcl 02:04:41 milosn_ [~milosn@user-5af50474.broadband.tesco.net] has joined #sbcl 02:04:46 -!- milosn [~milosn@user-5af50443.broadband.tesco.net] has quit [Read error: Operation timed out] 02:23:30 -!- slyrus [~chatzilla@adsl-99-183-240-66.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 264 seconds] 02:33:55 yacks [~py@180.151.36.168] has joined #sbcl 02:35:34 -!- yacks [~py@180.151.36.168] has quit [Read error: Connection reset by peer] 02:36:02 yacks [~py@180.151.36.168] has joined #sbcl 03:28:52 slyrus [~chatzilla@adsl-99-183-240-66.dsl.pltn13.sbcglobal.net] has joined #sbcl 03:32:04 echo-area [~user@182.92.247.2] has joined #sbcl 03:44:58 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 03:58:18 -!- Fare [fare@nat/google/x-kpwaqywfjxjhhhzt] has quit [Ping timeout: 264 seconds] 03:58:47 Fare [fare@nat/google/x-guuvacziyzcbwfng] has joined #sbcl 04:48:31 sdemarre [~serge@198.146-66-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 05:34:53 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:20:46 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 06:21:14 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 06:44:25 -!- Bike [~Glossina@67-5-212-240.ptld.qwest.net] has quit [Quit: leeps] 06:46:26 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 06:48:04 -!- wbooze [~wbooze@xdsl-78-35-176-116.netcologne.de] has quit [Ping timeout: 260 seconds] 06:56:30 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 07:17:56 -!- sdemarre [~serge@198.146-66-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 256 seconds] 07:22:33 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Ping timeout: 258 seconds] 07:47:08 attila_lendvai [~attila_le@95.56.74.96] has joined #sbcl 07:47:08 -!- attila_lendvai [~attila_le@95.56.74.96] has quit [Changing host] 07:47:09 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:57:11 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 08:33:48 prxq [~mommer@mnhm-590c0d5d.pool.mediaWays.net] has joined #sbcl 08:41:47 -!- scymtym_ [~user@ip-5-147-116-166.unitymediagroup.de] has quit [Read error: Operation timed out] 08:44:59 stassats [~stassats@wikipedia/stassats] has joined #sbcl 09:15:22 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 09:23:43 sdemarre [~serge@198.146-66-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 09:32:18 -!- Strigoides [~owen@60-234-213-126.bitstream.orcon.net.nz] has quit [Quit: leaving] 09:35:13 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 240 seconds] 09:39:24 yacks [~py@180.151.36.168] has joined #sbcl 09:41:38 -!- ASau` is now known as ASau 09:59:16 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 10:01:09 -!- Fare [fare@nat/google/x-guuvacziyzcbwfng] has quit [Ping timeout: 256 seconds] 10:03:05 wbooze [~wbooze@xdsl-78-35-156-57.netcologne.de] has joined #sbcl 10:39:27 attila_lendvai [~attila_le@95.56.74.96] has joined #sbcl 10:39:31 -!- attila_lendvai [~attila_le@95.56.74.96] has quit [Changing host] 10:39:31 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:50:52 -!- ASau [~user@p5797E18D.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds] 10:55:28 ASau [~user@p5797E18D.dip0.t-ipconnect.de] has joined #sbcl 11:11:13 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 11:16:27 Hydan [~hydan@176.74.140.3] has joined #sbcl 11:16:37 rahul [~chatzilla@14.139.60.220] has joined #sbcl 11:17:01 -!- rahul is now known as Guest41101 11:20:36 -!- tsuru```` [~charlie@adsl-98-87-50-6.bna.bellsouth.net] has quit [Ping timeout: 258 seconds] 11:23:19 hello there 11:23:39 I am very interested in Replacing the garbage collector with MPS project 11:24:06 can i talk to the mentor of the project? 11:24:06 ok 11:24:29 Guest41101, you can just ask your questions and whatnot in here, and someone might eventually respond 11:25:39 I am Rahul a student from india 11:25:54 and i think entry for this project are still open . 11:26:00 can i apply? 11:27:46 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:27:59 Guest41101, http://www.google-melange.com/gsoc/org/google/gsoc2013/sbcl 11:30:00 quasrescene: sir i have seen this page but dint find any useful info there 11:30:34 Guest41101, There is a big button in the middle of the page called "Register" 11:30:48 At the bottom is the application template. 11:30:53 Have you done both of those? 11:31:54 Sir i have seen this but i need to talk with the mentor of the project 11:32:13 regarding my skills and project details. 11:32:35 Guest41101, Okay, what are your questions? 11:34:22 I wants to introduce myself to the project mentor and i am interested in project . So i wants to ask the full details of the project 11:53:29 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 11:54:40 What should i do next 11:54:52 Quadrescene: sir? 12:01:42 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 12:05:14 -!- sdemarre [~serge@198.146-66-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 256 seconds] 12:10:15 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 12:21:50 sdemarre [~serge@198.146-66-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 12:22:18 -!- Guest41101 [~chatzilla@14.139.60.220] has quit [Ping timeout: 264 seconds] 12:23:38 -!- yacks [~py@180.151.36.168] has quit [Read error: Connection reset by peer] 12:41:28 yacks [~py@180.151.36.168] has joined #sbcl 12:41:51 -!- ASau [~user@p5797E18D.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds] 13:10:18 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds] 13:14:33 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 13:16:41 -!- Hydan [~hydan@176.74.140.3] has quit [Ping timeout: 268 seconds] 13:44:58 -!- sdemarre [~serge@198.146-66-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 256 seconds] 13:58:31 nyef [~nyef@pool-70-109-143-163.cncdnh.east.myfairpoint.net] has joined #sbcl 14:06:55 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 14:14:54 pkhuong, I've been testing different simple functions in search of peephole candidates, but I haven't found a single one. The closest things I can find would almost require flow analysis, which suggests that the register allocator needs improvement (which we already know). Maybe you know of examples where peephole can be done? 14:22:48 sdemarre [~serge@198.146-66-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 14:27:32 i'll be back later 14:27:54 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 14:36:46 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 14:55:26 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 15:17:53 minion: memo for quadrescence: obvious opportunities should occur when representation selection isn't sure between fixnum and untagged integers (those'll manifest as spurious shifts left and right) -- especially if bitwise operations are involved --, when there are spills to the stack (everything will read and write via the stack slot), and when operations don't exploit x86's support for memory operands, without going through a register. 15:17:53 Remembered. I'll tell quadrescence when he/she/it next speaks. 15:20:20 tsuru` [~charlie@adsl-74-179-30-160.bna.bellsouth.net] has joined #sbcl 15:20:45 minion: memo for quadrescence: we also fail to reuse condition code values, so we do stuff like sub/cmp, or cmp/cmov/cmp/cmov. Many rewrites do need minimal dataflow information, but TNs already have some of that information (read/writes), and the ir2opt pass for cmov conversion already performs some control flow analysis. 15:20:45 Remembered. I'll tell quadrescence when he/she/it next speaks. 15:29:53 Oh let's assume logs will be read. OPTIMIZATIONS #1, #2, #4, #32 look peepholable (unrelatedly, #22 and #24 might be already done...) 15:30:31 -!- sdemarre [~serge@198.146-66-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 258 seconds] 15:33:19 leuler [~user@p548FB119.dip0.t-ipconnect.de] has joined #sbcl 15:38:57 stassats [~stassats@wikipedia/stassats] has joined #sbcl 16:00:23 Bike [~Glossina@67-5-212-240.ptld.qwest.net] has joined #sbcl 16:13:31 tsuru`` [~charlie@adsl-98-87-25-31.bna.bellsouth.net] has joined #sbcl 16:15:22 -!- tsuru` [~charlie@adsl-74-179-30-160.bna.bellsouth.net] has quit [Ping timeout: 258 seconds] 16:18:57 ASau [~user@p5797E18D.dip0.t-ipconnect.de] has joined #sbcl 16:40:52 Snamich [~Snamich@71-9-62-86.dhcp.snlo.ca.charter.com] has joined #sbcl 16:59:40 gabnet [~gabnet@ACaen-652-1-281-41.w92-154.abo.wanadoo.fr] has joined #sbcl 17:00:20 -!- gabnet [~gabnet@ACaen-652-1-281-41.w92-154.abo.wanadoo.fr] has quit [Client Quit] 17:14:45 -!- ASau [~user@p5797E18D.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds] 17:15:56 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Ping timeout: 258 seconds] 17:28:56 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 17:30:03 ASau [~user@p5797E18D.dip0.t-ipconnect.de] has joined #sbcl 17:31:39 pranavrc [~pranavrc@122.174.30.122] has joined #sbcl 17:31:39 -!- pranavrc [~pranavrc@122.174.30.122] has quit [Changing host] 17:31:39 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 17:33:47 -!- foreignFunction [~niksaak@ip-4761.sunline.net.ua] has quit [Read error: Operation timed out] 17:34:10 astertronistic [~astertron@ip70-181-235-122.sd.sd.cox.net] has joined #sbcl 17:37:04 ... About how much leeway do I have for altering the guts of MAP-ALLOCATED-OBJECTS? And are there any hidden "gotchas" that I should know about? 17:37:23 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Quit: Ping timeout: ] 17:37:41 i think it's the standard "as long as it works" 17:37:51 What constitutes "works"? 17:38:10 since it's internal, anything which uses it still works 17:38:41 Hrm. And is there any tricky data patterns or whatever that might trip it up more easily? 17:39:04 and people who use it should learn not to use internall stuff and expect it to remain unchanged 17:40:35 Oh, and does anyone happen to know what "bug 344" is/was? 17:41:31 nyef: http://stuff.mit.edu/afs/sipb/project/clisp/src/sbcl-1.0.23-x86-linux/BUGS 17:42:06 Ah, thank you. 17:42:22 lp 309083 17:42:22 https://bugs.launchpad.net/bugs/309083 17:42:25 and there it is 17:42:46 Wonderful. Thank you. 17:43:26 maybe room should be integrated into the GC? 17:43:45 (somehow...) 17:44:23 map-allocated-objects is also used for some xref stuff, but i don't think that's a good idea to do so 17:45:09 According to slime-who-calls, nothing actually uses map-allocated-objects, but I think that that's the inlining screwing things up. 17:45:30 do you have xref for sbcl enabled? 17:46:05 sb-introspect:find-function-callers uses m-a-o 17:46:13 Might not, actually. 17:46:26 Okay, I'm clearly going to have to think about this a bit. 17:46:38 "This interface is trmendously experimental." 17:46:58 The process flow through m-a-o is horribly convoluted, and largely unnecessary. 17:47:18 introspect.lisp has some dangling parenthesis, outrageous! 17:50:07 I do, at least, have a replacement for the part of the "type database" initialization that deals with the array types. 17:50:07 there's also sb-introspect:map-root 17:53:31 Okay, I think this is a good start for now. 17:54:46 Going to have to think about quite how things need to work. 17:55:35 room itself doesn't actually need a full-featured map-allocated-objects, it may work by calling C with a vector for tags and the C code will fill that vector 17:57:54 and find-function-callers and find-function-callees, they mirror xref by going through the memory, i'm not really sure what's the point 18:00:26 and for memory introspection where you can actually do something, i would prefer a tool which worked on a saved image, not on the live memory 18:01:46 Yeah, I've long been a fan of the idea of having an out-of-process debugger, as well. 18:02:09 or maybe some special mode, where allocation happens in a separate space and it's not touched by the introspection code 18:02:46 Have the introspector skip the currently open allocation region, perhaps? 18:03:57 what happens if it triggers a GC? 18:04:07 M-A-O includes a WITHOUT-GCING. 18:04:28 well, what happens when the allocation region is out of space? 18:04:46 Close the current alloc region, open a new one. 18:04:55 If you run out of empty alloc regions, lose(). 18:05:02 sdemarre [~serge@198.146-66-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 18:05:31 lose doesn't sound like a nice thing to encounter 18:05:43 It's a heap exhaustion. You're going to lose() there anyway. 18:06:04 not with a working gc 18:06:12 But the GC is already disabled. 18:06:24 i'm not talking about the current code 18:06:29 Ah. 18:06:40 i'm talking about something that i would want to use 18:09:11 I'm not sure that I'm up for changing how ROOM or MAP-ALLOCATED-OBJECTS works on a fundamental level at this point. 18:17:38 One constraint with the current implementation is that whatever M-A-O is looking at, so long as it only deals with allocated pages, it's all effectively boxed heap data that the GC could be expected to / would have been expected to scavenge. 18:19:16 The whole "careful" thing and using the "safe" version of make-lisp-obj is a broken idea: ALL of the pointers constructed should be correct, by design. 18:19:36 If ROOM constructs an invalid pointer, something is wrong. 18:20:36 The use of SAPs is dangerous from an "avoiding consing" perspective... 18:22:07 i think that's why it's all inlined 18:22:29 Yeah. 19:03:35 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 19:10:25 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Read error: No route to host] 19:37:57 -!- wbooze [~wbooze@xdsl-78-35-156-57.netcologne.de] has quit [Ping timeout: 245 seconds] 19:40:24 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 19:44:53 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 19:51:42 wbooze [~wbooze@xdsl-78-35-187-173.netcologne.de] has joined #sbcl 20:00:28 nyef_ [~nyef@pool-64-222-145-250.man.east.myfairpoint.net] has joined #sbcl 20:01:33 -!- nyef [~nyef@pool-70-109-143-163.cncdnh.east.myfairpoint.net] has quit [Ping timeout: 240 seconds] 20:06:57 ... why don't we signal warnings on runtime type errors when the asserted type is NIL? 20:08:25 Because it's an occasionally-useful thing to do? Because nobody thought of it yet? 20:09:34 no, there's an explicit check for that case. 20:09:54 Which case? It being occasionally-useful? 20:10:24 -!- Tribal [tribal@fluttershy.is.best.pony.rcfreak0.com] has quit [Quit: Leaving] 20:10:29 Well there's no comment, just a check that the asserted type isn't NIL, and if so, no compile-time message. 20:11:10 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 246 seconds] 20:14:50 -!- sdemarre [~serge@198.146-66-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 256 seconds] 20:17:03 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 20:21:58 Tribal [~Tribal@rcfreak0.com] has joined #sbcl 20:26:42 -!- ASau [~user@p5797E18D.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds] 20:30:15 nyef_: what use case do you have in mind? 20:31:09 I don't know that I do, beyond functions that return (VALUES NIL &OPTIONAL). 20:31:31 I'm referring to doing (the nil ...) 20:31:59 or the equivalent of, via type propagation. 20:32:49 ASau [~user@p5797E18D.dip0.t-ipconnect.de] has joined #sbcl 20:33:39 Dead code elimination? 20:34:56 what do you mean? 20:36:18 There's some half-formed thought here about dead code elimination needing to kick in once a variable can be proven to not have any possible values whatsoever. 20:37:08 It's a kindof nebulous feeling for me, as I'm really not familiar with the behavior of the type propagator right now. 20:37:33 And since I have a pile of ROOM-related state in my head at the moment, I don't really want to try to nail it down more precisely. 20:37:34 sorry i'm sort of interjecting without a lot of scrollback, but you can have non-dead-code with a bottom type, no? 20:37:35 Quadrescence, memo from pkhuong: obvious opportunities should occur when representation selection isn't sure between fixnum and untagged integers (those'll manifest as spurious shifts left and right) -- especially if bitwise operations are involved --, when there are spills to the stack (everything will read and write via the stack slot), and when operations don't exploit x86's support for memory operands, without going through a register. 20:37:35 Quadrescence, memo from pkhuong: we also fail to reuse condition code values, so we do stuff like sub/cmp, or cmp/cmov/cmp/cmov. Many rewrites do need minimal dataflow information, but TNs already have some of that information (read/writes), and the ir2opt pass for cmov conversion already performs some control flow analysis. 20:37:37 compile-time type warnings are emitted during IR2 conversion. 20:37:57 so I think all dead code is supposed to have been elided by then. 20:38:16 Okay, in that case I'm lost. 20:38:28 Sorry. 20:41:24 that part of the code isn't fully baked (e.g. we complain about a type mismatch with the constant NIL when the value comes from a conditional), so who knows? 20:41:46 Also, another question I had: sometimes (on x64) code like this will be emitted: XOR EAX EAX; MOV [foo] EAX; or MOV EAX ; MOV [foo] EAX. I'm wondering why the constant isn't just moved directly to memory? The only reason I can think of why this might not be done is that for large integers this can choke I believe. 20:43:31 Quadrescence: I'm remembering something about sign extension on certain instructions. 20:43:45 Something like XOR being full-width and MOV not being or something. 20:44:19 Hrm. Or maybe not. 20:44:38 Well it's not the XOR really, it's the const -> reg -> mem, as opposed to const -> mem 20:46:46 we don't have any VOP to load immediate values into memory 20:47:21 Quadrescence: I believe this is done to save on VOPs. I remember, say 5 to 10 years ago, there being VOPs with names like ...-c-...-c-..., where the first -c- means constant array index and the second means constant arg (or the other way round). 20:47:59 and if we did, we'd have to special case large constants (with temp-reg-tn, that's certainly possible; tastefulness is another issue) 20:48:03 (here were my experiments, by the way: https://bitbucket.org/tarballs_are_good/lisp-random/raw/83483e050b62fd260444fa47ec7168425fcaa0c6/garbage-dump/sbcl-peepholes.lisp ) 20:48:55 I was a little surprised too that (map-into arr (constantly 0) arr) didn't produce good code, but I probably didn't coax SBCL well enough 20:49:21 (that is in the ZERO32-16 function) 21:16:29 nyef [~nyef@pool-71-161-84-192.cncdnh.east.myfairpoint.net] has joined #sbcl 21:18:03 -!- nyef_ [~nyef@pool-64-222-145-250.man.east.myfairpoint.net] has quit [Ping timeout: 245 seconds] 21:29:01 384 KiB core size reduction (on x86-64)! 21:34:42 awesome. how? 21:35:01 That was the reaction I wanted to provoke ;-) 21:35:47 The MOVE macro on x86-64 is large. Converting the SC-CASE in it into a function adds up due to several hundred VOPs using MOVE. 21:36:30 That is, moving that part into a helper function. 21:36:45 nice. 21:42:57 It seems the compiler can, in the original version, never determine that only one of the SC-CASE clauses is possible. Presumably VOPs couldn't declare the types of their arguments down to the SCs, also there sometimes is :LOAD-IF. 21:45:30 -!- Snamich [~Snamich@71-9-62-86.dhcp.snlo.ca.charter.com] has quit [Ping timeout: 256 seconds] 21:47:14 sdsl [~sdsl@bl16-197-131.dsl.telepac.pt] has joined #sbcl 21:56:41 tsuru``` [~charlie@adsl-74-179-250-226.bna.bellsouth.net] has joined #sbcl 21:58:26 -!- tsuru`` [~charlie@adsl-98-87-25-31.bna.bellsouth.net] has quit [Ping timeout: 258 seconds] 22:28:59 Strigoides [~owen@60-234-213-126.bitstream.orcon.net.nz] has joined #sbcl 23:09:25 -!- leuler [~user@p548FB119.dip0.t-ipconnect.de] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 23:47:36 -!- ASau [~user@p5797E18D.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 23:48:27 -!- foreignFunction [~niksaak@ip-4761.sunline.net.ua] has quit [Quit: Leaving.] 23:53:36 -!- sdsl [~sdsl@bl16-197-131.dsl.telepac.pt] has quit [Quit: sdsl] 23:56:08 -!- Strigoides [~owen@60-234-213-126.bitstream.orcon.net.nz] has quit [Ping timeout: 260 seconds]