PDS Dec 05 2300 UTC !!! | Priorities for this week: PDS, Google Code-In, MappedByteArray test&merge, fix `make cover`, GC algorithm review | Don't forget to post closed tickets in your report. | Note: This channel is only for our Tuesday status meetings (at 20:30 UTC); you probably want #parrot instead. | irclog: irc.pugscode.org/
Set by moderator on 2 December 2010.
01:21 whiteknight joined 01:49 bacek left 02:57 contingencyplan left 03:58 spinclad joined 04:02 whiteknight left 04:43 lucian left 10:33 contingencyplan joined 11:54 contingencyplan left 12:13 lucian joined 13:16 whiteknight joined 14:15 Infinoid joined
Infinoid *lurk lurk* 14:15
14:34 gg411 joined 14:38 PacoLinux joined 14:41 PacoLinux left 14:58 whiteknight left 15:00 whiteknight joined
cotto a note for the PDS later today: We won't be talking too much about Lorito, primarily because there's not much new. If anyone has questions, please do send them to parrot-dev or post them on LoritoDesignQuestions on the wiki. 15:09
I'll be meeting with allison and chromatic later this week to get a brain dump of Lorito as a starting point, at which time I'll get the other architecture team members involved and make sure that everyone who cares can easily find out where the design is at. 15:11
I'll probably be a bit late (eta 10-15m after the start of the meeting), but I will be here. 15:12
15:55 gg411 left, gg411 joined 16:53 TimToady left, sorear left 17:10 TimToady joined, sorear joined 17:19 sorear left, TimToady left 17:30 sorear joined, TimToady joined 17:46 kid51 joined 17:50 kid51 left 18:15 contingencyplan joined 18:27 lucian left 18:28 lucian joined 18:54 TimToady left, sorear left 19:00 TimToady joined 19:06 TimToady left 19:26 gg411 left 20:08 bluescreen left, bluescreen joined 20:13 gg411 joined 20:20 sorear joined, TimToady joined 20:42 plobsing joined 20:51 AndChat| joined, AndChat- joined 20:54 gg411 left 20:56 AndChat- left 20:57 AndChat| left 21:56 tcurtis joined 22:03 kid51 joined 22:54 chromatic joined 22:57 atrodo joined
kid51 Can people speak up as they enter the channel? 22:57
kid51 presente
mikehh been here for a bit
kid51 chromatic: Do you want to lead some part of the discussion (e.g., the retrospective)? 22:58
22:59 nwellnhof joined
atrodo Good $localtime ya'll 22:59
bluescreen hi everybody 23:00
mikehh greetings
chromatic I can do whatever's useful.
23:01 dukeleto joined
dukeleto hola 23:01
Util Hello
kid51 Is cotto here?
dukeleto is this the train to St. Louis?
mikehh said he woul;d be 10-15 mins late
kid51 So, my understanding of the overall agenda looks like this: 23:02
1. Review of project since last PDS.
2. Issues pre-scheduled for discussion
dukeleto will drive until cotto shows up 23:03
kid51 ... which includes (per postings on parrot-dev):
a. whiteknight's presentation on new API
b. scheduling of PDSes during 2011 (whiteknight's and kid51's post); scheduling of topics during next PDS (Jan 29 or 30)
3. Any other business
How does that sound?
dukeleto kid51++
chromatic +1
mikehh +1
atrodo +1
dukeleto Shall we start with a review since our last PDS? When was our last PDS? 23:04
particle waves
kid51 I believe it was in April ... but the last one I remember well was 12 months ago.
My subjective impressions: 23:05
1. Best thing: we've maintained our monthly release schedule
2. 2nd best thing: We haven't fallen apart, which is always a risk for all-volunteer projects
dukeleto (not falling apart)++ 23:06
kid51 No significant breakthroughs, some regression, some forward movement.
Some have said, "Parrot is dying," but resurgence of activity since Pacific Northwest Parrot Developers Gathering in October has been encouraging.
Contributions from Google Summer of Code and Google Code-In participants also encouraging (though most GSOC contributions are as yet unmerged).
I can get more specific, but let's hear from others.
chromatic How about: 23:08
1) Performance improvements for Rakudo
2) GSoC and GCI
3) Git migration
Those are my top three, in no specific order. 23:09
kid51 Are we able to quantify #1?
dukeleto PL/Parrot happened since the last PDS, which embeds Parrot in PostgreSQL. It is one of our few embedding projects that is alive currently. 23:10
chromatic Rough guess on #1, perhaps 40%, perhaps a little more.
dukeleto It depends on the benchmark, but the trend is that stuff is getting faster
chromatic We haven't reached The Realm of Dramatic Improvements, but we've steered our airship that direction. 23:11
Util My top one:
1. Our stability and support of one of our client languages (Rakudo) has been sufficient to allow them to ship a packaged distro (R*).
tcurtis is here.
dukeleto I think that Parrot is one of top open source projects that is using GSoC and GCI effectively to get new developers involved. That bodes well for the future health of our community. 23:13
The formation of Parrot Teams is also something new since the last PDS.
kid51 Others who haven't spoken yet? particle? atrodo? tcurtis? mikehh?
tcurtis git++ is all I particularly have to say, since I've not been paying as much attention to Parrot as I'd have liked in the last few months. 23:15
particle parrot foundation had its first board transition. much work remains to make pafo a viable entity.
dukeleto I think the amount of parrot development has increased since our git migration. I will try to get some stats about that. 23:16
atrodo I agree, git seems to have really helped contributions
dukeleto Yes, I am concerned about the current state of PaFo. We will be getting legal advice early next week about what to do about it.
mikehh we have had a gradual improvement in testing, but still need a lot more coverage
gc is getting better but needs more 23:17
git has made a lot of things easier to do
kid51 With respect to garbage collection: whiteknight has said, "It's going to get worse before it gets better" 23:18
Was that a valid assessment?
dukeleto mikehh: glad to hear it. It was a lot of work to do the git migration, but it seems to have been worth it.
kid51 Is it starting to get better?
dukeleto kid51: I would say yes.
whiteknight it already is worse. it is currently getting better 23:19
23:19 jnthn joined
kid51 dukeleto: Can you elaborate? (I concede it's over my head.) 23:19
cotto ~~
mikehh we are moving gradually to a generational approach, but it not all there yet 23:20
dukeleto cotto: you are driving now. I took the wheel while you weren't here.
cotto I need to backscroll
give me a coup[le minutes
whiteknight GSoC was a big success this year. GCI is only part way over, and is way exceeding my expectations 23:21
dukeleto kid51: i am far from the best to explain GC improvements, but we have been improving our GC API and optimizing datastructures, making structural improvements to how GC is related to other subsystems
whiteknight We are having trouble keeping up with the students, not the other way around as we expected
dukeleto whiteknight: yes, GCI is more intense than I expected. We have insanely smart kids interested in Parrot. And that is pretty awesome.
cotto gci is amazing so far. Some submissions are lta, but most are solid. 23:22
kid51 I agree about GCI. But my impression is that much GSOC code remains unmerged.
lucian kid51: that tends to be common (in other projects as well) 23:23
Util Is there a wiki page or master list of unmerged GSOC code?
cotto gsoc produces code that naturally takes longer to integrate
whiteknight kid51: yes. The problem with GSoC is that many projects are exploratory and aren't necessarily what Parrot wants
so some things need to be evaluated after they are complete (like NFG and Threads)
cotto I'd consider whiteknight's old gsoc project a great success if only because it got him involved. 23:24
whiteknight the NFG work was very good, but represents a major shift
:)
cotto same for tcurtis, though I have high hopes for his code too
kid51 Would we want to change our approach to working with GSOC participants in the coming year at all?
whiteknight kid51: how so? 23:25
dukeleto kid51: some gsoc branches became external projects
kid51: gsoc_nci got merged, which was huge
whiteknight (I am all for doing things better, suggestions welcome)
dukeleto kid51: we have 2 other gci branches that have not been merged, i think
whiteknight gsoc_past_optimization really needs to be merged, I think. We all want it 23:26
kid51 Would we, e.g., want to have the students scope the projects a bit more tightly so as to increase chances of an end-of-summer merge?
whiteknight gsoc_instrument I would like to see merged too, but the reception is a bit more luke-warm
lucian kid51: (hope I'm not intruding) it might stunt projects
cotto whiteknight, that one is an issue of tuits. If I find them, I'll do my best to make it happen.
whiteknight a big "end of summer merge ceremony" of sorts might be a draw 23:27
mikehh whiteknight: that should fit in with your api stuff
kid51 lucian: no, you're not intruding at all
whiteknight cotto: I was waiting on the inclusion policy to mature before making a decision on it
particle i think a gsoc breakout meeting sometime before the org deadline next year is a good idea 23:28
cotto +1
dukeleto +1 to that
mikehh +1
kid51 particle When would we have to hold that meeting?
particle socghop.appspot.com/document/show/g...0/timeline
cotto kid51, can you start a parrot-dev thread? 23:29
whiteknight +1
particle mid-february?
cotto we can use doodle for scheduling
whiteknight I liked doodle very much for this meeting
cotto doodle++
whiteknight We need to advertise it better
cotto any further gsoc/gci thoughts?
kid51 Note that we have scheduling of PDSes for 2011 on our agenda for later in this meeting
whiteknight GCI: We need more project ideas! The students are eating them up 23:30
chromatic Failure to merge gsoc/gci projects soon after completion counts as a failure in my book.
whiteknight and we've received complaints that our projects aren't big enough
chromatic: on a case-by-case basis, maybe
lucian whiteknight: generational semis-ace gc! :)
s/semis-ace/semi-space/
whiteknight the definitely should not just be abandoned
dukeleto chromatic: a failure on the students or parrot developers, or both? 23:31
chromatic A branch which sits untouched for three months (crossing a deprecation boundary) is a risk and may require heroics to merge.
cotto chromatic, I agree. We should be more aggressive about merging as soon as we can.
wrt gsoc code 23:32
whiteknight so that means we might want to be more selective to weed out branches that aren't likely to be merged
again, NFG is the consumate example
cotto whiteknight, just what I was thinking
lucian from my experience, we (gsoc students) often are short on time after gsoc
whiteknight even when it was complete, Allison wasn't sure she wanted the result merged in
lucian upstream help with merging would be useful
whiteknight but then we risk having fewer students, if they can't find acceptable projects
lucian (depends highly on organisation and gsoc project)
23:32 lichtkind joined 23:33 lichtkind left
kid51 Suggestion: In later part of this meeting, we schedule upcoming Summits and (if my recommendation is accepted) start to pre-schedule issues for discussion at very next summit. 23:34
dukeleto All unmerged gsoc branches are not failures. Some are exploratory branches that will never be merged.
But we did fail to merge some gsoc branches, for sure.
kid51 Next PDS is likely end of January 2011 .... which will be just a few weeks before start of next GSOC round.
whiteknight that's a good time to regroup and discuss it
cotto kid51, that'll be a good time to mop up any issues we fail to discuss between now and then
kid51 We could ask duke and GSOC veterans to prepare a report for next PDS
dukeleto I think we can talk more about GSoC on parrot-dev and other #ps's. We should probably go to the next concern/question. 23:35
particle are there adgenda wiki pages for pds's? gsoc is a good january preliminary adgenda item
kid51 .. which should enable us to apply as soon as google opens the doors
particle curse you, fingers! *agenda.
whiteknight particle: agendas on the wiki might be a great idea
kid51 particle: For this one, we simply asked people to post to parrot-dev
whiteknight I was hoping more people would discuss it on parrot-dev, but that remains a very low-traffic list
cotto whiteknight, I'll follow up on that. 23:36
cotto is keeping a list
whiteknight cotto++
kid51 What other items do we want to discuss as part of the retrospective?
chromatic Things that didn't work out so well. 23:37
kid51 Yes. chromatic, can you identify one or two?
dukeleto Cardinal (Ruby on Parrot) is blocked on our (meta) object model. This blocks the implementation of many other HLL's as well.
23:38 bluescreen_ joined, bluescreen left
cotto I'm most disappointed that this has only recently been made known. 23:38
Tene cotto: It's been known for over a year.
particle i agree with tene
Tene I'm not sure what you're referring to by "only recently made known"
cotto Tene, among general parrot developers?
mop issues for cardinal and js
whiteknight cotto: it has been known, but hasn't been too heavily discussed
cotto ok 23:39
Tene cotto: I don't know how you define "general", but it's been discussed on IRC with several people, trac tickets have been filed, etc.
lucian cotto: it was certainly known, it's the reason why I didn't do a GSoC project on pynie :)
whiteknight js has been dead in the water for a long time. I don't think MOP is why, but it certainly doesn't help new people get moving on it
dukeleto cotto: it has been known for a long time, but no one had the time or tuits to fix it
cotto has been overruled ;)
particle iirc the idea was that jnthn was developing a new mop in rakudoland that would be ported to parrot
dukeleto But now many people see the importance of fixing it.
particle: that is indeed the plan
kid51 I certainly know little about metaobject model or problems therewith 23:40
particle i am not up to date with the status on jnthn's effort
dukeleto particle: jnthn's 6model work and 'nom' branch in nqp-rx are what we are planning to use as a baseline for a parrot implementation
jnthn particle: Still working on it.
dukeleto jnthn: ping?
chromatic I've been waiting for 1) free time for me and 2) jnthn to tell me "Hey, this is ready to explore in Parrot itself!"
jnthn particle: Fleshing out the design in the 6model repo and then porting bits to Parrot.
lucian i personally think particular care should be taken so that the MOP isn't specific to a certain HLL or a class of them
dukeleto jnthn: care to explain your MOP work for the mere mortal parrot developer?
23:40 diakopter joined
particle jnthn: is it at a point where a parrot port would be complete enough to be usable for 80% of cases? 23:41
dukeleto lucian: we are very aware of that. We want a MOP that any dynamic language can use.
whiteknight the current Parrot MOP is not complete enough to be usable for 80% of cases
so anything would be a huge improvement, especially in terms of memory usage and GC friendliness
jnthn particle: I've got a few important pieces I want to prototype yet, especially native type handling and meta-model events so we can keep caches coherent. 23:42
particle: Both of which will have some consequences on the current API, I expect.
particle can these tasks be parallelized?
it appers we have willing developers
jnthn Porting stuff to Parrot could certainly be.
particle *appears
dukeleto jnthn: how can parrot devs help you? I want to help, and a few others do as well.
jnthn: if you could teach us enough to be able to help you, that might make a Parrot port happen faster 23:43
jnthn So long as anyone working on that is aware that stuff may chance a decent bit yet.
kid51 ?
jnthn dukeleto: I need to write more docs, that's for sure.
dukeleto jnthn: yes please! 23:44
jnthn The slides linked from 6guts.wordpress.com/2010/10/15/slid...ymorphism/ are still one of the best things to read.
dukeleto jnthn: i have been reading your commits, but docs would shed much light
cotto jnthn, I'm interested in any ways that Lorito's design could help or hinder the mop implementation. I'd be glad to do a tuit exchange.
whiteknight jnthn: assuming everthing goes well and you have an army of minions to command, could you give a rough estimate of when you are planning to finish?
dukeleto didn't even know about the 6guts blog!
jnthn dukeleto: oh!
cotto dukeleto, it's a nice blog 23:45
needs more posts though
;)
jnthn whiteknight: It's *really* hard to give an estimate right now.
The last month or so I've been *way* out of things compared to how I wanted. 23:46
Partly heavy $dayjob, but muchly perpetual not-entirely-healthy.
From January I can be sure that $dayjob is a lot less heavy, and I cross my fingers that I shake off...whatever I have...
whiteknight jnthn: that's okay. I want to stress the point about minions to control though 23:47
cotto +1 to minions
kid51 minions++ means increase in bus factor!
dukeleto jnthn: we will be sure to update you with any changes in how Lorito will be implemented.
jnthn If there's interest, I can try to get a task list together.
diakopter is a 6model minion, but not on the mop.
dukeleto jnthn: yes please!
jnthn: pawn off the easy tasks on us, so we can learn what is going on
chromatic A general overview of the individual pieces and a task list would be very useful.
jnthn I don't know how aware Parrot folks are of JnthnNQP, btw.
kid51 is unaware 23:48
jnthn It's a fork of NQP in the 6model repo where I do my research-y things and then they gradually migrate back towards nqp-rx.
Of note, the nom branch.
cotto nom branch?
Infinoid Sounds delicious
plobsing new object model IIRC
jnthn plobsing: yes ;)
cotto I suspect it'll get a lot of eyes rsn. 23:49
jnthn One thing that I know *is* going to cause issues is that I made a bunch of assumptions in JnthnNQP about lexpad handling.
That are not true on Parrot.
dukeleto noms the nom branch
jnthn Of note, when you auto-close, you hit a "static lexpad".
dukeleto jnthn: documenting your assumptions will really help us
jnthn And whenever you instantiate a dynamic lexpad, it has the things from the static one in it by default.
So you can install stuff at loadinit time (or later, freeze a static lexpad instnace in the bytecode). 23:50
And it's there "by default" for each sub.
Having this would make a bunch of things in Rakudo easier for one.
But JnthnNQP depends on this working.
plobsing I think we could make that work with some hll-maps and a little work to serialization 23:51
chromatic I think we need to rethink lexical handling for closures.
jnthn plobsing: We can, afaict, fix *part* of it by dynamic PMC lexpads but not all of it.
Auto-close lives int he Sub PMC.
I'd rather not just go and sub-class everything when I think the current behavior is, well, useless.
chromatic: The 6model on CLR implementation has new_closure/capture_lex style things like we have on Parrot, but still manages to do the other bits I mentioned just fine. 23:53
I see them as at least somewhat orthogonal.
The good news is that for anyone who reads C#, there's a working implementation of what I want already out there. :)
chromatic Parrot's lexical handling assumes that there is only one good way of handling lexicals and ignores the other one that's also useful other times. 23:54
kid51 We started talking about MOP because we were talking about things we had not done well since last PDS. Are there other such issues we need to discuss in this part of meeting? 23:55
whiteknight I think that's a good overview
chromatic PDDs
jnthn kid51: Sorry if I hijacked things. It is getting kinda late here, so I have to go sleep in a little. So was trying to answer the questions while here. :)
kid51 No, jnthn it was great to hear from you! 23:56
cotto jnthn, it was an apropos hijacking
jnthn (around a bit longer still)
cotto clearly there's interest
dukeleto has to go soon as well.
plobsing IIRC, at last PDS, we intended to migrate to PIRC. we failed pretty hard in that respect. we're still stuck with bad, old IMCC.
cotto chromatic, agreed. We need to take a weed wacker to those.
kid51 We should work discussion of MOP into our next PDS 23:57
dukeleto kid51: +1 to making MOP an agenda item for the next PDS
and possibly #ps
cotto noted
kid51 chromatic: Can you elaborate on PDDs? (and I know whiteknight has some opinions on them ;-) )
mikehh how badly are the PDDs out of date?
dukeleto mikehh: some are pretty badly out of date 23:58
they mention PGE and don't talk about nqp-rx
chromatic They haven't been relevant in the calendar period since the previous PDS.
cotto we need both a cleaning of the stables and a different approach. It doesn't appear that writing them and then implementing them leads to accurate docs.
s/docs/pdds/
dukeleto cotto: i agree
kid51 cotto Suggestions?
cotto (or not in the way we've been doing it)
whiteknight they certainly don't get enough attention 23:59
chromatic It'd be nice at some point to suggest that we don't merge big features without accurate docs and tests.
cotto +50
mikehh +1
dukeleto cotto: i tell that to people all the time
whiteknight even if we brought up one or two at every PDS (assuming regular PDS's) that would be much better than we do now
particle like, at deprecation boundaries
cotto whiteknight, sure. Attacking them all at once is too daunting.

Powered by Cro and the Raku® Programming Language.

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

Thank you!