[31909] in Perl-Users-Digest
Perl-Users Digest, Issue: 3172 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Oct 13 16:09:29 2010
Date: Wed, 13 Oct 2010 13:09:11 -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, 13 Oct 2010 Volume: 11 Number: 3172
Today's topics:
Re: Communication across Perl scripts <bart.lateur@telenet.be>
Re: Communication across Perl scripts <betterdie@gmail.com>
Re: cryptic error in cgi script <ben@morrow.me.uk>
Re: How to make XSUBs thread-safe? xsubpp switches? <nospam-abuse@ilyaz.org>
Re: How to make XSUBs thread-safe? xsubpp switches? <ben@morrow.me.uk>
Re: Looping on "if" statement? <cartercc@gmail.com>
Re: Looping on "if" statement? <uri@StemSystems.com>
Re: Looping on "if" statement? <cartercc@gmail.com>
minimal perl installation? <alfonso.baldaserra@gmail.com>
Re: minimal perl installation? <ben@morrow.me.uk>
modifying a PDF using PDF::API2? <bugbear@trim_papermule.co.uk_trim>
Re: real time log parser? <alfonso.baldaserra@gmail.com>
Re: suitable key for a hash <justin.1010@purestblue.com>
Re: suitable key for a hash <cartercc@gmail.com>
Re: suitable key for a hash <rvtol+usenet@xs4all.nl>
Re: suitable key for a hash <jurgenex@hotmail.com>
Re: suitable key for a hash <cartercc@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 13 Oct 2010 20:07:11 +0200
From: Bart Lateur <bart.lateur@telenet.be>
Subject: Re: Communication across Perl scripts
Message-Id: <h1tbb6dad2iuteohu9ninr8topd0s6n68t@4ax.com>
Randal L. Schwartz wrote:
>Look at DBM::Deep for a trivial way to store structured data, including
>having transactions so the data will change "atomically".
>
>And despite the name... DBM::Deep has no XS components... so it can even
>be installed in a hosted setup with limited ("no") access to compilers.
>
>Disclaimer: Stonehenge paid for part of the development of DBM::Deep,
>because yes, it's *that* useful.
Ouch. DBM::Deep is buggy, in my experience.
I don't know the exact circumstances, but when using it to cache the XML
contents of user home nodes on Perlmonks, I regularly get crashes in it.
It has something to do with changing size of the data, IIRC from larger
than 8k to below 8k. But I could have gotten these details wrong, as it
has been many since I last tried it.
--
Bart.
------------------------------
Date: Wed, 13 Oct 2010 12:12:11 -0700 (PDT)
From: paul <betterdie@gmail.com>
Subject: Re: Communication across Perl scripts
Message-Id: <154212a1-69ea-4bc4-8c72-6aea99ea44f3@26g2000yqv.googlegroups.com>
On Oct 13, 2:07=A0pm, Bart Lateur <bart.lat...@telenet.be> wrote:
> Randal L. Schwartz wrote:
> >Look at DBM::Deep for a trivial way to store structured data, including
> >having transactions so the data will change "atomically".
>
> >And despite the name... DBM::Deep has no XS components... so it can even
> >be installed in a hosted setup with limited ("no") access to compilers.
>
> >Disclaimer: Stonehenge paid for part of the development of DBM::Deep,
> >because yes, it's *that* useful.
>
> Ouch. DBM::Deep is buggy, in my experience.
>
> I don't know the exact circumstances, but when using it to cache the XML
> contents of user home nodes on Perlmonks, I regularly get crashes in it.
> It has something to do with changing size of the data, IIRC from larger
> than 8k to below 8k. But I could have gotten these details wrong, as it
> has been many since I last tried it.
>
> --
> =A0 =A0 =A0 =A0 Bart.
you can try Named pipes, as a special type of file that allows for
interprocess communication
. by using the "mknod" command you can create a name pile file, for
one process can open for reading
another for writing.
------------------------------
Date: Wed, 13 Oct 2010 05:19:01 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: cryptic error in cgi script
Message-Id: <liofo7-2on.ln1@osiris.mauzo.dyndns.org>
Quoth Sherm Pendley <sherm.pendley@gmail.com>:
>
> It was the lack of a comma that led me to think of indirect object
> syntax. So, sub arguments that are prototyped with '&' allow one to
> call the sub with no comma after the block?
An initial '&' allows you to omit the 'sub' keyword, in which case you
must omit the comma after the block. This only applies to an initial
'&', which is annoyingly inflexible.
> I suppose the intent is
> to allow subs that have similar syntax to the block forms of grep(),
> map(), eval(), etc.
Exactly.
> >> Remember - only perl can parse Perl. ;-)
> >
> > PPI?
>
> Is written in Perl. :-)
Yes, but perl is written in C :). More importantly, PPI implements a
parser that is completely distinct from the parser in perl, which is why
it isn't completely accurate. A better saying would be 'Perl cannot be
parsed', since it's impossible to parse without executing at least some
of the code.
Ben
------------------------------
Date: Wed, 13 Oct 2010 11:33:13 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: How to make XSUBs thread-safe? xsubpp switches?
Message-Id: <slrnibb67p.ml0.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-10-13, Ben Morrow <ben@morrow.me.uk> wrote:
>> For best result, one would have "global" switches like
>>
>> AUTOLOCK_ALL: local_XSUB_lock_shared_SV
>>
>> and an attribute
>>
>> AUTOLOCK: local_XSUB_lock_shared_SV
>> AUTOLOCK: 0
>>
>> for individual XSUBs...
> Well, you can get the latter with
>
> SCOPE: ENABLE
> PREINIT:
> dMY_CXT;
> INIT:
> SvLOCK(MY_CXT.locksv);
>
> plus appropriate logic in BOOT and CLONE.
And where the unlocking would happen? Or would dMY_CXT somehow
magically define something which unlocks on return? And if it is so
magical, why not make things which auto-SvLOCK inside dMY_CXT? Or
would it be then MY_dMY_CXT ;-] ?
Puzzled,
Ilya
------------------------------
Date: Wed, 13 Oct 2010 15:33:17 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How to make XSUBs thread-safe? xsubpp switches?
Message-Id: <disgo7-bps.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2010-10-13, Ben Morrow <ben@morrow.me.uk> wrote:
>
> > Well, you can get the latter with
> >
> > SCOPE: ENABLE
> > PREINIT:
> > dMY_CXT;
> > INIT:
> > SvLOCK(MY_CXT.locksv);
> >
> > plus appropriate logic in BOOT and CLONE.
>
> And where the unlocking would happen? Or would dMY_CXT somehow
> magically define something which unlocks on return? And if it is so
> magical, why not make things which auto-SvLOCK inside dMY_CXT? Or
> would it be then MY_dMY_CXT ;-] ?
dMY_CXT is a multiplicity-safe way of defining 'static' pointers to SVs.
See "Safely Storing Static Data in XS" in perlxs. The unlocking is
handled by the save stack: SvLOCK sets a lock which is only valid until
the end of the current scope. That's why SCOPE:ENABLE is needed.
Ben
------------------------------
Date: Wed, 13 Oct 2010 11:15:20 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: Looping on "if" statement?
Message-Id: <c5e57d71-fcd3-468c-ab95-496181b9a108@x42g2000yqx.googlegroups.com>
On Oct 8, 5:39=A0pm, T <zi...@yahoo.com> wrote:
> Greetings,
>
> I have been ask to support some old perl code that's been around and
> running for sometime. We upgrade our Linux Redhat OS from 3 to 5.5 and
> have bumped into a problem with the following if statement:
>
> =A0 =A0 =A0 =A0 # parse stdout to xml when:
> =A0 =A0 =A0 =A0 #
> =A0 =A0 =A0 =A0 # using xml mode 2 or xml mode 1 and command succeeds
> =A0 =A0 =A0 =A0 # we have xml obj
> =A0 =A0 =A0 =A0 # output contains xml formatted data
> =A0 =A0 =A0 =A0 #
> =A0 =A0 =A0 =A0 if (($mode =3D=3D 2 || ($mode =3D=3D 1 && !$res)) && ref =
$xml && grep{ m/
> [<>]/ }@out)
This may be a quibble, but you don't loop on an if statement, you
recurse. You test for the base case with your conditional. If the
conditional is true, you return the base case. If the conditional is
false, you call the function with some subset of the data.
Example:
sub recurse_through_array
{
my @ar =3D @_;
if (@ar =3D=3D 0) { return; } # @ar contains nothing
else
{
my $el =3D pop(@ar);
do_something($el);
recurse_through_array(@ar); # @ar minus one element
}
}
------------------------------
Date: Wed, 13 Oct 2010 14:45:59 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Looping on "if" statement?
Message-Id: <87vd56vsm0.fsf@quad.sysarch.com>
>>>>> "c" == ccc31807 <cartercc@gmail.com> writes:
c> On Oct 8, 5:39 pm, T <zi...@yahoo.com> wrote:
>> Greetings,
>>
>> I have been ask to support some old perl code that's been around and
>> running for sometime. We upgrade our Linux Redhat OS from 3 to 5.5 and
>> have bumped into a problem with the following if statement:
>>
>> # parse stdout to xml when:
>> #
>> # using xml mode 2 or xml mode 1 and command succeeds
>> # we have xml obj
>> # output contains xml formatted data
>> #
>> if (($mode == 2 || ($mode == 1 && !$res)) && ref $xml && grep{ m/
>> [<>]/ }@out)
c> This may be a quibble, but you don't loop on an if statement, you
c> recurse. You test for the base case with your conditional. If the
c> conditional is true, you return the base case. If the conditional is
c> false, you call the function with some subset of the data.
you shouldn't be one to use terms like recurse! :)
recursing is a sub concept and has nothing to do with if's. and you can
traverse a tree without recursion (either with looping or dispatching to
dedicated subs for each level).
c> Example:
c> sub recurse_through_array
c> {
c> my @ar = @_;
c> if (@ar == 0) { return; } # @ar contains nothing
c> else
c> {
c> my $el = pop(@ar);
c> do_something($el);
c> recurse_through_array(@ar); # @ar minus one element
c> }
c> }
that is tail recursion and is much simpler with a plain loop. also the
pop would likely want to be a shift so you process the leftmost elements
first.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Wed, 13 Oct 2010 13:02:33 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: Looping on "if" statement?
Message-Id: <536ea023-184e-43d2-807f-7d9f48adf0e3@l20g2000yqm.googlegroups.com>
On Oct 13, 2:45=A0pm, "Uri Guttman" <u...@StemSystems.com> wrote:
> recursing is a sub concept and has nothing to do with if's. and you can
> traverse a tree without recursion (either with looping or dispatching to
> dedicated subs for each level).
Recursion deals with the concept of calling the same function with a
subset of the data, and has everything to do with conditionals. If you
can't test for the base case, how could you stop the recursive call?
My point was that iterative controls, such as while, until, for, and
so on, involve looping. Conditional controls, such as if, unless,
case, and so on, involve recursion.
CC.
------------------------------
Date: Wed, 13 Oct 2010 05:51:22 -0700 (PDT)
From: alfonsobaldaserra <alfonso.baldaserra@gmail.com>
Subject: minimal perl installation?
Message-Id: <1edb39ec-7b5e-4dc4-ac12-27f646126951@c32g2000vbq.googlegroups.com>
hello,
i am required to write some automation scripts in perl for our windows
based users. to get scripts to run on their desktops we need to
install perl all the time.
i was wondering if there is some minimal and easy way we can get the
scripts to run on their systems without installing complete perl
distribution?
any pointers/suggestions are welcome.
thank you
------------------------------
Date: Wed, 13 Oct 2010 15:33:52 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: minimal perl installation?
Message-Id: <gjsgo7-bps.ln1@osiris.mauzo.dyndns.org>
Quoth alfonsobaldaserra <alfonso.baldaserra@gmail.com>:
>
> i am required to write some automation scripts in perl for our windows
> based users. to get scripts to run on their desktops we need to
> install perl all the time.
>
> i was wondering if there is some minimal and easy way we can get the
> scripts to run on their systems without installing complete perl
> distribution?
PAR::Packer
Ben
------------------------------
Date: Wed, 13 Oct 2010 14:56:31 +0100
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: modifying a PDF using PDF::API2?
Message-Id: <G8-dnWUm89oSJyjRnZ2dnUVZ8t2dnZ2d@brightview.co.uk>
I'm trying to add a watermark to an existing page; the watermark
is in a separate pre-prepared PDF.
Code is fairly simple -
my $base = PDF::API2->open($in);
my $page = $base->openpage(1);
my $water = PDF::API2->open("water.pdf");
my $xo = $dest->importPageIntoForm($water, 1);
$page->gfx->formimage($xo, 0, 0, 1);
$base->saveas($out);
This works OK on simple "base" files, but fails on larger ones;
Adobe Acrobat Reader says the output has an error (without
being specific)
sidebar
anyone know a good PDF checker that gives detailed fault reports?
I note that API2 is much more about creating new PDF files
than messing with existing ones - indeed, if I proceed
by transcribing the page from "$in" and the watermark
into a PDF::API2->new() object, that works OK,
in that it generates valid files, but it loses much
of the metadata from the base file.
So - is PDF::API2 really up to modifying existing files,
or should I try to "jazz up" my transcription solution?
BugBear
------------------------------
Date: Wed, 13 Oct 2010 05:57:26 -0700 (PDT)
From: alfonsobaldaserra <alfonso.baldaserra@gmail.com>
Subject: Re: real time log parser?
Message-Id: <af183d36-8f21-4ee6-a60a-33db040baf6e@c32g2000vbq.googlegroups.com>
> I would like to write a log parser which would work "in real time".
i wrote a similar one at previous work to monitor oracle logs and send
alerts to nagios server.
> Meaning, it will read i.e. /var/log/mail.info and append interesting
> entries it finds to a database, according to some criteria.
>
> What should I look at / read to achieve it? I'm OK to create a "static"
i utilised file::tail module and ran the program as a daemon.
file::tail is pretty good when the files are rotated so you dont have
to keep track of offsets and inodes etc.
also i created a small shell script and ran it as cron job to monitor
the status of my perl daemon.
------------------------------
Date: Wed, 13 Oct 2010 10:25:42 +0100
From: Justin C <justin.1010@purestblue.com>
Subject: Re: suitable key for a hash
Message-Id: <mhago7-cu5.ln1@zem.masonsmusic.co.uk>
On 2010-10-12, ccc31807 <cartercc@gmail.com> wrote:
> I have a data file to process that consists of about 25K rows and
> about 30 columns. This file contains no column with unique values,
> that is, every column contains duplicate values. I am placing the data
> in a hash to process it (so I can access the data values by name
> rather than position), and the only 'key' I can come up with is the $.
> variable for the input line numbers.
>
> Surely someone must have dealt with this problem before. Is there a
> better solution?
>
> The processing requires dumping the data into discrete categories,
> e.g., level, state, person's name, status, for the purpose of
> generating reports, e.g., by level, by state, by name, by status, and
> not having a unique key isn't an issue.
Instead of sticking it into a hash so that you can go over all of it
again, why not process (or part process) it into the relevant discrete
categories as part of the import?
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 13 Oct 2010 06:37:24 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: suitable key for a hash
Message-Id: <ed0471b0-8cc6-4f43-ba05-2a2e4f0f08e2@q2g2000vbk.googlegroups.com>
Thanks for your reply, and for all the others.
I decided to continue to use $. as the hash key. As it turns out, the
key isn't relevant to my application, as I'm not using the key to look
up the hash values. I'm just iterating through the hash, collecting
certain values, so the key is totally superfluous -- the only reason I
need a key is because of the nature of the hash.
I don't want to use an array because I'm creating a number of
different reports, and it's simply a lot easier to use values like:
$data{$key}{firstname}, $data{$key}{lastname}
than it is to use values like
$data[13456][2], $data[23543][3]
On Oct 12, 1:03=A0pm, RedGrittyBrick <RedGrittyBr...@spamweary.invalid>
wrote:
> An SSCCE would help.
I'm sorry, but I don't know this. What is an SSCCE?
CC
------------------------------
Date: Wed, 13 Oct 2010 15:51:26 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: suitable key for a hash
Message-Id: <4cb5b95e$0$81476$e4fe514c@news.xs4all.nl>
On 2010-10-13 15:37, ccc31807 wrote:
> I decided to continue to use $. as the hash key.
If it smells like an array index ...
> As it turns out, the
> key isn't relevant to my application, as I'm not using the key to look
> up the hash values. I'm just iterating through the hash, collecting
> certain values, so the key is totally superfluous -- the only reason I
> need a key is because of the nature of the hash.
>
> I don't want to use an array because I'm creating a number of
> different reports, and it's simply a lot easier to use values like:
>
> $data{$key}{firstname}, $data{$key}{lastname}
>
> than it is to use values like
>
> $data[13456][2], $data[23543][3]
That is not the proper comparison.
$data[ $row ]{ firstname }
$data[ $row ][ FIRSTNAME ]
(assumes a numeric constant FIRSTNAME)
> What is an SSCCE?
JFGI
--
Ruud
------------------------------
Date: Wed, 13 Oct 2010 08:08:35 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: suitable key for a hash
Message-Id: <4nibb61st9gktihavuhca5taju8btb2i6k@4ax.com>
ccc31807 <cartercc@gmail.com> wrote:
>I don't want to use an array because I'm creating a number of
>different reports, and it's simply a lot easier to use values like:
>
>$data{$key}{firstname}, $data{$key}{lastname}
>
>than it is to use values like
>
>$data[13456][2], $data[23543][3]
And why not use values like
$data[$key]{firstname}, $data[$key]{lastname}
jue
------------------------------
Date: Wed, 13 Oct 2010 11:03:10 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: suitable key for a hash
Message-Id: <2afe8560-a273-475b-8946-b1849ef96c5d@28g2000yqm.googlegroups.com>
On Oct 13, 11:08=A0am, J=FCrgen Exner <jurge...@hotmail.com> wrote:
> And why not use values like
>
> =A0 =A0 =A0 =A0 $data[$key]{firstname}, $data[$key]{lastname}
Because I wasn't completely truthful about my processing. I have to
break the data apart on various values, some if which are unique keys,
e.g., identification numbers for individual people. The data includes
clients and counselors, and (obviously) clients can have multiple
counselors and counselors can have multiple clients. Other values are
one of a kind, such as a person's address, regardless of the number of
times the particular person appears in the data. I have to cross
reference these values by unique keys, and I use five hashes to sort
out the data.
I see now that I could use an array for the handful of data elements
for each row that are unique.
Thanks, CC.
------------------------------
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 3172
***************************************
