00:03:50 specbot [~specbot@common-lisp.net] has joined #sbcl 00:30:05 drewc` [~user@S01060013101b6ddb.vc.shawcable.net] has joined #sbcl 00:34:20 -!- drewc [~user@S01060013101b6ddb.vc.shawcable.net] has quit [Ping timeout: 272 seconds] 01:45:37 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 01:45:57 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 01:46:16 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Client Quit] 02:14:42 -!- nyef [~nyef@pool-70-20-56-192.man.east.myfairpoint.net] has quit [Quit: G'night all.] 02:28:18 -!- drewc` [~user@S01060013101b6ddb.vc.shawcable.net] has quit [Ping timeout: 240 seconds] 02:39:41 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 03:30:30 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has left #sbcl 03:31:20 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 04:12:11 burtdirt [~karim@c-24-91-30-6.hsd1.ma.comcast.net] has joined #sbcl 04:18:18 -!- burtdirt [~karim@c-24-91-30-6.hsd1.ma.comcast.net] has left #sbcl 04:40:49 drewc [~user@S01060013101b6ddb.vc.shawcable.net] has joined #sbcl 06:01:28 cmpitg [~cmpitg@118.71.132.157] has joined #sbcl 06:34:10 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 06:55:33 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 245 seconds] 07:15:09 cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has joined #sbcl 07:18:24 -!- cmm- [~cmm@bzq-79-180-201-14.red.bezeqint.net] has quit [Ping timeout: 265 seconds] 07:18:33 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 07:35:55 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 07:35:55 -!- ChanServ has set mode +o nikodemus 07:52:04 Krystof [~csr21@cpc1-bour2-0-0-cust414.15-1.cable.virginmedia.com] has joined #sbcl 07:52:04 -!- ChanServ has set mode +o Krystof 08:07:29 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 08:19:42 angavrilov_ [~angavrilo@217.71.227.181] has joined #sbcl 08:19:44 -!- angavrilov_ is now known as angavrilov 08:23:56 good morning 08:26:57 how can I squash this warning about asserted type conflicting with whatever? 08:27:43 stassats [~stassats@wikipedia/stassats] has joined #sbcl 08:27:52 depends on the case 08:28:37 sometimes those are real type-errors, sometimes the warning can be bogus due to inline-expansion producing funky code with dead branches 08:29:43 It's my code, and I know that it is bogus, and the branch is dead 08:29:58 So I want it to just be ignored 08:30:24 (declare (muffle-conditions warning)) 08:30:45 sb-ext:muffle-conditions, that is 08:50:06 maetbag [~user@2.94.53.14] has joined #sbcl 10:07:34 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 265 seconds] 10:26:25 -!- rbarraud [~rbarraud@118-92-153-145.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 265 seconds] 10:56:55 nikodemus: dead branches aren't as much of an issue as they once were, though. 11:06:11 no, but only because constraint propagation works its ass off :) 11:07:30 cl-ppcre's are downgraded to style-warnings :) 11:09:06 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 11:15:07 nyef [~nyef@pool-70-20-56-192.man.east.myfairpoint.net] has joined #sbcl 11:15:24 G'morning all. 11:26:03 nyef: http://paste.lisp.org/display/115098 # buglet in new disassembly code 11:26:58 x86-64? 11:27:08 yes 11:27:16 Okay, I know what to do about that. Thanks. 11:27:37 ok. otherwise looking very good so far :) 11:27:55 Ran into the same thing on x86, but thought the OFFSET type would be larger on x86-64. 11:28:05 I'll just add the bounds-check. 11:28:38 just tell me when to pull :) 11:28:46 It's good... for SBCL. Not so much so when compared to CMUCL, though. 11:29:25 what does cmucl do? 11:29:25 cmucl does cool stuff for disassembly? 11:29:44 minion: paste 115066? 11:29:44 Paste number 115066: "more disassembly" by nyef in None. http://paste.lisp.org/display/115066 11:29:54 Have a look at the later annotations. 11:30:20 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 11:30:51 the sparc one is quite complete 11:31:11 that is pretty neat, yeah 11:31:25 symbolic reg names are a nice touch too 11:32:46 I think there's a switch for symbolic reg names already 11:33:01 For comparison, SBCL PPC disassembly of the same function comments the no-arg-parsing entry point and the error trap. 11:34:02 froydnj: No switch, it's a per-backend configuration, and the x86oids, because they don't have a partitioned register set, don't have them. 11:34:24 I've been semi-considering changing R12 to THREAD, though. 11:34:55 (Although, with improved TLS-block commenting, it's far from necessary.) 11:35:02 ah, right. I've wondered if x86-64 would benefit from NIL in a register 11:35:25 I've also been considering partitioning the x86-64 register set. 11:35:49 Which would then let us turn around and disable the conservative scan on the stack. 11:36:04 especially if you stuffed common constants (e.g. max-array-index) into NIL-offsetable values 11:36:23 -!- Krystof [~csr21@cpc1-bour2-0-0-cust414.15-1.cable.virginmedia.com] has quit [Ping timeout: 245 seconds] 11:37:41 nikodemus: Pull again. But note that I rewrote the history, rather than adding another commit... And I didn't actually test the change, just copied it from the x86 version. 11:38:01 possibly also beneficial if you could call assembly routines with NIL+offset 11:38:08 nyef: ISTM precision on stack is independent of precision on registers. 11:38:17 pkhuong: It is, and it isn't. 11:39:34 Because of the way the x86oid ports work, we can't really separate the two easily. 11:40:41 where's the problem? 11:41:22 For starters, we end up with interrupt contexts on the stack in linux. 11:42:02 (At least, I'm given to understand that we do, otherwise we wouldn't have that bit for dealing with darwin -not- stashing them on the stack.) 11:42:28 right... 11:43:19 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 11:43:51 Of course, there'd still be a lot of work involved, as every single VOP would need to be audited for SC restrictions. 11:43:57 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 11:44:59 *pkhuong* will go live in a cabin and code in asm with macros and regalloc 11:52:06 Blkt [~user@93-33-141-96.ip44.fastwebnet.it] has joined #sbcl 11:53:19 stassats [~stassats@wikipedia/stassats] has joined #sbcl 11:55:00 i think my brain is leaking 11:55:38 why is getting (LET ((F (LAMBDA ...))) (DECLARE (DYNAMIC-EXTENT F)) ...) to stack allocate so hard? 11:55:59 aha, i think i know 11:56:41 reason: i'm not alexey 11:56:45 :) 11:57:36 Heh. 11:58:04 At some point, I need to sit down and add all of the dynamic-extent junk to the PPC backend. 11:58:34 ... That said, now that I'm thinking about it, that may not be such a bright idea... 11:59:19 Largely because the stack is scavenged as if it were -all- boxed pointers, and if an object gets d-x allocated to it that has unboxed fields... 11:59:45 Oh well. 11:59:55 nyef: stack allocating only objects that are all boxed or unboxed would probably be pretty nice already. 12:01:25 True. 12:01:27 Arrays? 12:01:45 Dump them to either the control or number stack, depending on specialization? 12:08:49 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 12:13:34 Krystof [~csr21@cpc1-bour2-0-0-cust414.15-1.cable.virginmedia.com] has joined #sbcl 12:13:34 -!- ChanServ has set mode +o Krystof 12:13:53 nyef: right. 12:28:55 -!- maetbag [~user@2.94.53.14] has quit [Remote host closed the connection] 12:37:17 ... Oh, wow. The machinery for the PPC diassembly notes is -bad-. 12:39:42 Hrm. Might be able to work with it a bit, though. 12:50:30 -!- cmpitg [~cmpitg@118.71.132.157] has quit [Quit: leaving] 13:01:37 -!- lnostdal [~quassel@167.80-203-136.nextgentel.com] has quit [Remote host closed the connection] 13:02:41 lnostdal [~quassel@167.80-203-136.nextgentel.com] has joined #sbcl 13:32:13 -!- Krystof [~csr21@cpc1-bour2-0-0-cust414.15-1.cable.virginmedia.com] has quit [Ping timeout: 245 seconds] 13:48:02 tsuru [~charlie@c-174-50-217-160.hsd1.tn.comcast.net] has joined #sbcl 13:48:19 cmpitg [~cmpitg@118.71.132.157] has joined #sbcl 13:50:50 Krystof [~csr21@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 13:50:50 -!- ChanServ has set mode +o Krystof 14:13:52 So, bug in LOOP? 14:16:16 -!- deepfire [~deepfire@80.92.100.69] has quit [Read error: Operation timed out] 14:16:21 deepfire [~deepfire@80.92.100.69] has joined #sbcl 14:17:12 (Arguably also a bug in the spec, as REPEAT clauses are executed in order with their surrounding clauses, but affect the total number of executions of the body as a whole. 14:28:47 kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 14:39:42 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 15:16:43 rmarynch [~roman@88.135.194.233] has joined #sbcl 15:19:25 nyef: thanks again for helping me with that loop form. I find such cases quite hard to analyze :) 15:25:55 No problem. 15:26:12 I'm almost surprised that none of the implementations you tried got the "right" answer, though. 15:31:43 this is from CLISP: 15:31:44 WARNING: LOOP: REPEAT clauses should occur before the loop's main body 15:31:44 (3 3) 15:32:16 It'd be interesting to hear their justification, as it's -not- an iteration-control clause. 15:33:21 I guess that they all share the similar LOOP implementation, however I haven't checked that 15:33:38 Most of them would, the MIT LOOP. 15:33:48 -!- cmpitg [~cmpitg@118.71.132.157] has quit [Quit: leaving] 16:09:45 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 16:14:43 nyef: do you agree that this is at least strange: (loop repeat 1 repeat 2 do (print 1)) prints 1 once and gives no warning or error 16:14:57 ? 16:15:21 ASau [~user@ppp85-141-170-103.pppoe.mtu-net.ru] has joined #sbcl 16:15:28 No, I don't. 16:15:44 Consider the combination of WHEN and REPEAT. 16:16:11 (Yes, WHEN is permitted to suppress REPEAT.) 16:17:18 hmm... I will think about it more. But without WHEN, what is the rule to select between one and two iterations? 16:17:58 One of the REPEAT clauses prevents executing more than two iterations, the other REPEAT clause prevents executing more than one iteration... And they are both live. 16:18:12 Clearly, whichever runs out first will terminate the loop. 16:19:02 I'm generating more sympathy for the "REPEAT as iteration-control clause" interpretation, just in terms of implementability. 16:19:18 nyef: I don't think when can suppress repeat 16:19:47 Krystof: When suppresses the -next- clause. Repeat is mixed with other body clauses. When therefore can suppress repeat. 16:20:05 no, repeat is a termination test, not a selectable clause 16:20:39 termination-test::= while form | until form | repeat form | always form | never form | thereis form 16:21:27 Ah, okay. So it's disallowed by the grammar, but not the explanatory text. 16:21:36 and conditional::= {if | when | unless} form selectable-clause {and selectable-clause}* 16:21:55 Right, I see that now. 16:22:13 so, multiple repeats is a bug? 16:22:59 No, but it might merit a STYLE-WARNING. 16:23:02 no, I think (loop repeat 1 repeat 2 do (print 1)) should print exactly one 1 16:23:24 The logic for the smallest repeat count still applies. 16:23:24 I'd be happy with a style warning if both repeats are constant or provably do not have type ranges which intersect 16:24:19 (Note that the difference between the two cases is that if you use the -same- constant twice they'll have intersecting type ranges.) 16:25:26 Okay, so you can specify as many REPEATs as you want, their /form/s are evaluated prior to the start of the loop, and the test applied at the start of each iteration, regardless of their position within the loop body? 16:25:37 why the types intersection matters? 16:26:03 rmarynch: because (loop repeat (some-computed-number) repeat (some-other-computed-number) ...) makes sense 16:26:50 I mean, it's the same as (loop repeat (min (s-c-n) (s-o-c-n)) ...), but a completely legitimate way of expressing the same thing 16:26:54 nyef: macroexpand shows that the tests are applied at the start and at the end 16:26:57 * (macroexpand '(loop repeat 1)) 16:26:57 (BLOCK NIL 16:26:57 (LET ((#:LOOP-REPEAT-615 (CEILING 1))) 16:26:57 (DECLARE (TYPE INTEGER #:LOOP-REPEAT-615)) 16:26:57 (SB-LOOP::LOOP-BODY NIL 16:26:57 ((IF (<= #:LOOP-REPEAT-615 0) 16:26:59 (GO SB-LOOP::END-LOOP) 16:27:01 (DECF #:LOOP-REPEAT-615))) 16:27:03 NIL 16:27:05 ((IF (<= #:LOOP-REPEAT-615 0) 16:27:06 Gah! PASTEBOT! 16:27:07 (GO SB-LOOP::END-LOOP) 16:27:09 (DECF #:LOOP-REPEAT-615))) 16:27:11 NIL))) 16:27:13 T 16:27:15 * 16:27:17 sorry :) 16:27:51 Krystof: now I see that, thanks 16:35:33 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has quit [Remote host closed the connection] 16:41:05 ...and why there is CEILING called with argument 1 in LET? For integers it should be skipped, right? 16:43:14 well, that, or the compiler will fold it away 16:43:59 and it's less work to just let the compiler DTRT 16:57:14 one more LOOP question for today: in case we have (loop repeat 2 minimize 5 maximize 2), it returns 5. But (loop repeat 2 minimize 3 maximize 4) returns 4 (the second value). What is the rule for such cases (min/max value selection for return)? 16:59:04 it seems to return the maximum of these two 16:59:25 that seems like the right thing, no? 17:00:51 the loop says "find the minimum of IT and X (implicitly setting IT) and find the maximum of IT and Y, return IT" 17:02:27 froydnj: this is right, I had some wrong guess on how it should work 17:08:53 -!- Krystof [~csr21@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Ping timeout: 245 seconds] 17:10:32 -!- vsbuffalo [~fualo@markov.genomecenter.ucdavis.edu] has quit [Ping timeout: 276 seconds] 17:18:05 -!- rmarynch [~roman@88.135.194.233] has quit [Quit: Leaving] 17:57:13 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 245 seconds] 18:01:01 -!- Kaer [b@c-cfcee253.97-16-64736c12.cust.bredbandsbolaget.se] has quit [Read error: Connection reset by peer] 18:01:10 KB [b@c-cfcee253.97-16-64736c12.cust.bredbandsbolaget.se] has joined #sbcl 18:08:32 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 18:08:51 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Remote host closed the connection] 18:26:23 -!- ASau [~user@ppp85-141-170-103.pppoe.mtu-net.ru] has quit [Ping timeout: 245 seconds] 18:27:51 hm, we really need fast-ash-right 18:47:37 vsbuffalo [~fualo@markov.genomecenter.ucdavis.edu] has joined #sbcl 19:23:35 attila_lendvai [~attila_le@adsl-89-135-202-41.monradsl.monornet.hu] has joined #sbcl 20:21:31 -!- vsbuffalo is now known as vs 20:38:03 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 245 seconds] 20:54:03 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 21:06:49 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 22:04:21 -!- attila_lendvai [~attila_le@adsl-89-135-202-41.monradsl.monornet.hu] has quit [Ping timeout: 265 seconds] 22:14:30 burtdirt [~karim@c-24-91-30-6.hsd1.ma.comcast.net] has joined #sbcl 22:18:10 attila_lendvai [~attila_le@adsl-89-134-29-75.monradsl.monornet.hu] has joined #sbcl 22:25:04 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 22:35:05 *nyef* frowns. 22:35:38 FIND-IF has no docstring, and the result-type is (VALUES T &OPTIONAL), which fails to say anything useful other than the number of values. 22:37:01 Hrm. Clearly not the function I want anyway. 22:38:01 -!- tsuru [~charlie@c-174-50-217-160.hsd1.tn.comcast.net] has quit [Remote host closed the connection] 22:38:32 Right, REMOVE-IF-NOT is what I really want. 22:54:22 -!- Blkt [~user@93-33-141-96.ip44.fastwebnet.it] has quit [Quit: Error: do not makunbound t please] 23:01:34 -!- kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [Quit: kclifton] 23:11:17 -!- burtdirt [~karim@c-24-91-30-6.hsd1.ma.comcast.net] has left #sbcl 23:13:22 -!- fe[nl]ix [~lacedaemo@pdpc/supporter/professional/fenlix] has quit [Quit: Valete!] 23:13:36 fe[nl]ix [~lacedaemo@pdpc/supporter/professional/fenlix] has joined #sbcl