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 30 August 2011.
07:21 contingencyplan joined 08:02 lucian joined 12:00 bluescreen joined 12:17 bluescreen joined 14:35 bluescreen joined 17:48 ilbot2 joined
moderator 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/
18:03 contingencyplan joined 18:47 whiteknight joined 18:59 NotFound joined
whiteknight WHAT I DID: 19:00
* Working on Jaesop (formerly JSOP). Am most of the way towards a working stage 0.
* Have the Jaesop object model working more-or-less correctly. Redid the test suite to handle the new semantics. 19:01
* Suggested a few winxed changes that would make Jaesop life much easier
* Major refactor of the Rosella Harness library. Much cleaner public interface now. I am in the middle of redoing the TAP parser to be less bad.
* Playing with a few new Rosella libraries and misc cleanups throughout.
* On suggestion from jnthn++, set up, tested, and merged the whiteknight/pmc_is_ptr branch. Up to 25% improvement on some benchmarks.
* With help from nine++, the whiteknight/kill_threads branch is ready for testing and eventually merger.
* Talked with cotto about the deprecation policy. Said cursewords. Am happy to see it go.
* Looked at soh_cah_toa++'s new debugging metadata stuff. Going to get more involved in that.
* Drawing up some concrete plans for changes to PCC, IMCC, and Packfiles that are going to need to happen soon.
WHAT I WILL DO
* Finish refactor of Rosella Harness and the new TAP parser
* Continue playing with Jaesop, want to get the remaining few bits of syntax generating proper winxed code.
* Get my mind back into 6model. Need to rethink some things.
* Merge whiteknight/kill_threads
* Put together some code for precise GC
EOR
oh, also merged in some pmc_is_ptr fixes from not_gerd++ 19:05
NotFound What I did: 19:11
-parrot
* Just testing
-winxed
* Fix HLL namespace modifier and take HLL into account in several
operators and statemens.
* Several fixes and refactors.
What I will do:
More improvements to HLL handling in winxed
EOR
Util # Done 19:18
* Read cotto++ thoughts on Parrot, and am encouraged by the direction.
# Plan to do:
* Read new purchase: The Garbage Collection Handbook
# Blockers: 19:19
* $WORK
# 7-day ticket report:
1 closed: done
4 closed: fixed
4 new
.end
cotto_work *did: 19:25
- more all_hll_test.pl work, should be "ready" for use
-- all projects are welcome, including Rakudo-based projects that pass their tetss
- sent out message about reassessing (and dropping) our deprecation policy, among other things
-- lots of good feedback
-- uneasy concerns from Rakudo
-- Parrot needs better communication with Rakudo about proposed changes.
- looked at and hacked on mls++'s sub profiling branch
-- needs a lot of cleanup, has great potential
-- it's already proving highly useful for Rakudo, so it or something like it will eventually get merged
*todo
- figure out what a post-deprecation policy future looks like for Parrot, Rakudo and other users
- finish profiling docs
*eor
19:27 tewk__ joined
whiteknight hello 19:30
cotto_work hello
NotFound Hola 19:31
Util Hello 19:32
cotto_work How's this week gone? 19:33
whiteknight pretty darn good 19:34
cotto_work I'd say so.
We'll have to be careful to make sure that someone from Rakudo gets included in our discussions about future changes, but I like where this is going. 19:35
whiteknight yes, I think we're going to want to be more in contact with them than ever
Util Just barely dodged two hurricanes (New York and Alabama), and not cotto++ starts an earthquake :)
s/not/now/
whiteknight obviously their needs are going to be influencing our decisions at a finer-grained level than it has in the past two years
their/there 19:36
bleh
cotto_work I don't see any questions queued, so policy disucssion probably isn't out of place. 19:38
whiteknight go for it 19:39
cotto_work In general, I want notification and testing to replace our deprecation policy. 19:40
all_hll_test.pl is a part of that.
whiteknight more integration testing and better integration testing are key
cotto_work talking with active HLL developers about proposed changes is another
It all needs fleshing out, but I'm glad to see that there aren't any strong objections to replacing the deprecation policy, assuming that HLLs' needs are taken into account. 19:42
I guess that's all I've got for now. 19:46
whiteknight I'm very happy that there doesn't seem to be much pushback
I think it will all go better if we think it's the right thing to do
Util If the D.policy is so replaced, does tht mean that all the outstanding items (APIs, etc) that are being kept for dep's sake immediately go on a hit list? 19:47
cotto_work Util: yes, but it also means we need to make sure that removing them won't mess up HLLs. 19:48
Util Of course
cotto_work It won't hurt us to be explicit about that sort of thing. 19:50
whiteknight We're going to try to do things more quickly, without going completely crazy 19:51
When we make changes, make sure HLLs get fixed quickly
cotto_work run all_hll_test early and often
whiteknight that's a make target?
cotto_work it can be
whiteknight it should be 19:52
cotto_work give me a minute
it is 19:54
whiteknight awesome
cotto_work "allhlltest"
It's guaranteed not to work on all platforms. Patches are welcome. ;) 19:55
Coke I'll get it working on windows.
cotto_work I don't think it'll take too much effort. Coke++ 19:56
19:56 mikehh joined
Coke is it in master now? 19:56
cotto_work yup 19:57
Coke ORLY? didn't see it on an update. found it in all-hll-test, though. 19:58
19:59 pmichaud_ joined
cotto_work Coke: you may not be current 19:59
Coke cotto_work: also, System::Command barfs on windows, apparently. 20:00
so, will take some effort.
cotto_work I am disappoint 20:01
pmichaud_ When we make changes, make sure HLLs get fixed quickly
...how exactly might this happen?
whiteknight pmichaud_: it will be a process of experimentation, what the hlls want 20:02
pmichaud_ although I agree the deprecation policy needs to go, I'm a little concerned that it's going to result in a free-for-all with changes being made to Parrot that Rakudo has to constantly anticipate and react to.
whiteknight patches, pull request, detailed guidance, etc
pmichaud_ and frankly, I don't want to be spending all of my time reacting to Parrot changes (except for the changes that are because of a Rakudo need)
whiteknight pmichaud_: Rakudo being broken against Parrot HEAD has always been cause for concern, and still will be 20:03
pmichaud_ and the list of "proposed changes" I've seen so far seem to be rearranging Parrot's deck chairs as opposed to actually making things better for Rakudo.
cotto_work This is just a thought, but we might start using pull requests for the whole workflow.
whiteknight if it breaks, we fix it. that becomes priority
pmichaud_ whiteknight: what about Rakudo's DarkPAN?
see, for example, the NCI changes from earlier this year.
cotto_work pmichaud_: is that DarkPAN or just UntestedPAN
?
whiteknight pmichaud_: I'm not saying it's going to be perfect. It is going to be a learning process.
Coke (sys:command - error might be ignorable.)
whiteknight we need to figure out how to do what Rakudo needs in a timely manner, without doing what Rakudo needs us not to do 20:04
pmichaud_ cotto_work: could be UntestedPAN, but the tests live outside of the Rakudo compiler if so.
mikehh running the rakudpo test suite against changes before pushing would help
Coke I think it's premature to spend cycles on parrot or rakudo's darkpan at this point.
pmichaud_ there are people building modules and programs for Rakudo that aren't part of the rakudo/rakudo repository
Coke: except that we've already had breakages in Rakudo's userbase
cotto_work pmichaud_: if we can pull, we can automatedly test 20:05
pmichaud_ see, for example, MiniDBI and Zavolaj
whiteknight there's a difference between the darkpan and the module ecosystem
Util +1 to mikehh's comment
whiteknight darkpan is the stuff we don't know about, but assume must be out there somewhere
cotto_work mikehh: absolutely. That's just the first step though.
whiteknight we know about minidbi and zavolaj, so they hardly qualify as "darkpan"
mikehh we need to incorporate that in some form of testing
whiteknight and we need to test against them regularly
pmichaud_ what about Rakudo applications?
cotto_work mikehh: see allhlltest
pmichaud_ do we know about all of those?
Coke pmichaud_: instead of arguing by asking questions, can you tell us what you want? 20:06
pmichaud_ Coke: I don't know what I want.
I know what I don't want.
NotFound Are wa saying that we are going to be able to change things, as long as nothing changes?
Coke fair enough.
(to pmichaud)
pmichaud_ I don't want to be spending a huge amount of my time reviewing every proposed Parrot refactor to have to tell Parrot devs "no, that won't work for Rakudo" and hope that I get those warnings in before they land in Parrot.
cotto_work NotFound: we can change things as long as we know what we're changing and have talked to the people who maintain what all will be changed. 20:07
whiteknight pmichaud_: do you have a particular way you would like us to go about things?
pmichaud_ because frankly, most of the refactors and changes I've seen discussed thus far imply a lot of changes for Rakudo (and risks of breakage) with extremely little Rakudo benefit.
cotto_work: not just "who maintain", but also "who use"
although if "who maintain" know all of the details of "who use", that can be a surrogate.
whiteknight code review and pull requests are going to have to play a much bigger part in things, and we're going to have to go into changes with an eye towards the amount user code will be affected 20:08
effected
20:08 moritz joined, jnthn joined
cotto_work the Rakudo cavalry arrive 20:09
well, more of them ;)
PerlJam cotto_work: I think you might mean "dark horsemen" :) 20:10
whiteknight the old system wasn't working well, and the new system probably won't be perfect either. We need to have more ups and fewer downs
pmichaud_ and not to pick on cotto too much (because I agree with what's being discussed) -- all of this talk of changing the deprecation policy seems to have occurred without getting the input and feedback or soliciting direct input from hll devs.
I grant this is occurring now... 20:11
whiteknight that email was just the start of the conversation. This is the point where we are getting feedback
we haven't deleted the policy yet
cotto_work pmichaud_: I apologize for not including you specifically. I talked with masak and moritz earlier about it.
but nothing's set in stone. Like whiteknight said, this is the start. 20:12
whiteknight if a week goes by and we decide it's a mess, we can always go back
I think we are going to have a lot of refinements to make as a group
pmichaud_ I guess what I'm saying is that changing the deprecation policy is necessary but not sufficient. 20:13
whiteknight pmichaud_: okay, so what else do we need to do?
moritz agreed. And we need to be clear that it's changing the policy, not aborting it
pmichaud_ and that thus far the discussions are _still_ not focused on rakudo needs, but parrot's perceived desire to change its internals all over the place.
i.e., parrot's priorities are still radically orthogonal to rakudo's. 20:14
whiteknight pmichaud_: the benefits to rakudo are not always well communicated
cotto_work Now that it's clear what people think, it's a great time to start sketching out how code changes will be managed in the future.
pmichaud_ whiteknight: I'm saying it's worse than that.
whiteknight: parrot devs mean well and they think they're doing rakudo a favor when they're actually making things much worse. see NCI for example.
whiteknight we need to be more in tune with Rakudo. Previously, there was very little reason to communicate between deprecation boundaries, and I think we all suffered because of that 20:15
pmichaud_ last week there was discussion about changing the interface for "die" and I felt like my comments were basically brushed aside as irrelevant.
whiteknight if we are in closer communication more often, I think we can avoid problems, and maybe even produce better results
moritz that sounds both right and vague 20:17
pmichaud_ thus far "closer communication" tends to mean that rakudo devs have to monitor parrot changes closely.
whiteknight pmichaud_: we complained about die and friends, but there are no plans anywhere to change them now. Your comments were received and understood
pmichaud_ thus far "closer communication" seems to be parrot folks saying "as long as we improve our automated tools things will be okay". Our track record on that aspect is dismal. 20:18
cotto_work pmichaud_: That was my starting point. We're moving away from that thanks to your feedback.
pmichaud_ cotto_work: it's not just this time -- I've heard this refrain many times before ("automated tools") 20:19
cotto_work automated testing + communication
we didn't have one before
pmichaud_ api.yaml
that was an example of "automated tool" that was supposed to improve things but didn't.
cotto_work sorry. thought you meant testing
pmichaud_ no, whenever we have a problem, it's proposed that we develop a lot of new automated tools that will supposedly help alleviate the problem. 20:20
our record in this area is dismal.
cotto_work It's easier to write a tool than to remember something (or ingrain it in our developer culture)
whiteknight okay, let's no go there then. Let's call that a non-starter
pmichaud_ I apologize that I don't have an idea of what I want. I don't know what I want.
tewk__ api.yaml = "automated communication", "automated communication" isn't communication its only notification. 20:21
pmichaud_ I do know that as much as I hate the deprecation policy, it did promise that unstable events would occur at certain boundaries. (more)
cotto_work automated testing + manual communication
tewk__ I think we have all learned that you can't automate ocmmunication. but we can automate testing and notification which can lead to more prompt communication. 20:22
pmichaud_ I agree that we need to get rid of the deprecation policy. But more important (to rakudo) is for Parrot's goals to align closely with Rakudo's goals.... and I'm not encouraged by what I see so far.
whiteknight pmichaud_: what goals of Parrot do you think are not aligning well?
I think we're trying to make it obvious that our goal is a better Rakudo
cotto_work It's hard because Rakudo and Parrot largely attract distinct types of developer.
pmichaud_ I have no doubt that making a better Rakudo is a Parrot goal. Intention is clearly present. 20:23
but one of the items listed earlier as a "high priority" is Parrot sandboxing. That's totally unimportant to Rakudo at the moment.
whiteknight we put the deprecation policy in place, and we were still making refinements to it years after the fact. I think this new policy is also going to need iteration
cotto_work Knowing what will mess up Rakudo requires knowing Rakudo. Not a whole lot of Parrot's developers do. 20:24
whiteknight so we're not going to get it perfect today
pmichaud_ cotto_work: I agree, and I don't know how to fix that.
20:24 colomon joined
whiteknight We do work in parrot branches. Test rakudo et al against those branches. See what breaks and how significant the breakages are, if any. 20:24
Use that information to determine next steps
20:25 chromatic joined
pmichaud_ whiteknight: who does the testing? 20:25
chromatic Look, neither Parrot nor Rakudo is going to survive without Rakudo getting rid of encapsulation-breaking messes.
That can happen now or some eventual later, if that later ever comes and is significant.
whiteknight pmichaud_: whoever is making the branch
pmichaud_ whiteknight: if that happens, then I'm more hopeful.
whiteknight pmichaud_: or whoever volunteers to help
Tene out of curiosity, does Parrot have smoke tests running HLLs against new parrot commits yet?
whiteknight hello chromatic
pmichaud_ Tene: that doesn't quite work with branches, I don't think. 20:26
cotto_work I want to see communication when a change starts to look like a good idea, as the the change is implemented and when it's ready to merge.
Tene I remember hearing quite a while back that it was coming Real Soon Now, and seems relevant here.
pmichaud_ Tene: finding out that a branch merge breaks rakudo is often a bit late.
Tene: because it's generally undesirable to undo the merge.
Tene pmichaud_: IMO, people should be testing branches against rakudo before merging them, but they obviously currently aren't.
whiteknight it's possible we also maintain separate master/integration/bleed branches, or whatever, and cherry pick 20:27
pmichaud_ Tene: and the problem is that they need to be testing against Rakudo Star, not just the spectest suite.
it needs to be tested against Rakudo + modules
and we have to assume that the modules have sufficient tests
Tene IMO, parrot should be the first responsible party for dealing with changes that break rakudo, and they won't know that if nothing is testing that.
pmichaud_ because Rakudo Star is what we distribute to users, not just the latest compiler master branch
We can work on improving testing in Rakudo Star, yes. 20:28
Tene pmichaud_: how feasible does it sound to you to add a 'rakudotest' make target to parrot?
pmichaud_ Keep in mind that Rakudo Star doesn't always target or use the most redcent Rakudo.
*recent
whiteknight pmichaud_: what would be the most helpful is some kind of list of things that need to be included in integration tests regularly
we can certainly test rakudo star, modules, and other things if we have a list of things 20:29
pmichaud_ whiteknight: well, let's start by saying "Rakudo and NQP pass their test suites"
cotto_work If a feature isn't tested, I'm not going to worry about it. I'm all for running every test in whatever's in Rakudo *, but we can't worry about breaking things that don't tell us they're broken.
whiteknight pmichaud_: that's a good start
pmichaud_ we'll work on improving some sort of test coverage for Rakudo Star
but Rakudo Star isn't something that one can "git clone" and "make test"
whiteknight that's right. It's the responsibility of any dev to make sure they have plenty of test coverage
pmichaud_: we definitely want that, or some kind of a script that can set up all the necessary conditions for us 20:30
cotto_work pmichaud_: I don't care as long as it can be automated somehow.
pmichaud_ whiteknight: I'm not sure all devs and Parrot users will agree with that statement, fwiw.
just because Parrot adopts test-driven design doesn't mean all of its users will do so.
whiteknight pmichaud_: well, it certainly can't be our responsibility if Rakudo module X is not tested
that's true, but I'm not sure how else you identify a problem in a way that we will find useful
pmichaud_ whiteknight: well, that's why there was a deprecation policy :) 20:31
whiteknight bug reports, maybe, but we've had that mechanism for years
cotto_work pmichaud_: it's a cultural change we need to make to Parrot
whiteknight needs to sign out. Will be back later
pmichaud_ chromatic: your point about rakudo violating encapsulation is misplaced, I think. We've always recognized that Rakudo pokes into Parrot guts at its own peril. That's not what I'm talking about here. 20:32
chromatic That's the core of the problem as I see it.
pmichaud_ I don't.
I don't recall ever having a breakage where Parrot changed an internal and we complained or had difficulty adapting.
cotto_work pmichaud_: will you be happier if we say that frequent communication about Parrot changes and frequent running of any automatable tests is central to our new policy? 20:33
chromatic I recall not changing a lot of things because I didn't want to break internals Rakudo relied on.
pmichaud_ chromatic: I promise not to complain if you change internals and it breaks Rakudo.
(because of Rakudo's reliance on those internals.) 20:34
moritz also iirc things have gotten much better on the encapsulation front in the last year or two
chromatic I guess I've been misunderstanding your ideas in this discussion then; that seems like exactly what you don't want to see!
Tene pmichaud_: how feasibly could star become a branch in the rakudo repo?
moritz Tene: it makes no sense at all
pmichaud_ Tene: Not going to happen -- that goes against the point of separating compiler and distribution.
Tene nods. 20:35
pmichaud_ s/point/purpose/
NotFound About the NCI: Is that a problem of Rakudo, of Rakudo users, or both?
pmichaud_ chromatic: what is being discussed are wholesale API changes, not just internal refactors.
NotFound: The compiler doesn't use NCI at all. Some modules built for Rakudo (and included with Rakudo Star) use NCI. 20:36
chromatic: and really what I'm complaining about are refactors and API changes that result in Rakudo breaking or having to adapt but providing no real visible benefit to Rakudo.
PerlJam Tene: if Rakudo Star were built with some tool like Dist::Zilla and was configured to save the dist.ini on release, I think the automation you seek could be had.
NotFound pmichaud_: What's the problem, then? Can't these modules be updated to parrot changes? 20:37
pmichaud_ NotFound: who will do the updates?
moritz NotFound: I think the problem is that we still don't know how
chromatic I don't know what "no real visible benefit to Rakudo" means in this context. A smaller, faster, lighter, simpler, more correct Parrot seems like an obvious benefit to Rakudo to me.
moritz NotFound: mberends and others have tried to fix Zavolaj to deal with the changes, and succeeded only partially
pmichaud_ NotFound: the problem we had with NCI was that it broke things and nobody considered that they might break. We discovered the breakage *after* doing a release.
chromatic Especially if those changes make Rakudo faster, easier, smaller, simpler, and more correct. 20:38
pmichaud_ chromatic: in my experience, though, the refactors have not resulted in faster, smaller, lighter.
certainly they weren't for PCC.
NotFound pmichaud_: yes. I also discovered the problems in my code. I fixed it.
Tene NotFound: parrot developers should be the first point of contact for these changes, and only pushed off to rakudo devs if necessary, but right now parrot devs are only finding this out when notified by rakudo folks. 20:39
pmichaud_ NotFound: not only that, but the refactor removed features that we absolutely depended on, and didn't provide a viable replacement path
and our requests for help were basically "you're on your own, deal with it"
NotFound The point is that people can't reasonably ask at the same time for fast changes and for not breaking anything.
Tene NotFound: the solution I've always seen proposed is HLL smoke testing, but that's apparently never going to happen. 20:40
pmichaud_ NotFound: I think it's reasonable to ask for "don't break anything that isn't a pressing problem for us", though.
cotto_work pmichaud_: give us credit for eventually fixing the situation, at least.
pmichaud_ cotto_work: ....*who* fixed it?
NotFound pmichaud_: What are these removed features? There are tickest for them?
pmichaud_ I guarantee it wasn't a Parrot dev that fixed it.
(unless you count me as the Parrot dev) 20:41
NotFound: the 't' return type from NCI.
not to mention a fair number of NCI signatures that various Rakudo libs were using.
NotFound pmichaud_: I was told that that problem was solved by using the nci helper library. 20:42
chromatic Alright, so blame and credit duly assigned, the suggestion is "Parrot should work on things that Rakudo wants."
pmichaud_ NotFound: which occurred *after* the fact.
NotFound: which occurred by *me* writing it. 20:43
Tene considers the idea of a hook on github that rejects branch merges without a 'passes rakudotest' commit message.
pmichaud_ chromatic: speaking from a purely selfish point of view -- that's really what I've been saying for a couple of years.
chromatic Hey, I've offered.
20:44 wknight-phone joined
pmichaud_ I'm fine if Parrot says "no, we have other things we need to focus on also", but so far those "other things" have generically been to rakudo's detriment. 20:44
*generally
chromatic If that's the position of Rakudo developers, there's the impasse. 20:46
pmichaud_ I don't understand, can you clarify?
chromatic If you believe that pretty much any change in Parrot is going to screw Rakudo over, of course you're not interested in changes in Parrot.
pmichaud_ thanks for the clarification. you may be correct. 20:47
that's been my experience, although there are a few notable exceptions.
chromatic I see no point in enumerating past failures. I think most people here agree that things have not worked out as well as anyone has hoped. 20:48
cotto_work indeed 20:49
pmichaud_ I guess I'm concerned about the many changes taking place that aren't being done by looking at Rakudo's needs early/first.
s/taking place/proposed/
chromatic I'd like to think that most people here agree that they'd like things to work better in the future, but if there's no hope of that, there's really no point to this discussion.
cotto_work It's a fundamental problem.
wknight-phone at some point we need to get passed years-old bad experiences.
pmichaud_ wknight-phone: "years-old"?!?! 20:50
cotto_work Unless we want to have more Parrot devs hack on Rakudo (or vice versa), the best solution is frequent communication
wknight-phone we didn't have the same leadership for pcc refactors.
pmichaud_ ...what about nci refactors?
cotto_work That's an acknowledged failure.
pmichaud_ what about the proposal for merging :load and :init ?
TimToady I don't think he was excluding the recent ones :)
dukeleto ~~
wknight-phone that was cancelled. 20:51
and I told you about the replacement (:tag)
and that is in master now 20:52
NotFound Note there is still pending a NCI change that risk to break things.
wknight-phone nci is hard. patience appreciated
pmichaud_ wknight-phone: yes, but as yet there's not much benefit to rakudo. If it means that future changes become plausible, then perhaps. 20:53
wknight-phone will lay out benefits for rakudo tonight. 20:54
chromatic pmichaud_, if the biggest change to the deprecation policy were "Nothing removed without a viable replacement in place and acceptable to Rakudo", would that assuage your concerns?
pmichaud_ chromatic: partially (more)
it's not just removals that are a problem -- it's changes that slow performance even more.
NotFound In particular, unmanaged struct is candidate for deprecation since some time. Are we ready for its end of cycle?
pmichaud_ it's also changes that require us to update our toolsets and codebase for no measurable benefit. 20:55
wknight-phone we've been yelled at this week about focusing too much on performance.
pmichaud_ wknight-phone: you were? hopefully not by me.
wknight-phone not you. 20:57
pmichaud_ a rakudo dev?
wknight-phone it doesn't matter who
pmichaud_ it does to me.
of
rakudo's #1 priority is performance right now. if someone's working against that, it's against rakudo's goals. 20:58
20:59 wknight-phone joined
pmichaud_ okay, I've hijacked #parrotsketch, and I didn't necessarily want to do that. 21:00
21:01 PacoLinux_ joined
pmichaud_ I agree that this is necessarily an evolutionary process. 21:01
I'm not expecting things to be fixed all at once.
Tene I'd like to assert that any proposed change to rakudo's policies here needs to include a way to make sure it actually happens.
pmichaud_ ...rakudo's policies?
Tene erm
parrot's
chromatic Parrot has a lot of mess to clean up, and a lot of that mess has leaked into Rakudo. 21:02
wknight-phone our bad.
Tene right now, asking parrot devs to go out and manually test things against "some rakudo stuff" isn't happening.
pmichaud_ it's happening more often than it used to, though.
I do recognize that.
Tene At least one part of that is "someone" making an executable test of the things rakudo wants verified. 21:03
pmichaud_ it used to be a "oh, we really should do that". More often it's actually checked these days.
21:03 wknight8112 joined
pmichaud_ in some ways the effort to make parrot "lighter, faster, efficient" is really just pushing the work to higher levels of the abstraction tree. That doesn't help us. 21:04
cotto_work gist.github.com/1198962
there's our starting point. Let's iterate. 21:05
pmichaud_ cotto_work: maybe talk to #perl6 ?
chromatic I see it more as pushing the work to the *right* levels of abstraction.
Tene I don't know whether there's a clear expression of responsibilities for changes that cause problems for rakudo. I'd personally prefer something like "Nothing is merged without passing rakudotest", and parrot devs taking responsibility first for figuring out an appropriate response to breakage.
pmichaud_ chromatic: I agree that getting things to the right level of abstraction is important.
dukeleto Tene: we are making progress on HLL testing. cotto++ recently wrote a utility to smoke against a large subset of hll's and libs
pmichaud_ sometimes I think things are being pushed higher simply to make parrot's job easier.
not because it makes things better. 21:06
wknight8112 if parrot does it wrong rakudo needs to redo it anyway.
pmichaud_ and yes, a lot of what nqp and rakudo have done is to provide re-done replacements for things where parrot doesn't match what we need
Tene dukeleto: Sorry, but I've heard "making progress" at least four years ago, I think. If it ever actually happens, please let me know. I vaguely recall making a commitment to work on HLL interop again if HLL smoke testing ever happened. 21:07
chromatic Let's get those workarounds out of NQP and Rakudo then!
NotFound BTW I don't think that blaming Lua on the mailing list is going to help anything.
pmichaud_ chromatic: why? how does that help Rakudo?
Tene pmichaud_: What are your thoughts on "adopt and pull down 6model as our object model replacement" 21:08
pmichaud_ Tene: I agree it should happen.
Tene: but at this moment, getting 6model into Parrot isn't a huge Rakudo priority. It's just refactoring work that doesn't give us any direct benefit.
chromatic If behavior Rakudo wants is *in* Parrot, it'll be tested and maintained as part of Parrot, not as a part of NQP/Rakudo that might depend on Parrot internals.
Tene Well, some benefit. IIRC 6model does some work that wouldn't need to happen if it wasn't trying to work with PMCs. 21:09
But, yes, understood.
cotto_work Tene: list what more you need in order to be convinced that working on hll interop is a good idea. 21:10
pmichaud_ Tene: I'm not saying it's not a priority, it's just much lower than our other priorities at this time.
chromatic: point taken 21:11
chromatic: at this time, though, I think jnthn++ and I would be worried about parrot adopting things before they're relatively stable
right now we have a lot of freedom to rework and refactor things internally that we'd lose if it becomes a part of parrot 21:12
(granted, eliminating the deprecation policy would restore a lot of that freedom)
s/would/could/
chromatic Sure, but a better container model, improved PCC, reworked lexicals, namespace improvements, better serialization are all dramatic improvements that Rakudo/NQP oughtn't need to do.
Tene cotto_work: I don't think I've ever said that working on HLL interop isn't a good idea. I think HLL interop is a great idea, and it was my primary driver in my work on Parrot in the past, and feeling like nobody else cared about HLL interop at all was the primary thing that killed my interest in contributing to parrot. I'd be a bit surprised if there was anyone involed with parrot who more felt like HLL interop was a ...
... good idea to work on.
cotto_work Tene: let me clarify. What would convince you that it's a good time to start working on interop again? 21:13
Tene pmichaud_: how far would "Exceptions are permitted as long as you have arranged for appropriate fixes and updates to public projects using Parrot" go towards giving back that freedom? 21:14
pmichaud_ Tene: I don't know; this is kind of sudden for us. jnthn++ and I are still figuring out how things might work there. 21:15
We made our plans at YAPC::EU under the assumption that parrot's dep policy wasn't likely to change anytime soon.
Tene cotto_work: I have no idea. Stopping parrot contributions wasn't really an explicit decision. The other contributing factors were burnout and depression, and it's only recently that I've started any recreational coding again. I really loved working on Parrot, though, so if I could find a way to make that happen again, I'd be pretty happy. 21:16
pmichaud_ and as I started, we're both extremely happy to see that the dep policy can disappear, but not if it invites a free-for-all of changes that cause us to redo a lot of stuff we just got through redoing. 21:17
chromatic What if there were a list of possible changes Parrot could make? Could Rakudo make a list of its top priorities?
pmichaud_ I can't resist pointing out we've made these lists in the past... I admit it's not fair to point that out here. :)
I also admit that chromatic++ offered to work on them and we deferred him from it. 21:18
Tene Ah; I haven't been following parrot politics lately (or even this channel before I jumped in), so I wasn't aware of the context.
pmichaud_ I think that PCC is our current pain point for Rakudo. GC also, but not as much as it once was. 21:19
afaik, we don't have any plans to try to "redo" PCC on our own.
chromatic The binder still exists. That's a pain point.
pmichaud_ I'd need to check with jnthn, but if a PCC refactor were to cause us to have to make a bunch of changes to our code but got some good performance wins, we'd be all in favor of it. 21:20
Tene cotto_work: I've long expressed a public invitation for people to do whatever they like to try to get me motivated to work on Parrot again, but I don't personally understand the contributing factors to my motivation for recreational programming well enough to offer useful advice there.
chromatic I'd like to see all that binder code go away. I'd settle for 80% of it.
jnthn chromatic: And where exactly are you proposing that the stuff it does should go? 21:21
cotto_work Tene: ok
pmichaud_ Exceptions is another pain point, but I'm hesitant to ask Parrot to work on those because as yet we can't exactly say what we *do* need. My fear there is that something will happen similar to PCC and exceptions in the past -- it'll get a new API and a substantial reimplementation, but it'll end up being as slow and we won't be able to use it.
chromatic Fixing exceptions *and* closures *and* subs *and* namespaces all relies on the same foundations. 21:22
Tene Exceptions is the other thing I've liked working on, and long wanted to work on again.
NotFound Now that I think about it: Do we have some plan about the lowercasing of HLL namespace names? 21:23
pmichaud_ chromatic: afaik, fixing namespaces isn't a priority for us. And fixing subs/closures isn't a priority, except if they can be made faster.
if you're saying that all of these things need to be fixed in order for any performance improvements to occur, I don't disagree, but it seems like some sort of substantial branch has to occur there first. 21:24
chromatic I'm saying that much of that mess is because the underlying philosophical model is broken.
pmichaud_ Yes, and we've been saying that for years.
("we" is collective everyone-in-parrot-and-rakudo "we")
chromatic If Parrot had a working notion of lexical scope separate from a named Sub in a NameSpace, a lot of that mess would go away.
Tene NotFound: I complained about that inconsistency years ago when I first ported rakudo and the other languages into their own HLL namespace 21:25
pmichaud_ chromatic: I think Parrot has that already, though.
chromatic Not backed into Packfiles. 21:26
moritz lexicals indepent from Sub? that would be news to me
pmichaud_ perhaps not as directly as we'd like, but it definitely handles lexically scoped subs. Rakudo (both nom and ng) have successfully done this in the past.
chromatic baked into/backed by
cotto_work So it sounds like we have a good starting point for change management. Let's continue thinking and discussing how we can keep Rakudo in the loop to pmichaud_, etc's satisfaction over the coming weeks.
pmichaud_ Packfiles know lexical scoping -- that's :outer 21:27
granted the subs don't appear as lexical symbols, and that could be a huge improvement.
chromatic You can't freeze an outer lexical context which contains a constant exception handler, for example.
You also can't easily avoid recursive lookups of lexical symbols bound to scopes known at compilation time. 21:28
pmichaud_ subs need more attributes hung on them, yes.
21:28 bluescreen joined
pmichaud_ or, they need to be more primitive, and we make it easier for HLLs to derive their own sub datatypes 21:29
jnthn Well, generally delegation works out rather better than subtyping.
pmichaud_ jnthn: right.
chromatic and then you cross the C/PIR boundary and performance goes away.
So the inferior runloop problem needs solving and the vtable PIR/C distinction needs addressing and you want a MOP.... 21:30
moritz finds that the discussion has lost a bit of focus 21:31
NotFound You don't need to isa Sub to be invokable. 21:32
moritz so, we seem to be in violent agreement that the deprecation policy needs to be changed, but we don't know yet exactly how. Correct?
Tene afair, that's been the case since deprecation policy day one
pmichaud_ moritz: correct. But I also think a recognition that the deprecation is a necessary but not sufficient cultural change.
*change to deprecation policy
chromatic: yes, I agree that Parrot has carried forth a lot of baggage. I don't have any strong ideas for how to address that. 21:34
Rakudo is not culturally or resourcefully in a place where we can spend a lot of time refactoring internals if they don't produce good performance improvements in the near term. 21:35
We just went through a major refactor, and we know where we can find performance improvements that don't require a lot of changes to Parrot at this point.
cotto_work If I can interrupt this discussion for a bit, we ought to produce some goals for the coming week.
pmichaud_ cotto_work: please interrupt :) 21:36
cotto_work It sounds like working with pmichaud_, moritz, et al to form a new support policy will be a goal for at least the next week.
other suggestions? 21:37
pmichaud_ I'll be glad to review and make suggestions for the support policy, at least from a rakudo perspective. 21:38
tadzik so did we settle on anything re the language interop?
dukeleto cotto_work: instructions/docs for allhlltest and setting it up to run automatically
pmichaud_ I have a comment on language interop but don't want to interrupt cotto's interruption.
tadzik rethrow()
dukeleto cotto_work: also, making sure trac.parrot.org has a valid SSL cert sooner rather than later. This means bugging OSUOSL 21:39
cotto_work dukeleto: that's mostly reading the source and inline pod atm
dukeleto: can anyone involved in Parrot take care of that? 21:40
I have no idea what's involved.
dukeleto cotto_work: sure. But we need to add more pointers to it, like on the wiki and/or git_workflow.pod
cotto_work dukeleto: sounds like our second goal 21:41
pmichaud_: your thoughts?
pmichaud_ on hll interop? 21:42
dukeleto cotto_work: last I know, whiteknight contacted OSUOSL about installing the new cert, and that is all I know
cotto_work pmichaud_: yes
dukeleto: third goal (I'm keeping a list)
pmichaud_ a "frankly brutal" assessment of hll interop might be that it's a potentially nice feature that nobody's really interested in (or interested in anymore) .... (more) 21:43
Tene My recommendation for a task for this week is to get a rakudo test easily executable from parrot (make rakudotest?)
cotto_work Tene: already part of allhlltest (and definitely the longest-running part) 21:44
dukeleto cotto_work: as a meta-goal, we received a lot of different and good feedback to your thread on parrot-dev. We need to parse through it and take actions based on them
pmichaud_ it's possible that nobody's interested because we don't have enough hlls on parrot to interop, and/or that the ones we have change too frequently for interop to be stable enough to be even interesting, much less useful.
Tene ahh; that's nice to hear
dukeleto Tene: make allhlltest # tests 10 or so HLL's and libraries
pmichaud_ but I also wonder if hll interop comes up because parrot doesn't have much else to tout at the moment. 21:45
cotto_work Tene: to be fair, allhlltest is a couple hours old at this point. ;)
pmichaud_ (I fully admit that might not be a fair comment... I've only wondered about it and not examined it critically,)
Tene pmichaud_: afaict, nobody's ever been interested in hll interop (except for rakudo users wanting to use parrot libraries several times) 21:46
pmichaud_ Tene: right.
Tene: and now we can no longer really use parrot libraries anyway
because they're "foreign" objects to the p6 runtime. We have plans and thoughts about how to handle them, but it's not a super-high priority. 21:47
Tene pmichaud_: given a hash of subs, you can't write an import routine that does something meaningful with them? 21:48
NotFound I've done interoperability tests several times, without much problem. 21:49
pmichaud_ Tene: oh, we can call the subs. We can't handle the objects they return. 21:50
unless they just happen to be one of Integer/Float/String, in which case we unbox and rebox them into p6 equivalents.
Tene One more reason to get 6model into parrot core. ;) 21:51
pmichaud_ Indeed.
but yes, if rakudo-using-parrot-libs was the primary user of hll interop... that's pretty much gone away. 21:52
tadzik what about blizkost?
pmichaud_ I don't know where blizkost sits atm. 21:53
PerlJam Would it help if the parrot devs listed all of the things they want to do with Parrot and the Rakudo devs listed all of the things they want to do with Rakudo, and then everybody get together to find alignments between them and to prioritize the work?
(say ... next #ps?)
pmichaud_ PerlJam: We want Rakudo to be faster. That's been our #1 request for the last 22 months, I think. 21:54
Tene pmichaud_: if I did work on HLL interop again, what would it take for you to tell me with reasonable confidence that rakudo won't break and discard it again this time?
pmichaud_ Tene: if you work on HLL interop at the nqp level, I'd say it might exist for a while.
anywhere else, and I'd not be able to say much with reasonable confidence. :) 21:55
PerlJam: beyond that, we don't want to be paying too many upgrade taxes that aren't directly related to making Rakudo faster. 21:56
Tene Hmm. Okay. Maybe I'll check in again next year, then. I don't think "might exist for a while" is enough for me.
pmichaud_ We're willing to pay any upgrade tax that is a result of our making incorrect/undocumented use of Parrot internals, as we always have been.
cotto_work pmichaud_: do you mind unkilling hll interop? 22:01
pmichaud_ ..."unkilling hll interop"? 22:02
cotto_work "might exist for a while" doesn't inspire confidence
pmichaud_ nqp doesn't make any pretenses towards stability just yet. 22:03
cotto_work Sure, but can't hll interop be tested?
pmichaud_ I don't understand.
cotto_work nqp does a good job of passing its test suite
if tene does hll interop work that effects nqp, with tests, can't we ensure that those tests continue to pass? 22:04
I don't see where the uncertainty comes from. 22:05
pmichaud_ I think you and I are thinking of different things.
cotto_work It's possible. 22:06
pmichaud_ what does "hll interop" mean to you?
I suspect to Tene (and me) that it means that Rakudo can make use of libraries written in other languages. 22:07
cotto_work yes
pmichaud_ If those other languages are nqp-based, then I think we might be able to provide some level of hll-interop that will be relatively stable.
cotto_work and the mechanism that allows that should be testable 22:08
pmichaud_ I can't guarantee it though, because nqp itself isn't entirely stable yet.
and if nqp needs to change to meet one of its other goals, then hll interop at the nqp level could break.
cotto_work its rewrites are becoming progressively less extensive (from what I can tell)
pmichaud_ but there's a big one on the horizon.
we need to move pct into nqp. 22:09
that's not just "rewrite pct as nqp", but also to do some refactors to better support multi-vm-backend and to make type information more visible at the lower layers of the optrees
cotto_work which could have a significant impact on hll interop 22:10
pmichaud_ correct.
so, Tene's question was "rakudo won't break and discard it again"
and my confidence on that front isn't that high as things stand "today" 22:11
cotto_work Alright. It sounded like "we don't care" more than "we genuinely don't know". My mistake.
pmichaud_ my answer was also intended to indicate that hll interop for rakudo is likely to occur at the nqp level instead of the parrot one 22:12
it's definitely not intended as "we don't care", but more of "I can't make many guarantees for a short while"
cotto_work Thank you for clarifying.
I think I need to wrap up #ps. We're nearing 3 hours and I allegedly have a dayjob. 22:14
pmichaud_ heh
cotto_work the goals I have are:
GOAL 1: work with Rakudo on a new support policy
GOAL 2: filter through feedback on support policy, keep track of the important bits
GOAL 3: document allhlltest (git_workflow.pod)
GOAL 4: new SSL cert
GOAL 5: figure out a rough roadmap of what we want to change (whiteknight)
pmichaud_ moving to #parrot and #perl6, then :)
22:16 NotFound left 22:17 chromatic left 22:41 pmichaud_ left 22:54 whiteknight joined 22:55 Coke joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!