| Subcribe via RSS

Understanding Encoding (Trying To, At Least)

March 3rd, 2014 | 2 Comments | Posted in Perl, XML

Earlier this evening was a presentation at the San Francisco PM group, on “Unicode & Everything”. I wanted to go, but had a conflict so I had to miss it.

Character encoding is an area I’m weak in, and one that I need to be better at. My biggest module, RPC::XML, supposedly supports encodings other than us-ascii but in truth it’s pretty broken. I recently applied a patch that fixes the handling of UTF-8 content, but that’s not what I need. What I need is for it to properly handle content in (theoretically) any encoding. I don’t think that a talk focused on Unicode would have covered that, but I was hoping that I might be able to corner the speaker afterwards to bounce some questions off of him.

What it comes down to, is this: my library creates requests and responses in well-formed XML, complete with an encoding attribute in the declaration line:

<?xml version="1.0" encoding="us-ascii"?>
<methodCall>
    <methodName>someName</methodName>
    <params>
        <param>
            <value><string>Some string data</string></value>
        </param>
        <param>
            <value><int>42</int></value>
        </param>
    </params>
</methodCall>

What matters here is not the structure of XML (in this case)– it’s the encoding="us-ascii" part, and this line:

<value><string>Some string data</string></value>

See, my library generates the XML around the “Some string data“, but the string data itself comes from whatever the user provides, and the user expects that to be in the encoding he or she specified. And here is where I start to get confused: I know that the boilerplate code is US-ASCII (in the range that makes it passable as UTF-8), but I suspect that I can’t just paste in a string encoded in ShiftJIS and slap on encoding="shiftjis" in the XML declaration. Or can I?

XML-RPC has a very limited vocabulary and set of data-types. The character range, funny-encoded-strings notwithstanding, is just basic ASCII. You have the tags, then strings, integers, doubles, date/time values (ISO8601) and base-64 data. Regardless of encoding, all of these except the strings stay in the ASCII range.

So for those reading this that are more adept as working with encodings than I, how to approach this? Is the magic sauce somewhere in Perl’s Encode module? I really want to get this part of the RPC::XML module working right, so I can move on to the next big hassle, data compression…

(I also need to figure out why my code-highlighting plugin isn’t doing its job…)

(I think I got it now. Something was missing from one of the theme files. Gotta love WordPress/PHP…)

Tags: , ,

Test Suites: To Critic or Not?

February 19th, 2014 | 1 Comment | Posted in CPAN, Perl

Over the holiday weekend, I spent a good amount of time cleaning up my RPC::XML test suites with regards to Perl::Critic. It wasn’t quick work, either: Much of the suite was written when RPC::XML was first under development, which makes a lot of it well over 10 years old. But I had an extra day, and plenty of time to kill. So 25 files and one git commit later, my test are all clean with respect to my chosen Perl::Critic configuration. The exceptions are a couple of Modules::ProhibitExcessMainComplexity complaints, and most of them also chirp about Modules::RequireVersionVar because the policy doesn’t allow for exclusion of files like test suites.

But all through this, I was wondering: Does it really matter if your test suites are as clean as the code itself?

How often does someone else look at your test suites as closely as they look at the modules that those tests support? I’m not setting up a life-lesson here, I’m genuinely curious. I spent some time thinking about it, and I can say that the only times I’ve looked at test suites in other distributions has been when I was trying to figure out how they did something, or how a particular testing module is used. I’ve very rarely looked for examples of how to write my own tests, and I probably should. I’m pretty sure I could learn from some (most?) of them.

See, I look at Perl::Critic as at least partly geared towards the readability of code; using Perl::Critic helps me make my code more consistent in style and structure, which in turn makes it more readable. I introduced it into my day job (along with a web front-end) largely to try and encourage certain consistencies in style, uniformity even, in the name of corralling Perl coders who had no collective style. Yes, there are a lot of other benefits to critic that are there to be had. It has led me directly to bugs, or to code that could potentially fail, on numerous occasions. But for me, myself, style and structure are the order of the day. So, if few people look at your test suites, is there any reason to run them through the critic?

After a day or two of idle background-thought on it, I’ve decided that it is worth it. Even if the only person who looks at your tests is you. Because you do eventually have to look at those tests. And RPC::XML is not even remotely the oldest CPAN module, so there are distributions out there whose tests are much older than my 10+ years. And that’s plenty of time to forget WTF you were thinking when you wrote the test. The least you can do is try to make it readable for the next time you have to look at it.

Tags: , , ,

CPAN Testers Follow-Up: Progress Is Made

February 13th, 2014 | 3 Comments | Posted in CPAN, Perl

Or, How I Learned It (Mostly) Wasn’t My Fault

So, in my previous post I noted how my reward for getting back on the horse had been a slew of failure reports from the CPAN Testers service. This is a follow-up on what I’ve learned these last 6 days.

First, Do Not Panic

You’ve just gotten a barrage of FAIL reports from CPAN Testers. Don’t get yourself agitated over this. Think about it: You’ve just been handed (free of charge) the results of someone else taking the time to test your product for you, probably on a combination of architecture/OS/Perl that you didn’t have available to test yourself. This is a good thing for you. Once upon a time, you wouldn’t have had this until someone was actually using your code in the field. Then the report you got would have been from someone annoyed and/or angry over breakage. Instead, you’ve gotten some number of reports that look like this, which can hopefully help you zoom in on the issue.

I (kind of) panicked. Fortunately, after someone responded to my previous post I was able to calm down and start looking at the content of the reports more rationally.

Second, Figure Out What’s Gone Wrong

Look, you wrote the module in question. This means that you are almost certainly the best-suited to determine what went wrong. (Not always, as I’ll point out a little later, but probably.) Look at the reports carefully, see what tests failed. Look at those tests yourself and see what could have tripped them up. Look for counter-examples, or noteworthy differences. In my case, the majority of my test failures were caused by my server class (RPC::XML::Server) failing to instantiate because (it claimed) the address it was told to bind to was in use. This didn’t make sense, as I had code I was using that actually scanned for a port that wasn’t in use. The port that the server was trying to bind to had, just moments before, been judged available by virtue of the fact that a raw socket connection to it had failed. So what was wrong? Why was it failing? And more interestingly, why was it failing in these cases, but not in the dozens of PASS reports that I had also racked up?

I noticed that all the failing cases had something in common: a comment in the test output stream that a package called Acme::Override::INET was monkey-patching IO::Socket::IP in place of IO::Socket::INET. I had my first big clue.

Third, Prepare an Environment for Testing

If you aren’t using perlbrew, then either you aren’t testing as well as you could be or you’re spending way more effort on your testing than you need to be. I first started using it because the Perl that comes with Mac OS is older, and I wanted to be able to install and update CPAN modules more easily. Then I started keeping a half-dozen or so different additional installations of Perl around, at various versions with and without threading. If you’re developing modules, it’s an invaluable tool for testing your modules across different versions. It also meant that I could install Acme::Override::INET and IO::Socket::IP in a Perl other than my “main” one, so that I didn’t upset my primary work/development environment.

So I did just that; I picked a version of Perl that I had that was identical to one that had failed in one of the reports, and installed those two modules.

Fourth, Learn What You Can

Suddenly, I too was getting the exact same failures in the exact same places. This was great! I started throwing in some debugging statements, and verified that in each case a previous server allocation had succeeded but the next allocation (which was re-using the same port) would fail. For some reason, IO::Socket::IP seemed to be causing sockets (or at least the port allocations) to hold on beyond the life of the socket. I even managed to show that the error occurred over the process boundary, when I ran a test twice in rapid succession and the second run failed in the first server allocation! When I removed Acme::Override::INET and IO::Socket::IP, it immediately started working again. Same tests, same code, same Perl executable… the only difference was IO::Socket::IP.

(I should note here that un-doing the installation of Acme::Override::INET is tricky. It installs a “fake” IO/Socket/INET.pm file, but it uses Module::Build to do so. Unless you have M::B configured to use the same installation locations as ExtUtils::MakeMaker, M::B will install in a directory that is earlier in your search path than the directory that E::MM uses. So re-installing the IO module will not overwrite the IO::Socket::INET fake that Acme::Override::INET installed. I had to delete all four files that were installed.)

