[28640] in Perl-Users-Digest
Perl-Users Digest, Issue: 10004 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Nov 24 18:10:23 2006
Date: Fri, 24 Nov 2006 15:10:14 -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 Fri, 24 Nov 2006 Volume: 10 Number: 10004
Today's topics:
Re: Do I *have* to use 'OOP' to use modules? <nospam-abuse@ilyaz.org>
Re: Do I *have* to use 'OOP' to use modules? <nospam-abuse@ilyaz.org>
Re: handling hanging database connections: timeout in p xhoster@gmail.com
literal substitution <dave@walden-family.com>
Re: literal substitution <kenslaterpa@hotmail.com>
Re: literal substitution <jurgenex@hotmail.com>
Re: literal substitution <dave@walden-family.com>
prevent further hash auto-vivification ivowel@gmail.com
Re: prevent further hash auto-vivification <spamtrap@dot-app.org>
Re: prevent further hash auto-vivification <DJStunks@gmail.com>
Re: prevent further hash auto-vivification <tbmoore9@verizon.net>
Re: prevent further hash auto-vivification <mritty@gmail.com>
Re: prevent further hash auto-vivification <bik.mido@tiscalinet.it>
Re: prevent further hash auto-vivification <bik.mido@tiscalinet.it>
seek/tell in presence of multibyte characters <robert.dodier@gmail.com>
Re: seek/tell in presence of multibyte characters xhoster@gmail.com
Re: seek/tell in presence of multibyte characters (reading news)
speaking of forking -- parallel database fetches? <DJStunks@gmail.com>
Re: speaking of forking -- parallel database fetches? xhoster@gmail.com
Re: the opposite of 'chop' <news@lawshouse.org>
Re: the opposite of 'chop' <davidjpeacock@magma.ca>
Re: the opposite of 'chop' <dr.mtarver@ukonline.co.uk>
Re: the opposite of 'chop' <mritty@gmail.com>
Re: the opposite of 'chop' <john@castleamber.com>
Re: what is the best choose fork or thread? <m@remove.this.part.rtij.nl>
Re: what is the best choose fork or thread? xhoster@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 24 Nov 2006 22:21:47 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Do I *have* to use 'OOP' to use modules?
Message-Id: <ek7r9r$1gd9$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Abigail
<abigail@abigail.be>], who wrote in article <slrnemcgdn.c8.abigail@alexandra.abigail.be>:
> __ Do I understand correct that you agree on having the same namespace
> __ for attributes and methods?
>
> You understand incorrectly. Attributes should be private to the class;
> an object may have more than one attribute with the same name, but no
> class could have more than one attribute with the same name.
Sorry, but I have no idea what your "answer" has to do with my
question. E.g., note that an may have more than one method with
the same name, but no class could have more than one method with
the same name.
> I may not want to expose the existance (or non-existance) of an attribute
> to the world at large.
"Privateness" is indeed not addressed in my API. But neither is it
applicable to methods, so - in context of Perl - this is not a crucial
observation.
> Furthermore, if we would have Perl6 style attributes,
> we would have compile time checking of typos in attribute names; methods
> aren't resolved until runtime.
If one has the same namespace for methods and attributes, how is the
compiler to distinguish what to check, and what not?
> I couldn't give a rats ass whether it's core or a module. What I care about
> is:
>
> * Encapsulation. How one class is implemented should neither depend
> on the implementation of a superclass, nor restrict the implementation
> of a subclass.
Is in the discussed API.
> * Compile time checking of my attribute names. Full advantage of
> 'use strict'.
Not there.
> * A syntax that isn't convoluted. Attributes are variables - they should
> look like variables.
Not there. But neither is it in p6 syntax.
> Methods don't look like variables.
I fail to see how $o->method and $o.method are looking differently.
Yours,
Ilya
------------------------------
Date: Fri, 24 Nov 2006 22:28:57 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Do I *have* to use 'OOP' to use modules?
Message-Id: <ek7rn9$1gmt$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Abigail
<abigail@abigail.be>], who wrote in article <slrnemcgdn.c8.abigail@alexandra.abigail.be>:
> __ P.S. Recall that Abigail insisted that attributes should be present
> __ in the core, and I fail to see why this should not be delegated
> __ to a module.
>
> I couldn't give a rats ass whether it's core or a module.
Probably then it was some different gal who posted:
------
() I'd be interested to hear why you think OO Perl is not worth bothering with.
OOP doesn't have object attributes natively.
------
My point is simple: if attributes were REALLY important to somebody,
then this somebody would spend a couple of hours, and would implement
a module which enables attributes. (Out-of-band storage is not hard.)
Myself, I never needed attributes that badly.
Hope this helps,
Ilya
------------------------------
Date: 24 Nov 2006 20:41:11 GMT
From: xhoster@gmail.com
Subject: Re: handling hanging database connections: timeout in perl
Message-Id: <20061124154200.330$AC@newsreader.com>
daniel.crosby@gmx.de wrote:
> The eval does not seem to be enough to provoke a timeout on a hanging
> oracle connection i.e. where i get no response. I do not understand why
> this does not work in this perl example.
Your code is pretty much unreadable. You should produce a reduced example
> $SIG{ALRM} = sub {&ConnectTimeOut
> ($l_host, $l_db, $l_ars, $l_ars_sev, $l_erg) };
You haven't shown us what ConnectTimeOut does. That is pretty important if
we are to help you.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 24 Nov 2006 08:26:01 -0800
From: "Dave Walden" <dave@walden-family.com>
Subject: literal substitution
Message-Id: <1164385560.957006.59940@h54g2000cwb.googlegroups.com>
Hi,
Can someone tell me how I can obtain functionality like
$str =~ s/$a/$b/g;
where $a and $b contain strings and where instance of the the literal
string contained in $a are replaced by the literal string in $b
*without* regular expression interpretation. In other words, in the
following
my $str = 'moo \foo.* zoo';
my $a = ' \foo.*';
my $b = ' $';
$str =~ s/$a/$b/g;
I would like the value in $str to end up being 'moo $ zoo' while
allowing me to avoid having to escape in all the regex control
characters in the arguments to s///. Is there some qualifier I can use
to turn off regular expression interpretation in the arguments to s///
or some other way I can easily accomplish this without coding a new
subtroutine which takes the three arguments $str, $a, and $b and does
what I want?
Thanks, Dave
------------------------------
Date: 24 Nov 2006 08:40:59 -0800
From: "kens" <kenslaterpa@hotmail.com>
Subject: Re: literal substitution
Message-Id: <1164386459.433083.113340@l12g2000cwl.googlegroups.com>
Dave Walden wrote:
> Hi,
>
> Can someone tell me how I can obtain functionality like
> $str =~ s/$a/$b/g;
> where $a and $b contain strings and where instance of the the literal
> string contained in $a are replaced by the literal string in $b
> *without* regular expression interpretation. In other words, in the
> following
> my $str = 'moo \foo.* zoo';
> my $a = ' \foo.*';
> my $b = ' $';
> $str =~ s/$a/$b/g;
> I would like the value in $str to end up being 'moo $ zoo' while
> allowing me to avoid having to escape in all the regex control
> characters in the arguments to s///. Is there some qualifier I can use
> to turn off regular expression interpretation in the arguments to s///
> or some other way I can easily accomplish this without coding a new
> subtroutine which takes the three arguments $str, $a, and $b and does
> what I want?
>
> Thanks, Dave
You may want to look at the quotemeta function.
perldoc -f quotemeta
HTH, Ken
------------------------------
Date: Fri, 24 Nov 2006 16:43:20 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: literal substitution
Message-Id: <IiF9h.4663$_x3.3282@trndny02>
Dave Walden wrote:
> Hi,
>
> Can someone tell me how I can obtain functionality like
> $str =~ s/$a/$b/g;
> where $a and $b contain strings and where instance of the the literal
> string contained in $a are replaced by the literal string in $b
> *without* regular expression interpretation.
Sometimes I wonder why people are so obsessed with REs. Yes, they are great
and powerful and you you can do a lot with them.
However, why bend over backwards to make them fit a scenario they were not
meant for when there are much easier and straightforward solutions:
- use index() to find the location of string $a in $str
- use substr() to replace the text
jue
------------------------------
Date: 24 Nov 2006 10:52:30 -0800
From: "Dave Walden" <dave@walden-family.com>
Subject: Re: literal substitution
Message-Id: <1164394350.509682.306740@l39g2000cwd.googlegroups.com>
J=FCrgen Exner wrote:
> - use index() to find the location of string $a in $str
> - use substr() to replace the text
Thanks. That's the memory jog I needed (although not as ideal as
having an additional qualifier to s/// that turned off regex control
character interpretation).
------------------------------
Date: 24 Nov 2006 11:04:20 -0800
From: ivowel@gmail.com
Subject: prevent further hash auto-vivification
Message-Id: <1164395060.703122.309670@j72g2000cwa.googlegroups.com>
dear perl experts: how can I stop perl from auto-vivifying new keys in
a hash? this seems like something that everyone would want as an
optional feature in an object oriented context, isn't it? sincerely,
/iaw
------------------------------
Date: Fri, 24 Nov 2006 14:10:36 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: prevent further hash auto-vivification
Message-Id: <m2slg8acer.fsf@Sherm-Pendleys-Computer.local>
ivowel@gmail.com writes:
> dear perl experts: how can I stop perl from auto-vivifying new keys in
> a hash?
Use exists() to check for their presence before accessing them.
perldoc -f exists
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: 24 Nov 2006 11:38:54 -0800
From: "DJ Stunks" <DJStunks@gmail.com>
Subject: Re: prevent further hash auto-vivification
Message-Id: <1164397134.851842.136390@l39g2000cwd.googlegroups.com>
ivowel@gmail.com wrote:
> dear perl experts: how can I stop perl from auto-vivifying new keys in
> a hash? this seems like something that everyone would want as an
> optional feature in an object oriented context, isn't it?
http://www.perlarchive.com/articles/perl/ug0002.shtml
-jp
------------------------------
Date: Fri, 24 Nov 2006 21:38:35 GMT
From: boyd <tbmoore9@verizon.net>
Subject: Re: prevent further hash auto-vivification
Message-Id: <tbmoore9-F112F1.16383624112006@news.verizon.net>
In article <m2slg8acer.fsf@Sherm-Pendleys-Computer.local>,
Sherm Pendley <spamtrap@dot-app.org> wrote:
> ivowel@gmail.com writes:
>
> > dear perl experts: how can I stop perl from auto-vivifying new keys in
> > a hash?
>
> Use exists() to check for their presence before accessing them.
>
> perldoc -f exists
>
> sherm--
Not true. Exists will cause them to be vivified see the reference
quoted before:
http://www.perlarchive.com/articles/perl/ug0002.shtml
------------------------------
Date: 24 Nov 2006 14:27:07 -0800
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: prevent further hash auto-vivification
Message-Id: <1164407227.858791.321520@l39g2000cwd.googlegroups.com>
boyd wrote:
> In article <m2slg8acer.fsf@Sherm-Pendleys-Computer.local>,
> Sherm Pendley <spamtrap@dot-app.org> wrote:
>
> > ivowel@gmail.com writes:
> >
> > > dear perl experts: how can I stop perl from auto-vivifying new keys in
> > > a hash?
> >
> > Use exists() to check for their presence before accessing them.
> >
> > perldoc -f exists
> Not true. Exists will cause them to be vivified see the reference
> quoted before:
> http://www.perlarchive.com/articles/perl/ug0002.shtml
Did you read that article? Using exists() does NOT cause a hash level
to be autovivified. Accessing a level on the way towards using
exists() does. Therefore, you have to use exists on all levels that
you want to test:
if (exists $h{'baz'} and exists $h{'baz'}{'alpha'}) { ... }
rather than simply:
if (exists $h{'baz'}) { ... }
Paul Lalli
------------------------------
Date: Fri, 24 Nov 2006 23:51:12 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: prevent further hash auto-vivification
Message-Id: <ogtem29b640vqt5pn30m130c3n2sufih5r@4ax.com>
On Fri, 24 Nov 2006 21:38:35 GMT, boyd <tbmoore9@verizon.net> wrote:
>> > dear perl experts: how can I stop perl from auto-vivifying new keys in
>> > a hash?
>>
>> Use exists() to check for their presence before accessing them.
>>
>> perldoc -f exists
>>
>> sherm--
>
>Not true. Exists will cause them to be vivified see the reference
>quoted before:
>http://www.perlarchive.com/articles/perl/ug0002.shtml
Not true. Using "exist() to check for their presence before accessing
them" yields a way to "stop perl from auto-vivifying new keys in a
hash". That it won't prevent autovivification at some shallower levels
when accessing a complex data structure is a whole another story and
only means that you have to apply the same technique repeatedly and if
you end up doing so quite often or otherwise find it convenient, then
write some code that will factorize that apart, or find a module that
addresses the issue.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Fri, 24 Nov 2006 23:53:05 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: prevent further hash auto-vivification
Message-Id: <crtem25prt73bkbmrovmjte7krf44db72v@4ax.com>
On 24 Nov 2006 11:04:20 -0800, ivowel@gmail.com wrote:
>a hash? this seems like something that everyone would want as an
>optional feature in an object oriented context, isn't it? sincerely,
IMHO that's something someone may occasionally want. I don't really
see how that would be related to an object oriented context in any
particular way.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: 24 Nov 2006 11:18:52 -0800
From: "Robert Dodier" <robert.dodier@gmail.com>
Subject: seek/tell in presence of multibyte characters
Message-Id: <1164395932.226999.108480@14g2000cws.googlegroups.com>
Hello,
I would like to call seek and tell on files which contain multibyte
characters (utf8).
perldoc -f seek says that seek only considers byte offsets, not
character offsets.
How can I implement a seek-like function which takes a character
offset?
(Or does such a thing already exist in some library?)
Likewise, I need a tell function which reports character offset instead
of byte offset.
It is OK if these character seek/tell functions are slower than the
built-in byte seek/tell.
Thanks for any light you can shed on this problem.
Robert Dodier
------------------------------
Date: 24 Nov 2006 20:46:22 GMT
From: xhoster@gmail.com
Subject: Re: seek/tell in presence of multibyte characters
Message-Id: <20061124154711.914$Nc@newsreader.com>
"Robert Dodier" <robert.dodier@gmail.com> wrote:
> Hello,
>
> I would like to call seek and tell on files which contain multibyte
> characters (utf8).
> perldoc -f seek says that seek only considers byte offsets, not
> character offsets.
> How can I implement a seek-like function which takes a character
> offset?
Seek to the beginning of the file, then count characters until you
get where you want. To speed it up, save a table of occasional waymarks
giving the byte offset of certain character offsets, then you can seek back
to the last waymark which is less than the desired one and count from
there.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Fri, 24 Nov 2006 21:34:26 GMT
From: "Mumia W. (reading news)" <paduille.4060.mumia.w@earthlink.net>
Subject: Re: seek/tell in presence of multibyte characters
Message-Id: <CzJ9h.3479$1s6.3084@newsread2.news.pas.earthlink.net>
On 11/24/2006 01:18 PM, Robert Dodier wrote:
> Hello,
>
> I would like to call seek and tell on files which contain multibyte
> characters (utf8).
> perldoc -f seek says that seek only considers byte offsets, not
> character offsets.
> How can I implement a seek-like function which takes a character
> offset?
> (Or does such a thing already exist in some library?)
> Likewise, I need a tell function which reports character offset instead
> of byte offset.
>
> It is OK if these character seek/tell functions are slower than the
> built-in byte seek/tell.
>
> Thanks for any light you can shed on this problem.
>
> Robert Dodier
>
If I had control over the file format, I would use a 16-bit unicode
version. That would provide predictable character sizes.
I have no ideas of how you can seek through a utf-8 encoded file.
If you can, use GNU "recode" or a similar utility (such a Perl :-) ) to
convert the file from its original encoding to a 16-bit unicode file.
--
paduille.4060.mumia.w@earthlink.net
------------------------------
Date: 24 Nov 2006 11:23:27 -0800
From: "DJ Stunks" <DJStunks@gmail.com>
Subject: speaking of forking -- parallel database fetches?
Message-Id: <1164396207.844405.165060@j44g2000cwa.googlegroups.com>
Hey all,
I have a question about performing two long-running selects from a
database in parallel. I've only written a few scripts which do things
in parallel so I'm not an expert by any means.
I have two straightforward SELECT statements, but both take about two
minutes to complete. I'd like to run them in parallel, but I obviously
need access to all the rows - what's the best way to do so?
I was thinking something along these lines (pseudocode below) but I was
hoping there would be some way to give the parent access to the
statement handle itself so it could pull the rows once the queries were
complete rather than pulling all the rows in the child, and serializing
and passing to the parent.
Any ideas or maybe modules which could be handy? (I looked at both
Acme::Spork and Parallel::ForkManager but neither are appropriate)
TIA,
-jp
#!/usr/bin/perl <pseudocode>
use strict;
use warnings;
my @kids = (
{ query => 'select * from big_table' },
{ query => 'select * from another_big_table' },
);
my $pid;
for my $kid (@kids) {
$pid = open( my $fh, '|-');
die "Can't fork: $!\n" if not defined $pid;
@{ $kid }{ 'pid','handle' } = ($pid,$fh);
}
if ( $pid == 0) { # I'm one of the children
# connect to the db
# prepare query
# execute query
# wait for results
# foreach @row = $sth->fetchrow_array
# print join( $;, @row ), "\n"
# exit; (exit or waitpid? do I know the parent read everything?)
}
else { # I'm the parent
# while ( my $line = < $kids[0]{handle} >) {
# @row = split $;, $line;
# do whatever with @row
#
# while ( my $line = < $kids[1]{handle} >) {
# etc.
}
__END__
------------------------------
Date: 24 Nov 2006 21:05:56 GMT
From: xhoster@gmail.com
Subject: Re: speaking of forking -- parallel database fetches?
Message-Id: <20061124160645.883$i0@newsreader.com>
"DJ Stunks" <DJStunks@gmail.com> wrote:
> Hey all,
>
> I have a question about performing two long-running selects from a
> database in parallel. I've only written a few scripts which do things
> in parallel so I'm not an expert by any means.
>
> I have two straightforward SELECT statements, but both take about two
> minutes to complete. I'd like to run them in parallel, but I obviously
> need access to all the rows - what's the best way to do so?
How many rows are we talking?
> I was thinking something along these lines (pseudocode below) but I was
> hoping there would be some way to give the parent access to the
> statement handle itself so it could pull the rows once the queries were
> complete
I'm pretty sure that that ain't gonna happen.
> rather than pulling all the rows in the child, and serializing
> and passing to the parent.
>
> Any ideas or maybe modules which could be handy? (I looked at both
> Acme::Spork and Parallel::ForkManager but neither are appropriate)
Parallel::Jobs might help, although it isn't very easy to use and wants to
run commands rather than Perl code (so you would have to fire up a new Perl
interpreter from scratch, and it wouldn't inherit variables, etc, from the
existing one). I've posted here a while ago a simple mod of
Parallel::ForkManager to allow back tack from the child to the parent, but
it send the data as a slug of serialized data, not as a stream. Whether
this is deadly or not depends on how many rows.
http://groups.google.com/group/comp.lang.perl.modules/browse_frm/thread/9c8
ef79472740156/
Also, there is Parallel::Simple, which I never used but looks promising.
>
> my $pid;
> for my $kid (@kids) {
> $pid = open( my $fh, '|-');
> die "Can't fork: $!\n" if not defined $pid;
>
> @{ $kid }{ 'pid','handle' } = ($pid,$fh);
> }
>
> if ( $pid == 0) { # I'm one of the children
How does the child know which child it is? It would have to loop over
@kids comparing it's pid to the stored pid (which it can't do, because
the stored pid is stored only in the parent, not the child). Better to
move this else block into the inside of the the for my $kid loop, that way
the kid automatically know who it is by looking in $kid.
...
> # wait for results
> # foreach @row = $sth->fetchrow_array
Technically, you can't waid for results as a separate action from
calling fetchrow_array. fetchrow_array is inherently waiting for results.
> # print join( $;, @row ), "\n"
>
> # exit; (exit or waitpid? do I know the parent read everything?)
exit. You almost certainly don't want to waitpid (for what? The parent?).
At this point, you stuffed everything you have into the buffer up to the
parent. That is all you an do. If the parent doesn't read it all, what
is the child to do about it?
> }
> else { # I'm the parent
>
> # while ( my $line = < $kids[0]{handle} >) {
> # @row = split $;, $line;
> # do whatever with @row
You will want to "close $kids[0]{handle} or [die|warn] $! $?;" to make sure
the kid ended things on a good note. The close implicilty waits for the
the child to exit.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Fri, 24 Nov 2006 14:33:45 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: the opposite of 'chop'
Message-Id: <1164378825.73519.0@despina.uk.clara.net>
Paul Lalli wrote:
> my $first_char = substr($string,0,1, q{});
I thought this was a typo until I looked up perlop; I see that q{} is
synonymous with ''. Is there a particular benefit from using q{}
rather than '' here? I understand that it's very convenient when
single-quoting a string that contains a single quote.
--
Henry Law <>< Manchester, England
------------------------------
Date: Fri, 24 Nov 2006 08:52:33 -0600
From: David Peacock <davidjpeacock@magma.ca>
Subject: Re: the opposite of 'chop'
Message-Id: <slrneme1ph.ro3.davidjpeacock@david-peacocks-computer.local>
Henry Law <news@lawshouse.org> wrote:
> Paul Lalli wrote:
>
>> my $first_char = substr($string,0,1, q{});
>
> I thought this was a typo until I looked up perlop; I see that q{} is
> synonymous with ''. Is there a particular benefit from using q{}
> rather than '' here? I understand that it's very convenient when
> single-quoting a string that contains a single quote.
I believe that this is a style thing. The consensus appears to be that
when quoting an empty string, it's easier to read in future if you are
explicity stating that you're quoting and that that quote contains
nothing.
It's more readable, at least to me, anyways.
--
David Peacock - davidjpeacock@magma.ca
http://quasicanuck.blogspot.com/
------------------------------
Date: 24 Nov 2006 07:32:58 -0800
From: "Mark Tarver" <dr.mtarver@ukonline.co.uk>
Subject: Re: the opposite of 'chop'
Message-Id: <1164382378.322360.147810@l12g2000cwl.googlegroups.com>
thanks - new question posted.
Mark
Paul Lalli wrote:
> Mark Tarver wrote:
> > I understand 'chop' grabs the last token of a string.
>
> You understand incorrectly. chop() does not "grab" the last character
> in a string. It removes the last character from the string, and then
> returns whatever that character was. That is, it directly modifies the
> string you pass to it.
>
> > What grabs the first?
>
> There is no direct functional equivalent for the beginning of the
> string. If you'd like, you can use substr:
>
> my $first_char = substr($string,0,1, q{});
>
> Paul Lalli
------------------------------
Date: 24 Nov 2006 08:11:02 -0800
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: the opposite of 'chop'
Message-Id: <1164384661.995819.127260@j44g2000cwa.googlegroups.com>
Henry Law wrote:
> Paul Lalli wrote:
>
> > my $first_char = substr($string,0,1, q{});
>
> I thought this was a typo until I looked up perlop; I see that q{} is
> synonymous with ''. Is there a particular benefit from using q{}
> rather than '' here?
Because '' looks far too much like " and that can be confusing to
people reading the code.
Paul Lalli
------------------------------
Date: 24 Nov 2006 17:33:26 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: the opposite of 'chop'
Message-Id: <Xns98857590ED285castleamber@130.133.1.4>
"Paul Lalli" <mritty@gmail.com> wrote:
> Mark Tarver wrote:
>> I understand 'chop' grabs the last token of a string.
>
> You understand incorrectly. chop() does not "grab" the last character
> in a string. It removes the last character from the string, and then
> returns whatever that character was. That is, it directly modifies the
> string you pass to it.
>
>> What grabs the first?
>
> There is no direct functional equivalent for the beginning of the
> string. If you'd like, you can use substr:
>
> my $first_char = substr($string,0,1, q{});
or reverse the string, chop it, and reverse it back :-)
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: Fri, 24 Nov 2006 19:09:17 +0100
From: Martijn Lievaart <m@remove.this.part.rtij.nl>
Subject: Re: what is the best choose fork or thread?
Message-Id: <pan.2006.11.24.18.09.15.578158@remove.this.part.rtij.nl>
On Fri, 24 Nov 2006 11:55:19 +0000, Ben Morrow wrote:
>
> Quoth Martijn Lievaart <m@remove.this.part.rtij.nl>:
>> On Thu, 23 Nov 2006 23:56:42 +0800, sonet wrote:
>>
>> > I have a project must send a lot of file in win2k at the same time.
>> > But what is the best method in win32?
>> > Can the perl build-in function fork work in win32?
>> > Or the perl build-in thread is good solution
>>
>> Besides Anno's answer, be aware that threads have severe limitations. More
>> to the point, threads and signals don't mix. So if you need timeouts (in
>> Perl) or any other signal handling, you are pretty much stuck on forking.
>>
>> Other than that, in general threads are faster than forks. New threads are
>> created faster
>
> Do you have any evidence for this? While it may be true in general, it
> is very much *not* true of Perl threads as currently implemented. For
> instance, on my machine,
Thanks! I was talking in general, I didn't know Perl threads were this
slow.
M4
--
Redundancy is a great way to introduce more single points of failure.
------------------------------
Date: 24 Nov 2006 21:08:04 GMT
From: xhoster@gmail.com
Subject: Re: what is the best choose fork or thread?
Message-Id: <20061124160853.493$mA@newsreader.com>
Martijn Lievaart <m@remove.this.part.rtij.nl> wrote:
> On Thu, 23 Nov 2006 23:56:42 +0800, sonet wrote:
>
> > I have a project must send a lot of file in win2k at the same time.
> > But what is the best method in win32?
> > Can the perl build-in function fork work in win32?
> > Or the perl build-in thread is good solution
>
> Besides Anno's answer, be aware that threads have severe limitations.
> More to the point, threads and signals don't mix. So if you need timeouts
> (in Perl) or any other signal handling, you are pretty much stuck on
> forking.
>
> Other than that, in general threads are faster than forks.
Maybe in some languages, but in Perl they generally aren't.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
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 10004
****************************************
