[33086] in Perl-Users-Digest
Perl-Users Digest, Issue: 4362 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 4 05:17:23 2015
Date: Wed, 4 Feb 2015 02:17:07 -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, 4 Feb 2015 Volume: 11 Number: 4362
Today's topics:
Re: Am I adding an unnecessary step? <jblack@nospam.com>
Re: Am I adding an unnecessary step? <mvdwege@gmail.com>
Re: Am I adding an unnecessary step? <gravitalsun@hotmail.foo>
Re: Am I adding an unnecessary step? <mvdwege@gmail.com>
Re: Am I adding an unnecessary step? <rweikusat@mobileactivedefense.com>
Re: Am I adding an unnecessary step? <rweikusat@mobileactivedefense.com>
Re: Am I adding an unnecessary step? <gravitalsun@hotmail.foo>
Re: Am I adding an unnecessary step? <mvdwege@gmail.com>
Re: Am I adding an unnecessary step? <mvdwege@gmail.com>
Re: Global, Local, Static <rweikusat@mobileactivedefense.com>
Inserting a record with date field into Microsoft Acces <deasmhuinbreathnach@gmail.com>
Re: Inserting a record with date field into Microsoft A <deasmhuinbreathnach@gmail.com>
Re: Inserting a record with date field into Microsoft A <deasmhuinbreathnach@gmail.com>
Re: relative speed of regex vs split for splitting on w <rweikusat@mobileactivedefense.com>
Re: Why are these brackets necessary? <hjp-usenet3@hjp.at>
Re: Why are these brackets necessary? <news@todbe.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 2 Feb 2015 09:53:06 -0600
From: John Black <jblack@nospam.com>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <MPG.2f395961a2b3c7d0989816@news.eternal-september.org>
In article <86bnlcu6m2.fsf@gaheris.avalon.lan>, mvdwege@gmail.com says...
>
> John Black <jblack@nospam.com> writes:
>
> > In article <slrnmcqn6m.dr7.hjp-usenet3@hrunkner.hjp.at>, hjp-usenet3@hjp.at says...
> >> %colors = (
> >> red => [255, 0, 0],
> >> blue => [ 0, 0, 255],
> >> [...]
> >> );
> >>
> >> Rule of thumb: Every time you want to refer to a variable by name, you
> >> should consider using a hash instead.
> >>
> >
> > Duh. Yes, I like this. The [255, 0, 0] syntax automatically creates
> > a reference to a list
>
> It's important to get this concept right: [ 255, 0, 0 ] does not create
> a reference to a list; the square brackets take a list and return a
> reference to an array.
Yep, you are right. Thanks.
John Black
------------------------------
Date: Tue, 03 Feb 2015 11:25:11 +0100
From: Mart van de Wege <mvdwege@gmail.com>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <867fvzthq0.fsf@gaheris.avalon.lan>
John Black <jblack@nospam.com> writes:
> In article <86bnlcu6m2.fsf@gaheris.avalon.lan>, mvdwege@gmail.com says...
>>
>> John Black <jblack@nospam.com> writes:
>>
>> > In article <slrnmcqn6m.dr7.hjp-usenet3@hrunkner.hjp.at>, hjp-usenet3@hjp.at says...
>> >> %colors = (
>> >> red => [255, 0, 0],
>> >> blue => [ 0, 0, 255],
>> >> [...]
>> >> );
>> >>
>> >> Rule of thumb: Every time you want to refer to a variable by name, you
>> >> should consider using a hash instead.
>> >>
>> >
>> > Duh. Yes, I like this. The [255, 0, 0] syntax automatically creates
>> > a reference to a list
>>
>> It's important to get this concept right: [ 255, 0, 0 ] does not create
>> a reference to a list; the square brackets take a list and return a
>> reference to an array.
>
> Yep, you are right. Thanks.
>
I mention it because it is easy to think you're in list context when
working with references; leaving you banging your head because you can't
seem to find out why your program isn't working the way you expect to.
I found out that it becomes much easier to avoid that trap once you get
the difference between lists, arrays and arrayrefs straight and keep it
straight during work on a program.
Don't ask me how I know :(
Arrays and references are definitely one of Perl's legitimate ugly
warts.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Tue, 03 Feb 2015 12:43:09 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <maq8mu$1sqi$1@news.ntua.gr>
On 3/2/2015 12:25, Mart van de Wege wrote:
> Don't ask me how I know :(
>
> Arrays and references are definitely one of Perl's legitimate ugly
> warts.
>
> Mart
>
Are you serious ? Using "Arrays and references" I am able to create and
read complex data structures in small scripts that in other languages
they would Database support and full bloat programming.
------------------------------
Date: Tue, 03 Feb 2015 17:14:09 +0100
From: Mart van de Wege <mvdwege@gmail.com>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <86386nt1ke.fsf@gaheris.avalon.lan>
George Mpouras <gravitalsun@hotmail.foo> writes:
> On 3/2/2015 12:25, Mart van de Wege wrote:
>> Don't ask me how I know :(
>>
>> Arrays and references are definitely one of Perl's legitimate ugly
>> warts.
>>
>> Mart
>>
>
> Are you serious ? Using "Arrays and references" I am able to create
> and read complex data structures in small scripts that in other
> languages they would Database support and full bloat programming.
>
Yes, I am serious. And it has nothing to do with what you post.
There is nothing wrong with arrays and references on their own. The way
you use combinations of both lead to lots of misunderstandings;
especially for people just moving to perl or just beginning at all.
Perl5's syntax is just confusing and prone to promote errors and
erroneous thinking on that particular issue. It is a legitimate weakness
in the language in my opinion.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Tue, 03 Feb 2015 16:31:55 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <87wq3zrm6c.fsf@doppelsaurus.mobileactivedefense.com>
Mart van de Wege <mvdwege@gmail.com> writes:
> John Black <jblack@nospam.com> writes:
>> In article <86bnlcu6m2.fsf@gaheris.avalon.lan>, mvdwege@gmail.com says...
>>> John Black <jblack@nospam.com> writes:
>>> > In article <slrnmcqn6m.dr7.hjp-usenet3@hrunkner.hjp.at>, hjp-usenet3@hjp.at says...
>>> >> %colors = (
>>> >> red => [255, 0, 0],
>>> >> blue => [ 0, 0, 255],
>>> >> [...]
>>> >> );
>>> >>
>>> >> Rule of thumb: Every time you want to refer to a variable by name, you
>>> >> should consider using a hash instead.
>>> >>
>>> >
>>> > Duh. Yes, I like this. The [255, 0, 0] syntax automatically creates
>>> > a reference to a list
>>>
>>> It's important to get this concept right: [ 255, 0, 0 ] does not create
>>> a reference to a list; the square brackets take a list and return a
>>> reference to an array.
>>
>> Yep, you are right. Thanks.
>>
> I mention it because it is easy to think you're in list context when
> working with references; leaving you banging your head because you can't
> seem to find out why your program isn't working the way you expect to.
>
> I found out that it becomes much easier to avoid that trap once you get
> the difference between lists, arrays and arrayrefs straight and keep it
> straight during work on a program.
If so, it might help to get them really straight (all AFAIK):
- A 'list' is an ordered set of scalars on the Perl stack. It's
similar to an array insofar as randomly accessing an element
works in constant time and dissimilar because it doesn't take
ownership of its elements
- An 'array' is a kind of builtin Perl object composed of an
ordered set ot scalars (another Perl object)
- A reference is a (scalar) 'object pointer object' which does
take 'ownership' (possibly, shared ownership) of the object it
points to. Whenever a reference to an object is created,
its reference count is increased and it's decreased again when
the reference is destroyed.
When used in the indicated way, [] creates an anonymous array
initialized with copies of the list of scalar( value)s between the [] and
returns a reference to that.
> Arrays and references are definitely one of Perl's legitimate ugly
> warts.
I've read this about references a couple of times already, but only ever
as unsubstantiated assertion and usually from people with a strong air
of "programming language A sucks because it is different from
programming language B and I was already forced to learn B". I strongly
suspect that 'B' was usually Java and that this was the usual knee-jerk
rejection of anything unfamiliar because it's unfamiliar humans are
prone to.
A couple of examples of that:
But please, not the references. Not the anonymous references to
an array of hashes which make less sense than the
ThreeStarProgrammers on h4X0red crack.
The very existence of references and their ubiquity is a pretty
clear indication that your type safety is only virtual.
No, JUST USE A LANGUAGE WHICH GETS IT RIGHT! Real languages have
always passed by reference anyway.
(all from http://c2.com/cgi/wiki?WhyHatePerl)
It should be noted that none of this actually means anything.
------------------------------
Date: Tue, 03 Feb 2015 18:21:43 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <87mw4usvns.fsf@doppelsaurus.mobileactivedefense.com>
Mart van de Wege <mvdwege@gmail.com> writes:
> George Mpouras <gravitalsun@hotmail.foo> writes:
>> On 3/2/2015 12:25, Mart van de Wege wrote:
>>> Arrays and references are definitely one of Perl's legitimate ugly
>>> warts.
[...]
>> Using "Arrays and references" I am able to create
>> and read complex data structures in small scripts that in other
>> languages they would Database support and full bloat programming.
[...]
> There is nothing wrong with arrays and references on their own. The
> way you use combinations of both lead to lots of misunderstandings;
> especially for people just moving to perl or just beginning at all.
Some examples of such 'misunderstandings' including why they're relevant
would be very enlightening here. But even with them, this is a weak
claim: Anything someone hasn't learned yet will be problematic for said
someone, universally 'throughout the universe'.
> Perl5's syntax is just confusing and prone to promote errors and
> erroneous thinking on that particular issue.
Again, this would do very well with some substance added to it: What is
such confusing syntax and why precisely is it confusing? Which error are
promoted by it and how does this occur? What kind of 'erroneous thinking
on that particular issue' are you referring to and how is it caused by
'the Perl5 syntax' (for references).
Some specific criticism of 'Perl5 reference syntax': The 'Using
References' section of perlref strongly suggests that the mechanism for
using a 'hard reference' was designed (or maybe not so designed) to
resemble existing uses of symbolic references, eg, assuming a variable
$triplet = 'red';
one could refer to an array of RGB values named @red as
@$triplet;
In the same way, scalar variables holding a reference can be used
instead of an identifier in an expression, ie, there is no real syntax
for dereferencing a reference. Presumably because this was found to be
too limiting, a block returning a reference was allowed instead of the
scalar variable, leading to construct such as
${${$$a[0]}[0]}{a}
for accessing the value associated with a in
$a = [[{ a => b }, {c => d}]]
This is difficult to read and understand and very cumbersome to type if
it occurs frequently, especially when using a non-US or even non-English
keyboard layout. This was later rectified by allowing use of -> for such
cases, leading to
$a->[0]->[0]->{a}
and even later by making the -> optional between bracketed subscripts,
yielding
$a->[0][0]{a}
------------------------------
Date: Tue, 03 Feb 2015 20:21:17 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <mar3jv$18gh$1@news.ntua.gr>
On 3/2/2015 6:14 μμ, Mart van de Wege wrote:
> George Mpouras <gravitalsun@hotmail.foo> writes:
>
>> On 3/2/2015 12:25, Mart van de Wege wrote:
>>> Don't ask me how I know :(
>>>
>>> Arrays and references are definitely one of Perl's legitimate ugly
>>> warts.
>>>
>>> Mart
>>>
>>
>> Are you serious ? Using "Arrays and references" I am able to create
>> and read complex data structures in small scripts that in other
>> languages they would Database support and full bloat programming.
>>
> Yes, I am serious. And it has nothing to do with what you post.
>
> There is nothing wrong with arrays and references on their own. The way
> you use combinations of both lead to lots of misunderstandings;
> especially for people just moving to perl or just beginning at all.
>
> Perl5's syntax is just confusing and prone to promote errors and
> erroneous thinking on that particular issue. It is a legitimate weakness
> in the language in my opinion.
>
> Mart
>
maybe all this syntax is burn in to brain cells and I find it obvious,
and enjoyable !
------------------------------
Date: Wed, 04 Feb 2015 08:34:46 +0100
From: Mart van de Wege <mvdwege@gmail.com>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <86y4oeruy1.fsf@gaheris.avalon.lan>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> Mart van de Wege <mvdwege@gmail.com> writes:
>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>> On 3/2/2015 12:25, Mart van de Wege wrote:
>>>> Arrays and references are definitely one of Perl's legitimate ugly
>>>> warts.
>
> [...]
>
>>> Using "Arrays and references" I am able to create
>>> and read complex data structures in small scripts that in other
>>> languages they would Database support and full bloat programming.
>
> [...]
>
>> There is nothing wrong with arrays and references on their own. The
>> way you use combinations of both lead to lots of misunderstandings;
>> especially for people just moving to perl or just beginning at all.
>
> Some examples of such 'misunderstandings' including why they're relevant
> would be very enlightening here. But even with them, this is a weak
> claim: Anything someone hasn't learned yet will be problematic for said
> someone, universally 'throughout the universe'.
>
Yes, but Perl5 has a few pitfalls that users of other languages and
newbies should be made aware of as soon as possible, before they get in
a situation where misunderstandings will bite them in the ass.
The main stumbling block is the fact that Perl5 does not have
multidimensional arrays, meaning that for simple algorithms that need
such the user is immediately confronted with learning references and how
to use them; an intermediate-to-advanced concept in a lot of other
languages.
And your example of arrayref syntax is a fine one: unless you understand
exactly what is going on, knowing when the use of -> is optional seems
arbitrary.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Wed, 04 Feb 2015 09:12:09 +0100
From: Mart van de Wege <mvdwege@gmail.com>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <86twz2rt7q.fsf@gaheris.avalon.lan>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> Mart van de Wege <mvdwege@gmail.com> writes:
> When used in the indicated way, [] creates an anonymous array
> initialized with copies of the list of scalar( value)s between the [] and
> returns a reference to that.
>
Yes, that's what I said, only more verbose.
>> Arrays and references are definitely one of Perl's legitimate ugly
>> warts.
>
> I've read this about references a couple of times already, but only ever
> as unsubstantiated assertion and usually from people with a strong air
> of "programming language A sucks because it is different from
> programming language B and I was already forced to learn B". I strongly
> suspect that 'B' was usually Java and that this was the usual knee-jerk
> rejection of anything unfamiliar because it's unfamiliar humans are
> prone to.
I'm none of those. I have no problem with references per se, but the way
they interact with, for example, arrays, as in you *need* reference
syntax to even do multidimensional arrays, and the inconsistency of when
the -> dereference operator is mandatory is definitely not the very
example of elegance.
It is true that a lot of complaints are echo-chamber rantings, but
that's no reason to go the other way and deny that Perl5 has any warts
at all.
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Mon, 02 Feb 2015 17:28:54 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Global, Local, Static
Message-Id: <87zj8wjk89.fsf@doppelsaurus.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
[...]
> Still, “local” is occasionally useful, for two reasons:
[...]
> * “local” works on any lvalue, not just variables. So for example if I
> want to temporarily prevent DBI from throwing exceptions, I can do
> something like this:
>
> # $dbh->{AutoRaise} might be true or false here.
>
> {
> $local $dbh->{AutoRaise} = 0;
This obviously extends to any other kind of 'program-defined
environmental property', too. (DBI is just a module). Eg, assuming a
variable named $debug_level exists, declared as
our $debug_level;
in some module, a
{
local $debug_level = 0;
.
.
.
}
could be used to suppress diagnostics temporarily while executing the
code in this block.
Another real-world example would be some code I'm using the generate
netfilter rules (by invoking iptables as I don't have an infinite amount
of time to spend money of other people on whatever stuff happens to come
to my mind). In order for this to be generally useful, each iptables
call needs a table argument, yet, the table is almost always the same
and code which just wants to manipulate rules in 'the table' shouldn't
need to pass the name of it down into the command execution layer all of
the time (it shouldn't even know what 'the table' is actually called).
The solution for this comes in form of a package variable name
$the_table which is initialized to 'the name of the table'. In the
relatively rare cases where rules in another table have to be
manipulated, the code which 'knows' this is supposed to use local to
bind $the_table to a suitable value.
The whole local - my comparison in perlsub is really terribly misguided
in a language which support both dynamic and lexical scoping: The point
of local is to modify some part of 'the global execution environment'
when executing code in 'other than ordinary circumstances' without this
code itself having to be aware of that.
------------------------------
Date: Tue, 3 Feb 2015 08:59:52 -0800 (PST)
From: Desmond Walsh <deasmhuinbreathnach@gmail.com>
Subject: Inserting a record with date field into Microsoft Access using Perl DBI
Message-Id: <aaf47c18-4a12-4496-aac9-f364c693d4b7@googlegroups.com>
My Perl code connects successfully to my Access database. I have no problem=
with SQL SELECT's. SQL INSERT INTO works using place holders for specif=
ic fields if a field is not a DateTime data type. DBI keeps telling me th=
at there is a syntax error in the SQl statement. I have tried the followi=
ng input formats ;
"#2015-02-02#"
"2015-02-02"
"#2015-02-02 00:00:00#"
"2015-02-02 00:00:00"=20
even "02-Feb-2015"
since my display format in Access is ShortDate (of course that should be ir=
relevant).
I am using DBIx::Log4perl to get as much error logging as I can, but the m=
ost I get is;
DB errstr: [Microsoft][ODBC Microsoft Access Driver] Syntax error in INSERT=
INTO statement. (SQL-42000).
By the way, the same code (different Connection parameters) works perfectly=
with DBASEIV tables.
Clearly, I am missing some pecularity about handling Access DateTime fields=
.
Would appreciate if anybody has a suggestion.
Thanks
------------------------------
Date: Tue, 3 Feb 2015 21:05:04 -0800 (PST)
From: Desmond Walsh <deasmhuinbreathnach@gmail.com>
Subject: Re: Inserting a record with date field into Microsoft Access using Perl DBI
Message-Id: <0176223d-33c8-4067-98e1-6e1701894d6c@googlegroups.com>
On Tuesday, February 3, 2015 at 11:59:56 AM UTC-5, Desmond Walsh wrote:
> My Perl code connects successfully to my Access database. I have no probl=
em with SQL SELECT's. SQL INSERT INTO works using place holders for spec=
ific fields if a field is not a DateTime data type. DBI keeps telling me =
that there is a syntax error in the SQl statement. I have tried the follo=
wing input formats ;
> "#2015-02-02#"
> "2015-02-02"
> "#2015-02-02 00:00:00#"
> "2015-02-02 00:00:00"=20
> even "02-Feb-2015"
> since my display format in Access is ShortDate (of course that should be =
irrelevant).
>=20
> I am using DBIx::Log4perl to get as much error logging as I can, but the=
most I get is;
> DB errstr: [Microsoft][ODBC Microsoft Access Driver] Syntax error in INSE=
RT INTO statement. (SQL-42000).
>=20
> By the way, the same code (different Connection parameters) works perfect=
ly with DBASEIV tables.
>=20
> Clearly, I am missing some pecularity about handling Access DateTime fiel=
ds.
> Would appreciate if anybody has a suggestion.
> Thanks
Some more information on my problem. I am running Perl 5 version 16 (from =
Active State) on a Windows 7 OS. The driver being used by DBI is ODBC. I a=
m running Access 2010.
I can specify a date criterion in a SELECT statement using the format #YYYY=
-MM-DD#. Everything works except INSERT INTO with a DateTime field in the =
list of fields
------------------------------
Date: Tue, 3 Feb 2015 22:42:42 -0800 (PST)
From: Desmond Walsh <deasmhuinbreathnach@gmail.com>
Subject: Re: Inserting a record with date field into Microsoft Access using Perl DBI
Message-Id: <3798ec6f-0ddb-4529-95ab-569717cb33ec@googlegroups.com>
On Wednesday, February 4, 2015 at 12:05:10 AM UTC-5, Desmond Walsh wrote:
> On Tuesday, February 3, 2015 at 11:59:56 AM UTC-5, Desmond Walsh wrote:
> > My Perl code connects successfully to my Access database. I have no pro=
blem with SQL SELECT's. SQL INSERT INTO works using place holders for sp=
ecific fields if a field is not a DateTime data type. DBI keeps telling m=
e that there is a syntax error in the SQl statement. I have tried the fol=
lowing input formats ;
> > "#2015-02-02#"
> > "2015-02-02"
> > "#2015-02-02 00:00:00#"
> > "2015-02-02 00:00:00"=20
> > even "02-Feb-2015"
> > since my display format in Access is ShortDate (of course that should b=
e irrelevant).
> >=20
> > I am using DBIx::Log4perl to get as much error logging as I can, but t=
he most I get is;
> > DB errstr: [Microsoft][ODBC Microsoft Access Driver] Syntax error in IN=
SERT INTO statement. (SQL-42000).
> >=20
> > By the way, the same code (different Connection parameters) works perfe=
ctly with DBASEIV tables.
> >=20
> > Clearly, I am missing some pecularity about handling Access DateTime fi=
elds.
> > Would appreciate if anybody has a suggestion.
> > Thanks
>=20
> Some more information on my problem. I am running Perl 5 version 16 (fro=
m Active State) on a Windows 7 OS. The driver being used by DBI is ODBC. I=
am running Access 2010.
>=20
> I can specify a date criterion in a SELECT statement using the format #YY=
YY-MM-DD#. Everything works except INSERT INTO with a DateTime field in th=
e list of fields
PROBLEM RESOLVED
The problem was due to my unfortunate choice of the name DATE for the DateT=
ime field (should have heeded Access's complaint when copying in the origin=
al DBASEIV table). And the correct format for the field value of the now=
renamed TDATE field is YYYY-MM-DD. Note the absence of # delimiters. In co=
ntrast, a date criterion in a SELECT statement must use #YYYY-MM-DD#=20
Although not neccessary, its probably safer to use explicit bind statement=
s i.e.
$sth->bind_param(1,$budget_no);
$sth->bind_param(2,$input_date,DBI::SQL_TIMESTAMP);
$sth->bind_param(3,$payee);
$sth->execute;
instead of
$sth->execute($budget_no,$input_date,$payee);
------------------------------
Date: Mon, 02 Feb 2015 20:03:16 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: relative speed of regex vs split for splitting on whitespace
Message-Id: <87y4ogkrnf.fsf@doppelsaurus.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> In general Rainer you are correct, the split is faster 99% of the
> cases. I had a misleading set of weird data that gave me this idea.
>
> For example look at the following where the regex is much faster
> --------------------------
>
>
>
>
> #!/usr/bin/perl
> use strict;
> use warnings;
> use Benchmark qw(cmpthese);
> use feature 'say';
>
> #####################################
> ##### Generata some sample data #####
> #####################################
>
> my $lines = 10;
> my $fields_number = 23;
> my $field_length = 20;
> my $separator = '0' x300;
[...]
> sub MethodSplit {
> foreach (@DATA) {@fields = split /\Q$separator\E/, $_}
> }
>
> sub MethodRegex {
> foreach (@DATA) {@fields = $_ =~$regex}
> }
This isn't really a sensible example for use of split because the
'format' of each input line is identical to that of each other input
line and known in advance. The built regex is actually a 'mask' with
holes in the places where data is known to reside. Using a simpler test
program for such a case,
-------------
use Benchmark;
use constant TOKEN => 200;
use constant TOKENS => 20;
use constant SEP => 100;
use constant LINES => 100;
sub make_token
{
return 'A' x TOKEN;
}
sub make_sep
{
return ' ' x SEP;
}
sub make_line
{
my $l;
$l = make_token();
$l .= make_sep().make_token() for 2 .. TOKENS;
return $l;
}
sub make_token_re
{
return '(.{'.TOKEN.'})';
}
sub make_line_re
{
my $re;
$re = make_token_re();
$re .= '.{'.SEP.'}' . make_token_re() for 2 .. TOKENS;
return $re;
}
my @lines = map { make_line(); } 1 .. LINES;
my $sep = make_sep();
my $lre = make_line_re();
timethese(-3,
{
split => sub {
my @a;
@a = split(/$sep/, $_) for @lines;
},
re_split => sub {
my @a;
@a = /\S+/g for @lines;
},
re => sub {
my @a;
@a = /$lre/ for @lines;
}});
---------
it is possible to determine that split or re_split will be faster
depending on which has to 'regex' more (token length vs separator
length). The speed of the 'mask regex' (I also tried this with using a
suitable number of dots instead of {n} expression which was a lot worse)
only depends on the total length of an input line and it is usually
faster than the regex split, ie, if that's faster than splite, the mask
re will be faster, too, and if split is waster, both regexes will
usually be slower.
------------------------------
Date: Mon, 2 Feb 2015 20:37:33 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Why are these brackets necessary?
Message-Id: <slrnmcvkft.l6l.hjp-usenet3@hrunkner.hjp.at>
On 2015-02-02 09:06, Tim McDaniel <tmcd@panix.com> wrote:
> In article <slrnmcigap.efb.hjp-usenet3@hrunkner.hjp.at>,
> Peter J. Holzer <hjp-usenet3@hjp.at> wrote:
>>the same as for birthdays and anniversaries: 1 o'clock is at the end
>>of the first hour after midnight or noon, just like your first
>>birthday is at the end of the first year of your life.
>
> It's good to remember that that's current Western custom, but not
> necessarily true around the world.
We were talking about an oddity of the English language, so I hope it
was clear that any explanations/theories I offered are not generalizable
outside of the English culture.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpat. -- Ralph Babel
------------------------------
Date: Tue, 03 Feb 2015 19:20:33 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: Why are these brackets necessary?
Message-Id: <mas358$b1c$2@dont-email.me>
On 2/2/2015 00:46, Henry Law wrote:
> On 02/02/15 03:48, Martin Eastburn wrote:
>> Meridian Midnight hour
>
> Doesn't scan!
I'm gonna wait 'til the midnight hour
That's when my love comes tumbling down
I'm gonna wait 'til the midnight hour
When there's no one else around
I'm gonna take you girl and hold you
And do all things I told you in the midnight hour
Yes I am, yes I am
One more thing I just wanna say right here
I'm gonna wait till the stars come out
And see them twinkle in your eyes
I'm gonna wait 'till the midnight hour
That's when my love begins to shine
You're the only girl I know
That can really love me so in the midnight hour
Oh yeah, in the midnight hour
Yeah, alright, play it for me one time now
------------------------------
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 4362
***************************************