Fifth, Do Something with Your New Knowledge

So I opened up an RT ticket for IO::Socket::IP, and explained my situation at length in it. The module’s author replied and pointed out that the way I was selecting a port was much more work than I needed to do in that case. See, I’m not actually very adept at network programming. That’s actually an understatement… if it weren’t for HTTP in general, and HTTP-related Perl modules like LWP in particular, I would probably not have a CPAN module to my name that is so network-centric. Anyway, I at least felt at this point that there wasn’t anything wrong with RPC::XML::Server. But based on the suggestions from the IO::Socket::IP author, I changed most of my server-oriented tests to let the kernel allocate a random port instead of me selecting one. Now the tests all pass, even with the newer module and the monkey-patch installed. Mind you, there is still an issue with IO::Socket::IP, but I can’t help there. I can only hope that the information I’ve provided helps him out.

Sixth, and This Is Important, Be Content With It

It’s frustrating to know that there will still be some FAILs coming in, but I can’t help that. I can be happy with the fact that my tests are fixed, that there wasn’t actually anything wrong with my networking code (because I’d be close to lost if I had to go into a deep dive to troubleshoot that part). There are still things to fix and add to the RPC::XML package, but my server tests are all now a bit more robust than they were this time last week. I’ve found and reported an issue that will hopefully help another CPAN author. And, importantly for me, I’ve stayed engaged in my code for this last week. That’s been hard for me to do for a long time now, and it feels really good to have done it. Even though it’s only been about 5-6 hours of effort spread across that many days, I’m happy about it, and that will hopefully mean that the next 5-6 hours will come more easily.

Tags: , ,

CPAN Testers and RPC-XML: Well, Crap

February 7th, 2014 | 1 Comment | Posted in CPAN, Perl

So I’m starting to break my drought on personal-project coding, and yesterday I cut a new release of RPC-XML, the first one since September of 2012. I’m pretty happy about this; besides the fact that I was able to clear out my pull-request queue on GitHub, this means that I’m (slowly) getting my “old self” back. I’m (slowly) starting to work on my hobby-programming, and no longer seem to be limited to just doing my work for my day job.

Then this morning I checked my RSS feed for CPAN Testers Reports. NINE failures, all of them tests that passed just fine on my dev platform and on my Linux server. Tested with multiple Perl versions, etc. Granted, I don’t test other versions/platforms exhaustively, not compared to some people at least. But the things that seem to be failing are tests that have always passed before. Like, suddenly some of the tests that actually create server objects are failing to bind to their given address, saying that it’s already in use. Except that I programmatically select a port by first establishing that it is not in use. I suppose that theoretically it is possible that some other process stepped in between the time I do the port-detection and the time I actually allocate the server object. But like I said, these are tests that were passing just fine before. There are some others, as well, that seem to be consistently problematic for people who are not me. But I don’t get a lot of information from the CPAN Testers reports, just the output from “make test”, really. So until/unless I can replicate those failures, I’m not sure how to address them.

This isn’t really what I pictured, when I finally started getting back in the saddle…

Tags: , ,

Perl Module Release: RPC-XML 0.78

February 6th, 2014 | No Comments | Posted in CPAN, Perl, Software, XML
Version: 0.78
Released: Thursday February 6, 2014, 08:00:00 PM -0800

Changes:

  • lib/RPC/XML.pm

A patch to loop detection in smart_encode from Dag-Erling Smørgrav. Some other minor bits.

  • lib/RPC/XML/Procedure.pm

RT #83108: Fixed a spelling error. Some other fixes, too.

  • lib/RPC/XML.pm

RT #86187: Force key-ordering in struct as_string and serialize. Was getting some intermittent bug reports of failures in t/15_serialize.t that amounted to the keys in a fault struct not being in consistent order.

  • lib/RPC/XML.pm
  • t/15_serialize.t

Undo the previous change and fix the test. The previous change didn't feel right, so this rolls it back and fixes the problem at the level of the test, instead.

  • Makefile.PL
  • lib/RPC/XML.pm
  • lib/RPC/XML/Client.pm
  • lib/RPC/XML/Server.pm

Replace direct evals for loading optional modules with Module::Load. Required adding this to Makefile.PL because Module::Load is not core in 5.8.8. Also did some slight doc tweaking.

  • lib/RPC/XML.pm
  • lib/RPC/XML/Client.pm

Merge pull request #5 from alexrj/utf8-encode. Use utf8::encode() instead of utf8::downgrade().

  • lib/RPC/XML.pm
  • lib/RPC/XML/Client.pm
  • lib/RPC/XML/Server.pm

Finish the uft8 encode vs. downgrade change from the previous commit. Changed in places that were overlooked, and adjusted the version number in all three modules.

  • lib/RPC/XML.pm
  • lib/RPC/XML/Parser/XMLLibXML.pm

Merge pull request #6 from dctabuyz/master. Added 'no_blanks' libxml option to skip blank XML::LibXML::Text nodes.

  • lib/RPC/XML/Server.pm

Merge pull request #7 from kvar/master. Initialize $do_compress in RPC::XML::Server between requests.

  • lib/RPC/XML.pm
  • lib/RPC/XML/Parser/XMLLibXML.pm
  • lib/RPC/XML/Server.pm

Bump version numbers on modules changed in github pulls.

Tags: , , ,

Perl Module Release: RPC-XML 0.77

September 3rd, 2012 | No Comments | Posted in CPAN, Perl, Software, XML
Version: 0.77

Released: Monday September 3, 2012, 12:00:00 PM -0700

Changes:

  • t/15_serialize.t

Fix a test failure on Windows.

  • lib/RPC/XML.pm

RT #70408: Fix spelling error in man page, reported by Debian group.

  • t/90_rt54183_sigpipe.t

Fix to handle cases where server creation fails. Now skips the tests rather than dying.

  • lib/RPC/XML/Client.pm

RT #67486: Add port to Host header in client requests.

  • lib/RPC/XML/Server.pm

RT #65341: Added “use” of forgotten library File::Temp. This was causing failure when “message_file_thresh” kicked in.

  • t/10_data.t

RT #78602: Changed 64-bit test from use64bitint to longsize. On some systems (such as OS X), use64bitint can be true even when in 32-bit mode.

  • t/21_xml_libxml.t

Fix from Christian Walde, skip passed test on Windows.

  • lib/RPC/XML/Server.pm
  • t/40_server.t

Checkpoint refactoring and additional tests. Work is not complete here, but the Net::Server changes demand immediate attention

  • t/20_xml_parser.t

RT #72780: Check for a possible parser failure. One instance of XML::Parser failing to parse the extern entities test. Cannot reproduce, so wrap it in a “skip” block for now.

  • lib/RPC/XML/Procedure.pm
  • t/30_method.t

RT #71452: Correct handling of dateTime parameters. Existing code in lib/RPC/XML/Procedure.pm did not properly handle parameters of the dateTime.iso8601 type. Also, there were no tests for these.

  • MANIFEST
  • t/30_method.t (deleted)
  • t/30_proceudre.t (added)

Renamed t/30_method.t to t/30_procedure.t.

  • lib/RPC/XML/Server.pm

RT #77992: Make RPC::XML::Server work with Net::Server again, after the API changes of Net::Server 2.x.

Tags: , , ,

Perl Module Release: RPC-XML 0.76

August 21st, 2011 | No Comments | Posted in CPAN, Perl, Software
Version: 0.76

Released: Saturday August 20, 2011, 06:30:00 PM -0700

Changes:

  • etc/make_method
  • lib/RPC/XML/Server.pm

RT #70258: Fixed typos in docs pointed out by Debian team.

  • lib/Apache/RPC/Server.pm

Better version of the fix for infinite loops. This is the patch originally suggested by Eric Cholet, who found the bug.

  • t/00_load.t

RT #70280: This test was still testing RPC/XML/Method.pm. Rewrote to remove that but include the (forgotten) XMLLibXML.pm module. That test has to be conditional on the presence of XML::LibXML.

  • Makefile.PL
  • t/51_client_with_host_header.t

