% particle_ has joined #parrotsketch
% particle has left particle!~particle@c-24-19-12-148.hsd1.wa.comcast.net
% particle_ is now known as particle
% particle has left particle!~particle@144.81.84.132
% particle has joined #parrotsketch
% pmichaud has joined #parrotsketch
% obra has joined #parrotsketch
% allison has joined #parrotsketch
<allison> hi all
<allison> who's here?
<particle> we're waiting till 1830gmt, is the meeting early?
<pmichaud> I'm here
<allison> oh, time change
<pmichaud> yes, I forgot about the time change also :-)
<pmichaud> my report is short, anyway
<pmichaud> vacation does that :-)
* allison exits her calendar alarm
<allison> s/exits/edits/
% chromatic has joined #parrotsketch
* obra has a brief report today
<particle> !
<pmichaud> I show 18:35
<chromatic> Time to go.
<pmichaud> Coke said he would not make it to day
<pmichaud> s/to day/today/
* jonathan_ is here
* particle too
<chromatic> Let's go in alphabetical order.
<chromatic> ALLISON
<allison> I've been working through some great comments on the objects PDD from particle and jonathan.
% smash has joined #parrotsketch
<allison> I'm catching up on the mailing list at the moment.
<allison> EOR
<chromatic> I've poked at some weirdly designed parts of the system.
<chromatic> STM is a subject of curiosity, but I think we have part of a solution for part of it.
<chromatic> I also revised the Parrot::Embed build process to use Perl's ExtUtils::MakeMaker for in-tree builds.  I'm not sure how it works on Windows, but it ought to be much closer.
<chromatic> I don't have RT perms to close bugs.  Yet.
<chromatic> Finally, I'm adding an import() method to NameSpace.
<chromatic> Next: jonathan_.
<jonathan_> I have Parrot time again, which makes me happy.
<jonathan_> Been working on implementing PDD15, but that required a detour...
<jonathan_> * Discovered that PMINVOKE didn't actually work, so fixed it.
<jonathan_> * Later discovered that PMINVOKE and PMETHODs in general had GC issues - 
<jonathan_> if GC ran while you were inside one then,h the register set of the caller 
<jonathan_> (and its callers, etc) never got marked. Fixed this too.
<jonathan_> With this sorted out, PDD15 work progressed...
<jonathan_> * Adding attributes works
<jonathan_> * Can call .new() on a class to get an object
<jonathan_> * Builds the attribute lookup table on instantiation
<jonathan_> * Attribute lookup cache implemented too
<jonathan_> * Started stubbing in inheritance, but had questions on MRO - sent my 
<jonathan_> thoughts to the list to seed discussion (successfully)
<jonathan_> * Spent some time thinking on inheriting from PMCs, have a couple of 
<jonathan_> ideas for how it can work cleanly, but nothing fully coherent yet
<jonathan_> * Sent a few other random ideas and clarification requests for PDD15 to 
<jonathan_> Allison
<jonathan_> * Tried to set Parrot::Embed on Win32, but I think my Perl installation is br0ked
<jonathan_> My stuff I want to do list is huge, but next week is...
<jonathan_> * Document PMETHODs, and maybe add a few comments to the implementation 
<jonathan_> too so other people don't have to spend so long before digging in to it
<jonathan_> * Need a way to easily call a PMETHOD from C
<jonathan_> * Continue implementing PDD15 - next step is methods, maybe then I start 
<jonathan_> on roles and flattening composition, which is the part of this I'm most 
<jonathan_> looking forward to making work
<jonathan_> Doubt I will make ParrotSketch next week, but it's for a worthy cause - 
<jonathan_> I'm at the UKUUG Spring Conference talking about Perl 6.
<jonathan_> returncc
<chromatic> leo?
<pmichaud> jonathan++ jonathan++  # fantastic work
<chromatic> Probably no Leo.  mdiep?
<chromatic> I'm impatient.  obra?
<obra> As everybody knows, about two weeks ago, I decided to step back from parrot and refocus on the role I'd originally signed up for - attempting to help shepherd Perl 6. 
<pmichaud> (impatience is a virtue)
<obra> I wish everybody the best of luck getting parrot airworthy and expect I'll be showing up occasionally to hassle y'all on Perl 6 related issues. 
<obra> In the hear future, I'll be announcing new Perl 6 microgrants. No more than USD500. No longer than a month. 
<obra> Administered by me and Leon Brocard through the Perl Foundation based on a USD5k grant made by Best Practical toward Perl 6 Development.
<obra> They'll be a mix of parrot, 6on5 and pugs related things. Start thinking about what you might want to do now.
<obra> fin.
<particle> obra++ for years of service and new projects
<jonathan_> orba++ # thanks!
<chromatic> particle!
<jonathan_> *obra
<particle> busy week for me:
<particle> ~ added kjs++ as a new committer! welcome, kjs.
<particle> ~ applied tests and refactorings of ops2c by kid51++
<particle> ~ updated PDD22 based on conversations last meeting
<particle> ~ began testing PDD15: MetaClass, MetaAttribute, Object, and Role APIs, as well as t/oo dir for testing oo implementation. provided feedback to allison++ and jonathan++ on the PDD, based on my tests.
<particle> ~ fixed many tickets in anticipation of coke++'s ambitious release
<particle> ~ add some null guards to 'stringinfo' op, converted some 'internal_exception' to 'real_exception' in string code
<particle> ~ reenabled gc in sprintf tests, after jonathan++'s gc fix
<particle> ~ creation of docs/project dir for project docs, wrote metacommitter guide
<particle> ~ started release_manager_guide based on RELEASE_INSTRUCTIONS, and made a few updates to release instructions while i was there
<particle> ~ answering many questions from the folks on #parrot, seems like more people are interested every day
<particle> ~ started converting gen::makefiles to pir, so we can separate it from configure
<particle> ~ trying to finish up crow.pir before the next release
<particle> .end
<chromatic> pmichaud
<pmichaud> Miscellaneous:
<pmichaud> * Short report this week, last week was vacation
<pmichaud> * Southern California was great
<pmichaud> * Catching up on email and other tasks today
<pmichaud> * I'm glad to see so much progress on Parrot while gone
<pmichaud> * Also glad to see Coke++ in project manager role
<pmichaud> * Kudos to obra++ for all of his ongoing support as PM
<pmichaud> * I should be back on Parrot tomorrow
<pmichaud> * I expect to be available for Saturday bugday
<pmichaud> Pre-vacation stuff:
<pmichaud> * Updated Pynie grammar and PAST transform with help from kjs++, smash++
<pmichaud> EOR
<chromatic> smash?
<chromatic> tekw?
<chromatic> tewk?
<chromatic> Anyone I missed?
<chromatic> I forgot to mention I wrote two little articles on PIR: http://www.oreillynet.com/onlamp/blog/2007/03/fizzbuzz_in_parrot_part_two.html
<chromatic> Okay.  Question time.
<chromatic> That means free-for-all, first-come, first-ask.
<pmichaud> ENOQUESTIONSFROMPMTHISWEEK
<smash> when will that issue DOT/NODOTname will be over for new opcode ?
<allison> smash: ticket #?
<particle> new .Integer vs new Integer
<allison> it's tied in with the objects PDD
<smash> oh, ok
<particle> ah, so you're working on it, great!
<allison> the .Integer makes sense if it's a macro for the type number
<allison> but we're talking about entirely doing away with type numbers
<allison> in which case, you really only have the string name
<allison> and the dot prefix makes no sense at all
<smash> ok, i can wait
* particle wonders about .local pmc Integer ; $P0 = new Integer
<allison> that's a larger imcc problem
<particle> especially if you have Integer = 'String' in there somewhere
<allison> but the simple solution is $P0 = new "Integer"
<allison> and disallow bareword class names
<chromatic> Beats a keyword list, especially with dynpmcs.
* pmichaud notes that this has now come full circle to where he started
<allison> just proves it was a good idea :)
<pmichaud> well, I'm still curious about HLL classess... but I need to read the updated pdd first
<pmichaud> I'll comment there if I see a need for it
<allison> I don't recall if that discussion made it into the updated PDD, but should be there if it isn't
<chromatic> Alright.  Next question?
<allison> have we announced the bug squash-a-thon this weekend yet?
<chromatic> Now would be a good time.
<particle> no, coke keeps referring to it as 'not yet finalized'
<chromatic> Do we have any specific goals?
<particle> coke has a tracking ticket for the release, specified in #parrot topic
<allison> it's on Saturday, same as always, what's not finalized?
<particle> 04Fix these: http://xrl.us/u9y2 01
<particle> allison: i guess coke thought he had some control over the date :)
<mdiep> the ticket itself is no longer specified in #parrot topic. that's a saved search of the release's unresolved dependencies
% jisom has joined #parrotsketch
<particle> oh
<jonathan_> Maybe because dependencies don't show up as links if you ain't logged in IIRC.
<particle> http://rt.perl.org/rt3/Ticket/Display.html?id=41581 # tracking ticket
<chromatic> Makes sense to me.
% lichtkind has joined #parrotsketch
<particle> from the list of dependencies, this is a very ambitious bugfix release
<particle> and imo is progressing quite well
<allison> particle: the fewer changes we make from month-to-month, the better off we'll be
% lichtkind has left #parrotsketch
<allison> excellent
<mdiep> it would be a good thing to have fewer tickets in the parrot queue. atm, it's a bit overwhelming. pushing bug fixes helps with that.
<allison> oh, the changes I was talking about were changes in dates
<allison> not changes in code
<allison> bug fixes++
<particle> it's getting hard to manage 100+ new tx in the queue
<mdiep> and to manage 3-4 year old tx
<allison> indeed
<particle> i'd like to see an effort to further classify these bugs by platform etc
<allison> I've been happy at the progress we've made in these bug sqashing sessions
<particle> subsystem... it'll make searches easier for porters
<allison> sounds good
<particle> ok, i'll enter a ticket :)
<chromatic> Is it useful to have a focus for each monthly release, or is that premature or infeasible?
<particle> i've been talking to coke about targets for minor release increments
<particle> like, 0.5 may be i/o and oo implementations
<allison> chromatic: it's feasible
<allison> particle: sounds good
<particle> as for bugfix 0.4.x releases, we haven't had much focus lately
<allison> the core point is not to delay a release waiting for a particular feature
<particle> yes. but once certain features have been implemented, we have a number in mind for the release
<particle> features drive the version
<allison> the sub-major version, yeah
<particle> not the release
<allison> exactly :)
<chromatic> Any other questions?
<mdiep> have someone put together a list of summer of code ideas?
<jonathan_> One for Allison - I plan to start stubbing in the Role PMC real soon now - shall I just call it Role.pmc until a final decision on the naming is made?
<allison> yes, call it Role.pmc
<particle> jisom has a question
<allison> "The instance of Role is a role" doesn't have the same problem as "The instance of Class is class, and the instance of class is an object"
<chromatic> mdiep, I don't see a list within the Perl mentors list.
<jonathan_> You can always solve it by saying "an instance of the Class PMC is a class"...
<jonathan_> Worse is that an object is really an instance of the Object PMC too. ;-)
<jisom> do we currently have a method for defining multiple inheritence for c based pmc's?  for the pge grep, I had to add a splice to resizablestringarray.pmc because it was only in resizablepmcarray.pmc, and it'd be nice to have it in all the resizable ones without code duplication...
<particle> jisom: we're moving towards role-based composition, which is in the direction you're talking about
<particle> but currently? i don't know if you can extends foo extends bar
<jonathan_> Maybe, but the thing to understand with PMC inheritance is that your child and superclass need to co-operate on the use of the various data pointers that you can hang stuff off in a PMC.
<jisom> considering the splice would be nearly identical for all of them(or could be made as such), it'd seem pointless to just duplicate the function in each file rather than having it in one file...
<jonathan_> With MI that gets really hard to manage.
<jisom> but this is only one example
<jonathan_> Maybe if we implement role composition for PMCs that would help for this situation then, yeah.
<chromatic> Especially if that role composition could include C-level data storage.
<particle> yep, indeed
<jonathan_> Now you're onto changing the way PMCs work. :-)
<chromatic> Seems like the next step after variable-sized PMCs.
<particle> that's not out of the question, there's still leo's unimplemented cstruct proposal
<jonathan_> Yeah, true.
<particle> in fact, coders welcome to implement leo's spec
* jonathan_ runs away
<particle> i think that should be announced somewhere, like in an rt ticket
<particle> ooh, and i know how to do that!
<allison> I started on leo's variable-sized PMC spec, but it's not quite a spec
<allison> it's more a loose collection of semi-related ideas
<allison> which made implementation interesting
<particle> parrot has a history of interesting implementations :)
<jonathan_> If the spec was clear, it'd probably be more approachable to implementors.
<allison> but I haven't had time to work on it lately, and would be happy to pass along the condensed list of what it actually needs to do to anyone else who wants to tackle it
<particle> so, i gather the 'spec' needs a few rounds of feedback
<allison> yeah
* pmichaud thinks "you are in a maze of interesting implementations, all different."
<particle> allison: if you can stick a patch somewhere for folks to play with, that'd be great
<allison> a patch to the proposal?
<allison> or my notes?
<particle> no, your notes/implementation/work so far
<allison> ok
<allison> I'll try to do that this week
* particle gets eaten by a Grue Collector
<particle> oh, one thing more from me
<particle> we have had a gc bug for a long time with pge
<chromatic> It's not the only GC bug.
<particle> i'm considering the removal of -G from the test code that hides the bug
<particle> at least, until near release time
<mdiep> I think removing -G is a good idea
<particle> any dissenters?
<pmichaud> <-- no dissent
<chromatic> Do it.
<jonathan_> The biggest thing with GC bugs is being able to replicate them, which changes from time to time. So anything that increases the chance of that, will help.
<allison> pmichaud is most affected, so go with his call
<particle> wilco
<pmichaud> it's okay with me if the tests fail on gc bugs... I'm used to it :-)
<chromatic> Uh, are we talking about deliberately leaving tests failing?
<chromatic> 'cuz... no thanks!
<particle> chromatic: until sometime before the release, yes
<pmichaud> pge tends to evoke gc bugs, and gc bugs aren't things I can readily fix
<particle> for one thing, it'll help us know what platforms they occur on
<chromatic> We have TODO tests for a reason!
<mdiep> I don't think language tests should todo parrot bugs.
<pmichaud> and also, marking a test as 'TODO' because it fails under GC feels wrong
<allison> is this one specific test failure?
<pmichaud> no, they migrate all over the place
<allison> or a general -G throughout all pge tests
<particle> yep, it's deep internals
<pmichaud> it's a general -G throughout tests
<particle> #! parrot -G
<particle> on three files under t/compilers/pge
<pmichaud> i.e., in order to get the tests to pass, we add -G
<particle> ack -- -G t
* allison shudders
<pmichaud> the same appears in various languages/* implementations, especially those that use PGE
<chromatic> I'm concerned that if we leave tests failing, we condition ourselves to accept a certain amount of test failures as the default condition.
<allison> is there a ticket specifying the GC failures on that set of tests?
<pmichaud> I've filed tickets on gc failures in the past... but they're so transient that I don't know anyone who wants to work on them
<chromatic> As well, people who aren't the sinister keiretsu have little chance of knowing that certain test failures are meaningless.
<jisom> but ignoring the bug won't help it to get fixed, and we need it to occur to fix it
<chromatic> Take, for example, kid51.
<allison> the obvious course of action seems to that the person working on the bug turns off -G and diggs for the GC failures
<chromatic> "OH MY GOODNESS, TESTS ARE FAILING NOW!  Did I break them with my refactoring?  I can't tell!"
<pmichaud> part of the problem is that with -G on, nobody seems inclined to work on the bug
<mdiep> pmichaud: the problem with GC tickets is what to do when you can no longer reproduce the bug
<jisom> we need a "mightfail" instead of todo :)
<pmichaud> mdiep:  that's why all of my reports identify the specific svn revision
<chromatic> Do we need better GC tracibility?
<allison> chromatic: always :)
<allison> ok, turn -G off now
<pmichaud> mdiep: granted, this doesn't help much except for short periods of time
<allison> turn it on again if the problem isn't resolved by end-of-day Saturday
<particle> okay, i'll enter a ticket to track the issue
% obra has left #parrotsketch
<particle> that'll notify the list of my doings
<particle> and which tests to expect possible failure in
<mdiep> pmichaud: right. for instance: 41035, 40990, and 40966 no longer reproduce here. but there have been changes since then, so I can't be sure if the actual bug is fixed or not.
<pmichaud> mdiep: right
<mdiep> I'd vote that we just close those tickets and open up new ones if the problem appears again.
<pmichaud> I don't have an issue with that
<allison> mdiep: go for it
<particle> alternately, make the tickets stalled
<particle> rather than closed
<allison> stalled implies that they're still an issue
<pmichaud> I think it's worthwhile to close them, as there's no adequate way to know that they've been resolved
<pmichaud> I'd reject the tickets
<particle> ok
<pmichaud> I mean, mdiep is correct -- we don't know if the bugs still exist or not, and don't have a way to find out using the information in those tickets
<jonathan_> Does removing -G on the PGE tests cause failures *now*?
<particle> jonathan_: svn up and find out :)
<particle> -G removed in r17470
<jonathan_> OK, will try later.
<particle> prove t/compilers/pge # to test
<pmichaud> fwiw, most of the problems I've encountered seem to have something to do with Key PMCs
<chromatic> Interesting.
<jonathan_> That's might help to know, I'll keep it in mind if I go digging.
<pmichaud> i.e., the segfaults that I get all occur as subcalls to various *_key_* functions
<chromatic> It has "special" GC....
<chromatic> When you have multi-value keys, for example?
<pmichaud> hmmm
<pmichaud> I haven't associated it with multi-value keys, but it's possible
<pmichaud> I could start eliminating the multi-value keys to see if that "fixes" things
<pmichaud> the problem is that _any_ change to the code often causes the gc bug to disappear
<mdiep> pmichaud: tempting as it is, we don't want to be working around Parrot problems unless the bug is reproducible and we can write a test.
<jonathan_> My analysis of that is that it is often because changes to the code result in new PMCs getting allocated at different times, so GC runs at different times.
<pmichaud> mdiep:  I haven't added any -G flags to any tests... others have done that.  All I do is report the bug :-)
<chromatic> Perhaps we should take this discussion to #parrot.
<jonathan_> Maybe a way to force GC after every op would help.
<jonathan_> Only sometimes though.
<particle> ticket entered.
<chromatic> Any final questions?
<allison> thanks everybody, see you Saturday
% chromatic has left #parrotsketch
<jonathan_> thanks, cya
% jonathan_ has left #parrotsketch
% allison has left allison!~chatzilla@sub17-30.member.dsl-only.net
% rafl has left rafl!~rafl@armitage.dreker.org
% rafl has joined #parrotsketch
% coke has joined #parrotsketch
% coke is now known as Coke
% Coke has left #parrotsketch
% pmichaud has left #parrotsketch
% avar has left avar!~avar@dsl-228-236.hive.is
% avar has joined #parrotsketch
% jisom has left jisom!~jisom@74-134-230-123.dhcp.insightbb.com
% avar has left avar!~avar@dsl-228-236.hive.is
% avar has joined #parrotsketch
% avar has left avar!~avar@dsl-228-236.hive.is