00:06:37 Blkt [~user@82.84.159.26] has joined #sbcl 00:09:44 good (late) evening everyone 00:12:12 -!- prxq [~mommer@mnhm-590c1c27.pool.mediaWays.net] has quit [Quit: Leaving] 00:57:06 -!- Skrylar [~Skrylar@cpe-70-113-115-100.austin.res.rr.com] has quit [Ping timeout: 245 seconds] 01:21:19 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 01:29:48 Skrylar [~Skrylar@cpe-70-113-115-100.austin.res.rr.com] has joined #sbcl 01:46:32 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 01:48:18 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 01:53:29 -!- wbooze [~wbooze@xdsl-78-35-140-71.netcologne.de] has quit [Ping timeout: 246 seconds] 01:59:40 yacks [~yacks@180.151.36.168] has joined #sbcl 02:20:40 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 02:48:03 -!- Skrylar [~Skrylar@cpe-70-113-115-100.austin.res.rr.com] has quit [Ping timeout: 252 seconds] 02:57:39 Skrylar [~Skrylar@cpe-70-113-115-100.austin.res.rr.com] has joined #sbcl 03:01:15 Krystof: asm.js doesn't do setjmp / longjmp yet, so a condition system would impose a bit of pain  but they want to support it, have an open bug to do so, just not a lot of available time until after the Game Developer Conference this month. 03:24:54 -!- Skrylar [~Skrylar@cpe-70-113-115-100.austin.res.rr.com] has quit [Ping timeout: 240 seconds] 03:27:10 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 04:48:00 -!- LiamH [~none@pool-74-96-4-63.washdc.east.verizon.net] has quit [Quit: Leaving.] 05:40:36 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 248 seconds] 05:46:51 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 06:09:47 Skrylar [HydraIRC@cpe-70-113-115-100.austin.res.rr.com] has joined #sbcl 07:25:17 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 07:51:40 argh, deftransform can't replace deftransform because it can't compare function types which include keywords 08:01:36 *stassats`* writes a arg-key comparer just to be able to debug a transform 08:10:25 stassats`: re extension, one thing that gives a ncie speed up is accumulating chunks of vectors and concatenating at the very end, rather than copying to a contiguous vector each time you grow. 08:10:54 -!- yacks [~yacks@180.151.36.168] has quit [Quit: Leaving] 08:11:29 thought about that too, but checking if an array is alright to be encoded seems to be the fastest way 08:11:42 and falling back to the old way if the array contain errors 08:12:27 and for utf8, calculating the length of the result should be faster too, but i don't have a utf-8 length calculator laying around to check that 08:13:47 another optimization is (octets-to-string xx :external-format :ascii :element-type 'base-char) for best space and performance gains 08:16:10 and i'm not sure what to do with (type= (specifier-type '(FUNCTION (LIST &KEY (:ELEMENT-TYPE *)) *)) (specifier-type '(FUNCTION (LIST &KEY (:ELEMENT-TYPE *)) *))), i made it work, but not sure whether it's conceptually wrong to make them equal 08:21:01 Equality on *-ful types is suspect. 08:21:49 I think it's ok. 08:22:33 what's *-ful? 08:23:50 ah, i though it was a set of symbols ending with -ful 08:25:08 t and * are equal, but other types don't match with * 08:25:50 and that's already the case for (FUNCTION (t) *) and (FUNCTION (*) *), so nothing changed 08:30:06 <|3b|> doesn't babel have a utf8 length calculator? 08:33:56 i'd be rather more interested in the one which works with more than one byte at a time, but i guess even such will be faster than array extension 08:38:16 character -> utf-8? 08:39:15 both 08:39:28 but utf-8->character first 08:40:25 character->utf-8 is hard, to improve portably... of course a fast path that assumes everything is in ASCII ought to work well for us. 08:40:49 utf-8->character, we can do some SIMD-within-a-GPR. 09:43:22 stassats`: http://paste.lisp.org/display/136069 09:43:41 cool 09:43:51 i guess i had too much sbcl for the weekend, though 09:44:10 this would have been much simpler in asm ;) Still, easier than in C. 09:51:11 (logand length -8), and interesting trick 09:52:06 though, couldn't we keep the remainder of (truncate length 8), and do (- length rem) instead? 09:52:41 I'm more used to masking. 09:52:49 (and shifting) 09:52:58 Plus we save one register that way. 09:58:29 I'd shift the word left and shave ~1 cycle on the critical path, but SBCL can't infer types right if I do that. 10:02:16 what about encoding errors? it needs to return NIL in that case 10:04:41 it only gets you the length if there's no error. 10:06:09 (utf8->character-count (coerce #(55 128) '(vector (unsigned-byte 8)))) => 1 10:06:34 right. it gives you the length assuming it's valid utf8 10:07:30 If you need to check for errors, I'd basically fast path the ASCII case, and punt to a full error checking loop as soon as there's a high bit. When that checking loop has fully consumed n-w-byte ascii characters, we can go back to the ASCII loop. 10:09:08 but, really, that's better suited for the conversion step. 10:10:02 the problem is that conversion has a restart which can replace a character with a string of arbitrary length 10:10:33 so i have two branches, (if known-valid fast-path slow-path-with-extensible-vectors-and-restarts) 10:10:49 Punt to a slow path that handles potential extension only when you hit a replacement. 10:11:41 yacks [~yacks@180.151.36.168] has joined #sbcl 10:11:41 if you use a list of simple vectors instead of extendable vector, there's very little difference between the two paths, anyway. 10:12:09 the fast path could be faster if it didn't have to do any checks, though 10:12:21 you have to perform the check at some point. 10:13:24 Sure, it's faster if you don't have to detect invalid utf-8 sequences, but you have to do it at some point. The easy case for both decoding utf-8 and invalid sequences is 7-bit ASCII. Sounds like a good match. 10:13:40 my first candidate is at length calculation: you don't need to finish it if you catch a bad sequence first, and you don't allocate a simple-vector for nothing 10:14:20 what doyou mean, for nothing? 10:14:30 You can still work with simple vectors if you have replacements. 10:14:42 assuming that the slow path is unchanged 10:15:38 what kind of tests do you think we need for valid utf-8? 10:16:20 i haven't yet familiarized myself with utf-8 10:16:36 just checking that the multibyte encoding is correct might be doable, if a bit hairy, with bit bashing, but it's far from enough. 10:17:07 but i'll try list of simple-vectors thing 10:17:32 We also have to check that the value is in the unicode range... and that range is not a power of two, and not even contiguous. 10:17:32 i assume that invalid sequences is a degenerate case and don't need to be exceptionally fast 10:17:43 especially since we're using restarts and signals to handle it 10:17:57 perhaps an optional function to handle it would be better 10:18:12 probably. 10:19:25 so, basically, to check utf-8, you need to decode it... 10:20:03 there's still the very simple cast of when the string length and the byte vector's length are equal. In that case, you only need to check that everything is 7-bit ascii. 10:20:08 *simple case 10:21:00 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 10:22:25 sdemarre [~serge@109.134.133.85] has joined #sbcl 10:24:08 i guess the best solution is to optimistically calculate length, and have just one path, but which is able to grow the vector efficiently in case of errors 10:25:13 yup. and a list of simple vectors is perfectly suited (obviously, you want to cache the head of the list in a lexical variable). 10:25:47 you probably want a the-world-is-7bit-ascii fast path though. 10:26:20 yeah, that can be yanked from ascii encoding rotuines 10:27:14 dioxirane [~ln@unaffiliated/dioxirane] has joined #sbcl 10:30:31 I can add a second value telling you if the byte sequence is all 7-bit ascii. That's easy. 10:31:13 Then, your fast path is just a bash copy. 10:31:38 any ops for #lisp here? could use a reminder to stay at least coarsly on topic, I guess... 10:31:42 thanks a lot 10:34:42 wbooze [~wbooze@xdsl-87-79-194-97.netcologne.de] has joined #sbcl 10:34:57 seems to have calmed down a lot. 10:36:16 stassats`: see annotation. 10:41:46 pkhuong: sorry, any improvement with bug #1137924 present in 1.1.5 stable? .. now I'm trying to run tests on dev version .. 10:42:05 minion: lp 1137924 10:42:06 you speak nonsense 10:42:36 lp 1137924 10:42:38 lp 1137924 10:42:38 https://bugs.launchpad.net/bugs/1137924 10:43:17 dioxirane: if there's ever an improvement, it'll be on openbsd's end, AFAICT. 10:43:50 or if stop using its libm 10:44:23 *Skrylar* ponders about GC design for a moment 10:44:51 I'm tempted to classify it as an expected failure, so that we'll think about it if someone reports range reduction bugs on open. 10:45:08 stassats`: do you suggest any alternative to libm? 10:46:05 dioxirane: bundling our own. 10:49:22 pkhuong: thx but seems to be not so practical at all.. 10:49:47 at least, I've not many time to modify a library.. nor interest 10:49:48 indeed. So if there's ever an improvement in our range reduction on openbsd, it'll happen in open's libm. 10:50:31 You can try to file a bug for open. 11:01:02 [1]Skrylar [HydraIRC@cpe-70-113-115-100.austin.res.rr.com] has joined #sbcl 11:13:37 pkhuong: what do you think is wrong in the libm sources? 11:15:06 Thra11 [~thrall@87.114.249.45] has joined #sbcl 11:16:09 pkhuong: where is the bug? 11:20:16 its range reduction is suboptimal and seems to work witth a coarser approximation than the one used by the gnu libm. 11:40:15 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 11:48:04 pkhuong: ok, I've to understand better the involved alghoritm. Thx for the help. 11:55:18 -!- sdemarre [~serge@109.134.133.85] has quit [Ping timeout: 264 seconds] 11:57:01 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 11:58:46 -!- dioxirane [~ln@unaffiliated/dioxirane] has quit [Quit: leaving] 12:10:03 dioxirane [~ln@unaffiliated/dioxirane] has joined #sbcl 12:10:20 LiamH [~none@pool-74-96-4-63.washdc.east.verizon.net] has joined #sbcl 12:11:13 pkhuong: there is any alternatives to libm library (ad es. cephes) if you know? 12:11:57 cephes would probably be even less accurate. 12:14:52 -!- Thra11 [~thrall@87.114.249.45] has quit [Quit: kthxbai] 12:19:55 leuler [~user@p548FD5BA.dip.t-dialin.net] has joined #sbcl 12:23:14 would be interesting test the lib and prints a table of relative errors for different operations maybe 12:25:13 pkhuong: so a perl result is less accurate? 12:25:23 I do not think so.. 12:33:27 dioxirane: think away. Cephes is meant to be reasonably accurate while remaining simple and efficient. Even for sqrt, its peak relative error (out of 30k points, not even exhaustive) is 1.7e-16, while a correctly rounded double, as mandated by IEEE 754, would have < 1.1e-16. 12:34:03 Cephes's sin also only has a range of [-1.07e9,+1.07e9] for IEEE doubles. 12:34:19 Cephes isn't a general purpose alternative to libm. 12:38:15 pkhuong: I'm trying to test the Math::Trig now only for curiosity 12:39:09 You could also read. 12:50:35 mmm .. the same results of bug 43490 in bugzilla .. 12:52:48 GCC bugzilla - Bug 43490 12:55:04 but I've tested with "use Math::Trig;" in a perl script .. 12:56:09 even if sin and cos are defined in the core perl 12:56:25 anyway this is a lot strange 12:57:33 I don't think Math::Trig is the same as Math::Cephes. I also don't see how this is relevant. 12:58:48 pkhuong: even with the functions defined in the perl's core I get enourmous relative errors, like in the bug previously reported 12:59:12 OK. It probably uses the same libm call as SBCL. 13:00:26 Thra11 [~thrall@87.114.249.45] has joined #sbcl 13:01:42 now I would test Math::Libm .. 13:05:35 pkhuong: I not have actually Libm extension for the GNU C math library.. so not uses the same libm call as SBCL. 13:06:01 I thought you were on openbsd. 13:10:14 pkhuong: using "Math::Libm ':all';" In a perl script I get an error because I've not jet installed the perl extension/module via cpan , but on my syustem I hace libm, sure.. 13:13:28 maybe later i'll tests Math::Libm with perlbrew in a virtualized environment .. 13:18:48 pkhuong: Math::Libm seems be not a default perl module.. 13:20:30 -!- Thra11 [~thrall@87.114.249.45] has quit [Quit: kthxbai] 13:28:49 hlavaty`` [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 13:30:40 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: game over] 13:30:48 -!- hlavaty` [~user@friedrichstrasse.knowledgetools.de] has quit [Ping timeout: 264 seconds] 13:31:04 -!- dioxirane [~ln@unaffiliated/dioxirane] has quit [Quit: bye] 13:37:07 -!- wbooze [~wbooze@xdsl-87-79-194-97.netcologne.de] has quit [Remote host closed the connection] 13:39:57 dioxirane [~ln@unaffiliated/dioxirane] has joined #sbcl 13:40:44 wbooze [~wbooze@xdsl-87-79-194-97.netcologne.de] has joined #sbcl 14:09:29 -!- wbooze [~wbooze@xdsl-87-79-194-97.netcologne.de] has quit [Ping timeout: 255 seconds] 14:10:13 wbooze [~wbooze@xdsl-78-35-172-103.netcologne.de] has joined #sbcl 14:37:52 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 14:39:24 sdemarre [~serge@109.134.133.85] has joined #sbcl 14:43:20 -!- wbooze [~wbooze@xdsl-78-35-172-103.netcologne.de] has quit [Read error: Connection reset by peer] 15:13:41 wbooze [~wbooze@xdsl-78-35-177-230.netcologne.de] has joined #sbcl 15:29:43 -!- dioxirane [~ln@unaffiliated/dioxirane] has quit [Quit: bye] 15:46:17 Adding the S(S)SE3 and SSE4.1/2 instructions makes the core larger by 200 KB (that is 0.5 percent). Comparing compressed core sizes (using LZO) we have an increase of 0.3 percent. 15:47:13 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 245 seconds] 15:47:56 (char-decomposition #\½) ; => "12" 15:48:04 woot! I can still program, sort of 15:48:13 what kind of / is that? 15:48:37 u+2044 FRACTION SLASH 15:48:46 why not just /? 15:48:56 because that's not what Unicode says 15:48:57 or is that a standard prescription? 15:49:29 what about char-decomposition for ascii? 15:49:54 I'm not sure how useful this kind of decomposition is externally, but it's necessary for normalizing in Unicode terms. 15:50:34 decomposition isn't about restricting to a set of codepoints, it's decomposition (converting precombined characters into their component parts) 15:50:53 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 15:56:52 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 15:59:02 attila_lendvai [~attila_le@92.46.22.248] has joined #sbcl 15:59:02 -!- attila_lendvai [~attila_le@92.46.22.248] has quit [Changing host] 15:59:02 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:02:36 gabnet [~gabnet@ACaen-652-1-192-63.w83-115.abo.wanadoo.fr] has joined #sbcl 16:02:53 -!- gko [~user@114-34-168-13.HINET-IP.hinet.net] has quit [Ping timeout: 255 seconds] 17:00:08 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 17:01:12 -!- gabnet [~gabnet@ACaen-652-1-192-63.w83-115.abo.wanadoo.fr] has quit [Quit: Ex-Chat] 17:08:41 -!- kmb [~kmb@cpe-72-227-136-13.nyc.res.rr.com] has quit [Quit: kmb] 17:10:10 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 17:10:18 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:14:12 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 17:15:42 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 264 seconds] 17:18:38 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 17:29:05 pkhuong: I have looked into jarmond's additional SSE instructions. I have some minor remarks that I will add to the github pull request. But mostly I am wondering whether we want to unconditionally add all these instructions even though they are not supported on all x86-64 processors. 17:29:12 Fare [fare@nat/google/x-mjgyaraosnywtaoj] has joined #sbcl 17:34:46 -!- wbooze [~wbooze@xdsl-78-35-177-230.netcologne.de] has quit [Read error: Connection reset by peer] 17:45:48 -!- [1]Skrylar [HydraIRC@cpe-70-113-115-100.austin.res.rr.com] has quit [Ping timeout: 264 seconds] 18:09:35 Thra11 [~thrall@31.185.182.226] has joined #sbcl 18:09:48 -!- Thra11 [~thrall@31.185.182.226] has quit [Read error: Connection reset by peer] 18:17:49 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 18:22:08 -!- foreignFunction [~niksaak@94.27.88.112] has quit [Quit: Leaving.] 18:27:23 leuler: I think we already have a few of those (?) 18:31:01 leuler: I don't know. I can see the argument re image size, and SSE2 is a natural cutoff line for optional instructions. 18:31:38 Indeed, now that you mention it, we already have more than a few. 18:33:12 two commits, one with the extra instructions, another to split them off into base x86-64 and some build-time conditionals (enabled by default) for the extensions? 18:34:39 Regarding image size, I personally feel less rigorous recently. I am using btrfs with compression and while all these instructions generate huge amounts of code they will not be paged in as long as they are unused (this is an argument against SBCL's own compressed core feature). 18:39:04 There is for example pextrw which before SSE 4.1 supports only a register destination and which, with SSE 4.1, can be encoded differently to support a memory destination, too. This needs a conditional that not only enables additional code but also switches off other code. 18:39:58 oh, yuck. 18:40:23 also, I agree re core compression. 18:40:50 But not everybody has a file system that supports compression. 18:41:45 Of what kind of conditional do you think? Should we extend define-instruction to allow dependency on backend-subfeatures? 18:43:36 was thinking plain #!+, but you're right that backend subfeatures would be more appropriate. 18:43:40 *I 18:44:26 Basically, one should draw a line between the instructions the compiler uses and the ones that are provided as a convenience to people writing their own VOPs? 18:45:19 We could, but then a lot of the SSE2 stuff would go out as well, right? So I was thinking that SSE2/the rest would be a simpler criterion. 18:48:51 I see. 18:49:34 wbooze [~wbooze@xdsl-78-35-177-230.netcologne.de] has joined #sbcl 18:53:26 akovalen` [~user@195.18.46.21] has joined #sbcl 18:55:18 -!- akovalenko [~user@195.18.46.21] has quit [Ping timeout: 264 seconds] 18:58:01 backend-subfeatures is probably not the best way because one could want the instructions without the VOPs. So just a *features* for the non-SSE2 extensions? 19:05:50 I don't understand. Presumably one wants the instructions only if one intends to run on a machine supporting them. Also, presumably, VOPs using these instructions do so because they are faster and shorter. So why should one not want the VOPs then, too? 19:07:08 -!- yacks [~yacks@180.151.36.168] has quit [Quit: Leaving] 19:07:14 because you're testing stuff, for instance, and just want the instructions, without any uncommon codepath. 19:08:16 Or because you suspect there's an issue like the cmov-ful ASH actually being slower than a branch. 19:10:04 I see. 19:11:31 Or because it's easy to enable all the extensions with --fancy, but enabling all kinds of VOPs probably isn't a good idea ;) 19:12:47 siccegge` [~user@2001:a60:f01c:0:42::1] has joined #sbcl 19:13:55 How do you make sure that the backend-subfeature is not enabled when the *feature* is off? 19:14:26 No clue. Worst case, it won't build. 19:16:58 Hopefully, this could simply and automatically be ensured or at least checked at the beginning of the build, with only a little work. 19:20:22 How about two backend-subfeatures? :sse2-vops and :sse2-insts? 19:21:11 That there is an existing mechanism to select VOPs depending on backend-subfeatures (namely :guard) doesn't mean one can use the same feature list to enable instructions? 19:22:38 IIUC, the reason behind backend-subfeatures was so that it could be enabled in a running image? 19:25:06 The way I understand the comment at the start of src/compiler/backend.lisp this property was desirable only for CMUCL and made obsolete by the ability to cleanly cross-compile. 19:25:19 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Quit: +++ killed by SIGSEGV +++] 19:29:28 I don't think that's right -- backend-subfeatures came later 19:30:27 the idea is that you can build a generic image for distribution, but compile new code with new instructions (maybe detected at compile-time based on features of the deployment machine) 19:30:50 basically, the mechanism exists because I am perpetually about two or three generations behind the leading edge of x86 technology 19:36:33 Wait, "compile-time" is the compiler running in the generic image on the deployment machine? 19:41:13 yes 19:41:32 mind you, I'm not sure that this has ever been used in this way 19:41:34 but that was the intent 19:48:18 [1]Skrylar [HydraIRC@cpe-70-113-115-100.austin.res.rr.com] has joined #sbcl 19:57:21 I see. Given that we may now (to support pextrw, and to have a lean core) want to support different instruction subsets under x86-64: Krystof, do you, too, think *features* is the place to select instruction subsets, like pkhuong wrote above? 20:01:02 I'm not sure. By default, I think I'd have the instruction set have the superset of all instructions, and also by default use only a tastefully restricted common subset of the instructions 20:01:20 whether the backend-subfeatures mechanism is the right one for turning on extra instructions, I'm less sure 20:03:35 what about more efficient instruction encoding? 20:05:31 minion: chant 20:05:31 MORE EFFICIENT 20:05:36 hey, that still works. Awesome :) 20:06:07 Regarding "superset" please reread about pextrw above: The instruction definition in the "superset" is not backwards compatible, that is, an older machine supports the instruction, but only with a different encoding. 20:06:40 frankly, it's a different instruction that shares the same mnemonic ;) 20:13:26 :) 20:14:39 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 256 seconds] 20:16:55 -!- [1]Skrylar [HydraIRC@cpe-70-113-115-100.austin.res.rr.com] has quit [Ping timeout: 260 seconds] 20:18:24 Although: pextrw could be defined to use the older encoding if possible (that is, as long as the destination is a register) and the newer only when needed. That would make its definition more complicated but would be backwards compatible. 20:22:41 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 20:22:52 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 20:32:30 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 264 seconds] 20:32:32 that would be nice. I'd consider a variation on the mnemonic, but I think I'm in the minority. 20:34:56 -!- wbooze [~wbooze@xdsl-78-35-177-230.netcologne.de] has quit [Read error: Connection reset by peer] 20:49:51 OK, pushed my comments on github. 20:55:05 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 20:58:53 wbooze [~wbooze@xdsl-78-35-177-230.netcologne.de] has joined #sbcl 20:59:04 [1]Skrylar [HydraIRC@cpe-70-113-115-100.austin.res.rr.com] has joined #sbcl 21:10:23 -!- wbooze [~wbooze@xdsl-78-35-177-230.netcologne.de] has quit [Ping timeout: 240 seconds] 21:17:22 wbooze [~wbooze@xdsl-78-35-177-230.netcologne.de] has joined #sbcl 21:19:14 leuler: good, thanks. 21:22:09 Thanks for the discussion! 21:31:18 -!- sdemarre [~serge@109.134.133.85] has quit [Ping timeout: 264 seconds] 21:54:20 -!- [1]Skrylar [HydraIRC@cpe-70-113-115-100.austin.res.rr.com] has quit [Ping timeout: 255 seconds] 21:59:23 -!- akovalen` [~user@195.18.46.21] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 22:02:28 akovalenko [~user@195.18.46.21] has joined #sbcl 22:49:24 -!- leuler [~user@p548FD5BA.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 22:57:57 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 23:01:29 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 23:33:21 -!- LiamH [~none@pool-74-96-4-63.washdc.east.verizon.net] has quit [Quit: Leaving.] 23:53:05 [1]Skrylar [HydraIRC@cpe-70-113-115-100.austin.res.rr.com] has joined #sbcl