Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inexplicable failure of grammar post-CURI branch #4972

Open
p6rt opened this issue Dec 31, 2015 · 6 comments
Open

Inexplicable failure of grammar post-CURI branch #4972

p6rt opened this issue Dec 31, 2015 · 6 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Dec 31, 2015

Migrated from rt.perl.org#127108 (status was 'open')

Searchable as RT127108$

@p6rt
Copy link
Author

p6rt commented Dec 31, 2015

From @ShimmerFairy

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 (rakudo/rakudo@ac7b2a5), 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.

@p6rt
Copy link
Author

p6rt commented Jan 4, 2016

From @coke

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
(rakudo/rakudo@ac7b2a5),
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.

--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Jan 4, 2016

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Jan 19, 2016

From @coke

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
(rakudo/rakudo@ac7b2a5),
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.
--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Jan 19, 2016

From @coke

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
(rakudo/rakudo@ac7b2a5),
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

Inline Patch
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 \+\} \-\- Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Aug 17, 2016

From @coke

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
(rakudo/rakudo@ac7b2a5),
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

@p6rt p6rt added the precomp label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant