00:10:25 -!- milanj [~milanj@cable-94-189-145-213.dynamic.sbb.rs] has quit [Quit: Leaving] 00:18:51 robgssp [~user@c-24-147-78-203.hsd1.nh.comcast.net] has joined #sbcl 00:29:56 -!- robgssp [~user@c-24-147-78-203.hsd1.nh.comcast.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 00:39:26 robgssp [~user@c-24-147-78-203.hsd1.nh.comcast.net] has joined #sbcl 00:41:47 -!- robgssp [~user@c-24-147-78-203.hsd1.nh.comcast.net] has quit [Remote host closed the connection] 00:42:58 -!- Bike [~Glossina@67-5-223-95.ptld.qwest.net] has quit [Ping timeout: 252 seconds] 00:43:22 Bike [~Glossina@67-5-223-95.ptld.qwest.net] has joined #sbcl 00:47:51 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: supernova explosion] 01:18:24 -!- davazp [~user@92.251.175.178.threembb.ie] has quit [Remote host closed the connection] 01:57:22 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 02:30:09 yacks [~py@180.151.36.168] has joined #sbcl 02:39:01 -!- christoph4 [~christoph@ppp-188-174-138-74.dynamic.mnet-online.de] has quit [Ping timeout: 252 seconds] 02:53:30 christoph4 [~christoph@ppp-188-174-69-237.dynamic.mnet-online.de] has joined #sbcl 03:10:12 Fiora [~Fiora@ec2-50-17-93-47.compute-1.amazonaws.com] has joined #sbcl 03:11:29 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Ping timeout: 248 seconds] 03:12:27 echo-area [~user@182.92.247.2] has joined #sbcl 03:14:11 -!- Fiora [~Fiora@ec2-50-17-93-47.compute-1.amazonaws.com] has quit [Client Quit] 03:14:21 kanru` [~kanru@220-136-14-43.dynamic.hinet.net] has joined #sbcl 03:25:55 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Read error: No route to host] 03:26:02 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 03:28:36 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 03:46:41 -!- wbooze [~wbooze@xdsl-78-35-130-152.netcologne.de] has quit [Ping timeout: 248 seconds] 04:01:29 attila_lendvai [~attila_le@92.46.3.157] has joined #sbcl 04:01:29 -!- attila_lendvai [~attila_le@92.46.3.157] has quit [Changing host] 04:01:29 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:01:49 -!- kanru` [~kanru@220-136-14-43.dynamic.hinet.net] has quit [Ping timeout: 256 seconds] 04:24:21 echo-are` [~user@182.92.247.2] has joined #sbcl 04:25:05 -!- echo-area [~user@182.92.247.2] has quit [Ping timeout: 248 seconds] 04:32:11 kanru` [~kanru@118-163-10-190.HINET-IP.hinet.net] has joined #sbcl 04:52:05 teggi [~teggi@113.172.56.137] has joined #sbcl 04:57:26 (sb!xc:deftype bignum-index () '(integer 0 #.(1- (ash 1 (- 32 sb!vm:n-widetag-bits))))) 04:57:29 really? 04:57:56 -!- Bike [~Glossina@67-5-223-95.ptld.qwest.net] has quit [Quit: Reconnecting] 04:58:18 Bike [~Glossina@67-5-223-95.ptld.qwest.net] has joined #sbcl 04:58:48 having 32 there doesn't seem good 05:19:14 -!- Bike [~Glossina@67-5-223-95.ptld.qwest.net] has quit [Ping timeout: 245 seconds] 05:26:49 fold-index-addressing hasn't ever really worked on subtractions. 05:27:50 At some point, it does (+ (- x y) z) => (+ x (- y z)) ... 05:29:21 Bike [~Glossina@75-164-169-126.ptld.qwest.net] has joined #sbcl 05:31:44 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 05:40:00 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 05:48:35 -!- echo-are` is now known as echo-area 06:05:49 attila_lendvai [~attila_le@87.247.13.135] has joined #sbcl 06:05:49 -!- attila_lendvai [~attila_le@87.247.13.135] has quit [Changing host] 06:05:49 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:17:35 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has left #sbcl 06:28:30 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 07:35:33 -!- Bike [~Glossina@75-164-169-126.ptld.qwest.net] has quit [Ping timeout: 248 seconds] 07:50:01 scymtym [~user@89.31.118.161] has joined #sbcl 08:37:49 -!- specbot [~specbot@common-lisp.net] has quit [Read error: Operation timed out] 08:38:05 specbot [~specbot@common-lisp.net] has joined #sbcl 08:44:30 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 264 seconds] 08:49:29 yacks [~py@180.151.36.168] has joined #sbcl 08:50:11 pkhuong: wow 08:50:38 I just replied to this question on SO, suggesting there may be a bug in SBCL on Windows. Am I right? 08:50:39 http://stackoverflow.com/questions/16706958/the-pathname-directory-behave-strange/16709442#16709442 08:50:45 (less worried about the 32, though) 08:52:51 "there may be a bug in SBCL on Windows" <- least surprising statement ever :-) 08:59:46 Krystof: yeah, that's what I thought. And pathnames are buggered enough in CL without the help from Windows :-) 09:09:52 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 10:32:49 -!- kanru` [~kanru@118-163-10-190.HINET-IP.hinet.net] has quit [Ping timeout: 256 seconds] 10:40:46 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Remote host closed the connection] 10:41:33 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 10:50:24 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 11:03:35 -!- Strigoides [~owen@114-134-0-113.lightwire.co.nz] has quit [Quit: leaving] 11:04:34 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 11:12:32 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 11:25:58 nicdev` [user@2600:3c03::f03c:91ff:fedf:4986] has joined #sbcl 11:26:12 -!- nicdev [user@2600:3c03::f03c:91ff:fedf:4986] has quit [Remote host closed the connection] 12:24:05 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 12:30:30 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 12:42:15 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 12:51:24 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 12:59:59 drmeister [~drmeister@166.137.84.99] has joined #sbcl 13:04:16 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 13:13:54 -!- drmeister [~drmeister@166.137.84.99] has quit [Remote host closed the connection] 13:22:29 nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has joined #sbcl 13:23:07 G'morning all. 13:23:34 hi nyef 13:28:34 So, the two big questions on my mind are: Are we in code freeze yet, and did that modular-cut-constant-to-width or whatever it was bug get fixed? 13:29:52 Krystof: have you had time to look at the patch? 13:30:07 (and to confirm that it fixes things on x86/no-signed-modarith?) 13:32:20 drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has joined #sbcl 13:33:23 nyef: or can you try to apply http://paste.lisp.org/display/137260#3, if builds aren't glacially slow? 13:33:50 wbooze [~wbooze@xdsl-87-79-250-69.netcologne.de] has joined #sbcl 13:33:59 Builds are about 40 minutes, but I can set it running and work on something else. 13:37:19 Building now, I'll let you know how it goes. 13:37:26 good, thank you. 13:42:42 segv- [~mb@95-91-241-76-dynip.superkabel.de] has joined #sbcl 13:55:49 sorry, no, maybe this evening 13:55:50 -!- drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has quit [Read error: Connection reset by peer] 13:56:03 drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has joined #sbcl 14:05:36 -!- drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has quit [Ping timeout: 256 seconds] 14:07:49 drmeister [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 14:11:54 ... I was checking email earlier today, and found a patch for not disassembling unboxed constants on x86oids, based on an approach originally suggested by me... And I'm having trouble remembering the suggestion. What was it? (-: 14:15:34 attila_lendvai [~attila_le@92.46.3.157] has joined #sbcl 14:15:34 -!- attila_lendvai [~attila_le@92.46.3.157] has quit [Changing host] 14:15:34 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 14:15:44 look for the lowest forward RIP-rel address to determine where inline constants begin 14:16:49 Ah, cool. 14:17:04 Wouldn't work worth a damn if we had boxed return addresses, of course. 14:17:42 in a sane calling convention, they would be easily detected, no? 14:19:43 I think it'll help x86-64, but if you think the approach is completely broken for other platforms, maybe there's another way... 14:20:28 Right, they'd only appear in LEA instructions, and wind up computing an address with OTHER-POINTER-LOWTAG, and the corresponding object header would have LRA-LOWTAG, and the header value would be the word index (or was it doubleword index?) of the header within the code object. 14:21:01 That's sufficiently strict that it's unlikely to match any valid inline constants... unless you're packing sub-word constants tightly. 14:21:14 And even THEN it'd be rare. 14:24:28 and we already treat LEA specially when annotating 14:27:30 compiler.pure or compiler.impure? 14:27:40 *nyef* runs them both. 14:31:01 Looks good to a first approximation. Running the full suite now. 14:35:36 ugh. "The value NIL is not of type SB-C::IR2-LVAR." 14:36:22 of course it isn't! 14:36:24 silly compiler 14:38:45 hm. So, it's in %compile of a function. Then calls compile-component of, I think, the first inline function used within. and dies in there. 14:42:31 backtrace? 14:42:59 0: (SB-C::LVAR-RESULT-TNS # (#)) 14:43:13 1: (SB-C::IR2-CONVERT-TEMPLATE # 2: (SB-C::IR2-CONVERT-BLOCK #) 14:44:55 So, I suppose lvar-info of that guy was nil instead of being an ir2-lvar. 14:45:39 looks like 14:49:42 oh no... do you have an array lookup that's actually not used in that function? 14:49:55 That's it's entirely possible. 14:50:14 afaict, we have no logic to handle live VOPs whose result is unused. 14:50:29 and data-vector-ref-with-offset isn't marked as flushable. 14:51:27 because, I guess it isn't when we can't optimise it to a VOPs. 14:52:31 nope, it should be. 14:53:13 foom: can you try with data-vector-ref-with-offset marked flushable in fndb? 14:53:37 okay, trying. 15:03:29 Posterdati [~antani@host89-93-dynamic.19-79-r.retail.telecomitalia.it] has joined #sbcl 15:09:56 PPC tests look good across the board... Or, at least, not bad. 15:11:00 foom: a reasonably-sized test case would be awesome, of course (: 15:11:17 SLEEP still conses on 32-bit targets, RECHECK-NESTED-DX-BUG still only passes on conservative-stack targets, (TIMER PARALLEL-UNSCHEDULE) is still listed as broken... And (WALK-LET* HAIRY-SPECIALS) still appears twice. 15:11:32 And, of course, the two packages failures. 15:16:35 pkhuong: that didn't help. I'll see if I can minimize the failure case. 15:20:20 foom: or http://paste.lisp.org/display/137277, maybe. 15:29:08 but why did this just start happening? 15:29:31 Bisect, or did you do that already? 15:31:52 46602bb31b943b1793da732781586c032333c907 <- *might* be this commit 15:32:06 but it looks like it could be a long latent bug 15:32:28 haven't bisected yet. 15:33:17 bisect is annoying, because i need to merge after every step. 15:33:24 is there a trivial way to do that? 15:34:03 I know git can call a script to automate bisection. No clue how 15:34:30 oh look, it even has an example 15:45:09 -!- scymtym [~user@89.31.118.161] has quit [Ping timeout: 248 seconds] 15:47:13 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 276 seconds] 15:47:38 -!- drmeister [~drmeister@farnsworth.chem.temple.edu] has quit [Remote host closed the connection] 15:50:30 drmeister [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 15:51:19 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 16:26:20 -!- nicdev` is now known as nicdev 16:28:45 -!- drmeister [~drmeister@farnsworth.chem.temple.edu] has quit [Read error: Connection reset by peer] 16:36:42 *stassats`* slightly reduces consing in SLEEP on 32-bit by using (load-time-value 1e-9 t) instead of 1e-9 and saying "really?" 16:39:20 so, non-immediate floats can't be heap-allocated at compile-time 16:39:34 (that's not limited to x86, x86-64 has the same thing) 16:39:47 attila_lendvai1 [~attila_le@92.46.3.157] has joined #sbcl 16:39:47 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 16:39:47 -!- attila_lendvai1 [~attila_le@92.46.3.157] has quit [Changing host] 16:39:47 attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:45:10 x86-64 has immediate single-floats, though. 16:45:27 not double floats 16:45:31 True. 16:46:50 At least sb-unix:nanosleep or whatever the function is doesn't cons anymore, right? 16:47:43 right 16:49:15 -!- attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 16:49:19 attila_lendvai [~attila_le@92.46.3.157] has joined #sbcl 16:49:19 -!- attila_lendvai [~attila_le@92.46.3.157] has quit [Changing host] 16:49:19 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:50:22 attila_lendvai1 [~attila_le@92.46.3.157] has joined #sbcl 16:50:22 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 16:50:22 -!- attila_lendvai1 [~attila_le@92.46.3.157] has quit [Changing host] 16:50:22 attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:54:50 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:56:46 -!- attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 276 seconds] 16:57:04 attila_lendvai1 [~attila_le@92.46.3.157] has joined #sbcl 16:57:04 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 16:57:05 -!- attila_lendvai1 is now known as attila_lendvai 16:57:12 -!- attila_lendvai [~attila_le@92.46.3.157] has quit [Changing host] 16:57:12 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:58:17 attila_lendvai1 [~attila_le@92.46.3.157] has joined #sbcl 16:58:17 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 16:58:17 -!- attila_lendvai1 [~attila_le@92.46.3.157] has quit [Changing host] 16:58:17 attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:12:09 aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #sbcl 17:13:40 -!- teggi [~teggi@113.172.56.137] has quit [Remote host closed the connection] 17:16:01 what's required to add a completely new architecture foo to sbcl? I've noticed: src/assembly/foo and src/compiler/foo and src/runtime/foo*.c 17:17:29 slyrus [~chatzilla@adsl-99-183-240-185.dsl.pltn13.sbcglobal.net] has joined #sbcl 17:19:42 knowledge of SBCL and the architecture 17:22:16 time 17:22:34 usually also some staring at instruction sequences and register contents in the debugger 17:25:37 one way to ease sleep problems, add a transform for (sleep constant-float) => (nano-sleep seconds nanoseconds) 17:27:36 "optimization: faster SLEEPing" 17:41:53 attila_lendvai [~attila_le@92.46.3.157] has joined #sbcl 17:41:53 -!- attila_lendvai [~attila_le@92.46.3.157] has quit [Changing host] 17:41:53 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:42:26 -!- attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 17:46:32 and transforming suitable integers and floats directly to sb-unix:nanosleep gets rid of consing 17:49:22 and it's also faster 17:49:51 grepping various sources, literal arguments to sleep are quite common 17:51:39 faster, and more precise consequently 17:54:33 so, anybody have any ideas on how to reduce for not inline definitions? 17:55:51 drmeister [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 17:59:59 one way is inlining everything it calls for splitting a float into seconds and nanoseconds 18:00:47 prxq [~mommer@mnhm-5f75f6d4.pool.mediaWays.net] has joined #sbcl 18:08:59 -!- slyrus [~chatzilla@adsl-99-183-240-185.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 256 seconds] 18:11:08 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 18:11:57 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 18:19:03 here's the thing i came up with: http://paste.lisp.org/display/137279 18:19:33 assuming that single-floats come more often and that not consing matters only for sub-second sleeps 18:19:59 <|3b|> just declaring FRAC to be single-float seems to get rid of a good chunk of the consing 18:20:25 the pasted above thing gets rid of it completely 18:20:38 for single-floats only 18:20:44 for small single-floats, that is 18:21:06 *|3b|* gets consing from just nanosleep though, so possibly i'm testing wrong anyway 18:21:16 <|3b|> (or my 32bit sbcl is too old) 18:21:53 * 567588a..: Nikodemus Siivola 2011-08-16 non-consing NANOSLEEP 18:23:05 the pasted function can of course be made non-consing for double-floats, large single-floats, but i was trying to struck a balance between consing, code size and simplicity 18:24:05 and a transform should pick up literal things, which should cover most case 18:25:40 <|3b|> heh, downloaded most recent 32 bit linux binary, and it conses even more :p 18:26:35 nanosleep or sleep? 18:26:42 <|3b|> both 18:26:52 linux? 18:26:55 <|3b|> 'most recent' is 1.0.58 though 18:27:00 <|3b|> yeah 18:27:20 the "non-consing NANOSLEEP" commit is in 1.0.52 18:27:34 anyhow, it doesn't cons for me on 1.1.7.most-positive-commit 18:29:46 and i'll think about committing this after the freeze 18:32:41 foom: well, good neds, looks like someone's replicated your problem.. with clsql 18:35:13 (good news as well) 18:35:31 put it https://github.com/stassats/sbcl/commit/855460976f48424e5e917f6be4a4010f61344619 in the meantime 18:47:19 hm, it seems to cons even more with ratios 18:48:05 narrowed it down to smarter if/if convresion 18:48:08 *conversion 18:53:52 davazp [~user@92.251.196.202.threembb.ie] has joined #sbcl 19:00:29 well, the really nice thing about using ir1 hacking utilities is that you never know if you misused a function or the function was wrong. 19:01:00 I'm gnoing with the latter in this instance: delete-lvar-use didn't mark the deleted use for potential dead-code elimination. 19:01:39 (also, maybe we should unconditionally run a DCE pass before codegen) 19:04:50 *stassats`* added a case for ratios too http://paste.lisp.org/display/137279#1 19:05:48 has a benefit of being more exact as well 19:12:32 foom: http://paste.lisp.org/display/137277#1 fixes the clsql one. 19:23:40 -!- wbooze [~wbooze@xdsl-87-79-250-69.netcologne.de] has quit [Ping timeout: 276 seconds] 19:24:38 this is so exciting 19:24:41 105 commits and counting 19:25:47 pkhuong: would you still like confirmation of your patch on x86 with the fixnum modarith path removed? 19:35:59 slyrus [~chatzilla@adsl-99-183-240-185.dsl.pltn13.sbcglobal.net] has joined #sbcl 19:38:57 -!- davazp [~user@92.251.196.202.threembb.ie] has quit [Ping timeout: 256 seconds] 19:43:24 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 245 seconds] 19:56:54 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 20:03:28 is it me, or there is no way to bypass debugger programmatically, without unwinding, without disabling the debugger? 20:03:57 What are you trying to do, and can it be done with HANDLER-BIND? 20:04:14 to explain.. C function "c_foobar" needs to do its own unwinds 20:04:22 it correctly returns -1 and EINTR when any of system calls in it do same 20:04:50 Wait, wait... you're expecting host unwind interop? 20:04:50 so far so good.. Now, since EINTR is caused by SBCL's GC, I got to ignore it in most cases 20:04:59 just a sec let me finish explaining 20:05:36 so I put code to call c_foobar in a loop, if we got EINTR, everything works great, GC is now no problem 20:05:50 but lets say I want to run a server and correctly exit on Ctrl-C 20:06:24 I add handler-bind, which is invoked from inside of SIGINT handler, the c_foobar is still on the stack 20:06:46 from handler-bind, I have choices. a) Transfer control b) set a flag variable 20:07:18 because I know that c_foobar requires some cleanup, I can't use option a). It works, but c_foobar cleanup won't run 20:07:54 so I use option b) at which point SBCL enters debugger 20:08:12 I can click "continue" in the debugger 20:08:16 There's a restart to return from SIGINT, surely? 20:08:24 Have a look at FIND-RESTART and INVOKE-RESTART. 20:08:25 but inside of handler-bind, "continue" restart is not available 20:08:33 that is exactly what I was trying to do 20:08:38 Hrm. 20:08:49 but it seems SBCL calls (signal condition), and only then makes a continue restart 20:09:11 ... Lovely. That actually sounds like a bug. 20:09:17 look at sigint-handler in target-signal.lisp 20:09:33 I'd rather not, TBH. I've had to mess with that part of the code before. 20:09:54 well, are we boys or are we men? :-) 20:10:29 from handler-bind (COMPUTE-RESTARTS): (#) 20:10:42 from debugger (# # 20:11:11 pkhuong: My bisect concurred. the if/if commit broke it. 20:11:18 its coz it calls (signal c) and then (%break), and its the (%break) which does with-simple-restart 20:11:18 In my case, I'm BUSY, and am only going to be able to leave the office this evening in time to get to boston lisp meeting because a third party managed to screw up their side of what I'm supposed to be working on. 20:11:45 its not something I expect fixed overnight, just saying it seems like an oversight 20:12:20 I can submit a patch if you guys want, but with such system code, it seems you would want to do a fix yourselfs 20:13:09 maxm: you can set your own SIGINT handler 20:13:15 where do I log this, so it does not get lost? mailing list post, or such? 20:13:48 foom: yes, but it won't be portable. Portable code would expect "continue" to be available, if it is in the debugger? 20:14:02 you can disable the debugger too, which I highly recommend if you're not interactive 20:14:17 You used "portable code" and "debugger" in the same phrase 20:14:39 Those do not go together 20:14:53 well I'm actually writing patches to PZMQ, (the ones that auto-resume zmq calls on EINTR), and wanted to provide example on how to cleanly exit from a server loop via Ctrl-C 20:15:07 Honestly, my servers all have REPLs, C-c winds up in the debugger, and C-d exits... And the actual servery bits run in separate threads anyway. 20:15:40 and if you hit a condition that invokes the debugger, your server just hangs and waits for you? 20:17:22 well while debugging your server yes.. But it would be nice if HANDLER-BIND had a way to indicate that debugger should not be invoked, without unwinding C stack 20:19:59 maxm: Sounds like what you want is that CONTINUE restart, and you know where to patch it in. 20:21:11 My server has a handler-bind fairly high up in the stack that catches ERROR, takes a backtrace, stuffs everything into the database, and returns a suitably-encoded response to the inbound request. It only seems to go badly wrong when the database Isn't There. 20:21:52 ok, I'll send patch.. heh but your every patch requires a test case, have to think on how to write it 20:22:52 Not always, just usually. 20:23:12 what website you run out of curiosity, is it some commercial startup or just personal blog or such? 20:23:19 It's a startup. 20:23:22 unless super-secret 20:23:55 My server runs the backend, there's another server that does the website, and there are mobile client apps. 20:24:12 what guys do you use, hunchenhoot or all custom stuff? 20:24:33 you should like write a nice post describing your stack, I always have fun reading such 20:25:50 in a startup there's not normally time for luxury stuff like "blogging" or "sleep" 20:26:47 Mmm. I'm already in a position where I've spent too much time SBCL hacking this week (blasphemy!) and having to scramble to catch up. 20:26:55 well I remember nyef talking about it like 1 or 2 years ago, so I assume its more of a "most of stuff is coded" stage 20:27:15 "Major new project under development. Two, in fact." 20:28:32 so is the name secret? just wanted to look at how something nice done with SBCL looks thats all 20:29:31 "Quickable". Please note that all of the SBCL magic is on the backend. 20:30:14 Krystof: well, if you have time. I'd rather have eyeballs on it than another build though ;) 20:31:16 nyef: thats looks very nice 20:31:59 pkhuong: the idea looked sound to me; I still don't understand how any constant replacement in modarith worked ever 20:32:12 I have not checked the details 20:32:24 tell you what, I'll check the details tomorrow morning 20:32:32 so no freeze until tomorrow? (: 20:32:37 clearly! 20:32:50 Oh, freeze, just have an exception for this one patch. 20:33:12 I have two regressions and a half with patches ready 20:33:13 freeze, apart from this clearly obviously right patch that's not at all scary 20:33:39 foom's bug, modarith and PCL being too chatty 20:33:55 patch away; I'll freeze tomorrow for release mid next week 20:34:12 k. 20:34:25 if we're getting bug reports from people trying to use HEAD (or even just building bits of quicklisp) I am less scared 20:36:27 forcibly running a DCE pass at the end of ir1opt because otherwise we confuse IR2 (potentially with flamage if *check-consistency* is on). yes/later/no? 20:38:20 later 20:38:26 save something for next month ;-) 20:38:34 unless you have a test case 20:40:13 no... it was just the workaround I found before fixing delete-lvar-use 20:40:24 ASau` [~user@p4FF965AB.dip0.t-ipconnect.de] has joined #sbcl 20:40:58 -!- ASau [~user@p5797FB60.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 20:43:08 -!- ASau` is now known as ASau 20:43:53 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 20:45:57 -!- slyrus [~chatzilla@adsl-99-183-240-185.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 256 seconds] 20:54:11 -!- nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 20:54:42 slyrus [~chatzilla@adsl-99-183-240-185.dsl.pltn13.sbcglobal.net] has joined #sbcl 21:14:51 -!- slyrus [~chatzilla@adsl-99-183-240-185.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 256 seconds] 21:17:59 slyrus [~chatzilla@adsl-99-183-240-185.dsl.pltn13.sbcglobal.net] has joined #sbcl 21:25:00 davazp [~user@31.200.179.234] has joined #sbcl 21:25:46 -!- drmeister [~drmeister@farnsworth.chem.temple.edu] has quit [Remote host closed the connection] 21:31:49 davazp` [~user@31.200.179.50] has joined #sbcl 21:34:07 -!- davazp [~user@31.200.179.234] has quit [Ping timeout: 264 seconds] 21:34:23 -!- prxq [~mommer@mnhm-5f75f6d4.pool.mediaWays.net] has quit [Quit: Leaving] 22:11:33 pkhuong: your patch from before appears to have fixed the issue, modulo the typo s/use/node/ 22:18:19 -!- slyrus [~chatzilla@adsl-99-183-240-185.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 256 seconds] 22:19:26 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 23:10:05 Bike [~Glossina@75-164-169-126.ptld.qwest.net] has joined #sbcl 23:11:08 How are thread-local dynamic variables implemented in SBCL? 23:17:57 Bike_ [~Glossina@75-175-78-193.ptld.qwest.net] has joined #sbcl 23:18:04 every symbol that is ever dynamically bound gets assigned a unique index number 23:18:50 these numbers are used to index into a thread-local array of lisp objects 23:19:32 there's a special "not bound thread-locally" value -- if an array cell contains that, the global value is used instead 23:19:49 -!- Bike [~Glossina@75-164-169-126.ptld.qwest.net] has quit [Ping timeout: 252 seconds] 23:20:25 -!- Bike_ is now known as Bike 23:22:57 and the dynamic scoping is achieved using standard shallow binding 23:31:49 -!- segv- [~mb@95-91-241-76-dynip.superkabel.de] has quit [Ping timeout: 248 seconds] 23:37:50 -!- Tribal [tribal@rcfreak0.com] has quit [Quit: Leaving] 23:38:04 jsnell_: Thank you - and there is only one of these thread-local arrays and it has an entry for every symbol? 23:38:16 They aren't broken up by package or anything like that? 23:40:51 And do you do the same thing for the symbol function value? I guess you have to do it for every mutable property of Symbols - correct?