Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2013-02-19

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

All times shown according to UTC.

Time Nick Message
00:15 bluescreen joined #parrotsketch
06:55 cotto joined #parrotsketch
10:00 xcombelle joined #parrotsketch
11:25 jlaire joined #parrotsketch
13:55 benabik joined #parrotsketch
14:21 bluescreen joined #parrotsketch
14:27 benabik joined #parrotsketch
14:49 benabik joined #parrotsketch
14:51 benabik_ joined #parrotsketch
15:09 bluescreen joined #parrotsketch
15:16 rurban joined #parrotsketch
15:27 contingencyplan joined #parrotsketch
15:35 benabik joined #parrotsketch
18:02 kid51 joined #parrotsketch
18:16 tadzik joined #parrotsketch
18:24 pmichaud joined #parrotsketch
18:34 dukeleto joined #parrotsketch
18:56 benabik joined #parrotsketch
19:11 atrodo joined #parrotsketch
19:14 moritz joined #parrotsketch
19:18 kid51 joined #parrotsketch
19:24 not_gerd joined #parrotsketch
19:26 * Util is pre-reporting
19:26 Util Done:
19:26 Util * Discussed Perl [56] futures with stevan and Liz at Perl Oasis.
19:26 Util Doing:
19:26 Util * Releasing Parrot 5.1.0 *today*. (First time as Release Manager)
19:26 Util - Failed to shepherd the release during the lead-up time, so some chaos in #parrot right now
19:26 Util * Improving Config probes for PCRE and libFFI on Darwin
19:26 Util Proposing:
19:27 Util * YAPC hackathon for Perl-NG (Parrot, NQP, Rakudo, Niecza, Moe, and p5-mop)
19:27 Util .END
19:27 moritz with YAPC, do you mean YAPC::EU or YAPC::NA?
19:29 Util YAPC::NA; Thanks, moritz!
19:30 Coke I hacked on sixparrot, doing mostly nonessential removals rather than performance boosting updates. Making sure that nqp/rakudo can run unchanged on the branch.
19:31 Coke brought coke/rm_pasm branch back from the dead. Can't merge it to sixparrot as is, because it requires nqp to know that the .pasm includes are now named .pir instead.
19:31 cotto I'll give it a few minutes for late reports (including mine)
19:32 * kid51 will run 'make test' and/or 'make fulltest' on any branch on request; no other report; am mainly involved with P5P these days; organizing NY Perl Hackathon in 12 days
19:34 cotto done
19:34 cotto * lots of discussion about a new direction for Parrot; see http://reparrot.blogspot.com/2​013/02/its-been-quiet_15.html for detailk
19:34 cotto doing
19:34 cotto * working on resurrecting p5-based ops2c, one of the two users of the obsolote nqp-rx
19:34 cotto * working in the ops2c-necromancy branch
19:34 cotto * Parrot itself is building fine with one test failure
19:34 cotto * haven't tested nqp/Rakudo yet, will do so before thinking about merging
19:34 cotto todo
19:34 cotto * finish ops2c-resurrection
19:34 cotto * look at profiler tests (other use of nqp-rx)
19:34 cotto * get rid of nqp-rx
19:34 cotto * excise any nqp-rx-exclusive code paths from Parrot
19:34 cotto eor
19:34 cotto any other slowpokes?
19:35 not_gerd me
19:35 cotto fire at will
19:35 not_gerd * started porting nci_thunk_gen.pir -> pl
19:35 not_gerd stopped because the subsystem goes away
19:35 not_gerd * resurrected whiteknight's eval_pmc branch
19:36 not_gerd * added --target=pbc to NQP/Rakudo (pending review)
19:36 not_gerd EOR
19:36 cotto thank you
19:36 pmichaud I'm present, nothing specific to report, may have to leave w/o warning.
19:37 allison * I've been removing useless MMD
19:37 atrodo * worked on removing nci from sixparrot, hopefully will push something soon
19:38 moritz * did some random sixparrot removal, a force push, and trying to keep parrot<->rakudo relations productive
19:38 moritz EOR
19:38 cotto Util: do you have any reservations about the release today?
19:39 cotto I don't believe that the instructions will need any changes since this would normally be a developer release anyway.
19:39 Util I am just unclear from the last hour of #parrot.
19:39 pmichaud Util: I'd say cut the release, don't expect any further last-minute updates.
19:40 pmichaud (just my opinion)
19:40 Coke Even if we were going to tag a release as supported on something other than the quarterly schedule, it probably wouldn't be this one.
19:40 pmichaud Coke is correct, I think.
19:40 cotto I'd really like to see not_gerd's changes, but I agree that it's too late in the cycle.
19:40 cotto so +1 to what pmichaud said
19:40 pmichaud cotto: those are going to take a lot of planning and coordination, sadly.
19:41 cotto How about now for planning?
19:41 Util OK, will release today; no merges allowed until after release.
19:41 cotto Util: great
19:43 cotto So the problem appears to be that not_gerd's changes are backwards-incompatible.  Is there a way to make a smooth transition so that nqp and Rakudo can update at will?
19:43 pmichaud not likely
19:43 pmichaud at least, not with a single backend vm stream
19:43 Coke pmichaud: do you have any positive steps we could take?
19:44 Coke or is this improvement going to die on the vine?
19:44 not_gerd I can refactor the eval_pmc Parrot changes into API additions and Eval PMC removal
19:44 pmichaud I'm still having to try to digest all of this rapidly
19:44 not_gerd merge of my NQP/Rakudo branches depends on new API, but not Eval PMC removal
19:44 not_gerd eg the latter could only go into sixparrot and not master
19:44 allison not_gerd, so add the new API, but don't remove the old Eval PMC?
19:45 pmichaud I have difficulty following the nqp/rakudo branch moves because they do a lot of cosmetic code refactor in addition to the core change
19:45 allison i.e. suppport both for a while?
19:45 Coke not_gerd: note that rakudo/nqp still have to build unchanged on sixparrot.
19:45 pmichaud and yes, sixparrot is part of the confounding change
19:45 Coke pmichaud: (cosmetic) well, that I'm sure can be cleaned up.
19:45 pmichaud Coke: I'm sure it can also; the fact that it's not clean is what is making it hard for me to give snap answers
19:45 not_gerd add new API now, remove Eval PMC from sixparrot ones the Rakudo/NQP changes land
19:45 not_gerd ^once
19:46 cotto s/now/after the release/
19:46 allison not_gerd: that seams reasonable
19:46 pmichaud it's also confusing because we have Parrot, Parrot 5.0.0, Parrot 5.1.0, and "sixparrot"
19:46 allison cotto: not right after the release
19:46 allison cotto: because it breaks nqp/rakudo
19:46 Coke sixparrot's goal, in my mind, is an experiment to see what we can rip out without impacting nqp+rakudo and see what, if any gains we get. that's all. If we have to change something in nqp+rakudo, then you can worry about it; before that, it's just a smaller parrot.
19:46 pmichaud so when someone says "remove Eval PMC"  I don't know where the change is coming.
19:47 allison pmichaud: maybe not at all
19:47 cotto Let's clarify sixparrot.
19:47 allison it seems entirely safe to add the new APIs, though
19:48 cotto I see it as something that only Parrot developers need to care about, and that once changes are proven there they'll be merged into master.
19:48 cotto with appropriate coordination with Rakudo
19:48 pmichaud cotto: that doesn't sound to me like Coke's version of sixparrot
19:49 cotto Coke: how do you see it?
19:51 Coke sounds pretty close to my version, yes. Remove things that rakudo doesn't need/isn't using. If we get something faster, consider merging stuff back.
19:51 pmichaud okay, I'm corrected then :)
19:51 Coke I've been attempting to avoid doing anything in the branch that breaks nqp or rakudo.
19:51 pmichaud I think for the time being we want to do anything in nqp/rakudo that breaks the branch, too.
19:51 allison me too, my requirement for every change is "rakudo must still pass all tests"
19:52 pmichaud *to avoid
19:52 Coke something like "rm_pasm" can't be part of it yet, because there's no backward compitable/transitional way to .include 'constants.pasm'
19:52 Coke (my proposed workaround there is to have any pasm includes automatically include the pir file instead.)
19:53 Coke at which point it shouldn't impact nqp/rakudo.
19:53 allison (actually, my requirement has been "rakudo must still pass all tests, in the same time or faster")
19:54 Coke I think eliminating unused code and removing a maintenance burden is still a win for the branch.
19:54 Coke but sure, anything that slows things down defeats the purpose.
19:55 Coke my blind hacking isn't going to speed anything up, just cut off things that nothing complains about.
19:55 allison that will make it easier to speed things up :)
19:55 Coke aye.
19:56 pmichaud Coke: I'm not sure that sixparrot is something that only Parrot devs need to care about... unless you're saying that NQP/Rakudo should go ahead and adopt changes that appear in Parrot master but perhaps break sixparrot...?
19:56 Coke PASM is probably one of the more complicated things I could rip out (there's still IMCC guts that could go along with it); Next big thing for me when I have time is trying to peel out the unused bits of objects.
19:57 Coke pmichaud: sixparrot is going to merge in changes from master, so I don't understand the question.
19:57 pmichaud sorry, that was meant for cotto.
19:57 pmichaud okay, works for me.
19:57 allison Coke: that would be great (lightening objects)
19:57 Coke if you suddenly start using something before it being deleted lands on master, yes, we have to add it back in to sixparrot.
19:57 pmichaud I feel like I'm being more confusing than helpful here, perhaps I should go.
19:58 Coke I want you to understand what's going on.
19:58 cotto +1
19:58 pmichaud Yeah, I'm having trouble following what's going on, that's for sure.
19:58 cotto especially as the community manager on the Rakudo side
19:58 Coke which is basically that we're trying to make things small, faster, better.
19:59 Coke but it's all experimental at this point. I imagine we're going to regroup in a few weeks to see what's gone, what's left that could be ripped out, where performance is, etc. nothing's going to land on master without more discussion.
20:00 benabik If Rakudo starts using something, then obviously isn't useful and should stick around.  :-)
20:00 benabik *it's
20:00 pmichaud okay, I think I understand that part about sixparrot, then.  Basically, from a Rakudo/NQP perspective we ignore the existence of sixparrot for now, then?
20:00 cotto pmichaud: The onus is on Parrot developers to inform Rakudo when there's a change that needs coordination.  Not breaking Rakudo without proper communication is a major goal.
20:01 Coke it would be great if some rakudo devs occasionally ran against --gen-parrot=sixparrot to keep us honest.
20:01 cotto You should be safe ignoring anything in Parrot that we don't ask you about.
20:01 cotto (in theory)
20:01 Coke I run it, but it's slow to test /everything/ every time I rip out 3 lines of code. ;)
20:01 moritz Coke: will try to do it
20:02 cotto it won't hurt to do so occasionally, like Coke said
20:03 pmichaud I need to reserve a topic slot to discuss API change/backward compatibility issues
20:03 cotto pmichaud: today or in general?
20:03 pmichaud either.
20:03 pmichaud it's with respect to the evalpmc changes
20:05 cotto If you feel like we've been able to effectively communicate the purpose of sixparrot et al, now's a good time to disucss the eval pmc changes.
20:05 pmichaud I'm fine with sixparrot, yes.
20:05 pmichaud After having a few minutes to think about it, I think there are two forms of backward compatibility that we have to be aware of.
20:05 pmichaud and the evalpmc changes are bringing the distinction to the foreground
20:06 pmichaud let's look at backward compatibility from a parrot perspective.  Removing the EvalPMC today would be bad, because it would cause existing nqp/rakudo to break.
20:06 Coke agreed.
20:06 pmichaud That's one form of backward compability -- Parrot doesn't want to introduce changes that cause existing rakudo code to break.
20:07 pmichaud however, there's another form, from a Rakudo perspective.
20:07 pmichaud let's say that we go with the plan that instead of removing evalpmc immediately, we first add the new API to parrot
20:08 pmichaud this gives Rakudo time to adapt "on its own schedule"
20:08 pmichaud however, as soon as Rakudo starts using the new API, it becomes incompatible with all of the Parrots that came before that API was available
20:09 pmichaud currently, Rakudo works with Parrot 4.10 or later.
20:09 pmichaud as soon as Rakudo switches to the new API (let's say it first appears in 5.2), then Rakudo only works with 5.2 or later.
20:10 Coke that seems to be the price of progress, no?
20:10 cotto Doesn't Rakudo already support detecting a minimum Parrot version?
20:10 pmichaud sure
20:11 pmichaud yes, it's the price of progress, and yes, we detect the minimum Parrot version.
20:11 Coke are you suggesting that there is a way around that issue, or that we simply need to note it, or that it poses an impasse?
20:11 pmichaud But every time we bump the minimum Parrot version, we reduce the "newness" of Rakudos that can appear in Linux distros.
20:11 pmichaud I'm simply saying we need to be aware of it, I think.
20:11 Coke as discussed on parrot, that's already over a year old.
20:12 pmichaud for debian testing, yes.
20:12 pmichaud not for debian unstable, or ubuntu.
20:12 Coke I think we need to make sure that tickets from packagers get priority treatment.
20:12 Util Could EvalPMC's replacement have a (additional?) API that is compatible with the current EvalPMC API?
20:12 Coke (for both projects)
20:13 pmichaud Util: I think that's an example of my first form of compatibility.
20:13 pmichaud In this case, we know that we want Rakudo to move to the new API, it's just that doing so ought to be timed when it will have the least impact to distro packaging
20:14 Util pmichaud: Right, I am asking if it is actually feasible at all. I am unfamiliar with the replacement.
20:15 pmichaud I think we want to go ahead and eliminate the old API asap.
20:15 Util OK
20:15 pmichaud If Parrot has one customer (Rakudo/NQP), let's not keep too many APIs around just for the sake of Rakudo/NQP.
20:17 cotto ok.  We need to be strategic with backwards-incompatible changes.  What's the best timing strategy?
20:17 pmichaud I don't know, unfortunately.  We should probably get with debian packagers to ask that question.
20:17 cotto allison: ^
20:18 pmichaud if we know in advance what versions of rakudo and parrot the debian packagers expect to be using for each of their releases, we can plan our changes accordingly.
20:19 pmichaud I think the other thing I'm trying to get to is a general understanding that Rakudo/NQP is fine with making backwards-incompatible changes, but that we can't always do it as soon as they're available.
20:20 allison ah, see, I'd go the other way, just tell us which versions to package
20:21 pmichaud allison: that sounds like a push-driven model, though, which leads to some bad lead times
20:21 allison debian packaging always sufferes from bad lead times
20:21 pmichaud right, I'm trying to ameliorate that somewhat
20:21 allison it's the nature of the beast, unfortunately
20:21 pmichaud I think it doesn't have to be
20:21 allison in my ideal world, Debian packages two releases per year
20:22 allison so, if I do Parrot 5.0 now
20:22 pmichaud are the dates of the debian package releases known?
20:22 allison I'd say as long as Parrot 5.6 and Rakudo 2013-6 are usable together, that's all we need
20:22 allison debian is on a 2 year release schedule
20:22 allison but merges from unstable to testing happen on-the-fly
20:23 allison wheezy is expected very soon now, so it'll be going out the door with 2012-01
20:23 allison no way of changing that
20:23 allison (wheezy is already in freeze)
20:24 allison Ubuntu could get Parrot 5.0 into the 2013.04 release
20:24 pmichaud ...yes, but which version of Rakudo?
20:24 allison it's not "automatic" at this point, since we're past auto-sync, but I can request it and get it approved
20:24 moritz pmichaud: 2013.02
20:24 allison which version of rakudo do you want?
20:24 allison 2013-01 would be my default
20:25 allison (same month as 5.0)
20:25 benabik joined #parrotsketch
20:25 pmichaud allison: why not a later version of rakudo, though?
20:25 allison it's a matter of timing
20:25 moritz there's no indication that 2013.02 will need a parrot 5.1 or newer
20:25 allison I'll really have to get it into Ubuntu in the next few weeks
20:25 moritz and 2013.02 will be out on Thursday
20:25 allison so 2013-02 is possible
20:25 allison but, that's probably the last one possible
20:26 moritz and fi you need to do updates to packaging, you can do it even before the release
20:26 pmichaud allison: this is kind of what disturbs me, that there seems to be an automatic "same month as parrot release" assumption
20:26 moritz *if
20:26 allison pmichaud: well, that's what you all told me a few years ago, so I've just stuck with it
20:26 allison as in, that's the only rakudo release I'm *sure* is compatible
20:27 allison but, things were a lot faster and looser back then
20:27 allison so, I'm happy to revise that "rule of thumb"
20:28 pmichaud allison: that's why we need to know the packagers timings/needs a bit better (more)
20:28 pmichaud Rakudo has been making efforts to remain compatible with the oldest Parrot version possible (because that's what you told us a while ago also :)
20:28 pmichaud but if packagers are just always going to use the version of Rakudo that came out contemporaneously with Parrot, there's not much point.
20:29 pmichaud (came out contemporaneously with whatever version of Parrot they've decided to package)
20:29 allison well, it certainly does make our lives much easier if we don't have to do a simultaneous package release of Rakudo and Parrot
20:29 allison those get tricky
20:29 allison If we can upgrade Rakudo packages, get those out
20:29 allison and then go back and upgrade Parrot packages, it's simpler
20:30 allison though, right now I'm wondering if Rakudo 2012.10 is compatible with Parrot 5.0
20:30 allison because the dependency problem is running the other way :)
20:31 pmichaud well, there's no question that when you change parrot, you have to rebuild the rakudo package to match
20:31 pmichaud parrot doesn't offer us bytecode compatibility.
20:31 allison pmichaud: at the end of the day, the important thing is just to establish a target version for Rakudo and Parrot that are compatible
20:31 pmichaud allison: yes, and since
20:31 pmichaud 20:25 <allison> it's a matter of timing
20:32 pmichaud that's why we really want to know which versions of each the packagers will want to use (and when to have them ready), rather than us just say "oh, here's the one you should be using"
20:32 allison yes, and the bytecode compatibility thing means we always have to do a rebuild on the rakudo packages when a new parrot package comes out
20:32 moritz and also the paths change
20:32 allison but, a rebuild is simpler than a source version upgrade
20:33 Coke can we have them wing us an email when it's decidin' time?
20:33 allison sure
20:33 Coke seems the best thing is to talk about it rather than try to setup dominos in advance.
20:33 allison for now, the next target is Parrot 5.0
20:33 allison and I'm open to suggestions on Rakudo
20:33 allison sounds like 2013-01 or 2013-02
20:34 pmichaud allison: and "why" is the next target Parrot 5.0?
20:34 pmichaud because that's the last one we labeled "supported", or because that's the most recent one that you can reasonably package and get into the stream?
20:34 benabik Didn't someone push changes to make Parrot not invalidate bytecode so often?
20:35 allison pmichaud: both
20:35 allison pmichaud: and at this point, it's unlikely that another Parrot release will be packaged for 3-6 months
20:36 allison pmichaud: probably closer to 6
20:36 pmichaud allison: if we had labeled today's release as the supported one, would you have chosen it instead?
20:36 allison pmichaud: the problem is, there's substantial lag in packaging
20:37 pmichaud how much lag is the question I'm trying to get to :)
20:37 allison pmuchaud: so, I was *planning* to get 5.0 into debian right after its release
20:37 allison but, it's still not in
20:37 allison and this happens a lot
20:37 allison Parrot/Rakudo come out with a new release before the last one is into Debian
20:37 rurban benabik: I did
20:37 allison and then the question is "do we chuck all that work and move to the new new release?"
20:37 allison or "do we go ahead with what we've got?"
20:38 allison if we try to aim for every monthly release, we just end up thrashing endlessly
20:38 pmichaud I'm thinking we can avoid those questions if we know when things are likely to go into debian
20:38 allison so, we pick a point, and follow that all the way through to full inclusion to Debian
20:39 allison the reasons we go with supported are a) lower frequency and b) at least some greater chance of support if we hit bugs later
20:39 mberends joined #parrotsketch
20:40 allison the debian and Ubuntu support cycles are *way* longer than Parrot's
20:40 pmichaud I'm not asking for monthly, definitely.
20:40 allison so, it's not actually a good fit
20:40 allison but, it's a slightly better fit
20:40 pmichaud let's back up just a second.
20:40 rurban debian parrot 5.0 will be threaded, and rakudo cannot handle threads yet
20:40 Coke the way parrot releases things, there is no substantive difference between a supported one month and the devel the next. You /could/ just pick the latest one that works with rakudo.]
20:40 pmichaud If we agree that Parrot exists to support one major customer now, then "greater chance of support" becomes irrelevant.
20:41 allison different kinds of support
20:41 allison an example...
20:41 allison wheezy is shipping with Parrot 4.0 and Rakudo 2012-01
20:41 Coke rurban: be that as it may, latest rakudo builds on latest parrot, I think.
20:41 cotto Coke: yup.
20:41 allison if Debian finds a security bug in either of them
20:42 allison at any point before the next stable debian release (~2015)
20:42 allison we can only make direct patches to the packages
20:42 allison we can't ship a new version of the packages
20:42 allison so, the support I'm talking about is bug/security fixes in the *packaged* versions of the packages
20:43 allison which are already way outside the guarantee of support that Parrot gives on releases
20:43 pmichaud but why does 4.0 have a greater chance of support than any other version that we might tag for packaging?
20:43 allison that's what I'm saying
20:43 pmichaud greater than ... what?
20:43 allison it doesn't really
20:43 pmichaud so, your (b) reason doesn't really matter?
20:43 allison even supported releases only give, what, 1 year of support?
20:43 allison well, 1 year is better than "that's a month old, you're on your own"
20:44 allison which has been the policy for dev releases
20:44 pmichaud I'm saying that policy is irrelevant now.
20:44 allison irrelevant how?
20:44 allison I mean, if all bets are off, I'd probably go with a completely different support policy
20:45 allison which is "we agree to best-effort bug/security fixes on active distro versions"
20:45 allison and kick the rest to the curb
20:45 pmichaud for the case you're describing, what really matters is what version of parrot/rakudo gets pulled into a distro.
20:46 allison yes, and we've been providing some guidance on that by declaring some as "supported"
20:46 allison but, that's just a convention
20:46 pmichaud the notion of supported made more sense when we felt we would have multiple users and the need for coordinated deprecation points
20:46 allison any other way of signaling/choosing versions for packagin in the distros would work
20:47 allison as long as Parrot/Rakudo are willing to provide support for those versions, whatever they are
20:47 allison (and by "support" there, I mean distro bug/security patches, rather than any broader definition of "support")
20:48 pmichaud oops, I have to pick up kid from school
20:48 allison pmichaud: yes, the regular cycle was more important with a broad customer target
20:48 pmichaud bbi20
20:48 allison pmichaud: it's much easier to just declare a distro target when you're only coordinating between Parrot and Rakudo
20:49 allison pmichaud: (though, again, Parrot and Rakudo is really all Debian has cared about for years now)
20:49 allison cotto: I'll also drop out and hand this back to you
20:50 cotto allison: it sounds like it was winding down
20:50 cotto any other questions?
20:50 * kid51 is very glad to see everybody speaking with one another again
20:50 rurban Coke: Latest rakudo builds and runs on latest parrot yes, because the threads tests are not yet executed.
20:51 * not_gerd wants to highlight something that needs fixing long-term
20:51 not_gerd story on JVM: QAST->JAST->bytecode
20:51 cotto not_gerd: go for it
20:51 allison rurban: what's the incompatibility between Rakudo and Parrot 5.0?
20:51 not_gerd story on Parrot: QAST->POST/PIRT->PIR->[imcc]->bc
20:51 allison rurban: and can we eliminate it with different build flags?
20:51 allison rurban: build an unthreaded Parrot, for example?
20:52 allison rurban: if not, I'll hold back the Parrot packages
20:52 rurban we can tell people to not use threads on rakudo yet
20:52 rurban they do work fine on parrot though.
20:52 allison rurban: we can't ship  broken packages
20:52 rurban it's only nqp which is broken, when using threads
20:52 allison and "telling people feature x doesn't work" doesn't fly in package land
20:53 rurban since nobody is using threads yet, the tests pass
20:53 rurban see the threads branch in nqp
20:53 not_gerd allison: Rakudo does not expose threading
20:53 allison not_gerd: nqp is a separate package
20:54 rurban for now we are pretty safe package-wise
20:54 not_gerd nqp doesn't either ;)
20:54 rurban nqp branch=gh67-threads
20:54 allison rurban: you're not making sense. You're saying that nqp and rakudo are incompatible with a feature of parrot that they don't use?
20:55 rurban See t/nqp/67-threads.t
20:55 rurban yes
20:55 allison is there any way that a user could stumble on Parrot threads through Rakudo or NQP version 2013-02?
20:55 rurban via pir: $b := pir::new__PSP('Task', $a); pir::schedule__0P($b); pir::wait__0P($b)
20:56 rurban Not yet
20:56 allison then Debian doesn't care about it
20:56 cotto rurban: thanks for the heads up.  For the time being this doesn't sound like a blocker.
20:56 rurban But they might ask, so it should be mentioned. Some people already are spreading wrong fud about parrot threads
20:56 cotto We'll definitely want to get threads into a place where NQP/Rakudo can make use of them.
20:57 rurban nqplexpad.pmc needs to be fixed
20:57 allison rurban: pmichaud is content with upgrading to 5.0 in Debian/Ubuntu, so that's good enough for me
20:57 rurban the parrot lexpad implementation works fine threaded
21:00 not_gerd imo threads are not the priority right now, as long as we take care that sixparrot doesn't break them
21:00 not_gerd if someone wants to work on them, great
21:00 cotto not_gerd: that's how I feel too
21:00 not_gerd performance is probably more important
21:00 allison not_gerd: agreed, performance is key
21:01 cotto If Rakudo says that they're a priority or someone with sufficient tuits feels like making them work, fine.  Otherwise they're not hurting anything.
21:01 pmichaud back again
21:02 cotto not_gerd: You have a valid concern about QAST->...->pbc, but I can't imagine PIRATE being nearly fast enough to be usable right now, even if the if it worked.
21:02 cotto *even if it worked
21:03 pmichaud Rakudo's stance on parrot threads is I'd like to see an example of how the equivalent of Perl 6   "@a <<+>> @b" would be implemented using them.  Until I can see that, they don't pose much interest to me personally.
21:03 not_gerd we first need to provide a proper API for bytecode generation
21:03 not_gerd then, someone needs to come up with the intermediate layer between QAST and that API
21:04 benabik I was going to do that with PACT.  But I think building a structure the way it was doing isn't the right way.  Should expose a PackfileBuilder that has functions like "start_sub" and "add_op"
21:04 not_gerd ->POST/PIRT->PIR->[imcc]-> should be *one* step
21:04 not_gerd benabik: +1
21:04 not_gerd sounds sane to me
21:05 benabik Models: Rubinius, ASM
21:05 pmichaud before going too far on the post/pirt/pir/imcc replacement path, be sure to look at whatever jnthn++ has been doing for jvm codegen
21:05 cotto not_gerd: Parrot needs to be aggressive about improving performance before we can worry about providing saner APIs to do things that can currently be done.
21:05 pmichaud that's the likely api we'll want to use
21:05 allison pmichaud: there's a chance we can support that api directly
21:05 allison pmichaud: once it settles down
21:05 benabik pmichaud: nqp-jvm-prep repo?
21:05 pmichaud benabik: yes, I think so.
21:06 pmichaud jnthn has done a fair bit of work/thinking about codegen for nqp, so it'd be good to revisit whatever he's done recently and use it as a restarting point
21:06 allison codegen is codegen, whatever the target
21:07 benabik Looks like he's doing the same build a tree and compile it, it's just that the compiler is in Java.
21:07 not_gerd cotto: I don't have the numbers ready, but building Rakudo's core setting spends ~100s on parsing and ~40s on code gen
21:07 not_gerd cotto: so there is some performance improvement involved
21:08 cotto not_gerd: that's similar to what I remember seeing
21:09 benabik Uses http://commons.apache.org/bcel/.  Seems to have a similar factory system as I was discussing.
21:09 cotto not_gerd: The bigger question is how much of an impact there is to be had on runtime performance.
21:09 pmichaud allison: just to confirm, yes, 5.0 is fine for packaging.  Rakudo 2012.02 will still have Parrot 4.10 as a minimum version, which means it could be a candidate for packaging with the 5.0 release.
21:10 cotto If the build is indicative of that, improving codegen is a worthwhile goal.
21:10 allison pmichaud: okay, sounds good
21:10 not_gerd cotto: well, if the choice is between adding optimization stages to imcc or the new system, I know what I'd vote for
21:10 not_gerd as I mentioned when I brought it up, this is a long-term goal
21:10 cotto not_gerd: not a hard choice
21:11 cotto I'd be interested in seeing a profile of a typical Rakudo application (aside: Is there one?) to see if it spends a similar amount of time in parsing and codegen.
21:11 pmichaud also, my takeaway from the earlier discussion is that whenever someone wants to merge in the evalpmc changes to Parrot, we'll go ahead and update Rakudo/NQP to match (which will bump up the parrot revision requirement).  I may decide to-reimplement the nqp/rakudo patches myself, though, rather than adopt the pull requests.
21:12 cotto another takeaway: make pull requests to nqp minimal
21:12 pmichaud I think that's generally true; keep things as small diffs rather than large ones.
21:13 cotto yes
21:13 benabik s/to nqp//
21:13 not_gerd pmichaud: the problem was that I din't really know what I was doing when I started
21:13 allison pmichaud: yes, makes sense. I'll track when Rakudo makes that change.
21:13 not_gerd just moved stuff around until it worked
21:13 not_gerd pmichaud: if you want to do it, go ahead
21:14 not_gerd otherwise, I can rebase on master and provide a new, atomic set of patches
21:14 pmichaud allison: good deal.  I suspect it means that the next package-able version of rakudo will be 2013.04, which will concide with the Parrot 5.3.0 release (assuming it's the next supported release)
21:14 not_gerd pmichaud:just tell me what you prefer so we don't work in parallel
21:14 cotto pmichaud: It's the next supported release if Rakudo wants it to be.
21:15 allison pmichaud: ok, we can check in around that time and decide which Parrot/Rakudo releases should be the next Debian/Ubuntu target
21:15 pmichaud cotto: before declaring that, I think we should decide what the next supported release of Parrot ought to look like
21:15 pmichaud i.e., at what point do we start going minimal?
21:15 allison pmichaud: I suspect a lot is going to depend on the results of the next couple of weeks of work
21:16 pmichaud it may be too soon to decide that today, but at some point we do need to make a roadmap
21:16 allison pmichaud: and whether sixparrot starts to look like a feasible replacement for trunk
21:17 allison for me, that comes down to "does it offer enough advantages to be worth breaking compatibility with other languages"
21:17 allison I hope so
21:17 allison it's not really substantially different yet
21:17 allison like, 30 seconds on the test suite isn't hugely compelling
21:17 allison but, it's at least trending in the right direction :)
21:18 pmichaud cotto: from a rakudo perspective, we'd want there to be another "supported" release by April, unless we know for sure that packagers won't be using April as a candidate anyway.
21:19 pmichaud put another way, as long as Parrot 5.0 remains the latest "supported" release, distros and users would never be able to upgrade beyond Rakudo 2013.02.
21:19 allison pmichaud: seems to me like one of a) 5.3 is mostly the same as 5.0, b) 5.3 never happens because 5.0 is "good enough", and possibly c) 5.3 is sixparrot
21:19 allison (c) seems most unlikely
21:20 allison though I can imagine 5.6 as sixparrot
21:20 allison depending on how things go
21:20 pmichaud well, if we introduce the evalpmc changes, then 5.0 is no longer "good enough" because it places an upper bound on rakudo releases.
21:20 allison that'd make 5.3 worthwhile, then
21:20 Coke pmichaud: let's let development on sixparot drive whether something is merging back.
21:20 allison even without sixparrot
21:21 pmichaud right.  my point is that a backward-incompatible change (such as evalpmc) drives the need for another supported release in the relatively short term after that.
21:21 allison will the new evalpmc apis be in 5.1?
21:22 pmichaud allison: no.
21:22 pmichaud 5.1 is being released today.
21:22 allison ok, more like 5.2 then
21:22 Coke I would argue that it isn't int he short term after that, but "before packagers consider packaging another release"
21:22 pmichaud Coke: that was my point about letting packagers drive the release schedule, but allison gives me the impression that's not really possible.
21:23 allison I was wondering if it would be worth waiting for 5.1 instead of 5.0
21:23 pmichaud allison: I don't think 5.1 is significantly different from 5.0.
21:23 allison packaging is driven by the Ubuntu and Debian release schedules
21:23 allison which are so slow compared to Parrot/Rakudo as to be glacial
21:23 pmichaud 5.0 versus 5.1 really doesn't impact rakudo or nqp much.
21:24 allison I'll stick with 5.0, then
21:24 allison but, if Rakudo decides it wants 5.2, we can do that instead of waiting for 5.3
21:25 allison on the whole, I think adding evalpmc in 5.2
21:25 allison having Rakudo make the transition...
21:25 allison and then doing packaging of 5.3, is the most sane
21:25 allison the thing is, very few Debian packagers coordinate with upstreams like Parrot/Rakudo
21:26 allison it's unfamiliar to them to think they might have any say whatsoever in upstream release schedules
21:26 allison I try to do better than the usual :)
21:27 pmichaud yes, I can understand why packagers would look at it that way in the normal case.  In our case, having very old versions of packages in circulation is really hurtful to the overall project, so we're wanting to work with packagers to jit the release schedules as much as we can
21:29 cotto thanks, allison
21:29 pmichaud in later phases, with more maturity, the jitting is much less relevant, but when going through rapid growth/update we want to reduce lags if we can
21:29 allison pmichaud: yes, makes sense
21:34 Util (pre|post)-YAPC::NA::2013 hackathon for Perl-NG (Parrot, NQP, Rakudo, Niecza, Moe, p5-mop, Topaz, etc)
21:34 Util Interest?
21:35 cotto Util: yes
21:35 cotto In the likely event that I'm at YAPC::NA, I'll attend.
21:35 pmichaud Util: yes.
21:35 tadzik hm, if I may add my 5zł to the previous issues
21:35 Util I have emailed the YAPC list, to find out whether space is available before, or after YAPC.
21:36 cotto Util: before is much preferable
21:36 tadzik 1) the only use of threads in rakudo/nqp that I know of is my Threads.pm, which (1) explicitely states that it's experimental (2) lives outside rakudo (3) clearly says that it needs parrot --without-threads to work
21:36 masak joined #parrotsketch
21:36 Util cotto: for me, too, but I could do after. More discussion next week at #parrotsketch
21:36 cotto Util: +1
21:37 benabik tadzik: --without-threads?
21:37 tadzik and regarding the releasing issues, I read the discussion and wondered: if it's that much of a hassle to release parrot and rakudo in sync, maybe it would make sense for rakudo to just ship parrot source with it and build it itself?
21:37 tadzik like a submodule or something
21:37 tadzik benabik: yeah, that switches native threads to green threads
21:37 tadzik green threads work alright in nqp. Native ones, as rurban indicated, do not
21:37 rurban Util: You forgot p2
21:38 rurban (As I want to run p5 and p6 in true #p6p5 sense)
21:39 Util rurban: My email expanded it to ", etc.". I did have your p2 in mind, but did not explicitly list it since I got confused as to the final proposal(s) during the discussions on it.
21:39 masak rurban: I for one would really like to see someone reply to diakopter's mail about threads on parrot-dev. in my estimation, they raise serious concerns with Parrot's threading model, and I haven't seen anything to address those.
21:39 rurban masak: Those concerns were not serious. and whiteknight already answered.
21:40 rurban In short: threads from subthreads will leave stale proxies
21:40 rurban They will leak. But 1. we do not support subthreads from a thread, only from master, and 2. I would not be concerned by leaking proxies.
21:41 not_gerd masak: different threading models lead to different implementation strategies
21:41 not_gerd parrot's model is not pthread
21:41 not_gerd but neither is erlang's or rust's
21:41 not_gerd that does not mean any of these is defective
21:42 masak rurban: hm, I didn't see an answer from whiteknight. I'm looking not, and I still don't see it. got a url?
21:43 cotto Let's continue this discussion in #parrot and call #ps a wrap unless there are any unaddressed questions.
21:43 tadzik any opinion on my proposal?
21:43 rurban masak: it was nine. http://lists.parrot.org/pipermail/p​arrot-dev/2012-December/007295.html
21:45 rurban masak: And we need a semaphore library of course
21:45 masak rurban: diakopter wrote a reply to that one which raised more (serious) concerns. that mail went unanswered.
21:46 tadzik I implemented semaphores for Perl 6 :)
21:46 rurban I didn't see any serious concern in the 2nd mail
21:46 tadzik basing on some parrot example
21:46 not_gerd masak: I remember that mail
21:47 not_gerd my thoughts were: doctor, it hurts when I do that -- so don't
21:47 masak it sounded like quite an un-contrived example to me. but I'm not a threads expert.
21:47 masak what concerned me was that the email went unanswered, though.
21:47 masak I would have liked for someone from Parrot-land to have replied to it, settling any doubts.
21:48 masak even if you guys look at it and don't take it seriously, it *sounds* serious.
21:48 Coke As I suggested when this came up in parrot, it would be nice if those concerns could be translated into code that we could run and see the result of.
21:48 rurban Well, since you should not do cross-thread writes, only from main, it's a rather contrived limitation
21:49 masak not doing cross-thread writes sounds like a very limiting limitation.
21:49 Coke we should move the technical bits back to #parrot
21:49 rurban and proxy invoked code should not create other proxies
21:49 masak Coke: right. sorry.
21:49 masak left #parrotsketch
21:49 rurban in short: not serious concerns, but nice to have for the future
21:51 Coke in short: please stop saying "not serious". thanks.
21:51 benabik joined #parrotsketch
21:53 not_gerd left #parrotsketch
22:04 benabik left #parrotsketch

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