00:37:15 ccl-logbot [~ccl-logbo@setf.clozure.com] has joined #sbcl 00:37:15 00:37:15 -!- names: ccl-logbot Bike ehaliewicz Quadrescence wbooze Sagane ASau`` slyrus edgar-rft pjb maxm yacks easye psilord christoph_debian milosn Subfusc daem0n Posterdati nicdev Vivitron Blkt daimrod scymtym danlentz Tribal whoops pkhuong antifuchs astertronistic bege pipping samebchase jdz _8hzp` |3b| antoszka cow-orker joshe pchrist cmm asedeno_ ivan``_ xymox foom redline6561 jsnell brucem minion specbot fe[nl]ix flip214 reb automaciej Ralt luis @Krystof 01:01:12 -!- Sagane [~Sagane@177.100-226-89.dsl.completel.net] has quit [Read error: Connection reset by peer] 01:08:19 (I, however, will not look at the RTM stuff) 01:45:44 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 01:47:57 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Read error: No route to host] 02:39:17 -!- christoph_debian [~christoph@ppp-188-174-159-247.dynamic.mnet-online.de] has quit [Read error: Operation timed out] 02:52:29 christoph_debian [~christoph@ppp-188-174-145-252.dynamic.mnet-online.de] has joined #sbcl 04:18:40 sdemarre [~serge@146.147-66-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 04:39:59 pnpuff [~ff@unaffiliated/pnpuff] has joined #sbcl 04:51:44 -!- pnpuff [~ff@unaffiliated/pnpuff] has quit [Quit: leaving] 04:53:46 pnpuff [~TrafoLa@unaffiliated/pnpuff] has joined #sbcl 05:14:10 -!- pnpuff [~TrafoLa@unaffiliated/pnpuff] has quit [Quit: leaving] 05:16:43 -!- sdemarre [~serge@146.147-66-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 264 seconds] 05:20:41 pnpuff [~coc@unaffiliated/pnpuff] has joined #sbcl 05:21:38 attila_lendvai [~attila_le@92.46.2.96] has joined #sbcl 05:21:38 -!- attila_lendvai [~attila_le@92.46.2.96] has quit [Changing host] 05:21:38 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:56:18 -!- pnpuff [~coc@unaffiliated/pnpuff] has quit [Ping timeout: 256 seconds] 06:01:41 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Read error: Connection reset by peer] 06:02:06 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 06:06:27 scymtym_ [~user@ip-5-147-122-209.unitymediagroup.de] has joined #sbcl 06:37:54 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 06:41:30 stassats [~stassats@wikipedia/stassats] has joined #sbcl 06:43:27 pnpuff [~coc@unaffiliated/pnpuff] has joined #sbcl 07:02:24 -!- yacks [~py@180.151.36.168] has quit [Read error: Connection reset by peer] 07:11:47 -!- pnpuff [~coc@unaffiliated/pnpuff] has quit [Quit: "self defined idiot bird"] 07:17:56 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Operation timed out] 07:19:33 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:22:18 pnpuff [~coc@unaffiliated/pnpuff] has joined #sbcl 07:29:29 -!- pnpuff [~coc@unaffiliated/pnpuff] has left #sbcl 07:59:33 -!- wbooze [~wbooze@xdsl-84-44-209-223.netcologne.de] has quit [Ping timeout: 246 seconds] 08:14:49 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Ping timeout: 256 seconds] 08:27:51 pranavrc [~pranavrc@122.164.130.251] has joined #sbcl 08:27:51 -!- pranavrc [~pranavrc@122.164.130.251] has quit [Changing host] 08:27:51 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 08:43:46 with four arguments, even the register-passed ones are squeezed onto the stack 08:43:49 that seems a bit strange 08:44:36 looks like local calls can only use stack for more than register-arg-count args 08:44:47 or some kind of let conversion is in play 08:50:27 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 09:33:34 sdemarre [~serge@146.147-66-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 09:35:25 yacks [~py@180.151.36.168] has joined #sbcl 09:38:35 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Quit: Ping timeout: ] 09:40:55 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 09:43:47 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 256 seconds] 10:01:05 wbooze [~wbooze@xdsl-84-44-155-240.netcologne.de] has joined #sbcl 10:46:26 -!- sdemarre [~serge@146.147-66-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 256 seconds] 11:01:30 -!- wbooze [~wbooze@xdsl-84-44-155-240.netcologne.de] has quit [Quit: none] 11:20:31 pranavrc [~pranavrc@122.164.84.169] has joined #sbcl 11:20:31 -!- pranavrc [~pranavrc@122.164.84.169] has quit [Changing host] 11:20:31 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 11:59:04 sdemarre [~serge@146.147-66-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 11:59:13 leuler [~user@p548FDC8E.dip0.t-ipconnect.de] has joined #sbcl 12:03:55 attila_lendvai [~attila_le@92.46.2.96] has joined #sbcl 12:03:55 -!- attila_lendvai [~attila_le@92.46.2.96] has quit [Changing host] 12:03:55 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 12:13:09 -!- foreignFunction [~niksaak@ip-4761.sunline.net.ua] has quit [Quit: Leaving.] 12:33:42 wbooze [~wbooze@xdsl-84-44-155-240.netcologne.de] has joined #sbcl 12:46:35 yacks [~py@180.151.36.168] has joined #sbcl 12:52:48 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 256 seconds] 13:01:11 pkhuong: re 13:01:16 lp 1180102 13:01:16 https://bugs.launchpad.net/bugs/1180102 13:01:23 i tried your WITH-SYSTEM-MUTEX suggestions and it seems to work: https://ci.cor-lab.org/job/sbcl-merge-simulator/5/ 13:03:50 scymtym_: I can't look at the diff, but that sounds good. 13:04:21 pkhuong: sorry, i will add github links 13:04:45 btw, would this "merge simulator" be generally useful? 13:05:12 it merges branches matching a certain pattern into master and attempts a build 13:05:32 for multiple featuresets and architectures 13:06:58 ("githubweb" links should work now) 13:08:02 nice. Yeah. I currently hack it with cp -r and multiple builds, but automation is awesome. 13:09:20 it can pull from arbitrary git repos as long as http transport (as opposed to git://) is supported 13:10:22 should i point it at github.com/scbl/sbcl then? 13:16:41 I don't think any of us push to any branch except master nowadays 13:19:01 well, that would kind of defeat the purpose :) 13:25:09 Sigh. I love how it says ";; As it is, this lambda must not cons until we are ready to run GC. Be very careful." and the lambda enqueues its thread object itself. 13:26:36 prxq [~mommer@mnhm-590c1392.pool.mediaWays.net] has joined #sbcl 13:28:05 the push in initial-thread-function-trampoline? 13:28:18 right. 13:28:43 yeah ... 13:31:17 but when /is/ the new thread able to run gc? 13:36:07 somewhere in with-local-interrupts, *i think* 13:36:18 -!- prxq [~mommer@mnhm-590c1392.pool.mediaWays.net] has quit [Read error: Connection reset by peer] 13:36:31 prxq [~mommer@mnhm-590c1392.pool.mediaWays.net] has joined #sbcl 14:12:50 push (and with-simple-restart?) would be too early, then 14:15:58 the proposed changes to make-thread wouldn't make that situation worse as far as i can tell 14:21:44 to avoid consing, would it be possible to add a cons to *all-threads* and then only mutate the car from the new thread? 14:23:13 hang on, for a newly-created thread surely a small amount of consing is OK -- it will only end up triggering a gc if it allocates more than the nursery generation size 14:23:56 (I'm sure this is wrong but please tell me why :-) 14:24:48 i'm not sure why "the lambda must not cons" 14:24:56 i just trusted the comment 14:28:28 gc seems to be disabled until the new thread completes its initialization - maybe it could theoretically exhaust the heap by consing? 14:40:26 -!- wbooze [~wbooze@xdsl-84-44-155-240.netcologne.de] has quit [Quit: none] 14:46:50 wbooze [~wbooze@xdsl-84-44-155-240.netcologne.de] has joined #sbcl 14:50:06 -!- sdemarre [~serge@146.147-66-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 246 seconds] 15:05:27 Krystof: the newly created thread is initialised with an empty allocation region 15:09:06 sdemarre [~serge@146.147-66-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 15:13:02 ok. So in principle opening the new allocation region could trigger a collection? 15:22:19 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 246 seconds] 15:27:49 yup. 15:29:37 -!- sdemarre [~serge@146.147-66-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 248 seconds] 15:42:16 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Quit: Ping timeout: ] 16:15:57 Odyessus [~odyessus@chello080109062130.15.14.vie.surfer.at] has joined #sbcl 16:27:45 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 246 seconds] 16:58:47 Sagane [~Sagane@177.100-226-89.dsl.completel.net] has joined #sbcl 16:59:53 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:16:00 sdemarre [~serge@146.147-66-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 17:27:53 -!- Odyessus [~odyessus@chello080109062130.15.14.vie.surfer.at] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] 17:39:38 yacks [~py@180.151.36.168] has joined #sbcl 17:41:10 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 17:49:21 wyan [~wyan@ec2-54-246-94-212.eu-west-1.compute.amazonaws.com] has joined #sbcl 17:49:34 -!- wyan [~wyan@ec2-54-246-94-212.eu-west-1.compute.amazonaws.com] has left #sbcl 17:49:41 stassats [~stassats@wikipedia/stassats] has joined #sbcl 17:50:01 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 17:52:34 davazp [~user@79.Red-79-153-96.dynamicIP.rima-tde.net] has joined #sbcl 18:01:11 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 18:08:09 attila_lendvai [~attila_le@92.47.247.82] has joined #sbcl 18:08:09 -!- attila_lendvai [~attila_le@92.47.247.82] has quit [Changing host] 18:08:09 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:31:29 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 18:33:37 ASau``` [~user@p4FF96CC6.dip0.t-ipconnect.de] has joined #sbcl 18:37:44 -!- ASau`` [~user@p4FF9635C.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds] 18:38:24 -!- leuler [~user@p548FDC8E.dip0.t-ipconnect.de] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 18:51:42 -!- foreignFunction [~niksaak@ip-4761.sunline.net.ua] has quit [Quit: Leaving.] 18:51:53 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 19:34:26 -!- prxq [~mommer@mnhm-590c1392.pool.mediaWays.net] has quit [Read error: Connection reset by peer] 19:52:15 prxq [~mommer@mnhm-590c1392.pool.mediaWays.net] has joined #sbcl 19:53:26 looks like checking for the maximum allowed number of arguments is best done at the very beginning of a XEP, otherwise all the moves and saves are unpredictable 19:57:50 stassats: that sounds sane. 19:59:10 of course, it'd be good to make them predictable and non-redundant, but that doesn't seem easy 20:00:38 actually, both min and max tests can be done early, then it doesn't need any debug information and can use RCX and registers/stack directly to get supplied args, even at low debug 20:02:49 two simple compares instead of one shouldn't cause any noticeable slow down 20:03:45 btw, is it possible that (mod ) type checks now unconditionally test for fixnumness as well? 20:04:36 it does check for fixnumness unconditionally, indeed 20:05:08 but, (mod x) is applied only to fixnum X 20:05:20 but it checks even when the argument is known to be a fixnum 20:05:54 in local calls? 20:06:24 not even a call 20:06:36 let? 20:06:37 prxq_ [~mommer@mnhm-590c1392.pool.mediaWays.net] has joined #sbcl 20:06:39 yes 20:06:55 all the other type vops do that 20:07:05 -!- prxq [~mommer@mnhm-590c1392.pool.mediaWays.net] has quit [Read error: Connection reset by peer] 20:07:41 well, i'd be happy to correct that, if i knew a straightforward way 20:07:42 ok. but mod checks used not to do that. 20:07:50 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Remote host closed the connection] 20:08:01 mod checks used to do two comparisons 20:08:13 not for unsigned values 20:11:28 -!- wbooze [~wbooze@xdsl-84-44-155-240.netcologne.de] has quit [Ping timeout: 268 seconds] 20:11:30 ok, that's something to look at 20:11:40 including the other type-vops 20:14:03 can i just dispatch on the TN? 20:14:21 wbooze [~wbooze@xdsl-78-35-129-178.netcologne.de] has joined #sbcl 20:15:00 on its primitive-type 20:15:50 but that will force tagging anyway 20:15:53 -!- sdemarre [~serge@146.147-66-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 240 seconds] 20:15:58 -!- prxq_ [~mommer@mnhm-590c1392.pool.mediaWays.net] has quit [Ping timeout: 246 seconds] 20:16:22 maybe check-type should be done through translation, not through directly invoking vops 20:16:26 just fixing it for fixnum values would already be a iwn. 20:16:29 *win 20:17:17 maybe i can stop tagging with appropriate :load-if 20:17:47 it'll become quite ugly, granted 20:27:34 hm, PRIMITIVE-TYPE doesn't look like the best thing 20:28:22 you could try to handle multiple SCs 20:28:53 what do you mean? 20:29:20 if the value is in a signed-reg or an unsigned-reg, it's certainly an integer. 20:29:36 that still leaves fixnums. 20:29:52 [un]signed-reg are not tagged, right? 20:30:15 indeed. 20:32:06 and it can be larger than a fixnum, but mod shouldn't care 20:32:18 though, it could accept larger x in (mod x) 20:33:05 and you can have the same comparison for signed and unsigned, too 20:33:08 only for signed-reg and unsigned-reg, but no way to encode that into hairy-type-check-template-name 20:33:10 I see two issues: forcing tagging of machine integers, and redundantly testing known fixnum values for fixnumness. 20:33:40 multiple SCs can help with the former. Not really for the latter. 20:34:16 fixnums have tn-primitive-type of either fixnum or positive-fixnum 20:34:31 tagged-num. 20:34:44 right, but i haven't found primitive-subtypep yet 20:34:51 there isn't any. 20:35:05 primtypes don't really work that way 20:36:55 so, do i go through (csubtypep (specifier-type (primitive-type-specifier primitive-type)) (specifier-type 'fixnum))? 20:39:52 that's a bad idea. 20:40:05 primtypes are about representation, not the value represented. 20:40:23 it works in this case, but by accident. 20:40:34 so, just compare them for fixnum or positive-fixnum? 20:40:57 yup 20:43:57 using signed-reg together with any-reg complains on can't tell whether to load with LOAD-NUMBER or LOAD-IMMEDIATE when operand is in SC IMMEDIATE 20:44:37 yes. you need to handle immediate as well 20:45:06 that's characters and static symbols? 20:45:50 could be an integer. 20:45:58 prxq [~mommer@mnhm-590c1392.pool.mediaWays.net] has joined #sbcl 20:46:02 tn-value will give you the value 20:46:25 but it's not a constant tn 20:48:08 immediate tns are constants 20:48:25 i see, but then it wouldn't invoke that vop, would it? 20:48:29 -!- davazp [~user@79.Red-79-153-96.dynamicIP.rima-tde.net] has quit [Remote host closed the connection] 20:48:35 the VOP machinery can't know that 20:49:03 won't it be subsumed by constant folding sometime earlier? 20:49:32 the VOP machinery can't know that it's complaining about a case that should never happen 20:49:59 ah, i'm not talking about complaining, but about what would happen 20:50:15 sure, hopefully. 20:50:16 as in, i shouldn't handle immediate in the body in any way 20:50:46 why not? 20:51:09 shouldn't have to 20:51:16 do i? 20:51:26 maybe some day you will. 20:52:31 the VOP says it handles immediates. Handling immediates is easy. Why would we purposefully render our code base more brittle with bugs that are just waiting to be triggered by changes far away in ir1 or ir2tran? 20:53:28 If you must, at least error out explicitly in cases that aren't handled, so that we don't end up with silently broken output 5 years down the road... and then you might as well handle this case for real. 20:54:05 how should i handle it then? 20:54:22 perofrm the test at compile time? 20:55:01 but i can't give any sensible error from within the vop 20:55:21 just do an uncodintional jump to the error routine 20:55:27 yes. 20:55:41 might as well do it at run-time 20:56:00 except you can't because you have to handle the case that you received an immediate TN. 20:56:21 won't it be just loaded? 20:57:27 no: the whole point of specifying that you accept immediate TNs is so that the runtime doesn't have to guess how to load it. 20:57:40 s/runtime/VOP suppport library/ 20:58:17 ok, i'll try to invoke it with immediates somehow and see what happens 20:58:44 it won't be called. 20:58:56 maybe with a %primitive, I guess. 21:02:57 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 248 seconds] 21:05:57 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 21:07:42 stassats [~stassats@wikipedia/stassats] has joined #sbcl 21:07:58 not so well, it leaves the value untagged 21:08:28 it? 21:08:46 calling with un/signed-reg 21:08:56 yes, that's the whole point 21:09:06 but, it has to be tagged by the end 21:09:13 in that particular code 21:09:35 ok. 21:10:12 can't you make this a type test template rather than type check? 21:10:39 what do you mean? 21:10:46 with a :translate vop? 21:13:03 or make it how (typep x '(mod x)) is handled? the resulting type-checks are not optimal 21:14:31 so, it needs to be both 21:16:12 see source-transform-numeric-bound-test 21:16:19 and for type-checks, emit-type-check should be changed to use translated vops 21:16:22 * transform-num... 21:17:31 yes, then it slaps and (or test (error)) around it 21:17:54 which i can do better from the vop 21:20:20 i mostly don't like that it doesn't end up in *elswhere* 21:20:54 ok. control.lisp is where it's at. 21:21:01 anyway, it's workable within the VOP too 21:25:39 (integer -20 20) for some reason does a load before FAST-IF-<-C/FIXNUM, does it thing it will modify it? 21:25:47 think 21:27:12 :effects and :affected seem to be in order 21:28:41 only i don't see that :effects or :affected have any effect on the compiler 21:29:30 that's for tomorrow to sort out 21:34:06 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 268 seconds] 21:54:28 so yes, 80 LOC handles all the cases, including (un)boxing. 21:54:53 I'm really not convinced it's worth the trouble, compared to just emitting mod type *tests* right 21:57:40 or find how to hook into the machinery to insert load VOPs 22:37:24 -!- astertronistic [~astertron@ip70-181-235-122.sd.sd.cox.net] has quit [Quit: Leaving] 22:40:19 -!- Sagane [~Sagane@177.100-226-89.dsl.completel.net] has quit [Read error: Connection reset by peer] 22:52:16 What are your thoughts on merging SB-GMP in? 23:19:58 arubin [~arubin@99-114-192-172.lightspeed.cicril.sbcglobal.net] has joined #sbcl 23:20:46 -!- foreignFunction [~niksaak@ip-4761.sunline.net.ua] has quit [Quit: Leaving.]