|Do you know where your variables are?|
Weirdness (and bugfix for) XML::DOM ...by deprecated (Priest)
|on Feb 25, 2001 at 14:43 UTC||Need Help??|
deprecated has asked for the
wisdom of the Perl Monks concerning the following question:
Hi, Monks... My quest to get the Everything Engine running continues.
This is what I encountered earlier today (`make test`) when building XML::DOM. I will node something in the next couple days regarding my adventures getting this code to work. However, at the moment, it still doesn't. The fix for this particular error (yes it is an error) is very simple:
This strikes me as a particularly careless error on the author's part. However, it doesnt quite end here. When we run make test now, we still have the errors from before:
After a bit of hacking around, we see this code in ./CmpDOM.pm:
I did a fair amount of bitching this morning in the CB about this. I will spare everyone the rant, but basically, I feel this code is extremely stylistically impaired. There is not one single line of comment in it. After some searching and yelling, we find that $p1 is looking for a method 'equals' in the file /home/perl/lib/site_perl/5.6.0/ppc-linux-thread-multi/XML/Parser/Expat.pm which, according to perl (and correctly), doesnt exist. Getting the feeling that this module was hopelessly borked anyways, I decided to add that method to Parser::Expat. I added this code:
This is about as kludgey as I am willing to get on code that will actually be used. I interpret this to mean "if the parameters we are passed are both true, return the object that called us (which will mean true to a test since we got here anyways) otherwise, return undef." Sure, its ugly, but the method doesnt exist and the author provides no documentation for what this should actually be doing nor why it is coded as such. The good news is it then clears the syntax. Furthermore, it clears up a "dubious" result from the test. We are still left with two errors:
back in the attr test, we see this code:
The output of this was positively infuriating. As it turns out, the reason this assertion is failing is thus:
We fix this, and the test is passed. The last test, 'print' fails for a similar reason. In t/print.t:
I am really not one to be negative. And I am also totally unfamiliar with XML. But I am going to go waaaaay out on a limb here and say that these errors are criminally negligent. I read recently here in the CB that XML requires strict adherence to RFC's (or whatever) and mandates failure. Personally, if that is the reason this module failed to test correctly, I dont want anything to do with XML. No thank you. However, if this is in fact what I think it is, egregious errors on the part of the author, I am happy to have been able to provide a fix for people having trouble with it.
Before you ask if this is perhaps something I have locally (jptxs was able to successfully install this module), I have two things to say. First, this copy of perl was installed from scratch, by hand, today. Bundle::XML was the first package to be installed because I was so hell-bent on getting XML to work. Second, it is certainly possible that XML::Expat uses some weirdness in its c-code (provided it has any compiled c code at all). This is a PowerPC, so there might be some compilation differences. If that is the case, I apologize for my fiery rhetoric. Nobody, however, should ever have to spend hours fixing somebody elses undocumented, poorly styled, BROKEN code.
off my soapbox, and on to the Engine...