[26827] in Perl-Users-Digest
Perl-Users Digest, Issue: 8857 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jan 16 18:05:31 2006
Date: Mon, 16 Jan 2006 15:05:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 16 Jan 2006 Volume: 10 Number: 8857
Today's topics:
Re: create a hierarchical list from a text file <ebohlman@omsdev.com>
Re: ExpatXS: 'Can't call method "read" on an undefined <matthew.garrish@sympatico.ca>
Re: ExpatXS: 'Can't call method "read" on an undefined <nomail@sorry.com>
Re: ExpatXS: 'Can't call method "read" on an undefined <nomail@sorry.com>
Re: Netiquette aspect <noreply@gunnar.cc>
Re: Netiquette aspect <matthew.garrish@sympatico.ca>
Re: Netiquette aspect <flavell@ph.gla.ac.uk>
Re: while ( ) and until ( ) <j.mapson.nurick@dial.pipex.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 16 Jan 2006 15:08:15 GMT
From: Eric Bohlman <ebohlman@omsdev.com>
Subject: Re: create a hierarchical list from a text file
Message-Id: <Xns974D5CDB6278Bebohlmanomsdevcom@130.133.1.4>
Tad McClellan <tadmc@augustmail.com> wrote in
news:slrndsn7cp.hlf.tadmc@magna.augustmail.com:
> my $level = length($1) if $line =~ s/(\t*)//;
>
>
> But you don't even need regular expressions at all:
>
> my $level = $line =~ tr/\t//d;
In this case it would be better to use a regex since the OP should have
anchored it to the beginning of the line so that only leading tabs signify
level. Without the anchor, the data can't contain embedded tabs without
throwing the level calculations off, and IMHO it's best not to create such
"unwritten law" constraints.
my $level = length($1) if $line =~ s/^(\t*)//;
------------------------------
Date: Mon, 16 Jan 2006 15:01:32 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: ExpatXS: 'Can't call method "read" on an undefined value' after ca. 500 XML files
Message-Id: <tYSyf.1399$924.71383@news20.bellglobal.com>
"Arvin Portlock" <nomail@sorry.com> wrote in message
news:dqehgs$auv$1@agate.berkeley.edu...
> Matt Garrish wrote:
>
>> wrote in message
>> news:20060115160930.889$50@newsreader.com...
>>
>> >"Matt Garrish" wrote:
>> >
>> >>"Arvin Portlock" wrote in message
>> >>news:dq9gb7$219p$1@agate.berkeley.edu...
>> >>
>> >>>In using ExpatXS to parse large batches of XML files
>> >>>something curious happens. After parsing something close
>> >>>to 500 files the program crashes with the error:
>> >>>
>> >>>Can't call method "read" on an undefined value at
>> >>>/xxx/perl5.8/lib/site_perl/5.8.7/sun4-solaris-thread-multi/
>> >>>XML/SAX/ExpatXS.pm line 155.
>> >>>
>> >>
>> >>You aren't checking whether you succesfully get an object. I would
>> >>doubt
>> >>it's a memory leak or your system would have ground to a halt.
>> >
>> >But it could easily be a file-handle leak. Around 500 would be a common
>> >per-process limit on open file-handles.
>> >
>>
>>
>> That seems more likely. I just wonder what the read method is that is
>> being
>> called on what undefined object. It's not a particularly helpful error
>> message. It could be coming right from Expat from the sound of it.
>>
>> Matt
>
> The line in question in ExpatXS is this:
>
> $result = $args->{ParseFunc}->($args->{Parser},
> $args->{ParseFuncParam});
>
Sorry, for some reason I thought your script was reporting the error at line
175 (the .pm never seemed to register until just now). That's why I was
wondering what line 175 was. The evals were for nothing, I guess... : )
Matt
------------------------------
Date: Mon, 16 Jan 2006 11:47:29 -0800
From: Arvin Portlock <nomail@sorry.com>
Subject: Re: ExpatXS: 'Can't call method "read" on an undefined value' after ca. 500 XML files
Message-Id: <dqgt8h$vkd$1@agate.berkeley.edu>
xhoster@gmail.com wrote:
> Arvin Portlock wrote:
>
> ># $Id: ExpatXS.pm,v 1.39 2005/11/10 09:38:31 cvspetr Exp $
>
> I've now tried your program with this exact version of ExpatXS.pm, and
> it also works for at least 10_000 files.
And I just tried it on Windows and it works fine, though not
quite the same version of perl and an old version of ExpatXS.
I'm not a system administrator so I had to compile and install
my own local copy of perl and miscellaneous modules, something
I do infrequently. Perhaps I did something wrong there. At
least it isn't a bug in my program, and it seems not to be a
bug in ExpatXS. It seems doubtful it would be a solaris-specific
bug of any kind.
So I could try creating a single-file version of the program
and call it through a loop in a shell script. It's a bit less
convenient to maintain state. I wonder what kind of hit I'll
take doing that? Or I could use pure perl. Except the reason I'm
doing this is the Java DOM solution in place is way too slow
so I was hoping for a more impressive boost in speed. I might
try and bite the bullet and struggle through installing Xerces
which is pretty fast, and, come to think of it, would be useful
in other applications. Maybe I'll try and hack a destructor for
the parse object.
Anyway, I'm just thinking out loud now. Thank you very much
for all of your help. Though the problem remains, it still
helped me out very much.
Arvin
>
>
>
> >This is perl, v5.8.7 built for sun4-solaris-thread-multi
>
>
> This is perl, v5.8.7 built for x86_64-linux
> This is perl, v5.8.3 built for x86_64-linux-thread-multi
> This is perl, v5.8.0 built for i386-linux-thread-multi
>
> (I would have replied to myself, but my first post hasn't showed up for
> me yet. I hope it does eventually.)
>
> Xho
>
------------------------------
Date: Mon, 16 Jan 2006 12:33:52 -0800
From: Arvin Portlock <nomail@sorry.com>
Subject: Re: ExpatXS: 'Can't call method "read" on an undefined value' after ca. 500 XML files
Message-Id: <dqgvvg$10ek$1@agate.berkeley.edu>
>>>In using ExpatXS to parse large batches of XML files
>>>something curious happens. After parsing something close
>>>to 500 files the program crashes with the error:
>>>
>>>Can't call method "read" on an undefined value at
>>>/xxx/perl5.8/lib/site_perl/5.8.7/sun4-solaris-thread-multi/
>>>XML/SAX/ExpatXS.pm line 155.
>xhoster@gmail.com wrote:
>I've now tried your program with this exact version of ExpatXS.pm, and
>it also works for at least 10_000 files.
So I made one change to ExpatXS.pm which worked. I explicitly
closed $fh here:
sub _parse_systemid {
my $self = shift;
my $fh = IO::File->new(shift);
$self->{ParseOptions}->{ParseFunc} = \&ParseStream;
$self->{ParseOptions}->{ParseFuncParam} = $fh;
$self->_parse;
$fh->close;
}
I'm a little nervous this solution may be simplistic since
individual XML documents can span multiple files, though
none in this particular batch do. I should test that on
some other files I have. A Google search for:
IO::File perl bug file close solaris
Brings up some interesting things. Problems closing files
are noticeable on Solaris because its descriptor limit
is typically quite low. Quoting:
You can reproduce the problem on other systems, too.
Just set the file descriptor limit to a low value (e.g.
by using limits -n). Other systems like Linux and
FreeBSD have much higher default limits than Solaris.
But I don't know, 10,000 files seems like a pretty large
limit for any system.
Best regards,
Arvin
------------------------------
Date: Mon, 16 Jan 2006 16:51:05 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Netiquette aspect
Message-Id: <431tjdF1ih79eU1@individual.net>
Matt Garrish wrote:
> Gunnar Hjalmarsson wrote:
>>The netiquette bids us to read the whole thread before posting a reply,
>>obviously to avoid that the same thing is said repeatedly.[1] That aspect
>>of the netiquette could be better adhered to, giving us a less noisy and
>>more to the point clpmisc.
>
> What was this born of?
It happens quite often IMO.
> You may get four or five identical answers to a
> question because four or five people started typing them up at the same
> time,
Yeah, that's not what I'm talking about.
> but I can't say that I see all that many multi-branch threads where
> the exact same advice is being repeated over and over in each branch.
Well, sometimes it's repeated in the same branch. ;-)
Maybe I'll point it out next time I notice.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 16 Jan 2006 11:39:34 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: Netiquette aspect
Message-Id: <7%Pyf.8950$xk1.150661@news20.bellglobal.com>
"Gunnar Hjalmarsson" <noreply@gunnar.cc> wrote in message
news:431tjdF1ih79eU1@individual.net...
> Matt Garrish wrote:
>> Gunnar Hjalmarsson wrote:
>>>The netiquette bids us to read the whole thread before posting a reply,
>>>obviously to avoid that the same thing is said repeatedly.[1] That aspect
>>>of the netiquette could be better adhered to, giving us a less noisy and
>>>more to the point clpmisc.
>>
>> What was this born of?
>
> It happens quite often IMO.
>
>> You may get four or five identical answers to a question because four or
>> five people started typing them up at the same time,
>
> Yeah, that's not what I'm talking about.
>
>> but I can't say that I see all that many multi-branch threads where the
>> exact same advice is being repeated over and over in each branch.
>
> Well, sometimes it's repeated in the same branch. ;-)
>
> Maybe I'll point it out next time I notice.
>
That would probably be more helpful. I won't pretend I follow every thread
closely, but I haven't seen a lot of useless repetition. The google-posters
are the most annoying recent development, in my opinion, and there have been
a rash of multi-posters, but I haven't seen a lot of noise in the sense
you're suggesting.
Matt
------------------------------
Date: Mon, 16 Jan 2006 17:11:55 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Netiquette aspect
Message-Id: <Pine.LNX.4.62.0601161656350.1146@ppepc62.ph.gla.ac.uk>
On Mon, 16 Jan 2006, Matt Garrish wrote:
> I won't pretend I follow every thread
> closely, but I haven't seen a lot of useless repetition.
If I can try to make a positive suggestion, resisting the temptation
to just gripe: my own practice, which I'd recommend to anyone else, is
to sort the new postings into thread order with the newest first (PINE
regards that as "Reverse" ordering), and then work my way down each
thread, from the newest new posting to the oldest new posting, if you
see what I mean.
That way, I'm less likely to respond to a posting which has already
been "overtaken by events". h t h...
> The google-posters are the most annoying recent development, in my
> opinion,
I don't generally see those, as they're below my kill/score threshold;
if they say anything worth reading, I'm leaving it to those who have
more patience than I have to post a followup, then, if it looks
interesting, I'll go back and read the original posting, and maybe
even add the original poster to my g-g exceptions list. I don't know
what that makes me - but frankly, life's too short to read everything
on usenet, nor even to read everything on the groups that I've
"subscribed" to.
However, I get the impression there are far more followups which are
rebuking g-g posters for bad netiquette, than there are which are
responding to their substantive content. That itself carries a
message, IMNSHO. I also get the impression that, paradoxically, they
are the least likely to use g-g to research previous postings on their
topic.
cheers
------------------------------
Date: Mon, 16 Jan 2006 19:08:32 +0000
From: John Nurick <j.mapson.nurick@dial.pipex.com>
Subject: Re: while ( ) and until ( )
Message-Id: <a8rns11n1206digomendhon1g12rsfsu5i@4ax.com>
On Mon, 16 Jan 2006 10:20:54 +0100, "Tassilo v. Parseval"
<tassilo.von.parseval@rwth-aachen.de> wrote:
>It's a subtle difference in Perl's grammar:
>
>/* Loops: while, until, for, and a bare block */
>loop : label WHILE '(' remember texpr ')' mintro mblock cont
> { ... }
> | label UNTIL '(' remember iexpr ')' mintro mblock cont
> { ... }
>
>Note the distinction into 'texpr' and 'iexpr', the difference being that
>'texpr' is an expression where empty means true so 'while ()' is the
>same as 'while (1)'.
>
>I am quite sure this has been done on purpose because 'until () { ... }'
>would then be the same as 'until (1) { ... }', meaning: the body of the
>loop is never executed.
>
>Still, it would be nice to turn 'until ()' into 'until (0)' so a
>bug-report (see 'perldoc perlbug') might still be in order here.
Thank you for the info. I've submitted a bug report ('wishlist'
priority). I like the way that turning 'until ()' into 'until (0)'
would mean that 'until ()' and 'while ()' worked the same.
John
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 V10 Issue 8857
***************************************
