t/01_bad.t Failed test 'XML-Liberal-0.30/t/bad/BAD-chr-31.xml' at t/01_bad.t line 28 got: ' at position unknown location .. ' expected: '' #4
Comments
|
See also this question on stackoverflow.com |
|
In lib/XML/Liberal/Remedy/StandaloneAttribute.pm, we have my ($attr) = $error->message =~
/^parser error : Specification mandate value for attribute (\w+)/
or return 0;This should be my ($attr) = $error->message =~
/^parser error : Specification mandates? value for attribute (\w+)/
or return 0;(I'm assuming that some versions of libxml2 returned |
|
The other bug, bless( {
'message' => undef,
'line' => undef,
'column' => undef,
'location' => undef
}, 'XML::Liberal::Error' );Not a fix, but wouldn't it be better to get rid of XML::Liberal::Remedy::ControlCode and simply doing |
|
Fixed the regexp for |
|
@miyagawa I now get an error when I run |
|
that's because you don't have Module::Install::Repository and is not related to the test errors in this issue. |
|
I converted the repository to use Milla so you don't need to have Module::Install and its plugins. |
|
Ok great, I retried now: |
|
I can't reproduce the error: what version of perl and libxml2 do you have? Mine is Perl 5.32.1, and |
|
|
The fix is to replace my $error = $self->extract_error($@, \$xml);with my $error = $self->extract_error("$@", \$xml);I'm guessing the AUTOLOAD mechanism is implicitly localizing |
|
Interesting. Is that a change in perl 5.34? |
|
Bizarre, still can't repro with perl 5.34.0 with my libxml2, so it must be libxml2 version somehow that doesn't materialize this condition. |
|
You're right. It has nothing to do with AUTLOAD. The problem is that you're hitting this: |
|
Yeah, libxml2 might have changed the errors for the bad encoded characters. |
|
When I stringify $@, this is what I get: |
|
In any case, it can be avoided entirely by doing |
|
Well this is still weird, the logic still should have handled it correctly: if it encountered the Here's what I get if I add a debug output for I don't like the idea of fixing the XML before running it through the parser, since it will munge the input. |
|
I was able to reproduce with libxml 2.9.14, and applied the fix. |
|
Great, the last version works fine here (no failed tests). |
huh? You end up doing it anyway. You're just making the module slower and more error-prone. It's already broken once and you want to risk it happening again? |
|
There's a difference between proactively processing the data and reactively patching the data as the parser emits errors, and this module by design only does the latter. And the performance is not a concern for this module. Nothing stops you from doing the preprocessing before calling the module, though. |
|
What is this difference to which you allude?
And performance was just one of the two problems I brought up.
|
|
I pretend not to know anything about incoming XML whether it's valid or not. It runs it through an existing parser, and fix them as errors happen. That's the design, whether you like it or not. It's very error prone, but the entire concept of running it through another module and doing something based on its error message is, if that was not obvious. Changing how to handle one error message out of many doesn't change that. |
|
??? Did you identify the difference in there?
…On Tue, Mar 22, 2022 at 5:42 PM Tatsuhiko Miyagawa ***@***.***> wrote:
I pretend not to know anything about incoming XML whether it's valid or
not. It runs it through an existing parser, and fix them as errors happen.
That's the design, whether you like it or not.
It's very error prone, but the entire concept of running it through
another module and do something based on its error message is, if that was
not obvious. Changing how to handle one error message out of many doesn't
change that.
—
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFK2ZKGI4FXB33AISTPAF3VBIWEBANCNFSM5P5XHPPQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I'm going to reply to your original question. The entire code is based on "run it through the parser, parse the error output and apply a patch". If you describe that is error-prone (which I do not disagree), there's nothing to do about it, other than rewriting the module to apply the known patches beforehand, which is also error prone, because then you have to be an XML parser on your own. I don't understand what you're trying to get out of this conversation. Clearly you're not required to use this module (I suppose you don't anyway, and to be accurate, I don't either). Locking the issue. |
I am trying to install on Ubuntu 21.10, perl version 5.34.0:
The text was updated successfully, but these errors were encountered: