Parrot Sketch: Aug 29

jesse on 2005-10-03T19:52:59

13:56 hi ho 13:56 howdy, chip. glad you could make it this week. 13:56 thanks. glad my normality index has increased somewhat :-) 13:57 -!- chromatic [~chromatic@sub17-30.member.dsl-only.net] has joined #parrotsketch 14:04 <@obra> Hi all 14:04 Hello. 14:04 <@obra> chromatic has agreed to deal with moderating on my behalf today. 14:04 * obra is frantically packing for braga 14:04 hi all 14:05 -!- pmichaud [~chatzilla@c-24-1-26-255.hsd1.tx.comcast.net] has joined #parrotsketch 14:05 obra: jealously. I'm packing to move. Much less fun 14:05 s/ly/y/ 14:06 Cross-country? 14:07 chromatic: Indeed. I'll _almost_ be back in my cellphone's 707 area code. 14:07 chromatic: Instead, I'll be living in the East Bay and commuting to SF 14:08 By choice? 14:09 which part? :-) I like the SF part, I don't mind the commute, and East Bay has other benefits (GF's old stomping ground, she has plans there) 14:09 Pennsylvania, or as we call it "The Fool's Paradise", will not be missed 14:10 I guess you're tired of living in that Precious Moments figurine factory. 14:11 to get to my sister's place, I drive by The Franklin Mint. I can _smell_ the pewter. 14:11 Minty fresh. 14:11 So, are we self-organizing today, or is Jesse riding herd? 14:11 I'm in charge. It's 10 after, so we have everyone timely. 14:11 <@obra> "chromatic has agreed to deal with moderating on my behalf today." 14:11 oh, wait, I missed that big. chromatic's the boss 14:12 s/big/bit/ 14:12 chip's first in the sorting order. What's new? 14:12 I'm ... let's see ... 63% through the diff between trunk and leo-ctx5 branch 14:12 I'm writing up the comments on the way. 14:13 So far, no major surprises ... I see a merge before 1 sep release. 14:13 oh, that would be *excellent* 14:13 -!- mdiep [~matt@c-24-11-80-190.hsd1.mi.comcast.net] has quit [Quit: mdiep] 14:13 And soon. 14:13 How much breakage will there be in the libraries and tools and docs? 14:14 python stops working 14:14 tcl is being worked on - one bug lurking but known 14:14 PGE is fine 14:15 that's it as far as I know 14:15 IIRC, for other outside-the-tree code: anything that generates PIR that uses the .pcc_* macros for call & return won't even notice the calling convention change. But if it assumes that it knows that P2, P5, etc. have special meanings ... _boom_ 14:16 only a couple PIR things in the branch need changing 14:16 How far gone is Python? 14:16 yep - or PIR code like the 2 failing streams tests, that just assume P2 is unchanged for the next method call 14:16 implicit $self. heh 14:16 python is a bit of a problem 14:17 tewk is working on it 14:17 -!- mdiep [~matt@c-24-11-80-190.hsd1.mi.comcast.net] has joined #parrotsketch 14:17 ack. my keyboard stopped working. I had to restart. 14:17 Anything else, chip? 14:17 but he is more inclined to redo the old code with new calling conventions 14:17 When's the move? 14:17 I don't know enough Python to have followed Sam & tewk's comments. Is it all about Python adapting to Parrot, or do we have to do something for them? 14:17 but Sam didn't use interface code 14:18 he redid call stuff in his PMCs 14:18 AFAIK currying i.e. BoundMethod 14:18 chromatic: Right around 15 Sep. This is packing week, next week is moving heavy objects into crates week. door2doormoving++ 14:18 I think at the end of the thread, Sam's concerns were performance related 14:19 And his currying impl isn't friendly with the new coventions? 14:19 well, his code runs at 1/10th of speed compare to my Piethon code 14:19 the currying implementation was basically fine but: 14:19 Sam's going to go for correctness first, and will be uninclined to cheat in any way. Python people by and large apparently don't believe in cheating :-, 14:20 moving P6<-P5, P5<-P2 just doesn't work anymore 14:21 and most of this stuff was also related to the out-of-band passing of the object 14:21 but currying needs either an interface (shift_args) or Parrot support 14:22 f = o.meth 14:22 f(2) 14:22 this is a method call 14:22 o.f(2) 14:22 in two steps 14:22 OK, so it seems that in the absence of support to make it faster, it's possible to slurp the params, unshift the resulting array, then call with flatten. So there's a way forward without any work on our part (yet) 14:23 yes - one indirection throug a PIR helper function does it of course too 14:23 OK. chromatic: I have two notes about the PIR language that I could go into a bit, or not, your call 14:24 Go ahead. 14:24 OK 14:24 I'd like to hear them 14:24 pmichaud: you and leo were the ones I knew would 14:24 I mentioned a while ago, but I see it hasn't happened yet, that :opt_count is a bad semantic for noting that optionals are missing 14:25 I want to remove it in favor of :opt_flag, where you get one boolean per optional parameter (that you care about) rather than an integer 14:25 Someday we might have named parameter support, and if we do, the count isn't expressive enough - it doesn't tell you e.g. _which_ three optionals are present 14:26 I think this needs to be fixed before release, if not before merge 14:26 pmichaud: AFAICT, this is a SMOP for you 14:27 I think - if you care which optional is missing, you pass one :opt_count per :optional 14:27 chip: that's correct -- it doesn't matter much to me which approach is taken; just so long as I know which :-) 14:28 leo_: Named parameter passing means that arg processing isn't necessarily sequential - given sub foo(?$a,?$b,?$c), there's no guarantee that $a is processed before $b and $c. Therefore, the left-to-right semantic implied by :opt_count is wrong 14:29 So that's the first thing 14:29 The other thing is even easier to fix. I want the attributes on sub definitions to have sigils, not just be plain words. 14:30 hmm, it might need 2 passes, but I think I still can fill an :opt_count correctly 14:30 leo_: I prefer to avoid forcing the introduction of the second pass 14:31 ok, yes - if it is avoidable, then fine 14:31 what's currently spelled C< .sub "foo" @MULTI(_,int) method > should be spelled C< .sub "foo" :multi(_,int) :method >. But for now,the legacy spelling "@MULTI" will continue to work 14:32 that's fine with me 14:32 oh, the current spelling may require commas between, I don't know, but there shouldn't be any commas ... the sigils are the visual separation 14:33 Anyway, that's pretty much it for deltas from leo-ctx5's PIR to what I want to see. 14:33 Well, except for the old things not yet done, 14:33 Is _ now the "I don't care which parameter this is" marker? 14:33 ... like forbidding "$P0 = opcode" when the opcode does _not_ actually set its first parameter 14:33 yep it's Any 14:33 Wow, now i know three languages where that's the case. 14:34 Anything else, chip? 14:35 Nope, that's it 14:35 leo? 14:35 progress with SoC 14:36 When's the due date? 14:36 Nattfodd is getting near 100% tests 14:36 Sept 1th 14:36 Is everything on track to make it? 14:36 but he only now is checking that he did some unneeded stuff in the beginning of the project 14:37 yes should work out fine 14:37 the 2nd guy is working on imcc optimizations 14:38 his recent patch is on the list (p6i) for review 14:39 not much else - preparing for Braga, leaving tomorrow morning 14:39 ah and I found the 'last' bug in the branch that is currently killing tcl 14:40 but it isn't fixed yet 14:40 eof 14:41 Thanks, leo. Matt? 14:42 I've mostly been working on catching up on Real Life(tm) after moving in at school. I spent last night understanding the Python thread and today I started compiling the namespace requirement information. 14:43 I hope to have an email out to the list in a few days time detailing what information is required from different languages 14:43 after that I will begin to work on a proposal for making that information available 14:43 Native Parrot support for HLL namespaces? 14:44 yes. some of which will be conventions for compiler writers. 14:44 Sounds good. 14:45 I'm not sure what's currently in place in Parrot or what's going to stay. 14:45 It'll be easier to say with an overview of HLL needs. 14:45 which leads me to the question I have: what do we know is missing and what do we know has to get redone in Parrot? 14:46 from namespaces, you mean? 14:46 I think it was said that the lexical implementation was broken 14:46 no, I mean overall 14:46 Jeepers. 14:46 it'd be nice to have a list of things we know aren't working 14:46 This is the question I want in writing ahead of time. :-/ 14:46 chip, Autrijus mentioned the lexical stuff at YAPC. 14:47 I believe you said "jeepers" there too. 14:47 grr 14:47 That's a different kind of jeepers. 14:47 Should there be a "Call for B0rked" message on p6i? 14:47 is any of this documented anywhere? can we document them somewhere if it's not? does anyone have a mental list? 14:48 A parent RT ticket? 14:48 I have serious concerns about depending on RT 14:48 I'd prefer that chip pick where he'd like it to be. (I've heard that he has concerns :-) 14:48 It's not that RT is bad, but the interface is bad, in the manner of Bugzilla 14:48 Is there a single place for this information that you find preferable? 14:49 I've had three different answers typed & removed. 14:50 RT is good for bugs, as long as someone else is maintaining dependency info 14:50 bug dependency manipulation is a clickfest. 14:50 If someone else handles that, is it workable? 14:50 something in docs? 14:51 As for missing features and features that might as well be missing (see "lexicals"), RT is OK too, I guess 14:51 Again, if someone else is doing the dep thing 14:51 Alright, I'll see if Will Coleda is open to the idea. 14:51 "Call for B0rked" works, as long as it's filtered for redundancy & correctness ("oh, we fixed that") 14:52 who is doing the filtering? 14:52 well, whoever posts the question. :-) 14:52 Presumably anyone who can say "It works now" with authority. 14:53 chromatic: I think that's input to the filtering, right? 14:53 You see the finger, I see the moon. 14:53 heh 14:53 Anything else, Matt? 14:54 can I throw in a couple of off-the-wall comments here, about RT? 14:54 Sure. 14:54 Personally, I find RT to be a bit of a pain to use 14:54 seconded. 14:54 I believe Jesse has an intern working on upgrading the Perl.org installation to a newer version. 14:54 beyond that, I find myself wishing for the equivalent of pugs' "smoke test", where we can get a graphical view of what needs to be done 14:55 The HTML view? 14:55 yeah 14:55 and part of me wonders if we could get somewhere by using the repository as the official ticket log (more) 14:55 i.e., if our "to do list" could in fact be "to do" tests in the repo 14:55 so they'd show up in the smoke test graph 14:56 even if the test isn't code, it could just be a failure marker of some sort ("it's been reported that xyz doesn't work") 14:56 It'd have to be easier to write TODO tests, but Parrot::Test does support those. 14:56 "doesn't"? 14:56 Filter: I added TODO support to Parrot::Test a couple of months ago. 14:57 I think the only necessary part is convincing someone to run nothingmuch's harness against Parrot tests on a regular basis and post the results. 14:57 I'm not sure how we would mark dependencies, and it would mean that new tickets could only be entered by committers, but somehow that just seems like it'd be another way to maintain a task list 14:57 I vote for executable information in the form of TODO tests, rather than human-only info like a TODO doc 14:57 I think there may be an issue in that some of our todo list is HLL design issues. for instance, namespaces are a todo item, but I don't think we can really write a test for that currently. 14:58 mdiep: not yet. you need at least the PIR spec for them before you can write a test 14:58 fail( "namespaces not designed", todo => 1 ); 14:58 well, there _is_ that. 14:58 t/pmc/namespace.t 14:58 I'd always prefer an executable TODO test as well, but when that's not available we still need somewhere to record things that need to be done/fixed/whatever 14:59 Alright, let's say that we need to talk to #perl6 about stealing their smoke testing ideas. 14:59 pmichaud: quite, but it would seem it _is_ available, so ...? 14:59 Perhaps we can piggyback on that. 14:59 we stole their commitbot, so why not keep going back for more? 14:59 Patrick, anything to report? 14:59 it is just a thought I had. Somehow I like working in vi and the repository much better than firefox and rt's web interface 15:00 I interrupted matt -- does matt have anything else first? 15:00 pmichaud: at some point, _someone_ is going to write RT::Mechanize. 15:00 no, that covers things for me. I will probably contribute to "Call for B0rked" though. (by the way, who is sending that? me?) 15:01 chip: that's fine -- I'll be fine with using RT if that's the way to do it, but it often just feels like there ought to be a better way. And I would like to be able to more easily see the outstanding issues in some way that is directly tied to the repository. (end of rt diversion) 15:01 Matt, if you want to write it feel free. If not, I'll do it. 15:01 chromatic: if you're volunteering, go ahead. :-) 15:02 Well foo. 15:03 so, is it back to me? 15:03 yes 15:03 yes 15:04 well, not much happened for me parrot-wise in august; I had a (contracted) project that the other team members thought we could finish in 4 days but turned into a 14 day marathon 15:04 plus trips to corpus christi and nasa stennis space center in mississippi 15:04 culminating in the delivery of a trailer full of equipment last wednesday, which is probably on its side as of this morning :-( 15:04 PUGS... IN... SPACE! (sorry) 15:06 I'm glad to hear that we're getting to the leo-ctx5 merge with the trunk, that will make things a lot simpler (and more stable for me) 15:06 I still have yet to check in the operator-precedence parser (I need to update the docs a bit), and since we have the new calling conventions that changes things slightly there so will update that at the time of the merge 15:06 How stable is that parser? 15:07 it should be fairly stable but it needs a lot more testing 15:07 Sounds good. 15:07 and its calling interface is likely to change somewhat over the first few revisions 15:08 What comes after the parser? 15:08 parsing expressions, and probably a simple p6 expression interpreter 15:08 I think I'll work on a p6 interpreter in parallel with working on the tree transformation language issues for the compiler 15:09 Larry's working on the interface side of TTL. I think he'll end up unifying it with rules. 15:09 oh, I missed that in the notes (I'm behind on p6 mailing lists); that will be very very helpful 15:09 I'm glad he's doing it and not me :) 15:10 Ditto. 15:10 do I want to ask what TTL is? 15:10 transistor-transistor logic, yeah 15:10 TTL -- tree transformation language -- the stuff we talked about on saturday at oscon and then shelved as needing more research 15:10 forgot its name, OK 15:11 I'll be very happy to let the language designer design that part of the language and tool suite :-) 15:11 I'll implement it, but it'll be easier to work from a draft language spec than to design the language spec at the same time 15:11 Anything else, Patrick or anyone? 15:12 the only other thing I'll look at is using PGE to be able to parse PGE expressions, so that it'll be easier to parse p6 rules from other sources (e.g., pugs) 15:12 i.e., PGE needs a built-in rule that can parse a p6 expression :) 15:12 s/p6/p6rule/ 15:13 that's it for me 15:14 Sounds good. I'll summarize the summaries and the available tasks and send out an e-mail later today. 15:14 thanks 15:14 great. thanks, chromatic. 15:14 excellent, thanks 15:14 thx2 15:15 That's all. See you again next week. 15:15 <@obra> pmichaud: perl.org is robert spier's RT, not mine 15:15 <@obra> rt.cpan is what my interns are updating ;) 15:15 obra: okay 15:16 My mistake. 15:16 <@obra> no worries. 15:16 <@obra> but tell us what sucks and we'll try to improve it anyway 15:16 <@obra> you know there's a CLI for rt.perl.org? 15:17 I don't know why rspier is keeping rt.perl.org back 15:17 If he refuses to update, is the bug database portable to another RT instance? 15:23 -!- pmichaud [~chatzilla@c-24-1-26-255.hsd1.tx.comcast.net] has quit [Quit: Chatzilla 0.9.68.5 [Firefox 1.0.6/20050716]] 15:30 <@obra> chip: he's amenable to updating. 15:30 -!- chromatic [~chromatic@sub17-30.member.dsl-only.net] has quit [Quit: Leaving] 15:31 ok 15:53 -!- mdiep [~matt@c-24-11-80-190.hsd1.mi.comcast.net] has left #parrotsketch [] 15:59 -!- chip [~chip@ts3-126.twistspace.com] has left #parrotsketch [] 16:10 -!- leo_ [~lt@ts3-126.twistspace.com] has left #parrotsketch []