% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% contingencyplan has joined #parrotsketch
% rdice has joined #parrotsketch
% rdice has left rdice!~richard_d@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com
% rdice has joined #parrotsketch
% wknight8111 has joined #parrotsketch
% smash has joined #parrotsketch
% jonathan has joined #parrotsketch
% Infinoid has joined #parrotsketch
% smash has left smash!~smash@gil.di.uminho.pt
<jonathan> [pre-report because I'll be away] Haven't had chance to do much in the last week. Will be spending all day Thursday hacking on Rakudo. Also will be talking about Rakudo and Perl 6 at the French and Nordic Perl workshops at the end of May - arranged that this week. Other than that, just been watching the mailing lists, trying to keep up etc.
% allison has joined #parrotsketch
% cotto_work has joined #parrotsketch
% chromatic has joined #parrotsketch
% Coke has joined #parrotsketch
<chromatic> Hi all.
<Coke> And welcome to this meeting of Parroteers Anonymous.
% barney has joined #parrotsketch
% rgrjr has joined #parrotsketch
<wknight8111> jonathan left a pre-report message that some people probably missed 
<pmichaud> hello
<Infinoid> howdy
<barney> Hallo
<allison> hello
<particle> hi-o
<rgrjr> yo
<Coke> kjs is network challenged for a little while, and won't be able to hack much or join us here, fyi. Should be back in a few weeks.
<particle> jonathan posted an early report
% NotFound has joined #parrotsketch
<Coke> I think we have quorum, as it were. Why don't we get started.
<Coke> allison, I'm feeling alphabetical.
<allison> - Did a code review on the current exceptions implementation and expanded the task list with a bunch of small concrete tasks based on the review.
<allison> - chromatic and I worked on the same task this weekend: updating the Exception PMC to use a core struct. (My network access went down over the weekend, so I couldn't communicate with anyone about what they were working on.) I've merged in my changes with his.
<allison> - Found and fixed some bugs in the Pmc2c attribute accessors while I was at it.
<allison> EOR
<barney> Removed Digest::Perl::MD5.
<barney> Applied patch by Brad Gilbert,adding tests for sys ops.
<barney> Fiddled with Eclectus.
<Coke> barney?
<Coke> (nice trick. =-)
<barney> .eor
<Coke> chromatic?
<chromatic> Working on the cx branch.
<chromatic> Trying to excise more of the type-casting grottiness from the GC; need some 64-bit feedback on that.
<chromatic> Might be able to reduce memory usage in a few key structs as a result.
<chromatic> Applying some patches.
<chromatic> That's it.
<Coke> I added a page about the pre-con hackathon for yapc::na, hopefully to drum up some interest from non-committers. Still trying to work on the type_ids branch (have a merge in progress)
<Coke> not much else.
<Coke> Infinoid?
<Infinoid> * Backed out the vtable const stuff, as discussed last week.
<Infinoid> * Tweaked Ops2c's method-flags handling a bit.
<Infinoid> * Fixed some other const-related issues.  Fixed various other warnings.
<Infinoid> * Fixed a couple of failing tests.  Added a couple of missing Makefile dependencies.
<Infinoid> * Started genericising the C backtrace() stuff, turns out it's available on OSX 10.5+ too.
<Infinoid> 1;
<Coke> particle?
<particle> ~ did some work on the perl 6 spec test utilities and the rakudo test harness in order to improve the test failure reporting
<particle> ~ i think it helps nicely
<particle> ~ made a tiny patch to rakudo, for postcircumfix:<> colonpairs, which is probably broken, and on my short list of things to look at again
<particle> ~ it's taking me some time to get back into the swing of things
<particle> ~ lots of coordinating and back-channel work on related- but not so public stuff, and conference stuff
<particle> ~ 64bit build is busted on linux with --optimize
<particle> .end
<Coke> pmichaud ?
<pmichaud> (64bit build never worked with --optimize, iirc)
<pmichaud> * Closed RT#52838, 52840, 52842 (user stack and register stack)
<pmichaud> * Lots of dead code removals as a result
<pmichaud> * Presented Parrot, PCT, and Rakudo at Texas Open Source Symposium
<pmichaud> * Presenting Parrot, PCT, and Rakudo tonight at DFW.pm
<pmichaud> * Posted Rakudo milestones in languages/perl6/ROADMAP
<pmichaud> enqueue one item for discussion
<pmichaud> <cut>
<Coke> rgrjr?
<rgrjr> Not much to speak of (worked on my YAPC talk, posted some noise^Wadvice on the lists), but would like to reserve a question.
<rgrjr> .end
<Coke> Anyone else with a report that I missed? I also have a discussion item, giving us 3...
<Coke> let
<Coke> let's go in reverse on the questions. rgrjr ?
<rgrjr> let me go second, thx.
<pmichaud> I'll go ahead then
<Coke> ok, I'll go first. Just wanted to let folks know that I'm going to go through the RT queue and eliminate all the partcl tickets; They obscure actual parrot issues. I hope to have them all closed out and migrated by week's end.
* pmichaud waits for Coke.
<allison> coke: good idea
<Coke> the url is in the languages status and tcl's TODO. Eventually we'll hoist out the code as well, but one thing at a time.
<Coke> .eoc
<rgrjr> Q:  I am just waking up to the fact that exceptions are changing in a big way,
<rgrjr> so I'll probably have more questions after I've caught up in reading.
<rgrjr> But I was wondering what's going to happen to pushaction?
<allison> rgrjr: it'll be around a little while longer, but won't be used for exceptions
<rgrjr> I'm confused:  How is it "used" for exceptions now?
<rgrjr> Anyway, I ask because right now it's the only way for me to implement CL unwind-protect.
<allison> to be literal, the Parrot_push_action function isn't used for exceptions currently, but "stack_push" is the basis of both pushaction and setting exception handlers
<allison> yes, it's the means of directly manipulating the control stack
<pmichaud> I hadn't noticed pushaction before -- is it basically a way to put an exit handler on a sub?
<allison> if we ever do entirely eliminate the control stack, we'll provide functions that pretend to manipulate the control stack while actually doing Continuation Passing Style underneath
<rgrjr> pmichaud: yes.
<allison> pmichaud: all it does is push an executable block onto the control stack
<allison> you can consider it largely deprecated
<pmichaud> cooool.  I bet I could use that.  Would make END {} much easier to handle
<allison> noooooo!
<particle> hee
<allison> don't use it, it's pure evil! :)
<Coke> tcl needs something like that for sub entry *and* exit.
<particle> please document the deprecation
<pmichaud> I can certainly switch to whatever is available when it becomes available
<chromatic> continuation_splice()
<allison> it's doesn't work with CPS
<pmichaud> most everything we do now is in generate code and easy to fix
<rgrjr> allison:  I thought that's what we had now, but that
<rgrjr> makes it a bigger question than I had planned, so I'll save it for the list.
<rgrjr> allison: why not?  continuations capture dynamic_env.
<allison> capturing a control stack within your CPS linked list is highly inefficient, and ends up doing the wrong thing as often as it does the right thing
<allison> as a stack, you have to capture a copy of the entire stack
<allison> which means it resets when you do a CPS return
<rgrjr> and why is that not the right thing?
<allison> or, you don't capture it, and then you have two completely independent means of flow control happening at the same time
<allison> well, let's say you have an action on the stack
<allison> you make a series of subroutine calls
<allison> in one of them you pop off the action and perform it
<allison> then you return from the subroutine, and restore the control stack, including the action you just popped off (not what you wanted)
<rgrjr> Not allowed; you can only pop things you pushed in the same context.
<chromatic> The control "stack" isn't a stack, though.  It's a linked list.
* pmichaud wonders about "pop off the action"
<allison> parrot does have an actual control stack, not the CPS linked list
<allison> also has a user stack
<pmichaud> parrot no longer has a user stack
<pmichaud> unless that's a different stack than user_stack :-)
<chromatic> The stack made up of Stack_Chunk_t structs is a linked list.
<allison> pmichaud: and many thanks for your excellent work ripping out that dinosaur :)
<rgrjr> pmichaud: ditto!
<allison> chromatic: yes
<rgrjr> chromatic: with a structure parallel to the continuation linked list.
<chromatic> You can have lots of pointers to various places within that linked list.
<pmichaud> ooc, how does one "pop off the action" from the control stack?
<rgrjr> chromatic: Then I should read up and follow up on the list.
<rgrjr> pmichaud:  You can only pop stuff you've pushed within a context,
<allison> parrot had 7 stacks
<rgrjr> and within a context it looks stacklike.
<allison> we're whittling that number down as quickly as possible
<pmichaud> rgrjr: okay, but how does one do that?
<allison> stacks.c is the general purpose stack
<rgrjr> Oh, I see:  There isn't a "pop_action", so you have to "pop_mark".
<rgrjr> *That* could stand improving.
<pmichaud> rgrjr:  right, thus my question :-)
<rgrjr> pmichaud: Sorry for being dense.
<rgrjr> .eoq (for the record)
<pmichaud> fwiw, a quick 'ack' of the source seems to indicate that the only "stack" used by stack_push and stack_pop is &interp->dynamic_env
<chromatic> Yes.
<rgrjr> I think so.
<allison> pmichaud: it's evil and ancient and needs to be ripped out as soon as possible
<Coke> . o O (It's a trick. Get an ax.)
<rgrjr> I need actions and dynamic bindings, so I'd like to see what's going to replace if first . . . but later.
<pmichaud> I could use something like 'pushaction', definitely.  I'll probably start using it as an interim measure until its replacement is available
<allison> ah, I need to update my branch, it still has the user stack
<allison> pmichaud: it doesn't do exactly what you think it does, but that conversation can go back to #parrot
<pmichaud> allison: okay.  It won't happy anytime immediate anyway -- we already have one workaround for now.
<Coke> Yup. wrapping up this topic, any last minute quips before moving onto patrick?
<Coke> alrightee. patrick, you're up.
<pmichaud> I'm just wanting to point out RT#53302, to make sure it doesn't get warnocked.
<pmichaud> (:method automatically being entered in namespaces)
<pmichaud> it came up last December, based on me mis-interpreting something in Parrot
<pmichaud> it's come up again, in Rakudo code this time
<pmichaud> except this time I've switched sides to agree with allison :-)
<allison> ah, okay, thanks for the heads up, I didn't see the ticket
<pmichaud> can I assign you the ticket for now?
<allison> sure
<allison> :export seems like it needs another noun, "export to what?"
<allison> but agreed that :namespace is confusing
<pmichaud> actually, it's "export *as* what?"
<Coke> bikeshed: visible
<pmichaud> again, I was just loosely following Perl 6's   "is export" for methods.
<pmichaud> :visible works for me
<allison> as what namespace name? 
<pmichaud> yes, as what name in the namespace
<allison> "visible as what?"
<pmichaud> .sub 'foo' :export('bar')
<allison> ah, I see
<pmichaud> I don't really need the :export('bar') capability;  just having :export would be good enough
<pmichaud> nor is it terribly important what the flag is named :-)
<pmichaud> (beyond normal considerations, that is :-)
<allison> yeah, not huge
<allison> it'd be nice to get something clear, if possible
<allison> and not confusing with other unrelated features
<allison> I'll keep the ticket open and think about it more tomorrow
<Coke> ok. getting close to wrap up time. Anyone else have pending questions ?
<pmichaud> anyway, we had someone play with a rakudo test program that tickled this issue
<pmichaud> so it's becoming ripe(r) for resolution
<pmichaud> (and there aren't any convenient workarounds as things exist now)
<allison> pmichaud: agreed
<pmichaud> eoq
<Coke> excellent. I'm looking forward to yapc::na & the hackathon & the workshop.
<rgrjr> yay!
<pmichaud> me too
<pmichaud> I'm  looking forward to rgrjr's presentation :-)
<particle> i also
<Coke> I'm looking forward to pmichaud's solstice presen... oh, wait.
<rgrjr> Glad to hear it; I'll have at least a few attendees, even though they put me in a sucky time slot.
<rgrjr> ;-}
<Coke> Anyone blocking on anything other than tuits?
<Coke> Oh, one more reminder: tomorrow is the last day for this quarter's TPF grant proposals. You still have a day left.
<pmichaud> I'm only blocking on tuits.
<rgrjr> How would you not block on tuits?  Wouldn't they have to be infinite?
<Coke> you can only spend N tuits a day, no matter how many you have!
<Infinoid> I'm a twit.  Does that count?
<Coke> mrfl.
<Coke> thanks for all the tuits donated so far. See everyone next week.
% Infinoid has left #parrotsketch
<chromatic> tuits are non-blocking
<chromatic> they're round
<rgrjr> <groan/>
% rgrjr has left #parrotsketch
% chromatic has left #parrotsketch
% Coke has left #parrotsketch
% allison has left #parrotsketch
% NotFound has left #parrotsketch
% cotto_work has left #parrotsketch
% jonathan has left #parrotsketch
% barney has left barney!~bernhard@dslb-084-058-115-172.pools.arcor-ip.net
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
% particle has left particle!~particle@c-24-19-3-148.hsd1.wa.comcast.net
% particle has joined #parrotsketch
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net