"Tuesday at 20:30 UTC"
Set by moderator on 20 September 2010.
01:32 kid51 joined
kid51 kid51's report 01:41
* Will attend only first half hour of #parrotsketch today: opening of Perl Seminar NY meeting season.
DONE
* Organized and conducted Pacific Northwest Parrot Developers Gathering in Portland, Saturday, Oct 16. See reports here: www.parrot.org/blog/17 or at planet.parrotcode.org.
* Working with dukeleto on TT #1824 to determine a machine's ipv6 capabilities. Opened tt1824_ipv6_configure branch for this.
* Added tests in t/steps/ for two config steps lacking them.
WILL DO
* After release, will resolve deprecation in trac.parrot.org/parrot/ticket/1785.
* Will post additional weblog entries on Pac NW gathering.
EOR
01:55 bluescreen joined 02:17 whiteknight left 02:24 kid51 left 05:48 cotto left, cotto joined 08:07 contingencyplan left 11:40 ilbot2 joined 12:48 bluescreen left 12:59 bluescreen joined 13:33 contingencyplan joined 14:50 NotFound joined
NotFound What I did (last month): 14:54
-parrot 14:55
* Almost nothing, absolute lack of time.
-winxed
* Minimal fixes
What I will do:
No plan, get myself updated.
16:11 PacoLinux joined 16:16 PacoLinux left 19:06 dukeleto joined
dukeleto will be on a flight during todays #ps, but I am +1 to the proposed parrot teams 19:06
I am willing to lead the community management team, if folks want me to do that.
19:21 pmichaud joined 19:22 atrodo joined 19:39 PacoLinux joined 19:52 tcurtis joined 19:59 mikehh joined
cotto #done: 20:01
- attended Parrot dev meeting/hackathon arranged by kid51++
- kid51++
- helped draft a new structure for Parrot development based on my interpretation of the consensus
- if you haven't, please take a look at trac.parrot.org/parrot/wiki/ParrotTeams
- brought dukeleto up to speed (mostly) on the Lorito plan
- synced again on the Git migration
- It's immanent. I'll send a message to parrot-dev and parrot-users when the schedule is set.
- The big remaining task is for dukeleto++ to get a date nailed down.l
- got psyched up about Lorito
- updated LoritoRoadmap, created PirateTodo (what's needed to make PIRATE the default pir compiler)
- got started on step 1: resurrecting make_hello_world_pbc.pir after plobsing++'s dynop_mapping changes 20:02
- the yaks are abundant and hairy
#to do:
- resurrect make_hello_world_pbc
- help with Git migration, if that happens this week
- profit?
#eor
q2q
20:03 kid51 joined
pmichaud my items for #ps: 20:08
1. Will there be a 2.9.1 release? eta?
2. Parrot overall performance seems to be heading in the wrong direction:
gist.github.com/634994
I'm doing more timings and will report more as I get them.
.end
20:09 moritz joined
Util # Done: 20:11
* Resolved post-2.9.0 build speed issue in Rakudo.
= 2.9.1 still needed.
# No plan until healthy.
# Blockers:
* Rhinovirus
.end
tcurtis I did nothing parrot related, and am not likely to have more tuits this week, unfortunately. EOR 20:16
mikehh What I did since my last report: 20:21
* building and testing parrot on amd64/i386, with gcc/g++
* some fixes
* branch testing and fixing
What I intend to do in the next week:
* testing and fixing
.eor
20:29 chromatic joined
chromatic Hello. 20:31
cotto hi
Util Hello 20:32
mikehh hi there
20:32 bacek joined
chromatic Let's review last week. What happened? 20:32
NotFound Hola 20:33
kid51 Pacific Northwest Parrot Developers Gathering
20:33 allison joined
kid51 2.9.0 Parrot release -- but Rakudo immediately reported problems 20:33
mikehh gerd++ got the release out nbut rakudo seems to have a problem
cotto do we want 2.9.1? 20:34
Util Ticket changes: 8 closed, 9 new, 1 reopened
mikehh I think rakudo does
chromatic -0 to 2.9.1.
moritz chromatic: any other solutions? 20:35
chromatic 2.10 comes out in a month.
kid51 As I just pointed out in #parrot, solving Rakudo's problems will come at expense of smaller-resource machines.
moritz we can't target that for the 2010.10 rakudo release
and 2.9.0 is not usable for rakudo.
mikehh 2.9.0 is a "supported" release
Util chromatic: so Rakudo should release targeting a non-release Parrot?
bacek ~~ 20:36
chromatic If someone else wants to release 2.9.1, go ahead.
I'm in no mood to do so.
cotto +1 to the release
bacek Simplest solution - gc_threshold should be 1/8 of phys memory
Util +1 to release
cotto bacek, can you reliably detect physical memory in a cross-platform manner? 20:37
bacek Proper - dynamically adjust it based on gc pause
cotto, no idea. That's why I didn't implement it.
chromatic I don't believe you can, unless you catch page faults yourself and hope the user has disabled memory overcommit.
bacek otoh, jvm do it somehow 20:38
chromatic Rakudo 2010.10 gets to decide if it wants to run on all machines or only run on some machines.
moritz it doesn't run on any machines I own. It only crawls. 20:39
Util Smaller-resource machines are important, but we just *broke* something for a client language,
and that takes priority in my mind.
chromatic I don't see the brokenness. I see slowness, but no brokenness.
moritz chromatic: taking about 4 times longer to build, and more than 25min *is* a form of brokenness
Util chromatic: at what degree of slowness would you consider it broken? 20:40
chromatic Broken is "doesn't build at all".
20:40 moritz left
chromatic -1 to shipping a Parrot release that does not build Rakudo at all on some machines. 20:40
kid51 chromatic: I think that the *immediate* situation is that any 'correction' will leave someone unhappy. 20:42
chromatic Exactly.
My preference is to make Rakudo work for as many people as possible. 20:43
Slow for everyone trumps not working at all for some.
20:43 jnthn joined
kid51 Going back to 256M (as is the case with the reversion) will make Parrot "unbearably slow" on my 256M phys mem box 20:43
pmichaud anyone know how long spectests take with 2.9.0?
I can try it on my system and see
jnthn Making Rakudo unbearably slow for those of us developing with it is just silly.
kid51 pmichaud: Yes, more data would be desirable. 20:44
pmichaud a 25+ minute compile is unworkable for me.
jnthn Right, same.
chromatic I have the compile down to 11.5 minutes with some tuning and a threshold of 32 MB.
kid51 OTOH, with the 256M setting in that file, on a small resource box *Parrot* takes so long to build that I didn't even *try* to build Rakudo
mikehh one of the problems here is that the gc subsystem is in a state of flux 20:45
cotto bacek, how quickly could you implement a dynamic threshold based on gc pauses?
pmichaud I'll try running a spectest on my box
but it'll be 30 minutes before the spectest can start :-)
chromatic I'd *love* to flip a magic switch and make everyone happy, but we can't, so let's do actual project management here and figure out our priorities.
bacek cotto, couple of days
chromatic We don't know of gc pause tuning will even work though. 20:46
and -1 to committing to ship *that* in a supported release.
On to concrete questions then.
1) Is it acceptable for Rakudo 2010.10 to say "This only builds on machines with at least 512 MB RAM"? 20:47
pmichaud I don't have a problem with that. I don't know how long 512MB RAM has been a requirement anyway.
jnthn I would suspect 1 was the case for 2010.09.
In which csae it's hardly a regression.
20:47 bluescreen left
pmichaud I know that 256MB RAM has long been considered "too small to build Rakudo" 20:47
kid51 pmichaud: 2010.07 Rakudo Star was the first point where I noticed that it would not build with 256MB 20:48
chromatic 2) Is it workable to plan to release a 2.9.1 with some GC tuning in the next couple of days, if it provides reasonable performance improvements?
pmichaud well, Rakudo's next release is Thursday. 20:49
I don't mind if we slip that a day or two.... but it's also important that there be a hold on other Parrot changes while 2.9.1 is being brought out
chromatic Right, that's #3.
3) How do we develop a 2.9.1 that's only the important tuning changes? 20:50
pmichaud my suggestion: afaict, nothing else has landed in trunk since the release, so just continue the hold a bit longer
bacek branch from 2.9.0?
pmichaud rakudo's build system doesn't handle branches
chromatic Branching seems safer to me.
pmichaud granted, that's not parrot's fault 20:51
but I'd hate to do something special for this one release, and then turn around have to do it all again when we move to git
but we'll adapt to whatever parrot chooses
chromatic There's no easy way to guarantee that something unintentional won't land on trunk from a well-meaning contributor who didn't get the news.
kid51 pmichaud: Can rakudo do a test run from the head of a Parrot SVN branch?
pmichaud kid51: we can always test rakudo against a branch, sure 20:52
kid51 We could then merge that back to trunk right away, then do 2.9.1 from there ...
pmichaud but getting --gen-parrot and PARROT_REVISION to work from a branch is going to require a ton of work
kid51 ... keeping an eye out for people (like me) who were planning to implement post 2.9 deprecations.
chromatic Do --gen-parrot etc need to work for users who download the tarball? 20:53
bacek ok. I can detect physical memory on posix systems. There is a way to do it on win32.
cotto It's less fun, but we can hold those off for a bit if needed
bacek++
pmichaud --gen-parrot doesn't need to work for people who download the tarball, no.
and --gen-parrot usually isn't needed for star releases either, which bundle their own copy of the parrot tarball
oh, wait
--gen-parrot needs to work for the *rakudo tarball*, yes.
if someone downloads their own parrot tarball, then no. 20:54
("tarball" was ambiguous there)
kid51 For reference, except for Util's reversion to src/gc/gc_ms2.c, there have been no commits to trunk since release 2.9.0 20:57
So, in principle, if Rakudo builds against trunk HEAD right now, that could be 2.9.1 (albeit at "my" (small resource box) expense)
chromatic Well the easiest thing to do is to release 2.9.1 as 2.9.0 plus that commit.
20:58 allison_ joined
pmichaud Rakudo builds against trunk HEAD now, yes. 20:58
kid51 must leave for perl user group meeting
20:58 kid51 left, bluescreen joined
chromatic We could still do a 2.9.2 for anyone who wants a super bonus fun time extra. 20:59
but Rakudo could use 2.9.1 and call that good.
cotto +1 if Rakudo's happy with that. We can use bacek's findings to develop a better long-term dynamic tuning solution. 21:00
bacek If we can wait with 2.9.1 for 24 hours and someone on win32 can help me, I can implement phys-mem-dependant gc_thresold tonight
chromatic I really don't want to hold up 2.9.1 and hope that trunk stays pristine and I don't really like the idea of putting that untested code in 2.9.1.
pmichaud My position is that Rakudo will react to whatever Parrot decides to do here. I'm not pushing for a specific outcome. I do think that having a 25+ minute build (and who knows how long spectest) for a "supported release" is going to look _really_ bad. 21:01
cotto I'd also rather give dynamic tuning more than 24h for testing.
pmichaud one might argue that the extreme slowness is an unacceptable change from 2.6.0, as well.
bacek cotto, it's not dynamic
chromatic Let's rephrase it then.
Any objections to doing 2.9.1 *right now*? 21:02
pmichaud no objection.
cotto +1
NotFound No objection
chromatic I can live with it as the least worst approach at the moment too.
Any volunteers to make it? 21:03
cotto I can 21:04
bacek +0.5 for release now 21:05
+1 to hold other commits for 1 day.
cotto just for clarification, this will be without the changes chromatic nopasted into #parrot?
chromatic Yes.
All it is is 2.9.0 plus r49583. 21:06
pmichaud (plus whatever changes are needed to changelog/news/etc, I suspect)
cotto ok
mikehh took me 7 min 30 to build rakudo at r49583 21:07
chromatic Anything else on this topic? 21:08
Any value to a 2.9.2 branch with tweaks to improve the situation on smaller machines? 21:09
pmichaud I would call the branch something other than 2.9.2 21:10
cotto -.5. I'd rather just put those changes through the normal process.
pmichaud what cotto++ said
bacek -1 for 2.9.2 branch
chromatic Knowing that 2.9.0 will last as "supported" until 3.0?
pmichaud is it much different for 2.6.0 to 2.9.0, ooc? 21:11
I'm guessing "yes" based on kid51's statements in TT #1829. 21:12
chromatic Exactly.
If that's an acceptable decision to make for 2.9.x, that's fine, but the timing of making that decision seems awful to me. 21:13
pmichaud anyway, I presume you meant that 2.9.1 would last as supported until 3.0. That wouldn't bother me, but then again I'm not the one that 2.9.1 negatively impacts.
afaict, nobody really realized that rakudo was 5x slower with 2.9.0 until after it released. And it's only been slow since Saturday. 21:14
late Saturday, at that (Sunday for most of us)
cotto Do we have any idea how many distros will pick up 2.9.x vs 3.0 or 2.6? 21:15
pmichaud I don't.
chromatic We know RHEL will eventually upgrade to Parrot 0.x though. 21:16
cotto *rimshot*
allison Debian/Ubuntu will pick up 2.9, because I push it to them
pmichaud allison: so, 2.9 would be in the 11.04 release?
chromatic Does 3.0 come out before the feature freeze for Narcissistic Narwhal? 21:17
allison the other distros depend on the packagers who've volunteered for parrot
pmichaud: actually, it'll be 3.0 in 11.04
pmichaud allison: okay.
allison pmichaud: but I make sure they get every supported release, even if it'll be passed before the next distro release
10.10 has 2.6, BTW 21:18
chromatic Proposal: add to the 2.9.1 release notes "If you run out of memory on a box with < 512 MB physical RAM, please report it to us."
If *real users* and real workloads demonstrate this problem, *then* we bring up the possibility of a 2.9.2 for them. 21:19
pmichaud what does "out of memory" mean here, though?
I thought it was evidenced by extreme slowness.
chromatic Swap death.
cotto chromatic, good idea
pmichaud I would say we need to mention that explicitly, then.
chromatic Sure thing. 21:20
If we have moved to Git by then (let's hope), then making a branch for that with cherry-picked 2.10 tunings and changes is simpler.
allison chromatic: sounds good (2.9.2 only if needed by real users)
pmichaud +1 21:21
chromatic Any objections to that plan?
(with the caveat that we need to resolve kid51's ticket as soon as possible)
cotto +1 21:23
pmichaud no objections
chromatic Any other discussion on this subject?
cotto I'm going through the release process now. It shouldn't take too long. 21:24
chromatic Thank you.
Let's move on.
Goals for this week, besides "What's going on with the GC?" 21:25
mikehh deprecations?
cotto The "drink beer and talk about Parrot" goal was a great success.
chromatic noted
mikehh the generational_gc branch needs a lot of tuning 21:26
NotFound Success at beer drinking? 21:27
chromatic Success at project governance ideas.
allison some of both :)
chromatic cotto, do you want to explain? 21:28
cotto Sure. That covers one of my questions.
bacek Speaking of GC - I do need fresh eyes on ge_gc branch. 21:29
chromatic I hope to get to gen_gc shortly.
bacek It's passing tests since yesterday (modulo RO tests)
cotto At the meeting last Saturday, we discussed a new way of structuring Parrot development. I wrote up my interpretation on ParrotTeams on the wiki. What do feedback and suggestions do you (yes, you) have?
trac.parrot.org/parrot/wiki/ParrotTeams
pmichaud to me, it almost feels overly structured.
but that will depend on how it ends up working in practice. 21:30
bacek +1 to pmichaud
cotto I'm interested in seeing how it works after colliding with reality.
allison there were two goals in tension that cotto nicely integrated into that plan:
one was making sure there was someone with personal responsibility for each key task 21:31
pmichaud I will note that I had the same reaction to the original "roles and responsibilities" document that was created circa 2006 -- but in retrospect the r-and-r document was definitely beneficial (if only because it provided a framework, even though it was a framework we never used fully)
allison the other was making sure the bus factor on each task was higher than 1
and that people knew they could help out
mikehh I like the idea of a more structured approach, as long as we don't get too rigid about it 21:33
cotto We want to get away from everything being on a single person.
allison removing blockers, and increasing our tolerance unexpected interruptions for individual volunteers 21:34
cotto mikehh, sure. The idea is that teams will be responsible for making sure things happen, but they're not the only ones who can get work done.
chromatic We also want to make sure important tasks get done.
allison and, that anyone is free to volunteer for any team (or even for multiple teams)
if there aren't any objections, would like to start trying this out pretty quickly 21:37
we have candidates for all but one of the team leads, run through those now?
cotto sure
allison Architecture - cotto 21:38
Project Management - Jim Keenan
Community - dukeleto 21:39
Product Management - whiteknight
Quality Assurance - not yet assigned
thoughts, comments?
(volunteers for QA?)
chromatic QA seems more up Jim's alley
mikehh I am quite happy to be on the QA team, not sure I want to be team lead though 21:40
in fact I am pretty sure I don't want to be team lead 21:41
21:41 bluescreen left
mikehh same with Project Management 21:42
cotto We wouldn't force anyone.
mikehh cotto: :-} 21:43
cotto +1 to chromatic's sentiment
allison Jim could do both PM and QA if needed 21:44
partly, it's helpful to recognize "today I'm wearing my QA hat", etc
mikehh I am quite happy to assist in both areas
cotto If there's no separate QA team, it'd fall under project management
mikehh I think it's a good idea to have both 21:45
allison cotto: I like defining it as a separate team, even if it has the same leader for now
it helps with separation of tasks, and makes the opening clear if someone does want to step up for one or the other in the future 21:46
cotto true. +1
mikehh +1
allison one important note here, is that the Architecture Team lead takes on the current Chief Architect role/title 21:47
so while most roles are new, that one is a hand-off
with the expectation that I'll still be around and working on Parrot, but mainly helping cotto with transition and working on language implementations 21:48
this is something I've been talking about with various people off-and-on for a year now
and recognizes my more limited time availability with the new job 21:49
any concerns about the hand-off?
if any come to mind, feel free to contact me, cotto, or both on or off list 21:51
chromatic Shall we move to questions? 21:52
cotto a note 21:53
chromatic go ahead 21:54
cotto The new team structure reflects a new emphasis that we want Parrot to become a production-ready system, using the energy that people bring to the project not just to scratch their own itches, but to advance the state of everyday dynamic languages. 21:56
Lorito is a big part of this, and once the Git migration is done, chromatic, I and any interested developers will be expending more effort to make it a reality. 21:57
chromatic Any questions? 22:00
Let's wrap it up then. 22:02
22:08 allison_ left 22:19 atrodo left 22:21 PacoLinux left 23:48 whiteknight joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!