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 []
