. The This is an error
message\n gets read into the variable as expected, but P::RD's error
messages are printed to STDERR nonetheless.
you can cheat P::RD with directly accessing $thisparser-{errors},
see the FAQ: 'Accessing error data' and the answer by Damian
Best Redards
Charly
--
Karl
I just browsed the archives and found this:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00215.html
which is the exact question I just asked... Can I assume from the
unanimous silence that nothing has happened about this in the last two
years?
Jonas
Hi,
I think your question is related to the OS you're using and not to P::RD.
Have you tried redirecting STDERR (as in perldoc -f open) before calling the parser?
And you can always modify Descent.pm if you don't like what it's doing with STDERR ;-)
Regards
Alex
-Original Message-
Hi,
I want to capture error messages issued from the parser using the error
directive into a variable instead of echoing them to STDERR. Is there any
way to do this?
Thanks, Jonas
to match the yellow against the
yellow!
After spending a few more hours at it, and trying pretty much every
possible combination of error, error?, reject,
commit, etc, I've
given up on getting error messages.
As i sadi im pretty sure it never even gets to the point in the grammar
where
producing the right error messages now. I think
I'll just
quietly leave it alone for a while and put a big warning in
there not to
touch it ;)
With a note like :Caution: Here Be Dragons
Uhuh. In fact, my tendency is to use {1} as the autoaction
and to explicitly
provide the others. I
::skip, but I've spent long enough battling with this
that I want to know why it doesn't work.
PROBLEM 2:
I'm trying to get error messages from the parser I've created and I
can't figure out how. Here's a contrived example because the real
grammar is too long to post; I'll explain my problems after
.
and later on in the doc (shame on my head, but anyway it
doesn't solve the problem with misleading error messages)
Terminal Separators
For the purpose of matching, each terminal in a production is
considered to be preceded by a ``prefix'' - a pattern which
must be matched before a token match
