00:05:40 ebzzry [~ebzzry@203.213.202.186] has joined #sbcl 00:29:43 tsuru [~charlie@c-174-50-217-160.hsd1.tn.comcast.net] has joined #sbcl 00:38:54 Lovely. "# is wired to a location that it conflicts with." 00:51:36 -!- Blkt [~user@dynamic-adsl-94-37-236-50.clienti.tiscali.it] has quit [Quit: Error: do not makunbound t please!] 01:01:39 *nyef* ditches the idea of coming up with a usable TN for what he's trying to do and creates a new VOP for the special case instead. 01:08:47 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has left #sbcl 02:28:54 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 02:38:40 -!- nyef [~nyef@pool-64-222-178-106.man.east.myfairpoint.net] has quit [Quit: G'night all.] 03:24:05 kclifton [~kclifton@S010600123ff34d7d.cg.shawcable.net] has joined #sbcl 04:05:19 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Ping timeout: 260 seconds] 04:20:04 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 04:20:06 m_bohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 04:21:37 -!- m_bohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Read error: Connection reset by peer] 04:21:39 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Client Quit] 04:22:22 hargettp [~anonymous@96.237.121.128] has joined #sbcl 04:22:43 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 04:32:51 -!- hargettp [~anonymous@96.237.121.128] has quit [Quit: hargettp] 04:38:05 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 04:56:43 -!- rbarraud [~rbarraud@118-92-1-3.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 240 seconds] 05:26:38 -!- kclifton [~kclifton@S010600123ff34d7d.cg.shawcable.net] has quit [Quit: kclifton] 06:27:43 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 06:35:13 rbarraud [~rbarraud@118-93-70-162.dsl.dyn.ihug.co.nz] has joined #sbcl 06:55:30 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 06:55:30 -!- ChanServ has set mode +o nikodemus 07:21:34 -!- rbarraud [~rbarraud@118-93-70-162.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 07:22:31 rbarraud [~rbarraud@118-93-70-162.dsl.dyn.ihug.co.nz] has joined #sbcl 07:29:43 -!- rbarraud [~rbarraud@118-93-70-162.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 260 seconds] 07:36:33 Krystof [~csr21@cpc1-bour2-0-0-cust414.15-1.cable.virginmedia.com] has joined #sbcl 07:36:33 -!- ChanServ has set mode +o Krystof 07:47:45 -!- cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has quit [Remote host closed the connection] 07:48:02 cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has joined #sbcl 08:12:49 -!- Krystof [~csr21@cpc1-bour2-0-0-cust414.15-1.cable.virginmedia.com] has quit [Ping timeout: 245 seconds] 08:29:43 Krystof [~csr21@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 08:29:43 -!- ChanServ has set mode +o Krystof 08:38:12 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 08:56:35 rbarraud [~rbarraud@118-92-7-167.dsl.dyn.ihug.co.nz] has joined #sbcl 09:16:41 -!- rbarraud [~rbarraud@118-92-7-167.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 265 seconds] 09:37:21 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 10:11:53 hargettp [~anonymous@96.237.121.128] has joined #sbcl 10:22:52 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Read error: Connection reset by peer] 10:24:24 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 10:25:02 ASau` [~user@77.246.230.186] has joined #sbcl 10:55:24 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 11:08:17 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 12:27:51 nikodemus [~nikodemus@cs181058025.pp.htv.fi] has joined #sbcl 12:27:51 -!- ChanServ has set mode +o nikodemus 13:17:55 stassats [~stassats@wikipedia/stassats] has joined #sbcl 13:47:18 -!- gnooth [~test@ip98-176-79-151.sd.sd.cox.net] has quit [Read error: Operation timed out] 14:06:03 nikodemus: I've got a deadlock alert! :) 14:06:06 ; Evaluation aborted on #. 14:06:14 but it's rather useless... no backtrace, nothing... 14:06:50 do you get the condition object, or is it lost? 14:07:12 let me try again, I may have automatically pressed 'q' in sldb 14:07:18 nope 14:07:26 i can send you a patch that adds the chain of locks to the simple-error 14:07:27 all I get is the above comment line 14:07:56 so, I do *not* get a presentation of the simple-error in slime, only a comment printed 14:08:02 i'll make coffee and improcve the reporting 14:08:08 improve, even 14:08:35 I have no idea who's eating up the error, but I'm utterly annoyed by ignore-errors usages (including the recent sbcl compiler changes that turn errors into printf's) 14:08:53 well, recent as in a few months ago 14:09:29 attila_lendvai: i could be some defensive programming in slime in case the error occurs deep in the bowels of the slime debugger, or something 14:09:40 it could, even. (just guessing) 14:09:57 yep, it's in slime.el, straight in slime-eval-async 14:10:11 slime-rex sends a :abort to emacs 14:10:44 i'll ask you later about the printf thing, because i'm not sure i follow -- but i'll get the chain of locks first 14:12:40 nikodemus: It's because of the contrib split 14:12:53 that hinders deep integration of all parts 14:13:07 or makes it sometimes difficult to achieve so you just don't bother 14:14:08 Printing the error that resulted in ;Evaluation aborted is a recent thing, I asked stassats to add it 14:14:22 attila_lendvai's at fault at quitting sldb too quickly 14:14:42 Blkt [~user@160.80.132.14] has joined #sbcl 14:15:00 tcr: nope, I don't do anything, and all I get back is the pasted message 14:15:06 slime-repl-show-abort 14:15:39 I'm looking into changing it so that it gives back a presentation of the confition, not just a printout 14:15:51 especially with prin1-to-string 14:16:02 it's not just prin1-to-string 14:16:57 Why does sldb not pop up? 14:18:30 the whole thing is initiated by an asdf operation. asdf might be interfering here... 14:23:37 argh, I hate when I need to enter a recursive fixing session, especially when it's at the 3+ level... 14:23:51 (setf swank::*debug-on-swank-protocol-error* t) didn't change much 14:24:09 I'll try with stock slime just in case (although I haven't patched anything around there) 14:25:03 -!- Blkt [~user@160.80.132.14] has quit [Ping timeout: 265 seconds] 14:41:32 nikodemus pasted "better deadlock reporting for attila" at http://paste.lisp.org/display/115581 14:42:07 slime behavior is the same on slime HEAD 14:42:48 *attila_lendvai* tries 14:45:51 nyef [~nyef@pool-64-222-178-106.man.east.myfairpoint.net] has joined #sbcl 14:45:57 G'morning all. 14:46:03 hi nyef 14:46:15 hey nyef 14:46:18 attila_lendvai: i don't think it'll matter, but just in case, try on 116177f5edb26e1eeeda248feb72bc3601256c99 14:46:24 kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 14:46:35 boinkor git commit 14:52:52 stassats: even worse, I only got: "; Evaluation aborted." 14:53:24 well, that was the commit before i introduced that printing, so it wasn't at fault 14:55:32 nikodemus annotated #115581 "spinlocks too, barf the chain of locks to stderr before reporting the error" at http://paste.lisp.org/display/115581#1 14:55:51 stassats: interesting, I've changed print1-to-string to princ-to-string and there's a printing error... in this situation sldb comes up. 14:56:14 nikodemus: the printing error is: The value T is not of type LIST. 14:56:34 nikodemus: Why throw the chain of locks to stderr instead of making them part of the condition object? 14:57:27 nyef: in case like attila is having right now the object is lost in the fray 14:57:28 nyef: I guess due to a slime bug hindering printing the condition properly. but that bug should be fixed, too... 14:57:39 aarg 14:57:49 nikodemus: not anymore, I've changed it to princ-to-string... 14:58:00 prin1-to-string was intentional 14:58:20 attila: ((eq self other-thread) nil) 14:58:26 that message isn't supposed to be a replacement for the debugger 14:58:44 So, I found out something fun this morning. Unused VOP :TEMPORARY variables are STYLE-WARNINGs on the host, and WARNINGs in the XC. 14:58:45 add the NIL to the line in CHECK-DEADLOCK/DEADLOCK-CHAIN 14:58:51 stassats: I know, I'm not planning to push it 14:59:30 stassats: what's the logic in eval-for-emacs? shouldn't it contain the signalled errors? is it intentional that the handler-bind lets it fall through? 15:00:04 it falls through to *debugger-hook* 15:00:13 i think 15:00:32 and *debugger-hook* initiates sldb etc. 15:00:42 *attila_lendvai* checks 15:01:23 -!- Krystof [~csr21@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Ping timeout: 245 seconds] 15:04:32 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Excess Flood] 15:05:16 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 15:08:27 nikodemus: I lost you at your last comment about "add the NIL..." 15:09:08 ok, i'll paste a fixed version 15:14:00 Actually what might be better than the ;Evaluation aborted thingie, is to print ;Entering debugger on and go back to a normal ;Evaluation aborted 15:14:09 attila annotated #115581 "make-random-deadlocking-threads" at http://paste.lisp.org/display/115581#2 15:14:52 attila annotated #115581 "make-deadlocking-threads" at http://paste.lisp.org/display/115581#3 15:15:21 does it work without "def function"? 15:15:25 nikodemus annotated #115581 "one that i actually tested" at http://paste.lisp.org/display/115581#4 15:18:12 the output could still be improved, as it doesn't make it explicit that the next line always shows the lock the owner of the previous one was waiting for 15:18:55 tcr, stassats: I think the slime issue that the debugger doesn't come up is due to a recursive error 15:19:05 and it isn't actually nice to depend on the mutex printing the owner, since if another thread unwinds that information may be lost by the time the error is printed 15:19:13 what might also interfere is that it comes from inside compile-file, which muffles the error on sbcl... ? 15:19:48 So... bind *break-on-signals* around the compile-file? 15:21:38 I think swank should guard against nested errors while it's in a crucial part of sldb... I've done with-layered-error-handlers to deal with errors while logging/debugging: http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.util;a=headblob;f=/source/error-handling.lisp 15:22:25 It does guard against recursive errors 15:22:46 it has 3 layers of error handling, and falling back to less and less smartness... on the 3rd level it's full of ignore-errors, etc 15:24:02 on the 1st level it calls the user error handler hook, on the second it prints the nested and the original error, on the third it tries to make a note at least that something happened and gives up 15:26:48 -!- ASau` [~user@77.246.230.186] has quit [Ping timeout: 245 seconds] 15:30:11 -!- Kaer [b@c-6bcfe253.97-16-64736c12.cust.bredbandsbolaget.se] has quit [Ping timeout: 265 seconds] 15:32:42 Does sbcl keep track of the dynamic-usage before the last gc? 15:39:25 nikodemus: this is what I got: 15:39:26 ; Evaluation aborted on Deadlock on # trying to acquire lock: 15:39:26 # 15:39:26 #. 15:40:06 I guess (free) is because of the unwinding... 15:40:48 nikodemus: shall I extend the error with info about the threads or you do it? 15:41:26 hrm, *inferior-lisp* has some more info... I paste it 15:42:18 attila annotated #115581 "the actual deadlock and the recursive error slime doesn't deal with" at http://paste.lisp.org/display/115581#5 15:43:48 i'm on it right now 15:44:15 nikodemus: what's the interpretation of this? repl-thread has the "world lock" and tries to acquire "buffer write lock" while the flush thread already has... what? it shouldn't have the world lock... 15:44:51 hrm! I remember having issues due to this: world lock is needed by the compiler, which is in turn needed to compile method cache entries 15:45:08 yep 15:45:47 the world lock granularity doesn't have to be nearly as massive as it is -- but shrinking it is somewhat intricate 15:48:52 nikodemus: a related thought: it'd be some form of solution to install a deadline into the flush thread and loop over if the deadline is reached. but the deadline detection code will eagerly signal an error, even though a deadline might have kicked the system 15:50:35 gnooth [~gnooth@ip98-176-79-151.sd.sd.cox.net] has joined #sbcl 15:51:55 *attila_lendvai* commits a few non-controversial slime patches 15:58:43 nikodemus annotated #115581 "prettier barfing" at http://paste.lisp.org/display/115581#6 16:01:43 attila_lendvai: i think this is another example why the correct timeout construct in a with-lock looks like (unless (with-lock (lock :timeout to) ...stuff-to-do-with-lock...) ...stuff to do with timeout...) or similar: don't propagate upwards unless the user explicitly requests it 16:02:07 most of the time when a local timeout is reasonable, there is also a local recovery strategy 16:02:34 true 16:03:19 nikodemus: so, any idea how to resolve the actual issue? include a bit of #+sbcl stuff to fill up the method caches with gray stream entires? 16:03:48 attila_lendvai: didn't get that far yet 16:03:50 just a sec 16:03:53 ok 16:04:30 ok, this is a lock ordering problem 16:05:21 buffer-lock and world-lock need to be always acquired in the same order 16:06:52 DanLentz [~danlentz@c-68-32-54-29.hsd1.nj.comcast.net] has joined #sbcl 16:08:08 since it's going to be hard to avoid pcl grabbing the world-lock by accident, the easiest fix is to grab world-lock always before grabbing the buffer-lock 16:08:22 ugly as hell, but should get rid of the deadlocks 16:11:19 nikodemus pasted "a really big hammer" at http://paste.lisp.org/display/115583 16:12:00 i didn't test that, but the more conservative alternative is to add :around method for stream-foo-bar methods grabbing locks which do the same 16:12:32 well, it's not something that should be checked in... 16:12:43 not that I have *any* other ideas... 16:13:13 but looking at slime, pretty much all the locks appear to be on gray streams -- so i don't think that should hurt too much 16:13:41 um, unless slime also does blocking input on them, of course 16:13:49 which would be bad with that lock... 16:13:55 nikodemus: it may mean that an asdf:load-system will have no output until the very end 16:14:32 i'll add revisiting *world-lock* to my TODO before the December release 16:15:13 remember that asdf wraps :around every operation with a with-compilation-unit... 16:16:04 yeah 16:17:50 iirc the only places that really need world-lock are type-system and globaldb updates -- the low levels are pretty easy to protect, but finding out the toplevel operation that needs to have a consistent view is tricky 16:18:25 eg. a single defclass should probably have a consistent view of the world while it is running... 16:20:18 -!- DanLentz [~danlentz@c-68-32-54-29.hsd1.nj.comcast.net] has quit [Quit: Colloquy for iPhone - http://colloquy.mobi] 16:30:48 DanLentz [~danlentz@c-68-32-54-29.hsd1.nj.comcast.net] has joined #sbcl 16:40:56 *nyef* sighs. 16:41:27 My first attempt at hacking an IR1 analysis pass, and the analysis results come out a good approximation of /backwards/. 16:43:44 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Remote host closed the connection] 16:46:07 -!- DanLentz [~danlentz@c-68-32-54-29.hsd1.nj.comcast.net] has quit [Quit: Colloquy for iPhone - http://colloquy.mobi] 16:47:04 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 16:51:55 nikodemus: STM? 16:58:09 Does SBCL keep track of the dynamic usage before the last gc? 16:59:30 -!- gnooth [~gnooth@ip98-176-79-151.sd.sd.cox.net] has quit [Read error: Operation timed out] 17:03:17 gnooth [~gnooth@ip98-176-79-151.sd.sd.cox.net] has joined #sbcl 17:08:28 pkhuong: i've had that thought, yes 17:08:43 i think i actually talked about this with you at sbcl-10 17:09:10 as in: your n-word-cas might be really nice for this 17:16:27 yeah... or just the seqlock based STM I'm playing with 17:16:43 really doesn't scale as nicely, but so much simpler, and works very well for read-mostly workloads 17:17:44 can i haz code? 17:38:24 nikodemus: , mostly seqlock.lisp 17:39:07 thanks! 17:39:43 Trying to move towards parallelizable builds? 17:40:15 trying to break up world-lock 17:40:55 Nice. 17:40:57 a seqlock would be like world-lock, but with optimistic parallel reads. 17:41:38 pkhuong: do you have any suggestions on what i should read to learn about automatic (dynamic) sharing violations? 17:41:53 mmm... automatic detection, i mean 17:42:03 what's a sharing violation? (: 17:42:53 good question :) 17:49:18 hm, actually i'm not so much interested in sharing violations (which i understand to be unlocked parallel writes/reads), but rather about finding out the correct level for transactions/atomic operations. how to ensure that if i break up a lock i don't break it up too fine -- if A calls B and C and I make B and C atomic but not A, but i should have 17:50:01 going to bed with your friend's wife behind his back? :) 17:50:42 are there any sensible approaches beynd "think hard" for getting this right, testing that it has been done right, or proving that something doesn't require / requires atomicity? 17:51:30 mm... 17:52:11 I guess we could use a single global lock, but log acquisition/release of virtual locks 17:52:26 and solve all of these patterns for a consistent order 17:55:25 oops, The value NIL is not of type SB-C::NODE. 17:55:41 Heh. 17:55:54 wasn't that fixed? 17:55:57 Isn't that one of the bugs in launchpad? 17:56:04 Not so far as I know. 17:56:18 (It's on my list to possibly investigate at some point in the future, though.) 17:56:36 lp 551227 17:56:37 https://bugs.launchpad.net/bugs/551227 17:57:47 at least it was in the code i didn't intend to write 18:03:39 ... Oh, right. This bug. 18:03:48 nikodemus: your Very Big Hammer gets rid of the quite reproducible deadlock 18:04:09 I've put it in my .swank.lisp for now 18:04:31 ok. i hope you won't get hangs while waiting for input :) 18:06:30 the deadlock stuff on github should now be up-to-date if someone else wants it 18:06:36 I'm actually a lot more comfortable working with IR1 after the past few days, even if I still don't have my current project working. 18:12:38 -!- nikodemus [~nikodemus@cs181058025.pp.htv.fi] has quit [Quit: time to go home] 18:21:08 -!- stassats [~stassats@wikipedia/stassats] has quit [Remote host closed the connection] 18:22:48 stassats [~stassats@wikipedia/stassats] has joined #sbcl 18:29:30 does typep x 'class require class to be defined at load time? 18:30:10 i'm getting "Class not yet defined:" when loading a fasl, though i don't see where it can be used besides typep 18:33:08 and the last frame is (SB-KERNEL:FIND-CLASSOID-CELL CLASS-NAME) 18:33:30 TYPEP is probably inlining the class-name -> class object lookup. 18:34:04 ... Was the class defined at compile-time? 18:34:50 it's a normal defclass at the top-level 18:35:48 and it doesn't happen every-time 18:35:52 ... That's not a "no", is it? 18:36:22 What I'm trying to ask is, "does the compiler know about the class when compiling that TYPEP?" 18:36:38 nyef: i'm loading fasls into a fresh image, without compiling 18:37:03 i need to check that 18:37:31 Is the class defined in the failing fasl, or a different fasl? 18:37:50 in the failing fasls 18:38:23 Before the TYPEP is used, I hope? 18:39:28 Do you always compile the fasls in a clean image, or do you sometimes recompile them a couple of times in the same image? 18:39:49 the latter 18:40:49 i'm guessing the way ASDF decides what to recompile upon change is at fault here 18:41:13 I'm guessing that some difference between your compilation environment and load-time environment is at fault 18:41:15 maybe not at fault, but at least the reason why it sometimes succeeds 18:41:20 You're probably running afoul of the environmental restrictions on print/read consistency / compile-file output usability. 18:41:22 Look for an EVAL-WHEN. 18:41:57 stassats: It probably succeeds if you kill all your fasls and your image and reload, right? 18:42:18 if i compile everything afresh, it works, it fails whenever i modify some file, restart image, and load 18:42:43 i didn't catch the exact pattern yet 18:43:59 Do any of your failing files define a use of TYPEP (or outright use TYPEP) before defining the class? 18:44:27 i don't think so 18:44:38 Hrm. 18:44:55 ... It's not the expansion for DEFCLASS, is it? That'd suck. 18:45:31 i don't have a reproducible error now, so i'm not sure yet 18:46:39 Well, it's likely to be do a clean build, touch one of the source files (might be a list of vulnerable files), rebuild, quit, and then try to load. 18:47:27 i'll just wait till i catch it again, it comes out quite often 18:47:42 while i'm working on the code 18:49:45 and the code is a mess, and i can't keep in the head what is where defined, i should reorganize it in any case 18:50:39 -!- hargettp [~anonymous@96.237.121.128] has quit [Quit: hargettp] 19:01:17 -!- cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has quit [Ping timeout: 276 seconds] 19:01:39 cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has joined #sbcl 19:16:23 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Ping timeout: 265 seconds] 19:18:27 jweiss [~weissj@cpe-069-134-025-078.nc.res.rr.com] has joined #sbcl 19:19:08 can someone help a total newb here - i'm at a slime-repl for sbcl and (setq x 5) gives caught WARNING; undefined variable: X 19:19:20 it's true 19:19:33 clhs defvar 19:19:33 http://www.lispworks.com/reference/HyperSpec/Body/m_defpar.htm 19:19:48 though, use #lisp for such trivial questions 19:20:05 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 19:20:15 oh, hm i thought this was a sbcl thing. i guess i forgot more lisp from last year than i thought 19:20:34 i don't remember using defvar, and all the lisp tutorials go straight to setq 19:20:49 The "sbcl thing" aspect of this is that it's one of the few implementations to care about that particular aspect of the spec. 19:21:10 "All" the lisp tutorials are wrong here. 19:21:16 aha 19:21:19 so i'm not crazy. 19:21:59 Not in that respect, at least. 19:22:29 yes, thanks for pointing that out :) 19:25:54 rmarynch [~roman@88.135.194.233] has joined #sbcl 19:43:31 -!- rmarynch [~roman@88.135.194.233] has quit [Quit: Leaving] 20:23:18 -!- cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has quit [Ping timeout: 240 seconds] 20:24:27 cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has joined #sbcl 21:03:57 -!- kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [Quit: kclifton] 21:17:19 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has left #sbcl 21:35:18 I'd like to take this opportunity to say that dynamic-extent and functionals (such as LAMBDAs or FLET or LABELS functions) is obnoxious, and doesn't match up with what I expect it to do. 21:38:25 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 21:38:50 foom: You there? 21:40:06 nyef pasted "D-X closures are a /total/ pain" at http://paste.lisp.org/display/115587 21:58:40 rbarraud [~rbarraud@118-92-1-3.dsl.dyn.ihug.co.nz] has joined #sbcl 22:21:43 -!- fe[nl]ix [~lacedaemo@pdpc/supporter/professional/fenlix] has quit [Quit: Valete!] 22:22:13 fe[nl]ix [~lacedaemo@pdpc/supporter/professional/fenlix] has joined #sbcl 22:25:58 -!- jweiss [~weissj@cpe-069-134-025-078.nc.res.rr.com] has quit [Ping timeout: 245 seconds] 22:26:37 jweiss [~weissj@cpe-069-134-025-078.nc.res.rr.com] has joined #sbcl 22:56:40 -!- jweiss [~weissj@cpe-069-134-025-078.nc.res.rr.com] has quit [Ping timeout: 240 seconds] 23:36:47 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Quit: Leaving.]