% rdice has joined #parrotsketch
% rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com
% rdice has joined #parrotsketch
% jhorwitz has joined #parrotsketch
% rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com
% kj has joined #parrotsketch
% davidfetter has left davidfetter!~davidfett@start.fetter.org
% tewk has joined #parrotsketch
% allison has joined #parrotsketch
% davidfetter has joined #parrotsketch
% cotto-work has joined #parrotsketch
% barney has joined #parrotsketch
% chromatic has joined #parrotsketch
% rdice has joined #parrotsketch
<chromatic> Who's here?
<kj> i'm here
% pmichaud has joined #parrotsketch
% jonathan has joined #parrotsketch
<jonathan> /q
<jonathan> oops
<barney> I'm here
<chromatic> Alrighty, let's begin then.
<chromatic> barney?
<barney> Fiddled with Plumhead.
<barney> Added Makefile target 'languages-test-separate'
<tewk> Lurking :)
<barney> .eor
<chromatic> I applied some patches, but ran out of time.  I'll apply more patches and talk to wknight about his GC plans.
<chromatic> jonathan?
<jonathan> erm, writing my report still, come bback to me in a mo
<chromatic> pmichaud?
* Tene 
<pmichaud> erm, writing my report still, come bback to me in a mo
<pmichaud> :-)
<chromatic> allison?
<jonathan> :-P
<allison> -I did a serious revamp of continuations on the pdd25cx branch. They're now completely free of the stack, which means they can be safely invoked from any runloop, not just the runloop they were created in.
<allison> - This means we don't have to use the unstable setjmp/longjmp for exception handlers.
<allison> - It also resolves a bug that Patrick reported in trunk.
<allison> - Working on some final details there now, then it will be safe to merge the branch back in.
<allison> EOR
<chromatic> Tene?
<Tene> Updated cardinal to use the new metamodel that rakudo is now using
% DietCoke has joined #parrotsketch
<Tene> Cardinal now has arrays and hashes
* jhorwitz arrives late
% moritz has joined #parrotsketch
% Whiteknight has joined #parrotsketch
<Tene> Looked around for a ruby test suite to use.
<Tene> .end
<chromatic> jhorwitz?
<jhorwitz> as of noon today, mod_perl6 is now a pure perl module, and works w/o precompiling to PIR
<jhorwitz> required some changes to support interpolated namespaces in sub calls, but i defered the more general case to those less PCT-challenged.  will post the patch to RT in case we want to use it temporarily or as a basis for the final implementation.
<jhorwitz> updating to HEAD eliminated the "attempt to access code outside of current code segment" errors i saw last week.
<jhorwitz> implemented PERL6LIB in rakudo.  necessary for mod_perl6.  will discuss further about committing that one.
<jhorwitz> EOR
<chromatic> jonathan?
<jonathan> * Just got back from Sweden.
<jonathan> * More talking than coding at the moment.
<jonathan> * Talk on Parrot and PCT a Kista (Stockholm uni) was well received
<jonathan> * My two talks, one on Perl 6 and the other on Rakudo, seemed to get well at Nordic Perl Workshop too. Certainly, I enjoyed giving them and there were lots of good questions.
<jonathan> * Worked with pmichaud on Thursday to help get Rakudo switched over to the new proto-object and meta-model stuff. Seems we didn't break anything, and some things are probably More Right now than they were before.
<jonathan> * Wanted to get ranges right. Then realized I'd probably need to really implement lazy lists for that, or at least the first bits of support for that. Put it on hold for a little while, but hopefully not long.
<jonathan> * Created a branch for working on Mutable stuff. This will help improve Rakudo performance some, but is much more about getting the semantics of container vs value types correct.
<jonathan> * Going to FPW on Thursday, got some talks to give there. Won't have a Rakudo day this week, due to the conferences.
<jonathan> .end
<chromatic> pmichaud?
<pmichaud> == Parrot stuff
<pmichaud> : Removed the Super PMC
<pmichaud> == OO improvements
<pmichaud> : finished P6object implementation
<pmichaud> : migrated PGE, PCT, and Rakudo over to P6objects
<pmichaud> : thanks to jonathan++, moritz++, and particle++ for Rakudo migration help
<pmichaud> : wrote an (still unpublished) article about P6object -- looking for feedback - will probably post to parrotblog.org, maybe only a reference on use.perl
<pmichaud> == PGE stuff
<pmichaud> : removed remaining deprecations from PGE
<pmichaud> : <?foo> is now zero-width, use <.foo> for non-capturing
<pmichaud> == PCT stuff
<pmichaud> : added a keyed_int scope to force array keyed lookups
<pmichaud> : made PCT smarter about when to call newclosure on blocks
<pmichaud> : added an 'else' option to 'try' nodes
<pmichaud> == NQP stuff
<pmichaud> : added ternary ?? !! to NQP
<pmichaud> : switched postcircumfix:[ ]   to use keyed_int scope
<pmichaud> == Rakudo stuff
<pmichaud> : fixed Pair implementation
<pmichaud> : cleaned up Any, Object, built-in types inheritance and methods
<pmichaud> : applied lots of patches  (bacek++, moritz++, dolmen++, and others)
<pmichaud> : more to apply
<pmichaud> : fixed 'try' to return value of its block instead of undef
<pmichaud> : discussions on proper handling of $_, $!, $/
<pmichaud> : looking at a variety of refactors in actions.pm
<pmichaud> == Questions
<pmichaud> : queue one question from me
<pmichaud> __END__
<chromatic> DietCoke?
<DietCoke> not much to report this week, one eye on RT and commits as always. Trying to keep an eye on the pdd25 branch as well, have two questions in that regard which I can hold til the end.
<DietCoke> .
<chromatic> Did I miss anyone?
<kj> You already guessed I have no report :=) but I do have a couple of questions.
<chromatic> Let's take the questions in order then.
<chromatic> pmichaud, first question?
<pmichaud> need guidance on the message I posted to parrot-porters yesterday (more)
<pmichaud> the message I posted is at http://groups.google.com/group/perl.perl6.internals/msg/96417ed37799cd37
<pmichaud> basically I'm looking to know if we're entertaining changes to the parrot calling conventions or if Rakudo needs to do workarounds with what exists now.
<allison> hadn't looked at the message yet, but changes to the calling conventions are at least a possibility
<pmichaud> can they be soon?  (I'm willing to implement the changes myself.)
<pmichaud> I'd rather implement the changes than implement the workarounds :-)
<allison> certainly can provide hooks to make it easier to implement different semantics on top, even if we don't go with Perl 6's exact semantics
<chromatic> Ideally I'd like to see if the changes affect Pynie and Cardinal if there are any changes, but I'm not sure we ever had that with any version of the calling conventions.
<Tene> Perhaps we should ask what the most-general semantics we coudl provide would be that could be used to implement Perl 6's semantics?
<pmichaud> I think that the Perl 6 semantics are a superset of what we have now.  And I don't understand the reasons for the current handling of :named parameters being filled from positionals
<pmichaud> I think what I proposed falls under "most general semantics"
<allison> well, if you pass a positional parameter, in theory, you meant it to be used
<allison> I'd be more inclined to say it's not allowed to pass a parameter as both named and positional
<pmichaud> yes, but that positional should override an explicit named parameter?
<allison> is this possible because parameters marked with :named are still in the positional list?
<pmichaud> is ?what? possible?
<allison> they should be mutually exclusive: either the parameter is named or positional, not both
<pmichaud> pdd03 says that named parameters can be filled by positionals
<pmichaud> which is the exact opposite of Perl 6
<pmichaud> (positional parameters can be filled by named arguments)
<allison> fundamentally it's the same idea, but the semantics of priority are different, yes
<allison> throw an exception
<pmichaud> ...throw an exception?
<Tene> return null!
<DietCoke> don't our calling conventions basically exist to support Perl6 ? (I'm wondering how we ended up with something that is a mismatch.)
<allison> passing one argument twice should never be silently ignored
<pmichaud> I'm confused
<pmichaud> by "passing one argument twice".  that doesn't really happen.
<allison> okay, I'll start from the beginning
<pmichaud> DietCoke: I thought that the current calling conventions were to support Perl 6 as well.  Perl 6 might have changed since then, or there may have been a misunderstanding about what those calling conventions would be when pdd03 and the conventions were implemented.
<allison> The situation you're describing is a case where one parameter is passed two values: one positional, and one named, right?
<pmichaud> no.
<pmichaud> one parameter can be filled by either a named or a positional value
<pmichaud> (not both.)
<allison> good, that's how it should work
<pmichaud> if a named value is supplied, then the parameter uses that (and doesn't eat a positional value)
<pmichaud> if a named value is not supplied, then the parameter uses the next positional value
<allison> that's how it should work, yes
<pmichaud> :slurpy gains all of the positionals that weren't eaten by unnamed or named positionals
<pmichaud> :slurpy :named gains all of the named values that weren't eaten by named positionals or named parameters
<allison> okay
<pmichaud> so, the above is what I'd like to see in an ideal parrot.  :-)
<DietCoke> .. "named positionals" or "named parameters" ?
<allison> alright, so basically the problem is that the argument parsing isn't looking ahead to the named parameters before it doles out the positionals
<pmichaud> DietCoke: I need the ability to say "this named parameter can only be filled by a named argument"
<allison> i.e. Perl 6 wants to skip some positionals if they've been provided as named arguments
<pmichaud> I also need the ability to say "this named parameter can be filled by a named argument or by the next positional if no matching named argument provided"
<DietCoke> I remain, humbly, confused. =-) As long as you two understand. =-)
<pmichaud> we don't really "skip" positionals -- we simply save them for the next positional argument
<allison> well, at the moment, positionals can be quite stupid
<allison> each argument is assigned to the next parameter, in strict sequence
<pmichaud> right
<allison> for this, we'd have to add the ability to selectively skip some of the parameters in the allocation sequence
<pmichaud> no, we simply fill the named parameters first
<allison> now, Larry originally designed Perl 6 signatures so lookahead wouldn't be necessary
<allison> because lookahead is expensive
<pmichaud> is it that expensive in this case?
<allison> so, the rule was that if a parameter was passed as named, it couldn't be followed by any more positional parameters
<pmichaud> that's true for *arguments*, yes
<pmichaud> sorry
<pmichaud> I'm backwards
<pmichaud> the strictly named parameters (non-positional) come after all of the positional parameters, yes
<pmichaud> arguments can be supplied in any order
<pmichaud> -however-
<pmichaud> PCT already moves named arguments to come after positional arguments
<allison> yeah, the strictly positional and strictly named ones are clear
<allison> it's the intermediate set that's troublesome
<pmichaud> since we know that named arguments are always at the end of the argument list, it shouldn't be that hard to walk through that list and apply them to any named parameters and leave the rest for a :slurpy :named
<pmichaud> then whatever parameters weren't filled get handled by positionals
<pmichaud> (which are conveniently at the front of the argument list.)
<allison> I suggest we talk it over with Larry tomorrow, because my understanding of what he wanted is a bit different
<allison> it could have changed, of course
<pmichaud> it's pretty clearly laid out in S06, but sure, we can make it for a design meeting.
<allison> but, worth asking
<pmichaud> I think it did change as a result of Pugs
<pmichaud> (it changed to a much cleaner design, imo)
<DietCoke> It would be helpful if any resulting documentation was clear regarding arguments vs. parameters.
<allison> DietCoke: that's a classic problem
<pmichaud> for one, arbitrary pairs are no longer named arguments.  Only   colonpairs and fatarrow arguments will match named parameters.
<DietCoke> my cluelessness? completely agree. =-)
<chromatic> Shall we move on to DietCoke's first question?
<allison> DietCoke: no, using them ambiguously. arguments are what's passed in, parameters are what's pulled out. but people seem to use the terms interchangeably (unfortunately)
<allison> yeah
<pmichaud> okay, we'll save it for design call tomorrow.  I just need a fairly early decision about implementing workarounds.
<DietCoke> allison: did you see my ticket about the broken build in the pdd25 branch?
<allison> I'll take a look at S06 in the meantime
<DietCoke> Was unable to duplicate in trunk. did a realclean, but not a fresh checkout.
<DietCoke> just FYI. (that's #1)
<chromatic> Okay.
<allison> DietCoke: I didn't, when was it? It won't build today because of a hangup in resume in TGE's compile
<DietCoke> #2 - should I expect the changes you've made to eliminate some cases of the inferior run loop problem? Or is this something else.
<DietCoke> (TGE) yes, that's it. there's a ticket.
<allison> DietCoke: okay, thanks, I'll close it after fixed
<allison> and #2: yes, it will fix some of our inferior runloop problems
<DietCoke> (for example, tcl's got an issue where it throws an exception inside a PIR sub that's invoked from C that's invoked from PIR)
<DietCoke> allison++
<pmichaud> (S06 -- the section starting with "Required Parameters" makes it fairly clear what happens.)
<DietCoke> EOQ
<allison> The specific bug that Patrick reported that it fixes is RT#47956
<allison> pmichaud: thanks!
<pmichaud> yay!  #47956 is an ongoing pain for PCT and Rakudo.
<allison> DietCoke: that exception should work now, let me know if not
<chromatic> kjs had two questions.
% NotFound has joined #parrotsketch
<kj> yup:
<kj> I'll keep them short and refer to emails I send earlier.
<kj> #1 for pmichaud:
<kj> what kind of 2nd PCT tutorial would you like, and can I help you with that? (I sent an email about this earlier)
<DietCoke> allison: as soon as I can build the branch, I'll let you know. (also have a pending change to tcl to convert all my control flow exceptions to use the new standard ones.)
<pmichaud> 2nd PCT tutorial ought to be languages/abc, updated to do the new operator precedence parser (which I'll be working on tonight)
<allison> DietCoke: great!
<kj> #2 for allison: I'm converting the PCT tutorial to POD so it can be stored in the repos. (and updated from there). I sent a reply on your reply on my email w.r.t. licensing. Could you have a look at that sometime this week?
<allison> yeah, I'll go take a look at it now
<kj> it's low priority, but after all, #ps Q time is to ping people on blockers :-)
<kj> eh, that's EOQ
<chromatic> Are there any other questions?  I have one, if all is done.
<chromatic> I just talked to japhb, and I'm comfortable with his plans to work in a branch and get signoff.  Is everyone comfortable with enabling his commit access?
<chromatic> I'm comfortable reading his commits.
<pmichaud> I have no objections, as long as trunk continues to work.  :-)
<DietCoke> +1
<allison> sounds good
<chromatic> Alright, if that's everything, let's call it a week.
<allison> thanks c
% chromatic has left #parrotsketch
% cotto-work has left #parrotsketch
% kj has left #parrotsketch
% jhorwitz has left #parrotsketch
% NotFound has left #parrotsketch
% Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% Whiteknight has joined #parrotsketch
% barney has left barney!~bernhard@dslb-084-058-173-144.pools.arcor-ip.net
% pmichaud has left #parrotsketch
% jonathan has left #parrotsketch
% rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com
% DietCoke has left #parrotsketch
% Whiteknight has left Whiteknight!~Whiteknig@c-71-230-33-251.hsd1.pa.comcast.net
% Whiteknight has joined #parrotsketch
% allison has left allison!~chatzilla@dsl-241-62-167.telkomadsl.co.za
% contingencyplan has joined #parrotsketch
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% Whiteknight has left Whiteknight!~Whiteknig@c-71-230-33-251.hsd1.pa.comcast.net