|
Parrot 4.2.0 "Ornithopter" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC Set by moderator on 21 March 2012. |
|||
|
00:03
kurahaupo joined
00:14
preflex joined
00:56
whiteknight joined
01:17
kid51 joined
01:38
jashwanth joined
|
|||
| pmichaud | question: are later versions of Parrot expected to be able to run the bytecode created in earlier versions? | 01:50 | |
| 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:51 | ||
| (this is related to the parrot and rakuo debian packaging discussions) | 01:52 | ||
| *rakudo | |||
| 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 | ||
| 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:54 | ||
| 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 | ||
| sorear | pmichaud: Debian has exact verison constraints | ||
| pmichaud | whiteknight: yeah, I'm not sure sure what to do with that one. | ||
| sorear | Requires: parrot (= 4.2.0) | ||
| pmichaud | sorear: yes, that's one of the things allison and I discussed in a phone call a short bit ago | ||
| 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 | ||
| 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 | |
| the package for Rakudo 2011.07 contains compiled .pbc files (e.g., perl6.pbc) | |||
| 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 | ||
| pmichaud | of course, it also has a fakecutable perl6 | ||
| whiteknight | pmichaud: yes, I can imagine the problem in my head clearly | 01:57 | |
| jashwanth | whiteknight:hello | ||
| 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 | ||
| whiteknight | I had never thought about it, but as soon as allison mentioned it, the picture became clear | ||
| pmichaud: Okay, so here's the question: Is it a big big big problem, or only a small problem? | 01:58 | ||
| or somewhere in between? | |||
| pmichaud | whiteknight: I think we'd have to ask the packagers that. | ||
| whiteknight | okay, so this is pain for the packagers, but not for rakudo devs (in general)? | ||
| 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 | ||
| 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 | ||
| 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 | ||
| whiteknight | I think we should at least expect binary compatibility between major (january) releases | ||
| 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 | |
| (Actually, apt-get will helpfully offer to delete rakudo to unblock the parrot instgall) | |||
| whiteknight | okay, that's craptacular | ||
| pmichaud | sorear: yeah, that's what I'm expecting will happen | 02:02 | |
| sorear | whiteknight: responding to me or pm? | ||
| whiteknight | sorear: responding to what you just described | ||
| 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 | ||
| or we try to package "legacy" oplibs with our releases to cover N previous months worth of binaries | |||
| 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 | ||
| 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 | ||
| 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. | ||
| whiteknight | sorear: Our system is unnecessarily fragile, and we've know it for a long time | ||
| sorear: Whether debianeers are used to it or not, we can do better | |||
| pmichaud | and if one language requires = 3.9.0 and another language requires = 4.0.0 ..... the user is out of luck. | 02:05 | |
| 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 | ||
| whiteknight | So maybe we need multiple parrot packages. parrot-3.9.0, parrot-4.0.0, etc. They already install to different directories | 02:07 | |
| pmichaud | anyway, you answered my core question, which is that it's on the roadmap but not immediately addressed | 02:08 | |
| I wasn't sure if it was still somewhere on the roadmap :) | |||
| 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 | ||
| 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 :) | |||
| I know I certainly did. | 02:10 | ||
| whiteknight | Yeah, I was unaware | ||
| I rarely use parrot from the packages :) | |||
| cotto | "Why would I use those? I have the source right here." | ||
| whiteknight | srsly | ||
| benabik | I knew. | 02:15 | |
| 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. | ||
| benabik | Well, it's the same basic reason. | ||
| 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. | |||
| benabik likes semantic versioning. | 02:17 | ||
| pmichaud | can you succinctly state the "basic reason", ooc? | ||
| benabik | Because every PBC has the version number of the core oplib encoded and requires an exact match. | ||
| 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 | ||
| thanks | |||
| well, there are also issues with things like API changes | |||
| benabik | I noticed that when I started playing with the disassembler. | ||
| Well, that's why the bytecode is incompatible. Dynops and dynpmcs have additional issues. | 02:19 | ||
|
02:20
kid51_ joined
|
|||
| cotto | benabik, how would semantic versioning apply to Parrot and Rakudo? | 02:20 | |
| (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. | ||
| The theory of server is that built on Parrot X.Y.Z would build on any Parrot X.*.*. | |||
| X.Y updates _add_ things, and X.Y.Z updates are bug fix only. | |||
| 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? | ||
| benabik | Yes. | ||
| semver.org/ | |||
| 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. | ||
| benabik | Run on, I think... But the details of that are hazy. | ||
| Dynamic linking should handle additional symbols, I think. | |||
| Parrot has the additional issue of the bytecode. | 02:24 | ||
| cotto | and dynops/dynpmcs | ||
| 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. | ||
| Dynops and dynamics are just dynamic libraries. | |||
| cotto | yes | ||
| benabik | Which is what semantic versioning was created for. | ||
| (Sorry about the piles of text, this is another thing that's been on my mind for a while.) | |||
| cotto | is that your project? | 02:25 | |
| benabik | semver isn't mine. | ||
| cotto | mn. The bottom of the page lists the author. | ||
| benabik | I just liked it. | ||
| 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:28 | |
| benabik | Yeah. It's a lot more discipline and pain. But it'll be important for Parrot at some point, I think. | 02:29 | |
| 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 | |
| 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 | |||
| cotto | it seems that pbc_dump has stopped doing anything | ||
| benabik | That is true... But then any semantic changes to and op requires changing its sig | 02:31 | |
| Feels fragile. | |||
| cotto | or I'm using it incorrectly. tests still pass | ||
| whiteknight | benabik: most ops are relatively small and relatively fixed. Most of the time, semantic changes for an existing op reprsents a bug | ||
| benabik | It would be nice if core_ops was the core. | ||
| pmichaud | ooc, what happens to (previously compiled) dynops if the parrot core adds a new op? | ||
| i.e., Rakudo has a set of compiled dynops | 02:32 | ||
| benabik | Dynops shouldn't be affected... | ||
| pmichaud | Parrot releases a new version that doesn't change any existing opcodes, but adds a couple | ||
| whiteknight | pmichaud: Nothing should happen. Parrot maintains an array of separate oplibs internally, and each PBC contains a mapping of used ops | ||
| pmichaud | okay, wfm, thanks | ||
| benabik | Each PBC has a custom mapping to (library, op) | ||
| whiteknight | so we can change things around so long as the pbc's mapping stays updated with new op locations | ||
| pmichaud | I never looked at those internals | ||
| cotto | bacek++ added that a while back in response to that exact problem | ||
| benabik | The keys to compatability is core_ops and the APIs. | 02:34 | |
| whiteknight has to go to bed. he gets grumpy when he misses so much sleep | 02:38 | ||
| benabik | 'night! | 02:39 | |
| pmichaud | sleep well! | ||
| cotto | no good being grumpy for easter | ||
|
02:47
JimmyZ joined
02:51
JimmyZ_ joined
|
|||
| nbrown_ | cotto: I have an m0 question for you if you have a moment | 02:55 | |
| 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? | 02:58 | ||
| 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:01 | |
| nbrown_ | cotto: ok, I was looking at the perl code for inspiration. I'll keep working at it | 03:02 | |
| cotto | it was either that or modify the runloop | 03:03 | |
| I don't think that a C implementation would have the same issue | |||
| nbrown_ | cotto: it shouldn't | ||
| but I'm definitely doing something wrong | |||
| cotto | there are many things to do wrong to choose from | 03:04 | |
| nbrown_ | cotto: too true | ||
| benabik | It's important to try a few wrong things first. | ||
| Important part of the process. | |||
| cotto | sadly true | ||
| JimmyZ realized this email to parrot-dev about M0 design problem is not a problem, it's a design decision or direction. | |||
| nbrown_ | I was stepping through both and when I got to the point where there should be a call frame switch I was surprised | ||
| JimmyZ: I wholeheartedly agree | 03:05 | ||
| 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 | |||
| JimmyZ | but what I pushed is not about this email | 03:06 | |
| JimmyZ meant the code | |||
| nbrown_ | JimmyZ: I know, you're pursuing something else entirely | ||
| 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. | ||
| *semver | |||
| 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 | ||
| 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. | ||
| JimmyZ | nbrown_: I won't work on it untili someone tell me the direction is right. | 03:08 | |
| *until | |||
| benabik | We could do a release each month, but not have the version increase monotonically. | ||
| 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 | ||
| benabik | Even back with the depreciation policy, which versions had significant changes was very random. | ||
| JimmyZ | what I emailed to parrot-dev, will changed M0 to use dynamic size bytecode. | ||
| 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' | ||
| 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 | ||
| benabik | cotto: Or just "Parrot 2.3.0, released Jan 2012" | ||
| 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 | ||
| 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:27 | |
| 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 | ||
| benabik | I should bed. | 03:37 | |
| moritz | +1 to month-based release names | 05:34 | |
| there's nothing artificial in them, and you see immediatly how old a given release is | |||
|
09:18
PacoAir joined
09:43
lucian joined
10:22
lucian joined
10:30
Tene joined
11:38
Tene joined
11:50
kid51 joined
12:47
whiteknight joined
12:56
plobsing joined
|
|||
| whiteknight | plobsing: ping | 12:59 | |
| actually, unping. No time to talk right now. Be back later | 13:02 | ||
|
17:05
lucian joined
17:35
plobsing_ joined
18:50
whiteknight joined
|
|||
| whiteknight | good afternoon, #parrot | 18:50 | |
|
20:33
lucian joined
20:44
contingencyplan joined
21:16
mj41 joined
21:36
plobsing joined,
whiteknight joined,
PacoAir joined,
schmooster joined,
particle joined,
perlite joined,
alvis joined
21:48
Justin joined
|
|||
| Justin | good evening | 21:48 | |
|
21:51
kid51 joined
|
|||
| whiteknight | hello Justin | 21:51 | |
| dalek | sella: 73569f1 | Whiteknight++ | src/unstable/repl/View.winxed: [Repl] Fix a todo item with default parameter values |
21:52 | |
| sella: 230397d | Whiteknight++ | s (4 files): [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. |
|||
| sella: 64be49a | Whiteknight++ | / (2 files): [String] to_upper, to_lower and tests |
|||
| sella: a7b7626 | Whiteknight++ | src/ (3 files): [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. |
|||
| sella: 907f46d | Whiteknight++ | s (8 files): [FileSystem] Rename FilePath to Path. Factor it out so Directories can use it too. Fix path handling to always start from the directory root. |
|||
| sella: 181a7de | Whiteknight++ | src/ (2 files): [FileSystem] Fix Path to deal properly with . and .. special paths |
|||
| sella: 60fa5ce | Whiteknight++ | src/filesystem/Path.winxed: [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 | ||