00:39:51 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Quit: Leaving.] 00:55:31 -!- Krystof [~csr21@81.174.155.115] has quit [Ping timeout: 240 seconds] 01:09:43 Krystof [~csr21@csrhodes.plus.com] has joined #sbcl 01:09:43 -!- ChanServ has set mode +o Krystof 02:44:02 -!- nyef [~nyef@pool-70-109-147-129.cncdnh.east.myfairpoint.net] has quit [Quit: G'night all.] 02:47:26 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds] 05:00:57 -!- Fare [~Fare@ita4fw1.itasoftware.com] has quit [Quit: Leaving] 05:28:33 -!- rbarraud [~rbarraud@118-92-1-3.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 250 seconds] 05:43:01 hmm... perhaps I should ask this here instead: argh... where does this Not an absolute pathname #P"~/.clc/systems/" error when building sbcl contribs come from? 05:52:13 slyrus_: global c-l-c install + asdf2. 05:52:27 nyef posted on the ML on that topic. 05:53:20 yeah, we were just talking about this on #lisp. I forgot I had clc installed, thanks to sbcl depending on it (?!??) in the ubuntu package 05:53:51 still, this will prove to be an annoyance as now if someone does: 05:53:54 1) sudo apt-get install sbcl 05:54:00 2) 05:54:05 3) 05:54:07 it will break 05:54:45 I think this needs to be fixed. does anyone actually expect asdf to read something from /etc/common-lisp? 05:58:08 <_3b`> having a configurable system install path seems reasonable... having it break by default is a problem though :) 06:02:47 <_3b`> ignoring it during build as suggested earlier is probably a good idea too 06:07:34 I still don't know by which mechanism could anything be installed into ~/.clc 06:08:14 does anyone actually _use_ clc, apart from putting up with it because packages depend on it? 06:15:19 <_3b`> i think most of the #lisp community actively avoids it, but there seemed to be a reasonable number of people using os provided lisp libs in xach's survey 07:16:36 rbarraud [~rbarraud@118-92-1-3.dsl.dyn.ihug.co.nz] has joined #sbcl 07:43:29 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 07:43:29 -!- ChanServ has set mode +o nikodemus 07:47:18 -!- Krystof [~csr21@csrhodes.plus.com] has quit [Ping timeout: 240 seconds] 07:58:56 good morning 08:35:26 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 09:27:35 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 265 seconds] 09:30:39 stassats [~stassats@wikipedia/stassats] has joined #sbcl 10:13:56 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 10:37:08 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 10:53:12 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 10:53:59 nikodemus [~nikodemus@cs181058025.pp.htv.fi] has joined #sbcl 10:53:59 -!- ChanServ has set mode +o nikodemus 11:01:31 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 11:02:59 Krystof [~csr21@158.223.51.76] has joined #sbcl 11:02:59 -!- ChanServ has set mode +o Krystof 11:44:04 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 11:57:13 -!- rbarraud [~rbarraud@118-92-1-3.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 245 seconds] 12:01:17 mega1_ [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 12:01:17 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Read error: Connection reset by peer] 12:01:22 tcr [~tcr@89-251-198-185.chess.managedbroadband.co.uk] has joined #sbcl 12:25:47 -!- tcr [~tcr@89-251-198-185.chess.managedbroadband.co.uk] has quit [Ping timeout: 260 seconds] 12:54:30 tcr [~tcr@89-251-198-185.chess.managedbroadband.co.uk] has joined #sbcl 12:58:22 -!- Krystof [~csr21@158.223.51.76] has quit [Ping timeout: 272 seconds] 13:18:10 -!- tcr [~tcr@89-251-198-185.chess.managedbroadband.co.uk] has quit [Ping timeout: 252 seconds] 13:34:39 Krystof [~csr21@158.223.161.73] has joined #sbcl 13:34:39 -!- ChanServ has set mode +o Krystof 13:39:38 -!- Krystof [~csr21@158.223.161.73] has quit [Ping timeout: 264 seconds] 13:43:42 Krystof [~csr21@158.223.161.73] has joined #sbcl 13:43:42 -!- ChanServ has set mode +o Krystof 14:19:15 kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 14:22:56 -!- Krystof [~csr21@158.223.161.73] has quit [Ping timeout: 276 seconds] 14:31:22 tcr [~tcr@89-251-198-185.chess.managedbroadband.co.uk] has joined #sbcl 14:38:25 Krystof [~csr21@158.223.161.73] has joined #sbcl 14:38:25 -!- ChanServ has set mode +o Krystof 14:43:06 nyef [~nyef@pool-70-109-147-129.cncdnh.east.myfairpoint.net] has joined #sbcl 14:43:14 G'morning all. 14:46:21 heya 14:48:48 I notice that your list of tutorial projects seem centered around web development, and not local UI stuff. 14:49:05 yeah 14:49:37 And certainly doesn't have anything for OpenGL or audio and such. 14:49:37 i suppose i should pick a gui-kit or two as well 15:05:15 -!- tsuru [~charlie@c-174-50-217-160.hsd1.tn.comcast.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 15:09:03 -!- nikodemus [~nikodemus@cs181058025.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 15:26:15 tsuru [~charlie@c-174-50-217-160.hsd1.tn.comcast.net] has joined #sbcl 15:27:13 -!- tcr [~tcr@89-251-198-185.chess.managedbroadband.co.uk] has quit [Quit: Leaving.] 16:00:32 -!- Krystof [~csr21@158.223.161.73] has quit [Ping timeout: 265 seconds] 16:15:48 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 16:16:45 Fare [~Fare@ita4fw1.itasoftware.com] has joined #sbcl 16:18:34 Blkt [~user@dynamic-adsl-94-37-236-50.clienti.tiscali.it] has joined #sbcl 16:37:03 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 16:37:30 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 17:25:34 what happened to SBCL 1.0.43? 17:25:54 In what sense? 17:26:16 I see from www.sbcl.org that the latest version written on the main page is 1.0.42 17:26:28 Page probably wasn't updated. 17:26:44 I can assure you, I built 1.0.43.49 last night. 17:26:46 I thought I saw it updated a few days ago, well nvm 17:26:57 I didn't upload that page, didn't realize the page update script was updating more than the download page 17:26:58 good then, I was just curious 17:27:40 Maybe the script should use rsync or something, make sure it uploads everything it updates? 17:54:32 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 17:55:29 Dear SBCL committers ... would a patch be taken if it extends defstruct by another key parameter? 17:55:40 I'd like to provide a :default-instance-form 17:55:48 and what would that do? 17:56:52 So that eg. (defstruct (state :default-instance-form *state*) host ip port) would make accessors like (defun host (&optional (inst *state*)) ...) 17:57:26 That would be useful eg. for hunchentoot, where nearly every accessor function for *REPLY*, *REQUEST*, and so on has the special variable optional 17:57:46 I'd need that for some things of my own, too - and would like to get that upstream 17:58:01 as I believe it's useful to others, too 17:58:28 pkhuong: any opinion? 17:58:34 seems very niche. 17:58:49 Just generate wrappers with a macro. 17:59:43 How would you call the macro? 18:00:15 Well, I thought about the macro ... but hunchentoot needs that for a lot of functions. And some others might find that useful, too. 18:01:01 it doesn't seem useful enough to be included as an extension to CL. 18:01:05 but you can write a (defmacro defstruct-with-default-instance ...) 18:01:18 tcr: with a conc-name, a default value, and a set of slot names. 18:01:36 s/call/name/ 18:02:01 tcr: frobnicate-struct-accessors. 18:02:02 foom: Why is the threshold for extensions so high? 18:02:30 tcr: because SBCL attracts standard nazis. ACL is that way ;) 18:02:42 such a treshold doesn't need to be very high to exclude this one 18:03:10 Seriously, I'd like to have as little as possible in CL itself, and a lot of useful stuff in contribs. 18:05:24 We're talking of extensions of CL which I understand to be stuff that exactly can't go to a contrib 18:06:04 but you can write an extended defstruct macro easily 18:06:35 and name it defstruct* 18:06:37 Nobody debates that 18:06:47 or even generate the wrappers outside the struct definition. 18:06:54 Looking at the hunchentoot sources I see this ... 18:07:12 (defun headers-out* (&optional (reply *reply*)) 18:07:13 "doc..." 18:07:16 flip214: hunchentoot will ever be sbcl-only? 18:07:16 (headers-out reply)) 18:07:38 No ... but if that really proves useful (as I think it would), others might take it, too ... 18:07:47 haha 18:07:51 Sometimes it could be in CLTL3 18:07:56 *Sometime 18:08:15 hah 18:08:34 Of course I can write a macro ... but I'm not sure what optimizations, compiler magic and so on happens in defstruct to make slot access fast 18:08:43 I'd have to replicate that 18:08:55 *That's* what bothers me a bit 18:09:11 foom: So an extension is not above the threshold of usefulness if it can be written by macros on top of CL? 18:09:32 flip214: you'd write a macro that expands to CL:DEFSTRUCT 18:09:33 tcr: I wouldn't say that. 18:10:14 foom: I'd have guessed so. :-) So what's the threshold like? 18:11:37 a value function based on the helpfulness of the addition, the ease of working around not having it, the hurtfulness of a nonportable extension, the pain in implementing it, and maybe some other things too. :) 18:11:38 variable 18:12:08 extending a well-specified but already too byzantine standard form would have a high threshold 18:12:41 tcr: As a contrib, yes. generate a defstruct, remove the defined accessors, redefine them, and hope for all optimizations ;-( 18:12:42 compared to adding something that the standard doesn't consider at all 18:13:12 flip214: Redefine? Think harder. 18:13:21 if you're worried about speed, those optional arguments are going to be a bad idea anyway 18:13:33 beg your pardon? 18:14:00 jsnell: why? Should be just a special-variable access 18:14:06 not slower than writing it out 18:14:52 implementations that don't inline accessor calls are now going to replace it with something even slower 18:15:12 flip214, (shadow defstruct) is this way. 18:15:28 pointless micro-optimization? maybe, but so is the worry about all the magical optimization that the implementation defstruct would do 18:16:03 if one weren't into microoptimization, one would use defclass, anyway. 18:16:19 oh, one more quality I wish could be taken into consideration, but realistically is hopeless right now: the likelihood of getting other implementations to do the same thing. 18:17:54 jsnell: Most of CL is byzantine. But then what does byzantine mean? :-) 18:18:15 ... There's nothing like (SETF FUNCTION) that would affect local function bindings, is there? 18:18:22 s/local/lexical/ 18:19:14 nyef: thankfully no 18:19:22 Oh, good. 18:19:49 I didn't think there was, but it's the sort of thing that would be /really bad/ for my current state of mind if there was. 18:20:46 on another note...I was thinking on how and why eq hashtables can't be implemented in "userspace", and thought of a fairly simple extension would make it possible 18:20:54 A user-resettable indicator on a vector saying whether the GC changed any of the pointers in the vector. 18:21:52 sbcl does that...? or you mean a standard thing? 18:22:20 sbcl doesn't do that in a way that user code can use it 18:22:28 sbcl does that for its own internal hashtable impl 18:23:11 oh, is the sekret flag not set on vectors that aren't part of a hash table? 18:23:29 the sekret flag is actually set on the hashtable object itself 18:24:22 "hash_table = (struct hash_table *)native_pointer(where[2]);" then later "hash_table->needs_rehash_p = T;" 18:24:58 there are references wandering about to a flag set on vectors...dead code? 18:27:20 i think so. All that code changed pretty radically back 2-3 years ago. 18:28:17 it's still there for weak hashtables 18:29:38 oh, now I remember. it's the other way around. the flag doesn't say "the gc did something funny to this vector" it's a request for the gc to do the funny stuff 18:32:53 huh. I don't understand scav_vector: on a normal vector it returns "1" without looking at any of the contained data? why doesn't it have to iterate over its contents? 18:33:40 that skips over the header 18:33:50 and then the scavenger continues walking through the contents 18:34:55 oh, right, because it already has the length of the vector 18:36:11 does the scavenger skip elements past the fill-pointer? 18:36:18 So, going back to the ftype-declaration thing, and the restriction on the list form of FUNCTION type specifiers being used for discrimination, my current thought is that the prohibition on using the specifier for discrimination is for the user, not the implementation. 18:36:19 no, that would be invalid if it did 18:36:49 invalid? are you allowed to read elements past the fill-pointer and get predictable results? 18:36:58 foom: It returns 1, because all of the subsequent slots are boxed, and the scavenger will do the right thing when it sees them. 18:36:58 Fare: yes, with aref. 18:38:11 foom: It returns the number of slots to skip, IIRC, meaning that more complicated objects such as CODE-OBJECTs get to re-call into scavenge() to hit their boxed slots and then return their total length. 18:38:17 nyef: right. 18:38:40 ... And now I see jsnell's explanation. 18:39:48 :) 18:41:46 I guess by making the support generic, independent of a hashtable impl, you lose the ability to check that the object being moved actually did have a hashcode computed from its memory location. 18:41:51 So that's not great. 18:42:07 and I think you still need a portable without-gcing as well? 18:42:49 why? 18:43:11 you reset the flag before you start looking at stuff 18:43:40 so if the gc runs while you're munging things and re-sets the flag, you'll need to run again 18:44:09 I was thinking of the mutation end of things, but maybe that can be solved by sufficient retries as well 18:45:43 if the GC isn't checking against the hash values vector or the hashtable object itself, i don't think there's a race there 18:46:34 all it's doing is rewriting pointers in a vector and setting a flag in the vector header saying it's done so; it might set the flag right before you replace the pointer with a new object, but that's okay. 18:48:49 hmm... and the multiple race with multiple readers can be solved by having an extra counter telling how many times the flag has been reset 18:49:57 Hm? I don't see why you'd need a counter. 18:51:20 thread a is doing a lookup, gc happens, thread b starts doing a lookup, does a rehash, thread a doesn't find the entry, checks the flag, finds that the vector doesn't have the magic flag on 18:52:12 rehash makes a new vector currently; if it still did that wouldn't be a problem, because you wouldn't clear the flag unless it was a false alarm 18:53:07 we allocate new vector for a rehash?! 18:54:03 whew, no we don't. a gc-induced rehash will do it in place 18:55:24 oh, do we? okay. :) 19:19:40 foom: I thought about it; you can even use gc-epoch. But you need to inhibit GC in the general case :\ 19:19:55 I'd much rather have constant eq hashes 19:20:50 pkhuong: yea 19:21:39 if it wasn't for the darn cons cells, that'd be pretty easy. 19:21:42 "constant eq hashes" ? 19:22:06 you mean, an additional field for a hash, as in java? 19:22:07 foom: I've been thinking a per-generation hash table might work better 19:22:14 Fare: right. 19:22:15 Fare: doesn't have to be an actual field. 19:22:32 java doesn't actually allocate a field for it until the object is both a) asked its identityHashCode() and then b) moved. 19:22:48 but pretty much, yes. Rehashes caused by GC can kill your actual (amortised) performance. 19:22:48 but that means you need to have 2 bits in a header 19:23:15 which should be fine, except for stupid conses. 19:23:26 foom: either you're moving eagerly and need a read barrier, or you need that extra bit to save that information, or you need to always compute on a move. 19:23:27 foom: auxiliary bitmap 19:23:50 foom: so it gets a hash code based on its address when the hash code was first computed? 19:23:55 why two bits? No bebop to determine the new generation? 19:23:56 pkhuong: yeah. 19:24:06 or is it stored in an auxiliary table for that? 19:24:21 mm... Not sure how I feel about that: what happens with the nursery? 19:24:39 Maybe it adds a generation counter too it too these days 19:24:42 I guess you can mix that with a clock-based counter 19:24:56 Back in the old days it was actually just the object's address, the first time you asked 19:25:30 If you're going to have header magic in conses, you can implement CDR-CODING... 19:26:17 (wait, cdr coding requires a read-barrier if you can side effect the cdr) 19:26:28 Fare: it's much simpler than cdr coding 19:28:07 might make sense to always put cons cells on their own memory page, with a dedicated per-page bitmap area of the right size to hold the page-full-of-cons data 19:29:24 foom: I'd do it that way for everything. 19:32:08 nikodemus [~nikodemus@cs181058025.pp.htv.fi] has joined #sbcl 19:32:08 -!- ChanServ has set mode +o nikodemus 19:32:40 bebop + side table is fine -- but doesn't that play awfully with caches? 19:33:07 -!- Kaer [b@c-cfcee253.97-16-64736c12.cust.bredbandsbolaget.se] has quit [Ping timeout: 240 seconds] 19:33:46 what are you referring to by "bebop"? 19:34:02 bibop? 19:34:11 (BIg Bag Of Pages?) 19:34:48 nikodemus, thanks for 1.0.43.52 19:34:55 yeah, bibop 19:35:40 Krystof [~csr21@csrhodes.plus.com] has joined #sbcl 19:35:40 -!- ChanServ has set mode +o Krystof 19:35:47 bibop = associating GC metainformation about allocated data based on high bits of the address 19:36:09 why would that play horribly with caches? 19:36:21 you hardly ever need to touch the gc metadata 19:36:33 foom: temporal locality. 19:36:56 Fare: happy to be of service 19:37:10 Stuff allocated at the same time tends to be accessed together. Bump allocation tend to make spatial locality correlate with allocation order. 19:39:57 but I don't see why you need more than two kinds of pages: one for conses, and one for other objects. You should be able to stash a couple bits in the object header for other objs. 19:40:08 pkhuong, as long as there are not too many different kinds of pages, as the main metadata structures fit in cache, that should work. And/or you could do bump allocation for the nursery, bibop after GC. 19:40:34 bibop can also be fun for read or write barriers. 19:59:11 skalawag` [~user@c75-111-102-202.amrlcmta01.tx.dh.suddenlink.net] has joined #sbcl 20:00:41 -!- skalawag [~user@c75-111-102-202.amrlcmta01.tx.dh.suddenlink.net] has quit [Ping timeout: 255 seconds] 20:06:46 Kaer [b@c-6bcfe253.97-16-64736c12.cust.bredbandsbolaget.se] has joined #sbcl 20:27:18 -!- flip214 [~marek@unaffiliated/flip214] has quit [Ping timeout: 240 seconds] 20:53:29 rbarraud [~rbarraud@118-92-1-3.dsl.dyn.ihug.co.nz] has joined #sbcl 20:57:29 -!- skalawag` is now known as skalawag 21:11:27 *cmm* remembers how he had to write his own GC to replace Boehms in a project 10 years ago, because BGC's way of separating objects into different pools based on size killed performance of several critical inner loops 21:11:56 not that you'll necessarily get that with just 2 pools, but fwiw 21:13:55 cmm: allocation pools and bulk deallocation! 21:14:12 cmm: Btw, since you appear to know how boehm works, what are its object alignment guarantees actually? 21:15:00 I've read somewhere that for sizes being "small powers of two", the alignment is the same power of two - but what is small?.. 21:15:03 angavrilov: 10 years, remember? back then in was 16 bytes, but I may be lying 21:15:24 angavrilov: I believe that's configurable, actually. 21:15:41 that's my recollection too 21:16:02 dybvig's scheme in his don't stop the bibop paper always appealed to me, but i wonder how it performs on modern hardware 21:16:12 My interest here is alignment of SSE objects in ecl - so far it seems to work, but I don't have any proof that it is supposed to 21:16:41 angavrilov: if it doesn't you can file a bug. malloc is supposed to be aligned enough for sigbus-free operation. 21:54:54 does head (1.0.43.52) build for people? i get errors in the contribs like "Not an absolute pathname #P"~/.clc/systems/"" 21:55:06 i seem to remember a bug about this in lp, trying to find it 21:55:33 it does build for me, though i have no clc 21:55:49 i think it's related to asdf2 reading clc config 21:57:19 yeah, it's some asdf2 issue, something is missing from hte build scripts of contribs... but i can't find it in lp, maybe it was in a mail 21:59:11 found it: https://bugs.launchpad.net/sbcl/+bug/659105 21:59:35 attila_lendvai: New as of... yesterday morning, perhaps? 22:00:01 nyef: yep, thanks for the bug entry! 22:00:14 I'd argue that this is also a debian bug 22:00:19 (Builds fine for me, now that I've destroyed the last remnants of clc on my system. But you might not want to do that.) 22:00:25 fe[nl]ix: Probably is. 22:00:35 apt-get remove should default to always purging configuration files 22:01:07 Not even that, the clc package configuration files should bloody work with SBCL out of the box. 22:01:18 i'm used to always typing aptitude purge 22:01:20 currently, if I uninstall a package without --purge, I have to reinstall it and then --purge it 22:01:24 so annoying 22:01:25 i don't rely on package installed sbcl's (err, except when building sbcl... :) let's install a built one and get rid of clc 22:01:32 fe[nl]ix: dpkg --purge 22:01:50 Why would you have to reinstall it? 22:02:12 my bad, I think stassats has it right 22:02:30 attila_lendvai: The problem is that, even without a host SBCL, if the CLC config files are around they can screw things up. 22:03:23 clc excels at this 22:03:28 yeah, i know. my problem is that uninstalling clc will get rid of sbcl, too. so i need to install one into /usr/local/ but i can't build one currently, so i need to wipe clc config by hand 22:03:47 it _is_ a debian bug: older asdfs just didn't complain about that line, but it still didn't do what it was ment to do 22:05:08 It's also an SBCL bug: The file shouldn't be getting read in while building contribs. 22:05:18 point 22:05:27 but all our grumbling about clc aside, given the number of people who install sbcl using package managers, obviously they are doing something right 22:06:16 nikodemus: it's convenient to apt-get install sbcl and have it around for building different versions... but i'll stop doing that now 22:06:38 nikodemus: btw, i've sent you a mail about how the deadlock branch fails to build 22:07:13 attila_lendvai, it's a problem with CLC and ASDF 2.009 22:07:20 attila_lendvai, CLC 7.5 fixes it. 22:07:33 *attila_lendvai* looks for updates 22:08:15 (or removing CLC) - not sure CLC 7.5 and ASDF 2.009 have been uploaded to debian unstable or experimental, though. 22:08:35 attila_lendvai: i just got it to build on darwin -- except that the reporting was messed up 22:08:37 in the mean time, comment out the stuff in /etc/common-lisp/source-registry.conf.d/ 22:08:49 i'm on ubuntu, update is not there yet, so i'll just get rid of them... 22:12:16 ASDF should probably be more robust in the face of misconfigurations -- only issuing a warning or so. 22:13:06 blabla [~lisps@BSN-61-55-57.dial-up.dsl.siol.net] has joined #sbcl 22:19:51 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 22:20:09 a change in ASDF:COMPILE-FILE-PATHNAME* already broke my code (http://dwim.hu/gitweb/gitweb.cgi?p=slime;a=commitdiff;h=f733ec8d09b6d72ec58d9d88ee3e5733b5cbc8b9) 22:22:20 -!- blabla [~lisps@BSN-61-55-57.dial-up.dsl.siol.net] has quit [Quit: blabla] 22:22:50 attila_lendvai: ok, the stuff at github now seems to build on linux too. aside from that very much untested 22:23:24 nikodemus: thanks! (i'll probably only be able to test it in 1-2-3 days) 22:45:22 good night 22:45:41 -!- nikodemus [~nikodemus@cs181058025.pp.htv.fi] has quit [Quit: Leaving] 23:02:28 dj [~Patron@rrcs-24-39-79-115.nys.biz.rr.com] has joined #sbcl 23:02:46 -!- dj [~Patron@rrcs-24-39-79-115.nys.biz.rr.com] has left #sbcl 23:14:12 kclifton_ [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 23:15:54 -!- kclifton_ [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [Client Quit] 23:17:53 -!- kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [Ping timeout: 276 seconds] 23:20:00 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 23:30:21 attila_lendvai, what change broke your code how? 23:32:11 Fare: if you look at the diff, i use c-f-p* to extract the binary translation config from asdf. i think lispize-pathname is new (or the turename call?), and adds a :type "lisp" unconditionally, and i got an error form sbcl's pathname code that :type is non-nil while :name is nil. iirc from turename... 23:32:35 btw, that's a rather useful patch for ASDF head, i'll try to advertise it back into HEAD 23:33:51 attila: oh. But that's not the contract of that function. 23:34:02 The function should be called with the name of a file. 23:34:11 that may or may not be translated. 23:34:25 I suppose I could special case it to also accept directories. 23:34:45 you have a patch for ASDF? 23:35:11 Fare: i know, but there's no api to achive what i want. since then i've updated that patch, just not recorded it because amending a non-top patch with git is annoyingly complicated 23:35:33 Fare: nope, i've patched the way i call it 23:37:28 maybe you should only be calling c-f-p* when you have a filename. 23:37:37 OR, you may pass it a dummy filename. 23:37:42 then strip the file component 23:38:04 Fare: it's swank, it works different... :) i do the dummy kludge 23:39:14 although it would make sense to refactor swank-loader.lisp to call it every time on each file... maybe i'll do that eventually 23:39:21 What I mean is, you could refactor swank, so instead of merge-pathnames, you call a new function translate-pathnames that either does the merge-pathnames or the asdf call. 23:39:32 yep 23:40:08 i'll do that. i just try to minimize the intrusion to maximize the chances of the patch being accepted 23:40:17 I wonder if it's good that ASDF fails early rather than be lenient about configuration errors. 23:40:28 I think ideally, it should fail early, but with a better error message. 23:40:32 but your suggestion makes so much more sense, that i ignore the possible consequences of diverging from HEAD 23:41:43 if only asdf2 were universally available, you could just require it, use it, and drop swank-loader. 23:42:58 hah! try to sell that on swank-devel... :) 23:43:56 well, asdf2 is NOT yet universally there. 23:44:38 asdf was universally available for a long time... and i even had trouble getting in patches that fix the asdf stuff. but moving everything to asdf... out of question. 23:44:41 that said, swank could be delivered with asdf, and if require fails or is too old, load the one that comes with it. 23:44:43 oh well. 23:44:45 Fare: I already had dropped swank-loader with ASDF1 23:45:13 there was a good reason not to deliver asdf with swank, back when ASDF couldn't be upgraded. 23:45:26 Now that it can (bugs pending), that reason becomes mooter. 23:45:51 fe[nl]ix, I had at one point, then stopped because of the maintenance hassle. 23:48:03 Fare: http://repo.or.cz/w/gentoo-lisp-overlay.git/blob_plain/HEAD:/app-emacs/slime/files/9999/swank.asd 23:49:45 fe[nl]ix, why no-load ??? 23:50:22 because contribs are loaded by slime(the emacs side) through swank:swank-require 23:51:07 boggles 23:51:24 the proof is in swank.lisp 23:51:36 does your swank-require then use the asdf component, or is this thing just for fun? 23:52:57 the former 23:53:24 http://repo.or.cz/w/gentoo-lisp-overlay.git/blob/HEAD:/app-emacs/slime/files/9999/gentoo-module-load.patch 23:53:32 I've been using that patch and swank.asd for a few years now 23:53:33 works well 23:54:42 it's just that with the old ASDF, swank-fasl-pathname was a bit kludgy 23:54:47 see line 78 23:55:00 fe[nl]ix: darn! i've wasted so quite some time with the swank+asdf headaches... your patches really should go into HEAD, but it requires more voices. mine is pretty much blacklisted on slime-devel already... 23:56:02 I'd rather not start a fight with Heller :D 23:56:17 there are more entertaining ways to waste my time 23:58:20 very true! but still... i've also got quite useful patches in my branch: http://dwim.hu/gitweb/gitweb.cgi?p=slime;a=shortlog but i don't want to start fighting and/or quietly committing some of them without any backing, because it'll really be a waste of time then... 23:58:20 Fare: I'm waiting for Clozure 1.6, then switch all Gentoo CLs to ASDF2 23:59:30 attila_lendvai: I wouldn't mind forking slime, but I don't have time to take care of it