Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2009-12-13

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:33 PacoLinux joined #parrotsketch
00:34 PacoLinux left #parrotsketch
00:39 davidfetter joined #parrotsketch
00:40 davidfetter left #parrotsketch
01:07 japhb joined #parrotsketch
03:00 ilbot2 joined #parrotsketch
03:00 Topic for #parrotsketchis now Vision for 2.0: Production Users | Priority for 1.9: Performance and Testing | https://trac.parrot.org/parrot/wiki/ProposedParrotsketchProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
03:00 cotto joined #parrotsketch
03:04 cotto_work joined #parrotsketch
03:05 Tene joined #parrotsketch
03:08 tewk_ joined #parrotsketch
08:03 cotto_w0rk joined #parrotsketch
13:12 mikehh joined #parrotsketch
15:56 Whiteknight joined #parrotsketch
16:01 mikehh joined #parrotsketch
16:08 mikehh joined #parrotsketch
16:15 mikehh joined #parrotsketch
16:23 mikehh joined #parrotsketch
16:34 mikehh joined #parrotsketch
17:18 mikehh joined #parrotsketch
18:19 plobsing joined #parrotsketch
18:19 kid51 joined #parrotsketch
18:20 kid51 So this is where the online Parrot Roadmap meeting will be, starting at 2030 UCT -- i.e., about 2:10 from now.
18:25 mikehh well I am here - so will see what happens
18:29 Infinoid joined #parrotsketch
18:29 Infinoid *lurk*
18:29 kid51 I guess that, just as we do in weekly parrotsketch meetings, it would be a good idea to have people pre-post any major concerns/positions.
18:30 kid51 Infinoid:  Did you get my email of several days back re hackathon?
18:31 Infinoid kid51: I did.
18:31 kid51 Thoughts?
18:31 Infinoid My mental parrot-state is about 6 or 7 months out of date, but I'm always up for breaking code
18:32 kid51 My premise is this.
18:32 kid51 As wonderful as online collaboration is, a FOSS project's developers needed F2F contact periodically.
18:33 kid51 Speaking for $self, I hate the fact that the only time I can reliably see other Parrot people is once a year at YAPC.
18:34 kid51 But, more importantly, I think that putting some of our devs in the same room for 8 hours will have important benefits.
18:34 Infinoid It couldn't hurt, certainly
18:35 kid51 And I think 1Q 2010 would be an important time to do that, since our primary HLL customer wants to have a *major* release in 2Q 2010.
18:36 Infinoid The bits and pieces of parrot time I've spent recently were almost all dalek-related.  That is useful to the cause, but only in a tangental way
18:36 Infinoid I think I'd be more useful in the proposed hackathon if I spent some time beforehand and figured out what's changed in parrot since I last looked at it
18:37 kid51 I understand.  Most of what needs to be done in Parrot these days is outside of my scope as well.
18:37 kid51 Yes, I'm hoping that one of the things we get from today's meeting is a list of things to work on between now and, say, April.
18:38 Infinoid Cool.  That's why I wanted to lurk
18:39 kid51 Are you still in Delaware?
18:39 Infinoid Yeah.  Philly is within easy reach for me
18:41 kid51 Good.  Whiteknight now has a child, so a Philly location would probably improve the chances that he can attend.
18:41 allison kid51: also see proposed topics at https://spreadsheets.google.com/ccc?key=0Ahm1zTZwW0VHdFVPSW1BemVEZU82RkFrZDZ5cTdtYXc&hl=en
18:46 * Whiteknight should really meet up with Infinoid some time, he doesn't work too too far away from him
18:49 kid51 Whiteknight:  My opinion is:  Whatever works for you!  If an F2F meeting -- even if only 4 or 5 people for 4 or 5 hours -- will help you help Parrot in 1Q 2010, then I want to do what I can to bring that off.
18:53 Infinoid Who else is in the area?
18:53 kid51 I believe jhorwitz is in Philadelphia and Austin is in Jersey near Phila.
18:54 Infinoid cool.
18:54 kid51 There are, of course, *lots* of Perl 5 people in Phila who are not involved in Parrot or (to my knowledge) Rakudo.
18:54 Infinoid Whiteknight: Dropping by with pizza one day is still on my todo list :)
18:54 kid51 Nevertheless, that's > $#NYCparrotdevelopers
18:59 allison is anyone near Chicago?
18:59 allison we could do a face-to-face during the PyCon sprints
19:00 kid51 When are they?
19:00 allison February
19:01 allison Feb 22-25th
19:01 allison (conference the week before)
19:01 cotto I most likely won't be here for the meeting, but feel free to assign me work on anything on the spreadsheet that has my name in the Interested Parties column..
19:01 cotto afk
19:28 Whiteknight I added my name to the spreadsheet a few times too, in case I can't be 100% active at the meeting
20:12 chromatic joined #parrotsketch
20:17 bacek joined #parrotsketch
20:17 bacek Good morning
20:18 bacek chromatic, looks like your comment about Concurency belong to GC
20:19 bacek (in spreadsheet)
20:22 chromatic Looking now.
20:23 chromatic You're right; thanks.
20:28 japhb Hello all.
20:29 particle1 joined #parrotsketch
20:31 allison hi
20:31 mikehh hello
20:31 japhb o/
20:31 chromatic greetings
20:33 * bacek wave from tomorrow
20:33 chromatic Who's in charge and what's the agenda?
20:33 allison I know a few people won't make it in until later
20:33 allison it's worth starting with collecting a list of topic
20:34 allison we've got the spreadsheet of potential roadmap items
20:34 allison https://spreadsheets.google.com/ccc?key=0Ahm1zTZwW0VHdFVPSW1BemVEZU82RkFrZDZ5cTdtYXc&hl=en
20:34 allison chromatic: would you care to do the honors?
20:34 chromatic Reading spreadsheet.
20:35 chromatic I think there are several potential topics we should consider.
20:35 chromatic In no particular order:
20:35 chromatic *) What have we done right in the past year?
20:35 chromatic *) What mistakes did we make that we need to improve?
20:35 chromatic *) What short-term projects do we need?
20:35 chromatic *) What long-term goals do we need?
20:35 chromatic *) How can we be more effective?
20:36 chromatic Perhaps also:
20:36 chromatic *) What isn't working?
20:36 allison *) what items should we schedule for which releases?
20:36 chromatic That might be an open question; can and should we schedule those?
20:37 allison *) what are realistic goals, based on our velocity in the past year?
20:37 particle1 *) what is the goal for this meeting?
20:37 allison this meeting is a virtual substitute for PDS
20:37 particle1 i expected this to be a roadmap planning session, not a retrospective.
20:37 allison so, planning the next year, at least a rough outline
20:38 particle1 but perhaps i haven't paid enough attention to know what to expect
20:38 * japhb is finding the lack of edit UI really unintuitive ... am I missing something?  How do you edit (rather than replace) field contents?
20:38 allison there's some of both, since any planning session involves some of "what can we do better?
20:38 allison japhb: double click on the field
20:38 kid51 chromatic is suggesting a process-oriented part of the session ... which I think is correct, provided we set a time limit
20:39 allison kid51: good idea
20:39 japhb allsion: ah, THANK YOU
20:39 allison how long should we allocate to retrospective?
20:39 allison 30 min?
20:39 chromatic Can do.
20:39 kid51 Yes, let's do that and reassess in 30.
20:39 chromatic Okay.  First question.  What have we done right in the past year?
20:39 kid51 Maintained monthly release schedule.
20:40 bacek kid51, +1
20:40 allison shipped every monthly release on time
20:40 particle1 added committers and release managers
20:40 allison shipped two solid "supported" releases, which are now included in the major Linux distributions
20:40 kid51 A lot more HLL activity
20:40 allison (that was a big goal behind 1.o)
20:40 chromatic Parrot's installable now.
20:41 chromatic It also feels like a more stable platform for HLL developers... not that it's completely stable, but 2.0's going to be a lot easier to build on and use than 1.0 or 1.4.
20:42 particle1 hlls and other projects have taken parrot's release process as their own (including perl 5).
20:42 bacek ...but build directory is quite different from installed parrot
20:42 allison bacek: needs to go on the roadmap
20:43 chromatic Any other successes in the past year?
20:43 particle1 in the past year, we have grown the parrot user base and committer base with very little expenditure of funds
20:43 allison optimiations
20:43 allison parrot is substantially faster
20:43 chromatic We removed some ugly code.
20:44 japhb allison: I thought we were just managing to keep ourselves from not getting substantially *slower*, not that we're lots faster ....
20:44 kid51 That was my impression as well (better, but not faster)
20:44 chromatic Parts are substantially faster.
20:45 chromatic Anything else?
20:45 particle1 we held elections
20:45 allison dukeleto did a post of some benchmarks recently, over the major releases since 0.2, and parrot is now the fastest it's ever been (by a small margin)
20:45 mikehh testing has improved but still quite a way to go
20:46 kid51 Cleared out RT in favor of Trac
20:46 allison the regular roadmap reviews have definitely been helpful
20:46 chromatic The retrospective at YAPC was useful.
20:47 chromatic #ps has improved.
20:47 particle1 chromatic: +1
20:47 particle1 it drove process changes
20:47 particle1 like #parrotsketch format change
20:47 japhb Yes, the #ps format change was quite useful
20:47 chromatic Last call for successes.
20:47 allison yes, pre-posting reports has been a big help
20:48 particle1 we created a new role, but i haven't seen any positive impact
20:48 particle1 "dev coach"
20:48 particle1 anyone who can speak to positives on that?
20:48 kid51 ... and who plays that role?
20:48 allison I'd say that's largely because he was already doing the work
20:48 particle1 chromatic plays that role
20:48 allison it was more acknowledging the work, and defining it more clearly
20:48 chromatic allison and I argue less in public now....
20:49 kid51 ++
20:49 particle1 ++
20:49 allison :)
20:49 chromatic Where's that smiley key?  Oh, forget it.
20:49 allison which doesn't mean we're arguing more in private, either
20:49 chromatic Sure, but it's not visible.
20:49 chromatic Let's move on.  What hasn't worked in the past year?
20:49 chromatic I'll start: the deprecation policy has been too contentious.
20:50 particle1 parrot foundation hasn't raised any money
20:50 mikehh we've slipped a lot on roadmap items
20:50 kid51 Too long intervals between F2F meetings or sessions like this
20:50 allison our roadmaps have been too ambitious
20:50 chromatic We have a lot of technical debt.
20:51 particle1 i think there's less than before
20:51 allison the tasks are too big, hard to tackle them in small chunks of spare time
20:51 particle1 but still a lot of technical dept
20:51 kid51 While there's been a big increase in HLL activity, the flip side of that is that our HLLs are now making more demands on us.  I don't think we've geared up for that.
20:51 chromatic There's a monthly upgrade tax for HLL developers; I can only imagine the bi-annual tax.
20:52 allison which leads to: HLLs have felt their needs aren't being met
20:52 kid51 And they, after all, are our principal constituents/clients/customers/what have you.
20:52 allison yes
20:52 particle1 we haven't prioritised the needs of hll devs
20:53 allison we have very few languages in a "finished" state
20:53 darbelo joined #parrotsketch
20:54 chromatic We haven't improved or increased our design documentation.
20:54 particle1 it's still difficult for prospective parrot hll users to find info on the completion state of a parrot hll
20:54 kid51 I confess that I'm only aware of the HLLs that have commit-bots which post to #parrot
20:54 allison it's still difficult for prospective HLL developers to find info on how to develop HLLs on Parrot
20:55 chromatic Other negatives?
20:56 kid51 I have a sense that problems the HLL devs discover do not get reflected in our test suite.
20:56 japhb kid51: I'd love a way to bring some of the low-visibility HLLs more strongly into contact with us.
20:56 chromatic Oh yeah, lack of HLL-exposed bugs in tests.  That one hurts a lot.
20:56 kid51 It basically stopped half of yesterday's hackathon dead in its tracks.
20:57 japhb Which brings up: (Occasional) assumption that test suite is complete enough to proxy for "this is or is not every used"
20:57 japhb er ever
20:57 mikehh we need to adopt a policy like rakudo - don't close tickets until test is also there
20:58 chromatic Anything else?
20:59 chromatic Next question.
20:59 chromatic How can we improve what didn't work so well in the past year?
21:00 bacek Switch to opt-in deprecation policy
21:00 allison make HLL development needs a top priority
21:00 japhb ... and three month cycle
21:00 allison bacek: elaborate?
21:01 particle1 allison: there's a mailing-list thread on a new deprecation policy
21:01 bacek allison, most of our subsystems are not mature enough.
21:01 allison bacek: since we don't currently have customers outside of the HLLs, who's going to opt-in?
21:01 allison will look at the thread
21:01 particle1 where subsystems opt-in to the deprecation policy
21:01 particle1 not users
21:02 * allison checking if this topic is in the spreadsheet yet
21:02 particle1 e.g. "the following list of subsystems are no longer considered experimental, and are subject to the deprecation policy"...
21:02 chromatic It'll be a lot of work to review every subsystem for maturity and likelihood of change.
21:02 particle1 chromatic: i wrote a stability document some time ago that should help us classify subsystems
21:02 japhb chromatic, but still seems more reasonable than what we have now
21:02 kid51 To make "make HLL development needs a top priority" concrete:  We need to do whatever we can to make Rakudo*'s 2Q 2010 release perceived as successful.
21:03 allison deprecating a couple of subsystems before 2.0 could be a good idea
21:03 japhb kid51, +!
21:03 allison (threads, for example)
21:03 japhb er +1
21:03 bacek kid51, +1
21:03 chromatic We already deprecated a couple of subsystems: JIT, JITted call frames.
21:03 particle1 https://svn.parrot.org/parrot/trunk/docs/stability.pod
21:03 allison kid51: yes, that is an important goal for the next year
21:03 japhb Anything we're looking at changing in the next 6-12 months should probably be deprecated now.
21:04 chromatic I don't want to get these two threads mixed up; can we table kid51's suggestion temporarily?  It's a very good one.
21:04 kid51 Agreed
21:04 chromatic Is the list of milestones/tasks/whatever we plan to come up with later in this meeting sufficient to start marking deprecation possibilities?
21:05 particle1 note: we're 35mins in to our meeting.
21:05 allison chromatic: yes
21:06 chromatic Show of hands, say "yes" or decline: are there other ideas to address our negatives in the past year?
21:06 bacek chromatic, + explicit marking API supported by deprecation policy with PARROT_API decorator
21:07 chromatic We have (obviously) addressing deprecation and support and concentrating on Rakudo *.  Anything else?
21:07 allison chromatic: sounds like we've covered the space adequately
21:07 particle1 get better at asking for money
21:07 particle1 create tutorial to introduce hll devs
21:07 particle1 that's it
21:07 chromatic pmichaud is working on an NQP book.
21:08 bacek "marketing" of parrot become more and more critical
21:08 chromatic Last call.
21:08 Coke joined #parrotsketch
21:08 * Coke ~~
21:08 chromatic Okay.  Quick procedural question: can we take a few minutes to discuss kid51's suggestion of focusing on Rakudo *?
21:08 chromatic Any objections?
21:08 japhb please, yes
21:08 darbelo +1
21:08 kid51 May I state my case?
21:08 mikehh +1
21:08 particle1 should we wait for pmichaud?
21:09 chromatic Let's give this ten minutes and see what happens.
21:09 chromatic kid51, go ahead.
21:09 kid51 2010 marks the 10th anniversary of Perl 6.  If nothing viable emerges next year, a lot of people will say screw it.
21:09 kid51 And Rakudo* is the biggest viable thing on the horizon.
21:10 kid51 So I think it's really important that its launch be successful and be perceived as such.
21:10 kid51 We can't affect how fast Larry works
21:10 kid51 But we can affect how well Patrick, Jonathan, etc. work.
21:11 kid51 So I think what we do over next four months should always be measured against the criterion of successful Rakudo* debut.
21:11 kid51 That's my message.
21:11 chromatic Well put.
21:11 mikehh I agree wholeheartedly
21:11 kid51 Successful debut of rakudo* will lead to interest from other HLLs.
21:11 chromatic Can we make that our goal for the April release?
21:12 kid51 Perhaps Tcl could set a similar launch.
21:12 particle1 i don't think anyone's put a hard deadline on 10 years.  when something usable is made available, people will use it. rakudo * will be marketed as 'perl 6 usable today'.  HOW usable depends partially on us.
21:12 chromatic (I assume that we move to a three-month cycle for supported releases, which makes the April release a supported release.)
21:12 bacek chromatic, I think our goal for April release should be "fastest parrot ever".
21:12 particle1 larry is working fast enough for perl 6 devs today.
21:12 bacek which implies at least GC refactoring.
21:13 chromatic I think that's a reasonable concrete task.
21:13 Coke kid51: the partcl project project pretty much has zero expectations at the moment.
21:13 japhb 1) Agree wholeheartedly with kid51. 2) As to particle's comment -- no one deadlined 10 years, but it's a big (though sometimes subconcious) rule of thumb that people use to detect Xanadu and Duke Nukem Forever.  We don't want to do that to our top HLL.
21:13 kid51 japhb:  Yes that'
21:13 kid51 that'st the psychology people will have
21:14 particle1 chromatic: i think successful debut of rakudo * should be our goal for every release up to april
21:14 chromatic I think Rakudo could make a release with Parrot 2.0 and still hit its deadline, but that's no reason for us to do anything other than give it top priority.
21:14 Coke (in terms of people wanting to use it; I'd love to have a *-like release to coincide with rakudo's april release, but we'd need more contributors for that to e even a remote possibility, especially given the current from-the-ground-up rewrite.)
21:15 japhb chromatic: ISTR that there's some stuff that will not be ready for 2.0 that Rakudo * will really want, so April release is probably something pmichaud will want
21:15 japhb (No I don't remember details ATM)
21:15 chromatic I've read a lot of agreement.  Are there concerns or alternatives?
21:16 bacek We shouldn't abandon support for other HLLs.
21:16 allison seems reasonable
21:16 bacek E.g. Lua
21:16 kid51 While 2.3 will be a supported release, I think we should aim to get pmichaud most of what he needs by 2.2
21:16 Coke bacek: I don't think anyone is suggesting that.
21:16 kid51 Allow a month for things to settle.
21:16 allison bacek: of course, that's not even considered
21:16 bacek of course it's not considered.
21:17 japhb kid51: agreed
21:17 chromatic We're talking about the driving vision for 2.0 - 2.3.
21:17 bacek But it can happen accidentally.
21:17 kid51 My hope is that a successful debut of rakudo* will inspire more HLL devs from those languages
21:17 allison bacek: good point, and yes, when we say HLL needs are a focus it does include all HLLs
21:18 particle1 going back a bit, we still don't do a good job of watching hll test reports.
21:18 particle1 we still need a workable language smoke solution.
21:18 chromatic We also need to improve our ability to extract tests from HLLs to Parrot.
21:18 japhb Now that Plumage can smoke, someone (fperrad?) suggested using it as the core of an all-HLL smoke system
21:18 bacek particle1, I've added it as line 22 in spreedsheet
21:18 chromatic We're at the ten minute mark.  Can we agree on the HLL (and Rakudo in specific) concentration?
21:19 japhb +1
21:19 moritz joined #parrotsketch
21:19 darbelo +Inf
21:19 kid51 +1
21:19 Coke particle1: I think it is reasonable to expect the HLL authors to complain when things break; core dev then needs to help with getting a test for that into core.
21:19 allison +1
21:19 Coke chromatic: +1
21:19 bacek Yay! Rakudo ambassador arrived :)
21:19 bacek chromatic, +1
21:19 moritz not really, just observer
21:20 chromatic Hearing no objections, let's talk about the implications for a few moments.
21:20 japhb Coke: I agree, but note that when we have tried in the past that has not worked out all that well, IIRC
21:20 chromatic I think this means that we need to evaluate short-term milestones in terms of what they mean for HLL development.
21:20 chromatic For example, as much as I'd like to svn rm compilers/imcc/*, I don't think that's the best place for me to concentrate to help Rakudo *.
21:21 chromatic Likewise, we'll have to be careful about how much Lorito groundwork we lay.
21:22 allison yes, that's a good perspective on roadmap goals
21:22 kid51 I think that in next 4 months we have to encourage our strongest devs to focus on that which will meet the rakudo goal ...
21:22 bacek chromatic, 1. ops2c in NQP; 2. Emitting PBC from PIR (done); 3. Lorito ops "spec"
21:22 kid51 ... but that doesn't prevent other (newer?) devs from workking in branches on longer-term stuff.
21:23 chromatic Sure, there's a roadmap for Lorito, but if there are HLL bugs that need addressed, we should focus on those.
21:24 particle1 rakudo wants speed
21:24 particle1 without faster pcc, rakudo isn't 'usable' as it's too slow
21:25 chromatic Let's move on to concrete short-term goals.
21:25 particle1 the same could be said about gc.  as-is, it makes rakudo less usable.
21:25 chromatic With our vision in mind, let's brainstorm some goals.
21:25 particle1 can faster pcc and better gcc be made 3-mo goals?
21:25 bacek particle1, +1
21:26 chromatic "Reduce PCC overhead"
21:26 chromatic "Create fewer garbage GCables in PCC"
21:26 chromatic "Reduce GC cost with better algorithm"
21:26 bacek but "better gcc" is hard target. Probably "better gc" is simpler
21:27 kid51 bacek: u beat me to it!
21:27 particle1 heh, better gc, of course. beer++ fingers--
21:27 chromatic There's beer?
21:27 particle1 yeah, check the fridge. i've got plenty.
21:27 bacek chromatic, no... There is $dayjob coming.
21:27 chromatic Other short-term priorities?
21:27 chromatic "Fix line numbers in annotations"
21:28 chromatic "Reduce likelihood of inferior runloops"
21:28 particle1 what about making more of pbc available in pasm?
21:28 chromatic I'll put it in the list, but I don't know what it'll help.
21:28 allison quite a few in the spreadsheet, which need to be reshuffled in light of new goal
21:28 allison (or, reprioritized goal)
21:29 chromatic "Make freeze/thaw work reliably"
21:29 japhb particle1: you mean the old goal of making pbc <-> pasm round trip?
21:30 bacek particle1, (pbc in pasm) it's done. We are able to generate PBC from PIR. And read it back
21:30 japhb Plumage needs to take over from proto by Rakudo* time frame, I think.  Some of that is work on our side, some on theirs
21:31 chromatic Noted, japhb.
21:31 kid51 proto?
21:31 chromatic A Perl 6 installation system.
21:31 japhb kid51, Perl 6 module install too.  Meant to be a throw away, but has not yet been thrown away.
21:31 particle1 pir is not pasm.  we need pbc <-> pasm round trip, and documented.
21:31 japhb er tool
21:31 particle1 unless we drop pasm, which i don't think will happen.
21:31 Coke particle1: I hesitate to put more work into pasm.
21:32 japhb Coke, particle1: at one point we had discussed making pasm literally "the textual format of pbc"
21:32 particle1 for debugging, we need a human-readable version of bytecode.  pasm is supposed to be just that.
21:32 japhb right
21:32 allison japhb: yes, that's what it should be
21:32 particle1 currently, you can't express all pbc constructs in pasm.
21:33 allison japhb: which does mean some working making pbc<->pasm work
21:33 allison but, not much work
21:33 particle1 agreed, not much work.
21:33 japhb good to hear, that
21:33 allison I'll note that on the PASM milestone
21:33 chromatic I'm noting that as "Fix PBC <-> PASM roundtrip"
21:33 chromatic Any other short-term goals?
21:34 chromatic "PAST optimization tools" might be nice, but....
21:34 japhb Is Rakudo* supposed to have strong NCI support?
21:34 japhb Because that might bump the NCI fixes goal
21:34 allison chromatic: they're already on the list
21:35 allison chromatic: currently for 2.6, but seems like they could be pushed later
21:35 allison (provided we get enough speed gains out of GC and PCC work)
21:36 chromatic moritz, any thoughts on NCI?
21:36 japhb Also, do we know what is blocking DBI2?  Just Tim Bunce's time?  Because my gut feeling is when Rakudo* comes out, people are going to want to do DB work with it, but I don't know how the Perl 6 guys are dealing with that now.
21:36 moritz chromatic: NCI usable from Rakudo would be great
21:36 chromatic Is it a goal for Rakudo *?
21:37 moritz and would help DBD2 a lot
21:37 moritz chromatic: let me take a loook at the ROADMAP, but I think not
21:37 mikehh joined #parrotsketch
21:37 chromatic Anything else?
21:37 moritz chromatic: it's a low priority task (ie not mandatory)
21:38 chromatic Good to know, thanks.
21:38 davidfetter joined #parrotsketch
21:38 chromatic Let's move on.
21:39 * bacek moving to $dayjob
21:39 chromatic What risks do we face to our short-term goals?
21:39 allison time
21:39 chromatic Attention span.
21:40 kid51 I think that for some of our devs, it's more fun to play with their own HLL projects than to tackle difficult Parrot-internal issues.
21:40 Coke any risks /particular/ to our plan? time and attention are always a risk. =-)
21:40 japhb Plumage needs a much stronger test suite, and I'm flat out using all my time just to write the main code.  Without some help there, Plumage risks lacking quality.
21:40 allison Rakudo could have a sudden slew of needs towards the release that overload our developer capacity
21:40 chromatic The GC changes are risky code-wise; it's not easy to replace the GC in a running system.
21:41 allison it seems unlikely, given their reasonable plan, but it is a possibility
21:41 chromatic Freeze/thaw is some of the worst, oldest code in Parrot and no one knows it very well.
21:42 particle1 we face lack of focus on our goals
21:42 darbelo chromatic: There's a deprecation in for that after 2.0 so we can rewrite it.
21:43 chromatic We still tend to break projects into large chunks, but they remain large.
21:43 allison and, we have a large number of tasks that could potentially fall under the general umbrella of "support HLLs"
21:43 japhb particle: Because of "fire of the week" problems stealing developer cycles, or because developer goals are changing too often?
21:43 particle1 japhb: do you have a ticket system for plumage, and can you write some LHF (low-hanging fruit) tickets for testing?
21:43 particle1 chromatic: our gc system is supposedly pluggable
21:43 japhb particle1: IIRC it was agreed some time ago that Plumage would use Parrot Trac for now.  And yes, I can write some tickets if that will help.
21:44 particle1 so the risk is mitigated somewhat by not making the new gc subsystem the default until proven stable
21:44 allison particle: it is, but we're talking about changes to the infrastructure as well as adding a specific module
21:44 chromatic Read barriers... mark() and destroy()... there's lots of that code throughout the system.
21:44 allison particle: that is, we need to make it more pluggable
21:45 particle1 japhb: tickets will help.  a small investment in lowering the learning curve, and a small investment in marketing will help more.
21:45 chromatic Other risks?
21:46 japhb particle1: I already spent much of last week writing hacking docs for Plumage.  I would be *very* appreciative of advice on other ways to improve them, or any other ideas you might have.
21:46 particle1 ah, gc api changes will indeed be problematic.
21:46 japhb And I've added Tickets to my personal todo
21:47 chromatic Last chance to address other risks, and then we move on to the next question.
21:47 particle1 japhb: glad to hear it.  have i missed planet parrot posts on plumage? those would help.
21:47 japhb particle1: let's discuss that in #parrot
21:47 chromatic Next question.
21:48 chromatic How can we be more effective in the short term?
21:48 particle1 is there anything that can be gotten out of the way? what are the blockers to the current lack of  effectiveness?
21:48 allison set priorities that meet our goals
21:49 mikehh joined #parrotsketch
21:49 allison focus on those priorities
21:49 chromatic My motivation goes away when I face a really big problem where I can't swoop in, hack for an hour, and unblock someone else to do the same.
21:51 darbelo Having small tasks that can be acomplished in 1-2 hours of hacking is great for not blocking on a single person.
21:52 chromatic I've tried to break down tasks that way, but it hasn't seemed effective.  Am I too picky?
21:52 moritz what's stopping us from breaking down more tasks into smaller chunks?
21:52 allison it takes time to break down the tasks
21:52 chromatic We effectively have to do it anyway to perform them, though.
21:52 allison that is, someone has to do the work of making the tasks before others start consuming the tasks
21:53 mikehh joined #parrotsketch
21:54 Whiteknight joined #parrotsketch
21:54 darbelo chromatic: maybe it's a visibility thing.
21:54 chromatic Maybe.  I try to name names when I mention these tasks though.
21:55 kid51 Speaking for $self:  Since there's much about Parrot that is outside my (current) skill-set, I tend to be very focused on TT, i.e., I ask, "Can I do anything on this particular ticket?"
21:55 japhb I think we have "overwhelming ticket syndrome" too.  So many tickets open, it's daunting to go find a task, so then people fall back to bugging each other on #parrot.
21:55 chromatic That's for sure.
21:55 kid51 So, things that are outside of, or have not yet entered TT, are impossible for me to work on.
21:56 kid51 ... whereas if it's in TT, there's a (small) chance I *can* work on it.
21:56 kid51 And there are probably other people in same boat
21:56 chromatic How do we address that?  Can we?
21:57 darbelo We also have people on the other boat. Rarely look at Trac, but will work on stuff if bugged on IRC.
21:57 Coke Just encourage people to use trac. Offer to help enter tickets if that's what it takes.
21:57 Coke well, even if you can't work on a ticket, you can still bug someone else to on IRC.
21:57 japhb A "small tasks" tag/category/query/whatever that people just looking to be a 1-hour hero can search on?  If it gets used, it will also encourage people to split things into smaller tasks in order to get attention on their issues.
21:58 allison I like Coke's idea of urging the same "ticket reduction" work on trac that we did on RT
21:58 chromatic Is the number of Trac tickets blocking us somehow?
21:59 * kid51 notes that we now have the same average number of TTs as we did on RT: 600-700
21:59 kid51 So I don't think the number of tickets is the blocker per se
21:59 japhb Right, our ticket reduction in RT seemed to largely go to transferring to TT
21:59 allison I suspect tasks are getting lost in the stack
21:59 particle1 the lack of proper classification makes things easy to lose or hard to track
21:59 Coke I don't think it's a blocker, no; but it's certainly the case that having more people do review of tickets (even if they cannot close them for some reason) is a good thing.
21:59 particle1 s/track/find/
21:59 japhb allison, yeah, that's part of what I was trying to say
21:59 allison something like "review one ticket a day" would go a long way
22:00 chromatic Every committer closing one ticket a week would go a very long way.
22:00 darbelo We should probably do more ticket assigning, and then press people to clear their TT debt.
22:00 Whiteknight that might make a nice addition to #ps format: what ticket did I look at this week?
22:00 Coke reviewing tt's is a good intro task, too.
22:00 Whiteknight if it's routine, we're more likely to do it
22:00 allison Whiteknight: I like that idea
22:01 particle1 let's first concentrate on defining which tickets are high priority for or before 2.3
22:01 particle1 then address those tickets first
22:01 japhb Whiteknight, +1
22:01 chromatic I'll add that as a short-term goal.
22:02 chromatic How about also as a short-term goal "Write a ticket guidelines document for novices"?
22:02 chromatic We may have something like that; I didn't check just now.
22:03 mikehh I think we also need to triage our tickets
22:03 darbelo (Write documents for novices)++
22:04 chromatic Other efficacy improvements in the short term?
22:04 particle1 some hll devs track parrot tickets important to them.  i know pmichaud does.  ask them what's important.
22:04 Coke particle1: there is already a list/report for that.l
22:04 Coke use that.
22:04 particle1 coke++
22:05 japhb It's about halfway through meeting (well, the original 3 hour plan).  Anyone mind if we take a short leg-stretch?
22:05 chromatic Maybe we need to make the Wiki front page more useful.
22:05 chromatic 5 minute break, any objections?
22:05 Coke http://trac.parrot.org/parrot/report/16 (tickets that hll devs care about)
22:06 particle1 can we create redirects for trac to give those reports names?
22:06 particle1 break++
22:09 cotto Are conclusions from this meeting (if any) being documented on the wiki?
22:09 Whiteknight joined #parrotsketch
22:11 chromatic I've taken notes on concrete suggestions, but I haven't put them on the wiki yet.
22:13 cotto sure.  there's plenty of time left in the meeting
22:13 chromatic Unbreak time?
22:13 cotto (and plenty of log to read through)
22:14 pmichaud joined #parrotsketch
22:14 darbelo Do we wait for pmichaud
22:14 pmichaud here finally, sorry I was late
22:14 chromatic We're still talking about short-term efficacy and process improvements.  Any other thoughts?
22:14 darbelo Ah, hes here.
22:14 kid51 Ah! a customer has just walked thru the door!
22:14 japhb mmm, circulation.  It's a wonderful thing.
22:14 allison chromatic: I'd say the next step is to move into specifics
22:16 chromatic Okay.
22:16 chromatic Which specifics are those?
22:16 particle1 roadmap specifics?
22:17 mikehh joined #parrotsketch
22:17 allison yes
22:17 * mikehh my internet connection is really giving me a hard time
22:18 chromatic Want to lead this one, allison?
22:18 allison okay
22:18 allison we've got a long list of possible tasks
22:18 allison some have times assigned some don't
22:19 allison the ones that are attached to a milestone need to be reviewed in light of our short-term priority of helping Rakudo * to be a success
22:19 allison the ones that aren't attached to a release date need to be, even if we change it later
22:20 allison and, its possible that some tasks we put on the roadmap at the last PDS are no longer a roadmap-level priority
22:21 allison sticky notes were nice for this, because they let people dynamically interact
22:21 Whiteknight "no longer a roadmap-level priority" +1
22:21 allison but, we can go through the spreadsheet, tweak the release numbers and sort it to get our approximate timeline
22:21 pmichaud okay, done reading backscroll.  any specific questions I could answer at this point ?
22:22 particle1 can we give everybody a column to vote for a roadmap version per task? how shall we do this?
22:22 allison pmichaud: what are the highest priority needs from Parrot for Rakudo *, so we can put them on the roadmap
22:22 particle1 or take each item here for votes?
22:22 allison particle: let's just decide in channel
22:22 pmichaud Whiteknight sent me a message about that earlier in the week, I don't know what happened to my reply though
22:23 allison starting at the top:
22:23 allison Move to 3 month release cycle starting at 2.0
22:23 Whiteknight pmichaud: that mail wasn' on list
22:23 allison yay, nay?
22:23 chromatic +1
22:23 pmichaud Whiteknight: right, I know.  But I didn't see any response to it either :-)
22:23 pmichaud +1 on 3-month release cycle
22:24 Whiteknight oh, no response. Just accepted and digested the info
22:24 darbelo +1
22:24 pmichaud let me see if I can get the text of the sent-mail and post it somewhere for others to see
22:24 allison any opposed or any discussion?
22:24 Coke +1 on 3-month.
22:25 japhb +1 3 month
22:25 Whiteknight +1 (3-month cyle)
22:25 Whiteknight cycle*
22:25 pmichaud http://nopaste.snit.ch/19067   (partial response to whiteknight++'s message)
22:25 mikehh +1 on 3 month cycle
22:25 GeJ joined #parrotsketch
22:25 allison okay, we'll consider that motion carried (objections can be raised later)
22:26 allison we'll change that entry to a specific task of updating the support policy and release schedule documentation
22:26 * particle1 thought of a short-term effectiveness item (that has been brought up before): more frequent roadmap reviews
22:26 chromatic We discussed doing that the #ps of a release day.
22:27 pmichaud coke++ proposed that we do roadmap review before each supported release
22:27 pmichaud (which makes sense to me)
22:27 pmichaud oh, sorry,  roadmap review != roadmap planning
22:27 pmichaud coke++ proposed that we do roadmap planning before each supported release (but that was on the 6-month cadence)
22:28 allison good idea, added to spreadsheet
22:28 Coke should work the same on 3-month, yah.
22:28 allison (not sure where that will go in the docs yet, but should go somewhere)
22:28 allison it's not at the top, but related: review deprecation policy
22:29 allison are there any specific actions we want to take there at this meeting?
22:29 japhb I've heard mostly positive response to "opt-in".  Any objections to it?
22:29 japhb (Other than work to do the review of current state)
22:30 pmichaud I have mixed feeling about opt-in.
22:30 particle1 haven't seen objections, but a reply to the mailing list post should be made
22:30 allison I don't like the term "opt-in", but the general idea of clearly defining what is and isn't supported I like
22:30 Whiteknight pmichaud: opt-in should relieve your pains in waiting for deprecation cycles
22:31 Whiteknight so we don't stabilize something till it's been evaluated as good enough to stabilize
22:31 pmichaud Whiteknight:  yes, but at the potential cost of increasing my pains for unexpected changes
22:31 allison Whiteknight: I'm not sure it does
22:31 allison pmichaud: yes, exactly
22:31 Coke pmichaud: we need to have a decision as to what is supported. if you find something is not on the list that should be, we can resolve that.
22:31 particle1 i think that definition can be done by specifying stability levels per-subsystem, and specifying which levels of stability are on the deprecation policy
22:32 Coke particle1: something more specific than "yes or no"?
22:32 pmichaud Coke: sure, but I'm a little worried it might be hard for me to enumerate what needs support
22:32 Whiteknight currently we support things that *are not* good enough to make guarantees about
22:32 Whiteknight and that hurts everybody
22:32 pmichaud sometimes we rely on a feature without even knowing that we're relying on it.  (yes, that's a bit of a dark code argument)
22:32 Coke perhaps we'd be better off enumerating the things that are explicitly not good enough.
22:32 japhb Whiteknight, +1
22:32 allison pmichaud: yes, but it's only a 3 month dark code argument
22:33 pmichaud anyway, my biggest problem with the deprecation cycle has been its length.... what allison said
22:33 Coke I think switching to 3 months is going to alleviate most of the pain there.
22:33 allison pmichaud: which is substantially different than dark code into the infinite past
22:33 pmichaud to me, moving from a 6-month cycle to a 3-month cycle _greatly_ reduces the pain involved.
22:33 particle1 coke: http://svn.parrot.org/parrot/trunk/docs/stability.pod defines the stability levels
22:33 Coke I'd be happy to give the 3 month cycle a shot and see what falls out.
22:33 chromatic +1 to listing systems or features that may change.
22:33 pmichaud chromatic: I think we already do that, though
22:33 chromatic That's much more predictable in three-month increments.
22:33 japhb Do we need to "turn off deprecation cycle" until the Rakudo* is out?  In order to completely unblock this critical cycle?
22:34 pmichaud what whiteknight is proposing is that everything is allowed to change until it's declared "stable"
22:34 pmichaud japhb: I don't think that's necessary
22:34 allison well, we also do that now, we call those features "experimental"
22:34 japhb pmichaud, OK, just checking
22:34 Coke we have a month to figure out if we need to add anything to the experimental list for the 2.0 release.
22:34 particle1 turning off deprecation can have unexpected consequences, i caution against it.
22:35 allison it's sounds to me like the specific action here is a) change to 3 months, b) do a review and mark certain subsystems as experimental before 2.0
22:35 japhb particle1: sure. fair enough, just thought it was worth asking in case there was a random resounding "yes"
22:35 pmichaud particle1: it's not "turning off deprecation".  right now we have a policy that says "everything is stable unless declared otherwise".  Whiteknight++'s proposal is "everything is subject to change unless declared stable"
22:35 pmichaud I agree with "let's see how the 3-month cycle works out"
22:35 bacek_at_work joined #parrotsketch
22:35 bacek_at_work ~~
22:36 allison and, c) plan to review deprecation policy again at the next roadmap planning session before 2.3
22:36 pmichaud +1
22:36 pmichaud I have another brief comment here
22:36 allison sound like a reasonable resolution of the question for now?
22:36 allison pmichaud: go ahead
22:36 pmichaud first, I really appreciate the many comments from the earlier conversation about parrot supporting Rakudo*.  I agree it's important, and I'm glad to see others recognize and support that.
22:37 pmichaud If we move to the 3-month dep cycle, I think taht resolves a lot of issues.  I'm also assuming that if Rakudo ended up with a heroic need to break/fix something before April (and I don't expect such to be the case), that we'd find a way to do it.  I don't think we need major policy changes to plan for that (hopefully unlikely) outcome.
22:38 particle1 allison: +1
22:38 pmichaud (end of comment)
22:39 allison pmichaud: in the unlikely event of an extreme bending of the deprecation policy needed for Rakudo *, we can always do it with parallel system
22:39 pmichaud Rakudo*'s plan has always been that we would have the bulk of our critical needs done in early 2010.  Ideally around the January or February release.
22:39 chromatic Besides, if we need to release a 2.0.1 with additional deprecation notices, we can.
22:39 allison (keep the old and add the new, with a way to select between the two)
22:39 pmichaud So far we're pretty much on-track with that plan; perhaps a week or two behind, but we have a lot of buffer in the schedule.
22:40 allison chromatic: not so sure about that one, but it's unlikely we'll even get to a point where we need to consider it
22:41 pmichaud anyway, if there's a huge problem, we're likely to know about it in January or February, and not March or April.
22:41 pmichaud (and it's easy for people to know if this is the case -- we should have all of our "level 1" features in place by the January Rakudo release.
22:41 particle1 5 weeks
22:42 pmichaud yes, 5 weeks.  Out of the priority 1 items we identified, I think about 2/3rds are already complete.
22:42 allison Let's quickly run through the remaining ~50 items on the spreadsheet. Call it a triage.
22:42 pmichaud wfm
22:42 allison The focus here is first on the short-term priority of Rakudo *
22:43 allison and secondarily on our longer-term goals
22:43 allison "Where do we want Parrot to be in 2-3 years?"
22:43 allison line 4: lvalues
22:43 allison is this a 2.3 level priority?
22:43 allison 2.6?
22:43 pmichaud not for Rakudo.
22:44 pmichaud might be for other HLLs that want to come to the parrot party, though.
22:44 chromatic 2.6; we need to address it sooner than later.
22:44 particle1 2.6
22:44 allison it's about efficiency, which we've put as a high priority
22:44 allison I'm good with 2.6
22:45 allison concurrency?
22:45 pmichaud not a Rakudo* priority
22:45 allison this is a revamp of the current threads implementation
22:45 allison people generally happy with the 3.0 posted in the spreadsheet?
22:45 particle1 3.0
22:45 pmichaud 3.0 wfm
22:46 allison GC?
22:46 allison 2.3 for something is a good idea
22:46 pmichaud very important to Rakudo as it pertains to performance/speed
22:46 allison what do we plan to accomplish for 2.3?
22:46 chromatic We should be able to implement at least the sweep-free GC.
22:46 pmichaud basically, Rakudo*'s #1 need from parrot at this point is anything to improve performance/speed, especially for hll compilation and performance
22:47 allison okay, so we'll call 2.3 a pass for speed
22:47 pmichaud also, based on past velocity, I suspect that each major release can have at most 1 or maybe 2 "major targets".
22:47 allison which will likely involve a new GC module, but may not cover all the refactors we want to do
22:48 allison pmichaud: yes, agreed
22:48 particle1 on the spreadsheet, is "suggested release" supported releases only? for now?
22:48 allison particle: yes
22:49 allison we'll break them down into the monthly releases later
22:49 allison what's RTEMS port?
22:49 particle1 getting parrot to compile/run on the real time os RTEMS
22:49 darbelo http://www.rtems.com/
22:50 particle1 RTEMS has some good tools for developers/debuggers/profilers
22:50 allison a port
22:50 particle1 but i see it as either off-cycle, or 3.0 priority
22:50 chromatic It doesn't seem like a milestone task.
22:50 darbelo off-cycle sounds good to me
22:51 pmichaud if we accept the "1 or 2 major targets" premise, that means there are really only eight things we can do between now and 3.0
22:51 allison not really a roadmap item, but a good one to add to our list of os's to support
22:51 particle1 yes, it's a port. if we have a milestone goal for portability by *supported release M.N*, then it's roadmap
22:51 japhb off-cycle, yes
22:51 Coke I don't think we can make a port a milestone goal. it's too dependant on the porter.
22:51 allison marked as not for roadmap
22:51 pmichaud allison: +1
22:52 allison strings?
22:52 mikehh joined #parrotsketch
22:52 allison is this the NFG implementation?
22:52 pmichaud possibly
22:52 Coke yes.
22:52 darbelo nfg?
22:52 particle1 please i hope so.
22:52 particle1 darbelo: see the strings pdd
22:52 pmichaud the primary issue from a Rakudo perspective is the cost of variable-width encoded strings
22:53 allison darbelo: Grapheme Normalization Form
22:53 pmichaud and that without ICU, there's not a way to do some unicode-related items
22:53 japhb Why aren't we requiring ICU yet?
22:53 allison japhb: because that would limit the platforms we can support
22:53 chromatic Variable-width encoding hurts.
22:54 japhb poor portability, eh?  yucko
22:54 allison NFG is a way to get around variable width encodings
22:54 allison is it the best way?
22:54 Coke allison: we can't suppor the platforms that it would cost us anyway.
22:54 allison is it the easiest way?
22:54 particle1 it's the way perl 6 expects.
22:54 japhb Coke, I was wondering about that ...
22:54 chromatic Risk: few people understand NFG and the existing prototype may have bitrotted.
22:55 allison the existing prototype was written in Perl anyway
22:55 allison not a "working branch"
22:55 chromatic I meant design more than implementation, but point taken.
22:55 allison yes, NFG is complex, so it's a big task
22:56 Coke so we need someone to break it up into chunks.
22:56 allison but, if it's the only way, then we bite the bullet
22:56 pmichaud as things stand now, we can do a lot of Perl 6 without NFG, I think.  I put strings onto the spreadsheet simply because it's an ongoing issue that ought to be addressed, and I was thinking more of "unicode semantics" and "fixed-width encoding" more than "we have to have NFG".
22:56 allison (similar to GC)
22:56 Coke so, let's keep strings on the list, but it can stay way out there.
22:56 allison pmichaud: what do you have in mind?
22:56 pmichaud i.e., if Parrot decides that NFG is the best/easiest way to address unicode and fixed-width encoding, that's fine.  But NFG wasn't my driving factor.
22:56 allison require ICU?
22:57 allison and, what for the fixed-width encoding?
22:57 particle1 can we please put the detail on strings on that roadmap item?
22:57 chromatic There are other string concerns as well, such as removing in-place modification.
22:57 particle1 "strings: fixed-width encoding and unicode semantics"
22:57 particle1 unclear roadmap items bit us last year
22:57 allison (requiring ICU has it's disadvantages, but it at least involves very little developer effort)
22:57 pmichaud I don't have a specific solution in mind for resolving the strings issues.  Requiring ICU seems like the quickest short-term solution, though.
22:58 pmichaud and making sure that we can do something fast-ish with unicode strings
22:58 mikehh what platforms is ICU not available on
22:58 japhb We can always un-require it later, it's not like its a permanent decision
22:58 allison requiring ICU is going to bite us on later goals when we get to "nanoparrot for embedded systems"
22:58 darbelo There's a comment about stringnull and "no mutable strings" by chromatic there.
22:58 particle1 icu requires c++ compiler
22:59 Coke allison: and are we going to support unicode on nanoparrot for embedded systems??
22:59 darbelo unicode on embeded systems? No way.
22:59 allison Coke: no, but we're not saying "require ICU if you want unicode support"
22:59 allison Coke: that's what we do now
22:59 allison Coke: the question here is "do we require it in all cases?
23:00 allison these are design questions and won't be resolved here
23:00 pmichaud there's also the possibility that Rakudo could require ICU even if Parrot doesn't (more)
23:00 allison the question here is when do we need to resolve them?
23:00 pmichaud and perhaps Rakudo could handle the "ICU is present, let's use faster encodings" decision making, rather than Parrot doing it
23:01 pmichaud fast unicode string processing would seem to me to be something we want to have before 3.0
23:01 pmichaud it's not a 2.3 priority to me
23:01 Tene re F2F meetings, I have zero budget for travel, but I'm willing to go anywhere I'm asked if travel is funded.
23:01 particle1 sounds like we have multiple string-related roadmap items
23:02 particle1 some related to rakudo *, some unrelated
23:02 chromatic Perhaps we should table the ICU discussion for now.
23:02 pmichaud fwiw, none of the strings items are related to Rakudo*
23:02 allison Tene: aye, most of us are in that boat, which is why this isn't F2F
23:02 pmichaud (except to the extent that improving strings might improve speed.)
23:02 chromatic "No mutable strings" may improve performance.
23:02 allison so, we're putting the ICU and fixed-width encodings down for 3.0
23:03 allison is there a motion for the mutable strings question before 3.0?
23:03 particle1 right, refactoring for performance vs improvments/extensions to current system
23:03 allison and if so, when?
23:03 pmichaud I vote whatever chromatic votes :)
23:04 NotFound joined #parrotsketch
23:04 chromatic We need to discuss it seriously as a design decision, because it has API change implications we need to document in 2.0.
23:05 pmichaud I agree with others that there are multiple string-related roadmap items.  I wouldn't want to make this a pattern for subsequent topics in today's meeting, but my goal for 2.0 would be to map out a plan for strings between 2.0 and 3.0
23:05 NotFound hi
23:05 particle1 we have many more roadmap items to discuss, and 25 minutes
23:05 allison chromatic: so 2.3?
23:05 chromatic Love to; can we discuss in the next #ps?
23:05 Coke +1
23:05 particle1 ++
23:05 allison yes
23:05 allison okay, what's native type lexicals?
23:05 pmichaud currently Parrot lexicals can only refer to PMCs
23:05 chromatic Storing non-PMCs in LexPads.
23:06 pmichaud that has huge implications on being able to optimize things in compilers and subroutines
23:06 particle1 need.
23:06 allison so, a typed data structure like we use for CallSignature now
23:06 allison time frame?
23:06 pmichaud not 2.3
23:07 allison 2.3, 2.6, 2.9, 3.0?
23:07 allison beyond?
23:07 japhb 2.3 - 2.9 I would think ... it will be useful for NCI performance.
23:07 japhb So given pmichaud, 2.6 or 2.9
23:07 Coke default to later.
23:07 allison let's say 2.9
23:07 allison okay
23:07 pmichaud wfm
23:07 Coke (don't push anything sooner than it has to be.)
23:08 allison constant data structures in pir/pbc?
23:08 allison what's the task?
23:08 japhb Coke, +1 on that
23:08 moritz left #parrotsketch
23:08 particle1 ability to reuse exception handlers, for one
23:08 pmichaud that refers to my comment in my Nov 4 letter, that it's traditionally been very difficult to pre-compile data structures into pbcs
23:08 Whiteknight joined #parrotsketch
23:08 pmichaud i.e., if I have a large table of values, the best I can do at present is create that table at :load/:init time
23:08 japhb They have to be rebuilt in :init, yes?
23:09 japhb right
23:09 Coke ... I'm doing this in partcl.
23:09 pmichaud (chromatic++ has potentially improved this recently, I haven't had time to test/evaluate)
23:09 Coke (using the .const sub trickery, which chrom... what pmichaud said)
23:09 allison sounds like a good task
23:09 particle1 is this rakudo *-important?
23:09 pmichaud particle1: it's not a critical need, no.
23:09 chromatic Huge improvements for startup time potential with this and improved freeze/thaw.
23:09 japhb But good for startup performance.
23:09 pmichaud right
23:10 allison good ticket, is it a roadmap task?
23:10 chromatic Potential runtime performance improvement as well.
23:10 chromatic 2.3.
23:10 chromatic It's a broad goal, but it's definitely an area where a few specific tasks can pay off.
23:10 pmichaud also, rakudo * is adopting a much lazier constant generation strategy, so instead of building our data structures at load time, we build and cache them on first use.
23:10 allison how complex is it? 2.3 is getting top-heavy
23:10 japhb 2.3 or 2.6.  I'm not sure startup time is as important as runtime, but certainly nice to have
23:10 pmichaud in the general case, it can be very complex.
23:10 pmichaud especially if the constants have to refer to other hll-specific PMCs or data structures
23:10 chromatic Fixing EH isn't too difficult; a couple of days, if it goes well.
23:11 pmichaud fixing eh is easy-ish, yes.
23:11 allison 2.6 then, let's save 2.3 for things that are critical for Rakudo *
23:11 japhb So easy sub-cases for 2.3, and general "it just works" in 2.6?
23:11 particle1 2.6: +1
23:11 allison better load_bytecode semantics?
23:11 pmichaud I have doubts we'd make a 2.6 target given other things taking place, but I"m okay with that.
23:12 allison 2.9 is okay too
23:12 pmichaud I think the pdd31 draft I put in place, plus a recent proposal for freeze/thaw improvements may address the issues with load_bytecode
23:13 allison when do you need it?
23:13 pmichaud (thinking)
23:13 pmichaud "need" is a hard question.  we can work around it with various out-of-band communications mechanisms... that's what we do now
23:14 pmichaud I'd say it perhaps no longer needs to be a roadmap item, given we have workarounds.  if it becomes ripe for a solution, we just implement it.
23:14 allison ok
23:14 allison the methods in the namespace bug, timing?
23:15 pmichaud _lots_ of HLL folks get bit by this, as well as IMCC's choice to optimize function calls for same-named subs/methods in the namespace (instead of going through standard dispatch)
23:15 chromatic That one's harder than it looks.  We need to refactor how NameSpace works.
23:16 allison chromatic: yah, I just added that as a comment in the cell
23:16 chromatic If allison can remove some of the awful from the NameSpace PMC, we can probably fix it soonish.  We ought to fix it by 2.0 for certain.
23:16 allison okay, will put it down for 2.0
23:16 Whiteknight what needs removing? can only allison do it?
23:16 pmichaud at the moment I've been thinking that PAST may need to change its default function-call semantics to explicitly do "find_sub_not_null" and invocation instead of allowing IMCC to do it.
23:16 allison it is a bug, there's not doubt about that
23:17 allison Whiteknight: nah, anyone can do it, it's just nasty code
23:17 pmichaud we definitely would do better if methods don't show up in the namespace.
23:17 allison subroutine leave semantics/exit handlers?
23:17 allison timing?
23:17 allison (definitely a good feature to add)
23:18 chromatic Utility to Rakudo?
23:18 pmichaud high
23:18 allison needed for April?
23:18 pmichaud we can work around the lack of it, with performance cost
23:19 allison we're trying to avoid those performance costs
23:19 pmichaud but a lot of Perl 6 is built around the idea of being able to invoked ".leave" on a caller
23:19 allison would using properties work as a start?
23:19 pmichaud and being able to schedule tasks to run on scope exit
23:19 chromatic Or a bytecode-constant EH attached to a Sub?
23:19 allison or, the idea of storing them in the context?
23:19 allison or the Sub itself?
23:20 allison okay, let's put this down for 2.3, and discuss soon
23:20 pmichaud wfm
23:20 Whiteknight attaching const PMCs of all types to the sub they are defined in might be nice
23:20 allison exception handlers/inferior runloop?
23:20 allison what's needed and when is it needed?
23:20 pmichaud (btw, currently we're also exploring the possibility of using pushaction/pushmark/popmark for exit handlers.)
23:20 chromatic Lorito, for a real fix.  There may be a workaround.
23:21 Whiteknight Lorito should be ast-tracked
23:21 allison is it worth spending time on it, or should we spend the time on Lorito instead?
23:21 pmichaud in general, inferior runloop issues may bite us if there's not a good cleanup mechanism.  I'm specifically thinking of the cases where we might have exceptions occuring in a loop.
23:21 chromatic Depends on the invasiveness, efficacy, and usability of the workaround.
23:22 pmichaud i.e., if I loop over something 1000 times, and there are 1000 exceptions generating inferior runloops, we could end up with a problem :)
23:22 allison sounds like, not a roadmap item, but worth looking into?
23:22 chromatic +1
23:22 Whiteknight +1
23:23 pmichaud +1, with the caveat that it might end up being a black-eye on parrot if someone starts to use it for "real stuff"
23:23 allison pmichaud: yes, it will have to be dealt with
23:23 pmichaud right
23:23 allison Lorito?
23:23 chromatic Not 2.3.
23:23 allison is 2.9 reasonable, and soon enough?
23:23 chromatic I think it has to be *the* 3.0 task.
23:23 pmichaud chromatic: +1
23:23 allison with work going in beforehand
23:24 chromatic Definitely.
23:24 allison yes, that's sounds good
23:24 allison benchmarks?
23:24 pmichaud I'd be skeptical of placing lorito before 3.0.
23:24 allison more of an ongoing task
23:24 pmichaud (but we could have various lorito-related developments before then.)
23:24 allison yes, and it's important to remember that lorito isn't needed for Rakudo *
23:24 particle1 not roadmap
23:24 pmichaud I don't see benchmarks as being a roadmap task.
23:24 chromatic Agreed.
23:25 japhb allison, yes, but should discuss (in another #ps) more benchmarks that would help guide.  But no, not roadmap.  Just a task that needs attention.
23:25 allison marked as no roadmap
23:25 allison core libraries/plumage?
23:25 pmichaud benchmarks might be a dependency for other performance tasks, yes.
23:25 japhb Plumage needs to be a lot more there for 2.3
23:25 japhb I think it should have fully replaced proto for Rakudo use by then
23:26 pmichaud I highly doubt that Rakudo will end up with plumage as its module handler.
23:26 japhb And I need help writing tests.  Already discussed making TTs for that and so on.
23:26 japhb pmichaud, that's news to me
23:26 japhb (and not pleasant news)
23:26 pmichaud unless plumage expects to be the standard for Perl 6
23:26 particle1 address plumage later, then
23:27 allison okay, more discussion to happen there (later)
23:27 particle1 discuss offline, and modify roadmap at next review if necessary
23:27 japhb pmichaud, OK, we need to discuss in #parrot then
23:27 pmichaud let me rephrase what I said above
23:27 pmichaud I don't think there will be *one* module handler for Perl 6.  Or Rakudo.
23:27 allison plumage definitely will handle perl 6 modules, because it handles all languages
23:27 allison but, I suspect the Perl community will also have CPAN
23:27 allison in whatever form CPAN grows into
23:28 allison (that is, Plumage can pull from CPAN, CPAN6 or whatever)
23:28 japhb allison, yes
23:28 pmichaud that's fair enough.  But that definitely won't happen before April.  :)
23:29 pmichaud I'm willing to accept that plumage could be come a standard for module distribution.  But I suspect it might have to grow beyond Parrot.
23:29 japhb possibly
23:29 allison reasonable, since it is language agnostic
23:29 allison okay next (trying to zip through here)
23:29 allison multiple versions of Parrot libraries installed
23:29 pmichaud it's not just CPAN we're talking about, but also python modules, ruby gems, etc. etc.
23:30 allison is that "installed and loaded"? or just "installed"
23:30 allison pmichaud: yes, that's what we want
23:30 pmichaud Perl 6 will require "installed and loaded"
23:30 japhb allison, Perl 6 requires being able to ... pmichaud++
23:30 allison we have no answer to that at the moment, when do we need an answer by?
23:30 allison 2.3?
23:30 pmichaud no way :)
23:30 allison 2.9?
23:31 allison 3.0?
23:31 pmichaud from a Rakudo perspective, I don't plan for us to be doing anything like that before 2011, unless someone decides they need to focus a lot of effort into it
23:31 particle1 3.3
23:31 allison then let's not schedule it until you need it
23:31 allison 3.3 sounds good
23:31 pmichaud I'd prefer "unscheduled"
23:31 japhb I know it to be necessary, and will need to support it, but Rakudo will likely be the driving force
23:32 allison pmichaud: is it a roadmap task?
23:32 pmichaud we can put a target if we want, but Perl 5 has lived for a very long time without it such, so I suspect Rakudo can do the same.
23:32 allison or, just a general feature request?
23:32 pmichaud I wouldn't have it as a roadmap task, no.
23:32 pmichaud it's something we know we need eventually, but I think there's a lot of real-world use cases and experience with Rakudo that needs to develop before we can start making plans on it
23:32 allison okay, marked as no roadmap
23:32 allison Improved NCI/FFI
23:33 allison is this critical for Rakudo *?
23:33 pmichaud not critical for Rakudo *
23:33 allison then definitely not 2.3
23:33 pmichaud however, a lot of Perl 6 and other folks will be asking about it shortly thereafter :)
23:33 allison suggestions on timeframe?
23:33 japhb But I'd like to see that sooner rather than later.  2.6 would be really my preference
23:33 pmichaud because that's always been one of Parrot's supposed advantages
23:33 allison (definitely a good task)
23:33 chromatic We can start for 2.6, but a lot of the benefits will come from Lorito.
23:33 allison okay, will mark 2.6 for now, review later
23:34 allison self-hosted tools?
23:34 particle1 after lorito
23:34 pmichaud totally not a priority from my perspective :)
23:34 japhb A long term goal, not a roadmap task
23:34 allison that's currently on the roadmap for 3.0 (eliminate Perl 5 dependency)
23:34 pmichaud what's the advantage of self-hosted tools, and is working on that a greater advantage than resolving some of our other tasks?
23:34 japhb I think it's nice for people to jump in and work on, but no core person should consider it their main goal
23:35 allison (marked no rodmap)
23:35 allison switch from SVN to GIT?
23:35 particle1 pmichaud: no reliance on perl, better portability (maybe)
23:35 particle1 definitely no switch to parrot infrastructure before rakudo *. we have enough distractions
23:35 pmichaud particle1: I think we have enough distractions through 3.6 :)
23:35 particle1 i don't think infrastructure items are roadmap-worthy in general
23:35 chromatic I don't want to consider that before 2.3.
23:35 allison agreed, not a roadmap item
23:35 pmichaud switch from svn to git: no vote here
23:36 japhb I vote for "as soon as the rest of you let us"
23:36 japhb :-)
23:36 allison (I'm against git anyway)
23:36 pmichaud actually, I have a counter-vote
23:36 chromatic Me too, but I don't want to let it get in the way of 2.3.
23:36 allison but, we don't care about that now
23:36 pmichaud if switching to git, either do it for 2.0 or not until after 2.3
23:36 japhb After 2.3 then
23:36 allison we only care about "when do we raise it again"
23:36 kid51 Over the next year, more people will get familiar with git via other projects/HLLs.  That will create a better user base for considering such a change.
23:36 japhb Nothing gets in the way of 2.0
23:36 pmichaud I don't want to be rewriting my build scripts in February or March.
23:36 pmichaud (or April)
23:37 allison Algorithmic optimisations of PIR code?
23:37 allison what's the task, and when do we need it
23:37 Whiteknight that's dependent on PIRC
23:37 chromatic It can be PAST-level; no PIRC necessary.
23:37 japhb allison, as I commented on the spreadsheet, I think that effort needs to go into PAST or POST optimization, not after its in PIR
23:37 japhb chromatic++
23:37 particle1 in the meantime, we have dukeleto's git mirror of the parrot svn repo.
23:37 Whiteknight PAST-level optimizations would be nice too, but not enough
23:37 japhb Whiteknight, what about POST?
23:37 Whiteknight we need all the optimizations across all abstraction layers that we can get
23:37 chromatic I have my doubts that I'll have time to work on it until the 2.6 era.
23:38 Whiteknight PAST, PEST, PIST, POST, PUST, we can optimize them all
23:38 Whiteknight and more
23:38 chromatic (A Hague grant... well, I have some thoughts about that process as well.)
23:38 particle1 use tree-ssa on past/post
23:38 allison sounds like not a roadmap task
23:38 NotFound Whiteknight: Proust, even.
23:38 japhb But I don't think we want to consider "PIR" as our optimization base.  We should write optimization passes for the trees, not the file syntax
23:38 chromatic I'd like to see it for 2.6 actually.
23:38 particle1 not roadmap, it's a way to achieve performance
23:39 chromatic It's a feature for PCT.
23:39 Whiteknight and performance is king
23:39 allison put it in as a ticket
23:39 japhb chromatic: +1
23:39 allison (we're half-way through the list and 9 minutes over)
23:39 japhb I can stay
23:39 allison but, we're nearly done with the new items
23:39 allison last one is Parrot+HLL TapTinder/Buildbod
23:40 particle1 time is valuable, let's plow through.
23:40 Whiteknight "buildbot"?
23:40 particle1 this is infrastructure
23:40 allison then we can do a quick pass on the old items pushing them out
23:40 chromatic Infrastructure.
23:40 japhb allison, Plumage being able to support a "smoke" action now should help make that easier.
23:40 allison so, not roadmap?
23:40 particle1 Whiteknight: gives insight on failing parrot builds
23:40 Coke no.
23:41 Whiteknight particle: I know what smoke is, Pointing out what I think is a spelling error
23:41 allison okay, onto the old items
23:41 allison documentation translation infrastructure
23:41 allison currently 2.6, move to?
23:41 allison 3.6?
23:41 kid51 +1
23:41 japhb +1
23:42 allison it doesn't seem like translated documentation is a large obstacle to involvement at the moment
23:42 particle1 not roadmap
23:42 particle1 it's long-term
23:42 kid51 Yes, and I like coke's earlier point of no roadmap item before its time
23:42 allison I'll go with that
23:42 allison async I/O?
23:42 pmichaud asynch I/O:  not critical for Rakudo*, but (like NCI) people will undoubtedly start asking about it shortly after Rakudo*
23:42 allison who needs it and when?
23:43 pmichaud i..e, as soon as Rakudo* is out, people will start asking for it.
23:43 particle1 within a year from Rakudo *
23:43 pmichaud (and Rakudo will likely say "Parrot doesn't have it yet.")
23:43 allison currently 2.6
23:43 allison change?
23:43 Whiteknight AIO is high on my list of personal interests
23:43 japhb Not 2.3, but 2.6-3.0 at the latest
23:43 pmichaud I don't know how hard it will be to do, but I think failure to have it will reflect very badly on Parrot.
23:43 allison how about 2.9?
23:43 japhb pmichaud, exactly
23:43 allison (2.6 is heavily loaded)
23:43 particle1 2.9: +1
23:44 Whiteknight It's going to be intertwined with concurrency improvemets though
23:44 japhb I'm fine with 2.9
23:44 japhb "I like Ike"
23:44 Whiteknight I don't think we can do AIO without at least some fixin' on threads
23:44 allison vtable swap?
23:44 allison Whiteknight: yes, good point
23:44 japhb Whiteknight, and will be hard without some improvement to callbacks handling WRT threads as well
23:44 allison vtable swap isn't critical for Rakudo *, which pushes it out a bit
23:44 Whiteknight what is vtable swap?
23:44 pmichaud Whiteknight: what about things like select(), is that available now?
23:45 allison is it a roadmap task? or just a general "good to do at some point?"
23:45 Tene pmichaud: a Select PMC would be pretty simple to put together.
23:45 Whiteknight pmichaud: No select() that I am aware of now, at least not done well
23:45 Whiteknight pmichaud: could be added relatively quickly, I think
23:45 Tene It's been on my tasklist for a long time, but never got around to it.
23:45 pmichaud select() is more what I'm thinking people will want -- to write servers and the like.
23:45 pmichaud I agree that impacts threads as well, though.
23:45 pmichaud sorry, back to vtable swap :)
23:46 Tene There's a TT talking about thread issues that has attached patches for review.
23:46 chromatic You can remove vtable swap.  It's largely unnecessary after Key and Iterator refactors.
23:46 japhb Yes, (with Perl 6 user hat on) I want to be able to write IP servers and clients in Perl 6.  As soon as the infrastructure is there.  (swaps hats again)
23:46 allison chromatic: can we close the ticket?
23:46 particle1 crosstalk on #parrot, please?
23:46 chromatic Sure.
23:46 allison chromatic: noted
23:47 allison pirc?
23:47 particle1 can we do pirc and lorito in the same year?
23:47 Whiteknight yes
23:47 allison as chromatic noted earlier, nice, but not critical for Rakudo *
23:47 Whiteknight I don't think PIRC is too far off, in terms of development effort
23:47 pmichaud is there a purpose to doing pirc separate from lorito?
23:47 allison do we need pirc once we have lorito?
23:47 chromatic Depends how much of Lorito lands and when.
23:48 particle1 3.0
23:48 pmichaud can we live with imcc until lorito lands ?
23:48 allison is pirc a roadmap item?
23:48 particle1 we'll pull the pirc/lorito deps apart later.
23:48 chromatic IMCC will continue to be painful the longer it lasts.
23:48 allison I'll note "bundle with lorito task"
23:48 chromatic There are some intractable bugs in IMCC.
23:48 pmichaud bundle +1
23:48 Whiteknight even with lorito, we aren't getting rid of PIR/PASM
23:48 mikehh we need to get away from IMCC asap
23:49 Whiteknight so we are going to want a compiler for PIR/PASM
23:49 pmichaud Whiteknight: I agree, but I suspect a PIR compiler might look a bit different if it's targeting lorito
23:49 allison I suspect so too
23:49 allison okay, put at 3.0 with lorito
23:49 particle1 we'll have nine months after 2.3 to look at pirc/lorito/post->pbc etc
23:49 allison can merge if needed
23:50 pmichaud particle1: nine months is not that long.
23:50 allison bytecode generation from post?
23:50 Whiteknight pmichaud: it's just a difference in generated code
23:50 pmichaud nine months ago, we release 1.0, and not a lot of new features have landed since then.
23:50 particle1 pmichaud: agreed, but we can't do it before 2.3
23:50 chromatic I saw the POST->PBC proof of concept.
23:50 chromatic I don't know how much work remains, but I doubt it'll help Rakudo substantially.
23:51 allison not critical for 2.3
23:51 allison 3.3?
23:51 allison or non-roadmap?
23:51 particle1 after pbc<->pasm
23:51 pmichaud POST is another area that I think may be substantially affected by lorito, fwiw.
23:51 allison agreed
23:51 allison 3.9?
23:51 pmichaud 3.6.
23:51 pmichaud assuming lorito is 3.0.
23:51 allison marked 3.6
23:51 pmichaud (3.9 seems too far away from lorito)
23:52 allison increased portability?
23:52 allison is it a roadmap task?
23:52 particle1 no
23:52 kid51 Too vague
23:52 allison it seems to be happening naturally anyway
23:52 particle1 maybe a milestone target later
23:52 chromatic Maybe specific targets later.
23:52 particle1 (like rtems)
23:52 allison we can add it back as we have specific tasks
23:53 allison cross-compile configuration?
23:53 particle1 cross-compile is related to portability, drop it
23:53 allison PASM review?
23:53 kid51 The TT for "increase portability" translates to "recruit platform maintainers"
23:53 allison kid51: yes
23:54 allison when do we need PASM refinements as a plain english form of bytecode
23:54 allison 2.6 seems too early
23:54 particle1 before users can debug pbc effectively.
23:54 particle1 3.6?
23:55 pmichaud I'd leave it off the roadmap until someone identifies it as a pain point
23:55 particle1 wfm
23:55 chromatic +1
23:55 allison yes, 3.6 is good, for the same reasons as the POST->bytecode
23:55 mikehh +1
23:55 allison we already have painpoints
23:55 allison in debuggin
23:55 allison g
23:56 allison review bytecode implementation?
23:56 allison are there still aspects of the current bytecode spec that aren't implemented?
23:56 allison or, have we caught up with that?
23:57 chromatic Seems like an airplane-time task.
23:57 NotFound I think the string enconding is still not stoted in the pbc.
23:57 allison drop from roadmap?
23:57 particle1 drop review tasks
23:57 pmichaud it's generally not on my radar, no.  I'm not sure where bytecode compatibility fits in our roadmap.
23:57 pmichaud (i.e., backwards-compatible pbc)
23:57 allison that's currently on for 2.0
23:58 allison but, we'll review that when we get there
23:58 chromatic Maybe so, but we haven't worked on it.
23:58 allison (10 lines or so)
23:58 allison new jit?
23:58 particle1 jit before lorito?
23:58 allison currently 2.6
23:58 allison 3.0 seems awfully late for restoring a JIT
23:59 allison but then, we seem to be focusing on other optimizations
23:59 pmichaud I can't imagine anything jit-related happening before then.  Or perhaps even then, except if lorito provides some help there.
23:59 particle1 yep, other optimizations
23:59 allison 3.0?
23:59 allison 3.6?
23:59 allison 4.0?
23:59 chromatic Let's try 3.0.
23:59 particle1 3.3, shortly after lorito
23:59 japhb 3.0-3.6

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary