"Black smoke"

Andrew Whitworth wknight8111 at gmail.com
Sun Jul 19 02:21:07 UTC 2009


Talked to Patrick tonight in IRC and he suggested that we not back out
the branch changes until tomorrow night. He thinks Rakudo may be able
to implement a fix on their end before the release. If it doesn't get
resolved by then, or a solid plan isn't started to get it resolved
shortly thereafter, we can talk about backing out the merge. Sound
good?

--Andrew Whitworth

On Sat, Jul 18, 2009 at 8:09 PM, Vasily Chekalkin<bacek at bacek.com> wrote:
> Hello.
>
> I didn't realise how much code depends on Hash keys order. Shame on me.
> Almost all this code was fixed but no all.
>
> Last bit is handling "attributes" in Class.pmc which causes 2 failures in
> Rakudo. Problems are in this snippet of code:
>
>
>    class AttrInitTest {
>        has $.a = 1;
>        has $.b = 2;
>        has $.c = $.a + $.b;
>    };
>    say AttrInitTest.new.c;
>
> Because hash keys are in some random order now (which is correct from my
> point of view) attribute $!c some time initialised before other attributes.
> I can see 3 ways of solving this issue.
>
> 1. Unmerge keys_revamp branch, but big warning in release notes that Hash
> keys order will be random, merge it after release and implement dependency
> tracking of attributes in Rakudo. "warning", not "deprecation" because
> current behaviour isn't specified.
>
> 2. "Fix" Class PMC to use OrderedHash for "attributes" before release. This
> is actually very big change in current timeframe.
>
> 3. Polish and apply attached patch which restore ordering of Hash keys.
>  Revert this patch after release. Put big warning message from item 1.
>
> Patch is wrong in many ways because it restores "original" behaviour of
> iterating over hashes. E.g.
> a) it doesn't handle INTVAL keys properly.
> b) it will hide original problem with attributes. May be not applicable  to
> Rakudo, but for other languages which allows to remove "attribute" in
> runtime we can't guarantee order of them.
> c) we continue to support bad habit of relying on Hash keys order.
>
> But for purpose of release it's probably best (fsvo) solution.
>
>
> --
> Bacek
>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>


More information about the parrot-dev mailing list