Clean up test suite to work with older Test::More. Also specify a minimum Test::More that supports subtest(). This is also a part of RT #70280.

  • t/11_base64_fh.t
  • t/20_xml_parser.t
  • t/21_xml_libxml.t
  • t/40_server.t

These tests had failures when run as root. Permissions-based negative tests were incorrectly passing.

  • t/10_data.t

Moved the 64-bit “TODO” tests to a SKIP block. Non-64-bit systems will skip, rather than fail, these tests.

  • lib/RPC/XML/Server.pm

RT #65616: Fix for slow methods killing servers. Applied and modified patch from person who opened the ticket.

  • MANIFEST
  • lib/RPC/XML.pm
  • t/10_data.t
  • t/14_datetime_iso8601.t (added)

RT #55628: Improve flexibility of date parsing. This adds the ability to pass any ISO 8601 string to the RPC::XML::datetime_iso8601 constructor.

Tags: , , ,

Chasing a Very Elusive Warning

August 16th, 2011 | 7 Comments | Posted in Perl

I am getting a warning in one of my test suites for RPC-XML. I only get this warning when I run “make test“. I do not get the warning if I run the test directly with “perl -Mblib t/…“, or if I run it via prove. The test this occurs in is t/21_xml_libxml.t, which tests the XML::LibXML-based parser, and the warning I get is:

Use of uninitialized value in subroutine entry at .../site_perl/5.14.1/darwin-2level/XML/LibXML.pm line 843.

Because this is occurring within Perl itself, I cannot seem to get it to give me a stack-trace in place of the warning. My attempts to check for undefined values have not found any, yet I get the warning. Running in the debugger does not generate the warning.

Because my tests pass, I have confidence that this parser is fine, despite this only-in-test-harness warning. But the OCD side of me is going crazy over having this still show up when I run my tests locally (and yes, it shows up on all my platforms: Darwin, 64-bit Linux and 32-bit Linux). So, if anyone reading this can give me a helpful hint as to how I can get more/better diagnostic information on this, I would be truly grateful.

Tags: ,

Perl Module Release: RPC-XML 0.75

August 14th, 2011 | No Comments | Posted in CPAN, Perl, Software, XML

MetaCPAN.org: https://metacpan.org/release/RJRAY/RPC-XML-0.75

Version: 0.75

Released: Saturday August 13, 2011, 05:30:00 PM -0700

Changes:

  • MANIFEST

Somehow, t/13_no_deep_recursion.t never got added to MANIFEST.

  • lib/RPC/XML/Parser/XMLLibXML.pm

RT #65154: Fixed a cut/paste error in an error message.

  • lib/RPC/XML/Client.pm
  • t/51_client_with_host_header.t (added)

RT #68792: Merge pull request #2 from dragon3/master (https://github.com/dragon3). Allow setting of “Host” header, and test suite for it.

  • MANIFEST
  • t/51_client_with_host_header.t

Added new test suite to MANIFEST, fixed spelling. Also added “plan tests” line to the test suite.

  • lib/RPC/XML/Parser/XMLLibXML.pm
  • t/20_xml_parser.t
  • t/21_xml_libxml.t
  • t/41_server_hang.t

Merge pull request #3 from yannk/master (https://github.com/yannk). Expat parser subclass is protected against ext ent attack, libxml isn’t.

  • t/41_server_hang.t

Undo a change to this suite from yannk’s pull.

  • etc/make_method
  • lib/Apache/RPC/Server.pm
  • lib/Apache/RPC/Status.pm
  • lib/RPC/XML.pm
  • lib/RPC/XML/Client.pm
  • lib/RPC/XML/Function.pm
  • lib/RPC/XML/Method.pm
  • lib/RPC/XML/Parser.pm
  • lib/RPC/XML/Parser/XMLLibXML.pm
  • lib/RPC/XML/Parser/XMLParser.pm
  • lib/RPC/XML/ParserFactory.pm
  • lib/RPC/XML/Procedure.pm
  • lib/RPC/XML/Server.pm

More perlcritic-driven clean-up. This is mostly POD sections, but also includes heavy re-working of etc/make_method and parts of lib/RPC/XML.pm.

  • lib/RPC/XML/Parser/XMLLibXML.pm
  • t/21_xml_libxml.t

