[31955] in Perl-Users-Digest
Perl-Users Digest, Issue: 3218 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Nov 25 00:09:25 2010
Date: Wed, 24 Nov 2010 21:09:06 -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 Wed, 24 Nov 2010 Volume: 11 Number: 3218
Today's topics:
Re: FAQ 3.10 Is there an IDE or Windows Perl Editor? <ac.russell@live.com>
Re: Finding if something is in a list <tadmc@seesig.invalid>
Re: Finding if something is in a list sln@netherlands.com
Re: Finding if something is in a list <Peter@PSDT.com>
Re: Finding if something is in a list <jwkrahn@example.com>
Memory consumption when writing to files <bart@nijlen.com>
Re: Memory consumption when writing to files <NoSpamPleaseButThisIsValid3@gmx.net>
Re: Memory consumption when writing to files <peter@makholm.net>
Selective $SIG{CHLD} <whynot@pozharski.name>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 24 Nov 2010 11:44:23 -0500
From: Adam Russell <ac.russell@live.com>
Subject: Re: FAQ 3.10 Is there an IDE or Windows Perl Editor?
Message-Id: <icjfd5$8ev$1@speranza.aioe.org>
How about a mention of RAD GUI builders that support Perl?
For example,
Glade + gtk2-perl.
http://glade.gnome.org/
http://gtk2-perl.sourceforge.net/
ZooZ
http://cpan.uwinnipeg.ca/dist/ZooZ
specTCl
http://spectcl.sourceforge.net/
wxGlade
http://wxglade.sourceforge.net/
I am sure I missed some too but those are the ones I have heard most
about or have used myself.
------------------------------
Date: Tue, 23 Nov 2010 17:11:18 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Finding if something is in a list
Message-Id: <slrnieoj30.p3q.tadmc@tadbox.sbcglobal.net>
Keith Thompson <kst-u@mib.org> wrote:
> "C.DeRykus" <derykus@gmail.com> writes:
> [...]
>> Not a biggie which I'm sure is why Tad
>> just used () instead of (?:)
No, I almost never use (?:) because it is harder to read and is often
a case of premature optimization.
I write first for a human reading the code, and only ugly it up
if strictly required.
>> but any ()
>> creates a backref. (?:) though groups
>> without capturing. So (?:^|;) in this
>> case is faster since no capture/copy
>> is needed. Also, clearer about what's
>> going on which is important in longer
>> regexes.
> (?:) is
> also slightly harder to read
That is why I don't generally use it.
> I'm not saying that's an excuse for creating backrefs
> unnecessarily, but there is some pressure to use () because it works.
I _am_ saying that code readability is an excuse for creating
unused backrefs. :-)
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Tue, 23 Nov 2010 17:11:23 -0800
From: sln@netherlands.com
Subject: Re: Finding if something is in a list
Message-Id: <5cpoe6505qdp9mo6vi5g067gklr5jeurah@4ax.com>
On Tue, 23 Nov 2010 13:52:05 -0800, sln@netherlands.com wrote:
[snip preamble]
> |
> # Exclude free comments
> (\#) (?:[^\n])*
^^
In the interest of readability, this grouping can be removed.
(\#) [^\n]*
[snip lines and lines of stuff]
-sln
------------------------------
Date: Wed, 24 Nov 2010 04:45:52 GMT
From: Peter Scott <Peter@PSDT.com>
Subject: Re: Finding if something is in a list
Message-Id: <4M0Ho.76$jG3.63@newsfe08.iad>
On Tue, 23 Nov 2010 10:13:19 -0800, Keith Thompson wrote:
> I (almost) wish that the syntax for grouping without backrefs were at
> least as terse as the syntax for grouping with backrefs. Having to add
> extra punctuation to indicate *not* doing something just seems
> counterintuitive.
Understand that the basic syntax for regular expressions was created
first by mathematicians before computers existed, then transliterated for
computers before Perl existed, and so the Perl developers were starting
from a syntax that had already been developed according to certain
assumptions, and this constrained their choices as they extended the
syntax.
If you want to see what pattern matching syntax can look like when all
the legacy is thrown out or up for debate, see rules in Perl 6.
--
Peter Scott
http://www.perlmedic.com/ http://www.perldebugged.com/
http://www.informit.com/store/product.aspx?isbn=0137001274
http://www.oreillyschool.com/courses/perl3/
------------------------------
Date: Wed, 24 Nov 2010 08:42:22 -0800
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: Finding if something is in a list
Message-Id: <OfbHo.40514$z41.27493@newsfe05.iad>
Uri Guttman wrote:
>>>>>> "DS" == Dave Saville<dave@invalid.invalid> writes:
>
> DS> Can't change the string - it is coming from another application and I
> DS> can't change the data format.
>
> that makes no sense. you CAN always change it for internal use like
> searching. are you looking into this string many times? if so, spliting
> the values out to a hash and searching that will be much faster and
> simpler. no need for much other than split and a hash lookup:
>
> my %is_book_num = map { $_ => 1 } split /;/, $string ;
>
> that will create a leading empty field which shouldn't matter in your
> lookups. if you are worried about it, then either grep that out or use a
> different way to grab them (\d+ comes to mind) in a regex:
>
> my %is_book_num = map { $_ => 1 } $string =~ /(\d+)/ ;
That only captures the first \d+ value, which is OK if that is all that
is required. To capture all \d+ values:
my %is_book_num = map { $_ => 1 } $string =~ /\d+/g;
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
------------------------------
Date: Wed, 24 Nov 2010 01:26:58 -0800 (PST)
From: Bart Van der Donck <bart@nijlen.com>
Subject: Memory consumption when writing to files
Message-Id: <e520ff1b-0ba0-4a66-8d48-3144893db91a@y23g2000yqd.googlegroups.com>
Hello,
I am doing a bit of research about Perl's I/O memory consumption.
Using ">>" seems a very memory-efficient strategy for logging. In so
far I can see, the log file would not need to be opened. Web servers
use such techniques for HTTP logs - I've seen very busy web servers
that don't have trouble to write many log lines simultaneously into
already huge files. My best guess would be that the new data is stored
separately into some memory blocks (in C?), and that then the new
blocks are somehow added to the original file. I could be wrong, but
this could maybe explain the low memory use of ">>". In this logic, I
could write at the beginning of a file with exactly the same amount of
memory.
Using Perl's ">" would require more memory, as the occupied memory
would first need to be freed, and then new memory is allocated to
store the new data.
A traditional "Edit File" action would stand apart from this. It
requires much more memory: namely (1) open, (2) edit, and (3) save.
Like you would for example modify a text-document on your computer.
I'm not very confident with low-level memory handling; maybe some of
my thoughts are wrong.
Are these mechanisms done by the O.S. ? Or are they done by the Perl
executive in C (in a broader sense, the application that processes the
data) ? Or is this a general principle with identical results, e.g.
when I would do it from PHP/ASP ?
Thanks,
--
Bart
------------------------------
Date: Wed, 24 Nov 2010 10:42:24 +0100
From: Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net>
Subject: Re: Memory consumption when writing to files
Message-Id: <4cecde00$0$6972$9b4e6d93@newsspool4.arcor-online.net>
On 24.11.2010 10:26, Bart Van der Donck wrote:
> Hello,
>
> I am doing a bit of research about Perl's I/O memory consumption.
>
> Using ">>" seems a very memory-efficient strategy for logging. In so
> far I can see, the log file would not need to be opened.
What exactly are you referring to when writing ">>"? The only place that
makes sense to me is indeed "open". You will always need to open a file
even when only appending to it.
> Web servers
> use such techniques for HTTP logs - I've seen very busy web servers
> that don't have trouble to write many log lines simultaneously into
> already huge files.
Simultaneously? Are you really sure? They don't use some sort of locking?
> My best guess would be that the new data is stored
> separately into some memory blocks (in C?), and that then the new
> blocks are somehow added to the original file. I could be wrong, but
> this could maybe explain the low memory use of ">>". In this logic, I
> could write at the beginning of a file with exactly the same amount of
> memory.
At any place in the file. One does not need additional memory.
> Using Perl's ">" would require more memory, as the occupied memory
> would first need to be freed, and then new memory is allocated to
> store the new data.
I am a bit lost. What are you talking about? Opening a file with ">"
(without +) truncates it at the very beginning, that does not need to
allocate any memory at all.
> A traditional "Edit File" action would stand apart from this. It
> requires much more memory: namely (1) open, (2) edit, and (3) save.
> Like you would for example modify a text-document on your computer.
Open requires almost no memory (just the file handle). "Edit" and "save"
- that's a file editor offers you. On disk, you can only read, write,
seek and truncate. You cannot, for example, add something in the middle.
> I'm not very confident with low-level memory handling; maybe some of
> my thoughts are wrong.
>
> Are these mechanisms done by the O.S. ? Or are they done by the Perl
> executive in C (in a broader sense, the application that processes the
> data) ? Or is this a general principle with identical results, e.g.
> when I would do it from PHP/ASP ?
I'd say it's a general principle - but I am still not sure I understood
you correctly, especially because you are talking about memory and
writing about editing a file which are two separate things. Maybe you
want to know something about memory consumption vs. disk space usage?
Wolf
------------------------------
Date: Wed, 24 Nov 2010 11:02:44 +0100
From: Peter Makholm <peter@makholm.net>
Subject: Re: Memory consumption when writing to files
Message-Id: <87sjyrm43f.fsf@vps1.hacking.dk>
Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net> writes:
>> Web servers
>> use such techniques for HTTP logs - I've seen very busy web servers
>> that don't have trouble to write many log lines simultaneously into
>> already huge files.
>
> Simultaneously? Are you really sure? They don't use some sort of locking?
I think it is common to just open log-files in append mode and expect
writes to be atomic. This is not true for large write requests though.
//Makholm
------------------------------
Date: Tue, 23 Nov 2010 23:54:17 +0200
From: Eric Pozharski <whynot@pozharski.name>
Subject: Selective $SIG{CHLD}
Message-Id: <slrnieoe04.ee7.whynot@orphan.zombinet>
Context: An object forks multiple childs (with help of IO::Pipe, if
that matters). If an object is B<DESTROY>ed then everything is just
fine (there's B<DESTROY> and it works OK). However if filehandles are
closed first then an application get $SIG{CHLD}, obviously. The problem
is that that order (what is B<DESTROY>ed first) is likely out of my
control.
Thus the question. Is there any way (except writing, obviously global,
$SIG{CHLD} handler that would selectively C<IGNORE> or C<DEFAULT> just
got signal) to handle that? Look, I don't understand that as an *easy*
way. I think, that's least intrusive in the outer app environment.
Any comments? I think, the answer is negative.
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
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 3218
***************************************
