Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jonasbn (1153)

  reversethis-{gro.napc} {ta} {nbsanoj}
AOL IM: BJonasN (Add Buddy, Send Message)

Perl Programmer located in Copenhagen, Denmark. Active member of Copenhagen Perl Mongers.

Author of:

  • Business::DK::CPR
  • Business::DK::CVR
  • Business::DK::PO
  • Business::OnlinePayment::CashCow
  • Date::Holidays
  • Date::Holidays::Abstract
  • Date::Holidays::Super
  • Date::Pregnancy
  • Games::Bingo
  • Games::Bingo::Bot
  • Games::Bingo::Print
  • Module::Info::File
  • Module::Template::Setup
  • Test::Timer

and maintainer of:

  • Tie::Tools
  • XML::Conf
  • Workflow

Journal of jonasbn (1153)

Thursday September 04, 2008
02:23 AM

Workflow 0.32_4 released

[ #37344 ]

I made a rapid release of Workflow (Workflow 0.32_4) - which should address some of our problems, but the number of failing tests are still very high and I see more and more of the same diagnostics.

So I started to dig into the problems.

  • Processing workflow_action.xml: No _parse_* routine defined on this driver (If it is a filter, remember to set the Parent property. If you call the parse() method, make sure to set a Source. You may want to call parse_uri, parse_string or parse_file instead.) [XML::SAX::RTF=HASH(0x8721d18)] at /home/stro/perl510/lib/site_perl/5.10.0/XML/SAX/ line 2616.
  • Cannot read '/home/david/cpantesting/perl-5.10.0/.cpan/build/Workflow-0.32_4-qVqkc9/t/struct /workflow_sqlite.sql': No such file or directory at line 93.
  • A third one was a failure to build XML::Simple, but I cannot consider that a failure on my side, I think this particular problem of test reports on fails not related to the distribution being testing is being discussed quite intensively on the perl-testers-discuss mailing list right now.

Since none of these are emitted from the Workflow code base I did some googling in the first one.

One of the links I found googling was at Perlmonks so I clicked that right away

Here is the explanation, snipped from Perlmonks, it does however originate from a test report:

The problem in this case is a bug in the XML::SAX::RTF installer,
which registers itself in ...lib.../XML/SAX/ParserDetails.ini.
This ini file is used to determine the default SAX parser and
since XML::SAX::RTF was installed most recently, it is the default.
Unfortunately, XML::SAX::RTF is not an XML parser (despite
generating SAX events) so it should be removed from the
ParserDetails.ini file.

I have reported this problem to the module maintainer some time
ago, but I will try again and submit a patch this time.

Thanks for the test.

I wrote Grant to inquire on the status of the problem. Referring to the RT ticket

I installed XML::SAX::RTF and I could reproduce the error.

I wrote Andreas Köenig, whom I had just recently met at YAPC::Europe because he had sent me some test reports indicating failure as well and asked him to send me his: XML/SAX/ParserDetails.ini

His file did however look different from mine, but the reports looked somewhat the same. Since he did not have XML::SAX::RTF installed. So I started to examine XML::SAX and I came to the conclusion that this particular snippet is the problem (from XML::SAX::ParserFactory).

        if (@{$self->{KnownParsers}}) {
                return $self->{KnownParsers}[-1]{Name};
        else {
                return "XML::SAX::PurePerl"; # backup plan!

So as Grant stated earlier, the most recent XML::SAX parser installation is the parser used. It is quite an easy fix, take the XML::SAX::PurePerl (the topmost in the XML/SAX/ParserDetails.ini) so we do not get behavior based on installation behavior.

The problem is then how do we fix this?

I discussed with another Workflow developer on our mailing list about indicating requirements for modules not used directly by Workflow and that solution is not good and since XML::SAX is well encapsulated inside XML::Simple and the parser is well encapsulated within XML::SAX, we cannot really control this, since it is all a matter of configuration.

So what we might have to do is write a test, which attempts to find out what parser is used and then bail (fail) or continue... this will however still result in failing tests indicating that Workflow fails.

Installation of modules is mostly done by people so the XML::SAX configuration is our weakest link, I would prefer to rewrite the above snippet to be:

        if (@{$self->{KnownParsers}}) {
                #defaults to XML::SAX::PurePerl
                return $self->{KnownParsers}[0]{Name};
        else {
                return "XML::SAX::PurePerl"; # backup plan!

So we know we always get XML::SAX::PurePerl unless the user has changed the precedence in his/her XML/SAX/ParserDetails.ini.

This will however break a lot of XML::SAX installations, but the current implementation is stupid and yields unpredictable behavior - and we do not like unpredictable do we?

I have not gotten my head around the XML::SAX feature system, perhaps this could be used to tweak XML::SAX into behaving more predictably, but that will require patches to all parser distributions, XML::Simple and other places beyond my control and I feel like a I am straying from what I intentionally wanted to do, which was releasing Workflow 0.32.

About the other problem, I think this might have to be related to a definition of root directory, but I have not investigated this any further...

This situation calls for a quote from the Coneheads movie trailer (I have never seen the movie)

Coast guard using megaphone addressing refugees on a boat:

We appreciate your situation, but we have problems of our own

I am not sure the quote is correct, but it always pop to mind when situations like this occur.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.