Glad to hear the problem is solved! On Thu, Sep 14, 2017 at 11:56 PM, Andreas Kupries <[email protected]> wrote:
> > 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 <[email protected]> > 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 <[email protected]> > <http://core.tcl.tk/akupries/> > Developer @ SUSE (MicroFocus Canada LLC) > <[email protected]> > > 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/ > ------------------------------------------------------------ > ------------------- > > > > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