Fixed external entity handling on MacOS. Also made small change to the test suite to be cleaner.

  • lib/RPC/XML/Parser/XMLLibXML.pm
  • lib/RPC/XML/Parser/XMLParser.pm

Took out warnings on external entities blocking. Now it blocks silently. Also cleaned up some docs.

  • t/15_serialize.t

Additions to increase code coverage in XML.pm.

  • lib/RPC/XML.pm

Turns out this wasn’t exporting RPC_I8.

  • lib/Apache/RPC/Server.pm
  • lib/Apache/RPC/Status.pm
  • lib/RPC/XML.pm
  • lib/RPC/XML/Client.pm
  • lib/RPC/XML/Function.pm
  • lib/RPC/XML/Method.pm
  • lib/RPC/XML/Parser.pm
  • lib/RPC/XML/Parser/XMLLibXML.pm
  • lib/RPC/XML/Parser/XMLParser.pm
  • lib/RPC/XML/ParserFactory.pm
  • lib/RPC/XML/Procedure.pm
  • lib/RPC/XML/Server.pm
  • xt/02_pod_coverage.t

Made 5.8.8 the new minimum-required perl. Also dropped the utf8_downgrade hack, which affected an xt test.

  • lib/RPC/XML/Client.pm

Improved arguments-checking in send_request.

  • lib/RPC/XML/Client.pm
  • lib/RPC/XML/Parser/XMLLibXML.pm
  • lib/RPC/XML/Parser/XMLParser.pm
  • lib/RPC/XML/Server.pm

Fixed error-cases in usage of File::Temp->new(). File::Temp::new croaks on errors, doesn’t return undef like I thought.

  • MANIFEST
  • lib/RPC/XML/Function.pm (deleted)
  • lib/RPC/XML/Method.pm (deleted)
  • lib/RPC/XML/Procedure.pm

Roll Method.pm and Function.pm into Procedure.pm. Remove Method.pm and Function.pm from distro.

  • lib/RPC/XML/Parser/XMLLibXML.pm

Fixed regexp for methodName validation.

  • t/10_data.t
  • t/11_base64_fh.t
  • t/12_nil.t
  • t/15_serialize.t
  • t/20_xml_parser.t
  • t/21_xml_libxml.t
  • t/25_parser_negative.t (added)
  • t/29_parserfactory.t
  • t/30_method.t
  • t/40_server.t
  • t/40_server_xmllibxml.t
  • t/50_client.t
  • t/BadParserClass.pm (added)
  • t/meth_good_1.xpl
  • t/namespace3.xpl
  • t/svsm_text.b64 (added)
  • t/util.pl

First round of Devel::Cover-inspired improvements. These are the changes to the test suites to increase coverage of the code.

  • lib/RPC/XML.pm
  • lib/RPC/XML/Procedure.pm
  • lib/RPC/XML/Server.pm

Fixes and such from Devel::Cover analysis.

  • lib/RPC/XML/Procedure.pm
  • lib/RPC/XML/Server.pm
  • t/30_method.t
  • t/meth_good_1.xpl
  • t/meth_good_2.xpl (added)
  • t/meth_good_3.xpl (added)

Fixes for file-based method loading/reloading. New tests in the suite, and re-working of the ugliest hacky part of this package.

  • lib/RPC/XML/Procedure.pm
  • lib/RPC/XML/Server.pm
  • t/30_method.t
  • t/meth_good_3.xpl

RPC::XML::Procedure test-coverage improvement. Also removed some unneeded code.

  • lib/RPC/XML/Procedure.pm
  • lib/RPC/XML/Server.pm
  • t/30_method.t
  • t/40_server.t

Last round of RPC::XML::Procedure test coverage. This is mostly in t/40_server.t, though some bugs were found and addressed in the modules and in t/30_method.t.

  • lib/Apache/RPC/Server.pm
  • lib/Apache/RPC/Status.pm
  • lib/RPC/XML.pm
  • lib/RPC/XML/Client.pm
  • lib/RPC/XML/Parser.pm
  • lib/RPC/XML/Parser/XMLLibXML.pm
  • lib/RPC/XML/Parser/XMLParser.pm
  • lib/RPC/XML/ParserFactory.pm
  • lib/RPC/XML/Procedure.pm
  • lib/RPC/XML/Server.pm

