00:02:29 -!- Quadresce is now known as Qworkescence 00:06:23 -!- srydberg [~srydberg@c-89-160-99-93.cust.bredband2.com] has quit [Quit: Leaving] 00:15:06 -!- kanru`` [~user@61-228-144-239.dynamic.hinet.net] has quit [Ping timeout: 250 seconds] 00:23:34 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 00:27:14 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 265 seconds] 00:30:09 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 00:48:38 tsuru```` [~charlie@adsl-74-179-20-206.bna.bellsouth.net] has joined #sbcl 00:50:25 -!- tsuru``` [~charlie@adsl-74-179-20-106.bna.bellsouth.net] has quit [Ping timeout: 276 seconds] 01:13:54 -!- tsuru```` [~charlie@adsl-74-179-20-206.bna.bellsouth.net] has quit [Ping timeout: 245 seconds] 01:19:45 -!- saschakb [~saschakb@p4FEA0019.dip0.t-ipconnect.de] has quit [Read error: Connection timed out] 01:20:19 saschakb [~saschakb@p4FEA0019.dip0.t-ipconnect.de] has joined #sbcl 01:31:01 echo-area [~user@182.92.247.2] has joined #sbcl 02:25:41 KDr2 [~kdr2@125.34.44.137] has joined #sbcl 03:04:07 -!- homie```` [~levgue@xdsl-78-35-183-189.netcologne.de] has quit [Ping timeout: 252 seconds] 03:09:06 homie```` [~levgue@xdsl-78-35-183-189.netcologne.de] has joined #sbcl 03:11:07 -!- homie```` [~levgue@xdsl-78-35-183-189.netcologne.de] has quit [Read error: Connection reset by peer] 03:13:13 homie [~levgue@xdsl-78-35-183-189.netcologne.de] has joined #sbcl 03:44:30 saschakb_ [~saschakb@p4FEA0B60.dip0.t-ipconnect.de] has joined #sbcl 03:47:43 -!- saschakb [~saschakb@p4FEA0019.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 04:04:37 -!- saschakb_ [~saschakb@p4FEA0B60.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds] 04:11:11 saschakb_ [~saschakb@p4FEA0B60.dip0.t-ipconnect.de] has joined #sbcl 04:17:25 -!- saschakb_ [~saschakb@p4FEA0B60.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds] 04:30:49 saschakb [~saschakb@p4FEA0B60.dip0.t-ipconnect.de] has joined #sbcl 05:18:59 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 05:19:25 -!- saschakb [~saschakb@p4FEA0B60.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 05:24:59 saschakb [~saschakb@p4FEA0B60.dip0.t-ipconnect.de] has joined #sbcl 05:45:59 -!- saschakb [~saschakb@p4FEA0B60.dip0.t-ipconnect.de] has quit [Read error: Connection timed out] 05:46:41 saschakb [~saschakb@p4FEA0B60.dip0.t-ipconnect.de] has joined #sbcl 06:04:12 -!- saschakb [~saschakb@p4FEA0B60.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 06:09:34 saschakb [~saschakb@p4FEA0B60.dip0.t-ipconnect.de] has joined #sbcl 06:29:39 -!- slyrus [~chatzilla@209.52.84.50] has quit [Ping timeout: 260 seconds] 06:58:58 -!- saschakb [~saschakb@p4FEA0B60.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds] 07:05:55 saschakb [~saschakb@p4FEA0B60.dip0.t-ipconnect.de] has joined #sbcl 07:07:28 -!- homie [~levgue@xdsl-78-35-183-189.netcologne.de] has quit [Read error: Connection reset by peer] 07:08:07 homie [~levgue@xdsl-78-35-183-189.netcologne.de] has joined #sbcl 07:18:38 slyrus [~chatzilla@209.52.84.50] has joined #sbcl 07:48:23 edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 07:59:33 specbot [~specbot@pppoe.178-66-64-202.dynamic.avangarddsl.ru] has joined #sbcl 08:15:19 -!- les [moreorles@unaffiliated/les] has quit [Changing host] 08:15:19 les [moreorles@fsf/member/les] has joined #sbcl 09:37:37 -!- KDr2 [~kdr2@125.34.44.137] has quit [Remote host closed the connection] 10:10:27 attila_lendvai [~attila_le@87.247.54.209] has joined #sbcl 10:10:27 -!- attila_lendvai [~attila_le@87.247.54.209] has quit [Changing host] 10:10:27 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:06:37 -!- cmm [~cmm@109.65.214.84] has quit [Ping timeout: 276 seconds] 11:07:06 cmm [~cmm@bzq-109-65-214-84.red.bezeqint.net] has joined #sbcl 11:18:42 easye` [~user@213.33.70.157] has joined #sbcl 11:19:33 The download for sbcl-1.0.56-x86-solaris-binary.tar.bz2 appears to be corrupted 11:23:02 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 11:26:31 -!- edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 11:27:46 edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 11:38:32 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Ping timeout: 244 seconds] 11:42:10 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 11:54:59 -!- stassats` [~stassats@wikipedia/stassats] has quit [Read error: Connection reset by peer] 11:55:25 -!- specbot [~specbot@pppoe.178-66-64-202.dynamic.avangarddsl.ru] has quit [Read error: Connection reset by peer] 12:07:08 stassats [~stassats@wikipedia/stassats] has joined #sbcl 12:08:43 specbot [~specbot@pppoe.178-66-64-202.dynamic.avangarddsl.ru] has joined #sbcl 12:09:17 homie` [~levgue@xdsl-78-35-149-109.netcologne.de] has joined #sbcl 12:12:25 -!- homie [~levgue@xdsl-78-35-183-189.netcologne.de] has quit [Ping timeout: 246 seconds] 12:13:32 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 12:33:21 gko [~gko@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 12:49:38 leuler [~user@p54904CBF.dip.t-dialin.net] has joined #sbcl 13:23:50 homie`` [~levgue@xdsl-78-35-149-109.netcologne.de] has joined #sbcl 13:24:27 -!- homie` [~levgue@xdsl-78-35-149-109.netcologne.de] has quit [Read error: Connection reset by peer] 13:43:25 -!- gko [~gko@114-34-168-13.HINET-IP.hinet.net] has quit [Read error: Connection reset by peer] 14:04:46 nikodemus [~nikodemus@178-55-38-11.bb.dnainternet.fi] has joined #sbcl 14:04:46 -!- ChanServ has set mode +o nikodemus 14:18:03 -!- les [moreorles@fsf/member/les] has quit [Quit: leaving] 14:21:59 les [moreorles@lesharris.com] has joined #sbcl 14:22:00 -!- les [moreorles@lesharris.com] has quit [Changing host] 14:22:00 les [moreorles@fsf/member/les] has joined #sbcl 14:49:59 -!- pjs_ [~peter@pjstirling.plus.com] has quit [Read error: Connection reset by peer] 15:14:20 kwmiebach [~kwmiebach@164-177-155-66.static.cloud-ips.co.uk] has joined #sbcl 15:20:13 tsuru [~charlie@adsl-98-87-48-95.bna.bellsouth.net] has joined #sbcl 15:20:34 -!- tsuru is now known as tsuru` 15:35:20 Kryztof: any thoughts on my compiler macro patch? 15:36:22 (the only real change to the one i posted -> my current tree is that i signal a full warning for compiler-macro errors instead of just printing a notification) 15:36:37 the one with the hilarious keyword parameter observations? 15:36:45 yes 15:37:00 I wondered whether it was possible to do something sufficiently smart in the "normal" case 15:37:00 which everyone seems to implement religiously :) 15:37:31 you mean (foo 'key t) ? 15:38:02 Not sure what I mean 15:38:30 I'm not sure I understand: why is it a problem for compiler-macros to be macros? 15:38:34 Isn't that the expected behavior? 15:38:44 the problem is the semantics of the macro lambda list 15:39:09 Sure, macro lambda lists have some...unexpected...behavior 15:40:17 but it seems to me that it's equally unexpected in a macro vs. a compiler macro, isn't it? 15:41:15 (define-compiler-macro foo (&key ((key key-var)) bar) (format nil "key=~A, bar=~A" key-var bar)) 15:41:15 (let ((key :bar)) (foo key 42)) 15:42:08 in a regular macro lambda list that is at least sane, because you /must/ be able to resolve keyword arguments to expand 15:42:47 in a compiler-macro lambda list it's just ... spec bogoid 15:42:58 Doesn't seem sane to me. :) 15:43:38 yeah, but the insanity is in the spec :) 15:44:15 Why isn't it expected for a compiler-macro to behave mostly the same as a normal macro? 15:44:28 because they are function replacements 15:45:53 even the destructuring features of macro lambda lists are pretty useless in compiler macros, because there's no pattern matching. so if you destructure anything you're imposing syntax on all call sites 15:46:45 anyways, my patch makes the compiler not expand FOO above -- if there was a (defconstant key 'key), then it would let it happen 15:47:12 I would have liked &key ... in a compiler macro to insert into the expansion, if any, the minimal runtime keyword argument parsing 15:47:32 I think that's the Sufficiently Smart (if non-conforming) option 15:47:39 yeah 15:47:42 It would be nice if compiler-macros weren't actually macros. 15:47:56 But since they are... 15:48:27 there's probably a CDR in here somewhere 15:48:56 i think we should have something closer to deftransform that has a documented interface what doesn't expose too many internals -- but compiler macros are what they are 15:49:06 which, even 15:49:47 I don't see any reason why compiler macros behave differently than normal macros. They are macros, adding more special cases won't fix that. 15:49:59 add "should" in there 15:50:17 are you talking in the abstract, or about my patch? 15:51:00 abstract 15:51:48 compiler macros are -- in the abstract -- already pretty different from regular macros. there's decline to expand, and there's the FUNCALL special casing 15:52:01 and their optionality 15:52:07 right 15:52:09 and their inhibition with compiler switches 15:52:37 to me, they are clearly meant to augment functions, and to give users a chance to do custom optimizations 15:53:01 and the semantics of the compiler macro lambda list basically shoot down anything with an interesting signature 15:54:18 re. the patch. 15:55:22 my recollection is that the patch was minimally sane: doesn't make things actively better, but removes gun from in between toes 15:55:23 pro: makes simple &key compiler macros a lot easier to write, since (define-compiler-macro foo (&key ...) ...) no longer signals an error when someone writes (foo variable value) 15:55:50 pro: no gun between toes 15:56:03 milanj [~milanj_@109-92-107-108.dynamic.isp.telekom.rs] has joined #sbcl 15:56:36 pro: just a compile-time warning/failure instead of both compile-time failure and runtime error 15:56:43 in my ideal world, the ANSI Gods would have specified 15:56:48 (define-compiler-macro foo (&key x) `(1+ ,x)) 15:56:49 (foo bar 3) => (destructuring-bind (&key (:x #:x-key-arg) &allow-other-keys) (list bar 3) (1+ #:x-key-arg)) 15:56:49 15:57:03 but they didn't 15:58:19 con: makes somewhat easier to write compiler-macros that aren't quite as portable as a naive author might think 15:58:54 style-warn on &key compiler macro lambda lists? 15:59:07 so, alternative plan: style warning on any define-compiler-macro with &key in it (or indeed any macro lambda list "feature"), and have sb-ext:define-what-compiler-macro-should-have-been? 15:59:27 pkhuong: so you're expected to parse &key arguments yourself? 15:59:45 froydnj: the compiler-macro as specified requires that anyway 16:00:00 unless all calls are guaranteed to have no variable keyword arguments 16:00:11 fun. 16:00:12 Kryztof: in many cases you don't have to 16:00:43 specifically: if you only expand if all the keywords present have constant arguments, so order of evaluation doens't matter 16:00:59 froydnj: that's how things were specced. If we go beyond spec, I'd want a style warning. 16:01:08 and since :foo t is a fairly common pattern, i don't think that's insignigicant 16:01:47 don't you still have to parse the keyword arguments, so that you can be sure that you haven't missed a variable? 16:02:18 you can't just do (&key foo &allow-other-keys) because then you will expand (let ((y :foo)) (frob y nil :foo t)) wrong 16:02:35 so whatever happens you need the &rest list and to parse it yourself 16:03:31 (define-compile-macro foo (&whole form ...requireds... &key opt1 opt2) (if (and (constantp opt1) (constantp opt2)) ..expansion.. form)) 16:03:39 no &REST needed 16:04:19 but then you will break on (foo var t :opt1 nil :opt2 t) 16:04:36 (as specified) 16:05:00 with my patch you won't -- and it's legal, since we're always allowed to decline to expand 16:05:41 the patch declines to expand a compiler-macro when there's anything but a self-evaluating symbol in keyword position 16:06:09 so yes, for portability you need &REST 16:06:28 right 16:07:09 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 16:07:41 it is sort of ironic that the "aim gun away from foot" is the bit that creates the reduced outwards portability here 16:08:49 sounds good to me: decline to expand when we can't see far enough in the future, and style warn on &key-ful compiler macro lambda lists? 16:09:08 style warn on &key-and-no-&rest? 16:09:21 ohh, another option. 16:09:40 and construct a compatible interface that Does the Right Thing? something along the lines of the destructuring bind expansion, only less sucky? 16:10:15 potential bonus point: we can run that compatible interface version after type derivation 16:10:51 style warnings i can add at short notice, bonus points will have to wait 16:11:03 IIUC, nikodemus's patch still handles common cases like all-constant keyword arguments. 16:11:10 yes 16:11:30 eh, good enough. exposing deftransform-like capabilities can wait. 16:11:30 no objection 16:12:36 "STYLE-WARNING: Using &KEY in compiler-macro lambda-lists without manually parsing &REST is unportable."? 16:13:09 LGTM. Possibly worth a reference condition and a mention in beyond-ansi? 16:13:14 right. 16:13:34 The issue is subtle enough that I don't expect to be able to understand it via a style warning. 16:15:25 isn't this specifically "not beyond ansi" kind of thing? 16:15:46 it's behaviour that we specify beyond ANSI guarantees 16:16:17 but not an extension as such 16:16:41 I mean, I agree, it's not beyond ANSI, but it needs documenting anyway, and beyond-ansi is the place that it fits best as far as I can tell 16:17:03 i mean, i would not look for information on compiler-macro expansion details in beyond-ansi, but rather the compiler or optimizations chapter 16:17:31 *froydnj* may have to consider his ironclad compiler macros a little more carefully now 16:17:38 the manual /so/ needs an editor 16:17:58 well, I am perhaps leaping ahead a couple of steps 16:18:19 4.5 then? 16:18:48 but I imagine that style warning turning into "STYLE-WARN: your code doesn't work, but you meant to use sb-ext:define-useful-compiler-macro. See also: Beyond Ansi#DEFINE-USEFUL-COMPILER-MACRO" 16:18:49 4.5 sounds about right 16:19:13 aah 16:21:48 but I guess DEFINE-USEFUL-COMPILER-MACRO might end up in the compiler chapter anyway, so maybe 16:23:46 by the time it arrives the manual might have gone through The Second Great Re-Organization or something, so... 16:27:26 true 16:27:34 maybe we could release 2.0 and sell printed copies of the manual 16:27:47 then we would all be rich 16:28:12 *Kryztof* imagines the kickstarter now. $10000 SPECIAL ILLUMINATED EDITION 16:28:40 perk: Christophe's choir will call you on skype and sing you the docstring of your choice 16:28:47 haha 16:29:43 but hey, since people are here, on thing i would like to set on percolation in your minds... 16:30:27 coffee? 16:32:11 if, for the benefit of quicklisp, we add sb-http as a contrib, it opens a nice door for sb-updates for hotpatches, announcements of major releases, etc 16:32:54 if we add sb-https too, then the dream of bug reporting from within the environment could be realised 16:32:56 and sneakily, via server stats, might actually give use a better idea installed base 16:33:28 Xach wants to eventually make quicklisp https anyways... 16:33:54 "simply type in your gpg passphrase, Sir" 16:34:58 haha 16:35:59 second thing, while the village fair lasts 16:37:01 *froydnj* thinks adding sb-http-esque things (e.g. python's urllib2) would be a fine thing 16:37:02 i would like to add an initfile for --script 16:37:36 would you be able to do (load "http://quicklisp.org/quicklisp.lisp")? 16:38:02 nikodemus: so initfile and :script in features or something like that? 16:38:54 more like .sbcl-scriptrc 16:38:55 (make-pathname :host "quicklisp.org" :device "http" ...)? 16:39:19 about every three years I convince myself that it should be possible to represent urls in pathnames 16:39:23 then I wake up from the screaming nightmare 16:39:28 (load (sb-http:get "http://quicklisp.org/quicklisp.lisp")) 16:39:57 well, on ccl you can just do (load "http://quicklisp.org/quicklisp.lisp") 16:39:58 Kryztof: =D 16:40:21 SCL too, iirc. 16:40:35 ABCL and CCL people have gone there, but i don't know if they're screaming 16:40:35 SCL represents URLs as pathnames 16:40:37 afair 16:40:59 dtc does it, it can't be too bad, right? 16:41:16 SCL pays a steep price re. pathname merging, though 16:41:22 Xach has the details 16:41:26 and ccl just does it in LOAD 16:41:40 I'd rather that sbcl bundled a portable http client. It really bugs me that so much functionality exists in sbcl which duplicates portable equivalents, but has a totally different API. 16:42:21 *froydnj* senses the debate moving in a direction we have already gone... 16:43:05 if there's a minimal http client without external deps and a good licence, i'm fine bundling it 16:43:30 but adding more external deps just to make bootstrapping quicklisp easy is... backwards :) 16:43:56 just strip the quicklisp's http client 16:44:08 not a bad idea, actually 16:44:12 quickhttp 16:44:21 Only if you don't plan to remove the duplicative internal deps later. 16:45:20 Does this mean I ran out of memory? "Heap exhausted during garbage collection: 0 bytes available, 16 requested." ldb> 16:45:28 LiamH: yup. 16:45:51 foom: sb-rt, sb-md5, ... do you also count sb-posix? sb-bsd-sockets? 16:45:52 foom: At some point, the plan was to just exploit quicklisp. 16:46:06 i think that's /still/ the plan 16:46:09 It might be time to bundle it, like asdf. 16:46:11 nikodemus: yes, also unicode support. 16:46:16 what? 16:46:20 *blink* 16:46:46 foom: if we *had* real unicode support (as opposed to just the minimal infrastructure to enable it), I'd agree with you. 16:47:10 But we don't even have code to canonicalise strings. 16:47:45 pkhuong: well, we have encoding/decoding support for a bunch of character sets. But every third party package uses one of a few 3rd party libraries' support for that instead. 16:48:08 sb-alien too. 16:48:09 ours should be better. (They aren't, mind you) 16:48:10 ok. I can see that. 16:48:16 sb-alien *is* better 16:48:56 what are the sucky bits of our unicode support? 16:49:05 babel isn't bad, but it isn't great either -- and every 3rd-party package that uses it either doesn't use it on streams (cos it doesn't do streams), or adds another layer of streams 16:49:07 foom: otoh, I'm not comfortable saying that SBCL supports unicode if it can only read/write ascii or iso-8859-1. 16:49:12 pkhuong: Right, but it doesn't matter. Unless sbcl's betterness is exposed as an extension to cffi, everyone should use CFFI instead. 16:49:52 sb-alien's betterness can't be exposed elsewhere until they sprout type propagation. 16:49:56 foom: cffi's design is explicitly at odds with betterness of sb-alien 16:50:43 The reason I strongly prefer cffi over sb-alien is its lack of the weird type stuff. 16:51:38 lichtblau: I like the weird type stuff (: If I don't want it, I can always cast aliens to SAPs. 16:51:44 pkhuong: right, the duplication between salza and babel is also crazy. 16:51:53 i would ideally like to have a CFFI-style FFI interface in sbcl, because sometime's it's just easier -- when i use sb-alien i tend to use a lot of saps anyways 16:52:16 I realize others have different preferences, and I think everyone should get their wishes, so I'm not trying to convince anyone to change their personal API goals. But I think that cffi's lack of type stuff makes it much easier for new users to get started with it. 16:52:17 but i don't see how we can /build/ sbcl with cffi 16:52:57 why not? 16:52:59 but having a CFFI-style interface in SBCL /would/ be clear duplication, unless it's CFFI 16:53:19 why we can't build with CFFI? 16:53:21 yea 16:53:27 CLOS in cold init for one 16:53:43 someone had a plan to fix that a few years ago, I think. :) 16:54:02 that needs either independent wealth or about four grad students 16:54:05 I'll take either 16:54:55 four? You only need one, if you can chain it to a desk for 6 years. 16:55:22 froydnj: isn't it still quite slow, compared even with the excessively slow babel? Or is that gone now? 16:55:36 also, we don't support anything else, like normalization, collation, case-conversion, ... 16:55:59 it's slow 16:56:03 Kryztof: I haven't done benchmarks recently; I thought we weren't too far behind... 16:56:07 not always excessively 16:56:16 some of it is slow because of the ultraclever restart stuff that I put in 16:56:16 depends on exactly what you're doing 16:56:17 so blame me 16:56:24 but yes, all the other normalization, collation stuff is suboptimal 16:56:25 was 16:56:32 excellent 16:56:34 the slow restarts are gone, since 16:56:45 I hope they were replaced with fast restarts :) 16:57:03 since someone figured out the trick of not putting them around places where they're not needed 16:57:08 someone was clever 16:57:13 wasn't me 16:57:22 this is all iirc, though 16:57:35 yeah, maybe we need ... BENCHMARKS! 16:57:50 -!- slyrus [~chatzilla@209.52.84.50] has quit [Ping timeout: 265 seconds] 16:57:57 of course, if one really cares about perf, they should work on the un-decoded bytestream (: 16:58:46 Anyways, I think my main point is, all you really smart people are working on adding these awesome features for sbcl. But then, all that work is wasted, because the wider development community will never use it, they use a portable library that reimplements everything from scratch. 16:58:48 And then there's me, a user who traditionally hasn't used any third party libraries, but wants to start. And as I start looking, I get sad that everything requires me to pull in duplicate functionality to that which is already present in sbcl, and has had so much effort put into optimizing it. 16:59:21 And I just can't help but think there's got to be a better way. 16:59:45 i have a partial answer, which hingers on quicklisp 17:00:10 no more contribs unless they're totally unportable-can't-ever-even-think-of-how 17:00:34 with the exception of stuff that we need to make bootstrapping quicklisp trivial 17:00:38 nikodemus: sure. Expose the foundation, move everything else to a third-party package. 17:00:47 e.g. my grand SSE intrinsic plan. 17:00:52 i have a step 2 :) 17:01:03 foom: there is clearly a tension between use-an-implementation and write-portable-or-almost-so CL 17:01:06 you moved the profit step up! excellent! 17:01:17 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 17:01:20 ? 17:01:40 oh wait 17:01:47 no, this is step 1 17:01:56 That's teclo's plan too. 17:01:58 1. Profit. 17:01:59 step 1: profit? I like it alrady! 17:02:11 cuts to the chase, nice and direct 17:02:20 what would have been a contrib, is still sb-foo -- but in quicklisp, and portable, but the main implementation is explicitly sbcl 17:02:46 so we get mindshare, publicity, /and/ reduced duplication 17:02:57 the nice thing about contribs is that they're installed by default too. 17:03:27 i stopped caring about that with quicklisp, in all honesty 17:04:06 Oh, I forgot to mention sb-threads above, too. Also a duplicative interface. :) 17:04:14 it would be fine for such a "non-contrib" to be _optimized_ heavily for SBCL, but I think there should be a rule to also support at least, say, Clozure 17:06:14 It's hard to set such a rule in stone, of course, when the other implementation isn't under the control of the contrib author, but I think Clozure in particular is reasonably easy to target for most stuff, and is a very important impl to support. 17:06:17 Whereas if such extensions start out as SBCL-only libraries, the benefit wouldn't seem clear to me. 17:06:39 the old MCL community built up largely around a whole heap of MCL-only libraries 17:06:54 Kryztof: that's the apple crowd. 17:08:06 lichtblau: if i wear my lisp advocate hat, i agree. wearing my sbcl hat i say that put it on github and merge clozure patches as they come in 17:08:10 I would like it to be conceivable to use SBCL and to develop on without particularly caring that there are other CL implementations 17:08:29 lichtblau: kind of like sb-cga has ended up 17:08:49 lichtblau: we could at least do stuff like separate sbcl-specific code from the rest that merely exploits that interface 17:08:50 I realise that our platform support isn't there yet for many users ;-) 17:09:23 it runs even on clisp, but the fancy vops are sbcl only -- if someone sends me a patch that makes it better on another impl, i'll merge 17:09:48 nikodemus: that's a fine strategy if you're developing for yourself, or if your client targets SBCL only. But I wonder whether it addresses the needs of most actual (or potential) SBCL users/customers. 17:09:52 Kryztof: Yeah. Me too! I don't ever want my software to run on other impls. But I realize that lots of people do want that, and thus *their* stuff depends on annoying portability layers. 17:10:30 Being bound to an implementation feels less terrible if it's the only impl for your OS (what pkhuong says). Or if you're so focused on speed that it would be impossible to support anything else (foom's project, I suppose). 17:10:51 So, I want sbcl to just provide the portable interface itself, instead of having multiple layers and multiple APIs to go through. 17:11:11 lichtblau: considering how /slow/ some of the third party layers like flexi-streams (iirc -- maybe i misremember) are, i think "runs FAST on sbcl, works elsewhere too" should be a pretty good deal 17:11:12 And if it has additional functionality, provide it as an extension to the portable API, so I can still use the extra sbcl-only features. 17:11:25 Having been through it, for anything else, I really couldn't recommend to anyone to ever write a major project for a single implementation. And I can't imagine that other users don't have the same feeling. 17:11:28 nikodemus: ++ 17:12:12 re. "stuff that's already in sbcl and contribs, and duplicated elsewhere" 17:12:31 i'm not opposed to cleaning those things up at all 17:12:38 nikodemus: Yes, that's cool. If, running with CCL, need to set up three times as many app servers as with SBCL for speed reasons, that's something I can explain. As long as it works at all. 17:13:45 but for things that are not contribs, i don't see an obvious way to do it that doesn't take an awful lot of time that could be spent on other stuff as well 17:15:24 You know, I think that's actually great. It sounds like everyone might actually pretty much agree it would be a good goal. :) 17:17:00 slyrus [~chatzilla@209.52.84.50] has joined #sbcl 17:17:06 foom: now find someone to actually do it ;) 17:17:12 slyrus: you rang? 17:22:39 -!- slyrus [~chatzilla@209.52.84.50] has quit [Ping timeout: 245 seconds] 17:35:31 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:43:24 slyrus [~chatzilla@209.52.84.50] has joined #sbcl 17:49:55 I just used REMOVE-DUPLICATES on a slightly long list and noticed that, if :KEY is used, it is slow. There is an optimization to use a hash table instead of the quadratical generic algorithm, but it is used only without :KEY. 17:50:03 I think the hash table using code would be sufficiently easy to extend to the :KEY case that I could do it. Would that be desirable? 17:50:13 I am asking because I currently intend to only try to improve that one case but would like to think further ahead before starting: 17:50:19 There is also the vector case which currently never uses a hash table, but maybe that should be changed, too? And for DELETE-DUPLICATES, would consing (a hash table) be undesirable? 17:50:41 leuler: all sound desirable to me 17:51:21 I can see delete-duplicates not wanting to cons 17:51:30 apropos: if someone wants to see something painfully unoptimized, take a look at merge 17:51:47 does anybody use it? 17:51:52 maybe there could be a space/speed tradeoff? 17:52:29 delete-duplicates consing but running in linear time on long inputs sounds good to me 17:52:56 tsuru`` [~charlie@adsl-74-179-25-14.bna.bellsouth.net] has joined #sbcl 17:53:53 Why? If a user wants delete-duplicates to be fast and doesn't care about consing, he can use remove-duplicates instead. 17:54:24 hm 17:54:50 who cares about not consing if it's slow? 17:54:52 -!- tsuru` [~charlie@adsl-98-87-48-95.bna.bellsouth.net] has quit [Ping timeout: 265 seconds] 17:55:17 maybe 17:55:38 you care about not consing if your working set is about the size of the heap 17:55:39 and delete will cons less 17:56:07 Kryztof: then implement your own thing 17:56:22 But if your working set is large a quadratical algorithm will "never" finish. 17:56:34 i imagine a non-consing delete-duplicates on the size of the heap to be excruciatingly slow 17:56:37 if your working set is large but your vector is small, it will 17:56:41 unless heap is very small 17:57:41 Large working set essentially meaning that gc's are slow? 17:57:42 imagine a large number of smallish vectors, all of which need to have duplicates deleted 17:58:09 if you're doing remove-duplicates, you've already excluded this case, because you're consing up return values. If you're doing delete-duplicates, you haven't 17:58:24 I do not have a real use case for this, obviously, I'm just saying that this is a case not catered for by making delete-duplicates fast-but-consy 17:59:59 or that the heap might be exhausted with any extra allocation 18:00:46 n generally doesn't guaranty not consing, just that it might be destructive, so the code shouldn't really depend on that 18:00:56 n and delete 18:01:20 I agree, there aren't many guarantees in the spec 18:01:51 if you only allow dependence on what is explicitly guaranteed, a whole heap of programs break 18:02:00 and i think it'd be quite confusing why delete-duplicates is slower than remove-duplicates 18:02:01 stack allocate a bit-vector, mark sxhash mod n for one there, if sxhash mod n is zero, you know it isn't a duplicate. for the rest do the slow version :) 18:02:30 creative! 18:03:08 -!- tsuru`` is now known as tsuru` 18:03:10 our pages are pretty big now, so there should not even be too many collisions for a one-page bit vector :) 18:03:11 this discussion sounds somewhat crazy to me if we're already doing the hash-table optimization for the normal case, and just not for :key 18:03:35 stassats: currently delete-duplicates is slower the remove-duplicates for long lists. 18:03:35 jsnell: not for delete-duplicates, i believe 18:04:00 ok, misunderstood the original problem statement then :-) 18:04:02 vector-delete-duplicates has no hash table thingy 18:04:19 The only case currently hashing is: list, no :KEY, REMOVE-DUPLICATES 18:07:17 and i replaced delete-duplicates instead of remove-duplicates in the past, thinking it'd be faster 18:07:20 how foolish of me 18:09:28 nikodemus: with 4e7866afc56e4eec4e33dc2d61bd4f0aeed72cfd (for associating conditions with restarts) maybe stream-foocoding-error could have been a macro expanding into ERROR instead? restart-case macroexpands its argument to look for that 18:09:49 remove-duplicates was only optimized to help fix bug 384, something with the compiler taking too long processing some complemented character type. 18:10:37 *stassats* enncountered the tree of nested IFs ORs and ANDs in remove-duplicates 18:10:50 and shivered 18:11:31 that's in the non-hash-using parts. 18:16:51 hrm... new sbcl seems to be repeatedly hanging doing simple things like asdf-loading stuff from slime 18:18:13 sdemarre [~serge@91.176.119.155] has joined #sbcl 18:22:52 OK, my conclusion for now is: I will look into LIST-REMOVE-DUPLICATES to improve the case of provided :KEY, with an eye on the possible future extension of using a hash table in VECTOR-REMOVE-DUPLICATES, too, (both without and with :KEY), and leave DELETE-DUPLICATES completely alone. 18:23:43 leuler: what about nikodemus's suggestion? 18:23:58 hmm... it actually seems to be trying to compile make-flexi-stream that is causing the hang. 18:26:21 stassats: I thought that suggestion was not completely serious, but most importantly meant only for the destructive case. 18:30:05 Kryztof: sure, but each function only had one call-site, so 18:30:34 -!- psilord [~psilord@76.201.149.239] has quit [Ping timeout: 276 seconds] 18:31:10 slyrus: can you bisect? 18:31:23 after skiing :) 18:32:12 priorities :) 18:32:42 leuler: not completely serious, not completely joking :) 18:33:52 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 18:33:55 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 260 seconds] 18:35:57 nikodemus: Seriously: But you were targeting only DELETE-DUPLICATES with that suggestion, not REMOVE-DUPLICATES? 18:36:42 i wasn't really thinking of it in those terms 18:36:57 makes sense. 18:37:05 although mod is a sucky hash. 18:37:24 "can i make up a silly way to speed things up without consing? oh, hey, this might not be completely silly, actually" 18:38:28 now, you could either store one object in each slot of a simple vector, or go for a bit vector. 18:40:36 let me write a quick sketch of what i had i mind 19:01:38 https://gist.github.com/2423090 19:05:35 i think i want make-pages 19:06:15 make-array -style function, which gets told how many pages the array should fill 19:07:01 one of the "*list*" should be "list" 19:07:20 oops 19:18:48 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 19:39:24 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Read error: Connection reset by peer] 19:39:47 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 19:51:52 nikodemus: I don't know what to make of that. It is much faster than delete-duplicates for reasonable input. But if the input list is so long that most bits are set it obviously degrades to quadratical behaviour again. 20:10:24 -!- sdemarre [~serge@91.176.119.155] has quit [Ping timeout: 260 seconds] 20:14:07 i think (if i measured correctly, that is), nikodemus' function can be made faster by using multiple result bins (see comment in https://gist.github.com/2423090) 20:17:21 Yes. But that doesn't work for the intended application, as remove-duplicates is specified to keep elements in the same order that they have in the input sequence. 20:18:43 Presumably, the bit array could be used more efficiently as a bloom filter, shifting the point where it degrades to quadratical behaviour further towards longer lists and/or more duplicate elements. 20:18:53 leuler: i don't know either. if non-consingness is deemed essential for delete-duplicates, then it seems like a decent haflway house 20:19:11 oh, clever! 20:22:44 What about putting a fixed-size hash table in the same space? This avoids false positives completely until more different elements are encountered than fit in it. 20:23:28 sure, but you need to either jump through a fair amount of hoops to get stack-allocatable hash-tables (which would be totally cool, actually), or hand-roll one 20:23:29 won't all this use too much stack space? 20:25:02 use two pages? one for simple-vector, used initially as a linear-probed hash-table. second with the bit vector that the system can degrade into if the table gets too full? 20:25:40 How complicated do you want to make all that? I'm getting scared. 20:26:08 to get the SSC Seal of Approval 20:26:30 this is really Sufficiently Smart Library :) 20:26:42 SSI 20:27:26 leuler: thanks, i wasn't aware of that 20:27:45 but seriously: whatever seems appropriate to you. i'm just tossing ideas :) 20:28:40 Someone please explain to me which of the many possible meanings of SSC and SSI were intended? 20:30:02 i assumed Sufficiently Smart Compiler -- not sure about SSI 20:30:18 Sufficiently Smart Interpreter? 20:30:28 interpreter? come on! 20:30:32 Implementation 20:30:41 Thanks. 20:32:49 leuler: on one hand i'm pretty sure massive inputs for those functions aren't worth worrying about -- but it's nice if they perform well beyond the point which lists-as-sets is really a good choice, because people are lazy 20:33:21 Yes, I see your point. 20:33:31 leuler: on the other hand, if someone wants to make them massively clever, i don't think the maintenance burden is especially big either 20:34:26 leuler: on, um, left leg, i think there might be serious payoffs for reasoanble lists-as-sets in doing similar optimizations as have been done for assoc, member, etc 20:35:02 and it might speed up compilation 20:37:09 nikodemus: You lost me with your last statement. You refer to which optimizations? and which operations on lists-as-sets? 20:37:12 eg. special case for :test #'eq 20:37:57 ie, teach the compiler to turn (delete/remove-duplicates list :test #'eq) to (%delete/remove-duplicates-eq list) 20:38:08 EQ vs EQL comparison cost is massive 20:38:26 I see. 20:39:41 but then again, for member and assoc the compiler can often do that without the user asking for it, if it sees (or fixnum (not number)) as the comparison element 20:40:08 massive? really? 20:44:17 http://paste.lisp.org/display/129054 20:44:40 in my books 2 x is massive 20:45:17 3 x here 20:45:30 it also depends on just what the types of arguments are 20:46:50 difference grows if you make the list filled with eg. 0.0, and look for 1.0 there 20:48:57 but, bottom line: i think it's definitely worthwhile sprucing those to functions up. calling the point of diminishing returns is IMO up to the person doing the work 20:49:48 OK. That was at least a lot of good food for thought and experimentation. 20:52:35 flip214: i get lots of Extra arguments in (MAYBE-COERCE-TO-SIMPLE-STRING ... 20:53:05 oh, the patch didn't apply cleanly 20:54:00 and, the wrong channel 21:04:45 psilord [~psilord@76.201.149.239] has joined #sbcl 21:25:09 -!- antgreen [~user@bas3-toronto06-1176449538.dsl.bell.ca] has quit [Ping timeout: 245 seconds] 21:26:16 -!- nikodemus [~nikodemus@178-55-38-11.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 22:06:35 -!- leuler [~user@p54904CBF.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 22:30:25 re remove-duplicates: i think, the current implementation is buggy 22:30:40 (remove-duplicates '(1 2 3 2)) => (1 3 2) 22:31:21 as leuler pointed out, the order of elements should be preserved 22:36:15 "The elements of sequence are compared pairwise, and if any two match, then the one occurring earlier in sequence is discarded, unless from-end is true" 22:39:38 oh, i see. sorry 22:45:26 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 23:03:50 -!- milanj [~milanj_@109-92-107-108.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 23:06:53 borodon [~Borodon@ip68-106-150-168.cl.ri.cox.net] has joined #sbcl 23:13:41 -!- edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 23:17:29 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 23:40:59 hmm... perhaps this issue is deeper than I thought. 23:41:42 Older SBCLs (a few weeks ago) don't hang, but they also give an ; Evaluation aborted on #. error when trying to asdf:load flexi-streams 23:42:41 any other (indirectly even) flexi-streams around? 23:59:00 <|3b|> slyrus: do you use dedicated output stream in slime?