00:10:29 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Quit: Leaving.] 00:14:59 -!- jga [~gajon@189.253.66.20] has quit [Quit: Leaving] 00:48:16 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 00:57:17 rbarraud__ [~rbarraud@118-92-25-3.dsl.dyn.ihug.co.nz] has joined #sbcl 00:57:54 -!- rbarraud_ [~rbarraud@118-92-3-220.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 265 seconds] 01:33:51 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 01:49:28 -!- nyef [~nyef@pool-70-20-56-192.man.east.myfairpoint.net] has quit [Quit: G'night all.] 02:35:14 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has left #sbcl 04:22:43 -!- drewc [~user@S01060013101b6ddb.vc.shawcable.net] has quit [Ping timeout: 252 seconds] 05:16:38 -!- tsuru [~charlie@c-174-50-217-160.hsd1.tn.comcast.net] has quit [Remote host closed the connection] 05:47:16 cliftonk [~cliftonk@S010600123ff34d7d.cg.shawcable.net] has joined #sbcl 06:06:46 -!- cliftonk [~cliftonk@S010600123ff34d7d.cg.shawcable.net] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] 06:31:58 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 06:31:58 -!- ChanServ has set mode +o nikodemus 06:40:33 good morning 06:51:14 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 07:58:24 cmpitg [~cmpitg@123.16.50.194] has joined #sbcl 08:23:01 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 08:28:29 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 08:38:12 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 08:41:47 -!- cmpitg [~cmpitg@123.16.50.194] has quit [Quit: leaving] 08:45:41 stassats [~stassats@wikipedia/stassats] has joined #sbcl 09:26:03 Blkt [~user@93-33-134-89.ip44.fastwebnet.it] has joined #sbcl 09:48:50 Krystof [~csr21@nat67.mia.three.co.uk] has joined #sbcl 09:48:50 -!- ChanServ has set mode +o Krystof 09:52:40 nikodemus: vector-fill* appears not to return its sequence argument 09:52:43 similarly string-fill* 09:54:24 vector-fill* at least does -- see ((= index end) sequence) in the DO 09:56:42 but yeah, for complex strings string-fill* returns the data vector instead of the complex string 09:59:13 huh, yes 10:03:20 bbi 30 10:04:49 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 10:49:01 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Ping timeout: 265 seconds] 10:50:14 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 10:51:05 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 276 seconds] 10:57:24 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Disconnected by services] 10:57:24 attila_lendvai1 [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 11:01:48 -!- attila_lendvai1 [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Ping timeout: 245 seconds] 11:02:04 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 11:25:42 -!- Krystof [~csr21@nat67.mia.three.co.uk] has quit [Ping timeout: 240 seconds] 11:34:42 nikodemus [~nikodemus@cs181058025.pp.htv.fi] has joined #sbcl 11:34:42 -!- ChanServ has set mode +o nikodemus 11:40:13 hargettp [~anonymous@pool-71-184-178-112.bstnma.east.verizon.net] has joined #sbcl 12:13:41 ugh, need trace files from cross compilation 12:30:15 -!- rbarraud__ [~rbarraud@118-92-25-3.dsl.dyn.ihug.co.nz] has quit [Read error: Operation timed out] 12:39:04 Krystof [~csr21@nat67.mia.three.co.uk] has joined #sbcl 12:39:09 -!- ChanServ has set mode +o Krystof 12:47:59 stassats [~stassats@wikipedia/stassats] has joined #sbcl 12:54:39 cmpitg [~cmpitg@118.71.132.157] has joined #sbcl 12:55:25 wtf? 12:55:43 the compiler should be just the same during make-target-2 as when it is ready, right? 12:58:07 tsuru [~charlie@c-174-50-217-160.hsd1.tn.comcast.net] has joined #sbcl 13:00:50 *froydnj* cannot figure out why this optimization is not triggered... 13:02:30 *nikodemus* cannot figure why make-target-2 breaks but i cannot replicate the isssue by hot-patching the same change and file-compiling the breaking definition 13:04:14 aha! different policy! 13:04:33 I was about to say 13:04:34 see #lisp :_) 13:24:57 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Quit: Leaving.] 13:42:58 nyef [~nyef@pool-70-20-56-192.man.east.myfairpoint.net] has joined #sbcl 13:43:12 G'morning all. 13:50:22 hi nyef 14:27:00 How again can I disable Division-by-0 exceptions? 14:27:25 any ideas: http://paste.lisp.org/display/115232 ? 14:27:50 hm, the optimization triggers in MERGE and MISMATCH, but not in other sequence functions. why not? argh! 14:31:17 nikodemus: ... what? 14:31:53 tcr: (describe 'sb-int:set-floating-point-modes) 14:31:54 tcr: like (sb-int:with-float-traps-masked (:divide-by-zero) (/ 10d0 0d0)) => #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY ? 14:32:28 nyef: i thought i understood how &rest list type was derived, but i don't 14:32:32 nikodemus: First obvious thing, the DEFUN of COMPILER-DERIVED-TYPE isn't involved, the transform is. 14:32:32 I just tried that with (/ 1 0) which still signalled an error 14:32:48 I guess that kind of makes sense but, bah 14:32:50 1 and 0 doesn't look like floats 14:32:58 nyef: yes, the question is: why does the first one return T, T and not LIST, T 14:33:04 nikodemus: Some difference between a toplevel lambda and an internal one? 14:33:28 something like that probably, yes. but what? 14:33:40 and why does the internal one fair worse? 14:33:58 Wasn't that a bug you just fixed? 14:35:32 I wish divide-by-zero came with a use-value restart 14:36:12 sounds expensive 14:36:38 tcr: nope. this is part of figuring out why my pending changes to make-functional-from-toplevel-lambda aren't working as expected 14:36:40 why? 14:36:59 the pasted code is with vanilla sbcl 14:37:44 Is there a difference in a trace-file between the two? 14:38:04 I thought a use-value restart would be better than using (handler-case (/ a b) (divide-by-zero () ) 14:38:32 but then I wonder how I would have thought that 14:38:39 triple-bah 14:39:13 ah right, because in my case I have lots of divisions, with restart, I could just have an outer HANDLER-BIND instead of half a dozen handler-cases 14:39:40 tcr: Would you be interested in knowing how to implement such a restart? 14:40:11 I'm not sure what you mean 14:40:22 DIY? 14:40:25 Yeah. 14:41:07 Well the thing is while we do depend on sbcl we don't depend on sbcl-latest-release and I don't want to have to explain why everyone is forced to update their sbcls :-) 14:41:35 Hrm. Actually, for floaty values, that might be trickier, given the inaccuracy on exception cause location... 14:56:54 Is there a predicate to test real floats from the denormalized crap etc? 14:57:15 ok. in case of two lambdas let-substitution hasn't been done 14:57:32 so we see the lambda-var, and not %listify-rest-args 14:57:42 Ahh. 14:58:53 but WHY it isn't done, i don't know 14:58:56 tcr: don't think so. there probably should be something (infinityp et al too) 14:59:14 and even if it was done, we should still be able to do better with the lambda-var for for &rest list 15:00:00 froydnj: sb-kernel::float-infinity-p & co 15:00:13 rmarynch [~roman@88.135.194.233] has joined #sbcl 15:00:37 ah, good :) 15:02:51 tcr: sb-ext even! 15:03:37 suboptimal on SSE platforms though ;) 15:05:27 well (or ) of all those is not real optimal either because each function will try to number-dispatch 15:08:09 What's a good name for a non-inf, non-denorm, non-nan float? 15:09:24 "normal" 15:09:26 dull-float 15:09:27 tcr: normal. 15:09:36 (as opposed to de/sub normal ;) 15:12:02 arithmetic error FLOATING-POINT-INVALID-OPERATION signaled 15:13:12 I'm a bit baffled what that could be about 15:13:19 0/0 15:13:37 or (- +inf -inf), or similar 15:14:00 (* 0 inf) 15:14:21 basically, anything that would give you "any answer you like, pick one" 15:14:47 I trapped :devide-by-zero, and yes it's 0/0 15:15:20 I would be content with getting some NaN in that case 15:15:23 Krystof: although (- +inf -inf) would be ok. 15:15:35 (: 15:15:35 whoops, yes, I meant "+" 15:15:57 I was right, it was my brain and fingers that got it wrong 15:17:05 ah gotta trap :invalid too 15:18:27 ah, bother, I wonder if FIXNUMP/SIGNED-BYTE-32 is screwing things up 15:20:14 no, dammit. i still don't see where the lambda-var gets its type set 15:20:18 grrr 15:20:55 *nikodemus* instruments leaf-type &co 15:27:41 froydnj: do you have any performance numbers? 15:27:53 even for contrieved test-cases 15:29:03 nyef: gentoo folks are right. 15:29:22 nyef: we have release engineering too, pulling from VCS bypasses it. 15:29:43 nikodemus: no, I haven't benchmarked seriously yet 15:29:55 nyef: after that it is hard to tell what version any particular user has. 15:30:02 purely anecdotal numbers are ~1-2% 15:30:35 nyef: if you do want to pull from VCS, we have some support for it, 15:30:41 but would have to be more careful to get real numbers 15:30:56 nyef: but this is strictly outside engineered scope. 15:31:17 ASau: Fair enough. 15:32:18 -!- hargettp [~anonymous@pool-71-184-178-112.bstnma.east.verizon.net] has quit [Quit: hargettp] 15:32:26 ah, bother, we're also using unsigned+ and move-from-signed 15:32:42 froydnj: and code size? 15:33:07 nyef: as for checking out specific tag or timestamp, 15:33:23 nyef: it is still problematic from releng PoV. 15:33:34 blech, useless WORD-MOVEs too =/ 15:33:59 nyef: if you have some specific need for "version no earlier than this", 15:34:23 you basically follow the development, you're either maintainer yourself, 15:34:34 pkhuong: core size increases by a couple of pages. the actual assembly for the sequence is IIRC 5 bytes smaller if we stick compensation code in *elsewhere* 15:34:44 nyef: or deal with all arising problems yourself. 15:35:10 nyef: if you don't have this specific need, then you could use previous release just fine, 15:35:23 nyef: that's what releases exist after all. 15:36:06 froydnj: k, so code that's actually used is smaller. 15:36:30 pkhuong: yeah, quite a bit 15:40:40 kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 15:53:42 -!- Krystof [~csr21@nat67.mia.three.co.uk] has quit [Ping timeout: 240 seconds] 15:55:39 hargettp [~anonymous@pool-71-184-178-112.bstnma.east.verizon.net] has joined #sbcl 15:58:15 drewc [~user@S01060013101b6ddb.vc.shawcable.net] has joined #sbcl 16:05:47 -!- rmarynch [~roman@88.135.194.233] has quit [Quit: Leaving] 16:09:15 ugh, I think arith VOPs not accepting descriptor-reg just kills codegen in some places 16:24:21 so, speaking of sequence functions, it seems like they should all be limited to doing fixnum arith 16:24:36 you can't actually have more cons cells than the size of a fixnum... 16:25:16 a lot of the functions are doing generic-+ and such completely uselessly 16:25:26 Which is more efficient, or does it not matter: SUB [R12+xxx], ; MOV RAX, [R12+xxx], or MOV RAX, [R12+xxx]; SUB RAX, ; MOV [R12+xxx], RAX ? 16:26:24 they are doing fixnum arithmetic...or do you mean the useless "yup, still a fixnum" checks should be thrown away? 16:26:24 nyef: the one that generates smaller code, perhaps 16:26:48 nyef: I think the second one is probably preferable 16:27:02 Heh. So, two conflicting answers? 16:27:22 Same again, but without the R12 in the addresses? 16:28:26 they should at least do the fixnum arithmetic inline, not via generic-ops 16:28:31 clarification: I am guessing the second one wins from a performance standpoint. depending on size differences we might prefer the first one 16:28:46 afaics, they are all doing fixnum arithmetic inline 16:29:13 I'm pretty sure there was at least a few of them doing generic arith. lemme see if I can find which one it was. 16:29:54 but yes, they could be simply doing fixnum arith, not fixnum->bignum 16:31:54 yea, so, %find-position for one example. 16:32:36 froydnj: This is for part of sb-alien, so I'm not substantially worried about core bloat from it. 16:35:56 ah, hm, I wonder which bit of %find-position is doing that 16:39:22 -!- cmpitg [~cmpitg@118.71.132.157] has quit [Quit: leaving] 16:44:00 Fare [~Fare@ita4fw1.itasoftware.com] has joined #sbcl 16:50:59 -!- kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [Remote host closed the connection] 16:51:10 kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 16:52:38 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 276 seconds] 17:24:25 http://paste.lisp.org/display/115237 # propagate-local-call-args was too lazy 17:24:36 now to see if this breaks anything else... 17:29:39 Ugh. "((lispobj *)th)[symbol >> WORD_SHIFT] = binding->value;" 17:29:49 nikodemus: Congratulations. 17:30:53 aie! where is that? 17:31:35 That's going into dynbind.c on my local branch right now. 17:31:54 Twice, actually. 17:32:02 actually, after looking at it for a while it isn't too bad aside from the cast :) 17:32:07 Storing TLS indexes instead of symbols on the binding stack. 17:32:27 one less indirection? 17:32:31 nyef: that's the new setf for thread-local special symbols? 17:33:21 Yeah, less indirection. 17:33:34 Also saves a register load in many cases. 17:33:41 symbol->tls-index + thread->tls-area = value vs tls-index + thread->tls-area = value ; cool 17:33:46 could that be combined with wide-bindings? 17:33:57 wide-bindings? 17:34:24 seriously, what about indexing with a thread id? 17:34:35 aka wide binginding 17:34:36 -!- drewc [~user@S01060013101b6ddb.vc.shawcable.net] has quit [Read error: Connection reset by peer] 17:34:51 drewc [~user@S01060013101b6ddb.vc.shawcable.net] has joined #sbcl 17:34:53 symbol->tls-area + thread_id = value 17:34:57 Wouldn't that slow dynamic binding down instead of speed it up? 17:34:59 ah right :) 17:35:19 nyef: we'd have to make sure symbols are clustered by cache line 17:35:32 then you could just put the tls-area on the stack, so it would be tls-area + thread-id = value 17:36:06 sorry, which stack are you talking about??? 17:36:08 so that we'd index cache lines by thread id, and index into that by symbol. 17:36:42 per-symbol tls means lots of cache contention between multiple CPUs 17:36:54 Where do you store the thread id? 17:36:58 stassats [~stassats@wikipedia/stassats] has joined #sbcl 17:37:23 the bigger issue, i think, is that in our current scheme a limited number of symbols can have dynamic bindings. in wide-binding scheme the number of threads is limited instead 17:37:24 Remembering that we still need a per-thread control block for things that aren't kept in symbols. 17:37:25 all cputs running simultaneous threads that use the same symbol will spend their time paging in the symbol's tls 17:37:27 nyef: in the thread struct. It might be slightly slower, but at least we'll run into issues with a maximal number of threads, not of symbols 17:37:39 Fare: that's why you want to index into a cache line with the thread id. 17:37:39 "1024 threads should be enough for everybody" :) 17:38:34 Okay, my build is going, that should be good for half an hour, provided nothing breaks. 17:38:36 e.g. 8 symbols use the same TLS vector, and you index by (symbol->tls_vector+offset)[thread_id*cache_line_size] 17:38:53 where tls_vector+offset can be precomputed, and thread_id prescaled. 17:39:23 then you need different code for each processor and/or pick your cache line size as the biggest available, plus to not waste memory, allocate your tls areas for multiple symbols at once, etc... 17:39:30 hey, this builds! /me is amazed 17:39:44 Fare: 64 bytes for the near future. It's just a constant. 17:40:17 so group symbols by eight, etc. 17:40:17 efficiency aside, limiting number of dynbound symbols vs number of threads is the bigger thing 17:40:42 (if someone has a scheme where neither is limited, i'm all ears) 17:40:47 nikodemus: not quite; the slow path to grow a TLS vector indexed by thread id isn't as complex. 17:40:53 How often are people hitting this limit, anyway? 17:40:55 nikodemus: atomic grow on demand. 17:41:12 nyef: in theory, we could use a similar scheme for what we put in R12, and have the thread id in R12 directly. 17:41:27 pkhuong, and you need to grow when the number of threads increases past the previous max alloted? 17:41:57 nyef: often enough that we need to signal an error for running out of tls-area -- it has happened in the wild already 17:42:09 Fare: right. That problem (lock-free replacement of a vector with a copy) is pretty common, and we have well-tested implementations to lift into our code base, if we want to go that way. 17:42:24 PROGV + GENSYMS in a custom evaluator can easily do that 17:42:38 nyef: E-lang hits that; the problem is compounded by the fact that they use gensymmed symbols to fake TLS. 17:42:55 Ugh. Fair enough, I guess. 17:43:17 And threads are expensive enough that it's more reasonable to accept a lower maximum. 17:43:28 pkhuong, as long as only one thread ever uses a given symbol, that's fine. 17:44:07 i'd rather have a limit on dynamically bound symbols than threads 17:44:55 Wait, wait... Let's go back to the GCing of TLS-slots. 17:45:55 when no code objects reference one anymore, you can reuse it. 17:45:58 code is hard. 17:46:04 I'm already thinking that there needs to be a way to determine which TLS-slots were allocated for a TLS-index fixup, so the rest in theory can be freed if they're not bound. 17:46:14 does anyone actually run into this limit anyways? 17:46:19 what is the limit? 17:46:52 foom: Limit is... somewhere around 3000, I think, and nikodemus and pkhuong have claimed it's been hit in the wild. 17:47:25 how is it done right now, already? 17:47:40 But that's just a constant in the source, right? 17:47:55 Interaction between two constants, but yeah. 17:48:19 Simple solution: make it be a startup tunable, yay, now it's the user's problems to jump through hoops to make the runtime work for their app. :) 17:48:27 oh my - now there will be statically static variables, and dynamically static variables (via progv). 17:49:47 s/dynamically static/dynamically dynamic/ 17:50:01 Fare: we're already on our way to have that. 17:50:02 s/statically static/statically dynamic/ 17:53:00 (unless PROGV calls the same thing as compile internally; after all, PROGV can be expensive) 17:54:50 ooh, this even shrunk the core by 20k bytes 17:59:19 hm, --tls-size should be possible 17:59:40 -!- hargettp [~anonymous@pool-71-184-178-112.bstnma.east.verizon.net] has quit [Quit: hargettp] 18:02:20 hargettp [~anonymous@pool-71-184-178-112.bstnma.east.verizon.net] has joined #sbcl 18:02:34 ... "and shrinking MAX_INTERRUPTS should also increase the available TLS indexes..." 18:02:44 Not that you really want to do that. 18:20:12 Krystof [~csr21@nat79.mia.three.co.uk] has joined #sbcl 18:20:12 -!- ChanServ has set mode +o Krystof 18:28:53 -!- kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [Read error: Connection reset by peer] 18:41:39 -!- nikodemus [~nikodemus@cs181058025.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 19:04:51 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 19:04:51 -!- ChanServ has set mode +o nikodemus 19:16:24 -!- hargettp [~anonymous@pool-71-184-178-112.bstnma.east.verizon.net] has quit [Quit: hargettp] 19:23:50 Is there a way to get a C FILE stream from a Lisp FD-STREAM? 19:24:35 grab the fd and call fdopen? 19:24:47 Yeah, grab the fd and call fdopen. 19:25:11 There's a similar procedure for getting a windows HANDLE. 19:27:45 hm I wonder why I didn't use that before 19:27:54 and instead ended up with this code 19:28:03 *tcr* scratches head 19:29:42 oh right 19:29:50 *tcr* curses 19:33:13 You know what'd be interesting? A symbol global-storage array, with corresponding slot-indexes stored in the symbol object, to parallel the TLS-indexes. 19:33:57 And the reason it'd be interesting is that your symbol-value accessors for constant symbols suddenly boil down to an absolute memory reference. 19:39:43 -!- Krystof [~csr21@nat79.mia.three.co.uk] has quit [Ping timeout: 240 seconds] 20:04:45 it seems like you can set an fd to be nonblocking by fcntl(fd, F_SETFL, O_NONBLOCK); that seems to _additionally_ set the fd flags to non-blocking (and leaves other flags untouched); which is all nice, I'm just wondering if that's really true, how do you turn off non-blocking again? 20:09:09 F_SETFL doesn't add options, it sets the option mask 20:09:18 kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 20:09:33 also, be careful, that sets the *FILE* options, not the file descriptor options. 20:09:59 that too 20:10:06 so, e.g. setting nonblockingness on stdout can be a rather evil thing to do to people. 20:10:20 foom writes too fast 20:10:33 *types 20:12:25 uh if that's the case it's just confusing :-) the flags are the ones passed to open(2) which is about file descriptor not handles 20:13:11 I tried f_setfl and it added to the value returned by f_getfl rather than replacing it 20:13:35 adding, or probably ORing to it 20:13:49 no, open creates a file descriptor and a file description. 20:14:03 O_SETFL sets the file description flags 20:14:09 er, F_SETFL 20:14:23 which means it's shared across file descriptors created with dup, dup2, fork, etc. 20:15:28 fe[nl]ix pasted "set O_NONBLOCK state" at http://paste.lisp.org/display/115245 20:15:40 I thought you were referring to FILE handles above, but if I get you right this time you meant the actual in-kernel state, right? 20:15:54 i mean a particular kind of in-kernel state 20:16:09 the kind created once by open and shared by all file descriptors pointing to that 20:16:14 fe[nl]ix: Sure 20:16:18 as opposed to the kind duplicated by dup 20:16:32 foom: yeah alright, that's stated in the manpage :-) 20:16:40 yea, but it's really tricky 20:17:19 nobody thinks about how evil it is to change the fd some other process is writing to to non-blocking out from under it. 20:40:34 *nyef* nearly tried to build a version of SBCL that used a TLS-index fixup in BOUNDP when passed a constant symbol. 20:40:49 Does anyone else see the problem with such a scenario? 20:42:36 minion: Paste 115246? 20:42:41 minion? 20:42:45 Damnit, minion! 20:44:12 minion [~minion@common-lisp.net] has joined #sbcl 20:44:49 minion: Paste 115246? 20:44:49 Paste number 115246: "A bad idea, but a possibly-useful technique" by nyef in None. http://paste.lisp.org/display/115246 20:46:22 Arguably, the last LOADW would no longer have worked... And static-symbols would have failed the AVER... 20:46:54 Still, I haven't seen the :load-tn thing done before. 20:54:03 so MAKUNBOUND nukes the tls-index? 20:54:20 or do i misunderstand completely? 21:00:53 http://paste.lisp.org/display/115248 # duh 21:04:40 No, it's more that some symbols are -never- dynamically bound, their global value is always used instead. 21:05:22 ... What on earth is that disassembly? 21:05:43 that's what i'm trying to figure out 21:06:13 it happens when i run locall-analyze-fun on the locall-fun in make-functional-from-toplevel-lambda 21:06:20 Hang on, what's #x1432 when it's interpreted on a tagged value? 21:06:57 the code works, and fails only a single backtrace test -- but adds 70kb of this crap to the core 21:07:55 #x32 is a SIMPLE_FUN_HEADER_WIDETAG. 21:08:13 It's a function entry point that's not linked to the list of entry points in the component. 21:08:52 In that disassembly, it starts at 5A0. 21:09:12 What was your input function, anyway? 21:09:42 (defun x () (throw 'bad t)) ; in the repl 21:10:58 So, where'd the (lambda () #'x) come from? 21:11:49 annotated with the make-functional-from-toplevel-lambda 21:12:06 And why is the real function not linked on the list for the code-component? 21:14:13 (lambda () #'x) has to be the tl-xep compiled in the repl 21:16:22 Something seems rather brute-force about the replacement m-f-f-t-l. 21:17:10 Where'd the stuff starting at reoptimize-component come from? 21:17:37 ShereKahn [~ajourez@88.17-67-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 21:19:10 see make-xep 21:19:32 and reference-entry 21:20:12 make-functional-from-toplevel-lambda is very much like the combination of those two, and skipping the reanalysis causes some issues 21:20:22 You mean reference-entry-point? 21:20:37 Or did I miss something? 21:20:40 sorry, yes 21:20:46 misremembered the name 21:20:57 Hrm. 21:21:05 aha 21:21:28 Hrm? 21:21:29 if i keep marking both fun and xep as having external references the bogosity goes away 21:21:41 Ah. 21:21:45 but i don't understand why the fun needs that 21:22:46 If you don't, then I certainly don't. 21:23:08 maybe i'll just stroke my beard and look wise 21:23:14 "ahem" 21:23:21 Heh. 21:26:03 -!- Blkt [~user@93-33-134-89.ip44.fastwebnet.it] has quit [Ping timeout: 265 seconds] 21:26:12 (this is for 310173 and 384892) 21:29:24 Blkt [~user@93-33-134-89.ip44.fastwebnet.it] has joined #sbcl 21:29:40 hmph, now the core is even bigger 21:31:14 Speaking of compiler bugs, do you have any ideas on 309099 (nonlinear LVARs)? 21:33:40 nothing new 21:34:08 i suspect stack-analysis, but that's just a hunch 21:35:12 It's actually because non-local exits can introduce an LVAR that gets assigned twice over valid control flow. 21:36:10 Thus causing the stack-analysis to consider the LVAR to not be live at one point when it is, and thus drop it. 21:37:07 And the only concept I have with which to fix it is a phi-function on the non-local entry. 21:39:10 hm. this build fixes three bugs: 310173, 384892, and 655203, but increases core size by... 828Kb on x86-64 21:39:23 but at least all tests pass... 21:39:50 phi-function in the SSA-sense, or something you'd actually execute at runtime? 21:40:14 In the SSA-sense. 21:40:21 828Kb?!? 21:41:11 yep 21:41:36 from 44228656 to 45076528 21:41:47 ... Lovely. 21:42:20 tomorrow i'll try to figure out where the hell that happens 21:42:28 Does this show up in component disassembly? 21:42:40 not for the ones i've tried so far 21:42:44 Hunh. 21:43:31 something is bizarre here, but i'll figure it out 21:45:01 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 252 seconds] 21:54:18 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 21:56:06 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: Leaving] 22:07:35 -!- cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has quit [Ping timeout: 240 seconds] 22:08:42 cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has joined #sbcl 22:18:12 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 22:21:12 good night everyone 22:23:51 -!- Blkt [~user@93-33-134-89.ip44.fastwebnet.it] has quit [Quit: Error: do not makunbound t please] 22:24:04 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 240 seconds] 22:24:38 -!- ShereKahn [~ajourez@88.17-67-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 264 seconds]