[32682] in Perl-Users-Digest
Perl-Users Digest, Issue: 3955 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 3 14:55:49 2013
Date: Sun, 26 May 2013 11:09:17 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 26 May 2013 Volume: 11 Number: 3955
Today's topics:
cannot compile static-perl.exe with mingw no.spam@for.me_invalid
Re: cannot compile static-perl.exe with mingw <ben@morrow.me.uk>
Re: I'd like to try Perl... <ben@morrow.me.uk>
Re: I'd like to try Perl... <jurgenex@hotmail.com>
Re: I'd like to try Perl... <peterxpercival@hotmail.com>
Re: I'd like to try Perl... <ben@morrow.me.uk>
Re: iCalendar module? <hjp-usenet3@hjp.at>
it hurts when I press here (was: Re: Signals and local <rvtol+usenet@xs4all.nl>
Re: it hurts when I press here <derykus@gmail.com>
Re: it hurts when I press here <rweikusat@mssgmbh.com>
Re: it hurts when I press here <derykus@gmail.com>
Re: it hurts when I press here <rweikusat@mssgmbh.com>
Re: Need more info about problem resolving entity refer <ben@morrow.me.uk>
Re: Signals and local $@ <jurgenex@hotmail.com>
Re: Signals and local $@ <derykus@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 26 May 2013 11:22:34 +0200
From: no.spam@for.me_invalid
Subject: cannot compile static-perl.exe with mingw
Message-Id: <lgk3q8t0kb0cuhuicdc2n3nqjolpckc0qi@4ax.com>
I've downoaded perl source:
http://www.cpan.org/src/5.0/perl-5.18.0.tar.gz
compiler:
http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.0/32-bit/threads-posix/sjlj/
dmake:
http://code.google.com/a/apache-extras.org/p/dmake/downloads/detail?name=dmake-win32-4.12.zip&can=1&q=
all extracted and added to path, it compiles normal executables but
when I change makefile.mk:
BUILD_STATIC *= STATIC_EXT
or
BUILD_STATIC *= ALL_STATIC
it doesn't create static compilation of perl
there all other exes:
\perl-5.18.0\generate_uudmap.exe
\perl-5.18.0\miniperl.exe
\perl-5.18.0\perl.exe
\perl-5.18.0\perlglob.exe
\perl-5.18.0\wperl.exe
but perl-static.exe is nowhere to be found
are there any other options that I must set in makefile ?
------------------------------
Date: Sun, 26 May 2013 17:20:51 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: cannot compile static-perl.exe with mingw
Message-Id: <3cp97a-1n01.ln1@anubis.morrow.me.uk>
Quoth no.spam@for.me_invalid:
> I've downoaded perl source:
> http://www.cpan.org/src/5.0/perl-5.18.0.tar.gz
>
> compiler:
> http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.0/32-bit/threads-posix/sjlj/
>
> dmake:
> http://code.google.com/a/apache-extras.org/p/dmake/downloads/detail?name=dmake-win32-4.12.zip&can=1&q=
>
> all extracted and added to path, it compiles normal executables but
> when I change makefile.mk:
> BUILD_STATIC *= STATIC_EXT
> or
> BUILD_STATIC *= ALL_STATIC
Did you read the instructions? You need
BUILD_STATIC *= define
ALL_STATIC *= define
or
BUILD_STATIC *= define
STATIC_EXT *= <list of extensions to link statically>
Out of interest, why do you think you need a statically-linked perl?
It's likely a lot less use than you think; for one thing, Dynaloader
doesn't work, for another, neither does Encode.
Ben
------------------------------
Date: Fri, 24 May 2013 19:34:06 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: I'd like to try Perl...
Message-Id: <udo47a-mmq2.ln1@anubis.morrow.me.uk>
Quoth Peter Percival <peterxpercival@hotmail.com>:
> Peter Percival wrote:
> > I'd like to try Perl on Win 7 and according to this:
> > http://www.perl.org/get.html, it's a choice between ActiveState,
> > Strawberry and DWIM. Any advice on choosing between them would be welcome.
>
> I have "Learning Perl on Win32 Systems" by Schwartz, Olson and
> Christiansen. It's the right level for me, but I need something for
> Windows 7 specifically, and suggestions?
What is special about Win 7 that makes you think you need a different
book? Concentrate on learning the basics first; then, later, if you need
to, you can find out how to do system-specific stuff on your system.
Ben
------------------------------
Date: Fri, 24 May 2013 12:11:04 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: I'd like to try Perl...
Message-Id: <skevp853vgtpgcja55c3jndcjobivm584a@4ax.com>
Peter Percival <peterxpercival@hotmail.com> wrote:
>Peter Percival wrote:
>> I'd like to try Perl on Win 7 and according to this:
>> http://www.perl.org/get.html, it's a choice between ActiveState,
>> Strawberry and DWIM. Any advice on choosing between them would be welcome.
>
>I have "Learning Perl on Win32 Systems" by Schwartz, Olson and
>Christiansen. It's the right level for me, but I need something for
>Windows 7 specifically,
Luckily Perl is blissfully independant and ignorant of any OS version.
Therefore unless you are doing some very specialized coding for a
specific OS-version there is no need for any OS-version specific
learning.
jue
------------------------------
Date: Fri, 24 May 2013 20:16:42 +0100
From: Peter Percival <peterxpercival@hotmail.com>
Subject: Re: I'd like to try Perl...
Message-Id: <knoeas$p42$1@news.albasani.net>
Jürgen Exner wrote:
> Peter Percival <peterxpercival@hotmail.com> wrote:
>> Peter Percival wrote:
>>> I'd like to try Perl on Win 7 and according to this:
>>> http://www.perl.org/get.html, it's a choice between ActiveState,
>>> Strawberry and DWIM. Any advice on choosing between them would be welcome.
>>
>> I have "Learning Perl on Win32 Systems" by Schwartz, Olson and
>> Christiansen. It's the right level for me, but I need something for
>> Windows 7 specifically,
>
> Luckily Perl is blissfully independant and ignorant of any OS version.
> Therefore unless you are doing some very specialized coding for a
> specific OS-version there is no need for any OS-version specific
> learning.
Strawberry 5.16 seems not to understand
use Win32::NetAdmin;
I guess that's because Win 7 doesn't have a Win32, but I may have
misunderstood.
--
I think I am an Elephant,
Behind another Elephant
Behind /another/ Elephant who isn't really there....
A.A. Milne
------------------------------
Date: Fri, 24 May 2013 22:06:06 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: I'd like to try Perl...
Message-Id: <ua157a-55s2.ln1@anubis.morrow.me.uk>
Quoth Peter Percival <peterxpercival@hotmail.com>:
> Jürgen Exner wrote:
> > Peter Percival <peterxpercival@hotmail.com> wrote:
> >> Peter Percival wrote:
> >>> I'd like to try Perl on Win 7 and according to this:
> >>> http://www.perl.org/get.html, it's a choice between ActiveState,
> >>> Strawberry and DWIM. Any advice on choosing between them would be welcome.
> >>
> >> I have "Learning Perl on Win32 Systems" by Schwartz, Olson and
> >> Christiansen. It's the right level for me, but I need something for
> >> Windows 7 specifically,
> >
> > Luckily Perl is blissfully independant and ignorant of any OS version.
> > Therefore unless you are doing some very specialized coding for a
> > specific OS-version there is no need for any OS-version specific
> > learning.
>
> Strawberry 5.16 seems not to understand
>
> use Win32::NetAdmin;
>
> I guess that's because Win 7 doesn't have a Win32, but I may have
> misunderstood.
Almost certainly. What error did you get? Have you got Win32::NetAdmin
installed?
Ben
------------------------------
Date: Fri, 24 May 2013 23:06:19 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: iCalendar module?
Message-Id: <slrnkpvlie.id7.hjp-usenet3@hrunkner.hjp.at>
On 2013-05-23 19:50, hymie! <hymie@lactose.homelinux.net> wrote:
> I found this ruby script
> cals = Icalendar.parse($<)
> cals.each do |cal|
> cal.events.each do |event|
> puts "Organizer: #{event.organizer}"
> puts "Event: #{event.summary}"
> puts "Starts: #{event.dtstart.myformat} local time"
[...]
>
> and I was hoping to write something similar in perl.
>
> The question is, can somebody recommend to me a module that I can use
> to read iCal files? All of the modules that I see appear to handle
> creating iCal files, but not reading them and outputting something
> human-readable. Although it's likely that I missed it.
I have used Text::vFile::asData to convert iCal MIME parts to something
I can read. It handles all the v-type formats (vCalendar, vCard, ...),
but that flexibility makes it a bit cumbersome to use. Here's a snippet
from my script (whole script available on request if anyone wants it):
...
my $data = Text::vFile::asData->new->parse(\*STDIN);
my $vcalendar = $data->{objects}[0];
die "unexpected type $vcalendar->{type}" unless $vcalendar->{type} eq 'VCALENDAR';
my $vevent;
for (@{ $vcalendar->{objects} }) {
if ($_->{type} eq 'VEVENT') {
$vevent = $_;
last; # there can be only one (or so we hope)
}
}
die "no VEVENT found" unless $vevent;
print "Summary : $vevent->{properties}{SUMMARY}[0]{value}\n";
print "\n";
print "Begin : ", fmttime($vevent->{properties}{DTSTART}[0]{value}), "\n";
print "End : ", fmttime($vevent->{properties}{DTEND}[0]{value}), "\n";
print "\n";
...
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sat, 25 May 2013 14:59:40 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: it hurts when I press here (was: Re: Signals and local $@)
Message-Id: <51a0b5bc$0$15939$e4fe514c@news2.news.xs4all.nl>
On 25/05/2013 07:05, Charles DeRykus wrote:
> On 5/24/2013 4:05 AM, Adrien BARREAU wrote:
>> #!/usr/bin/perl
>>
>> use strict;
>> use warnings;
>>
>> sub sleep10
>> {
>> local $@;
>> sleep 10;
>> }
>>
>> {
>> eval {
>> local $SIG{'ALRM'} = sub { die "Here comes the death\n"; };
>> alarm 2;
>> sleep10();
> alarm(0); # <--- to here
>> };
>>
>> # alarm 0; #----- move inside eval {};
>
>
> Just an aside but, if you're not using Try::Tiny, you should move the
> alarm inside the eval{} to remove another small race condition.
It must be in both places, if you assume that sleep10 can die for
multiple reasons.
And the return-value of the eval{} must be checked, after forcing it to
1 for success. Etc.
--
Ruud
------------------------------
Date: Sat, 25 May 2013 09:47:02 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: it hurts when I press here
Message-Id: <knqpus$h4e$1@speranza.aioe.org>
On 5/25/2013 5:59 AM, Dr.Ruud wrote:
> On 25/05/2013 07:05, Charles DeRykus wrote:
>> On 5/24/2013 4:05 AM, Adrien BARREAU wrote:
>
>>> #!/usr/bin/perl
>>>
>>> use strict;
>>> use warnings;
>>>
>>> sub sleep10
>>> {
>>> local $@;
>>> sleep 10;
>>> }
>>>
>>> {
>>> eval {
>>> local $SIG{'ALRM'} = sub { die "Here comes the death\n"; };
>>> alarm 2;
>>> sleep10();
>> alarm(0); # <--- to here
>>> };
>>>
>>> # alarm 0; #----- move inside eval {};
>>
>>
>> Just an aside but, if you're not using Try::Tiny, you should move the
>> alarm inside the eval{} to remove another small race condition.
>
> It must be in both places, if you assume that sleep10 can die for
> multiple reasons.
Yes, mea culpa. Of course sleep10 as shown didn't 'die' and wasn't
re-throwing the exception... which threw me :)
> And the return-value of the eval{} must be checked, after forcing it to
> 1 for success. Etc.
>
And, even with that, it should be mentioned Try::Tiny is a better solution.
--
Charles DeRykus
------------------------------
Date: Sat, 25 May 2013 20:44:36 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: it hurts when I press here
Message-Id: <87hahq7skb.fsf@sapphire.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 5/25/2013 5:59 AM, Dr.Ruud wrote:
[...]
>> And the return-value of the eval{} must be checked, after forcing it to
>> 1 for success. Etc.
>
> And, even with that, it should be mentioned Try::Tiny is a better
> solution.
In the sense that it has three times as much 'voodoo coding' but
(hark!) nobody needs to look at the mess. Apart from that, these
opinion statements regarding 'proper error handling' would be more
convincing if they were expressed as opinion statements and came with
a reason eg "I'm generally of the opinion that exceptions shouldn't be
used for error handling because ...".
I'm using eval and die extensively, both for aborting some sequence of
processing steps from nested subroutines and for actual exception
handling and this works very nicely. Some remarks about Try::Tiny:
,----
| finally (&;$)
|
| [...]
|
| This allows you to locate cleanup code which cannot be
| done via local() e.g. closing a file handle.
`----
This would be more aptly described as 'This construct is necessary to
work around deficiencies of a sixty year old concept for "automatic
memory management" which is limited to manageing memory while all
other resources which need to be allocated and freed have to be
managed with explicitly written code. That's not a problem for Perl 5
which uses a more modern approach for automatic resource management
with support for stack unwinding, deterministic finalization and
automatic management of file handles *BUT* it will become a problem
with Perl 6, should that ever evolve beyond being an abandoned Haskell
demo."
,----
| There are a number of issues with eval.
`----
,----
| Clobbering $@
|
| When you run an eval block and it succeeds, $@ will be cleared,
| potentially clobbering an error that is currently being caught.
`----
That's an inherent limitation of the idea to use 'a global variable'
as 'the exception location' and part of the documented functionlity of
eval. The solution is that someone who wants to use $@ for exception
handling has to save the value in some other location before starting
any more complicated unrelated computation.
,----
| Localizing $@ silently masks errors
|
| Inside an eval block, die behaves sort of like:
|
| sub die {
| $@ = $_[0];
| return_undef_from_eval();
| }
|
| This means that if you were polite and localized $@ you can't die in
| that scope, or your error will be discarded (printing "Something's
| wrong" instead).
`----
'Localizing $@# does not 'silently mask errors', it localizes $@, that
is, it creates a lexically scoped binding for a global
variable. Because of this, changes to $@ while this binding is in
scope will not affect 'the outside world' anyhow. Since $@ is used for
exception propagation, this means that code which localizes $@ without
dealing with this possibility 'might silently mask an error' aka 'is
broken'.
,----
| $@ might not be a true value
|
| This code is wrong:
|
| if ( $@ ) {
| ...
| }
|
| because due to the previous caveats it
| may have been unset.
`----
This example is incomplete: The code supposed to set $@ is
missing. Also, there were no general 'previous caveats': The first
situation roughly amounts to the following:
eval {
...;
...;
}
eval {
...;
...;
}
if ($@) {
}
plus the expectation that the value of $@ would reflect something
which happened during the first eval which it doesn't: This is a
coding error and needs to be avoided. Localizing $@ without dealing
with its 'special magic' is also a coding error.
,----
| The classic failure mode is:
|
| [...]
|
| In this case since Object::DESTROY is not localizing $@ but still uses
| eval, it will set $@ to "".
`----
That's the sole valid concern so far: Object destructors are executed
automatically during stack unwinding. Because of this, it is prudent
to write them such that they don't modify any kind of 'state
information' visible to unrelated parts of the program. That's the
downside of any 'convenience mechanism' which might lead to the
execution of subroutines in places where this isn't obvious when
looking at the code causing these invocation. 'Operator overloading'
suffers from the same problem. Not related to eval/ $@ in any
particular way.
NB: This text is an opinion statement itself and there might well be
valid counterarguments for anything contained in it.
------------------------------
Date: Sat, 25 May 2013 16:18:40 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: it hurts when I press here
Message-Id: <knrgta$fd9$1@speranza.aioe.org>
On 5/25/2013 12:44 PM, Rainer Weikusat wrote:
> Charles DeRykus <derykus@gmail.com> writes:
>> On 5/25/2013 5:59 AM, Dr.Ruud wrote:
>
> [...]
>
>>> And the return-value of the eval{} must be checked, after forcing it to
>>> 1 for success. Etc.
>>
>> And, even with that, it should be mentioned Try::Tiny is a better
>> solution.
>
> In the sense that it has three times as much 'voodoo coding' but
> (hark!) nobody needs to look at the mess. Apart from that, these
> opinion statements regarding 'proper error handling' would be more
> convincing if they were expressed as opinion statements and came with
> a reason eg "I'm generally of the opinion that exceptions shouldn't be
> used for error handling because ...".
>
> I'm using eval and die extensively, both for aborting some sequence of
> processing steps from nested subroutines and for actual exception
> handling and this works very nicely.
Good objection. Admittedly, I was mostly parroting the consensus about
Try::Tiny. Still IMO most are better off with T::T than rolling an eval
eval block. It's easy to forget the subtleties of Perl's exception
handling... or remain blissfully unaware of them in the first place. For
the latter reason, I can't comment in any depth.
But, if 'sleep10' had been using T::T -- instead of mangling $@ as it
apparently did and which is easy to do -- the code would have arguably
been cleaner and chances of mayhem reduced. Even visually, I'd prefer:
try{} catch {} rather than: local $@; eval{...;1};
That's not a big edge but with eval, you have also to remember to
localize $@ and to ensure the block returns true. Plus there can be
concerns as you cite of a DESTROY block which zaps $@. IIUC, T:T handles
these problems for you
Both approaches involve discipline of course. Even with T::T, a global
$_ is in play if errors occur. But, at least there's not the potential
of collateral damage to the exception model itself because of $@
vulnerability.
--
Charles DeRykus
------------------------------
Date: Sun, 26 May 2013 18:19:36 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: it hurts when I press here
Message-Id: <87bo7xk6af.fsf@sapphire.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 5/25/2013 12:44 PM, Rainer Weikusat wrote:
>> Charles DeRykus <derykus@gmail.com> writes:
>>> On 5/25/2013 5:59 AM, Dr.Ruud wrote:
>>
>> [...]
>>
>>>> And the return-value of the eval{} must be checked, after forcing it to
>>>> 1 for success. Etc.
>>>
>>> And, even with that, it should be mentioned Try::Tiny is a better
>>> solution.
>>
>> In the sense that it has three times as much 'voodoo coding' but
>> (hark!) nobody needs to look at the mess. Apart from that, these
>> opinion statements regarding 'proper error handling' would be more
>> convincing if they were expressed as opinion statements and came with
>> a reason eg "I'm generally of the opinion that exceptions shouldn't be
>> used for error handling because ...".
>>
>> I'm using eval and die extensively, both for aborting some sequence of
>> processing steps from nested subroutines and for actual exception
>> handling and this works very nicely.
>
> Good objection. Admittedly, I was mostly parroting the consensus about
> Try::Tiny.
Consensus of whom? Obviously, all people who use Try::Tiny do so
because they're convinced that it is useful for them. But this doesn't
necessarily mean that it actually is. As someone wrote in a complete
different context: Science is not a democracy because 'truth' is not
'what most people believe in'.
> Still IMO most are better off with T::T than rolling an
> eval eval block. It's easy to forget the subtleties of Perl's
> exception handling... or remain blissfully unaware of them in the
> first place.
The Try::Tiny documentation list three 'concerns' about 'Perl exception
handling' (I consider two of them invalid for reasons stated
elsewhere) but it contains no less than seven 'caveats' supposed to
apply to using it (and some of the open bugs -- apparently, bugs in
Try::Tiny are usually neither fixed nor closed -- are about people who
still didn't understand how to use it). Memoizing more than two times
as much 'subtleties' about using Try::Tiny in order to avoid learning
about 'the subtleties of Perl exception handling' doesn't seem like a
sensible tradeoff to me.
Not to mention that most details of the Try::Tiny code are quoted (in
simplified form) in the documentation and the author himself
consistently refers to them as 'ugly hacks' (I agree with this
assessment :->).
> But, if 'sleep10' had been using T::T -- instead of mangling $@ as it
> apparently did and which is easy to do -- the code would have arguably
> been cleaner and chances of mayhem reduced. Even visually, I'd prefer:
> try{} catch {} rather than: local $@; eval{...;1};
And I prefer to use a facility for dealing with 'exceptional events'
(which change the 'normally linear' control flow of something) for
doing actual 'exception throwing and handling'. Otherwise, I'd use
some 'special return value' error signalling convention without the
overhead of the former. Mixing both in this way in order to work
around hypothetical bugs in other code (instead of fixing these) is IMHO
just totally bizarre: The point of having 'exceptions' in the first
place is that return values can be used for returning 'useful
information' and exceptions for 'exceptional events'.
I also don't quite understand why one would localize $@ and want to
propagate errors out of the scope of the local at the same time. The
easy way to accomplish that would be not localizing $@ to begin with.
------------------------------
Date: Fri, 24 May 2013 21:57:07 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Need more info about problem resolving entity reference
Message-Id: <3q057a-55s2.ln1@anubis.morrow.me.uk>
[Please don't double-space quotes. I know it's something Google Groups
does without being asked to; I also know it can be avoided, because
other people manage to avoid it.]
Quoth David Karr <davidmichaelkarr@gmail.com>:
> On Thursday, May 23, 2013 7:34:04 PM UTC-7, Ben Morrow wrote:
> > Quoth David Karr <davidmichaelkarr@gmail.com>:
> >
> > > I have a Cygwin Perl script makes numerous REST api calls to a local
> > > service, parses the results from those, and makes other calls with that
> > > data. It also runs some of these calls in multiple threads, using
> > > LWP::UserAgent.
> > >
> > > It mostly works, but I sometimes get errors like this:
> > >
> > > -----------------------
> > > caught error:
> > > 500 Can't connect to www.w3.org:80 (Operation now in progress)
> > > http://www.w3.org/TR/html4/strict.dtd
> > > Handler couldn't resolve external entity at line 1, column 90, byte 92
> > > error in processing external entity reference at line 1, column 90, byte 92:
> > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> > > "http://www.w3.org/TR/html4/strict.dtd">
> > > ======================================================================
> > > ===================^
> > > <html>
> > > <head>
> > > at
> > > /usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int/XML/Parser.pm
> > > line 187 thread 2
> > > ----------------------
> > >
> > > That's the entire error message. I have no idea where in the script
> > > this gets called from, and I'm not really sure what this error is
> > > telling me.
> >
> > This error comes from XML::Parser. I assume you are invoking that
> > directly, to parse the REST response? What's happening is that
> > XML::Parser sees a DOCTYPE declaration like
> >
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> > "http://www.w3.org/TR/html4/strict.dtd">
> >
> > and, like a good little SGML-derived XML parser, tries to fetch the DTD
> > (using LWP) so it can validate the rest of the file. For some reason,
> > when it tries to connect to www.w3.org to download the DTD file, the
> > connection is failing with EINPROGRESS. Since LWP isn't expecting that
> > error code, it throws an error.
> >
> > So, what's the real problem? Well, first, that's an HTML doctype. You
> > can't, in general, parse HTML with an XML parser, so are you sure you're
> > getting the responses you expect? REST services are usually pretty good
> > about getting their Content-types right, so you ought to be able to
> > check for an XML Content-type before passing the data to XML::Parser.
>
> I'm completely certain that in these anomalous cases, I'm definitely not
> getting the response I expect. The problem with this error message is
> that it gives me absolutely no clue where in the script this is
> happening. I'm guessing that our back-end server gets confused in some
> cases, but it's hard to diagnose when I don't know what URL was being
> attempted, or where in the script it was done.
I agree it's not the best error message in the world; however, it does
mention XML::Parser, which should give you some idea of where it's
actually coming from. A useful trick in situations like this is to put
use Carp;
$SIG{__WARN__} = \&Carp::cluck;
$SIG{__DIE__} = \&Carp::confess;
at the top of the program: this usually means you will get a full
backtrace.
> > Second, you really don't want to keep fetching the DTDs like that. Does
> > the XML you're actually trying to parse use external DTDs? If not, then
> > you want to pass the NoLWP option to XML::Parser, so that it doesn't
> > even try to fetch DTDs from the network. In the case of a public DTD
> > like HTML the attempt to load it as a local file will fail, of course,
> > but the parsing wasn't going to succeed anyway, because it wasn't XML.
>
> That "NoLWP" option sounds useful, but it's somewhat moot here.
>
> > However, I'm slightly confused here, because the XML::Parser
> > documentation seems to say it doesn't parse external DTDs by default.
> > It's possible I'm misunderstanding; I don't think I've used XML::Parser
> > myself. Are you passing ParseParamEnt, and if so, why?
>
> I don't know what "ParseParamEnt" is, so I imagine I'm not.
OK, well, I'm not entirely sure whether things are working as they are
supposed to or not. Someone more familiar with XML::Parser would have to
chime in here...
> > Third, you probably don't want to be using XML::Parser at all. As you
> > can see, it's old and rather cronky, and while it's extremely solid code
> > it also takes a rather SGMLish approach to parsing XML. Most of the
> > time, with modern XML use, DTDs are not used, and instead the XML just
> > needs to be well-formed and properly namespaced. For this sort of thing
> > (small documents) I would use XML::LibXML (which, incidentally, also
> > includes a reasonable HTML parser); if a streaming model is more
> > appropriate, either because your documents may be ridiculously large or
> > simply because your program is structured that way, I would use one of
> > the SAX modules.
>
> The funny thing about searching in CPAN is that there are no packages
> (I'm guessing) that say "do not use this, use something better". I'll
> take a look at XML::LibXML to see what it does for me.
There are more modules like that than you might think; but you are
right, selecting an appropriate module from among the many available can
be tricky. Asking here or on Perlmonks or Stack Overflow can be one
solution, though of course any such recommendations have to be taken
with a generous pinch of salt. (For instance, a Google search quickly
gave me <http://stackoverflow.com/questions/487213/whats-the-best-
xml-parser-for-perl>; note that none of the answers mention
XML::Parser.)
The only real answer is to have a solid understanding of the problem
domain, and to carefully read the documentation of the modules concerned
to see whether they behave the way you would expect. For instance, in
this case a careful reading of the XML::Parser documentation reveals
that it cares a lot about DTDs, which indicates (at least to someone who
knows about the history of the development of XML) that this is rather
old code which may not be suitable for a modern situation.
> > Finally, fourth, I have no idea where that EINPROGRESS is coming from.
> > That error is supposed to be returned if a socket is connected while in
> > non-blocking mode, and the connection cannot be completed without
> > blocking; it's basically the equivalent of EAGAIN for connect(). This
> > means it shouldn't be possible to get that error without having asked
> > for it by setting nonblocking mode on the socket, which LWP does not
> > (normally) do.
> >
> > Are you doing something peculiar which might cause this to happen?
> > Alternatively, it's possible this is some sort of Cygwin peculiarity,
> > which unfortunately may be difficult to track down; if you can isolate
> > the conditions where the error occurs it would be useful. (For instance,
> > does it tend to occur when the network goes down? When the network is
> > overloaded? When the DNS doesn't respond promptly?)
>
> The script runs for perhaps 30-40 minutes, basically walking the entire
> data model of a REST api. It sends hundreds of requests to the
> (load-balanced) service, some from multiple threads. This kind of error
> happens several times during the run of the script, which means that the
> vast majority work well enough. I ended up putting a hack into my
> "sendGet" sub that just checks for "DOCTYPE HTML" in the output and
> simply tries again, with a reasonable limit of retries. Almost all of
> the calls that detect this once or twice eventually get good data.
So you do know where the error is coming from. Good. As I said before,
it would probably be better to check the Content-type on the response
than to rely on heuristics like that.
As for working out what is actually going wrong, I assume you've tried
printing out the HTML? I would have expected this would give you some
idea of where it's coming from, and perhaps why. Since you can now
detect the incorrect responses, that means you can also log the URLs
they were responding to, which gives you a place to start.
Ben
------------------------------
Date: Fri, 24 May 2013 11:30:07 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Signals and local $@
Message-Id: <e9cvp8pjsknqe30jai2tfjdtq9gbtc9cb3@4ax.com>
Adrien BARREAU <adrien.barreau@live.fr> wrote:
>On 05/24/2013 06:54 PM, Ben Morrow wrote:
>> Quoth Adrien BARREAU<adrien.barreau@live.fr>:
>>> Of course, but this is meant to run on some computer where adding new
>>> CPAN files is not an option.
>>> That's not my choice and I can't help it.
>>
>> So copy the code out of Try/Tiny.pm into your own script.
>>
>Once again, I agree about that idea, but I'm not allowed to do that either.
Then take 4 days off at full pay, come back, and claim that during those
4 days you developed that piece of code. Problem solved.
jue
------------------------------
Date: Fri, 24 May 2013 22:05:15 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Signals and local $@
Message-Id: <knpgr4$2f8$1@speranza.aioe.org>
On 5/24/2013 4:05 AM, Adrien BARREAU wrote:
> Hello all.
>
>
> I'm trying to write a little wrapper which properly handles a call with
> a timeout.
>
> Since I'm on a 5.10.1, I take care of all eval{} pitfalls I know (more
> or less take some parts of Try::Tiny ideas just to do a proper eval).
>
> Here is the thing I don't know how to deal with.
>
> # ---
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> sub sleep10
> {
> local $@;
> sleep 10;
> }
>
> {
> eval {
> local $SIG{'ALRM'} = sub { die "Here comes the death\n"; };
> alarm 2;
> sleep10();
alarm(0); # <--- to here
> };
>
> # alarm 0; #----- move inside eval {};
Just an aside but, if you're not using Try::Tiny, you should move the
alarm inside the eval{} to remove another small race condition.
--
Charles DeRykus
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3955
***************************************
