On Mon, Dec 23, 2013 at 12:45 AM, Jeffrey Kegler <
[email protected]> wrote:
> 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.
>
Yes, and that fixed bug shows IMHO in a third ('using strings') of the
tests passing.
I just tested input strings utf8::is_utf8() in sl_advent.t and it shows
that they're not utf8 unlike in Jean-Damien's
perl6advent.day18.with.marpa.pl where that are read from __DATA__ section.
And, once I move
use utf8
anywhere before
use open ':std', ':encoding(utf8)';
all tests pass. Pull request submitted, case closed I think. :)
> 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]> 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].
>> 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.
>
--
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.
