Fromn the logs, it looks like Unicode strings are being treated as
Latin-1 after a round-trip through Marpa -- the bug Jean-Damien
pinpointed and I (so I thought) fixed. The Jean-Damien gist you mention
as running OK included workarounds for the bug.
I'm hoping this is just an issue with the specific Perl/OS combination
or the specific build, rather than with Marpa. As you mention, testing
looks good elsewhere, including on other MSWin setups with Perl releases
both before & after.
Perhaps Jean-Damien can shed some more light on this.
-- jeffrey
On 12/22/2013 11:10 AM, Ruslan Shvedov wrote:
All fine on cygwin; however, sl_advent.t fails all 'using char class'
and 'using hex' tests ('using strings' are all ok) on perl
5.14.2 under WinXP SP3 (cl MS VS .NET 2003) for me, logs attached.
Jean-Damien's gist <https://gist.github.com/jddurand/8047822>runs ok.
I saw Marpa-R2 2.077_014 passed on mswin32 under higher version perls
so perhaps it's only me, but just in case. :)
On Sun, Dec 22, 2013 at 7:46 AM, Jeffrey Kegler
<[email protected]
<mailto:[email protected]>> wrote:
I've just uploaded a new release candidate, Marpa-R2 2.077_014
<https://metacpan.org/release/JKEGL/Marpa-R2-2.077_014>, to CPAN.
In it the SLIF recognizer's named argument processing is changed
to leave the original hash untouched.
I've left myself some flexibility by not changing the
documentation, but realistically, given my attitude toward
regressions, this pretty much paints me into a corner on the issue.
I opened myself to this kind of argument hash manipulation by
allowing multiple argument hashes. That is, for most Marpa methods
that take named arguments, you can do
$obj->method( { arg1 => value }, { arg2 => value, arg3 =>
value }, ...)
Allowing this is unusual in Perl modules -- it may even be one of
my inventions. I originally did it to overcome one of the limits
of Perl's hashes-as-named-arguments processing -- lack of control
over the order. Allowing more than one hash allows you to both use
hashes and to specify the order in which the arugments will be
processed. Order of argument processing is not an issue in the
SLIF, but in some previous Marpa interfaces it was. As one
example, in the Pure Perl versions, it was often useful to specify
at what point in the argument processing certain kinds of tracing
were turned on or off.
Anyway, once you start to put together the named arguments in
pieces, that very naturally carries over into a desire to reuse
the pieces.
-- jeffrey
--
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]
<mailto:marpa-parser%[email protected]>.
For more options, visit https://groups.google.com/groups/opt_out.
--
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/groups/opt_out.
--
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/groups/opt_out.
