> > 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.
Assertions and failure handling put in.
No change.
Updated to to libmarpa 8.6.0. (Head of trunk as of sometime today).
No change.
Looked for a way to get more debugging info out of libmrpa, found
_marpa_v_trace().
Activated this.
While my tracing now shows `step-trace` steps as well, it does not
make a change with respect to the other step-types. Still only
step-token and step-inactive.
I believe I will step away from this for a while, do other stuff, let
the back of my mind think about ways of instrumenting marpa_v_next()
to see what it is actually doing in this situation, and other possibilities.
--
See you,
Andreas Kupries <akupr...@shaw.ca>
<http://core.tcl.tk/akupries/>
Developer @ SUSE (MicroFocus Canada LLC)
<andreas.kupr...@suse.com>
Tcl'2017, Oct 16-20, Houston, TX, USA. http://www.tcl.tk/community/tcl2017/
-------------------------------------------------------------------------------
--
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 options, visit https://groups.google.com/d/optout.
