% spinclad has left spinclad!~rhale@209-6-140-232.c3-0.bkl-ubr2.sbo-bkl.ma.cable.rcn.com
% spinclad has joined #parrotsketch
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% contingencyplan has joined #parrotsketch
% pmichaud has joined #parrotsketch
% jhorwitz has joined #parrotsketch
% jonathan has joined #parrotsketch
% amoore has joined #parrotsketch
% kjs_ has joined #parrotsketch
% barney has joined #parrotsketch
% chromatic has joined #parrotsketch
% moritz has joined #parrotsketch
<chromatic> Roll call!
* barney is here
% allison has joined #parrotsketch
* jonathan is here
* particle  
<allison> hola
<chromatic> Let's begin then.  allison?
<allison> not pretyped
<allison> but...
<allison> - I'm finding that giving 3 talks in 3 countries in 2 weeks, is not good for productivity
<allison> - my plan for the year is to say "no" to all new talk invitations
<allison> - I did make some progress on the PMC implementation
<allison> - chromatic has been quite helpful there, chewing through tasks
<allison> - I hope we can have that branch finished off and ready for language testers this week
<allison> (though I fly again tomorrow, so it'll be late this week)
<allison> EOR
<chromatic> barney?
<barney> Fiddled with perl6/Makefile
<barney> Otherwise was busy with preparing for freelancing
<barney> .eor
<chromatic> I fixed a couple of bugs.
<chromatic> Then I worked on PMC PDD tasks -- still have one to do.
<chromatic> Then I looked at how to remove PARROT_API from VTABLE functions.
<chromatic> Then I worked with Andy to clean up IMCC's memory leaks.
<chromatic> All three will continue into the next week.
<chromatic> jonathan?
<jonathan> * Hacked on getting the very, very preliminary bits of OO support into Rakudo
<jonathan> ** Making attributes a tad more in line with S12
<jonathan> ** First cut at inheritance
<jonathan> ** Parsing roles
<jonathan> ** Very initial work on role composition too
<jonathan> * Blocking on something in PAST -> POST translation, though maybe it's not a bug - waiting on pmichaud's feedback on that. Have a workaround for it if I need that.
<jonathan> * Fixed the Role PMC to pull methods from the namespace, like the Class one does
<jonathan> * Reading various interesting stuff Stevan Little sent me
<jonathan> * Next up I want to start getting some of the OO tests together
<jonathan> * Going to 3 conferences this month (GPW, UPW, DPW); hope to try and attract new Rakudo and/or Parrot contributors and get some hacking done, or at least just show people what's going on with it.
<jonathan> * Pondering that I really should do some of the packfile stuff.
<jonathan> EOR
<chromatic> particle?
<particle> ~ added a first pass at perl6doc -- it's not much, but it's a start
<particle> ~ discussed list context and other PAST-related items, but no real action
<particle> ~ some work on a serialized PAST emitter and parser, but no commits yet
<particle> ~ submitted oscon talks
<particle> ~ i'm having trouble keeping up with mail/patches/irc this week, and that's likely to continue into next
<particle> .end
<chromatic> Any other committer?
<kjs_> me
<kjs_> I started working on cardinal, which was an empty language shell. Before that, I've updated ecmascript, punie and pynie.
<kjs_> but those are on hold as i need featurs of past that aren't there
<kjs_> such as break/return/continue and friends
<kjs_> .eor
<chromatic> Anyone else?
<chromatic> Okay.
<chromatic> Are there questions this week?  I have one.
<particle> i have one
<chromatic> Go ahead.
<particle> seems hll developers need more from Sub PMC's arity method
<Tene> Yes, we do!
<particle> things like # optional, # slurpy, # named, etc
<particle> i propose an api like .arity( PARROT_ARG_SLURPY ) etc
<particle> $I0 = PARROT_ARG_POSITIONAL | PARROT_ARG_OPTIONAL ; $P0.'arity'( $I0 )
<allison> not sure arity is the right method, but agreed we need an interface for that information
<jonathan> Maybe stop using FixedIntegerArray for signatures, but instead a subclass of that.
<chromatic> That might improve some of the code in inter_call.c too.
<jonathan> And the subclass has methods for introspecting such things.
<particle> yes, this can definitely improve inter_call
<jonathan> Then Sub PMC gets a get_signature() method.
<chromatic> (by "improve" I mean "shorten and simplify")
<particle> what about a Capture/Signature PMC in core?
<allison> how about $P0.'inspect'('slurpy_params')
<jonathan> On the sub?
<allison> yup
<jonathan> Woulrd work too.
<jonathan> Of course, slurpys are named and positional.
<allison> we added 'inspect' for introspection on all PMCs
<jonathan> Sure.
<jonathan> Like that approach.
<particle> ok, then 'arity' becomes an alias for the inspect vtable
<jonathan> Stops us having a method explosion.
<allison> $P0.inspect('arity')
<jonathan> And you can cache this hash that contains this introspection info in the sub.
<allison> $P0.inspect('named')
<chromatic> I'm all about the caching.
<particle> sure, arity never changes
<allison> Isn't the information already an attribute of the Sub PMC?
<jonathan> Right. But we needn't build the introspection hash unless it's asked for.
<chromatic> ... not... really...
<chromatic> It's not in the Sub PMC in a useful form at the moment.
<allison> Oh, we don't build the introspection hash for individual calls
<particle> it would be so easy if this info was in the pmc
<allison> I mean, for calls that ask for a single point of data
<particle> arity is constant
<jonathan> allison: We cache each individual item and build the hash when it's asked for?
<particle> it's set at Sub creation time
<allison> but, I do like the idea of caching the whole hash if someone does call $P0.inspect()
<particle> i don't see why it shouldn't all be cached at once
<particle> it's used for every PCCMETHOD call
% Coke has joined #parrotsketch
<allison> arity is used?
<jonathan> I don't think caching it all at once would hurt performance too much, but it may hurt memory usage. But it depends on what uses it.
<particle> you need to match up the params/args
* Coke ~~
<jonathan> I mean, one run through the signature PMC tells you all of the info you need to build the hash.
<allison> it also depends on whether we need to use all the other possible introspection information
<particle> jonathan: right
<allison> jonathan: we may ultimately add more introspection options than just signature information
<chromatic> Coke, do you have a report?
<Coke> ayup. brief one.
<jonathan> allison: Good point.
<allison> jonathan: but for now, cache the signature when we initialize
<jonathan> allison: OK. It's the interface that matters, anyway.
<allison> jup
<jonathan> We can optimize the implementation when we see the use cases.
<allison> on to coke...
<allison> aye
<Coke> $DAYJOB busy still; minor updates to website, mailing list; 
<Coke> Going through RT tickets trying to close, update, or otherwise
<Coke> prod movement on some old stuff.
<Coke> Tcl is still borked.
<Coke> Piper vanished from logging #parrot; Robrt notified, looking into it.
<Coke> EOR
<chromatic> Okay, back to question time.
<chromatic> If there are no more questions, then I'll go.
<chromatic> Are we still getting sufficient value out of the SVN metadata tests that we should still include them in 'make test'?
<jonathan> Anyone for implementing the introspection on subs stuff as just discussed? If not, I'll take it.
<particle> they used to be in t/distro/, and run once a month
<particle> (pre-release)
<particle> i'm fine if they go back to that
<chromatic> I ask because I can't remember the last time they caught something that would have been a real problem.
<allison> moving them to make fulltest is fine with me
<chromatic> However, I can remember quieting them a few dozen times in recent memory.
<particle> i'd also like to see the configure tests consolidated to one dir
<allison> they  occasionally catch something, and I'll fix a few files
<chromatic> But do they catch something *useful*?
<particle> and see the config tests run only during config time
<particle> svn:metadata is only somewhat useful
<allison> if we made it a policy to run them once between releases (so every two weeks), it won't be too much hassle for the release manager
<particle> the most important is line endings, as far as i'm concerned
<barney> checking for svn:keywords and for svn:filetype is useful
<chromatic> Is it *useful* in that it catches real bugs?
<Coke> Not IME.
<particle> line endings catches real bugs
<particle> but only for i/o
<Coke> but wouldn't those bugs smoke soon anyway?
<chromatic> I know it catches real bugs in heredocs and a couple of other tests.
<barney> I'd rather generate MANIFEST on release
<Coke> I'm a big fan of testing *features* and regressions and such, but not all this meta-test.
<Coke> barney: there was an old thread, MANIFEST MUST DIE.
% Andy has joined #parrotsketch
<Andy> Did I miss everything?
<Coke> (yes. see the web logs)
<allison> the reason we maintain it constantly is that it gives us lots of opportunities to catch errors in the MANIFEST
<particle> no, but we missed you
<Andy> waaah
<allison> anything we look at only once a month has a higher chance of errors creeping in
<particle> running mk_manifest_and_skip.pl could be a post-commit hook
<chromatic> The proposal then is to move the SVN props tests to t/distro/ and to recommend that people run make fulltest more often.
<allison> and, releases won't always been once a month, after 1.0 they'll be more like every 3-6 months
<particle> chromatic++
<allison> chromatic: agreed
<particle> allison: after 1.0 we can change the rules
<Coke> no, but with a less rigorous release schedule, it's ok to slow down the frequency of these meta tests, too. "what particle said."
<allison> particle: define a set of things we do once a month between releases, agreed
<Andy> and just before release.
<particle> yep, it becomes a cage task
<chromatic> That requires getting people besides just me and the release manager to run and report 'make fulltest' and fix what they can.
<Andy> Have we all patted c on the back for driving the mem leak stuff?  We did?  Good.
<chromatic> Speaking of which, do you have a report Andy?
<Andy> Just doing what you're doing: Cleaning up the memory leaks.
<Andy> Hey, do we have an opinino either way on snprintf()?
<Andy> vs. sprintf?
<Andy> Never mind, I'll post to the list.
<Coke> <nixon>I am not a c....programmer</nixon>
<chromatic> I agree with particle about the configure tests, by the way.
<allison> chromatic: moving all configure tests to make fulltest?
<particle> first, consolidating configure tests under one dir
<chromatic> Consolidating the configure tests in one directory and running them only before and after configuration time.
<Andy> Anything we can do to make "make test" quicker and less painful leads to more running of "make test"
<particle> t/configure t/steps t/postconfigure
<moritz> Andy: like parallel testing?
<allison> andy: agreed
<particle> second, only running them with perl Configure.pl --test
<Andy> Well, I always run make -j2 test
<Andy> whcih works jsut fine.
<Andy> but I'd like it to be EVEN FASTER
<chromatic> Andy's exactly right.  Occasionally we get legitimate failures because people don't run the tests because the tests that test non-functional features take way too long to run.
<moritz> Andy: but it doesn't work when parrot isn't built, because parrot build fails too often with -j $something
* Andy sheepishly raises his hand.
<allison> particle: I'm generally okay with the idea, but should talk it over with kid51, since he's primary maintainer of that subsystem
* particle admits he hasn't been running the 10min test suite often enough
<Andy> moritz: I have zero problems with -j2, but that's not the point here.
<particle> guess why?
<Andy> particle: You forgot how?
<particle> allison: yes, will do.
<particle> andy: i forgot that my time is not valuable, and i have 10 minutes to wait.
<Andy> I AM MASTER OF MULTIPLE WINDOWS.
<Andy> But even then it's still painful.
<particle> ayep.
<particle> ok, so we'll aim to fix that.
<barney> For quick tests we have 'make testj' and such
<Tene> Are buildbot propositions relevant here?
<particle> proposals?
<Tene> I've seen some buildbot discussions in #parrot every once in a while.
<particle> probably better on the mailing list. what do other folks think?
<Andy> Yeah, never proposition a buildbot.  
<Tene> I'm just wondering if tests that take a long time to run might be better run by a bot, because historically people won't run them often.
<particle> yes, agreed, tene.
<chromatic> Only non-functional tests.
<Andy> c: yes
<chromatic> Or tests on platforms not under your direct control.
<chromatic> Rationale: I'm all for buildbots, but only as an enhancement to knowledge.
<chromatic> It's much faster and requires less context-switching to be able to run 'make test' and get an answer right now.
<allison> yeah, we need them run by buildbots anyway to get multiple platform results
<Andy> We need more buildbots on more platforms, too.
<Andy> See also: The OS X stuff we went thru.
<chromatic> If we can't get that answer right now, I think the answer is to speed up our tests such that we can get an answer right now, not rely on buildbots to get an answer even later.
<allison> but, everything needed to verify before a commit, should always be included in a local test target
<allison> whether it's make test, make devtest (something like that), or make fulltest
<allison> buildbots are for post commit continuous testing
<Andy> allison: And for doing the testing the humans aren't.
<chromatic> or can't
<allison> yes
<chromatic> The proposal then is to review the configuration tests with kid51, then try to recruit more buildbot slaves on other platforms.
<Andy> I think my next Big Sweeping Task will be to eradicate sprintf().
<chromatic> Are there any other questions?
<chromatic> Alright, thank you all.   Let's adjourn until next week.
<allison> Thanks all, and thanks c.
<jonathan> See you all next time (maybe not next week, I'll probably be just arriving in Erlangen and failing to find my hotel, as per usual...)
% chromatic has left #parrotsketch
% barney has left barney!~bernhard@p549A2FFC.dip0.t-ipconnect.de
% Coke has left #parrotsketch
% jonathan has left #parrotsketch
% Andy has left #parrotsketch
% moritz has left #parrotsketch
% kjs_ is now known as kj
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
% jhorwitz has left #parrotsketch
% contingencyplan has left contingencyplan!~contingen@76.186.27.146
% allison has left #parrotsketch
% contingencyplan has joined #parrotsketch