Camelia, the Perl 6 bug

IRC log for #parrot, 2012-04-08

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:03 kurahaupo joined #parrot
00:14 preflex joined #parrot
00:56 whiteknight joined #parrot
01:17 kid51 joined #parrot
01:38 jashwanth joined #parrot
01:50 pmichaud question:  are later versions of Parrot expected to be able to run the bytecode created in earlier versions?
01:51 pmichaud I know this was planned at one point early in parrot development, it was abandoned at the time of Parrot 1.0, and I'm wondering if it's in the pipeline to be picked up again someday
01:52 pmichaud (this is related to the parrot and rakuo debian packaging discussions)
01:52 pmichaud *rakudo
01:53 sorear I am not a policy setter, don't listen too much to me, but last I heard that was part of the goals for M0/Lorito
01:53 pmichaud okay
01:54 pmichaud apparently part of the problem the debian packagers are having is that packing a later version of Parrot causes existing versions of Rakudo to break
01:55 sorear M0 bytecode, being simpler, is easier to make stable, or something like that
01:55 whiteknight pmichaud: It's still on the roadmap, though nobody has really put forth a plan to make it work reliably
01:55 sorear pmichaud: Debian has exact verison constraints
01:55 pmichaud whiteknight: yeah, I'm not sure sure what to do with that one.
01:55 sorear Requires: parrot (= 4.2.0)
01:55 pmichaud sorear: yes, that's one of the things allison and I discussed in a phone call a short bit ago
01:55 whiteknight pmichaud: if we know it's a pain point, we can try to focus more effort on it. Until now, I think we've assumed it wasn't worth the effort
01:56 pmichaud whiteknight: the situation that allison described to me is:   someone installs, for example, Rakudo 2011.07 running on Parrot 3.6.0
01:56 pmichaud the package for Rakudo 2011.07 contains compiled .pbc files (e.g., perl6.pbc)
01:56 whiteknight Every Parrot release updates the version number of the core opcode lib, which is tested for strict equality. Honestly, most releases it isn't necessary to bump that number unless PBC_COMPAT is changed
01:56 pmichaud of course, it also has a fakecutable perl6
01:57 whiteknight pmichaud: yes, I can imagine the problem in my head clearly
01:57 jashwanth whiteknight:hello
01:57 pmichaud so, to continue the story for the rest of the lurkers/chan:  when someone attempts to upgrade to Parrot 3.9.0, all hell breaks loose because the Rakudo binaries can't be run by Parrot 3.9.0
01:57 whiteknight I had never thought about it, but as soon as allison mentioned it, the picture became clear
01:58 whiteknight pmichaud: Okay, so here's the question: Is it a big big big problem, or only a small problem?
01:58 whiteknight or somewhere in between?
01:58 pmichaud whiteknight: I think we'd have to ask the packagers that.
01:58 whiteknight okay, so this is pain for the packagers, but not for rakudo devs (in general)?
01:59 pmichaud it's a little unexpected but not really a pain point (more)
01:59 whiteknight I don't want to marginalize any group, I'm just trying to understand so we can figure out how to allocate resources
01:59 pmichaud rakudo does tend to expect that future versions of Parrot will be able to run existing versions of Rakudo, but we never looked at it at a bytecode/binary level
02:00 whiteknight "officially", the support policy says something about blah blah blah, supported releases every few months, blah blah blah
02:00 pmichaud what it does mean is that dealing with API changes and "minimum revision levels" doesn't make any difference to packagers as long as Parrot bytecode and binaries are incompatible from one (stable) release to the next
02:00 whiteknight I think we should at least expect binary compatibility between major (january) releases
02:01 sorear pmichaud: user runs 'apt-get install parrot', apt carps that Rakudo depends on Parrot = 4.2.0 and no newer version is available
02:01 sorear (Actually, apt-get will helpfully offer to delete rakudo to unblock the parrot instgall)
02:01 whiteknight okay, that's craptacular
02:02 pmichaud sorear: yeah, that's what I'm expecting will happen
02:02 sorear whiteknight: responding to me or pm?
02:02 whiteknight sorear: responding to what you just described
02:03 whiteknight I'm wondering how we fix this. We could either put in some terrible policy where we require pbc-level compatibility over some arbitrary timeframe (more)
02:03 whiteknight or we try to package "legacy" oplibs with our releases to cover N previous months worth of binaries
02:03 sorear whiteknight: what I'm proposing is an improvement to the current situation, which is silent breakage that apt-get can't detect in advance
02:04 whiteknight sorear: I'd like a long-term solution with less breakage, not more polite breakage
02:04 sorear whiteknight: also, Debian users are familiar with this kind of tight binding, because a lot of core packages (like g++ and gcc) also need to be installed in version pairs
02:04 pmichaud essentially, it means that people with one or more Parrot languages installed cannot upgrade Parrot until new versions of all of the language packages are also available.
02:04 whiteknight sorear: Our system is unnecessarily fragile, and we've know it for a long time
02:04 whiteknight sorear: Whether debianeers are used to it or not, we can do better
02:05 pmichaud and if one language requires = 3.9.0  and another language requires = 4.0.0 .....    the user is out of luck.
02:06 whiteknight pmichaud: The only language worth talking about now is Rakudo. Other languages are immature at best, if the build and run at all. by the time we have other viable compilers, we should have this issue resolved
02:06 pmichaud whiteknight: wfm
02:07 whiteknight So maybe we need multiple parrot packages. parrot-3.9.0, parrot-4.0.0, etc. They already install to different directories
02:08 pmichaud anyway, you answered my core question, which is that it's on the roadmap but not immediately addressed
02:08 pmichaud I wasn't sure if it was still somewhere on the roadmap :)
02:09 whiteknight it is on the roadmap, but has not been prioritized. I'll ask around and see what we can do about it
02:09 pmichaud wfm
02:09 pmichaud I'm not at all claiming it needs to be a high development priority -- just that all involved needed a better awareness of the issue :)
02:10 pmichaud I know I certainly did.
02:10 whiteknight Yeah, I was unaware
02:10 whiteknight I rarely use parrot from the packages :)
02:10 cotto "Why would I use those?  I have the source right here."
02:10 whiteknight srsly
02:15 benabik I knew.
02:16 benabik Every Parrot release involves rebuilding NQP and Rakudo.  I've brought it up a few times.
02:16 pmichaud I knew it at that level -- I didn't recognize it at a packaging level.
02:16 benabik Well, it's the same basic reason.
02:16 benabik I personally think core_libs should be broken up and all the libs should use semantic versioning so they only change when they need to and you can tell when it's a bug fix via real changes.
02:17 * benabik likes semantic versioning.
02:17 pmichaud can you succinctly state the "basic reason", ooc?
02:17 benabik Because every PBC has the version number of the core oplib encoded and requires an exact match.
02:18 benabik And because Parrot's version numbers have nothing to do with the actual rate of change of code, it's impossible to determine compatability.
02:18 pmichaud well stated
02:18 pmichaud thanks
02:18 pmichaud well, there are also issues with things like API changes
02:18 benabik I noticed that when I started playing with the disassembler.
02:19 benabik Well, that's why the bytecode is incompatible.  Dynops and dynpmcs have additional issues.
02:20 kid51_ joined #parrot
02:20 cotto benabik, how would semantic versioning apply to Parrot and Rakudo?
02:21 cotto (asking about the mechanics, not if it'd make sense)
02:21 benabik Semver is designed so the version number tells you how much the API changed.
02:21 benabik The theory of server is that built on Parrot X.Y.Z would build on any Parrot X.*.*.
02:21 benabik X.Y updates _add_ things, and X.Y.Z updates are bug fix only.
02:22 benabik Sorry, "build on any Parrot X.Q.W where Q >= Y"
02:22 cotto and only a major version bump means something can go away?
02:22 benabik Yes.
02:22 benabik http://semver.org/
02:23 pmichaud ..."build on" or "run on" ?
02:23 cotto yeah.  I'm trying to get the motivation and big idea before I tackle the big wall o' text.
02:23 benabik Run on, I think...  But the details of that are hazy.
02:23 benabik Dynamic linking should handle additional symbols, I think.
02:24 benabik Parrot has the additional issue of the bytecode.
02:24 cotto and dynops/dynpmcs
02:24 benabik Parrot's versions look meaningful but are only date based.  And the fact that it's written directly into the bytecode means all compiled code expires after a month.
02:24 benabik Dynops and dynamics are just dynamic libraries.
02:24 cotto yes
02:24 benabik Which is what semantic versioning was created for.
02:24 benabik (Sorry about the piles of text, this is another thing that's been on my mind for a while.)
02:25 cotto is that your project?
02:25 benabik semver isn't mine.
02:25 cotto mn.  The bottom of the page lists the author.
02:25 benabik I just liked it.
02:28 cotto if we versioned dynop and dynpmc libraries separately, followed a disciplined versioning specification similar to semver and embedded that information into pbc, I can imagine that working
02:29 benabik Yeah.  It's a lot more discipline and pain.  But it'll be important for Parrot at some point, I think.
02:30 whiteknight A bytecode file already lists out the ops that it uses. If we load up a bytecode and we still have those same few ops with the same signatures, We should call it a match
02:30 whiteknight We add new ops and delete old ops with some regularity, but we have a very stable core of ops that do not change and represent 99% of most executable code
02:30 cotto it seems that pbc_dump has stopped doing anything
02:31 benabik That is true...  But then any semantic changes to and op requires changing its sig
02:31 benabik Feels fragile.
02:31 cotto or I'm using it incorrectly.  tests still pass
02:31 whiteknight benabik: most ops are relatively small and relatively fixed. Most of the time, semantic changes for an existing op reprsents a bug
02:31 benabik It would be nice if core_ops was the core.
02:31 pmichaud ooc, what happens to (previously compiled) dynops if the parrot core adds a new op?
02:32 pmichaud i.e., Rakudo has a set of compiled dynops
02:32 benabik Dynops shouldn't be affected...
02:32 pmichaud Parrot releases a new version that doesn't change any existing opcodes, but adds a couple
02:32 whiteknight pmichaud: Nothing should happen. Parrot maintains an array of separate oplibs internally, and each PBC contains a mapping of used ops
02:32 pmichaud okay, wfm, thanks
02:32 benabik Each PBC has a custom mapping to (library, op)
02:32 whiteknight so we can change things around so long as the pbc's mapping stays updated with new op locations
02:32 pmichaud I never looked at those internals
02:32 cotto bacek++ added that a while back in response to that exact problem
02:34 benabik The keys to compatability is core_ops and the APIs.
02:38 * whiteknight has to go to bed. he gets grumpy when he misses so much sleep
02:39 benabik 'night!
02:39 pmichaud sleep well!
02:39 cotto no good being grumpy for easter
02:47 JimmyZ joined #parrot
02:51 JimmyZ_ joined #parrot
02:55 nbrown_ cotto: I have an m0 question for you if you have a moment
02:58 nbrown_ cotto: I was looking at how the perl implementation passes the poke_caller test and I think there's a cheat in m0_opfunc_set. It seems to set the callframe pointer to the callframe register in addition to what the specs says, do you know why?
03:01 cotto nbrown_, it was tricky to write that test and to get M0 to support it.  I did have to add a cheat there.
03:02 nbrown_ cotto: ok, I was looking at the perl code for inspiration. I'll keep working at it
03:03 cotto it was either that or modify the runloop
03:03 cotto I don't think that a C implementation would have the same issue
03:03 nbrown_ cotto: it shouldn't
03:03 nbrown_ but I'm definitely doing something wrong
03:04 cotto there are many things to do wrong to choose from
03:04 nbrown_ cotto: too true
03:04 benabik It's important to try a few wrong things first.
03:04 benabik Important part of the process.
03:04 cotto sadly true
03:04 * JimmyZ realized this email to  parrot-dev about  M0 design problem is not a problem, it's a design decision or direction.
03:04 nbrown_ I was stepping through both and when I got to the point where there should be a call frame switch I was surprised
03:05 nbrown_ JimmyZ: I wholeheartedly agree
03:05 nbrown_ I still think the current m0 design is prety solid except for the dereferencing of consts as I laid out in my email to the list
03:06 JimmyZ but what I pushed is not about this email
03:06 * JimmyZ meant the code
03:06 nbrown_ JimmyZ: I know, you're pursuing something else entirely
03:06 benabik cotto: (re: server and major numbers)  Part of the key to semver is that it's not time-based.  Major version changes can happen when we need, so it's not too limiting.  Obviously we'd want to build up a few major changes and do them all at once instead of jumping several major versions in a couple months.
03:06 benabik *semver
03:07 cotto benabik, we'd need to figure out how that'd fit with our monthly release process
03:07 nbrown_ JimmyZ: but I thought the conclusion on the list was that you should do that development in a separate branch
03:07 benabik cotto: Decoupling the version number from years isn't a bad start.  It is somewhat designed for more mature projects that likely have separate development and maintenance branches.
03:08 JimmyZ nbrown_: I won't work on it untili someone tell me the direction is  right.
03:08 JimmyZ *until
03:08 benabik We could do a release each month, but not have the version increase monotonically.
03:09 nbrown_ JimmyZ: and I thought cotto's email asked you to move your work to a different branch so that work to the existing spec could continue in the m0 branch
03:09 cotto me too
03:09 benabik Even back with the depreciation policy, which versions had significant changes was very random.
03:09 JimmyZ what I emailed to parrot-dev, will changed M0 to use dynamic size bytecode.
03:11 cotto benabik, yes.  What would monthly releases look like?  Would we do something like "Parrot Jan-2012 2.3.0" with independent time-based and semver-based version descriptions?
03:11 JimmyZ hmm, maybe I meant 'not fixed align size'
03:11 nbrown_ JimmyZ: true, but if anyone (like me for example) wants to continue to contribute to the other concept, there's no place in the parrot repo for my to submit my pull request
03:11 benabik cotto: Or just "Parrot 2.3.0, released Jan 2012"
03:12 cotto benabik, what about the case where there aren't semver changes month-to-month?
03:12 benabik cotto: 100% compatable changes are patch # increases.  2.3.1 released Feb 2012
03:27 cotto benabik, I can see that working.  it'd also give our version numbers more significance.  Knowing which month a release came out on doesn't tell anyone a whole lot.
03:28 benabik I've been thinking we should use semver or just something akin to Rakudo's 2012.04 versions...  If it's time based just make it explicit.  Janurary is kind of sad when "4.0" didn't actually mean much changed.
03:28 cotto yes
03:37 benabik I should bed.
05:34 moritz +1 to month-based release names
05:34 moritz there's nothing artificial in them, and you see immediatly how old a given release is
09:18 PacoAir joined #parrot
09:43 lucian joined #parrot
10:22 lucian joined #parrot
10:30 Tene joined #parrot
11:38 Tene joined #parrot
11:50 kid51 joined #parrot
12:47 whiteknight joined #parrot
12:56 plobsing joined #parrot
12:59 whiteknight plobsing: ping
13:02 whiteknight actually, unping. No time to talk right now. Be back later
17:05 lucian joined #parrot
17:35 plobsing_ joined #parrot
18:50 whiteknight joined #parrot
18:50 whiteknight good afternoon, #parrot
20:33 lucian joined #parrot
20:44 contingencyplan joined #parrot
21:16 mj41 joined #parrot
21:36 plobsing joined #parrot
21:36 whiteknight joined #parrot
21:36 PacoAir joined #parrot
21:36 schmooster joined #parrot
21:36 particle joined #parrot
21:36 perlite joined #parrot
21:36 alvis joined #parrot
21:48 Justin joined #parrot
21:48 Justin good evening
21:51 kid51 joined #parrot
21:51 whiteknight hello Justin
21:52 dalek Rosella: 73569f1 | Whiteknight++ | src/unstable/repl/View.winxed:
21:52 dalek Rosella: [Repl] Fix a todo item with default parameter values
21:52 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/73569f1d26
21:52 dalek Rosella: 230397d | Whiteknight++ | s (4 files):
21:52 dalek Rosella: [Date] Add in a second implementation of DateFormatter logic using Parse instead of in-place string.replace() calls. Surprisingly, this implementation is slower in many cases, despite allocating fewer PMC and STRING headers. Preliminary investigations suggest StringBuilder is the culprit.
21:52 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/230397d7cd
21:52 dalek Rosella: 64be49a | Whiteknight++ | / (2 files):
21:52 dalek Rosella: [String] to_upper, to_lower and tests
21:52 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/64be49ac5c
21:52 dalek Rosella: a7b7626 | Whiteknight++ | src/ (3 files):
21:52 dalek Rosella: [Net] Break receive logic up into separate functions for receive type. Break response header parsing into a separate method in the Header class. Add comments to several bits.
21:52 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/a7b7626bd2
21:52 dalek Rosella: 907f46d | Whiteknight++ | s (8 files):
21:52 dalek Rosella: [FileSystem] Rename FilePath to Path. Factor it out so Directories can use it too. Fix path handling to always start from the directory root.
21:52 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/907f46d135
21:52 dalek Rosella: 181a7de | Whiteknight++ | src/ (2 files):
21:52 dalek Rosella: [FileSystem] Fix Path to deal properly with . and .. special paths
21:52 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/181a7de467
21:54 dalek Rosella: 60fa5ce | Whiteknight++ | src/filesystem/Path.winxed:
21:54 dalek Rosella: [FileSystem] Remove old TODO note. Fix a case where when we are working with the system root path we get correct-looking results
21:54 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/60fa5ce311

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

Parrot | source cross referenced