03:51:12 -!- cmm [~cmm@109.67.212.191] has quit [Ping timeout: 240 seconds] 03:51:24 cmm [~cmm@bzq-109-67-212-191.red.bezeqint.net] has joined #sbcl 04:30:59 -!- tsuru` [~charlie@adsl-74-179-19-82.bna.bellsouth.net] has quit [Remote host closed the connection] 05:28:08 -!- antgreen [~user@bas3-toronto06-2925098489.dsl.bell.ca] has quit [Ping timeout: 276 seconds] 06:33:25 sdemarre [~serge@91.176.28.90] has joined #sbcl 07:31:09 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 07:49:49 Any ideas for special variables and threads? threads use the _original_ value of special variables, not a currently bound one; is there some way to let them start with a copy of the parent threads specials? (without listing every one in two (LET)s, of course ... ;) 07:50:04 I'd prefer a flag to (make-thread) or something like that ... 07:50:44 Of course, I could write a macro that looks for specials, binds them to gensyms, makes a thread, and binds the gensyms to the specials again ... but that's _awful_. 07:50:50 Is there a better solution? 07:51:44 flip214: nothing official and stable, but.. examine the stack of bindings and build arguments for PROGV. 07:56:18 well, for now I'd be satiesfied with an SBCL solution ... long-time I'd like a CDR 07:56:22 thanks, I'll take a look 08:01:12 good morning everyone 08:57:14 oiiii [~oiiii@82.71.241.25] has joined #sbcl 09:07:32 flip214: we implemented threads and specials that way first -- inheriting values from the current bindings of the parent thread. It turned out not to work so well 09:07:36 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Remote host closed the connection] 09:08:59 why? too slow? 09:30:06 no, semantic difficulties 09:30:27 this way round it is possible to inherit the global binding by default and the thread-local value explicitly 09:30:51 the other way round it's not actually possible to override inheriting the thread-local value. This caused subtle problems in actually using threads 09:31:59 listing everything you care about in two lets is the way to go -- inheriting thread-local values implicitly (including in libraries that you have no control over at all) leads to disaster 09:37:20 hmmm ... yes, but having to find out/remember which specials library code needs is unfortunate, too 09:37:48 eg. all the *print-pretty* and similar ... in one thread it works, in another one that's spawned it doesn't 09:39:47 ECL has an initial-bindings parameter ... http://ecls.sourceforge.net/new-manual/re21.html 09:41:58 flip214: sure, but that's not really any more expressive than a pair of lets 09:42:17 I accept that it might be a bit more convenient 09:42:44 and the point is that at least finding the set of specials that a user should care about in the union of all libraries being used is tractable and usually sort-of-documented 09:43:04 finding the set of specials that have interesting internal state and must not be shared between threads in the union of all libraries is much, much harder and undocumented 09:53:49 with your second sentence I agree ("much harder"), but the first point I think to be hard, too 10:02:43 it is hard 10:02:50 it's just possible (vs "effectively impossible") 10:04:41 fine .... so, do you have any advice? 10:04:51 how to find out which specials are needed? 10:05:06 then I can make a macro wrapping make-thread myself 10:14:37 read documentation 10:15:55 a first approximation might be "all symbols exported from a public package with a special binding" 10:18:18 (apropos-list "*PRINT-" :cl) ;; stuff evaluation result into your code, don't leave (apropos-list ...) in your program. That's what I use to rebind all printer control variables, unless WITH-STANDARD-IO-SYNTAX is what I need.. 10:21:47 akovalen` [~anton@95.73.216.147] has joined #sbcl 10:22:12 -!- akovalen` is now known as akovalenko` 10:23:39 -!- akovalenko [~anton@95.73.127.155] has quit [Ping timeout: 258 seconds] 10:23:53 -!- akovalenko` is now known as akovalenko 10:32:15 yes, that's fine, but it doesn't say anything about specials from other packages ... well, never mind, I'll see what I can do. 10:33:48 prxq [~mommer@mnhm-5f75c126.pool.mediaWays.net] has joined #sbcl 12:14:16 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 12:14:26 G'morning all. 12:33:41 Is SBCL going to enter code freeze soon? Almost seems like it's overdue. 12:44:18 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 12:44:18 -!- ChanServ has set mode +o nikodemus 12:46:13 -!- foom [~jknight@ita4fw1.itasoftware.com] has quit [Ping timeout: 245 seconds] 12:46:27 hi nyef 12:46:34 foom [~jknight@ita4fw1.itasoftware.com] has joined #sbcl 12:46:50 Hello fe[nl]ix. 12:47:04 Oh, hey. nikodemus is here. 12:53:28 Oh, neat. Just found bug 309069. 12:57:57 hi (goes look at lp) 12:58:22 Note that 309069 is still valid... on darwin PPC. 12:58:30 anti-darwinian selection in action :) 12:58:46 Heh! 13:01:02 much kudos for that fix -- i added a note re. current status to the bug! 13:01:59 nikodemus: So, have any build problem reports with XCode 4.1 yet? 13:07:42 nikodemus: sorry for bothering, but did you see https://bugs.launchpad.net/sbcl/+bug/876376 ? error when inspecting gensyms? 13:34:31 flip214: anton's diagnosis is right for the first part 13:34:59 the second looks like purely a slime issue 13:35:22 well, slime/swank 13:35:37 nikodemus: that's on slimv ... but it dies inside of sbcl 13:36:04 in the same preprocess-for-eval 13:36:16 flip214: the issue is that you cannot serialize gensyms while maintaining identity 13:36:17 So I'd hoped they'd be related and quickly fixed ;) 13:36:23 totally unrelated 13:36:37 well, how should gensyms in a macroexpansion then get inspected in a backtrace? 13:36:45 there should be a way, /me thinks ... 13:37:55 flip214: slimv needs to maintain identity of gensyms on the cl side 13:39:29 slimv is on the vim side ... so you mean swank, right? 13:40:19 sorry, bbl ... but just write anyway, I'll read it when I'm back 13:43:30 tsuru [~charlie@adsl-74-179-19-82.bna.bellsouth.net] has joined #sbcl 14:06:20 flip214: i'm not too familiar with this area of slime 14:09:00 but the bottom line is that (eq (read-from-string "#:G123") (read-from-string "#:G123")) => NIL always 14:11:02 so if you want to be able to pass gensyms to the editor and receive them back while maintaining identity, you need to keep a table on the CL side 14:12:05 Okay, one PPC test suite failure down. 14:14:26 ...but i've never run across this as a problem in slime proper, so it seems likely to me that slimv is doing something different 14:15:37 slime seems to use (:emacs-rex (swank:frame-locals-and-catch-tags 2) "COMMON-LISP-USER" 0 104) instead of inspect-in-frame for that 14:16:05 oops, sorry: (:emacs-rex (swank:inspect-frame-var 2 0) "COMMON-LISP-USER" 0 105) 14:28:59 nikodemus: Do you know if we're likely to see a code-freeze soon? 14:35:48 I wonder if anybody ever tried to do a proper 'macroexpand in context' extension for slime, for debugging macrolet-heavy semi-dsl like stuff? 14:37:00 I did some hack using hu.dwim.walker, and some advice definitions to hook into slime, but it loses gensym identity for repeated expansions... 14:38:19 it seems that _nested presentations_ could be a starting point (they would be useful anyway) 14:39:13 Being able to control how a presentation appears in the REPL would be nice as well. Something like Xof's R stuff, but for lisp objects. 14:40:10 At the same time, it's technically off-topic for #sbcl. 14:48:54 i have a hack somewhere that allows lisp code to display images in slime repl, based on xofs R stuff 14:49:19 I know that my R stuff assumes that symbols are packageless 14:49:34 we should fix that before anyone starts believing me about R being a lisp 14:50:21 nyef: I was planning on starting a freeze next weekend 14:52:10 though really in the sbcl model there's always a freeze soon, so you should never care about the exact timing is there isn't one right now :-) 14:54:12 jsnell: Okay, so I can continue banging on the loose ends (like PPC test failures) for a little bit longer. 14:54:26 please do 14:54:34 "<24h after a release is tagged" is about as close as you can get to "freeze is far away" :) 14:55:11 And maybe attack the scrub_control_stack() disaster, although given that I haven't heard of anyone else having problems with it... 14:55:30 so one thing about having cabal absentees at lisp events is that we have to discuss things like "is jsnell doing too much work?" on IRC instead of over beer 14:59:11 which reminds me: david and i briefly talked about how we should schedule a most-hands irc meeting for freeze weeks -- not to talk about releases necessarily, but just to ... talk 14:59:49 (doing it on freeze weeks simplifies the question of "when's the next one?" nicely) 15:05:04 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 15:07:23 he's gone, but I think that's quite a good idea 15:16:41 rereading my old blogs about ECLMs gone by in preparation for a new one... 15:17:10 nyef: one thing that ITA do, according to my notes from ECLM 2006, is "punning fixnums as pointers to word-aligned data (which works because of the tag bits)" 15:17:57 Krystof: Still works, really. But they're no longer guaranteed to be word addresses. 15:19:16 Eesh. 48-minute builds suck. 15:21:04 ... oh, god. The ROOM of DOOM strikes again. No wonder this test file fails with an invalid exit status. )-: 15:38:29 -!- Xof [~crhodes@158.223.51.79] has quit [Ping timeout: 276 seconds] 15:39:49 wow. Bye, Xof. (I wonder who's tripped over a cable at Goldsmiths) 15:51:47 Xof [~crhodes@158.223.51.79] has joined #sbcl 15:51:47 -!- ChanServ has set mode +o Xof 16:27:54 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Read error: Connection reset by peer] 16:30:10 -!- oiiii [~oiiii@82.71.241.25] has quit [Remote host closed the connection] 16:59:48 homie [~levgue@xdsl-78-35-173-101.netcologne.de] has joined #sbcl 18:01:16 nikodemus: thanks for the inspect-in-frame hint, will try 18:16:20 Oh, lovely. Gencgc on PPC conses if you try to pin one object, but doesn't cons if you pin more than one. 18:22:38 Gah. Host-alieneval / maybe-with-pinned-objects only pins on x86oids, because x86oids are the only ones that you can pin on without disabling the GC. WTF? 18:23:39 ... are all these evils related to the scrub_control_stack() craziness? 18:24:32 No, I'm looking at ROOM craziness right now. 18:24:34 Krystof: yea...but it only sortakinda works on x86-64, because the data is actually 4-word aligned, and x86-64 used 61bit fixnums. :) 18:24:59 foom: Can I interest you in 63-bit fixnums? :-D 18:25:02 Krystof: so we stole a bit from the top with a shift, and called it a day. :) 18:27:55 foom: you could have stolen 15 more ;) 18:50:19 Hunh. threads.impure.lisp / (DEADLOCK-DETECTION INTERRUPTS) is failing for me because INTERRUPT-THREAD throws an error due to the thread having already finished. 19:34:44 pkhuong: sure. Maybe it'd be worth it to steal more, to make immediate SAPs instead of using fixnums. And hope nobody ever wants to use those address bits. :) 20:02:42 ... would you be interested in immediate SAPs for aligned addresses? We could scare up a two-bit lowtag on 64-bit systems for that if you wanted, at the cost of only having 62-bit fixnums. 20:32:23 That sounds like it would involve a test at creation time and at sap-access time, to determine what kind of sap you have, which would be unfortunate. The fixnum representation hasn't been hurting, so I'm not sure there's much incentive to change. In non-perfcritical places, it's boxed inside of a custom struct, sorta like alien except with much less overhead: just a struct header and one fixnum field. 20:34:39 (defstruct (c-object) (pointer 0 :type fixnum)) with subtypes for c structures, e.g. (defstruct (SomeStructType (:include c-object))) 20:35:14 ... sb-alien struct types? 20:37:52 well, the accessors are defined via sb-alien, with wrapper functions for each slot to go fixnum->sap->alien->slot-dereference and c-object->sap->alien->slot-dereference 20:38:53 Actually, why involve alien->slot-dereference? Why not just SAP-REF-FOO ? 20:39:36 -!- sdemarre [~serge@91.176.28.90] has quit [Ping timeout: 240 seconds] 20:40:39 because alien takes care of the layout 20:40:47 it all gets optimized away 20:40:49 ... oh, right, I was going to make SAP-REF-LISPOBJ. Better write that down before I forget. 20:41:21 the code turns into a straight dereference of the fixnum, no saps or alien objects in sight. 20:41:55 Okay, that's pretty sweet. 20:42:38 sbcl's optimizer isn't *totally* useless. :) 20:43:09 Mmm. 20:43:46 Just mostly so? (-: 20:44:27 well, that level of opts seems to work great. It's only the lowlevel stuff that's worthless. Things like getting rid of redundant shifts. 20:44:45 -!- homie [~levgue@xdsl-78-35-173-101.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 21:08:55 that's almost like snapshots, right? 21:08:59 er, wrong channel 21:09:02 sorry. :) 21:10:29 foom: yeah. ir2 -> llvm would be doable, but I don't trust its gc-friendliness. 21:11:04 just make sure it's really good at optimizing out allocations 21:11:18 that has to happen before. 21:11:28 then it'll run until you get around to fixing up llvm's gc support! :) 21:11:52 ir1 and representation selection. 21:12:19 it's the part where safepoints move all the roots to the stack that sucks. 21:12:42 maybe I could hack that away and just have roots be alive. 21:14:48 I suspect it's not too hard to fix anything wrong with its gc support well enough to make a conservative-stack gc work right. 21:16:32 I don't know what sort of code it'll emit for references via tagged pointers. 21:19:12 Well, probably ideally it would directly deref the tagged pointer because it's fewer insns, but maybe it would convert it to a raw pointer first. Either of which should be fine. 21:19:32 the latter increases the register pressure 21:20:02 I meant fine for a GC. 21:20:27 The second only increases the register pressure if you keep the tagged pointer around too, which you probably wouldn't need to. 21:20:41 but I do want the tagged pointer for GC. 21:20:51 why? 21:21:10 there's conservative and then there's conservative. 21:22:12 sure. precise would be better. After it's working conservatively, making llvm emit a stack map off to the side would be awesome. 21:22:29 that part's easy 21:22:42 it's stack map without killing code quality that's hard. 21:22:55 stack + register map, sorry. :) 21:23:50 ... and here I was considering partitioning the x86-64 register set and setting up a control stack that didn't share space with the C stack... 21:24:06 You *should* be able to tell at every IP what the registers contain and what the stack contains, without changing the code output. 21:24:24 it's just a matter of getting the compiler to write out an appropriate datastructure 21:24:41 sure, that's doable. Transformations make this harder. 21:25:03 transformations like what? 21:25:21 "this register contains a pointer to X + 6"? 21:26:07 ... if you had TN lifetimes down to the instruction boundaries in VOPs, would that be sufficient to create your maps? 21:26:23 nyef: we're talking llvm, though. 21:26:40 Ah. 21:26:50 the point of going through llvm is that it can do interesting code optimisation, including code motion. 21:27:08 foom: it's harder when it's x+n because of loops. 21:30:13 If it's x+n and n is also available, that's still fine. But, yeah: when you have a loop like for(int *y = x; y < end; y++), you mightn't need x at all after the loop started, and you lose your object-start pointer entirely... 21:31:48 so, in theory, we could force the original pointer to be live. 21:35:11 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Ping timeout: 244 seconds] 21:35:25 oh well. I'm having too much fun specializing C at runtime for now. 21:35:45 the potential usefulness:code ratio is very interesting (: 21:36:45 I wonder if there's already code to ensure it stays accessible (not necessarily live). Because you need the exact same thing for debugability. 21:38:54 ...or unwinding. 21:39:01 You don't need to keep the original pointer if it's derivable via combination with another variable or a constant, but you do if it's not derivable. 21:44:25 kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #sbcl 21:44:27 -!- prxq [~mommer@mnhm-5f75c126.pool.mediaWays.net] has quit [Ping timeout: 260 seconds] 22:42:06 tsuru` [~charlie@adsl-98-87-45-21.bna.bellsouth.net] has joined #sbcl 22:44:48 -!- tsuru [~charlie@adsl-74-179-19-82.bna.bellsouth.net] has quit [Ping timeout: 240 seconds] 22:51:43 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.]