Camelia, the Perl 6 bug

IRC log for #parrotsketch, 2011-09-06

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

All times shown according to UTC.

Time Nick Message
07:21 contingencyplan joined #parrotsketch
08:02 lucian joined #parrotsketch
12:00 bluescreen joined #parrotsketch
12:17 bluescreen joined #parrotsketch
14:35 bluescreen joined #parrotsketch
17:48 ilbot2 joined #parrotsketch
17:48 Topic for #parrotsketch is now 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: http://irclog.perlgeek.de/
18:03 contingencyplan joined #parrotsketch
18:47 whiteknight joined #parrotsketch
18:59 NotFound joined #parrotsketch
19:00 whiteknight WHAT I DID:
19:00 whiteknight * Working on Jaesop (formerly JSOP). Am most of the way towards a working stage 0.
19:01 whiteknight * Have the Jaesop object model working more-or-less correctly. Redid the test suite to handle the new semantics.
19:01 whiteknight * Suggested a few winxed changes that would make Jaesop life much easier
19:01 whiteknight * 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.
19:01 whiteknight * Playing with a few new Rosella libraries and misc cleanups throughout.
19:01 whiteknight * On suggestion from jnthn++, set up, tested, and merged the whiteknight/pmc_is_ptr branch. Up to 25% improvement on some benchmarks.
19:01 whiteknight * With help from nine++, the whiteknight/kill_threads branch is ready for testing and eventually merger.
19:01 whiteknight * Talked with cotto about the deprecation policy. Said cursewords. Am happy to see it go.
19:01 whiteknight * Looked at soh_cah_toa++'s new debugging metadata stuff. Going to get more involved in that.
19:01 whiteknight * Drawing up some concrete plans for changes to PCC, IMCC, and Packfiles that are going to need to happen soon.
19:01 whiteknight WHAT I WILL DO
19:01 whiteknight * Finish refactor of Rosella Harness and the new TAP parser
19:01 whiteknight * Continue playing with Jaesop, want to get the remaining few bits of syntax generating proper winxed code.
19:01 whiteknight * Get my mind back into 6model. Need to rethink some things.
19:01 whiteknight * Merge whiteknight/kill_threads
19:01 whiteknight * Put together some code for precise GC
19:01 whiteknight EOR
19:05 whiteknight oh, also merged in some pmc_is_ptr fixes from not_gerd++
19:11 NotFound What I did:
19:11 NotFound -parrot
19:11 NotFound * Just testing
19:11 NotFound -winxed
19:11 NotFound * Fix HLL namespace modifier and take HLL into account in several
19:11 NotFound operators and statemens.
19:11 NotFound * Several fixes and refactors.
19:11 NotFound What I will do:
19:11 NotFound More improvements to HLL handling in winxed
19:11 NotFound EOR
19:18 Util # Done
19:18 Util * Read cotto++ thoughts on Parrot, and am encouraged by the direction.
19:18 Util # Plan to do:
19:18 Util * Read new purchase: The Garbage Collection Handbook
19:19 Util # Blockers:
19:19 Util * $WORK
19:19 Util # 7-day ticket report:
19:19 Util 1  closed: done
19:19 Util 4  closed: fixed
19:19 Util 4  new
19:19 Util .end
19:25 cotto_work *did:
19:25 cotto_work - more all_hll_test.pl work, should be "ready" for use
19:25 cotto_work -- all projects are welcome, including Rakudo-based projects that pass their tetss
19:25 cotto_work - sent out message about reassessing (and dropping) our deprecation policy, among other things
19:25 cotto_work -- lots of good feedback
19:25 cotto_work -- uneasy concerns from Rakudo
19:25 cotto_work -- Parrot needs better communication with Rakudo about proposed changes.
19:25 cotto_work - looked at and hacked on mls++'s sub profiling branch
19:25 cotto_work -- needs a lot of cleanup, has great potential
19:25 cotto_work -- it's already proving highly useful for Rakudo, so it or something like it will eventually get merged
19:25 cotto_work *todo
19:25 cotto_work - figure out what a post-deprecation policy future looks like for Parrot, Rakudo and other users
19:25 cotto_work - finish profiling docs
19:25 cotto_work *eor
19:27 tewk__ joined #parrotsketch
19:30 whiteknight hello
19:30 cotto_work hello
19:31 NotFound Hola
19:32 Util Hello
19:33 cotto_work How's this week gone?
19:34 whiteknight pretty darn good
19:34 cotto_work I'd say so.
19:35 cotto_work 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
19:35 Util Just barely dodged two hurricanes (New York and Alabama), and not cotto++ starts an earthquake :)
19:35 Util s/not/now/
19:35 whiteknight obviously their needs are going to be influencing our decisions at a finer-grained level than it has in the past two years
19:36 whiteknight their/there
19:36 whiteknight bleh
19:38 cotto_work I don't see any questions queued, so policy disucssion probably isn't out of place.
19:39 whiteknight go for it
19:40 cotto_work In general, I want notification and testing to replace our deprecation policy.
19:40 cotto_work all_hll_test.pl is a part of that.
19:40 whiteknight more integration testing and better integration testing are key
19:40 cotto_work talking with active HLL developers about proposed changes is another
19:42 cotto_work 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:46 cotto_work 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
19:46 whiteknight I think it will all go better if we think it's the right thing to do
19:47 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:48 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
19:50 cotto_work It won't hurt us to be explicit about that sort of thing.
19:51 whiteknight We're going to try to do things more quickly, without going completely crazy
19:51 whiteknight When we make changes, make sure HLLs get fixed quickly
19:51 cotto_work run all_hll_test early and often
19:51 whiteknight that's a make target?
19:51 cotto_work it can be
19:52 whiteknight it should be
19:52 cotto_work give me a minute
19:54 cotto_work it is
19:54 whiteknight awesome
19:54 cotto_work "allhlltest"
19:55 cotto_work It's guaranteed not to work on all platforms.  Patches are welcome. ;)
19:55 Coke I'll get it working on windows.
19:56 cotto_work I don't think it'll take too much effort.  Coke++
19:56 mikehh joined #parrotsketch
19:56 Coke is it in master now?
19:57 cotto_work yup
19:58 Coke ORLY? didn't see it on an update. found it in all-hll-test, though.
19:59 pmichaud_ joined #parrotsketch
19:59 cotto_work Coke: you may not be current
20:00 Coke cotto_work: also, System::Command barfs on windows, apparently.
20:00 Coke so, will take some effort.
20:01 cotto_work I am disappoint
20:01 pmichaud_ When we make changes, make sure HLLs get fixed quickly
20:01 pmichaud_ ...how exactly might this happen?
20:02 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.
20:02 whiteknight patches, pull request, detailed guidance, etc
20:02 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)
20:03 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.
20:03 cotto_work This is just a thought, but we might start using pull requests for the whole workflow.
20:03 whiteknight if it breaks, we fix it. that becomes priority
20:03 pmichaud_ whiteknight: what about Rakudo's DarkPAN?
20:03 pmichaud_ see, for example, the NCI changes from earlier this year.
20:03 cotto_work pmichaud_: is that DarkPAN or just UntestedPAN
20:03 cotto_work ?
20:03 whiteknight pmichaud_: I'm not saying it's going to be perfect. It is going to be a learning process.
20:03 Coke (sys:command - error might be ignorable.)
20:04 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.
20:04 mikehh running the rakudpo test suite against changes before pushing would help
20:04 Coke I think it's premature to spend cycles on parrot or rakudo's darkpan at this point.
20:04 pmichaud_ there are people building modules and programs for Rakudo that aren't part of the rakudo/rakudo repository
20:04 pmichaud_ Coke: except that we've already had breakages in Rakudo's userbase
20:05 cotto_work pmichaud_: if we can pull, we can automatedly test
20:05 pmichaud_ see, for example, MiniDBI and Zavolaj
20:05 whiteknight there's a difference between the darkpan and the module ecosystem
20:05 Util +1 to mikehh's comment
20:05 whiteknight darkpan is the stuff we don't know about, but assume must be out there somewhere
20:05 cotto_work mikehh: absolutely.  That's just the first step though.
20:05 whiteknight we know about minidbi and zavolaj, so they hardly qualify as "darkpan"
20:05 mikehh we need to incorporate that in some form of testing
20:05 whiteknight and we need to test against them regularly
20:05 pmichaud_ what about Rakudo applications?
20:05 cotto_work mikehh: see allhlltest
20:05 pmichaud_ do we know about all of those?
20:06 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.
20:06 pmichaud_ I know what I don't want.
20:06 NotFound Are wa saying that we are going to be able to change things, as long as nothing changes?
20:06 Coke fair enough.
20:06 Coke (to pmichaud)
20:06 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.
20:07 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?
20:07 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.
20:07 pmichaud_ cotto_work: not just "who maintain", but also "who use"
20:07 pmichaud_ although if "who maintain" know all of the details of "who use", that can be a surrogate.
20:08 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 whiteknight effected
20:08 moritz joined #parrotsketch
20:08 jnthn joined #parrotsketch
20:09 cotto_work the Rakudo cavalry arrive
20:09 cotto_work well, more of them ;)
20:10 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
20:10 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.
20:11 pmichaud_ 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
20:11 whiteknight we haven't deleted the policy yet
20:11 cotto_work pmichaud_: I apologize for not including you specifically.  I talked with masak and moritz earlier about it.
20:12 cotto_work 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
20:12 whiteknight I think we are going to have a lot of refinements to make as a group
20:13 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?
20:13 moritz agreed. And we need to be clear that it's changing the policy, not aborting it
20:13 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.
20:14 pmichaud_ 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
20:14 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.
20:14 pmichaud_ whiteknight: I'm saying it's worse than that.
20:14 pmichaud_ 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.
20:15 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.
20:15 whiteknight if we are in closer communication more often, I think we can avoid problems, and maybe even produce better results
20:17 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.
20:17 whiteknight pmichaud_: we complained about die and friends, but there are no plans anywhere to change them now. Your comments were received and understood
20:18 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.
20:19 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
20:19 cotto_work we didn't have one before
20:19 pmichaud_ api.yaml
20:19 pmichaud_ that was an example of "automated tool" that was supposed to improve things but didn't.
20:19 cotto_work sorry.  thought you meant testing
20:20 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 pmichaud_ our record in this area is dismal.
20:20 cotto_work It's easier to write a tool than to remember something (or ingrain it in our developer culture)
20:20 whiteknight okay, let's no go there then. Let's call that a non-starter
20:20 pmichaud_ I apologize that I don't have an idea of what I want.  I don't know what I want.
20:21 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)
20:21 cotto_work automated testing + manual communication
20:22 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.
20:22 whiteknight pmichaud_: what goals of Parrot do you think are not aligning well?
20:22 whiteknight I think we're trying to make it obvious that our goal is a better Rakudo
20:22 cotto_work It's hard because Rakudo and Parrot largely attract distinct types of developer.
20:23 pmichaud_ I have no doubt that making a better Rakudo is a Parrot goal.  Intention is clearly present.
20:23 pmichaud_ but one of the items listed earlier as a "high priority" is Parrot sandboxing.  That's totally unimportant to Rakudo at the moment.
20:23 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
20:24 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
20:24 pmichaud_ cotto_work: I agree, and I don't know how to fix that.
20:24 colomon joined #parrotsketch
20:24 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 whiteknight Use that information to determine next steps
20:25 chromatic joined #parrotsketch
20:25 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.
20:25 chromatic That can happen now or some eventual later, if that later ever comes and is significant.
20:25 whiteknight pmichaud_: whoever is making the branch
20:25 pmichaud_ whiteknight: if that happens, then I'm more hopeful.
20:25 whiteknight pmichaud_: or whoever volunteers to help
20:25 Tene out of curiosity, does Parrot have smoke tests running HLLs against new parrot commits yet?
20:25 whiteknight hello chromatic
20:26 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.
20:26 Tene I remember hearing quite a while back that it was coming Real Soon Now, and seems relevant here.
20:26 pmichaud_ Tene: finding out that a branch merge breaks rakudo is often a bit late.
20:26 pmichaud_ Tene: because it's generally undesirable to undo the merge.
20:26 Tene pmichaud_: IMO, people should be testing branches against rakudo before merging them, but they obviously currently aren't.
20:27 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.
20:27 pmichaud_ it needs to be tested against Rakudo + modules
20:27 pmichaud_ and we have to assume that the modules have sufficient tests
20:27 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.
20:27 pmichaud_ because Rakudo Star is what we distribute to users, not just the latest compiler master branch
20:28 pmichaud_ 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?
20:28 pmichaud_ Keep in mind that Rakudo Star doesn't always target or use the most redcent Rakudo.
20:28 pmichaud_ *recent
20:28 whiteknight pmichaud_: what would be the most helpful is some kind of list of things that need to be included in integration tests regularly
20:29 whiteknight 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"
20:29 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.
20:29 whiteknight pmichaud_: that's a good start
20:29 pmichaud_ we'll work on improving some sort of test coverage for Rakudo Star
20:29 pmichaud_ but Rakudo Star isn't something that one can "git clone" and "make test"
20:29 whiteknight that's right. It's the responsibility of any dev to make sure they have plenty of test coverage
20:30 whiteknight 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.
20:30 pmichaud_ whiteknight: I'm not sure all devs and Parrot users will agree with that statement, fwiw.
20:30 pmichaud_ just because Parrot adopts test-driven design doesn't mean all of its users will do so.
20:30 whiteknight pmichaud_: well, it certainly can't be our responsibility if Rakudo module X is not tested
20:30 whiteknight that's true, but I'm not sure how else you identify a problem in a way that we will find useful
20:31 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
20:31 cotto_work pmichaud_: it's a cultural change we need to make to Parrot
20:31 * whiteknight needs to sign out. Will be back later
20:32 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.
20:32 pmichaud_ I don't.
20:32 pmichaud_ I don't recall ever having a breakage where Parrot changed an internal and we complained or had difficulty adapting.
20:33 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.
20:33 pmichaud_ chromatic: I promise not to complain if you change internals and it breaks Rakudo.
20:34 pmichaud_ (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
20:34 chromatic I guess I've been misunderstanding your ideas in this discussion then; that seems like exactly what you don't want to see!
20:34 Tene pmichaud_: how feasibly could star become a branch in the rakudo repo?
20:34 moritz Tene: it makes no sense at all
20:34 pmichaud_ Tene: Not going to happen -- that goes against the point of separating compiler and distribution.
20:35 * Tene nods.
20:35 pmichaud_ s/point/purpose/
20:35 NotFound About the NCI: Is that a problem of Rakudo, of Rakudo users, or both?
20:35 pmichaud_ chromatic: what is being discussed are wholesale API changes, not just internal refactors.
20:36 pmichaud_ NotFound: The compiler doesn't use NCI at all.  Some modules built for Rakudo (and included with Rakudo Star) use NCI.
20:36 pmichaud_ 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.
20:36 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.
20:37 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?
20:37 moritz NotFound: I think the problem is that we still don't know how
20:37 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.
20:37 moritz NotFound: mberends and others have tried to fix Zavolaj to deal with the changes, and succeeded only partially
20:37 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.
20:38 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.
20:38 pmichaud_ certainly they weren't for PCC.
20:38 NotFound pmichaud_: yes. I also discovered the problems in my code. I fixed it.
20:39 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
20:39 pmichaud_ and our requests for help were basically "you're on your own, deal with it"
20:39 NotFound The point is that people can't reasonably ask at the same time for fast changes and for not breaking anything.
20:40 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.
20:40 cotto_work pmichaud_: give us credit for eventually fixing the situation, at least.
20:40 pmichaud_ cotto_work: ....*who* fixed it?
20:40 NotFound pmichaud_: What are these removed features? There are tickest for them?
20:40 pmichaud_ I guarantee it wasn't a Parrot dev that fixed it.
20:41 pmichaud_ (unless you count me as the Parrot dev)
20:41 pmichaud_ NotFound: the 't' return type from NCI.
20:41 pmichaud_ not to mention a fair number of NCI signatures that various Rakudo libs were using.
20:42 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."
20:42 pmichaud_ NotFound: which occurred *after* the fact.
20:43 pmichaud_ 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.
20:43 pmichaud_ chromatic: speaking from a purely selfish point of view -- that's really what I've been saying for a couple of years.
20:43 chromatic Hey, I've offered.
20:44 wknight-phone joined #parrotsketch
20:44 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 pmichaud_ *generally
20:46 chromatic If that's the position of Rakudo developers, there's the impasse.
20:46 pmichaud_ I don't understand, can you clarify?
20:46 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.
20:47 pmichaud_ thanks for the clarification.  you may be correct.
20:47 pmichaud_ that's been my experience, although there are a few notable exceptions.
20:48 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:49 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.
20:49 pmichaud_ s/taking place/proposed/
20:49 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.
20:49 cotto_work It's a fundamental problem.
20:49 wknight-phone at some point we need to get passed years-old bad experiences.
20:50 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
20:50 wknight-phone we didn't have the same leadership for pcc refactors.
20:50 pmichaud_ ...what about nci refactors?
20:50 cotto_work That's an acknowledged failure.
20:50 pmichaud_ what about the proposal for merging :load and :init ?
20:50 TimToady I don't think he was excluding the recent ones :)
20:50 dukeleto ~~
20:51 wknight-phone that was cancelled.
20:51 wknight-phone and I told you about the replacement (:tag)
20:52 wknight-phone and that is in master now
20:52 NotFound Note there is still pending a NCI change that risk to break things.
20:52 wknight-phone nci is hard. patience appreciated
20:53 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:54 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?
20:54 pmichaud_ chromatic: partially (more)
20:54 pmichaud_ it's not just removals that are a problem -- it's changes that slow performance even more.
20:54 NotFound In particular, unmanaged struct is candidate for deprecation since some time. Are we ready for its end of cycle?
20:55 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.
20:55 pmichaud_ wknight-phone: you were?  hopefully not by me.
20:57 wknight-phone not you.
20:57 pmichaud_ a rakudo dev?
20:57 wknight-phone it doesn't matter who
20:57 pmichaud_ it does to me.
20:57 pmichaud_ of
20:58 pmichaud_ rakudo's #1 priority is performance right now.  if someone's working against that, it's against rakudo's goals.
20:59 wknight-phone joined #parrotsketch
21:00 pmichaud_ okay, I've hijacked #parrotsketch, and I didn't necessarily want to do that.
21:01 PacoLinux_ joined #parrotsketch
21:01 pmichaud_ I agree that this is necessarily an evolutionary process.
21:01 pmichaud_ I'm not expecting things to be fixed all at once.
21:01 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.
21:01 pmichaud_ ...rakudo's policies?
21:01 Tene erm
21:01 Tene parrot's
21:02 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.
21:02 Tene right now, asking parrot devs to go out and manually test things against "some rakudo stuff" isn't happening.
21:02 pmichaud_ it's happening more often than it used to, though.
21:02 pmichaud_ I do recognize that.
21:03 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 #parrotsketch
21:04 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 https://gist.github.com/1198962
21:05 cotto_work there's our starting point.  Let's iterate.
21:05 pmichaud_ cotto_work: maybe talk to #perl6 ?
21:05 chromatic I see it more as pushing the work to the *right* levels of abstraction.
21:05 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.
21:05 pmichaud_ chromatic: I agree that getting things to the right level of abstraction is important.
21:05 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
21:05 pmichaud_ sometimes I think things are being pushed higher simply to make parrot's job easier.
21:06 pmichaud_ not because it makes things better.
21:06 wknight8112 if parrot does it wrong rakudo needs to redo it anyway.
21:06 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
21:07 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!
21:07 NotFound BTW I don't think that blaming Lua on the mailing list is going to help anything.
21:07 pmichaud_ chromatic: why?  how does that help Rakudo?
21:08 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.
21:08 pmichaud_ 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.
21:08 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.
21:09 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 Tene But, yes, understood.
21:10 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.
21:11 pmichaud_ chromatic: point taken
21:11 pmichaud_ chromatic: at this time, though, I think jnthn++ and I would be worried about parrot adopting things before they're relatively stable
21:12 pmichaud_ 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 pmichaud_ (granted, eliminating the deprecation policy would restore a lot of that freedom)
21:12 pmichaud_ s/would/could/
21:12 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.
21:12 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 ...
21:12 Tene ... good idea to work on.
21:13 cotto_work Tene: let me clarify.  What would convince you that it's a good time to start working on interop again?
21:14 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:15 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 pmichaud_ We made our plans at YAPC::EU under the assumption that parrot's dep policy wasn't likely to change anytime soon.
21:16 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:17 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?
21:17 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.  :)
21:18 pmichaud_ 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.
21:19 pmichaud_ I think that PCC is our current pain point for Rakudo.  GC also, but not as much as it once was.
21:19 pmichaud_ afaik, we don't have any plans to try to "redo" PCC on our own.
21:19 chromatic The binder still exists. That's a pain point.
21:20 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.
21:20 chromatic I'd like to see all that binder code go away. I'd settle for 80% of it.
21:21 jnthn chromatic: And where exactly are you proposing that the stuff it does should go?
21:21 cotto_work Tene: ok
21:21 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.
21:22 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.
21:23 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.
21:24 pmichaud_ 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.
21:24 pmichaud_ Yes, and we've been saying that for years.
21:24 pmichaud_ ("we" is collective everyone-in-parrot-and-rakudo "we")
21:24 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.
21:25 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.
21:26 chromatic Not backed into Packfiles.
21:26 moritz lexicals indepent from Sub? that would be news to me
21:26 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.
21:26 chromatic baked into/backed by
21:26 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.
21:27 pmichaud_ Packfiles know lexical scoping -- that's :outer
21:27 pmichaud_ granted the subs don't appear as lexical symbols, and that could be a huge improvement.
21:27 chromatic You can't freeze an outer lexical context which contains a constant exception handler, for example.
21:28 chromatic 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 #parrotsketch
21:29 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.
21:29 pmichaud_ jnthn: right.
21:29 chromatic and then you cross the C/PIR boundary and performance goes away.
21:30 chromatic So the inferior runloop problem needs solving and the vtable PIR/C distinction needs addressing and you want a MOP....
21:31 * moritz finds that the discussion has lost a bit of focus
21:32 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?
21:32 Tene afair, that's been the case since deprecation policy day one
21:32 pmichaud_ moritz: correct.  But I also think a recognition that the deprecation is a necessary but not sufficient cultural change.
21:32 pmichaud_ *change to deprecation policy
21:34 pmichaud_ 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:35 pmichaud_ 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 pmichaud_ 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.
21:35 cotto_work If I can interrupt this discussion for a bit, we ought to produce some goals for the coming week.
21:36 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.
21:37 cotto_work other suggestions?
21:38 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?
21:38 dukeleto cotto_work: instructions/docs for allhlltest and setting it up to run automatically
21:38 pmichaud_ I have a comment on language interop but don't want to interrupt cotto's interruption.
21:38 tadzik rethrow()
21:39 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
21:40 cotto_work dukeleto: can anyone involved in Parrot take care of that?
21:40 cotto_work I have no idea what's involved.
21:40 dukeleto cotto_work: sure. But we need to add more pointers to it, like on the wiki and/or git_workflow.pod
21:41 cotto_work dukeleto: sounds like our second goal
21:41 cotto_work pmichaud_: your thoughts?
21:42 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
21:42 cotto_work pmichaud_: yes
21:42 cotto_work dukeleto: third goal (I'm keeping a list)
21:43 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?)
21:44 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
21:44 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.
21:44 Tene ahh; that's nice to hear
21:44 dukeleto Tene: make allhlltest # tests 10 or so HLL's and libraries
21:45 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. ;)
21:45 pmichaud_ (I fully admit that might not be a fair comment... I've only wondered about it and not examined it critically,)
21:46 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.
21:46 pmichaud_ Tene: and now we can no longer really use parrot libraries anyway
21:47 pmichaud_ 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:48 Tene pmichaud_: given a hash of subs, you can't write an import routine that does something meaningful with them?
21:49 NotFound I've done interoperability tests several times, without much problem.
21:50 pmichaud_ Tene: oh, we can call the subs.  We can't handle the objects they return.
21:50 pmichaud_ unless they just happen to be one of Integer/Float/String, in which case we unbox and rebox them into p6 equivalents.
21:51 Tene One more reason to get 6model into parrot core. ;)
21:51 pmichaud_ Indeed.
21:52 pmichaud_ 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?
21:53 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?
21:53 PerlJam (say ... next #ps?)
21:54 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?
21:54 pmichaud_ Tene: if you work on HLL interop at the nqp level, I'd say it might exist for a while.
21:55 pmichaud_ anywhere else, and I'd not be able to say much with reasonable confidence.  :)
21:56 pmichaud_ 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.
21:56 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.
22:01 cotto_work pmichaud_: do you mind unkilling hll interop?
22:02 pmichaud_ ..."unkilling hll interop"?
22:02 cotto_work "might exist for a while" doesn't inspire confidence
22:03 pmichaud_ nqp doesn't make any pretenses towards stability just yet.
22:03 cotto_work Sure, but can't hll interop be tested?
22:03 pmichaud_ I don't understand.
22:03 cotto_work nqp does a good job of passing its test suite
22:04 cotto_work if tene does hll interop work that effects nqp, with tests, can't we ensure that those tests continue to pass?
22:05 cotto_work I don't see where the uncertainty comes from.
22:05 pmichaud_ I think you and I are thinking of different things.
22:06 cotto_work It's possible.
22:06 pmichaud_ what does "hll interop" mean to you?
22:07 pmichaud_ 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
22:07 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.
22:08 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.
22:08 pmichaud_ and if nqp needs to change to meet one of its other goals, then hll interop at the nqp level could break.
22:08 cotto_work its rewrites are becoming progressively less extensive (from what I can tell)
22:08 pmichaud_ but there's a big one on the horizon.
22:09 pmichaud_ we need to move pct into nqp.
22:09 pmichaud_ 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
22:10 cotto_work which could have a significant impact on hll interop
22:10 pmichaud_ correct.
22:10 pmichaud_ so, Tene's question was "rakudo won't break and discard it again"
22:11 pmichaud_ 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.
22:12 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 pmichaud_ it's definitely not intended as "we don't care", but more of "I can't make many guarantees for a short while"
22:12 cotto_work Thank you for clarifying.
22:14 cotto_work I think I need to wrap up #ps.  We're nearing 3 hours and I allegedly have a dayjob.
22:14 pmichaud_ heh
22:14 cotto_work the goals I have are:
22:14 cotto_work GOAL 1: work with Rakudo on a new support policy
22:14 cotto_work GOAL 2: filter through feedback on support policy, keep track of the important bits
22:14 cotto_work GOAL 3: document allhlltest (git_workflow.pod)
22:14 cotto_work GOAL 4: new SSL cert
22:14 cotto_work GOAL 5: figure out a rough roadmap of what we want to change (whiteknight)
22:14 pmichaud_ moving to #parrot and #perl6, then :)
22:16 NotFound left #parrotsketch
22:17 chromatic left #parrotsketch
22:41 pmichaud_ left #parrotsketch
22:54 whiteknight joined #parrotsketch
22:55 Coke joined #parrotsketch

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