00:01:20 or maybe i'm just misinterpreting git blame 00:01:58 fisxoj [~fisxoj@192-0-131-151.cpe.teksavvy.com] has joined #sbcl 00:03:12 *COMPILER-ERROR-BAILOUT* is use when a READ-ERROR is encountered during COMPILE-FILE 00:03:36 SUB-COMPILE-FILE binds it to a function which aborts the file 00:03:40 and there's enough resignalling magic that it doesn't show when doing compile-file or load from the repl 00:08:37 lexenvs seem to encode which restart should be signaled for which condition 00:08:56 that's resignalling magic indeed 00:09:07 s/signaled/invoked/ 00:22:10 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 00:23:20 -!- andreh [~andreh@177.133.52.29.dynamic.adsl.gvt.net.br] has quit [Quit: Quitte] 00:23:42 andreh [~andreh@177.133.52.29.dynamic.adsl.gvt.net.br] has joined #sbcl 01:01:33 lp 1219601 01:01:33 https://bugs.launchpad.net/bugs/1219601 01:02:22 scymtym_: signal-error is not needed without *compiler-error-bailout* 01:02:51 are you sure? 01:03:10 yes 01:03:30 i think it is used, for example, when you COMPILE-FILE in the REPL 01:04:45 at the beginning of SIMPLE-EVAL-IN-LEXENV 01:05:44 that can be removed 01:06:18 but that breaks the unraveling of the wrappers 01:06:48 i won't go ahead without understanding first how those wrappers are operating 01:10:52 (error (sb-int:encapsulated-condition condition)) could do a better job than invoking a restart, no confusing "signal-error" interactive restart 01:13:40 but i still fail to see how that restart is any useful as an interactive, it's invoked everywhere automatically, except for reader errors, which bail out of the compilation entirely 01:14:51 i don't it was intended for interactive invocation 01:15:04 *i don't think 01:16:15 pranavrc [~pranavrc@122.164.37.145] has joined #sbcl 01:16:22 -!- pranavrc [~pranavrc@122.164.37.145] has quit [Changing host] 01:16:22 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 01:18:10 and why does it surface only in --load? 01:18:37 LiamH [~none@96.231.222.26] has joined #sbcl 01:18:46 ah, because it doesn't go through eval? 01:19:25 seem like that 01:19:45 SIMPLE-EVAL-IN-LEXENV will automatically invoke SIGNAL-ERROR 01:19:48 right 01:19:55 as will eval-in-native-environment 01:20:35 only --load leads to READ-AS-SOURCE not being enclosed by one these 01:21:21 i can think of other ways: (sb-thread:make-thread (lambda () (load "/tmp/bla.lisp"))) 01:22:37 true 01:30:47 and LOAD calls eval for all other cases, but this error happens during READ 01:30:56 ok, everything seems to make sense now 01:32:10 but compile-file doesn't enter into the debugger in this case, just returns NIL 01:32:13 maybe LOAD should return NIL too? 01:34:10 i remember tcr doing something with them and the result wasn't good 01:34:13 or nikodemus 01:38:10 and then there's ASDF complicating things 01:38:25 i can't find anything helpful in clhs for load and the referenced issue EVAL-TOP-LEVEL:LOAD-LIKE-COMPILE-FILE 01:40:24 i guess if LOAD returned NIL on errors, then (load :if-does-not-exist nil) wouldn't work that well 01:45:44 such a simple thing, but turns it's not so easy 01:51:16 echo-area [~user@182.92.247.2] has joined #sbcl 01:57:10 and while we at it, LOAD shouldn't signal "READ error during COMPILE-FILE:" 02:15:01 -!- edgar-rft [~GOD@HSI-KBW-078-043-120-047.hsi4.kabel-badenwuerttemberg.de] has quit [Ping timeout: 268 seconds] 02:26:15 dto [~user@pool-96-252-62-13.bstnma.fios.verizon.net] has joined #sbcl 02:32:55 -!- loke [~loke@203.127.16.194] has quit [Remote host closed the connection] 02:35:13 loke [~loke@203.127.16.194] has joined #sbcl 02:39:13 -!- christoph_debian [~christoph@ppp-188-174-109-108.dynamic.mnet-online.de] has quit [Ping timeout: 246 seconds] 02:41:23 teggi [~teggi@123.20.116.221] has joined #sbcl 02:52:39 christoph_debian [~christoph@ppp-188-174-14-217.dynamic.mnet-online.de] has joined #sbcl 03:01:42 -!- LiamH [~none@96.231.222.26] has quit [Quit: Leaving.] 03:05:09 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 03:06:41 -!- xymox [lechuck@unaffiliated/contempt] has quit [Ping timeout: 245 seconds] 03:08:22 xymox [lechuck@unaffiliated/contempt] has joined #sbcl 03:30:17 edgar-rft [~GOD@HSI-KBW-078-043-120-047.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 03:39:30 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds] 03:44:18 -!- fisxoj [~fisxoj@192-0-131-151.cpe.teksavvy.com] has quit [Ping timeout: 264 seconds] 03:51:09 -!- edgar-rft [~GOD@HSI-KBW-078-043-120-047.hsi4.kabel-badenwuerttemberg.de] has quit [Quit: conversation closed by nothing] 04:00:28 -!- scymtym_ [~user@ip-5-147-120-181.unitymediagroup.de] has quit [Ping timeout: 268 seconds] 04:03:32 stassats [~stassats@wikipedia/stassats] has joined #sbcl 04:08:39 Hmm, the SBCL manual doesn't document (or even mention) SB-SEQUENCE. Is there any documentation for it anywhere? 04:09:42 the paper by Krystof 04:11:32 and of course, the source 04:18:02 Got a link to the paper? 04:18:08 joshe: Of course 04:42:45 -!- dto [~user@pool-96-252-62-13.bstnma.fios.verizon.net] has quit [Remote host closed the connection] 05:11:49 -!- yacks [~py@103.6.159.99] has quit [Read error: Operation timed out] 05:12:32 -!- eeezkil [~eeezkil@unaffiliated/eeezkil] has quit [Quit: ^D] 05:13:26 yacks [~py@103.6.159.99] has joined #sbcl 05:24:25 sdemarre [~serge@109.134.165.148] has joined #sbcl 05:36:41 -!- sdemarre [~serge@109.134.165.148] has quit [Ping timeout: 245 seconds] 05:39:33 prxq [~mommer@mnhm-4d011a25.pool.mediaWays.net] has joined #sbcl 05:41:01 -!- yacks [~py@103.6.159.99] has quit [Quit: Leaving] 06:02:16 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 06:10:58 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Ping timeout: 245 seconds] 06:47:38 edgar-rft [~GOD@HSI-KBW-078-043-120-047.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 07:05:29 benkard [~benkard@2a01:198:6d5:0:9c5e:7e08:f3c4:5e73] has joined #sbcl 07:16:09 jdz [~jdz@85.254.212.34] has joined #sbcl 07:29:15 prxq_ [~mommer@mnhm-5f75c469.pool.mediaWays.net] has joined #sbcl 07:30:14 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 240 seconds] 07:32:13 -!- prxq [~mommer@mnhm-4d011a25.pool.mediaWays.net] has quit [Ping timeout: 245 seconds] 08:12:05 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 245 seconds] 08:18:17 -!- benkard [~benkard@2a01:198:6d5:0:9c5e:7e08:f3c4:5e73] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 08:18:30 benkard [~benkard@2a01:198:6d5:0:9c5e:7e08:f3c4:5e73] has joined #sbcl 08:28:16 oleo_ [5098faa7@gateway/web/freenode/ip.80.152.250.167] has joined #sbcl 08:28:20 morning 09:31:02 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 240 seconds] 09:33:14 -!- benkard [~benkard@2a01:198:6d5:0:9c5e:7e08:f3c4:5e73] has quit [Ping timeout: 264 seconds] 09:35:07 benkard [~benkard@2a01:198:6d5:0:9c5e:7e08:f3c4:5e73] has joined #sbcl 09:36:26 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 10:02:30 -!- benkard [~benkard@2a01:198:6d5:0:9c5e:7e08:f3c4:5e73] has quit [Ping timeout: 245 seconds] 10:05:16 benkard [~benkard@2a01:198:6d5:0:9c5e:7e08:f3c4:5e73] has joined #sbcl 10:08:23 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Quit: Ping timeout: ] 10:12:12 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 10:17:50 hydan [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has joined #sbcl 10:25:55 -!- andreh [~andreh@177.133.52.29.dynamic.adsl.gvt.net.br] has quit [Quit: Quitte] 10:47:16 yacks [~py@103.6.159.99] has joined #sbcl 11:29:10 pranavrc [~pranavrc@122.164.37.145] has joined #sbcl 11:29:10 -!- pranavrc [~pranavrc@122.164.37.145] has quit [Changing host] 11:29:10 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 11:41:36 -!- teggi [~teggi@123.20.116.221] has quit [Remote host closed the connection] 11:41:58 teggi [~teggi@123.20.116.221] has joined #sbcl 11:44:24 ASau` [~user@p4FF96E41.dip0.t-ipconnect.de] has joined #sbcl 11:45:18 attila_lendvai [~attila_le@62-165-243-178.pool.digikabel.hu] has joined #sbcl 11:45:18 -!- attila_lendvai [~attila_le@62-165-243-178.pool.digikabel.hu] has quit [Changing host] 11:45:18 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:46:43 davazp [~user@178.167.171.178.threembb.ie] has joined #sbcl 11:47:23 -!- ASau [~user@p4FF969B1.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 12:12:03 -!- teggi [~teggi@123.20.116.221] has quit [Remote host closed the connection] 12:37:19 -!- hydan [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has quit [Remote host closed the connection] 12:48:50 -!- oleo_ [5098faa7@gateway/web/freenode/ip.80.152.250.167] has quit [] 13:12:28 Odyessus [~odyessus@guest-wlan.highway.telekom.at] has joined #sbcl 13:22:28 stassats [~stassats@wikipedia/stassats] has joined #sbcl 13:25:00 -!- Odyessus [~odyessus@guest-wlan.highway.telekom.at] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] 13:33:24 Odyessus [~odyessus@guest-wlan.highway.telekom.at] has joined #sbcl 13:52:30 Odyessus_ [~odyessus@089144192036.atnat0001.highway.a1.net] has joined #sbcl 13:53:02 -!- Odyessus [~odyessus@guest-wlan.highway.telekom.at] has quit [Ping timeout: 264 seconds] 14:05:59 -!- Odyessus_ [~odyessus@089144192036.atnat0001.highway.a1.net] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] 14:15:24 Odyessus [~odyessus@089144192036.atnat0001.highway.a1.net] has joined #sbcl 14:16:37 loke: there is a luanchpad bug for sequence documentation (with patch) 14:16:38 lp 994528 14:16:38 https://bugs.launchpad.net/bugs/994528 14:32:40 -!- yacks [~py@103.6.159.99] has quit [Ping timeout: 260 seconds] 14:34:46 mncoder [~mncoder@c-107-2-68-72.hsd1.mn.comcast.net] has joined #sbcl 14:35:00 -!- mncoder [~mncoder@c-107-2-68-72.hsd1.mn.comcast.net] has left #sbcl 14:35:06 mncoder [~mncoder@c-107-2-68-72.hsd1.mn.comcast.net] has joined #sbcl 14:46:23 -!- Odyessus [~odyessus@089144192036.atnat0001.highway.a1.net] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] 14:47:13 Odyessus [~odyessus@089144192036.atnat0001.highway.a1.net] has joined #sbcl 14:51:32 yacks [~py@103.6.159.99] has joined #sbcl 14:55:40 -!- drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 14:56:07 drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has joined #sbcl 15:07:55 I'd like to be able to distinguish some closures I generate from all other function objects. Is that possible? Can I attach a tag to a function in some way? I've tried NAMED-LAMBDA, but the function name seems to be overwritten by something else at some point. 15:11:36 -!- Odyessus [~odyessus@089144192036.atnat0001.highway.a1.net] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] 15:16:53 Odyessus [~odyessus@089144192036.atnat0001.highway.a1.net] has joined #sbcl 15:19:59 works here. 15:20:19 is this for debugging or normal operations? 15:22:45 Something in-between. My interpreter generates closures that the debugging code needs to be able to detect to generate meaningful debugger frame objects. 15:23:59 Also, I want to attach source location information to the generated closures. 15:25:13 I've been using a weak hash table until now, but it slows the code down pretty badly. 15:25:56 you could use a specific class of funcallable instance for them 15:26:14 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Read error: No route to host] 15:26:27 -!- Odyessus [~odyessus@089144192036.atnat0001.highway.a1.net] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] 15:28:32 Hm, yes. I suspect that might also turn out to be a performance bottleneck. But I haven't tried it yet, so I'll do that now. 15:29:00 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 15:32:42 funcallable instances won't work 15:33:00 as the instance won't be accessible in the debugger 15:34:37 Oh. Right. 15:36:24 I wonder why my hack for storing the original closure pointer on the stack + adding the necessary debug information stopped working for you (haven't tried running your tree yet, sorry) 15:36:52 Also, it's strange how the function name changes. After loading gabriel.olisp from cl-bench, (sb!kernel:%fun-name #'cl-bench.gabriel:browse) gives me (MACRO-FUNCTION CL-BENCH.GABRIEL::CTIMES). It doesn't seem to make sense. 15:37:03 teggi [~teggi@123.20.116.221] has joined #sbcl 15:37:57 Does DEFMACRO overwrite the function name of the %fun-fun of its macro function? 15:39:37 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 15:43:18 not something I'd expect it to do, but it seems like a plausible hypothesis given the result :-) 15:44:50 jsnell_: By the way, the bytecode branch isn't as hopelessly inefficient as I thought it was. The weak hash tables were skewing the results. :) 15:45:50 yes. it sets %fun-name. 15:48:15 cool. I actually hadn't noticed the work on that due to insufficient github stalking skills (there must be some way to see all activity in a repo, not just activity on a given branch) 15:54:15 -!- drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 15:54:38 setting %fun-name looks vestigial to me, the named-lambda in the defmacro expansion should be enough. but the other stuff set by %defmacro on the function object / infodb would be equally problematic and can't be fixed as simply 15:54:42 I don't understand why we first compile a named lambda with name (defmacro foo), and then rename its to (macro-function foo) in %epander for defmacro. 15:55:03 -typos. +coffee for me. 15:55:29 a bit of a shame if defmacro would need to be aware of the interpreter 15:57:05 I could patch %fun-name. Hmm... A weak hash table wouldn't be all that bad for that, I guess. 15:58:54 I think making %defmacro not set %fun-name, and just have the correct name in the defmacro expansion would be better 16:00:49 But wouldn't it be good for (eval '(named-lambda foo ())) to have a %fun-name of FOO? Right now, all interpreted functions share a function name. 16:01:26 it'd be good for all the %fun-* accessors to be aware of the new interpreter 16:02:54 it's just that for this particular case it's silly for defmacro to name a function and then immediately rename it 16:04:15 drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has joined #sbcl 16:04:21 (hmm... surprising that the ansi-test documentation tests weren't failing due to this) 16:04:25 Odyessus [~odyessus@089144192036.atnat0001.highway.a1.net] has joined #sbcl 16:07:44 (so "would be better" as in "in addition, even if fixing %fun-* hides the duplicate work done by defmacro", not "instead of") 16:09:13 -!- drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 16:09:20 (OK :)) 16:14:52 fisxoj [~fisxoj@192-0-131-151.cpe.teksavvy.com] has joined #sbcl 16:16:27 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:18:52 drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has joined #sbcl 16:38:48 -!- yacks [~py@103.6.159.99] has quit [Read error: Connection reset by peer] 16:38:56 yacks [~py@103.6.159.99] has joined #sbcl 16:43:52 -!- Odyessus [~odyessus@089144192036.atnat0001.highway.a1.net] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] 16:48:20 davazp` [~user@178.167.171.178.threembb.ie] has joined #sbcl 16:49:19 -!- davazp [~user@178.167.171.178.threembb.ie] has quit [Remote host closed the connection] 16:55:42 i'm a bit confused by sb-impl::index: 1) the maximum value, (1- array-dimension-limit), seems too large since (make-array (1- array-dimension-limit)) is the largest (1d) array (maybe lists can be longer than 1d arrays?) 2) the comment claims array-dimension-limit = most-positive-fixnum which seems to be false (on x86) 3) the comment says "ANSI specifies it as an exclusive bound" but ANSI seems to refer to array size not indices within 16:55:42 arrays (in make-array and "valid array dimensions") 16:55:47 am i missing something? 17:10:18 scymtym: every dimension must be less than a-d-l. 17:10:54 so (make-array (1- a-d-l)) respects that restriction. 17:11:33 pkhuong: yes, and doesn't that imply that an index can at most be (- a-d-l 2)? 17:11:34 what comment claims that a-d-l = m-p-f? 17:12:12 the comment above sb-impl:index 17:13:08 I think if we fix that, we'll find bugs in code that abuses INDEX as for sequence lengths. 17:14:15 pkhuong: that's how i started looking :) 17:14:45 -!- ASau` is now known as ASau 17:15:06 the index comment refers to an old value of a-d-l. I don't know how I feel about artificially restricting bitvector sizes ;) 17:15:38 Yay! #'cl-bench.gabriel:browse => # 17:15:57 nice. 17:17:14 scymtym: easier to fix the comment than to fix the code, I'd think. 17:18:59 very likely 17:19:27 the downside could be missing some statically detectable bounds violations 17:20:09 -!- teggi [~teggi@123.20.116.221] has quit [Remote host closed the connection] 17:20:49 i'll try to write a new comment 17:22:32 benkard: I tried the HEAD from your master branch, but native-environment->context appears to be undefined. is there a good version to check out? 17:23:40 jsnell_: Try the bytecode branch, it's what I'm working on right now. 17:24:25 ok 17:24:56 jsnell_: But the master branch should be usable. Hmm. Maybe I forgot to backport a patch. 17:26:26 Oh. I need to patch function-lambda-expression in addition to the %fun- accessors. Makes me wonder whether there are other places that need adapting. 17:29:18 -!- yacks [~py@103.6.159.99] has quit [Ping timeout: 245 seconds] 17:34:00 benkard: grep for #!+sb-eval (: 17:34:42 Hmm. Sounds sensible. :) 17:34:49 -!- davazp` [~user@178.167.171.178.threembb.ie] has quit [Remote host closed the connection] 17:37:33 yacks [~py@103.6.159.99] has joined #sbcl 17:38:14 Ah, yes. That reminds meI had a question about those read-time conditionals. Why is using #-sbcl an error, and is there a workaround? 17:38:43 (A workaround that keeps the code portable, that is.) 17:43:47 benkard: it's hard to make bootstrappy code portable. 17:44:02 #-sbcl will be disabled if the cross-compilation host isn't sbcl. 17:44:13 Ah. 17:45:19 I see. So I should just use #! and define it myself on other platforms. 17:56:12 I don't know if people will be stoked about an evaluator hooking into their readtable just for #!. It's probably easiest to factor the differences out into a couple files. 17:57:31 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 18:03:33 I've mostly done that, but I suspect Emacs will be confused when I put the in-package form behind a macro. That said, I could use "SB!EVAL" even on non-SBCL systems and nickname the problem away. 18:04:45 sometimes copy paste or text substitution is the best solution. 18:08:45 -!- yacks [~py@103.6.159.99] has quit [Ping timeout: 245 seconds] 18:11:44 yacks [~py@103.6.159.99] has joined #sbcl 18:20:33 pkhuong: would http://paste.lisp.org/display/138734 be ok? 18:21:36 benkard: a couple of points re: the latest changes 18:22:22 first, it might be better not to use the term "interpreted-function" for something that doesn't actually match the CLHS definition for an "interpreted function" 18:22:31 -!- yacks [~py@103.6.159.99] has quit [Ping timeout: 245 seconds] 18:22:59 since these are minimally compiled 18:24:18 scymtym: indexing into sequence, I think? 18:25:54 jsnell_: That's true. I can't think of a good term, but something can surely be found. 18:26:23 second, there are actually two kinds of closures created by the evaluator. there are ones that actually represent a user-created function, and there are ones that correspond to evaluator internals 18:26:58 yacks [~py@103.6.159.99] has joined #sbcl 18:27:35 using funcallable instances for the first should be fine from a performance point of view 18:27:55 the former could reuse sb-eval's funcallable instances, and that'd immediately benefit from the preexisting scaffolding. 18:28:31 pkhuong: i'm not sure what the limits for other sequence types are according to CLHS, but in SBCL, ELT is index -> t, for example 18:28:57 so sequences instead of arrays sounds right 18:29:19 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Quit: Ping timeout: ] 18:29:42 scymtym: CLHS says integer, but our LENGTH is also specified to return INDEX, so I guess the restriction for lists and vectors carries over to sb-sequence. 18:29:52 hm, but NTHCDR is unsigned-byte -> list -> t 18:29:53 pkhuong: but then they'd be called "interpreted-functions", negating my first point :-) 18:30:29 jsnell_: right. 18:30:29 Hmm... Funcallable instances  well, it's worth a try. 18:33:27 maybe "minimally-compiled-function"? it's a bit ugly, but at least descriptive 18:33:28 pkhuong: i annotated the paste. should anything else be changed? 18:35:21 Not a bad name. 18:35:53 and a superclass for interpreted-function and minimally-compiled-function would likely help avoid code duplication. 18:38:45 scymtym: do you think the second paragraph could be confusing because the first one says the type is also used for LENGTH? Do you think my annotation is clearer? 18:38:51 either way, it's better than what we have. 18:40:08 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 18:40:59 maybe the first sentence should only mention indexing into sequences since that's the proper use of the type 18:41:45 other uses could be mentioned at the end of the second paragraph 18:42:00 and yes, the explanation you added makes sense 18:44:27 I don't expect anyone will split index and sequence-length types any time soon, so I don't really have an opinion on whether the first sentence should describe the intention or its current actual usage. 18:46:04 i agree, if sequence-length should ever become independent of INDEX, much more than that comment will have to change 19:04:41 -!- yacks [~py@103.6.159.99] has quit [Read error: Operation timed out] 19:05:43 yacks [~py@103.6.159.99] has joined #sbcl 19:10:48 -!- edgar-rft [~GOD@HSI-KBW-078-043-120-047.hsi4.kabel-badenwuerttemberg.de] has quit [Quit: lifetime finished because of unexpected error] 19:12:38 -!- milosn [~milosn@user-5af50f1f.broadband.tesco.net] has quit [Ping timeout: 245 seconds] 19:26:36 milosn [~milosn@user-5af50b07.broadband.tesco.net] has joined #sbcl 19:52:59 does --load ing the contents of http://paste.lisp.org/display/138737 from a file with current master fail for anybody else? 19:55:13 no 19:55:48 milosn_ [~milosn@user-5af50b8a.broadband.tesco.net] has joined #sbcl 19:56:17 it doesn't crash, i have no idea what would constitute a fail 19:56:20 stassats: does it print (MAKE-ENUM (:ENUM NIL)) or (MAKE-ENUM (:ENUM (:FOO :BAR)))? 19:57:06 -!- milosn [~milosn@user-5af50b07.broadband.tesco.net] has quit [Ping timeout: 264 seconds] 19:57:50 the former 19:58:04 sdemarre [~serge@109.134.165.148] has joined #sbcl 19:58:57 i think it should print the latter 19:59:06 clisp and 1.0.58 do 20:09:36 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 20:09:54 scymtym: http://paste.lisp.org/display/138737#1 20:11:04 nice reduction 20:12:27 even smaller: 20:12:57 (defmethod b (x z d &key key) key) (b t t t :key 10) 20:13:00 so, keys passed just at the beginning of the stack cause this problem 20:14:33 not really, method functions take more arguments 20:14:59 and they take them as lists? 20:15:21 Could be 3b98d369be67b42cbd823af9c6df55ac9601bfa9. 20:15:37 but the stack should still take only 3 require 20:15:40 err 20:16:10 s/stack/gf/ 20:21:43 could be my changes to copy-more-args, whoops 20:22:49 well. I'm building the revision just before the stack frame size change. If you do copy-more-args, that'll accelerate bisection ;) 20:25:14 i'm now building 002a377 (and will test on x86) 20:28:17 x86 1.1.10.9 has it too 20:28:24 so, it's not copy-args, since that was x86-64 only 20:28:51 yeah, it's regalloc 20:28:54 starting frames at size 4. 20:29:18 ... but really, if we write to random places in our stack without telling regalloc about it, who knows what else could break any day? 20:31:24 i can't make a non-pcl test-case yet 20:39:11 -!- mncoder [~mncoder@c-107-2-68-72.hsd1.mn.comcast.net] has quit [Quit: mncoder] 20:40:53 if it still matters: on x86 022a377 is bad, 44fa192 is good 20:45:28 3b98d3 is bad on x86-64. 20:45:58 Looking at the VOPs, there's some confusion regarding whether stack frame sizes include the return address and old fp or not. 20:50:05 milosn [~milosn@user-5af50c69.broadband.tesco.net] has joined #sbcl 20:51:45 attila_lendvai [~attila_le@62-165-243-178.pool.digikabel.hu] has joined #sbcl 20:51:45 -!- attila_lendvai [~attila_le@62-165-243-178.pool.digikabel.hu] has quit [Changing host] 20:51:45 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 20:51:50 -!- milosn_ [~milosn@user-5af50b8a.broadband.tesco.net] has quit [Ping timeout: 264 seconds] 20:51:57 got a pcl-less case: http://paste.lisp.org/display/138737#2 20:53:13 -!- stassats [~stassats@wikipedia/stassats] has quit [Remote host closed the connection] 20:53:30 stassats [~stassats@wikipedia/stassats] has joined #sbcl 20:53:59 more simple http://paste.lisp.org/display/138737#3 20:57:02 &more is actually not needed 20:57:36 the bug is all in d 20:58:07 (apply (compile nil `(lambda (a b c d e &rest args) args)) 1 2 3 4 5 (list :key 10)) 20:58:10 => (10 10) 20:59:10 right, no apply either 20:59:13 the least possible test case: (funcall (compile nil `(lambda (a b c d e &rest args) args)) 1 2 3 4 5 :key 10) 21:01:19 and only with 5 required 21:03:50 -!- benkard [~benkard@2a01:198:6d5:0:9c5e:7e08:f3c4:5e73] has quit [Ping timeout: 264 seconds] 21:04:51 so. I can fix the symptom by patching some arithmetic in copy-more-arg 21:05:02 but I'm really not sure it's correct 21:06:50 the ;; Initialize R8 to be the end of args. bit? 21:07:38 I don't understand why that one works yet 21:07:53 the issue seems to be that we don't grow rsp-tn enough. 21:10:23 it copies from the end, so one 10 is from the parent frame, and another one is copied down 21:10:26 i guess 21:11:29 that doesn't explain why :key is gone 21:15:39 the copy loop has an off by one. 21:15:42 -!- sdemarre [~serge@109.134.165.148] has quit [Ping timeout: 264 seconds] 21:21:06 or, at least, doesn't seem to fully agree with more-arg-context? 21:27:37 maybe the problem is actually in listify-rest-args? 21:29:52 %more-arg directly also fails 21:33:42 (d 1 2 3 4 5 :a 10) => (10 10), (d 1 2 3 4 5 :a 10 20) => (20 20 20), (d 1 2 3 4 5 :a 10 20 30) => (30 30 30 30) 21:34:43 looks like 5 arguments make it onto a point in the overlap, where it copies the last argument over and over 21:36:16 i replaced mov with LEA, the address changes, (d 1 2 3 4 5 :a 10 20 30) => (70368646556880 70368646556876 70368646556872 70368646556868) 21:36:17 so that would be copy more args 21:36:23 well, obviously 21:37:13 oh wow. there is no guarantee on whether the source is below or above the destination. 21:37:39 we'll have to switch the copy direction depending on whether # fixed > stack frame size or below 21:37:53 and nothing to do if they're equal. 21:39:04 -!- prxq_ [~mommer@mnhm-5f75c469.pool.mediaWays.net] has quit [Remote host closed the connection] 21:39:53 damn irc lag 21:39:56 my messages come out of sync 21:41:32 ok. So I think what happened is that very few functions have more than 8 fixed arguments followed by optional stuff. 21:41:45 so the copy direction was always correct. 21:43:59 yep, that's an old bug 21:44:25 -!- stassats [~stassats@wikipedia/stassats] has quit [Remote host closed the connection] 21:44:57 stassats [~stassats@wikipedia/stassats] has joined #sbcl 21:45:37 (apply (compile nil `(lambda (,@(loop repeat 9 collect (gensym)) &rest args) args)) (append (make-list 9) '(:key 10))) => (10 10) 21:45:45 -!- stassats [~stassats@wikipedia/stassats] has quit [Remote host closed the connection] 21:46:17 stassats [~stassats@wikipedia/stassats] has joined #sbcl 21:46:40 that's on an older sbcl, and on PPC as well 21:48:22 (turns out, restarting emacs solve the irc lag issue) 21:49:37 http://paste.lisp.org/display/138737#4 21:51:22 all other platforms will need to fixed as well 21:51:49 I think I can micro-optimize that to save a register. 21:51:49 although having larger stacks made it unnoticeable before 21:52:27 the offset between source and destination is known at compile-time, so only a single pointer is needed for source and destination. 21:54:43 probably nota win in code size though. 21:55:02 let's leave it as is. 22:04:29 the no copy case has a couple dead instructions, but fixing that seems more likely to introduce new bugs than to improve any existing code. 22:05:04 will you commit this today? i can deal with PPC and x86 later 22:05:53 sure, unless you want to commit for these three platforms at once. 22:06:18 We should have a log of all the fixes/improvements that we've only done on x86oids and perhaps PPC. 22:07:13 this particular thing can be tracked with a test-case 22:07:32 just generating list from 0 to, say, 1000 22:07:36 just ;) 22:09:28 i guess the x86 version can be just copied 22:09:43 but i don't want to deal with ppc tonight 22:10:11 stassats, pkhuong: thanks for your work (i have to go now) 22:10:20 your stack reduction can be, perhaps, applied to ppc too 22:10:52 scymtym: thanks for the report. 22:11:23 stassats: most probably. In fact, this fix probably explains the strange build failures I had with < 4 stack slots initially. 22:11:39 s/explains/eliminates/ 22:11:52 what are these slots used for? 22:12:26 return address, old rbp, and a magic slot (code component) that doesn't seem to be used anymore 22:15:29 copy-more-arg on x86 still uses esi/ecx from string instructions 22:16:08 bah, it's a useful mnemonic. 22:16:33 not when you have to push these registers onto the stack 22:16:51 ah ok. 22:16:54 sure. 22:17:47 it's also because the function is in a wonky state, and we have to perform regalloc by hand, in VOPs 22:17:52 otherwise arguments will be overwritten. 22:18:47 define-vop can be extended with :exclude-arg-registers 22:19:38 but x86 doesn't have much registers to play with 22:20:23 exactly 22:22:51 what if there was some extra space left on the stack so that copy-more-arg would consist only of copying the needed registers onto the stack? 22:25:40 copy-more-arg is used only for making it easier to use by other more accessing functions 22:25:58 well, regalloc could make sure that there's at least as many stack slots as there are fixed args. 22:26:06 but that would potentially make for huge stack frames. 22:26:18 and more conservative badness. 22:29:46 now that makes me wonder: what happens if we hit an interrupt in the middle of copy more args, and rsp was increased to a shorter stack? 22:30:55 won't it be restored? 22:31:41 sure, but in the meantime, the values to copy to lower stack slots (higher addresses) will have been overwritten by the handler 22:32:22 so, rsp has to be set to the right sight once? 22:32:26 size 22:32:37 it is. 22:33:04 that's the problem: for very small stack frames and many arguments, we'll read values that are below rsp. 22:35:40 so then, not using rsp as a pointer? 22:36:02 it depends on the copy direction 22:36:34 rsp should, until the copy loop is exited, be the minimum of old rsp and new rsp. 22:37:38 the good news is that I'm pretty sure we can determine which case applies by comparing fixed and (sb-allocated-size 'stack). 22:38:45 but that's for later. 23:16:25 yeah. so another fix is to leave everything in place when there are more arguments than the stack frame size. 23:16:28 and adjust more-arg-context. 23:20:13 which also avoids RSP badness. 23:33:41 scymtym_ [~user@ip-5-147-120-181.unitymediagroup.de] has joined #sbcl