Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2010-10-19

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

All times shown according to UTC.

Time Nick Message
01:32 kid51 joined #parrotsketch
01:41 kid51 kid51's report
01:41 kid51 * Will attend only first half hour of #parrotsketch today: opening of Perl Seminar NY meeting season.
01:41 kid51 DONE
01:41 kid51 * Organized and conducted Pacific Northwest Parrot Developers Gathering in Portland, Saturday, Oct 16.  See reports here:  https://www.parrot.org/blog/17 or at http://planet.parrotcode.org.
01:41 kid51 * Working with dukeleto on TT #1824 to determine a machine's ipv6 capabilities.  Opened tt1824_ipv6_configure branch for this.
01:41 kid51 * Added tests in t/steps/ for two config steps lacking them.
01:41 kid51 WILL DO
01:41 kid51 * After release, will resolve deprecation in http://trac.parrot.org/parrot/ticket/1785.
01:41 kid51 * Will post additional weblog entries on Pac NW gathering.
01:41 kid51 EOR
01:55 bluescreen joined #parrotsketch
02:17 whiteknight left #parrotsketch
02:24 kid51 left #parrotsketch
05:48 cotto left #parrotsketch
05:48 cotto joined #parrotsketch
08:07 contingencyplan left #parrotsketch
11:40 ilbot2 joined #parrotsketch
12:48 bluescreen left #parrotsketch
12:59 bluescreen joined #parrotsketch
13:33 contingencyplan joined #parrotsketch
14:50 NotFound joined #parrotsketch
14:54 NotFound What I did (last month):
14:55 NotFound -parrot
14:55 NotFound * Almost nothing, absolute lack of time.
14:55 NotFound -winxed
14:55 NotFound * Minimal fixes
14:55 NotFound What I will do:
14:55 NotFound No plan, get myself updated.
16:11 PacoLinux joined #parrotsketch
16:16 PacoLinux left #parrotsketch
19:06 dukeleto joined #parrotsketch
19:06 * dukeleto will be on a flight during todays #ps, but I am +1 to the proposed parrot teams
19:06 dukeleto I am willing to lead the community management team, if folks want me to do that.
19:21 pmichaud joined #parrotsketch
19:22 atrodo joined #parrotsketch
19:39 PacoLinux joined #parrotsketch
19:52 tcurtis joined #parrotsketch
19:59 mikehh joined #parrotsketch
20:01 cotto #done:
20:01 cotto - attended Parrot dev meeting/hackathon arranged by kid51++
20:01 cotto - kid51++
20:01 cotto - kid51++
20:01 cotto - helped draft a new structure for Parrot development based on my interpretation of the consensus
20:01 cotto - if you haven't, please take a look at http://trac.parrot.org/parrot/wiki/ParrotTeams
20:01 cotto - brought dukeleto up to speed (mostly) on the Lorito plan
20:01 cotto - synced again on the Git migration
20:01 cotto - It's immanent.  I'll send a message to parrot-dev and parrot-users when the schedule is set.
20:01 cotto - The big remaining task is for dukeleto++ to get a date nailed down.l
20:01 cotto - got psyched up about Lorito
20:01 cotto - updated LoritoRoadmap, created PirateTodo (what's needed to make PIRATE the default pir compiler)
20:02 cotto - got started on step 1: resurrecting make_hello_world_pbc.pir after plobsing++'s dynop_mapping changes
20:02 cotto - the yaks are abundant and hairy
20:02 cotto #to do:
20:02 cotto - resurrect make_hello_world_pbc
20:02 cotto - help with Git migration, if that happens this week
20:02 cotto - profit?
20:02 cotto #eor
20:02 cotto q2q
20:03 kid51 joined #parrotsketch
20:08 pmichaud my items for #ps:
20:08 pmichaud 1.  Will there be a 2.9.1 release?  eta?
20:08 pmichaud 2.  Parrot overall performance seems to be heading in the wrong direction:
20:08 pmichaud http://gist.github.com/634994
20:08 pmichaud I'm doing more timings and will report more as I get them.
20:08 pmichaud .end
20:09 moritz joined #parrotsketch
20:11 Util # Done:
20:11 Util * Resolved post-2.9.0 build speed issue in Rakudo.
20:11 Util = 2.9.1 still needed.
20:11 Util # No plan until healthy.
20:11 Util # Blockers:
20:11 Util * Rhinovirus
20:11 Util .end
20:16 tcurtis I did nothing parrot related, and am not likely to have more tuits this week, unfortunately. EOR
20:21 mikehh What I did since my last report:
20:21 mikehh * building and testing parrot on amd64/i386, with gcc/g++
20:21 mikehh * some fixes
20:21 mikehh * branch testing and fixing
20:21 mikehh What I intend to do in the next week:
20:21 mikehh * testing and fixing
20:21 mikehh .eor
20:29 chromatic joined #parrotsketch
20:31 chromatic Hello.
20:31 cotto hi
20:32 Util Hello
20:32 mikehh hi there
20:32 bacek joined #parrotsketch
20:32 chromatic Let's review last week.  What happened?
20:33 NotFound Hola
20:33 kid51 Pacific Northwest Parrot Developers Gathering
20:33 allison joined #parrotsketch
20:33 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
20:34 cotto do we want 2.9.1?
20:34 Util Ticket changes: 8 closed, 9 new, 1 reopened
20:34 mikehh I think rakudo does
20:34 chromatic -0 to 2.9.1.
20:35 moritz chromatic: any other solutions?
20:35 chromatic 2.10 comes out in a month.
20:35 kid51 As I just pointed out in #parrot, solving Rakudo's problems will come at expense of smaller-resource machines.
20:35 moritz we can't target that for the 2010.10 rakudo release
20:35 moritz and 2.9.0 is not usable for rakudo.
20:35 mikehh 2.9.0 is a "supported" release
20:35 Util chromatic: so Rakudo should release targeting a non-release Parrot?
20:36 bacek ~~
20:36 chromatic If someone else wants to release 2.9.1, go ahead.
20:36 chromatic I'm in no mood to do so.
20:36 cotto +1 to the release
20:36 bacek Simplest solution - gc_threshold should be 1/8 of phys memory
20:36 Util +1 to release
20:37 cotto bacek, can you reliably detect physical memory in a cross-platform manner?
20:37 bacek Proper - dynamically adjust it based on gc pause
20:37 bacek cotto, no idea. That's why I didn't implement it.
20:37 chromatic I don't believe you can, unless you catch page faults yourself and hope the user has disabled memory overcommit.
20:38 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.
20:39 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,
20:39 Util and that takes priority in my mind.
20:39 chromatic I don't see the brokenness.  I see slowness, but no brokenness.
20:39 moritz chromatic: taking about 4 times longer to build, and more than 25min *is* a form of brokenness
20:40 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 #parrotsketch
20:40 chromatic -1 to shipping a Parrot release that does not build Rakudo at all on some machines.
20:42 kid51 chromatic: I think that the *immediate* situation is that any 'correction' will leave someone unhappy.
20:42 chromatic Exactly.
20:43 chromatic My preference is to make Rakudo work for as many people as possible.
20:43 chromatic Slow for everyone trumps not working at all for some.
20:43 jnthn joined #parrotsketch
20:43 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?
20:43 pmichaud I can try it on my system and see
20:43 jnthn Making Rakudo unbearably slow for those of us developing with it is just silly.
20:44 kid51 pmichaud: Yes, more data would be desirable.
20:44 pmichaud a 25+ minute compile is unworkable for me.
20:44 jnthn Right, same.
20:44 chromatic I have the compile down to 11.5 minutes with some tuning and a threshold of 32 MB.
20:44 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
20:45 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?
20:45 pmichaud I'll try running a spectest on my box
20:45 pmichaud but it'll be 30 minutes before the spectest can start :-)
20:45 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.
20:45 bacek cotto, couple of days
20:46 chromatic We don't know of gc pause tuning will even work though.
20:46 chromatic and -1 to committing to ship *that* in a supported release.
20:46 chromatic On to concrete questions then.
20:47 chromatic 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.
20:47 jnthn I would suspect 1 was the case for 2010.09.
20:47 jnthn In which csae it's hardly a regression.
20:47 bluescreen left #parrotsketch
20:47 pmichaud I know that 256MB RAM has long been considered "too small to build Rakudo"
20:48 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?
20:49 pmichaud well, Rakudo's next release is Thursday.
20:49 pmichaud 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
20:49 chromatic Right, that's #3.
20:50 chromatic 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
20:50 bacek branch from 2.9.0?
20:50 pmichaud rakudo's build system doesn't handle branches
20:50 chromatic Branching seems safer to me.
20:51 pmichaud granted, that's not parrot's fault
20:51 pmichaud 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
20:51 pmichaud but we'll adapt to whatever parrot chooses
20:51 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.
20:51 kid51 pmichaud: Can rakudo do a test run from the head of a Parrot SVN branch?
20:52 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 ...
20:52 pmichaud but getting --gen-parrot and PARROT_REVISION to work from a branch is going to require a ton of work
20:52 kid51 ... keeping an eye out for people (like me) who were planning to implement post 2.9 deprecations.
20:53 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.
20:53 cotto It's less fun, but we can hold those off for a bit if needed
20:53 cotto bacek++
20:53 pmichaud --gen-parrot doesn't need to work for people who download the tarball, no.
20:53 pmichaud and --gen-parrot usually isn't needed for star releases either, which bundle their own copy of the parrot tarball
20:53 pmichaud oh, wait
20:53 pmichaud --gen-parrot needs to work for the *rakudo tarball*, yes.
20:54 pmichaud if someone downloads their own parrot tarball, then no.
20:54 pmichaud ("tarball" was ambiguous there)
20:57 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 kid51 So, in principle, if Rakudo builds against trunk HEAD right now, that could be 2.9.1 (albeit at "my" (small resource box) expense)
20:57 chromatic Well the easiest thing to do is to release 2.9.1 as 2.9.0 plus that commit.
20:58 allison_ joined #parrotsketch
20:58 pmichaud Rakudo builds against trunk HEAD now, yes.
20:58 * kid51 must leave for perl user group meeting
20:58 kid51 left #parrotsketch
20:58 bluescreen joined #parrotsketch
20:59 chromatic We could still do a 2.9.2 for anyone who wants a super bonus fun time extra.
20:59 chromatic but Rakudo could use 2.9.1 and call that good.
21:00 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
21:00 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.
21:01 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.
21:01 pmichaud one might argue that the extreme slowness is an unacceptable change from 2.6.0, as well.
21:01 bacek cotto, it's not dynamic
21:01 chromatic Let's rephrase it then.
21:02 chromatic Any objections to doing 2.9.1 *right now*?
21:02 pmichaud no objection.
21:02 cotto +1
21:02 NotFound No objection
21:02 chromatic I can live with it as the least worst approach at the moment too.
21:03 chromatic Any volunteers to make it?
21:04 cotto I can
21:05 bacek +0.5 for release now
21:05 bacek +1 to hold other commits for 1 day.
21:05 cotto just for clarification, this will be without the changes chromatic nopasted into #parrot?
21:05 chromatic Yes.
21:06 chromatic All it is is 2.9.0 plus r49583.
21:06 pmichaud (plus whatever changes are needed to changelog/news/etc, I suspect)
21:06 cotto ok
21:07 mikehh took me 7 min 30 to build rakudo at r49583
21:08 chromatic Anything else on this topic?
21:09 chromatic Any value to a 2.9.2 branch with tweaks to improve the situation on smaller machines?
21:10 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.
21:10 pmichaud what cotto++ said
21:10 bacek -1 for 2.9.2 branch
21:10 chromatic Knowing that 2.9.0 will last as "supported" until 3.0?
21:11 pmichaud is it much different for 2.6.0 to 2.9.0, ooc?
21:12 pmichaud I'm guessing "yes" based on kid51's statements in TT #1829.
21:12 chromatic Exactly.
21:13 chromatic 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.
21:14 pmichaud 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 pmichaud late Saturday, at that (Sunday for most of us)
21:15 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.
21:16 chromatic We know RHEL will eventually upgrade to Parrot 0.x though.
21:16 cotto *rimshot*
21:16 allison Debian/Ubuntu will pick up 2.9, because I push it to them
21:16 pmichaud allison: so, 2.9 would be in the 11.04 release?
21:17 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
21:17 allison pmichaud: actually, it'll be 3.0 in 11.04
21:17 pmichaud allison: okay.
21:17 allison pmichaud: but I make sure they get every supported release, even if it'll be passed before the next distro release
21:18 allison 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."
21:19 chromatic 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?
21:19 pmichaud I thought it was evidenced by extreme slowness.
21:19 chromatic Swap death.
21:19 cotto chromatic, good idea
21:19 pmichaud I would say we need to mention that explicitly, then.
21:20 chromatic Sure thing.
21:20 chromatic 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.
21:20 allison chromatic: sounds good (2.9.2 only if needed by real users)
21:21 pmichaud +1
21:21 chromatic Any objections to that plan?
21:21 chromatic (with the caveat that we need to resolve kid51's ticket as soon as possible)
21:23 cotto +1
21:23 pmichaud no objections
21:23 chromatic Any other discussion on this subject?
21:24 cotto I'm going through the release process now.  It shouldn't take too long.
21:24 chromatic Thank you.
21:24 chromatic Let's move on.
21:25 chromatic Goals for this week, besides "What's going on with the GC?"
21:25 mikehh deprecations?
21:25 cotto The "drink beer and talk about Parrot" goal was a great success.
21:25 chromatic noted
21:26 mikehh the generational_gc branch needs a lot of tuning
21:27 NotFound Success at beer drinking?
21:27 chromatic Success at project governance ideas.
21:27 allison some of both :)
21:28 chromatic cotto, do you want to explain?
21:28 cotto Sure.  That covers one of my questions.
21:29 bacek Speaking of GC - I do need fresh eyes on ge_gc branch.
21:29 chromatic I hope to get to gen_gc shortly.
21:29 bacek It's passing tests since yesterday (modulo RO tests)
21:29 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?
21:29 cotto http://trac.parrot.org/parrot/wiki/ParrotTeams
21:29 pmichaud to me, it almost feels overly structured.
21:30 pmichaud but that will depend on how it ends up working in practice.
21:30 bacek +1 to pmichaud
21:30 cotto I'm interested in seeing how it works after colliding with reality.
21:30 allison there were two goals in tension that cotto nicely integrated into that plan:
21:31 allison 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)
21:31 allison the other was making sure the bus factor on each task was higher than 1
21:31 allison and that people knew they could help out
21:33 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.
21:34 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.
21:34 chromatic We also want to make sure important tasks get done.
21:34 allison and, that anyone is free to volunteer for any team (or even for multiple teams)
21:37 allison if there aren't any objections, would like to start trying this out pretty quickly
21:37 allison we have candidates for all but one of the team leads, run through those now?
21:37 cotto sure
21:38 allison Architecture - cotto
21:38 allison Project Management - Jim Keenan
21:39 allison Community - dukeleto
21:39 allison Product Management - whiteknight
21:39 allison Quality Assurance - not yet assigned
21:39 allison thoughts, comments?
21:39 allison (volunteers for QA?)
21:39 chromatic QA seems more up Jim's alley
21:40 mikehh I am quite happy to be on the QA team, not sure I want to be team lead though
21:41 mikehh in fact I am pretty sure I don't want to be team lead
21:41 bluescreen left #parrotsketch
21:42 mikehh same with Project Management
21:42 cotto We wouldn't force anyone.
21:43 mikehh cotto: :-}
21:43 cotto +1 to chromatic's sentiment
21:44 allison Jim could do both PM and QA if needed
21:44 allison partly, it's helpful to recognize "today I'm wearing my QA hat", etc
21:44 mikehh I am quite happy to assist in both areas
21:44 cotto If there's no separate QA team, it'd fall under project management
21:45 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
21:46 allison 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
21:46 mikehh +1
21:47 allison one important note here, is that the Architecture Team lead takes on the current Chief Architect role/title
21:47 allison so while most roles are new, that one is a hand-off
21:48 allison 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 allison this is something I've been talking about with various people off-and-on for a year now
21:49 allison and recognizes my more limited time availability with the new job
21:49 allison any concerns about the hand-off?
21:51 allison if any come to mind, feel free to contact me, cotto, or both on or off list
21:52 chromatic Shall we move to questions?
21:53 cotto a note
21:54 chromatic go ahead
21:56 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:57 cotto 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.
22:00 chromatic Any questions?
22:02 chromatic Let's wrap it up then.
22:08 allison_ left #parrotsketch
22:19 atrodo left #parrotsketch
22:21 PacoLinux left #parrotsketch
23:48 whiteknight joined #parrotsketch

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