Re: discarded then accepted

Thanks - this was with latest dev version and is not a bug - a pb in my grammar -; I am dealing with a new grammar that is newline oriented and this is causing me some problems -; JD. Le samedi 18 janvier 2014 08:16:56 UTC+1, Jeffrey Kegler a écrit : > > It's quite possible with two different l

Re: discarded then accepted

> > By the way, it's helpful to me if you always mention which version is > referred to, and whether the issue seems to be new as of that version (to > the extent you know). Particularly when I've just released a new version, > my mindset is to wonder if the behavior described is a regression,

Re: sl_json.t with ASF semantics a bit slower than AST: as expected?

Is it intended that the JSON grammar is not reused? The script would 2 times faster if it were. On Thu, Jan 16, 2014 at 8:53 PM, Jeffrey Kegler < jeffreykeg...@jeffreykegler.com> wrote: > $naif_recce->value() is being called to parse the JSON grammar, as > opposed to the JSON itself. Note that

alternative() failed

Jeffrey, Another question: Is the message "Problem in u_read(), alternative() failed: Token symbol is inaccessible at /usr/local/lib/perl/5.18.2/Marpa/R2/SLR.pm line 881" expected to be a problem in the user's grammar or in the SLIF internals ? This is with 2.07901. Thanks / JD. -- You rece

Re: alternative() failed

cpan/libmarpa/dev/api.texi [1] says it "typically indicates an application error", so internals are less likely. [1] @deftypevr Macro int MARPA_ERR_INACCESSIBLE_TOKEN This error code indicates that indicates that th

Re: alternative() failed

I'd expect it indicates the the symbol being read is not accessible, that is, not reachable from the start symbol. The message isn't of the best -- it talks too much about the internals. Was there a warning message that you have an inaccessible symbol? -- jeffrey On 01/18/2014 05:45 AM, Dur

Re: sl_json.t with ASF semantics a bit slower than AST: as expected?

This is from MarpaX::Demo::JSONParser, right? That gives you a choice of two grammars, and if you chose mine, it was written for benchmarking with long input strings, so I wasn't optimizing for repeated parses of short strings. There's also Peter Stuifzand's grammar, and Peter's intentions w

Adding lhs array descriptor -- push_lhs command implementation

Context . With this commit push_lhs command returns the right LHS id's to the test script. Jeffrey, can you take a look? Those comments with '-

Re: alternative() failed

Ah yes, sorry, these messages were lost in the thousands of lines of debug... I am experimenting with a grammar that give me troubles-; forgiving keyword included. Thx / JD. Le samedi 18 janvier 2014 17:33:56 UTC+1, Jeffrey Kegler a écrit : > > I'd expect it indicates the the symbol being r

Re: sl_json.t with ASF semantics a bit slower than AST: as expected?

On Sat, Jan 18, 2014 at 6:42 PM, Jeffrey Kegler < jeffreykeg...@jeffreykegler.com> wrote: > This is from MarpaX::Demo::JSONParser, right? That gives you a choice > of two grammars, and if you chose mine, it was written for benchmarking > with long input strings, so I wasn't optimizing for repeat

Re: Adding lhs array descriptor -- push_lhs command implementation

I made comments on the commit. With regard to name vs. ID, I'd return the ID. They might *want* the ID and if you've already converted it to a name, they'll have to convert it back. After for the name of the descriptor element, "lhs" vs. "lhs_id", you're closer to this, I'll let you make the

Re: Adding lhs array descriptor -- push_lhs command implementation

On Sat, Jan 18, 2014 at 8:10 PM, Jeffrey Kegler < jeffreykeg...@jeffreykegler.com> wrote: > I made comments on the commit. > Thanks, I answered on the mailing list. With regard to name vs. ID, I'd return the ID. They might *want* the ID > and if you've already converted it to a name, they'll ha

Re: sl_json.t with ASF semantics a bit slower than AST: as expected?

Exactly. See also the FAQ question: http://savage.net.au/Perl-modules/html/MarpaX/Demo/JSONParser.html#Which_JSON_BNF_is_best%3F -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, s

Undo's

I am working at adding "undo's" to Libmarpa -- the ability, while a parse is in progress, to go back and erase or "undo" some of the rules it has recognized. Potential applications include zero-width assertions. Zero-width assertions are things like word boundaries and line endings, etc. Regexes

Re: [ASF's] can't use per-traversal object

Fixed in commit fd82c77. Thanks! -- jeffrey On 01/16/2014 07:06 AM, Ruslan Shvedov wrote: I'm trying to use per-traversal object in Marpa::R2::ASF (latest dev version, 5.14.2, cygwin) like this: $asf->traverse( { 'grammar' => $g }, \&generic_traverse

Re: Undo's

This typo 'they're state machines that run deal in character sequences' in the 2nd para is confusing me. -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to marpa-p

Re: sl_json.t with ASF semantics a bit slower than AST: as expected?

Yes, I think it's a great exercise for Marpa, and it's one I've run often. I'd be glad to see someone else running it. And, yes, running against JSON::PP is something I often do. JSON::XS is beautifully written C code dedicated to parsing that one grammar -- Marpa is never going to beat that.

Re: Undo's

I intended something like this: they're state machines that treat their inputs as character sequences -- jeffrey On 01/18/2014 10:29 PM, Ron Savage wrote: This typo 'they're state machines that run deal in character sequences' in the 2nd para is confusing me. -- You received this message

Re: Undo's

OK. So 'run deal' probably should read 'only deal'. Thanx. -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to marpa-parser+unsubscr...@googlegroups.com. For more op