On Tue Jan 19 11:20:59 2016, coke wrote: > On Tue Jan 19 10:12:08 2016, coke wrote: > > On Mon Jan 04 11:53:44 2016, coke wrote: > > > On Thu Dec 31 05:04:23 2015, lue wrote: > > > > There's unfortunately no real diagnostic I can provide for the > > > > error > > > > specifically, since the result of the bug is a failed grammar > > > > parse. > > > > > > > > The grammar of my SUPERNOVA project > > > > (https://github.com/ShimmerFairy/SUPERNOVA) has been failing > > > > since > > > > the > > > > CURI branch was merged into mainline rakudo, for reasons that are > > > > unclear. I can verify that switching to a pre-CURI-merge commit > > > > (e.g. > > > > 6d9d0f11aba8e2f465c2958a9311d9d4016017ff, the last commit before > > > > the > > > > fast-forward merge of CURI) will allow the grammar to work again, > > > > with > > > > no changes to SUPERNOVA, thus it's an issue with rakudo. > > > > > > > > My attempt to bisect rakudo led to commit > > > > ac7b2a5a8381d5f255906437d1980c9c3b77e2a5 > > > > (https://github.com/rakudo/rakudo/commit/ac7b2a5a8381d5f255906437d1980c9c3b77e2a5), > > > > however as you can see the reason why _this_ commit should break > > > > grammar parsing is a complete mystery. (I may try bisecting again > > > > sometime to confirm the result.) > > > > > > > > Like I said, there's absolutely nothing I provide in terms of > > > > errors, > > > > since the only indicator is just the grammar suddenly failing to > > > > match > > > > a valid string. It seems to be centered around the "directive" > > > > multi > > > > token in my grammar, however I don't have any more specific info > > > > on > > > > the location of the issue. > > > > > > Even if some golfed code isn't possible, providing explicit > > > instructions about how to see the breakage would be helpful, e.g. > > > "check out from this repo, checkout this specific version, run this > > > specific code, get this result, expect this other result." That > > > will > > > at least give others the change to try to golf the problem. > > > > Note that bisecting this pre and post Christmas is also difficult > > because SUPERNOVA depends on Grammar::Parsefail - which you'd > > normally > > install with panda, and the behavior here intentionally changed as > > part of the CURI merge. > > > > So a full bisect would involve finding an appropriate version of > > panda > > to go with the rakudo commit (and, btw, removing the install > > directory > > after each bisect step to insure you're using the version of nqp or > > moar that goes with that commit.) This makes it very difficult to > > track down via a bisect. (Not to mention tracking the version of any > > modules like Grammar::Parsefail over that period) > > > > Golfing the test.p6 script (reported elsewhere as a canary for this > > problem) is probably the easiest way forward at this point. > > Although it's hard to tell since test.p6 isn't a test file, per se, I > believe that if you apply this patch, you can avoid the bug and > continue working. Presumbably the CURI branch exposed an already > existing precompilation issue. > > There might be another RT that already tracks the underlying cause. > > $ git diff > diff --git a/lib/Grammar.pm6 b/lib/Grammar.pm6 > index df3b332..2f4141f 100644 > --- a/lib/Grammar.pm6 > +++ b/lib/Grammar.pm6 > @@ -1,6 +1,7 @@ > # Grammar.pm6 --- Pod6 Grammar > > use v6; > +no precompilation; > > # since this will eventually be plugged into the rakudo > grammar/actions setup, > # we need to be as NQP-y as can be reasonably done. Why not just write > it in NQP > @@ -1360,4 +1361,4 @@ grammar Pod6::Grammar is Grammar::Parsefail { > [<reserved_name> | <typename>] > ] > } > -} > \ No newline at end of file > +}
Can you retest this (without the no precompilation hack suggested above) with a current rakudo and see if you're still having the issue? -- Will "Coke" Coleda
