[DGD] Working with parse_string()

[Shentino]

This reminds me of another couple of questions I've wanted to ask:

1.  Apart from padding a grammar with ambiguity catching error cases, is
there any way to extract diagnostic information from a bad parse?

So far, I can think of tracking the successful fragment parses as "progress
points"

2.  How do you handle a grammar parse where the grammar, the sentence, or
both exceed the limits of string size, without hacking DGD and upping the
limits.

A case in point for this would be parsing a very large XML document that was
larger than 64K

On Tue, Jul 21, 2009 at 3:25 AM, Felix A. Croes <felix at dworkin.nl> wrote:

> Kamil N <kamiln at gmail.com> wrote:
>
> >[...]
> > By the way, is there any way I can somehow track runtime errors that
> > happen inside parse_string() function, for example in LPC functions
> > that are called by the parser? The most detailed error message I can
> > get is:
> >
> > Runetime error: Index on bad type [caught]
> >   46 receive_message   /kernel/obj/telnet (#25)
> >  197 receive_message   /kernel/lib/connection (/kernel/obj/telnet#25)
> >  232 receive_message   /usr/System/obj/user (#26)
> >   37 input             /usr/System/obj/wiztool (#27)
> >  763 call_limited      /kernel/lib/auto (/usr/System/obj/wiztool#27)
> >  100 process           /usr/System/obj/wiztool (#27)
> >  917 cmd_code          /kernel/lib/wiztool (/usr/System/obj/wiztool#27)
> >   10 exec              /usr/admin/_code
> >   39 do_parse          /usr/admin/parser_test
> >
> > Line 39 is just where I call parse_string() so it doesn't really help
> > with finding in which LPC function this runtime error ocurred.
>
> Line 39 is where the error is.  Had it been in a LPC function called
> by parse_string(), the error trace would have included that function.
>
> Regards,
> Felix Croes
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>