Re: Trouble with retrieving valuation steps.

[Andreas Kupries]

While a necro of the thread, I can say that the issue is now SOLVED.


Given that the initial lexer and parser made before I started on the
RTC are working correctly I did a stronger audit of my code to find
any differences in the use of the libmarpa API between working and
breaking engine.

The difference is that the working engine calls

marpa_g_force_valued()

on the grammars immediately after creation, and the RTC code did not.

With this call added to the RTC lexer/parser the valuation begins to
return step-rule and step-nulling as well.

In hindsight the issue is clear.

Without the call the symbols of the grammar are not valued (by
default?), and thus any valuator based on such a grammar has no need
of returning the kind of instructions to deal with the construction of
such.

May I propose to change the line

It is recommended that this call be made immediately after the
grammar constructor. It turns off a deprecated feature.

in the documentation of `marpa_g_force_valued()` to read

It is __required__ that this call be made immediately after
the grammar constructor. Without this call valuators derived
from the grammar will not emit instructions of types
MARPA_STEP_RULE or MARPA_STEP_NULLING_SYMBOL.

or similar? Anything which explains the symptoms when not making the
call a bit clearer than just a general reference to a `deprecated
optimization for evaluation`?!

Maybe also a direct reference/note in the documentation of
`marpa_g_new()` as well ?


Right now I wonder if I ran into this when writing the Tcl
lexer/parser as well, and had forgotten about it when I started on
RTC. Or that I was more observant when reading the docs.


> > Not necessarily relevant but marpa_v_step() can return a negative
> > number on failure, and I think this is not handled. In particular
> > there are a number of cases of unexpected returns from
> > marpa_v_step() which you handle via fall-through which probably are
> > better treated as fatal errors.
>
> > Same with marpa_v_new() -- it can return NULL on failure and this is
> > not checked for. I have no real evidence that this has anything to
> > do with your problem, but this is C language so subtle stuff could
> > be happening with memory overwrites, etc.
>
> Agreed.
>
> > And the checks *do* belong in your final code, so you might as well
> > have them in for debugging.
>
> Agreed as well.
>
> Will definitely put in code to handle failures ... Oh, the bocage
> wrapper needs them as well. If I remember correctly it does not handle
> these things either.
>
> Are the negative numbers from marpa_v_step() regular marpa error
> codes, or are they their own set ?
>
> Memory. Right. While I am mostly confident that I managed to avoid
> issues, due to the lot of assertions I put in all over the place it
> will definitely not hurt (except speed (*) of the system) to activate
> the memory debugging Tcl's memory utility functions provide, and
> should trip anything bad I may have in the code.
>
> Thank you for the reminder of that.
>
> (*) Especially if I have it check the entire set of allocations on
> each and every malloc, realloc, or free, instead of just the
> specific memory allocated or freed by the current call.
>
>
> > > On Thu, Aug 17, 2017 at 6:55 PM, Andreas Kupries <akup...@shaw.ca> wrote:
> > >
> > >>
> > >> > Looked some more at `rule` and `rslot` and I not 100% sure it's wrong,
> > >> but
> > >> > I can't convince myself it's right.

--
See you,
Andreas Kupries <akup...@shaw.ca>
<http://core.tcl.tk/akupries/>
Developer @ SUSE (MicroFocus Canada LLC)
<andreas...@suse.com>

Tcl'2017, Oct 16-20, Houston, TX, USA. http://www.tcl.tk/community/tcl2017/
EuroTcl 2017, Jul 8-9, Berlin/DE, http://www.eurotcl.tcl3d.org/
-------------------------------------------------------------------------------

[Jeffrey Kegler]

Glad to hear the problem is solved!

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.