% Coke has joined #parrotsketch
% mdiep has joined #parrotsketch
<Coke> I will no doubt miss the actual meeting again today. Report: Updated tcl so that it's using a ParrotObject wrapper around a .Sub for all user defined procedures. I'm taking the next release (0.4.10) and swapping with Matt. I've started tossing tickets into the milestone release ticket at http://xrl.us/u7hs. Please go through and 1) take any that you can resolve in the next 2 weeks, or 2) add more that you were working on anyway.
<Coke> Expect the usual bug day time. I'd like to have tickets opened for planned work in advance of that. (if they're not open already).
<Coke> EOR.
<mdiep> My report for the week:
<mdiep>  - Finally managed to get back into Parrot development
<mdiep>  - Not sure how long that'll last... but the semester's over in a month
<mdiep>  - That coincides with the April release (which is why Will and I switched)
<mdiep>  - Began by taking a look at chromatic's call-a-multi-in-C test
<mdiep>  - Found that Sub/Coroutine/Continuation are a mess
<mdiep>  - Trying to clean that up enough that the fix for chromatic's bug becomes obvious
<mdiep> One question wrt pdd15:
<mdiep>  - The accessors don't begin with "get_". While I hate "get_", it appears to be what we've chosen for Parrot. Those accessors should get changed, right?
<mdiep> ^D
% kjs_ has joined #parrotsketch
% allison has joined #parrotsketch
% chromatic has joined #parrotsketch
<chromatic> Good ${TIMEZONE}, hackers.
<allison> ${insert_culturally_appropriate_phrase_here} to you, chromatic.
<particle> hi-o
<chromatic> And your ${LOCAL_BEAST_OF_BURDEN} too, Allison.
<chromatic> Who else do we have?
<Coke> ~~, though I've already reported.
<chromatic> Alright, let's start then.
<chromatic> Coke, where did you report?
<Coke> here. tweety has it.
<chromatic> Okay.  Allison?
<Coke> http://www.parrotcode.org/misc/parrotsketch-logs/irclog.parrotsketch-200703/irclog.parrotsketch.20070306 , if you're feeling somewhat meta.
<allison> Not typed in advance: We had a tremendously productive hackathon this weekend.
<allison> Jonathan and I spent a long time threshing out the internal structure of the new object metamodel.
<allison> and started implementing it
<allison> (extending the smop C prototype tewk started)
<allison> I've still got some tests from that I need to check in
<allison> one thing I'd like to differently in later hackathons, is prepare an introduction for new parrot hackers
<allison> EOR
<chromatic> particle?
<particle> ~ almost all my commits this week were for Crow. i hope to add support for multiple templates soon, that should make writing release announcements pretty easy
<particle> ~ had a few more thought about pdd22 (io). would like to discuss with allison
<particle> ~ looking for hardware for a vm server. smash++ has created one for us to use (windows xp, debian stable, openbsd, and solaris.) it's not GA both because it's run from his home and underpowered. it's proven quite valuable already. know of anyone who might help us host such a beastie?
<particle> ~ resolved two easy 0.4.10 related tx today
<particle> .end
<chromatic> Okay.  I read patches on the commit list and yell if anything bugs me.  So far so good, though some of the MOP stuff looks like easy targets for eventual refactorings.
<chromatic> Anyone else here?
<chromatic> Allison, are you blocking on anything?
<allison> not at the moment, no
<chromatic> Coke?
<chromatic> particle?
<particle> yes, always
<chromatic> Anything we can fix somehow?
<particle> perl6: patrick -- he's on vacation, so that's expected
<particle> parrot: i/o and therefore objects
<particle> i need these done before i can implement pure-pir testing framework
<chromatic> Do we have tests in place for the IO behavior you need?
<particle> i have created tests for the I/O objects, based on PDD22
<particle> i have not yet created tests for interpreter control ala IPC::Run
<particle> good idea, that'll help with requirements for the designer/implementor
<Coke> (blocking) I had some issues with the ParrotObject vs. PMC stuff, but worked around it.
<chromatic> I think everyone has issues with ParrotObject versus PMC.
<chromatic> I notice that mdiep is looking at my multicall bug, yay.
<chromatic> He also had a question:
<chromatic> Regarding PDD 15, the accessors don't begin with "get_". While I hate "get_", it appears to be what we've chosen for Parrot. Those accessors should get changed, right?
<allison> separating out get_ and set_accessors? Yes, that's a good idea for consistency
<allison> though, I'm undecided on the "get a list of all attributes" (for example) accessors
<chromatic> In creating them at all or renaming them?
<allison> I almost think that should be more of an introspection feature
<allison> I guess there's no reason introspection shouldn't use the familiar interface
<chromatic> That's part of the point of a MOP.
<allison> we'll try it and see what it's like to work with.
<chromatic> Are there any other questions?
<particle> yes, looking for hardware for a parrot dev vm server
<particle> smash has put enormous effort into setting up a beta for us, and so far it's working great
<chromatic> Hardware as in "If we had some money, we should buy some hardware?"
<particle> i think we can take the lessons learned there and quickly set up something manageable
<particle> smash: you here?
<smash> particle: yeap
<allison> put together a hardware proposal and we'll run it by TPF
<smash> allison: me ?
<particle> ok, great. we'll need hosting/bandwidth, too
<allison> you or particle, either one
<particle> smash: we'll work together :)
<allison> or both :)
<smash> sure.. the bigger problem in my POV is actually hosting/bandwidth
<allison> so note that cost as well
<particle> fab.
<allison> as I understand it, the box you have is somewhat limited speed? so a little more power could be useful
<smash> hmm, dont think so.. it only needed more memory (which i got it) the bigger problem (mos ppl comlaint bout) is latency/bandwidth
<particle> latency--
<smash> but that would also depende on what vm machines would be running at the same time
<smash> (you can always stop some and start others in real time)
<chromatic> Does PITA offer any interesting guidance?
<smash> my approach would aybe be, more modest hardware with a GOOOD conectivity (at least, that's what i think)
<particle> not yet, pita's still too far off
<smash> particle: but feel free to ping me for details (that's all for my opinion)
<particle> smash: will do. if you're hosting this locally, i can't tell much about prices, though
<particle> let's talk about it in #parrot
<chromatic> Next question.
<chromatic> Branch management.
<chromatic> If kid51's working on stuff in tools/, why does he have to synchronize the rest of the repository?
<particle> i reserve two q's on pdd22 (io)
<chromatic> Failure of the model, failure of Subversion, or something else?
<particle> "synchronize the rest"??
<chromatic> Yeah, look at the commit logs.  When he syncs to head, he pulls in stuff in languages/ too, for example.
<particle> if i had to say anything, it seems he's synchronizing too often
<particle> don't need to do it every day, as the modules he's working on aren't under active development
<chromatic> Why synchronize stuff out of the directory he's working on though?
<chromatic> I mean "outside".
<particle> i imagine so he can run make test
<particle> and make sure everything still tests after his refactorings
<particle> when you're refactoring configure/build system, that's the safe way
<particle> since languages/ uses the same configure/build system as parrot core
<chromatic> I can buy that, but I thought you could switch part of a checkout path to a branch and leave the rest.
<particle> ah. i think svn is COW, so i don't know that it's actually updating anything other than metadata
<particle> i'm not terribly familiar with svn branch management
<chromatic> Anyway, my question is if we should encourage people to develop in public branches or to use distributed version control and update on their own.
<particle> mugwump has suggested 'git'. from my perspective, i don't care what a developer uses for scm locally. we have chosen svn for the repo, and that's staying around.
<chromatic> I can see pros and cons.
<particle> i won't use git, mainly because i can't.
<particle> (no win port)
<chromatic> Public development lets other people see works in progress fairly trivially, but it can clutter up the commit list and the repo.
<chromatic> Private development means less management overhead for other people, but less visibility into the process.
<chromatic> A third possibility is discouraging long-lived branches.
<particle> agreed, the frequency of commits/synchs is an annoyance.
<particle> i like public development, because it allows sharing
<chromatic> Any other opinions or questions on this?
<particle> how about a seperate pugs-style repo
<allison> people don't see it
<particle> then patches can be made to the "official" repo
<allison> is the main concern just that it's flooding the commit list?
<particle> the main concern is lack of strategy
<chromatic> My main concern is that it may be creating more work than its value.
<allison> it's not a concern of server overhead, since we're fine there
<allison> integrating the patches back into the mainline is more work than value?
<chromatic> Managing a long-lived branch may be more work than value, especially with Subversion.
<allison> yeah
<allison> the general rule is branches live as briefly as possible
<allison> this is just a short build-tools overhaul
<allison> not intended to stick around for 6months
<particle> "short" is 4mo now
<allison> then it's time to review the plan for the build-tools overhaul
<particle> so maybe we should have had different branches - pmc2c, ops2c, ops2pm, parrot-distribution, etc
<particle> and the upcoming configure-pl refactor
<Coke> (merging long lived branches) I remind of the pain of merging dan's string code back to trunk.
<particle> ooh, ick.
<allison> it totally depends on the size and scope of the refactor
<chromatic> If these are really refactorings, why do they have to land in big thuds?
<Coke> branches good. If it's too noisy, people can filter based on branch.
<allison> should we take this to the list?
<allison> seems like a larger planning thread
<allison> not limited to one branch, or one refactor
<Coke> Sure. I can put something together this evening if you like, and solicit comments.
<allison> excellent, thanks
<chromatic> particle, you had two more questions.
<particle> yes, short ones, i hope
<particle> pdd22 has IO methods returning Status objects for most methods
<particle> .print() doesn't return anything. i think it probably should
<particle> sound good?
<allison> yes
<particle> ok
<particle> also
<allison> a status object, I presume
<particle> yes.
<allison> also?
<particle> also, async methods currently send a callback, and return a Status object
<allison> yes
<particle> a Status object is passed to the callback
<allison> yes, same status object
<particle> and returned from the method call
<particle> is that desired?
<allison> aye
<particle> ok. that's it for me. shall i update the pdd?
<allison> the status object returned from the method call you can use to check the status while the async call is still in progress
<particle> ah, gotcha.
<allison> and, the callback doesn't have access to the original context, so we pass it the status object too
<allison> (worth adding a note to the PDD)
<particle> indeed
<allison> yes, please do update the PDD, thanks!
<particle> will do.
<chromatic> Last chance for questions.  Anyone?
<particle> one
<particle> i'm thinking about a focused hacking day
<particle> it's really time for Configure.pl to be refactored and improved
<particle> we have folks interested in porting to pdas and such
<chromatic> Separate from a bug day?
<allison> like the bug squashing sessions? meeting on IRC?
<particle> yes
<particle> could be *on* a bug day if that makes it easier
<allison> sounds like a good idea
<chromatic> Do we know enough information about how to improve it to make it happen?
<allison> same time or different time could work
<particle> well, we have some ideas already on how to make configure better
<particle> increasing test coverage is certainly an important start
<chromatic> I think we'll make better progress with very clearly defined bite-sized tasks.
<particle> ok
<particle> perhaps, discussed on list, then opened as tx?
<chromatic> I could even see using a branch for it.
<Coke> yes.
<Coke> (list, tickets, and branch. yes.)
<particle> sounds good to me
<particle> that's all from seattle.
<Coke> new york, out.
<chromatic> That sounds like it.  Thank you all.  See you next week.
<allison> thanks all!
% chromatic has left #parrotsketch
% kjs_ has left #parrotsketch
% Coke has left #parrotsketch
% allison has left allison!~chatzilla@ppp-71-139-10-127.dsl.snfc21.pacbell.net