[32655] in Perl-Users-Digest
Perl-Users Digest, Issue: 3931 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 24 09:09:28 2013
Date: Wed, 24 Apr 2013 06:09:07 -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 Wed, 24 Apr 2013 Volume: 11 Number: 3931
Today's topics:
Ascertaing uploaded file size <Joey@still_Learning.invalid>
Re: Ascertaing uploaded file size <ben@morrow.me.uk>
Re: Ascertaing uploaded file size <Joey@still_Learning.invalid>
Re: Ascertaing uploaded file size <justin.1303@purestblue.com>
Re: Ascertaing uploaded file size <ben@morrow.me.uk>
Re: Ascertaing uploaded file size <justin.1303@purestblue.com>
HTML to MHT conversion programmatically (Vincent =?iso-8859-1?Q?Bela=EFche?=)
Re: HTML to MHT conversion programmatically <ben@morrow.me.uk>
Re: HTML to MHT conversion programmatically (Vincent =?iso-8859-1?Q?Bela=EFche?=)
Re: Is Perl dying or not? domestuff@gmail.com
Re: Is Perl dying or not? <justin.1303@purestblue.com>
Re: Is Perl dying or not? <rweikusat@mssgmbh.com>
Loading modules from DBI? domestuff@gmail.com
Re: Loading modules from DBI? <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 23 Apr 2013 10:10:21 -0700
From: "Joey@still_Learning.invalid" <Joey@still_Learning.invalid>
Subject: Ascertaing uploaded file size
Message-Id: <agedn8t746tormb69b08i63f4u31tms02q@4ax.com>
I'm uploading multiple files (HTML5) to an internet server. I wish to
verify that the files were properly received. I'm expecting to compare
file sizes. I have the file size of the file being uploaded, and I get the
size of the file on the server using -s /path-to-server-file/$filename. No
problems.
My code snippet is:
for (my $i=0;$i<$imgCnt;$i++) {
$filename = $uploadFiles[$i];
$filesize = -s $filename;
# $imgCnt = number of images selected for upload
# @uploadFiles is an array of filenames selected for upload
open (UPLOADFILE, ">$filePath/$filename") or die "Can't Open $!";
binmode UPLOADFILE;
while (<$upload_filehandle>) {
print UPLOADFILE;
}
#Compare file size
if (-e $filename) {
$srvrsize = -s $filename;
if ($srvrsize == $filesize) {
$numImagesReceived++;
}
}
else {print "$filename does not exist on server<br>\n";}
close UPLOADFILE or die "Can't Close. $!";
}
My question: Is the file size on the server the actual size of the file on
the server, or is it space reserved for the original file that's reported
at 'open (UPLOADFILE, ">$filePath/$filename")?'
The above code supposedly checks each file as it's being uploaded. Would
it be more appropriate to compare file sizes after all files have been
uploaded, as follows?
...
...
close UPLOADFILE or die "Can't Close. $!";
}
opendir DH,$filePath or die "Can't opendir $filePath $!";
for (my $i = 0; $i < $imgCnt; $i++) {
$filename = $uploadFiles[$ii];
if (-e $filename) {
$srvrsize = -s $filename;
if ($srvrsize == $filesize) {
$numImagesReceived++; $k++;
}
else error
...
TIA,
--
Joey
------------------------------
Date: Tue, 23 Apr 2013 23:48:46 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Ascertaing uploaded file size
Message-Id: <enfj4a-um.ln1@anubis.morrow.me.uk>
Quoth "Joey@still_Learning.invalid" <Joey@still_Learning.invalid>:
> I'm uploading multiple files (HTML5) to an internet server. I wish to
> verify that the files were properly received. I'm expecting to compare
> file sizes. I have the file size of the file being uploaded, and I get the
> size of the file on the server using -s /path-to-server-file/$filename. No
> problems.
OK, let's start at the beginning. Where is this Perl code running, on
the client or on the server? How is it being invoked? I am going to
assume it's running on the server as some sort of CGI-alike, but you
need to be clear about things like that.
>
> My code snippet is:
>
> for (my $i=0;$i<$imgCnt;$i++) {
> $filename = $uploadFiles[$i];
for my $filename (@uploadFiles) {
You do have
use warnings;
use strict;
at the top of every Perl file, right?
> $filesize = -s $filename;
Um, this makes no sense. If the file is already there, why do you need
code to upload it? And if it's not there, how is -s supposed to find its
size?
Where exactly are these files coming from? What does @uploadFiles
contain?
> # $imgCnt = number of images selected for upload
> # @uploadFiles is an array of filenames selected for upload
>
> open (UPLOADFILE, ">$filePath/$filename") or die "Can't Open $!";
open(my $UPLOADFILE, ">", "$filePath/$filename") or die ...;
You can also add
use autodie;
to 'strict' and 'warnings' and perl will do the 'or die' for you.
Where does $filePath come from? Is this supposed to be the same file as
you statted earlier, because it's not (unless $filePath is ".")? If the
file is already on the server why do you need to recreate it?
> binmode UPLOADFILE;
> while (<$upload_filehandle>) {
> print UPLOADFILE;
> }
If this is (or might be) a binary file then reading it by lines is
unlikely to be sensible. You want to read fixed-size blocks instead; the
simplest way to do this (though not the easiest to understand if you're
unfamiliar with Perl) is to put something like
local $/ = \8192;
before the while loop. See perldoc perlvar and perldoc -f local for an
explanation of what that does. Alternatively, you can use read().
More generally: what on Earth are you doing? Where does
$upload_filehandle come from?
> #Compare file size
> if (-e $filename) {
What is this test supposed to accomplish? The -s test before would have
returned undef if $filename didn't exist; are you expecting it might
have been deleted in the meantime?
> $srvrsize = -s $filename;
> if ($srvrsize == $filesize) {
Again, you've just run -s twice on the same file, a short time apart.
Under what circumstances are you expecting the results to be different
from each other? (And, again, this is *not* the file you've just
written.)
> $numImagesReceived++;
> }
> }
> else {print "$filename does not exist on server<br>\n";}
> close UPLOADFILE or die "Can't Close. $!";
> }
>
> My question: Is the file size on the server the actual size of the file on
> the server, or is it space reserved for the original file that's reported
> at 'open (UPLOADFILE, ">$filePath/$filename")?'
That question makes no sense. How on earth could the open() reserve
space when you haven't told it how big the file might be? Yes, the file
size on the server is the file size on the server. This may or may not
be the same as the file size on the client, but in order to check that
you would have to know what the client thought the file size was...
> The above code supposedly checks each file as it's being uploaded. Would
> it be more appropriate to compare file sizes after all files have been
> uploaded, as follows?
If you had been checking the size of the file you were writing to (which
you aren't), then it's likely that size won't be correct until after you
call close(). As far as the comparing goes, I'm still entirely unclear
what you think you are comparing to what...
> ...
> ...
> close UPLOADFILE or die "Can't Close. $!";
> }
> opendir DH,$filePath or die "Can't opendir $filePath $!";
Um, wot?
> for (my $i = 0; $i < $imgCnt; $i++) {
> $filename = $uploadFiles[$ii];
This is why you use strict...
Ben
------------------------------
Date: Tue, 23 Apr 2013 17:01:59 -0700
From: "Joey@still_Learning.invalid" <Joey@still_Learning.invalid>
Subject: Re: Ascertaing uploaded file size
Message-Id: <c28en8tbs9ggk4kqrghc3l38rv7dtf3j93@4ax.com>
Ben Morrow wrote:
>
>Quoth "Joey@still_Learning.invalid" <Joey@still_Learning.invalid>:
>> I'm uploading multiple files (HTML5) to an internet server. I wish to
>> verify that the files were properly received. I'm expecting to compare
>> file sizes. I have the file size of the file being uploaded, and I get the
>> size of the file on the server using -s /path-to-server-file/$filename. No
>> problems.
>
>OK, let's start at the beginning. Where is this Perl code running, on
>the client or on the server? How is it being invoked? I am going to
>assume it's running on the server as some sort of CGI-alike, but you
>need to be clear about things like that.
>
>>
>> My code snippet is:
>>
>> for (my $i=0;$i<$imgCnt;$i++) {
>> $filename = $uploadFiles[$i];
>
> for my $filename (@uploadFiles) {
>
>You do have
>
> use warnings;
> use strict;
>
>at the top of every Perl file, right?
>
>> $filesize = -s $filename;
>
>Um, this makes no sense. If the file is already there, why do you need
>code to upload it? And if it's not there, how is -s supposed to find its
>size?
>
>Where exactly are these files coming from? What does @uploadFiles
>contain?
>
>> # $imgCnt = number of images selected for upload
>> # @uploadFiles is an array of filenames selected for upload
>>
>> open (UPLOADFILE, ">$filePath/$filename") or die "Can't Open $!";
>
> open(my $UPLOADFILE, ">", "$filePath/$filename") or die ...;
>
>You can also add
>
> use autodie;
>
>to 'strict' and 'warnings' and perl will do the 'or die' for you.
>
>Where does $filePath come from? Is this supposed to be the same file as
>you statted earlier, because it's not (unless $filePath is ".")? If the
>file is already on the server why do you need to recreate it?
>
>> binmode UPLOADFILE;
>> while (<$upload_filehandle>) {
>> print UPLOADFILE;
>> }
>
>
>If this is (or might be) a binary file then reading it by lines is
>unlikely to be sensible. You want to read fixed-size blocks instead; the
>simplest way to do this (though not the easiest to understand if you're
>unfamiliar with Perl) is to put something like
>
> local $/ = \8192;
>
>before the while loop. See perldoc perlvar and perldoc -f local for an
>explanation of what that does. Alternatively, you can use read().
>
>More generally: what on Earth are you doing? Where does
>$upload_filehandle come from?
>
>> #Compare file size
>> if (-e $filename) {
>
>What is this test supposed to accomplish? The -s test before would have
>returned undef if $filename didn't exist; are you expecting it might
>have been deleted in the meantime?
>
>> $srvrsize = -s $filename;
>> if ($srvrsize == $filesize) {
>
>Again, you've just run -s twice on the same file, a short time apart.
>Under what circumstances are you expecting the results to be different
>from each other? (And, again, this is *not* the file you've just
>written.)
>
>> $numImagesReceived++;
>> }
>> }
>> else {print "$filename does not exist on server<br>\n";}
>> close UPLOADFILE or die "Can't Close. $!";
>> }
>>
>> My question: Is the file size on the server the actual size of the file on
>> the server, or is it space reserved for the original file that's reported
>> at 'open (UPLOADFILE, ">$filePath/$filename")?'
>
>That question makes no sense. How on earth could the open() reserve
>space when you haven't told it how big the file might be? Yes, the file
>size on the server is the file size on the server. This may or may not
>be the same as the file size on the client, but in order to check that
>you would have to know what the client thought the file size was...
>
>> The above code supposedly checks each file as it's being uploaded. Would
>> it be more appropriate to compare file sizes after all files have been
>> uploaded, as follows?
>
>If you had been checking the size of the file you were writing to (which
>you aren't), then it's likely that size won't be correct until after you
>call close(). As far as the comparing goes, I'm still entirely unclear
>what you think you are comparing to what...
>
>> ...
>> ...
>> close UPLOADFILE or die "Can't Close. $!";
>> }
>> opendir DH,$filePath or die "Can't opendir $filePath $!";
>
>Um, wot?
>
>> for (my $i = 0; $i < $imgCnt; $i++) {
>> $filename = $uploadFiles[$ii];
>
>This is why you use strict...
>
Thanks for the reply. I'm sorry I presumed that various strings and
variables origins weren't identified. I would think that in looking at the
basic methodology, one would not have to detail everything.
At any rate, I decided it was safest to test files after all files were
uploaded.
Thanks again.
--
Joey
------------------------------
Date: Wed, 24 Apr 2013 09:18:08 +0100
From: Justin C <justin.1303@purestblue.com>
Subject: Re: Ascertaing uploaded file size
Message-Id: <03hk4a-qo5.ln1@zem.masonsmusic.co.uk>
On 2013-04-24, Joey@still_Learning.invalid <Joey@still_Learning.invalid> wrote:
> Thanks for the reply. I'm sorry I presumed that various strings and
> variables origins weren't identified. I would think that in looking at the
> basic methodology, one would not have to detail everything.
>
> At any rate, I decided it was safest to test files after all files were
> uploaded.
I'm not certain that helps you. Doesn't the reported size of the file
depend on such things as the file system on the remote machine, and
the block-size used?
I would have thought the best way to test files are the same (and you
need them to be the same don't you, not just the same size?) would be
to use md5sum - this may be overkill, others may suggest a better
way.
I think, what I would do (with my limited perl skillset) is to upload
all the files and have a program on the remote machine calculate the
md5sum of the files and store that in a file. I DL that file and
compare the md5sums with ones calculated locally.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 24 Apr 2013 10:43:49 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Ascertaing uploaded file size
Message-Id: <l3mk4a-p8o.ln1@anubis.morrow.me.uk>
Quoth Justin C <justin.1303@purestblue.com>:
> On 2013-04-24, Joey@still_Learning.invalid <Joey@still_Learning.invalid> wrote:
> > Thanks for the reply. I'm sorry I presumed that various strings and
> > variables origins weren't identified. I would think that in looking at the
> > basic methodology, one would not have to detail everything.
> >
> > At any rate, I decided it was safest to test files after all files were
> > uploaded.
>
> I'm not certain that helps you. Doesn't the reported size of the file
> depend on such things as the file system on the remote machine, and
> the block-size used?
No. The amount of disk space used does, but (under normal OSen) files
have a size which depends only on how much data has been written to
them.
> I would have thought the best way to test files are the same (and you
> need them to be the same don't you, not just the same size?) would be
> to use md5sum - this may be overkill, others may suggest a better
> way.
I get the impression (though this is incredibly unclear) that the OP is
not in control of the client, and this is a piece of server-side code to
accept an upload from a web browser. While it is possible (at least with
really modern browsers) to MD5 or SHA1 a file before uploading it, using
newish JavaScript APIs for reading the files, the OP hasn't given me the
impression that is what he is trying to do.
> I think, what I would do (with my limited perl skillset) is to upload
> all the files and have a program on the remote machine calculate the
> md5sum of the files and store that in a file. I DL that file and
> compare the md5sums with ones calculated locally.
Well, in that situation I'd just use rsync...
Ben
------------------------------
Date: Wed, 24 Apr 2013 12:44:18 +0100
From: Justin C <justin.1303@purestblue.com>
Subject: Re: Ascertaing uploaded file size
Message-Id: <i5tk4a-7e9.ln1@zem.masonsmusic.co.uk>
On 2013-04-24, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth Justin C <justin.1303@purestblue.com>:
>> On 2013-04-24, Joey@still_Learning.invalid <Joey@still_Learning.invalid> wrote:
>> > Thanks for the reply. I'm sorry I presumed that various strings and
>> > variables origins weren't identified. I would think that in looking at the
>> > basic methodology, one would not have to detail everything.
>> >
>> > At any rate, I decided it was safest to test files after all files were
>> > uploaded.
>>
>> I'm not certain that helps you. Doesn't the reported size of the file
>> depend on such things as the file system on the remote machine, and
>> the block-size used?
>
> No. The amount of disk space used does, but (under normal OSen) files
> have a size which depends only on how much data has been written to
> them.
Oh, OK. Thank you for the clarification.
>> I think, what I would do (with my limited perl skillset) is to upload
>> all the files and have a program on the remote machine calculate the
>> md5sum of the files and store that in a file. I DL that file and
>> compare the md5sums with ones calculated locally.
>
> Well, in that situation I'd just use rsync...
Of course, you *could* just do that ;-)
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 24 Apr 2013 08:24:10 +0200
From: vincent.belaiche@gmail.com (Vincent =?iso-8859-1?Q?Bela=EFche?=)
Subject: HTML to MHT conversion programmatically
Message-Id: <80haiwe99x.fsf@gmail.com>
Hello,
I am a newbie in Perl. I have written only a few simples scripts, but
that could make me feel the power of the language.
Now, I am looking for some way to convert an HTML file and the
dependency thereof into an MHT archive. All the files are local on my
hard drive. I looked for that on the internet, in vain.
I thought that Perl is probably the best language to make it, and I
wondered whether that already exists or not. I could not find anything
such thing on the CPAN --- well there are Email::MIME or MIME::Entity
and Email::Sender for MIME encoding, but I am not sure whether they are
flexible enough to do an MHT archive, and I must admit that I am not
expert in MHT archive format. Also I found quite a few HTML parsers, but
I don't know which one is the most suited.
In a nutshell, there seems to be already all the building blocks to make
it in a few lines of code, however nothing ready to work off-the-shelf.
Any feedback or help is welcome.
Vincent.
------------------------------
Date: Wed, 24 Apr 2013 10:12:22 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: HTML to MHT conversion programmatically
Message-Id: <m8kk4a-v0o.ln1@anubis.morrow.me.uk>
Quoth vincent.belaiche@gmail.com (Vincent =?iso-8859-1?Q?Bela=EFche?=):
>
> Now, I am looking for some way to convert an HTML file and the
> dependency thereof into an MHT archive. All the files are local on my
> hard drive. I looked for that on the internet, in vain.
>
> I thought that Perl is probably the best language to make it, and I
> wondered whether that already exists or not. I could not find anything
> such thing on the CPAN --- well there are Email::MIME or MIME::Entity
> and Email::Sender for MIME encoding, but I am not sure whether they are
> flexible enough to do an MHT archive, and I must admit that I am not
> expert in MHT archive format.
The MHT format is just a multipart/related MIME entity, isn't it?
Creating one of those with one of the MIME modules should be entirely
straightforward. In this case I would probably recommend MIME::Entity
rather than one of the Email:: modules, because it will let you leave
the attached files as files and convert them on the fly when writing out
the completed email.
> Also I found quite a few HTML parsers, but
> I don't know which one is the most suited.
I would have thought HTML::LinkExtor is what you want in this case,
since all you need to do is find which additional files need archiving.
> In a nutshell, there seems to be already all the building blocks to make
> it in a few lines of code, however nothing ready to work off-the-shelf.
So try to write something, and, if you get stuck, post again.
Ben
------------------------------
Date: Wed, 24 Apr 2013 15:02:39 +0200
From: vincent.belaiche@gmail.com (Vincent =?iso-8859-1?Q?Bela=EFche?=)
Subject: Re: HTML to MHT conversion programmatically
Message-Id: <80obd4nksw.fsf@gmail.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth vincent.belaiche@gmail.com (Vincent =?iso-8859-1?Q?Bela=EFche?=):
>>
>> Now, I am looking for some way to convert an HTML file and the
>> dependency thereof into an MHT archive. All the files are local on my
>> hard drive. I looked for that on the internet, in vain.
>>
>> I thought that Perl is probably the best language to make it, and I
>> wondered whether that already exists or not. I could not find
>> anything such thing on the CPAN --- well there are Email::MIME or
>> MIME::Entity and Email::Sender for MIME encoding, but I am not sure
>> whether they are flexible enough to do an MHT archive, and I must
>> admit that I am not expert in MHT archive format.
>
> The MHT format is just a multipart/related MIME entity, isn't it?
> Creating one of those with one of the MIME modules should be entirely
> straightforward. In this case I would probably recommend MIME::Entity
> rather than one of the Email:: modules, because it will let you leave
> the attached files as files and convert them on the fly when writing
> out the completed email.
>
>> Also I found quite a few HTML parsers, but I don't know which one is
>> the most suited.
>
> I would have thought HTML::LinkExtor is what you want in this case,
> since all you need to do is find which additional files need
> archiving.
>
>> In a nutshell, there seems to be already all the building blocks to
>> make it in a few lines of code, however nothing ready to work
>> off-the-shelf.
>
> So try to write something, and, if you get stuck, post again.
>
> Ben
Thank you so much with the quick feedback. I will try that. Whether I am
stuck or not I will anyway make it public --- because writing functional
code, does not mean that the code is well written.
VBR,
Vincent.
------------------------------
Date: Tue, 23 Apr 2013 06:39:34 -0700 (PDT)
From: domestuff@gmail.com
Subject: Re: Is Perl dying or not?
Message-Id: <07a660e2-80ad-4ab6-80be-5b819c66fe1b@googlegroups.com>
On Friday, October 19, 2012 10:43:53 PM UTC-4, Ignoramus7380 wrote:
<SNIP>
>=20
>=20
> So this is not some kind of "perl suxxx" troll. Rather, I want to ask
>=20
> if perl will continue to be a viable ecosystem. I have a lot invested
>=20
> in and relying on perl and I have a vested interest in having perl to
>=20
> be a great platform.
>=20
<SNIP>=20
IMHO, perl is proof that there is such a thing as a language that is too fl=
exible. There are a LOT of free perl scripts on the Internet that are prett=
y terribly written, and so at first glance, some people get an impression o=
f perl that it is kindof kludgy. The truth is that it has been adopted by p=
eople with so many different programming backgrounds, that perl tends to ha=
ve dialects within itself.=20
Many got tired of trying to bend their minds around this and ran to python =
for structure. Many never automated their way around perls particularly ver=
bose object oriented syntax, and ran to Ruby.=20
In practice, perl is very good for writing tools that make writing perl cle=
an and fast. But you have to get past the fact that you _should_ write perl=
like perl, and NOT like BASIC, C, Java, etc. etc. etc. even though that is=
what brought you to perl in the first place.=20
The hardest thing about perl, is learning what good perl design is, because=
it is so easy to misbehave and get away with it.=20
=20
My 2 cents.=20
------------------------------
Date: Tue, 23 Apr 2013 15:04:03 +0100
From: Justin C <justin.1303@purestblue.com>
Subject: Re: Is Perl dying or not?
Message-Id: <jvgi4a-ujn.ln1@zem.masonsmusic.co.uk>
On 2013-04-23, domestuff@gmail.com <domestuff@gmail.com> wrote:
[snip]
>
> My 2 cents.
This thread has passed on, it is no more, it has ceased to be.
It has expired and gone to meet its maker. It is bereft of life,
it rests in peace. It has kicked the bucket and shuffled off
its mortal coil. If you hadn't ressurected it it would be off
with the choir invisible. This is an ex-thread. It died sometime
last year.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Tue, 23 Apr 2013 19:46:45 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Is Perl dying or not?
Message-Id: <8761zdaxuy.fsf@sapphire.mobileactivedefense.com>
domestuff@gmail.com writes:
> On Friday, October 19, 2012 10:43:53 PM UTC-4, Ignoramus7380 wrote:
[...]
>> So this is not some kind of "perl suxxx" troll. Rather, I want to ask
>> if perl will continue to be a viable ecosystem. I have a lot invested
>> in and relying on perl and I have a vested interest in having perl to
>> be a great platform.
[...]
> IMHO, perl is proof that there is such a thing as a language that is
> too flexible. There are a LOT of free perl scripts on the Internet
> that are pretty terribly written, and so at first glance, some
> people get an impression of perl that it is kindof kludgy. The truth
> is that it has been adopted by people with so many different
> programming backgrounds, that perl tends to have dialects within
> itself.
A splendid non-sequitur: There is a real lot of 'terribly written'
code in any programming language 'on the internet': What precisely
constitutes 'terribly written' is very much a matter of opinion (and
'opinion' doesn't necessarily mean 'reasoned opinion' here) and there
are a lot more bad programmers than good programmers, as with anything
else (=> Sturgeon's relevation). Even if there was more 'terribly
written free Perl code' on the internet, that would - at best - be a
hint (not a proof) that Perl is a lot easier to use than less
frequently abused languages. Also, all programming languages have
'dialects within themselves', just like all other languages.
> Many got tired of trying to bend their minds around this and ran to
> python for structure.
What's this supposed to mean?
> Many never automated their way around perls
> particularly verbose object oriented syntax, and ran to Ruby.
Or this?
I've been using Perl extensively since about 1995 without encountering
any 'particularly verbose object oriented syntax' which had warranted
'automating around it'. In fact, I've been using objects based on
anonymous arrays and manual slot allocation until fairly recently and
the only reason why I wrote (and published) some code to automate that
was to demonstrate how little is actually needed to turn the existing
'Perl OO' facilities into a complete OO-system, in contrast to
'everything anybody else ever came up with plus two kitchen sinks to be
on the safe side' approaches a la "Der Elch ist los!".
> In practice, perl is very good for writing tools that make writing
> perl clean and fast.
What does this mean?
> But you have to get past the fact that you _should_ write perl like
> perl, and NOT like BASIC, C, Java, etc. etc. etc. even though that
> is what brought you to perl in the first place.
Anything perl can compile and which has the intended effect upon
execution is 'Perl written like perl': Like any language, it can
accomodate different styles of writing: The mere fact that a text
someone else wrote reminds you of a different text written in another
lanuage is not an indicator of any particular quality. And people can
have different reasoned opinions on 'style issues': Eg, to me, a
'regex' is something delimited by forward-slashes and the occasional
forward slash inside a regex needs to be quoted. That's the way all
other tools I regularly use offering such features work and -
conveniently for me - Perl (can) work(s) in the same way.
Other people are convinced that 'avoiding the occasional quoted
delimiter' is sufficiently important that each regex should utilize a
(set of) delimiter character(s) which has been individually chosen to
avoid the need to quote anything. To me, this just looks needlessly
noisy ("What's the delimiter this time ???") and since it won't teach
awk, ed and sed new tricks, anyway, why bother with that?
> The hardest thing about perl, is learning what good perl design is,
> because it is so easy to misbehave and get away with it.
You seem to be fixated on syntactical issues to a degree I really
don't understand ...
------------------------------
Date: Tue, 23 Apr 2013 06:57:39 -0700 (PDT)
From: domestuff@gmail.com
Subject: Loading modules from DBI?
Message-Id: <4aff2645-04fb-4caf-ab1d-a656a26855b4@googlegroups.com>
Howdy,
I've got a bunch of templates which also happen to be perl objects. I would like to stick them in postgresql and then 'require' or 'use' at runtime after extracting them as text from the database.
What is the best way to do this?
Thanks in advance!
------------------------------
Date: Tue, 23 Apr 2013 16:00:48 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Loading modules from DBI?
Message-Id: <0aki4a-6dt2.ln1@anubis.morrow.me.uk>
Quoth domestuff@gmail.com:
>
> I've got a bunch of templates which also happen to be perl objects. I
> would like to stick them in postgresql and then 'require' or 'use' at
> runtime after extracting them as text from the database.
>
> What is the best way to do this?
Do you mean something other than eval? If so, you will have to explain
what you want.
If you're asking how to serialise them in the first place, you can use
Data::Dumper or D::D::Streamer, though it may be better to use Storable
and put the stored value in a bytea rather than a text column.
If these objects have non-trivial connections to other objects you will
need to think about how you're going to serialise that information and
set them up again afterwards. Again, if you want help with that you will
need to explain a bit more about what you're doing.
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 3931
***************************************