Documentation clean-up and update.

  • lib/Apache/RPC/Server.pm
  • lib/Apache/RPC/Status.pm
  • lib/RPC/XML/Client.pm
  • lib/RPC/XML/Parser/XMLLibXML.pm
  • lib/RPC/XML/Parser/XMLParser.pm
  • lib/RPC/XML/Procedure.pm
  • lib/RPC/XML/Server.pm

Changes from new Perl::Critic::Bangs policies.

  • xt/01_pod.t
  • xt/02_pod_coverage.t
  • xt/03_meta.t
  • xt/04_minimumversion.t
  • xt/05_critic.t

Adjustments to reflect moving from t to xt. Also made changes to xt/02_pod_coverage.t to reflect changes to modules.

  • lib/RPC/XML/Client.pm

Removed some error checks that can never fail.

  • lib/RPC/XML/Server.pm
  • t/40_server.t

Code-coverage-driven changes and added tests.

  • etc/make_method

Fixes from new Perl::Critic::Bangs policies.

  • lib/RPC/XML/Server.pm

Removed usage of AutoLoader completely.

  • lib/RPC/XML/Server.pm
  • t/40_server.t
  • xt/02_pod_coverage.t

Removed some dead code and better did the aliases. This required a change in t/40_server.t for a private sub that no longer exists. Also updated xt/02_pod_coverage.t for private subs that have no pod.

  • lib/Apache/RPC/Server.pm

RT #67694: Fix a potential infinite-loop condition.

Tags: , , ,

Perl Module Release: RPC-XML 0.74

January 23rd, 2011 | No Comments | Posted in CPAN, Perl, Software, XML
Version: 0.74

Released: Sunday January 23, 2011, 12:50:00 PM -0800

Changes:

  • t/90_rt54183_sigpipe.t

RT #56800: Make this suite skip all tests on Windows platforms.

  • lib/Apache/RPC/Server.pm

Clean up some run-time “use of undefined value” messages.

  • lib/RPC/XML/Parser/XMLLibXML.pm
  • lib/RPC/XML/Parser/XMLParser.pm
  • t/90_rt58323_push_parser.t (added)

RT #58323: Started as making the parser interfaces correctly report errors when passed null-length strings or “0″ values. Turned out that the error return interface from XMLLibXML.pm was not consistent with the rest of the system, so fixed that as well.

  • lib/RPC/XML/Server.pm
  • t/40_server.t

RT #58240: Applied a patch from Martijn van de Streek that adds access to the HTTP::Request object to called method code.

  • lib/RPC/XML.pm
  • lib/RPC/XML/Parser/XMLLibXML.pm
  • lib/RPC/XML/Parser/XMLParser.pm
  • t/90_rt58065_allow_nil.t (added)

RT #58065: Allow the parsing of <nil /> tags when they are encountered, even if $RPC::XML::ALLOW_NIL is not set. Only limit the generation of these tags.

  • lib/RPC/XML/Server.pm
  • t/41_server_hang.t

This test sporadically fails, so enhance the error message for more info. Also alter the test slightly, hoping it fixes the random failures.

  • etc/make_method

Applied perlcritic to the make_method tool.

  • lib/XML/RPC.pm
  • t/10_data.t
  • t/20_xml_parser.t
  • t/21_xml_libxml.t

RT #62916: Previous adjustments to the dateTime.iso8601 stringification caused it to no longer fit the XML-RPC spec. Fixed.

  • lib/RPC/XML.pm
  • lib/RPC/XML/Client.pm
  • lib/RPC/XML/Parser/XMLParser.pm
  • lib/RPC/XML/ParserFactory.pm
  • lib/RPC/XML/Server.pm

Used warnings::unused to find unused variables not found by Perl::Critic.

  • t/10_data.t

Realized I had no boundary-tests for ints in smart_encode(). This revealed some problems with i8 values on my 32-bit system. Don’t want to introduce dependency on BigInt right now, so marked those tests “TODO”.

Tags: , , ,