KIMURA Takeshi <[EMAIL PROTECTED]> writes:
> Gisle Aas wrote on 00.9.17 1:57 AM:
> >This release contains experimental support for decoding of Unicode
> >entities. This is the only change since 3.12.
>
> Thank you for the new release.
>
> I built up the XS and installed it on MacPerl and tested the t
> files.
>
> I get some errors as shown below. The problem seems to be
> MacPerl specific since it is based on 5.004, but I canot be very
> sure.
>
> Can anybody give a clue to figure out the problem?
Isn't MacPerl prepending some string to the exception string (in $@).
At least some of this looks like it can be failing because of this. I
seem to remember having patched LWP for some of this brain damage.
Why does MacPerl do this?
Regards,
Gisle
> <argspec-bad.t>
> 1..6
> # Unrecognized identifier xyzzy in argspec.
> File 'KIM-HD-001:WorkShop:MacPerl XS:MacPerl_Src:perl:ext:HTML-
> Parser-3.11:t:argspec-bad.t'; Line 9
> not ok 1
> # Missing comma separator in argspec.
> File 'KIM-HD-001:WorkShop:MacPerl XS:MacPerl_Src:perl:ext:HTML-
> Parser-3.11:t:argspec-bad.t'; Line 17
> not ok 2
> # Unterminated literal string in argspec.
> File 'KIM-HD-001:WorkShop:MacPerl XS:MacPerl_Src:perl:ext:HTML-
> Parser-3.11:t:argspec-bad.t'; Line 25
> not ok 3
> # Backslash reserved for literal string in argspec.
> File 'KIM-HD-001:WorkShop:MacPerl XS:MacPerl_Src:perl:ext:HTML-
> Parser-3.11:t:argspec-bad.t'; Line 33
> not ok 4
> # Literal string is longer than 255 chars in argspec.
> File 'KIM-HD-001:WorkShop:MacPerl XS:MacPerl_Src:perl:ext:HTML-
> Parser-3.11:t:argspec-bad.t'; Line 40
> not ok 5
> ok 6
>
> <handler.t>
> 1..11
> not ok 1
> not ok 2
> ok 3
> ok 4
> ok 5
> ok 6
> ok 7
> not ok 8
> ok 9
> ok 10
> ok 11
>
> <magic.t>
> 1..5
> not ok 1
> not ok 2
> not ok 3
> not ok 4
> ok 5
>
> <options.t>
> 1..5
> ok 1
> ok 2
> ok 3
> ok 4
> not ok 5
