[32380] in Perl-Users-Digest
Perl-Users Digest, Issue: 3647 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 23 14:09:24 2012
Date: Fri, 23 Mar 2012 11:09:05 -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 Fri, 23 Mar 2012 Volume: 11 Number: 3647
Today's topics:
Re: Problem with splitting data (Tim McDaniel)
Re: Problem with splitting data (Tim McDaniel)
Re: Problem with splitting data <rweikusat@mssgmbh.com>
Re: Problem with splitting data <rweikusat@mssgmbh.com>
Re: Problem with splitting data <uri@stemsystems.com>
Re: Problem with splitting data <uri@stemsystems.com>
Re: Problem with splitting data <rvtol+usenet@xs4all.nl>
Re: Problem with splitting data <ben@morrow.me.uk>
Re: yet another question about numbers and strings (hymie!)
Re: yet another question about numbers and strings <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 21 Mar 2012 18:32:20 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Problem with splitting data
Message-Id: <jkd6rj$26d$1@reader1.panix.com>
In article <87vclxsyl2.fsf@stemsystems.com>,
Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
> TM> I hadn't heard about File::Slurp.
>
>the module name is File::Slurp. ... you haven't heard of it?
I must apologize to the newsgroup. There seems to be a fault in my
keyboard. Several people are able to quote what I wrote but
apparently are unable to read it. Perhaps I have to set the proper
permission bits on the ASCII characters? It occurred elsewhere in
this article, where I wrote
> TM> I think it's simpler.
followed by 5 paragraphs of explanation of precisely why I think it is
simpler -- including that I cannot use that of which I am unaware --
receiving the reply
>how can you think 4 ops with a special var, a missing open line,
>etc. is simpler?
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 21 Mar 2012 19:03:53 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Problem with splitting data
Message-Id: <jkd8mp$je7$1@reader1.panix.com>
Tim McDaniel <tmcd@panix.com> wrote:
>> TM> I think it's simpler.
>
>followed by 5 paragraphs of explanation of precisely why I think it is
>simpler -- including that I cannot use that of which I am unaware --
Wow, that's so badly written! I meant that, *as of two days ago*,
I didn't know about File::Slurp but did have a vague memory that there
is a special variable that helps with that. So, *at that time*,
I could only have called the raw-Perl method "simpler" for lack of
alternatives.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 21 Mar 2012 20:26:55 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Problem with splitting data
Message-Id: <87ehslzomo.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
[...]
>>how can you think 4 ops with a special var, a missing open line,
>>etc. is simpler?
The answer to that is still that something which is composed of
several hundreds of lines of code (which all have to pass through the
compiler) does not suddenly become 'simple' wrt a single line of code
just because these hundreds of lines of code reside in some file no
one usually looks at.
Apart from that, the 'simple' was supposed to refer to the last bit of
code I posted here which provided a complete 'slurp solution' based on
passing a filename to some subroutine. That was a subroutine and
included the code for opening this file and consequently, code dealing
with an already opened file, as in the current example, is simpler
than that (since it doesn't have to open the file).
------------------------------
Date: Wed, 21 Mar 2012 20:28:27 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Problem with splitting data
Message-Id: <87aa39zok4.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> Tim McDaniel <tmcd@panix.com> wrote:
>>> TM> I think it's simpler.
>>
>>followed by 5 paragraphs of explanation of precisely why I think it is
>>simpler -- including that I cannot use that of which I am unaware --
>
> Wow, that's so badly written! I meant that, *as of two days ago*,
> I didn't know about File::Slurp but did have a vague memory that there
> is a special variable that helps with that. So, *at that time*,
> I could only have called the raw-Perl method "simpler" for lack of
> alternatives.
File::Slurp is also a 'raw Perl method', just a much more complicated
one than anything I've ever employed for actually reading data from a
file or filehandle since 1996 or so (when I started to use Perl).
------------------------------
Date: Wed, 21 Mar 2012 16:44:18 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Problem with splitting data
Message-Id: <87mx79smzh.fsf@stemsystems.com>
>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
RW> tmcd@panix.com (Tim McDaniel) writes:
RW> [...]
>>> how can you think 4 ops with a special var, a missing open line,
>>> etc. is simpler?
RW> The answer to that is still that something which is composed of
RW> several hundreds of lines of code (which all have to pass through the
RW> compiler) does not suddenly become 'simple' wrt a single line of code
RW> just because these hundreds of lines of code reside in some file no
RW> one usually looks at.
then you never use any modules? the concept is to make the caller's code
simpler. you can't use that silly argument and use any modules where you
use one call vs the source of the module. so get off that high horse.
RW> Apart from that, the 'simple' was supposed to refer to the last
RW> bit of code I posted here which provided a complete 'slurp
RW> solution' based on passing a filename to some subroutine. That was
RW> a subroutine and included the code for opening this file and
RW> consequently, code dealing with an already opened file, as in the
RW> current example, is simpler than that (since it doesn't have to
RW> open the file).
and it still is slower by a long shot. have you even tried to do a
benchmark? oops. it is including in the distro but you won't even
download that (other than to make silly useless comments).
and opening the file is part of the whole issue. as well as reading it
with a clunky idiom. so if you are ever posting in the future and don't
show hand written code vs any module use, i am allowed to call you out
on it? jeez. you make santorum look smart.
uri
------------------------------
Date: Wed, 21 Mar 2012 16:48:20 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Problem with splitting data
Message-Id: <87iphxsmsr.fsf@stemsystems.com>
>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
RW> tmcd@panix.com (Tim McDaniel) writes:
>> Tim McDaniel <tmcd@panix.com> wrote:
TM> I think it's simpler.
>>>
>>> followed by 5 paragraphs of explanation of precisely why I think it is
>>> simpler -- including that I cannot use that of which I am unaware --
>>
>> Wow, that's so badly written! I meant that, *as of two days ago*,
>> I didn't know about File::Slurp but did have a vague memory that there
>> is a special variable that helps with that. So, *at that time*,
>> I could only have called the raw-Perl method "simpler" for lack of
>> alternatives.
RW> File::Slurp is also a 'raw Perl method', just a much more complicated
RW> one than anything I've ever employed for actually reading data from a
RW> file or filehandle since 1996 or so (when I started to use Perl).
ever use LWP? it is also pure RAW perl. i am sure you can whip up a 1
liner to do that with socket calls. please do so as LWP is so large it
must be useless. also make sure you only code up the minimum necessary
to fetch a page with no options or variations or whatever. that is also
what your own code does. and your mention of line counts is silly as
well as much of the module is for other things than just read_file. oh,
i am sure you counted up all the lines accurately to come up with your
numbers. your dislike me so my module must be bad. have fun with all the
other cpan authors. i am sure many of them you wouldn't like at all
given that there are thousands. you can't possibly like thousands of
perl authors. just learn to choose which ones by getting to know them
all.
your rectum is occupied by your cranium.
uri
------------------------------
Date: Thu, 22 Mar 2012 01:51:41 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Problem with splitting data
Message-Id: <4f6a779d$0$6864$e4fe514c@news2.news.xs4all.nl>
On 2012-03-21 04:13, Uri Guttman wrote:
> RW> In this case, the 'pure Perl' equivalent is even simpler. Assuming
> RW> that keeping the previous value of $/ actually matters (which it very
> RW> likely doesn't), it would be
>
> RW> my $data = do { local $/;<$binfile>; };
>
> simpler? for some wacko definition of simpler. it uses a do block, a
> local call (rare these days), a special variable AND a<> op. plus the
> open call you don't show. you don't even know the proper idiom to bypass
> the open call.
And it uses twice the memory. To prevent that, write it like:
my $data; { local $/; $data = <$binfile> }
--
Ruud
------------------------------
Date: Thu, 22 Mar 2012 01:08:15 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Problem with splitting data
Message-Id: <vkaq39-1rc2.ln1@anubis.morrow.me.uk>
Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
>
[slurping]
>
> And it uses twice the memory. To prevent that, write it like:
>
> my $data; { local $/; $data = <$binfile> }
It's terribly hard to avoid copying in Perl, and not usually worth it.
If 'twice the memory' is too much, you should be looking for a different
algorithm.
Ben
------------------------------
Date: 22 Mar 2012 17:15:55 GMT
From: hymie@lactose.homelinux.net (hymie!)
Subject: Re: yet another question about numbers and strings
Message-Id: <4f6b5e4b$0$7538$882e7ee2@usenet-news.net>
In our last episode, the evil Dr. Lacto had captured our hero,
Ben Morrow <ben@morrow.me.uk>, who said:
>
>Quoth hymie@lactose.homelinux.net (hymie!):
>>
>> I have an MSSQL database. It includes a field for ID numbers
>> that are about 18 digits long.
><snip>
>>
>> Sadly, I end up with a response that looks like this:
>> ID bigint 8 not null
>> 9.21474030305498e+18
>At a further guess: you are using DBD::Sybase version 1.09 or older? The
>current version has this comment in dbdimp.c:
I'm now running DBD::Sybase 1.14 , and I'm still having the same
problem.
ID bigint 8 not null
9.21814636810375e+18
--hymie! http://lactose.homelinux.net/~hymie hymie@lactose.homelinux.net
-------------------------------------------------------------------------------
------------------------------
Date: Thu, 22 Mar 2012 22:16:50 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: yet another question about numbers and strings
Message-Id: <ivks39-4vu2.ln1@anubis.morrow.me.uk>
Quoth hymie@lactose.homelinux.net (hymie!):
> In our last episode, the evil Dr. Lacto had captured our hero,
> Ben Morrow <ben@morrow.me.uk>, who said:
> >
> >Quoth hymie@lactose.homelinux.net (hymie!):
> >>
> >> I have an MSSQL database. It includes a field for ID numbers
> >> that are about 18 digits long.
> ><snip>
> >>
> >> Sadly, I end up with a response that looks like this:
> >> ID bigint 8 not null
> >> 9.21474030305498e+18
>
> >At a further guess: you are using DBD::Sybase version 1.09 or older? The
> >current version has this comment in dbdimp.c:
>
> I'm now running DBD::Sybase 1.14 , and I'm still having the same
> problem.
>
> ID bigint 8 not null
> 9.21814636810375e+18
Odd. What do you get from this?
use DBI;
use Devel::Peek;
my $dbh = DBI->connect("dbi:Sybase:...", ...);
my $bigint = $dbh->selectcol_arrayref(<<SQL);
SELECT bigint FROM table WHERE ...
SQL
Dump $bigint;
You will need to adjust the connect call and the SQL, obviously: the
point is to select just one row with one bigint column in it, with as
little between you and the DBI as possible, to get a clear picture of
exactly what the database is returning.
Ben
------------------------------
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 3647
***************************************
