Vision for 2.0: Production Users | Priority for 1.9: Performance and Testing | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
Set by moderator on 3 December 2009.
00:33 PacoLinux joined 00:34 PacoLinux left 00:39 davidfetter joined 00:40 davidfetter left 01:07 japhb joined 03:00 ilbot2 joined
moderator Vision for 2.0: Production Users | Priority for 1.9: Performance and Testing | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
cotto joined 03:04 cotto_work joined 03:05 Tene joined 03:08 tewk_ joined 08:03 cotto_w0rk joined 13:12 mikehh joined 15:56 Whiteknight joined 16:01 mikehh joined 16:08 mikehh joined 16:15 mikehh joined 16:23 mikehh joined 16:34 mikehh joined 17:18 mikehh joined 18:19 plobsing joined, kid51 joined
kid51 So this is where the online Parrot Roadmap meeting will be, starting at 2030 UCT -- i.e., about 2:10 from now. 18:20
mikehh well I am here - so will see what happens 18:25
18:29 Infinoid joined
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.
Infinoid: Did you get my email of several days back re hackathon? 18:30
Infinoid kid51: I did. 18:31
kid51 Thoughts?
Infinoid My mental parrot-state is about 6 or 7 months out of date, but I'm always up for breaking code
kid51 My premise is this. 18:32
As wonderful as online collaboration is, a FOSS project's developers needed F2F contact periodically.
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:33
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
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:35
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
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
kid51 I understand. Most of what needs to be done in Parrot these days is outside of my scope as well. 18:37
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.
Infinoid Cool. That's why I wanted to lurk 18:38
kid51 Are you still in Delaware? 18:39
Infinoid Yeah. Philly is within easy reach for me
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 spreadsheets.google.com/ccc?key=0A...&hl=en
Whiteknight should really meet up with Infinoid some time, he doesn't work too too far away from him 18:46
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:49
Infinoid Who else is in the area? 18:53
kid51 I believe jhorwitz is in Philadelphia and Austin is in Jersey near Phila.
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.
Infinoid Whiteknight: Dropping by with pizza one day is still on my todo list :)
kid51 Nevertheless, that's > $#NYCparrotdevelopers
allison is anyone near Chicago? 18:59
we could do a face-to-face during the PyCon sprints
kid51 When are they? 19:00
allison February
Feb 22-25th 19:01
(conference the week before)
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..
afk
Whiteknight I added my name to the spreadsheet a few times too, in case I can't be 100% active at the meeting 19:28
20:12 chromatic joined 20:17 bacek joined
bacek Good morning 20:17
chromatic, looks like your comment about Concurency belong to GC 20:18
(in spreadsheet) 20:19
chromatic Looking now. 20:22
You're right; thanks. 20:23
japhb Hello all. 20:28
20:29 particle1 joined
allison hi 20:31
mikehh hello
japhb o/
chromatic greetings
bacek wave from tomorrow 20:33
chromatic Who's in charge and what's the agenda?
allison I know a few people won't make it in until later
it's worth starting with collecting a list of topic
we've got the spreadsheet of potential roadmap items 20:34
spreadsheets.google.com/ccc?key=0A...&hl=en
chromatic: would you care to do the honors?
chromatic Reading spreadsheet.
I think there are several potential topics we should consider. 20:35
In no particular order:
*) What have we done right in the past year?
*) What mistakes did we make that we need to improve?
*) What short-term projects do we need?
*) What long-term goals do we need?
*) How can we be more effective?
Perhaps also: 20:36
*) What isn't working?
allison *) what items should we schedule for which releases?
chromatic That might be an open question; can and should we schedule those?
allison *) what are realistic goals, based on our velocity in the past year? 20:37
particle1 *) what is the goal for this meeting?
allison this meeting is a virtual substitute for PDS
particle1 i expected this to be a roadmap planning session, not a retrospective.
allison so, planning the next year, at least a rough outline
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?
allison there's some of both, since any planning session involves some of "what can we do better?
japhb: double click on the field
kid51 chromatic is suggesting a process-oriented part of the session ... which I think is correct, provided we set a time limit
allison kid51: good idea 20:39
japhb allsion: ah, THANK YOU
allison how long should we allocate to retrospective?
30 min?
chromatic Can do.
kid51 Yes, let's do that and reassess in 30.
chromatic Okay. First question. What have we done right in the past year?
kid51 Maintained monthly release schedule.
bacek kid51, +1 20:40
allison shipped every monthly release on time
particle1 added committers and release managers
allison shipped two solid "supported" releases, which are now included in the major Linux distributions
kid51 A lot more HLL activity
allison (that was a big goal behind 1.o)
chromatic Parrot's installable now.
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:41
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
allison bacek: needs to go on the roadmap
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
allison optimiations
parrot is substantially faster
chromatic We removed some ugly code.
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)
chromatic Parts are substantially faster.
Anything else? 20:45
particle1 we held elections
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)
mikehh testing has improved but still quite a way to go
kid51 Cleared out RT in favor of Trac 20:46
allison the regular roadmap reviews have definitely been helpful
chromatic The retrospective at YAPC was useful.
#ps has improved. 20:47
particle1 chromatic: +1
it drove process changes
like #parrotsketch format change
japhb Yes, the #ps format change was quite useful
chromatic Last call for successes.
allison yes, pre-posting reports has been a big help
particle1 we created a new role, but i haven't seen any positive impact 20:48
"dev coach"
anyone who can speak to positives on that?
kid51 ... and who plays that role?
allison I'd say that's largely because he was already doing the work
particle1 chromatic plays that role
allison it was more acknowledging the work, and defining it more clearly
chromatic allison and I argue less in public now....
kid51 ++ 20:49
particle1 ++
allison :)
chromatic Where's that smiley key? Oh, forget it.
allison which doesn't mean we're arguing more in private, either
chromatic Sure, but it's not visible.
Let's move on. What hasn't worked in the past year?
I'll start: the deprecation policy has been too contentious.
particle1 parrot foundation hasn't raised any money 20:50
mikehh we've slipped a lot on roadmap items
kid51 Too long intervals between F2F meetings or sessions like this
allison our roadmaps have been too ambitious
chromatic We have a lot of technical debt.
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
particle1 but still a lot of technical dept
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.
chromatic There's a monthly upgrade tax for HLL developers; I can only imagine the bi-annual tax.
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.
allison yes
particle1 we haven't prioritised the needs of hll devs
allison we have very few languages in a "finished" state 20:53
20:53 darbelo joined
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
kid51 I confess that I'm only aware of the HLLs that have commit-bots which post to #parrot
allison it's still difficult for prospective HLL developers to find info on how to develop HLLs on Parrot
chromatic Other negatives? 20:55
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.
chromatic Oh yeah, lack of HLL-exposed bugs in tests. That one hurts a lot.
kid51 It basically stopped half of yesterday's hackathon dead in its tracks.
japhb Which brings up: (Occasional) assumption that test suite is complete enough to proxy for "this is or is not every used" 20:57
er ever
mikehh we need to adopt a policy like rakudo - don't close tickets until test is also there
chromatic Anything else? 20:58
Next question. 20:59
How can we improve what didn't work so well in the past year?
bacek Switch to opt-in deprecation policy 21:00
allison make HLL development needs a top priority
japhb ... and three month cycle
allison bacek: elaborate?
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.
allison bacek: since we don't currently have customers outside of the HLLs, who's going to opt-in?
will look at the thread
particle1 where subsystems opt-in to the deprecation policy
not users
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"...
chromatic It'll be a lot of work to review every subsystem for maturity and likelihood of change.
particle1 chromatic: i wrote a stability document some time ago that should help us classify subsystems
japhb chromatic, but still seems more reasonable than what we have now
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.
allison deprecating a couple of subsystems before 2.0 could be a good idea 21:03
japhb kid51, +!
allison (threads, for example)
japhb er +1
bacek kid51, +1
chromatic We already deprecated a couple of subsystems: JIT, JITted call frames.
particle1 svn.parrot.org/parrot/trunk/docs/stability.pod
allison kid51: yes, that is an important goal for the next year
japhb Anything we're looking at changing in the next 6-12 months should probably be deprecated now.
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
chromatic Is the list of milestones/tasks/whatever we plan to come up with later in this meeting sufficient to start marking deprecation possibilities?
particle1 note: we're 35mins in to our meeting. 21:05
allison chromatic: yes
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
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
particle1 get better at asking for money
create tutorial to introduce hll devs
that's it
chromatic pmichaud is working on an NQP book.
bacek "marketing" of parrot become more and more critical 21:08
chromatic Last call.
21:08 Coke joined
Coke ~~ 21:08
chromatic Okay. Quick procedural question: can we take a few minutes to discuss kid51's suggestion of focusing on Rakudo *?
Any objections?
japhb please, yes
darbelo +1
kid51 May I state my case?
mikehh +1
particle1 should we wait for pmichaud?
chromatic Let's give this ten minutes and see what happens. 21:09
kid51, go ahead.
kid51 2010 marks the 10th anniversary of Perl 6. If nothing viable emerges next year, a lot of people will say screw it.
And Rakudo* is the biggest viable thing on the horizon.
So I think it's really important that its launch be successful and be perceived as such. 21:10
We can't affect how fast Larry works
But we can affect how well Patrick, Jonathan, etc. work.
So I think what we do over next four months should always be measured against the criterion of successful Rakudo* debut. 21:11
That's my message.
chromatic Well put.
mikehh I agree wholeheartedly
kid51 Successful debut of rakudo* will lead to interest from other HLLs.
chromatic Can we make that our goal for the April release?
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.
chromatic (I assume that we move to a three-month cycle for supported releases, which makes the April release a supported release.)
bacek chromatic, I think our goal for April release should be "fastest parrot ever".
particle1 larry is working fast enough for perl 6 devs today.
bacek which implies at least GC refactoring.
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.
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.
kid51 japhb: Yes that'
that'st the psychology people will have
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.
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.)
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
(No I don't remember details ATM)
chromatic I've read a lot of agreement. Are there concerns or alternatives?
bacek We shouldn't abandon support for other HLLs. 21:16
allison seems reasonable
bacek E.g. Lua
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
Coke bacek: I don't think anyone is suggesting that.
kid51 Allow a month for things to settle.
allison bacek: of course, that's not even considered
bacek of course it's not considered.
japhb kid51: agreed 21:17
chromatic We're talking about the driving vision for 2.0 - 2.3.
bacek But it can happen accidentally.
kid51 My hope is that a successful debut of rakudo* will inspire more HLL devs from those languages
allison bacek: good point, and yes, when we say HLL needs are a focus it does include all HLLs
particle1 going back a bit, we still don't do a good job of watching hll test reports. 21:18
we still need a workable language smoke solution.
chromatic We also need to improve our ability to extract tests from HLLs to Parrot.
japhb Now that Plumage can smoke, someone (fperrad?) suggested using it as the core of an all-HLL smoke system
bacek particle1, I've added it as line 22 in spreedsheet
chromatic We're at the ten minute mark. Can we agree on the HLL (and Rakudo in specific) concentration?
japhb +1 21:19
21:19 moritz joined
darbelo +Inf 21:19
kid51 +1
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.
allison +1
Coke chromatic: +1
bacek Yay! Rakudo ambassador arrived :)
chromatic, +1
moritz not really, just observer
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
chromatic I think this means that we need to evaluate short-term milestones in terms of what they mean for HLL development.
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 *.
Likewise, we'll have to be careful about how much Lorito groundwork we lay. 21:21
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 ...
bacek chromatic, 1. ops2c in NQP; 2. Emitting PBC from PIR (done); 3. Lorito ops "spec"
kid51 ... but that doesn't prevent other (newer?) devs from workking in branches on longer-term stuff.
chromatic Sure, there's a roadmap for Lorito, but if there are HLL bugs that need addressed, we should focus on those. 21:23
particle1 rakudo wants speed 21:24
without faster pcc, rakudo isn't 'usable' as it's too slow
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.
chromatic With our vision in mind, let's brainstorm some goals.
particle1 can faster pcc and better gcc be made 3-mo goals?
bacek particle1, +1
chromatic "Reduce PCC overhead" 21:26
"Create fewer garbage GCables in PCC"
"Reduce GC cost with better algorithm"
bacek but "better gcc" is hard target. Probably "better gc" is simpler
kid51 bacek: u beat me to it! 21:27
particle1 heh, better gc, of course. beer++ fingers--
chromatic There's beer?
particle1 yeah, check the fridge. i've got plenty.
bacek chromatic, no... There is $dayjob coming.
chromatic Other short-term priorities?
"Fix line numbers in annotations"
"Reduce likelihood of inferior runloops" 21:28
particle1 what about making more of pbc available in pasm?
chromatic I'll put it in the list, but I don't know what it'll help.
allison quite a few in the spreadsheet, which need to be reshuffled in light of new goal
(or, reprioritized goal)
chromatic "Make freeze/thaw work reliably" 21:29
japhb particle1: you mean the old goal of making pbc <-> pasm round trip?
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
chromatic Noted, japhb. 21:31
kid51 proto?
chromatic A Perl 6 installation system.
japhb kid51, Perl 6 module install too. Meant to be a throw away, but has not yet been thrown away.
particle1 pir is not pasm. we need pbc <-> pasm round trip, and documented.
japhb er tool
particle1 unless we drop pasm, which i don't think will happen.
Coke particle1: I hesitate to put more work into pasm.
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.
japhb right
allison japhb: yes, that's what it should be
particle1 currently, you can't express all pbc constructs in pasm.
allison japhb: which does mean some working making pbc<->pasm work 21:33
but, not much work
particle1 agreed, not much work.
japhb good to hear, that
allison I'll note that on the PASM milestone
chromatic I'm noting that as "Fix PBC <-> PASM roundtrip"
Any other short-term goals?
"PAST optimization tools" might be nice, but.... 21:34
japhb Is Rakudo* supposed to have strong NCI support?
Because that might bump the NCI fixes goal
allison chromatic: they're already on the list
chromatic: currently for 2.6, but seems like they could be pushed later 21:35
(provided we get enough speed gains out of GC and PCC work)
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.
moritz chromatic: NCI usable from Rakudo would be great
chromatic Is it a goal for Rakudo *?
moritz and would help DBD2 a lot 21:37
chromatic: let me take a loook at the ROADMAP, but I think not
21:37 mikehh joined
chromatic Anything else? 21:37
moritz chromatic: it's a low priority task (ie not mandatory)
chromatic Good to know, thanks. 21:38
21:38 davidfetter joined
chromatic Let's move on. 21:38
bacek moving to $dayjob 21:39
chromatic What risks do we face to our short-term goals?
allison time
chromatic Attention span.
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. =-)
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.
allison Rakudo could have a sudden slew of needs towards the release that overload our developer capacity
chromatic The GC changes are risky code-wise; it's not easy to replace the GC in a running system.
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.
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.
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"
japhb particle: Because of "fire of the week" problems stealing developer cycles, or because developer goals are changing too often?
particle1 japhb: do you have a ticket system for plumage, and can you write some LHF (low-hanging fruit) tickets for testing?
chromatic: our gc system is supposedly pluggable
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.
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
chromatic Read barriers... mark() and destroy()... there's lots of that code throughout the system.
allison particle: that is, we need to make it more pluggable
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?
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.
japhb And I've added Tickets to my personal todo
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.
japhb particle1: let's discuss that in #parrot
chromatic Next question.
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?
allison set priorities that meet our goals
21:49 mikehh joined
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.
darbelo Having small tasks that can be acomplished in 1-2 hours of hacking is great for not blocking on a single person. 21:51
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?
allison it takes time to break down the tasks
chromatic We effectively have to do it anyway to perform them, though.
allison that is, someone has to do the work of making the tasks before others start consuming the tasks
21:53 mikehh joined 21:54 Whiteknight joined
darbelo chromatic: maybe it's a visibility thing. 21:54
chromatic Maybe. I try to name names when I mention these tasks though.
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.
chromatic That's for sure.
kid51 So, things that are outside of, or have not yet entered TT, are impossible for me to work on.
... whereas if it's in TT, there's a (small) chance I *can* work on it. 21:56
And there are probably other people in same boat
chromatic How do we address that? Can we?
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.
well, even if you can't work on a ticket, you can still bug someone else to on IRC.
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.
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?
kid51 notes that we now have the same average number of TTs as we did on RT: 600-700 21:59
So I don't think the number of tickets is the blocker per se
japhb Right, our ticket reduction in RT seemed to largely go to transferring to TT
allison I suspect tasks are getting lost in the stack
particle1 the lack of proper classification makes things easy to lose or hard to track
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.
particle1 s/track/find/
japhb allison, yeah, that's part of what I was trying to say
allison something like "review one ticket a day" would go a long way
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.
Whiteknight that might make a nice addition to #ps format: what ticket did I look at this week?
Coke reviewing tt's is a good intro task, too.
Whiteknight if it's routine, we're more likely to do it
allison Whiteknight: I like that idea
particle1 let's first concentrate on defining which tickets are high priority for or before 2.3 22:01
then address those tickets first
japhb Whiteknight, +1
chromatic I'll add that as a short-term goal.
How about also as a short-term goal "Write a ticket guidelines document for novices"? 22:02
We may have something like that; I didn't check just now.
mikehh I think we also need to triage our tickets 22:03
darbelo (Write documents for novices)++
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.
Coke particle1: there is already a list/report for that.l
use that.
particle1 coke++
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.
5 minute break, any objections?
Coke trac.parrot.org/parrot/report/16 (tickets that hll devs care about)
particle1 can we create redirects for trac to give those reports names? 22:06
break++
cotto Are conclusions from this meeting (if any) being documented on the wiki? 22:09
22:09 Whiteknight joined
chromatic I've taken notes on concrete suggestions, but I haven't put them on the wiki yet. 22:11
cotto sure. there's plenty of time left in the meeting 22:13
chromatic Unbreak time?
cotto (and plenty of log to read through)
22:14 pmichaud joined
darbelo Do we wait for pmichaud 22:14
pmichaud here finally, sorry I was late
chromatic We're still talking about short-term efficacy and process improvements. Any other thoughts?
darbelo Ah, hes here.
kid51 Ah! a customer has just walked thru the door!
japhb mmm, circulation. It's a wonderful thing.
allison chromatic: I'd say the next step is to move into specifics
chromatic Okay. 22:16
Which specifics are those?
particle1 roadmap specifics?
22:17 mikehh joined
allison yes 22:17
mikehh my internet connection is really giving me a hard time
chromatic Want to lead this one, allison? 22:18
allison okay
we've got a long list of possible tasks
some have times assigned some don't
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
the ones that aren't attached to a release date need to be, even if we change it later
and, its possible that some tasks we put on the roadmap at the last PDS are no longer a roadmap-level priority 22:20
sticky notes were nice for this, because they let people dynamically interact 22:21
Whiteknight "no longer a roadmap-level priority" +1
allison but, we can go through the spreadsheet, tweak the release numbers and sort it to get our approximate timeline
pmichaud okay, done reading backscroll. any specific questions I could answer at this point ?
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
particle1 or take each item here for votes?
allison particle: let's just decide in channel
pmichaud Whiteknight sent me a message about that earlier in the week, I don't know what happened to my reply though
allison starting at the top: 22:23
Move to 3 month release cycle starting at 2.0
Whiteknight pmichaud: that mail wasn' on list
allison yay, nay?
chromatic +1
pmichaud Whiteknight: right, I know. But I didn't see any response to it either :-)
+1 on 3-month release cycle
Whiteknight oh, no response. Just accepted and digested the info 22:24
darbelo +1
pmichaud let me see if I can get the text of the sent-mail and post it somewhere for others to see
allison any opposed or any discussion?
Coke +1 on 3-month.
japhb +1 3 month 22:25
Whiteknight +1 (3-month cyle)
cycle*
pmichaud nopaste.snit.ch/19067 (partial response to whiteknight++'s message)
mikehh +1 on 3 month cycle
22:25 GeJ joined
allison okay, we'll consider that motion carried (objections can be raised later) 22:25
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
chromatic We discussed doing that the #ps of a release day.
pmichaud coke++ proposed that we do roadmap review before each supported release 22:27
(which makes sense to me)
oh, sorry, roadmap review != roadmap planning
coke++ proposed that we do roadmap planning before each supported release (but that was on the 6-month cadence)
allison good idea, added to spreadsheet 22:28
Coke should work the same on 3-month, yah.
allison (not sure where that will go in the docs yet, but should go somewhere)
it's not at the top, but related: review deprecation policy
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?
(Other than work to do the review of current state)
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
allison I don't like the term "opt-in", but the general idea of clearly defining what is and isn't supported I like
Whiteknight pmichaud: opt-in should relieve your pains in waiting for deprecation cycles
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
allison Whiteknight: I'm not sure it does
pmichaud: yes, exactly
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.
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
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
Whiteknight currently we support things that *are not* good enough to make guarantees about
and that hurts everybody
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)
Coke perhaps we'd be better off enumerating the things that are explicitly not good enough.
japhb Whiteknight, +1
allison pmichaud: yes, but it's only a 3 month dark code argument
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.
allison pmichaud: which is substantially different than dark code into the infinite past
pmichaud to me, moving from a 6-month cycle to a 3-month cycle _greatly_ reduces the pain involved.
particle1 coke: svn.parrot.org/parrot/trunk/docs/stability.pod defines the stability levels
Coke I'd be happy to give the 3 month cycle a shot and see what falls out.
chromatic +1 to listing systems or features that may change.
pmichaud chromatic: I think we already do that, though
chromatic That's much more predictable in three-month increments.
japhb Do we need to "turn off deprecation cycle" until the Rakudo* is out? In order to completely unblock this critical cycle?
pmichaud what whiteknight is proposing is that everything is allowed to change until it's declared "stable" 22:34
japhb: I don't think that's necessary
allison well, we also do that now, we call those features "experimental"
japhb pmichaud, OK, just checking
Coke we have a month to figure out if we need to add anything to the experimental list for the 2.0 release.
particle1 turning off deprecation can have unexpected consequences, i caution against it.
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"
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"
I agree with "let's see how the 3-month cycle works out"
22:35 bacek_at_work joined
bacek_at_work ~~ 22:35
allison and, c) plan to review deprecation policy again at the next roadmap planning session before 2.3 22:36
pmichaud +1
I have another brief comment here
allison sound like a reasonable resolution of the question for now?
pmichaud: go ahead
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.
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:37
particle1 allison: +1 22:38
pmichaud (end of comment)
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.
chromatic Besides, if we need to release a 2.0.1 with additional deprecation notices, we can.
allison (keep the old and add the new, with a way to select between the two)
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.
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:40
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
(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.
particle1 5 weeks
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.
pmichaud wfm
allison The focus here is first on the short-term priority of Rakudo *
and secondarily on our longer-term goals 22:43
"Where do we want Parrot to be in 2-3 years?"
line 4: lvalues
is this a 2.3 level priority?
2.6?
pmichaud not for Rakudo.
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.
particle1 2.6
allison it's about efficiency, which we've put as a high priority
I'm good with 2.6
concurrency? 22:45
pmichaud not a Rakudo* priority
allison this is a revamp of the current threads implementation
people generally happy with the 3.0 posted in the spreadsheet?
particle1 3.0
pmichaud 3.0 wfm
allison GC? 22:46
2.3 for something is a good idea
pmichaud very important to Rakudo as it pertains to performance/speed
allison what do we plan to accomplish for 2.3?
chromatic We should be able to implement at least the sweep-free GC.
pmichaud basically, Rakudo*'s #1 need from parrot at this point is anything to improve performance/speed, especially for hll compilation and performance
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".
allison which will likely involve a new GC module, but may not cover all the refactors we want to do
pmichaud: yes, agreed 22:48
particle1 on the spreadsheet, is "suggested release" supported releases only? for now?
allison particle: yes
we'll break them down into the monthly releases later 22:49
what's RTEMS port?
particle1 getting parrot to compile/run on the real time os RTEMS
darbelo www.rtems.com/
particle1 RTEMS has some good tools for developers/debuggers/profilers 22:50
allison a port
particle1 but i see it as either off-cycle, or 3.0 priority
chromatic It doesn't seem like a milestone task.
darbelo off-cycle sounds good to me
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
particle1 yes, it's a port. if we have a milestone goal for portability by *supported release M.N*, then it's roadmap
japhb off-cycle, yes
Coke I don't think we can make a port a milestone goal. it's too dependant on the porter.
allison marked as not for roadmap
pmichaud allison: +1
allison strings? 22:52
22:52 mikehh joined
allison is this the NFG implementation? 22:52
pmichaud possibly
Coke yes.
darbelo nfg?
particle1 please i hope so.
darbelo: see the strings pdd
pmichaud the primary issue from a Rakudo perspective is the cost of variable-width encoded strings
allison darbelo: Grapheme Normalization Form 22:53
pmichaud and that without ICU, there's not a way to do some unicode-related items
japhb Why aren't we requiring ICU yet?
allison japhb: because that would limit the platforms we can support
chromatic Variable-width encoding hurts.
japhb poor portability, eh? yucko 22:54
allison NFG is a way to get around variable width encodings
is it the best way?
Coke allison: we can't suppor the platforms that it would cost us anyway.
allison is it the easiest way?
particle1 it's the way perl 6 expects.
japhb Coke, I was wondering about that ...
chromatic Risk: few people understand NFG and the existing prototype may have bitrotted.
allison the existing prototype was written in Perl anyway 22:55
not a "working branch"
chromatic I meant design more than implementation, but point taken.
allison yes, NFG is complex, so it's a big task
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
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".
allison (similar to GC)
Coke so, let's keep strings on the list, but it can stay way out there.
allison pmichaud: what do you have in mind?
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.
allison require ICU?
and, what for the fixed-width encoding? 22:57
particle1 can we please put the detail on strings on that roadmap item?
chromatic There are other string concerns as well, such as removing in-place modification.
particle1 "strings: fixed-width encoding and unicode semantics"
unclear roadmap items bit us last year
allison (requiring ICU has it's disadvantages, but it at least involves very little developer effort)
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.
and making sure that we can do something fast-ish with unicode strings 22:58
mikehh what platforms is ICU not available on
japhb We can always un-require it later, it's not like its a permanent decision
allison requiring ICU is going to bite us on later goals when we get to "nanoparrot for embedded systems"
darbelo There's a comment about stringnull and "no mutable strings" by chromatic there.
particle1 icu requires c++ compiler
Coke allison: and are we going to support unicode on nanoparrot for embedded systems?? 22:59
darbelo unicode on embeded systems? No way.
allison Coke: no, but we're not saying "require ICU if you want unicode support"
Coke: that's what we do now
Coke: the question here is "do we require it in all cases?
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)
allison the question here is when do we need to resolve them?
pmichaud and perhaps Rakudo could handle the "ICU is present, let's use faster encodings" decision making, rather than Parrot doing it
fast unicode string processing would seem to me to be something we want to have before 3.0 23:01
it's not a 2.3 priority to me
Tene re F2F meetings, I have zero budget for travel, but I'm willing to go anywhere I'm asked if travel is funded.
particle1 sounds like we have multiple string-related roadmap items
some related to rakudo *, some unrelated 23:02
chromatic Perhaps we should table the ICU discussion for now.
pmichaud fwiw, none of the strings items are related to Rakudo*
allison Tene: aye, most of us are in that boat, which is why this isn't F2F
pmichaud (except to the extent that improving strings might improve speed.)
chromatic "No mutable strings" may improve performance.
allison so, we're putting the ICU and fixed-width encodings down for 3.0
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
allison and if so, when?
pmichaud I vote whatever chromatic votes :)
23:04 NotFound joined
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:04
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
particle1 we have many more roadmap items to discuss, and 25 minutes
allison chromatic: so 2.3?
chromatic Love to; can we discuss in the next #ps?
Coke +1
particle1 ++
allison yes
okay, what's native type lexicals?
pmichaud currently Parrot lexicals can only refer to PMCs
chromatic Storing non-PMCs in LexPads.
pmichaud that has huge implications on being able to optimize things in compilers and subroutines 23:06
particle1 need.
allison so, a typed data structure like we use for CallSignature now
time frame?
pmichaud not 2.3
allison 2.3, 2.6, 2.9, 3.0? 23:07
beyond?
japhb 2.3 - 2.9 I would think ... it will be useful for NCI performance.
So given pmichaud, 2.6 or 2.9
Coke default to later.
allison let's say 2.9
okay
pmichaud wfm
Coke (don't push anything sooner than it has to be.)
allison constant data structures in pir/pbc? 23:08
what's the task?
japhb Coke, +1 on that
23:08 moritz left
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
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?
right 23:09
Coke ... I'm doing this in partcl.
pmichaud (chromatic++ has potentially improved this recently, I haven't had time to test/evaluate)
Coke (using the .const sub trickery, which chrom... what pmichaud said)
allison sounds like a good task
particle1 is this rakudo *-important?
pmichaud particle1: it's not a critical need, no.
chromatic Huge improvements for startup time potential with this and improved freeze/thaw.
japhb But good for startup performance.
pmichaud right
allison good ticket, is it a roadmap task? 23:10
chromatic Potential runtime performance improvement as well.
2.3.
It's a broad goal, but it's definitely an area where a few specific tasks can pay off.
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.
allison how complex is it? 2.3 is getting top-heavy
japhb 2.3 or 2.6. I'm not sure startup time is as important as runtime, but certainly nice to have
pmichaud in the general case, it can be very complex.
especially if the constants have to refer to other hll-specific PMCs or data structures
chromatic Fixing EH isn't too difficult; a couple of days, if it goes well.
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 *
japhb So easy sub-cases for 2.3, and general "it just works" in 2.6?
particle1 2.6: +1
allison better load_bytecode semantics?
pmichaud I have doubts we'd make a 2.6 target given other things taking place, but I"m okay with that.
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
allison when do you need it? 23:13
pmichaud (thinking)
"need" is a hard question. we can work around it with various out-of-band communications mechanisms... that's what we do now
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
the methods in the namespace bug, timing?
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.
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.
allison okay, will put it down for 2.0
Whiteknight what needs removing? can only allison do it?
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.
allison it is a bug, there's not doubt about that
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.
allison subroutine leave semantics/exit handlers?
timing?
(definitely a good feature to add)
chromatic Utility to Rakudo? 23:18
pmichaud high
allison needed for April?
pmichaud we can work around the lack of it, with performance cost
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
allison would using properties work as a start?
pmichaud and being able to schedule tasks to run on scope exit
chromatic Or a bytecode-constant EH attached to a Sub?
allison or, the idea of storing them in the context?
or the Sub itself?
okay, let's put this down for 2.3, and discuss soon 23:20
pmichaud wfm
Whiteknight attaching const PMCs of all types to the sub they are defined in might be nice
allison exception handlers/inferior runloop?
what's needed and when is it needed?
pmichaud (btw, currently we're also exploring the possibility of using pushaction/pushmark/popmark for exit handlers.)
chromatic Lorito, for a real fix. There may be a workaround.
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?
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.
chromatic Depends on the invasiveness, efficacy, and usability of the workaround.
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?
chromatic +1
Whiteknight +1
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
pmichaud right
allison Lorito?
chromatic Not 2.3.
allison is 2.9 reasonable, and soon enough?
chromatic I think it has to be *the* 3.0 task.
pmichaud chromatic: +1
allison with work going in beforehand
chromatic Definitely. 23:24
allison yes, that's sounds good
benchmarks?
pmichaud I'd be skeptical of placing lorito before 3.0.
allison more of an ongoing task
pmichaud (but we could have various lorito-related developments before then.)
allison yes, and it's important to remember that lorito isn't needed for Rakudo *
particle1 not roadmap
pmichaud I don't see benchmarks as being a roadmap task.
chromatic Agreed.
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
core libraries/plumage?
pmichaud benchmarks might be a dependency for other performance tasks, yes.
japhb Plumage needs to be a lot more there for 2.3
I think it should have fully replaced proto for Rakudo use by then
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.
pmichaud, that's news to me
(and not pleasant news)
pmichaud unless plumage expects to be the standard for Perl 6
particle1 address plumage later, then
allison okay, more discussion to happen there (later) 23:27
particle1 discuss offline, and modify roadmap at next review if necessary
japhb pmichaud, OK, we need to discuss in #parrot then
pmichaud let me rephrase what I said above
I don't think there will be *one* module handler for Perl 6. Or Rakudo.
allison plumage definitely will handle perl 6 modules, because it handles all languages
but, I suspect the Perl community will also have CPAN
in whatever form CPAN grows into
(that is, Plumage can pull from CPAN, CPAN6 or whatever) 23:28
japhb allison, yes
pmichaud that's fair enough. But that definitely won't happen before April. :)
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
allison reasonable, since it is language agnostic
okay next (trying to zip through here)
multiple versions of Parrot libraries installed
pmichaud it's not just CPAN we're talking about, but also python modules, ruby gems, etc. etc.
allison is that "installed and loaded"? or just "installed" 23:30
pmichaud: yes, that's what we want
pmichaud Perl 6 will require "installed and loaded"
japhb allison, Perl 6 requires being able to ... pmichaud++
allison we have no answer to that at the moment, when do we need an answer by?
2.3?
pmichaud no way :)
allison 2.9?
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
particle1 3.3
allison then let's not schedule it until you need it
3.3 sounds good
pmichaud I'd prefer "unscheduled"
japhb I know it to be necessary, and will need to support it, but Rakudo will likely be the driving force
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.
allison or, just a general feature request?
pmichaud I wouldn't have it as a roadmap task, no.
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
allison okay, marked as no roadmap
Improved NCI/FFI
is this critical for Rakudo *? 23:33
pmichaud not critical for Rakudo *
allison then definitely not 2.3
pmichaud however, a lot of Perl 6 and other folks will be asking about it shortly thereafter :)
allison suggestions on timeframe?
japhb But I'd like to see that sooner rather than later. 2.6 would be really my preference
pmichaud because that's always been one of Parrot's supposed advantages
allison (definitely a good task)
chromatic We can start for 2.6, but a lot of the benefits will come from Lorito.
allison okay, will mark 2.6 for now, review later
self-hosted tools? 23:34
particle1 after lorito
pmichaud totally not a priority from my perspective :)
japhb A long term goal, not a roadmap task
allison that's currently on the roadmap for 3.0 (eliminate Perl 5 dependency)
pmichaud what's the advantage of self-hosted tools, and is working on that a greater advantage than resolving some of our other tasks?
japhb I think it's nice for people to jump in and work on, but no core person should consider it their main goal
allison (marked no rodmap) 23:35
switch from SVN to GIT?
particle1 pmichaud: no reliance on perl, better portability (maybe)
definitely no switch to parrot infrastructure before rakudo *. we have enough distractions
pmichaud particle1: I think we have enough distractions through 3.6 :)
particle1 i don't think infrastructure items are roadmap-worthy in general
chromatic I don't want to consider that before 2.3.
allison agreed, not a roadmap item
pmichaud switch from svn to git: no vote here
japhb I vote for "as soon as the rest of you let us" 23:36
:-)
allison (I'm against git anyway)
pmichaud actually, I have a counter-vote
chromatic Me too, but I don't want to let it get in the way of 2.3.
allison but, we don't care about that now
pmichaud if switching to git, either do it for 2.0 or not until after 2.3
japhb After 2.3 then
allison we only care about "when do we raise it again"
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.
japhb Nothing gets in the way of 2.0
pmichaud I don't want to be rewriting my build scripts in February or March.
(or April)
allison Algorithmic optimisations of PIR code? 23:37
what's the task, and when do we need it
Whiteknight that's dependent on PIRC
chromatic It can be PAST-level; no PIRC necessary.
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
chromatic++
particle1 in the meantime, we have dukeleto's git mirror of the parrot svn repo.
Whiteknight PAST-level optimizations would be nice too, but not enough
japhb Whiteknight, what about POST?
Whiteknight we need all the optimizations across all abstraction layers that we can get
chromatic I have my doubts that I'll have time to work on it until the 2.6 era.
Whiteknight PAST, PEST, PIST, POST, PUST, we can optimize them all 23:38
and more
chromatic (A Hague grant... well, I have some thoughts about that process as well.)
particle1 use tree-ssa on past/post
allison sounds like not a roadmap task
NotFound Whiteknight: Proust, even.
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
chromatic I'd like to see it for 2.6 actually.
particle1 not roadmap, it's a way to achieve performance
chromatic It's a feature for PCT. 23:39
Whiteknight and performance is king
allison put it in as a ticket
japhb chromatic: +1
allison (we're half-way through the list and 9 minutes over)
japhb I can stay
allison but, we're nearly done with the new items
last one is Parrot+HLL TapTinder/Buildbod
particle1 time is valuable, let's plow through. 23:40
Whiteknight "buildbot"?
particle1 this is infrastructure
allison then we can do a quick pass on the old items pushing them out
chromatic Infrastructure.
japhb allison, Plumage being able to support a "smoke" action now should help make that easier.
allison so, not roadmap?
particle1 Whiteknight: gives insight on failing parrot builds
Coke no.
Whiteknight particle: I know what smoke is, Pointing out what I think is a spelling error 23:41
allison okay, onto the old items
documentation translation infrastructure
currently 2.6, move to?
3.6?
kid51 +1
japhb +1
allison it doesn't seem like translated documentation is a large obstacle to involvement at the moment 23:42
particle1 not roadmap
it's long-term
kid51 Yes, and I like coke's earlier point of no roadmap item before its time
allison I'll go with that
async I/O?
pmichaud asynch I/O: not critical for Rakudo*, but (like NCI) people will undoubtedly start asking about it shortly after Rakudo*
allison who needs it and when?
pmichaud i..e, as soon as Rakudo* is out, people will start asking for it. 23:43
particle1 within a year from Rakudo *
pmichaud (and Rakudo will likely say "Parrot doesn't have it yet.")
allison currently 2.6
change?
Whiteknight AIO is high on my list of personal interests
japhb Not 2.3, but 2.6-3.0 at the latest
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.
allison how about 2.9?
japhb pmichaud, exactly
allison (2.6 is heavily loaded)
particle1 2.9: +1
Whiteknight It's going to be intertwined with concurrency improvemets though 23:44
japhb I'm fine with 2.9
"I like Ike"
Whiteknight I don't think we can do AIO without at least some fixin' on threads
allison vtable swap?
Whiteknight: yes, good point
japhb Whiteknight, and will be hard without some improvement to callbacks handling WRT threads as well
allison vtable swap isn't critical for Rakudo *, which pushes it out a bit
Whiteknight what is vtable swap?
pmichaud Whiteknight: what about things like select(), is that available now?
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.
Whiteknight pmichaud: No select() that I am aware of now, at least not done well
pmichaud: could be added relatively quickly, I think
Tene It's been on my tasklist for a long time, but never got around to it.
pmichaud select() is more what I'm thinking people will want -- to write servers and the like.
I agree that impacts threads as well, though.
sorry, back to vtable swap :)
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.
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)
allison chromatic: can we close the ticket?
particle1 crosstalk on #parrot, please?
chromatic Sure.
allison chromatic: noted
pirc? 23:47
particle1 can we do pirc and lorito in the same year?
Whiteknight yes
allison as chromatic noted earlier, nice, but not critical for Rakudo *
Whiteknight I don't think PIRC is too far off, in terms of development effort
pmichaud is there a purpose to doing pirc separate from lorito?
allison do we need pirc once we have lorito?
chromatic Depends how much of Lorito lands and when.
particle1 3.0 23:48
pmichaud can we live with imcc until lorito lands ?
allison is pirc a roadmap item?
particle1 we'll pull the pirc/lorito deps apart later.
chromatic IMCC will continue to be painful the longer it lasts.
allison I'll note "bundle with lorito task"
chromatic There are some intractable bugs in IMCC.
pmichaud bundle +1
Whiteknight even with lorito, we aren't getting rid of PIR/PASM
mikehh we need to get away from IMCC asap
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
allison I suspect so too
okay, put at 3.0 with lorito
particle1 we'll have nine months after 2.3 to look at pirc/lorito/post->pbc etc
allison can merge if needed
pmichaud particle1: nine months is not that long. 23:50
allison bytecode generation from post?
Whiteknight pmichaud: it's just a difference in generated code
pmichaud nine months ago, we release 1.0, and not a lot of new features have landed since then.
particle1 pmichaud: agreed, but we can't do it before 2.3
chromatic I saw the POST->PBC proof of concept.
I don't know how much work remains, but I doubt it'll help Rakudo substantially.
allison not critical for 2.3 23:51
3.3?
or non-roadmap?
particle1 after pbc<->pasm
pmichaud POST is another area that I think may be substantially affected by lorito, fwiw.
allison agreed
3.9?
pmichaud 3.6.
assuming lorito is 3.0.
allison marked 3.6
pmichaud (3.9 seems too far away from lorito)
allison increased portability? 23:52
is it a roadmap task?
particle1 no
kid51 Too vague
allison it seems to be happening naturally anyway
particle1 maybe a milestone target later
chromatic Maybe specific targets later.
particle1 (like rtems)
allison we can add it back as we have specific tasks
cross-compile configuration? 23:53
particle1 cross-compile is related to portability, drop it
allison PASM review?
kid51 The TT for "increase portability" translates to "recruit platform maintainers"
allison kid51: yes
when do we need PASM refinements as a plain english form of bytecode 23:54
2.6 seems too early
particle1 before users can debug pbc effectively.
3.6?
pmichaud I'd leave it off the roadmap until someone identifies it as a pain point 23:55
particle1 wfm
chromatic +1
allison yes, 3.6 is good, for the same reasons as the POST->bytecode
mikehh +1
allison we already have painpoints
in debuggin
g
review bytecode implementation? 23:56
are there still aspects of the current bytecode spec that aren't implemented?
or, have we caught up with that?
chromatic Seems like an airplane-time task. 23:57
NotFound I think the string enconding is still not stoted in the pbc.
allison drop from roadmap?
particle1 drop review tasks
pmichaud it's generally not on my radar, no. I'm not sure where bytecode compatibility fits in our roadmap.
(i.e., backwards-compatible pbc)
allison that's currently on for 2.0
but, we'll review that when we get there 23:58
chromatic Maybe so, but we haven't worked on it.
allison (10 lines or so)
new jit?
particle1 jit before lorito?
allison currently 2.6
3.0 seems awfully late for restoring a JIT
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.
particle1 yep, other optimizations
allison 3.0?
3.6?
4.0?
chromatic Let's try 3.0.
particle1 3.3, shortly after lorito
japhb 3.0-3.6

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!