Failure on current rakudo moar #1
Comments
|
full gdb backtrace from moar built with --debug --optimize=0 |
|
|
It's not a segfault on my system. raiph@hack:~/dev$ perl6 -v For reasons not worth talking about atm, I renamed the module to lose the '::'. Other than that, my test is the same basic one that raydiak had golfed to, and it still fails, but it has a cleaner exit than a segfault: raiph@hack:~/dev$ perl6 -I. -MGrammarGenerative -e 'grammar G { token TOP { . } }' I get the same message when running this project's t/01-basic.t file. The debugger shows code setting everything up then starting to go thru |
|
I'm interested in using reversible grammars, but alas I am also also getting "getcodename requires a concrete code object" when running t01-rules. I'm using Rakudo* 2016.01.1 on Windows 64-bit Running the test inside perl6-debug-m (is that also your project?) gives a different error, and this backtrace: perl6-debug-m -I..\lib 01-basic.t |
|
I no longer get a segfault, but this instead: $ raku -Ilib t/01-basic.t # You planned 16 tests, but ran 0 |
raydiak
changed the title
|
I have golfed and bisected the current failure point to 2017.02: https://gist.github.com/Whateverable/708722d6f5228bbde5907d1619f2fbc8 The comment on rakudo/rakudo@f526c7d looks like a pertinent clue to relevant changes around that time, but we no longer have Cursors, and full-text searching the current docs for "braid" yields 0 results. I don't immediately see where to read for the current best way to accomplish this; more digging will be necessary if nobody better informed steps up. @jnthn I assume this was a brief and unprofitable side project for you, but any insight to guide the less meta-capable of us who would like to spend some tuits on this module would be greatly appreciated. Even just a link or few to the pertinent doc pages or a similar working model in a maintained module would greatly lower the contribution barrier. I've also genericized the title of this issue, as various failure modes beyond my original segfault have been added to this discussion. |
|
Hi @raydiak,
Ah. That's pretty close to the time Larry stopped working on Rakudo. Presumably you know all about the braid, right? |
|
Hello @raiph, good to hear from you. I noticed Larry isn't active; I miss him. I do recall a vague impression of reading about the braid somewhere, but it's been so many years that it'd be more productive to assume I know very little. That goes double for things which have changed in the past half decade. Relevant links or explanations are totally welcome, including anything I may have already known. When I have another block of time to throw at this, I was going to look for useful examples in slangs on the ecosystem, and read docs some more. Asking specific questions in #raku was not fruitful, and I've avoided cluttering #raku-dev as I'm not currently contributing to raku itself. |
It was quite interesting to explore the idea, and I got a conference talk out of it (which I believe remains the most brain-melting one I've done to date). :-)
This module always was going to be terribly fragile due to its reliance on Rakudo compiler guts. However, there's good news: the ongoing RakuAST work means that there will finally be a supported API providing access to the grammar syntax tree - at which point there will be a supported way to write a module like this! I do wonder, however, if that will ultimately be the "easy" part. Glancing the code, it seems I decided to do whatever the generative alternative to backtracking is with copious use of coroutines, nicely embedded in a tree of closures, and I'm still not sure if that's beautiful or terrible (I'm quite sure it isn't going to be very fast, and would be rather "fun" to debug). Looking at it the better part of a decade on, I'm mildly horrified that this relatively small amount of code was able to run, if I remember correctly, a JSON grammar backwards. Anyway, it'd be a nice thing to resurrect once we have RakuAST. |
|
I did enjoy that talk very much when I originally watched it! Now that I realize it relies on unspeced compiler guts, I understand why it's been so broken for so long and why I've had difficulty determining the correct path forward. I don't know much about the RakuAST work other than having seen it mentioned, but it sounds quite exciting. If you don't like the tree of closures, perhaps RakuAST could help there also, by building up a single large function for the entire grammar as you walk the tree at compile time, instead of a small separate function for each branch. The same could be done now, but you'd have to build the function textually and then EVAL it (a technique I'm unfortunately reliant on in multiple modules). Thanks for the update! Keeps me from chasing my tail in circles. I appreciate the context, and the AST excitement to look forward to. |
The text was updated successfully, but these errors were encountered: