Post closed tickets in your report. | Note: This channel is for our weekly status meetings (Tuesdays at 19:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/
Set by moderator on 20 January 2013.
00:15 bluescreen joined 06:55 cotto joined 10:00 xcombelle joined 11:25 jlaire joined 13:55 benabik joined 14:21 bluescreen joined 14:27 benabik joined 14:49 benabik joined 14:51 benabik_ joined 15:09 bluescreen joined 15:16 rurban joined 15:27 contingencyplan joined 15:35 benabik joined 18:02 kid51 joined 18:16 tadzik joined 18:24 pmichaud joined 18:34 dukeleto joined 18:56 benabik joined 19:11 atrodo joined 19:14 moritz joined 19:18 kid51 joined 19:24 not_gerd joined
Util is pre-reporting 19:26
Done:
* Discussed Perl [56] futures with stevan and Liz at Perl Oasis.
Doing:
* Releasing Parrot 5.1.0 *today*. (First time as Release Manager)
- Failed to shepherd the release during the lead-up time, so some chaos in #parrot right now
* Improving Config probes for PCRE and libFFI on Darwin
Proposing:
* YAPC hackathon for Perl-NG (Parrot, NQP, Rakudo, Niecza, Moe, and p5-mop) 19:27
.END
moritz with YAPC, do you mean YAPC::EU or YAPC::NA?
Util YAPC::NA; Thanks, moritz! 19:29
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:30
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)
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:32
cotto done 19:34
* lots of discussion about a new direction for Parrot; see reparrot.blogspot.com/2013/02/its-b...et_15.html for detailk
doing
* working on resurrecting p5-based ops2c, one of the two users of the obsolote nqp-rx
* working in the ops2c-necromancy branch
* Parrot itself is building fine with one test failure
* haven't tested nqp/Rakudo yet, will do so before thinking about merging
todo
* finish ops2c-resurrection
* look at profiler tests (other use of nqp-rx)
* get rid of nqp-rx
* excise any nqp-rx-exclusive code paths from Parrot
eor
any other slowpokes?
not_gerd me 19:35
cotto fire at will
not_gerd * started porting nci_thunk_gen.pir -> pl
stopped because the subsystem goes away
* resurrected whiteknight's eval_pmc branch
* added --target=pbc to NQP/Rakudo (pending review) 19:36
EOR
cotto thank you
pmichaud I'm present, nothing specific to report, may have to leave w/o warning.
allison * I've been removing useless MMD 19:37
atrodo * worked on removing nci from sixparrot, hopefully will push something soon
moritz * did some random sixparrot removal, a force push, and trying to keep parrot<->rakudo relations productive 19:38
EOR
cotto Util: do you have any reservations about the release today?
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.
pmichaud Util: I'd say cut the release, don't expect any further last-minute updates.
(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.
pmichaud Coke is correct, I think.
cotto I'd really like to see not_gerd's changes, but I agree that it's too late in the cycle.
so +1 to what pmichaud said
pmichaud cotto: those are going to take a lot of planning and coordination, sadly.
cotto How about now for planning? 19:41
Util OK, will release today; no merges allowed until after release.
cotto Util: great
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
at least, not with a single backend vm stream
Coke pmichaud: do you have any positive steps we could take?
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
pmichaud I'm still having to try to digest all of this rapidly
not_gerd merge of my NQP/Rakudo branches depends on new API, but not Eval PMC removal
eg the latter could only go into sixparrot and not master
allison not_gerd, so add the new API, but don't remove the old Eval PMC?
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?
Coke not_gerd: note that rakudo/nqp still have to build unchanged on sixparrot.
pmichaud and yes, sixparrot is part of the confounding change
Coke pmichaud: (cosmetic) well, that I'm sure can be cleaned up.
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
not_gerd add new API now, remove Eval PMC from sixparrot ones the Rakudo/NQP changes land
^once
cotto s/now/after the release/ 19:46
allison not_gerd: that seams reasonable
pmichaud it's also confusing because we have Parrot, Parrot 5.0.0, Parrot 5.1.0, and "sixparrot"
allison cotto: not right after the release
cotto: because it breaks nqp/rakudo
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.
pmichaud so when someone says "remove Eval PMC" I don't know where the change is coming.
allison pmichaud: maybe not at all 19:47
cotto Let's clarify sixparrot.
allison it seems entirely safe to add the new APIs, though
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
with appropriate coordination with Rakudo
pmichaud cotto: that doesn't sound to me like Coke's version of sixparrot
cotto Coke: how do you see it? 19:49
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 :)
Coke I've been attempting to avoid doing anything in the branch that breaks nqp or rakudo.
pmichaud I think for the time being we want to do anything in nqp/rakudo that breaks the branch, too.
allison me too, my requirement for every change is "rakudo must still pass all tests"
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'
(my proposed workaround there is to have any pasm includes automatically include the pir file instead.)
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")
Coke I think eliminating unused code and removing a maintenance burden is still a win for the branch. 19:54
but sure, anything that slows things down defeats the purpose.
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 :)
Coke aye.
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.
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.
okay, works for me.
allison Coke: that would be great (lightening objects)
Coke if you suddenly start using something before it being deleted lands on master, yes, we have to add it back in to sixparrot.
pmichaud I feel like I'm being more confusing than helpful here, perhaps I should go.
Coke I want you to understand what's going on. 19:58
cotto +1
pmichaud Yeah, I'm having trouble following what's going on, that's for sure.
cotto especially as the community manager on the Rakudo side
Coke which is basically that we're trying to make things small, faster, better.
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. 19:59
benabik If Rakudo starts using something, then obviously isn't useful and should stick around. :-) 20:00
*it's
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?
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.
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.
(in theory)
Coke I run it, but it's slow to test /everything/ every time I rip out 3 lines of code. ;)
moritz Coke: will try to do it
cotto it won't hurt to do so occasionally, like Coke said 20:02
pmichaud I need to reserve a topic slot to discuss API change/backward compatibility issues 20:03
cotto pmichaud: today or in general?
pmichaud either.
it's with respect to the evalpmc changes
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.
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.
and the evalpmc changes are bringing the distinction to the foreground
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.
pmichaud That's one form of backward compability -- Parrot doesn't want to introduce changes that cause existing rakudo code to break.
however, there's another form, from a Rakudo perspective. 20:07
let's say that we go with the plan that instead of removing evalpmc immediately, we first add the new API to parrot
this gives Rakudo time to adapt "on its own schedule" 20:08
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
currently, Rakudo works with Parrot 4.10 or later. 20:09
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.
Coke that seems to be the price of progress, no? 20:10
cotto Doesn't Rakudo already support detecting a minimum Parrot version?
pmichaud sure
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?
pmichaud But every time we bump the minimum Parrot version, we reduce the "newness" of Rakudos that can appear in Linux distros.
I'm simply saying we need to be aware of it, I think.
Coke as discussed on parrot, that's already over a year old.
pmichaud for debian testing, yes. 20:12
not for debian unstable, or ubuntu.
Coke I think we need to make sure that tickets from packagers get priority treatment.
Util Could EvalPMC's replacement have a (additional?) API that is compatible with the current EvalPMC API?
Coke (for both projects)
pmichaud Util: I think that's an example of my first form of compatibility. 20:13
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
Util pmichaud: Right, I am asking if it is actually feasible at all. I am unfamiliar with the replacement. 20:14
pmichaud I think we want to go ahead and eliminate the old API asap. 20:15
Util OK
pmichaud If Parrot has one customer (Rakudo/NQP), let's not keep too many APIs around just for the sake of Rakudo/NQP.
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.
cotto allison: ^
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:18
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:19
allison ah, see, I'd go the other way, just tell us which versions to package 20:20
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
pmichaud right, I'm trying to ameliorate that somewhat
allison it's the nature of the beast, unfortunately
pmichaud I think it doesn't have to be
allison in my ideal world, Debian packages two releases per year
so, if I do Parrot 5.0 now 20:22
pmichaud are the dates of the debian package releases known?
allison I'd say as long as Parrot 5.6 and Rakudo 2013-6 are usable together, that's all we need
debian is on a 2 year release schedule
but merges from unstable to testing happen on-the-fly
wheezy is expected very soon now, so it'll be going out the door with 2012-01 20:23
no way of changing that
(wheezy is already in freeze)
Ubuntu could get Parrot 5.0 into the 2013.04 release 20:24
pmichaud ...yes, but which version of Rakudo?
allison it's not "automatic" at this point, since we're past auto-sync, but I can request it and get it approved
moritz pmichaud: 2013.02
allison which version of rakudo do you want?
2013-01 would be my default
(same month as 5.0) 20:25
20:25 benabik joined
pmichaud allison: why not a later version of rakudo, though? 20:25
allison it's a matter of timing
moritz there's no indication that 2013.02 will need a parrot 5.1 or newer
allison I'll really have to get it into Ubuntu in the next few weeks
moritz and 2013.02 will be out on Thursday
allison so 2013-02 is possible
but, that's probably the last one possible
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
moritz *if
allison pmichaud: well, that's what you all told me a few years ago, so I've just stuck with it
as in, that's the only rakudo release I'm *sure* is compatible
but, things were a lot faster and looser back then 20:27
so, I'm happy to revise that "rule of thumb"
pmichaud allison: that's why we need to know the packagers timings/needs a bit better (more) 20:28
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 :)
but if packagers are just always going to use the version of Rakudo that came out contemporaneously with Parrot, there's not much point.
(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
those get tricky
If we can upgrade Rakudo packages, get those out
and then go back and upgrade Parrot packages, it's simpler
though, right now I'm wondering if Rakudo 2012.10 is compatible with Parrot 5.0 20:30
because the dependency problem is running the other way :)
pmichaud well, there's no question that when you change parrot, you have to rebuild the rakudo package to match 20:31
parrot doesn't offer us bytecode compatibility.
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
pmichaud allison: yes, and since
20:25 <allison> it's a matter of timing
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
moritz and also the paths change
allison but, a rebuild is simpler than a source version upgrade
Coke can we have them wing us an email when it's decidin' time? 20:33
allison sure
Coke seems the best thing is to talk about it rather than try to setup dominos in advance.
allison for now, the next target is Parrot 5.0
and I'm open to suggestions on Rakudo
sounds like 2013-01 or 2013-02
pmichaud allison: and "why" is the next target Parrot 5.0? 20:34
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?
benabik Didn't someone push changes to make Parrot not invalidate bytecode so often?
allison pmichaud: both 20:35
pmichaud: and at this point, it's unlikely that another Parrot release will be packaged for 3-6 months
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?
allison pmichaud: the problem is, there's substantial lag in packaging
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
but, it's still not in
and this happens a lot
Parrot/Rakudo come out with a new release before the last one is into Debian
rurban benabik: I did
allison and then the question is "do we chuck all that work and move to the new new release?"
or "do we go ahead with what we've got?"
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
allison so, we pick a point, and follow that all the way through to full inclusion to Debian
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
20:39 mberends joined
allison the debian and Ubuntu support cycles are *way* longer than Parrot's 20:40
pmichaud I'm not asking for monthly, definitely.
allison so, it's not actually a good fit
but, it's a slightly better fit
pmichaud let's back up just a second.
rurban debian parrot 5.0 will be threaded, and rakudo cannot handle threads yet
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.]
pmichaud If we agree that Parrot exists to support one major customer now, then "greater chance of support" becomes irrelevant.
allison different kinds of support 20:41
an example...
wheezy is shipping with Parrot 4.0 and Rakudo 2012-01
Coke rurban: be that as it may, latest rakudo builds on latest parrot, I think.
cotto Coke: yup.
allison if Debian finds a security bug in either of them
at any point before the next stable debian release (~2015) 20:42
we can only make direct patches to the packages
we can't ship a new version of the packages
so, the support I'm talking about is bug/security fixes in the *packaged* versions of the packages
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?
allison that's what I'm saying
pmichaud greater than ... what?
allison it doesn't really
pmichaud so, your (b) reason doesn't really matter?
allison even supported releases only give, what, 1 year of support?
well, 1 year is better than "that's a month old, you're on your own"
which has been the policy for dev releases 20:44
pmichaud I'm saying that policy is irrelevant now.
allison irrelevant how?
I mean, if all bets are off, I'd probably go with a completely different support policy
which is "we agree to best-effort bug/security fixes on active distro versions" 20:45
and kick the rest to the curb
pmichaud for the case you're describing, what really matters is what version of parrot/rakudo gets pulled into a distro.
allison yes, and we've been providing some guidance on that by declaring some as "supported" 20:46
but, that's just a convention
pmichaud the notion of supported made more sense when we felt we would have multiple users and the need for coordinated deprecation points
allison any other way of signaling/choosing versions for packagin in the distros would work
as long as Parrot/Rakudo are willing to provide support for those versions, whatever they are 20:47
(and by "support" there, I mean distro bug/security patches, rather than any broader definition of "support")
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
pmichaud bbi20
allison pmichaud: it's much easier to just declare a distro target when you're only coordinating between Parrot and Rakudo
pmichaud: (though, again, Parrot and Rakudo is really all Debian has cared about for years now) 20:49
cotto: I'll also drop out and hand this back to you
cotto allison: it sounds like it was winding down 20:50
any other questions?
kid51 is very glad to see everybody speaking with one another again
rurban Coke: Latest rakudo builds and runs on latest parrot yes, because the threads tests are not yet executed.
not_gerd wants to highlight something that needs fixing long-term 20:51
story on JVM: QAST->JAST->bytecode
cotto not_gerd: go for it
allison rurban: what's the incompatibility between Rakudo and Parrot 5.0?
not_gerd story on Parrot: QAST->POST/PIRT->PIR->[imcc]->bc
allison rurban: and can we eliminate it with different build flags?
rurban: build an unthreaded Parrot, for example?
rurban: if not, I'll hold back the Parrot packages 20:52
rurban we can tell people to not use threads on rakudo yet
they do work fine on parrot though.
allison rurban: we can't ship broken packages
rurban it's only nqp which is broken, when using threads
allison and "telling people feature x doesn't work" doesn't fly in package land
rurban since nobody is using threads yet, the tests pass 20:53
see the threads branch in nqp
not_gerd allison: Rakudo does not expose threading
allison not_gerd: nqp is a separate package
rurban for now we are pretty safe package-wise 20:54
not_gerd nqp doesn't either ;)
rurban nqp branch=gh67-threads
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?
rurban See t/nqp/67-threads.t 20:55
yes
allison is there any way that a user could stumble on Parrot threads through Rakudo or NQP version 2013-02?
rurban via pir: $b := pir::new__PSP('Task', $a); pir::schedule__0P($b); pir::wait__0P($b)
Not yet 20:56
allison then Debian doesn't care about it
cotto rurban: thanks for the heads up. For the time being this doesn't sound like a blocker.
rurban But they might ask, so it should be mentioned. Some people already are spreading wrong fud about parrot threads
cotto We'll definitely want to get threads into a place where NQP/Rakudo can make use of them.
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
rurban the parrot lexpad implementation works fine threaded
not_gerd imo threads are not the priority right now, as long as we take care that sixparrot doesn't break them 21:00
if someone wants to work on them, great
cotto not_gerd: that's how I feel too
not_gerd performance is probably more important
allison not_gerd: agreed, performance is key
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
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
*even if it worked
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
then, someone needs to come up with the intermediate layer between QAST and that API
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
benabik: +1
sounds sane to me
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
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.
pmichaud that's the likely api we'll want to use
allison pmichaud: there's a chance we can support that api directly
pmichaud: once it settles down
benabik pmichaud: nqp-jvm-prep repo?
pmichaud benabik: yes, I think so.
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
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
cotto: so there is some performance improvement involved
cotto not_gerd: that's similar to what I remember seeing 21:08
benabik Uses 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.
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.
cotto If the build is indicative of that, improving codegen is a worthwhile goal. 21:10
allison pmichaud: okay, sounds good
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
as I mentioned when I brought it up, this is a long-term goal
cotto not_gerd: not a hard choice
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.
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.
cotto yes 21:13
benabik s/to nqp//
not_gerd pmichaud: the problem was that I din't really know what I was doing when I started
allison pmichaud: yes, makes sense. I'll track when Rakudo makes that change.
not_gerd just moved stuff around until it worked
pmichaud: if you want to do it, go ahead
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)
not_gerd pmichaud:just tell me what you prefer so we don't work in parallel
cotto pmichaud: It's the next supported release if Rakudo wants it to be.
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
i.e., at what point do we start going minimal?
allison pmichaud: I suspect a lot is going to depend on the results of the next couple of weeks of work
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
for me, that comes down to "does it offer enough advantages to be worth breaking compatibility with other languages" 21:17
I hope so
it's not really substantially different yet
like, 30 seconds on the test suite isn't hugely compelling
but, it's at least trending in the right direction :)
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:18
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
(c) seems most unlikely
though I can imagine 5.6 as sixparrot 21:20
depending on how things go
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.
allison that'd make 5.3 worthwhile, then
Coke pmichaud: let's let development on sixparot drive whether something is merging back.
allison even without sixparrot
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?
pmichaud allison: no. 21:22
5.1 is being released today.
allison ok, more like 5.2 then
Coke I would argue that it isn't int he short term after that, but "before packagers consider packaging another release"
pmichaud Coke: that was my point about letting packagers drive the release schedule, but allison gives me the impression that's not really possible.
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.
allison packaging is driven by the Ubuntu and Debian release schedules
which are so slow compared to Parrot/Rakudo as to be glacial
pmichaud 5.0 versus 5.1 really doesn't impact rakudo or nqp much.
allison I'll stick with 5.0, then 21:24
but, if Rakudo decides it wants 5.2, we can do that instead of waiting for 5.3
on the whole, I think adding evalpmc in 5.2 21:25
having Rakudo make the transition...
and then doing packaging of 5.3, is the most sane
the thing is, very few Debian packagers coordinate with upstreams like Parrot/Rakudo
it's unfamiliar to them to think they might have any say whatsoever in upstream release schedules 21:26
I try to do better than the usual :)
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:27
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
allison pmichaud: yes, makes sense
Util (pre|post)-YAPC::NA::2013 hackathon for Perl-NG (Parrot, NQP, Rakudo, Niecza, Moe, p5-mop, Topaz, etc) 21:34
Interest?
cotto Util: yes 21:35
In the likely event that I'm at YAPC::NA, I'll attend.
pmichaud Util: yes.
tadzik hm, if I may add my 5zł to the previous issues
Util I have emailed the YAPC list, to find out whether space is available before, or after YAPC.
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
Util cotto: for me, too, but I could do after. More discussion next week at #parrotsketch 21:36
cotto Util: +1
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?
like a submodule or something
benabik: yeah, that switches native threads to green threads
green threads work alright in nqp. Native ones, as rurban indicated, do not
rurban Util: You forgot p2
(As I want to run p5 and p6 in true #p6p5 sense) 21:38
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.
rurban masak: Those concerns were not serious. and whiteknight already answered.
In short: threads from subthreads will leave stale proxies 21:40
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.
not_gerd masak: different threading models lead to different implementation strategies 21:41
parrot's model is not pthread
but neither is erlang's or rust's
that does not mean any of these is defective
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:42
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?
rurban masak: it was nine. lists.parrot.org/pipermail/parrot-d...07295.html
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.
tadzik I implemented semaphores for Perl 6 :) 21:46
rurban I didn't see any serious concern in the 2nd mail
tadzik basing on some parrot example
not_gerd masak: I remember that mail
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.
what concerned me was that the email went unanswered, though.
I would have liked for someone from Parrot-land to have replied to it, settling any doubts.
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.
rurban Well, since you should not do cross-thread writes, only from main, it's a rather contrived limitation
masak not doing cross-thread writes sounds like a very limiting limitation. 21:49
Coke we should move the technical bits back to #parrot
rurban and proxy invoked code should not create other proxies
masak Coke: right. sorry.
21:49 masak left
rurban in short: not serious concerns, but nice to have for the future 21:49
Coke in short: please stop saying "not serious". thanks. 21:51
21:51 benabik joined 21:53 not_gerd left 22:04 benabik left

Powered by Cro and the Raku® Programming Language.

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

Thank you!