[31905] in Perl-Users-Digest
Perl-Users Digest, Issue: 3168 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Oct 11 21:09:24 2010
Date: Mon, 11 Oct 2010 18:09:09 -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 Mon, 11 Oct 2010 Volume: 11 Number: 3168
Today's topics:
Re: Bug in Win32::Clipboard::WaitForChange() ? <jl_post@hotmail.com>
Communication across Perl scripts <alertjean@gmail.com>
Re: Communication across Perl scripts <sherm.pendley@gmail.com>
Re: Communication across Perl scripts <tzz@lifelogs.com>
Re: Communication across Perl scripts <tzz@lifelogs.com>
Re: Communication across Perl scripts <m@rtij.nl.invlalid>
Re: Communication across Perl scripts <jl_post@hotmail.com>
Re: Communication across Perl scripts <derykus@gmail.com>
Re: Communication across Perl scripts <tzz@lifelogs.com>
Re: Communication across Perl scripts <tzz@lifelogs.com>
Re: Date difference in days <glex_no-spam@qwest-spam-no.invalid>
How can I check if two refs point to the same object? <jl_post@hotmail.com>
Re: How can I check if two refs point to the same objec (Alan Curry)
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>
LINDSAY LOHAN SEX VIDEOS <step2hell@gmail.com>
Re: toy list processing problem: collect similar terms <e9427749@stud4.tuwien.ac.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 11 Oct 2010 08:34:41 -0700 (PDT)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Bug in Win32::Clipboard::WaitForChange() ?
Message-Id: <c48880d9-e7fa-4aee-9318-5f99fbae8c6b@q18g2000vbm.googlegroups.com>
On Oct 4, 10:56=A0pm, "C.DeRykus" <dery...@gmail.com> wrote:
>
> If your script calls WaitForChange() again, it
> actually waits as you'd expect.
Thanks, Charles. That does help somewhat. I had never tried
calling WaitForChange() a second time, so I never discovered this work-
around before.
Thanks again,
-- Jean-Luc
------------------------------
Date: Mon, 11 Oct 2010 09:25:25 -0700 (PDT)
From: Jean <alertjean@gmail.com>
Subject: Communication across Perl scripts
Message-Id: <c3bc5b1a-6c3e-4e2b-84f5-5dd37dfb1c15@m1g2000vbh.googlegroups.com>
I am searching for efficient ways of communication across two Perl
scripts. I have two scripts; Script 1 generates some data. I want my
script two to be able to access that information. The easiest/dumbest
way is to write the data generated by script 1 as a file and read it
later using script 2. Is there any other way than this ? Can I store
the data in memory and make it available to script two (of-course with
support from my Linux ) ? Meaning malloc somedata by script 1 and make
script 2 able to access it.
There is no guarantee that Script 2 will be run after Script 1. So
there should be some way to free that memory using a watchdog timer.
------------------------------
Date: Mon, 11 Oct 2010 13:09:06 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: Communication across Perl scripts
Message-Id: <m2fwwcmzbh.fsf@sherm.shermpendley.com>
Jean <alertjean@gmail.com> writes:
> I am searching for efficient ways of communication across two Perl
> scripts.
Options are plentiful. Have a look at "perldoc perlipc" for a good
overview.
sherm--
--
Sherm Pendley
<http://camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Mon, 11 Oct 2010 14:17:58 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Communication across Perl scripts
Message-Id: <87iq187d3t.fsf@lifelogs.com>
On Mon, 11 Oct 2010 09:25:25 -0700 (PDT) Jean <alertjean@gmail.com> wrote:
J> I am searching for efficient ways of communication across two Perl
J> scripts. I have two scripts; Script 1 generates some data. I want my
J> script two to be able to access that information. The easiest/dumbest
J> way is to write the data generated by script 1 as a file and read it
J> later using script 2. Is there any other way than this ? Can I store
J> the data in memory and make it available to script two (of-course with
J> support from my Linux ) ? Meaning malloc somedata by script 1 and make
J> script 2 able to access it.
J> There is no guarantee that Script 2 will be run after Script 1. So
J> there should be some way to free that memory using a watchdog timer.
Depends on your latency and load requirements.
If you need speed, shared memory is probably your best bet.
If you need easy reliable implementation, put the information in files
(you can notify the reader there's a new file with fam/inotify or
SIGUSR1). That's not a dumb way as long as you implement it properly
and it fits your requirements.
If you need low latency, use a message queue.
Ted
------------------------------
Date: Mon, 11 Oct 2010 14:20:11 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Communication across Perl scripts
Message-Id: <87eibw7d04.fsf@lifelogs.com>
On Mon, 11 Oct 2010 13:09:06 -0400 Sherm Pendley <sherm.pendley@gmail.com> wrote:
SP> Jean <alertjean@gmail.com> writes:
>> I am searching for efficient ways of communication across two Perl
>> scripts.
SP> Options are plentiful. Have a look at "perldoc perlipc" for a good
SP> overview.
Unfortunately that page doesn't mention (nor should it) databases,
message queues, ESBs, loopback network interfaces, etc. Each one of
those may have distinct advantages over plain IPC, depending on the OS,
environment, policies, and existing infrastructure.
Ted
------------------------------
Date: Mon, 11 Oct 2010 22:14:29 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Communication across Perl scripts
Message-Id: <5q7co7-2l5.ln1@news.rtij.nl>
On Mon, 11 Oct 2010 14:17:58 -0500, Ted Zlatanov wrote:
> If you need low latency, use a message queue.
Speaking of message queues, what do people recommend on Unix/Linux?
M4
------------------------------
Date: Mon, 11 Oct 2010 14:15:13 -0700 (PDT)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Communication across Perl scripts
Message-Id: <8fed3db8-77d7-4ba4-8664-1a1804ebfffc@k10g2000yqa.googlegroups.com>
On Oct 11, 10:25=A0am, Jean <alertj...@gmail.com> wrote:
> I am searching for efficient ways of communication across two Perl
> scripts. I have two scripts; Script 1 generates some data. I want my
> script two to be able to access that information.
> There is no guarantee that Script 2 will be run after Script 1. So
> there should be some way to free that memory using a watchdog timer.
It sounds like there's no guarantee that either script will overlap
while running, either. Unless you write your data to a file on disk,
you'll need another program to act as some sort of broker to manage
the data you want to share.
You could try using a third-party broker, or perhaps use an SQL
database to store your data. ...or you could just write what you want
to share to disk, to be picked up by Script 2.
> The easiest/dumbest way is to write the data generated by
> script 1 as a file and read it later using script 2.
That may be easiest, but I don't think it's the dumbest. And if
you use this approach, I highly recommend using the "Storable" module
(it's a standard module so you should already have it). If you have a
reference to data in Script 1 (for example, $dataReference), you can
save it in one line (if you don't count the "use Storable" line), like
this:
use Storable qw(lock_nstore lock_retrieve);
lock_nstore($dataReference, "file_name");
and then Script 2 can read it in with one line like this:
use Storable qw(lock_nstore lock_retrieve);
my $dataReference =3D lock_retrieve("file_name");
Now Script 1 and Script 2 should both have a $dataReference that
refers to identical data.
Type "perldoc Storable" at the Unix/DOS prompt to read more about
this module.
It's hard to get much simpler than this. You might be tempted to
write your own file-writing and file-reading code, but if you do,
you'll have to handle your own file locking and your own to/from file
stream conversions. (And that'll probably take more than just two
lines of code to implement.)
If you're good with SQL, you may want to try a DBI module like
DBD::SQLite. The database for SQLite is stored on disk (so you don't
need a third-party program to manage the data), and it gives you the
flexibility in that if you ever have move your shared data to a
database server, most of the data-sharing code will remain unchanged.
Also, don't forget to "use strict;" and "use warnings;" if you
aren't using them already; they'll save you lots of headaches in the
long run.
I hope this helps,
-- Jean-Luc
------------------------------
Date: Mon, 11 Oct 2010 14:25:59 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Communication across Perl scripts
Message-Id: <33b0e3b1-6a43-43f2-9c97-92745eeb61c9@i5g2000yqe.googlegroups.com>
On Oct 11, 9:25=A0am, Jean <alertj...@gmail.com> wrote:
> I am searching for efficient ways of communication across two Perl
> scripts. I have two scripts; Script 1 generates some data. I want my
> script two to be able to access that information. The easiest/dumbest
> way is to write the data generated by script 1 as a file and read it
> later using script 2. Is there any other way than this ? Can I store
> the data in memory and make it available to script two (of-course with
> support from my Linux ) ? Meaning malloc somedata by script 1 and make
> script 2 able to access it.
>
> There is no guarantee that Script 2 will be run after Script 1. So
> there should be some way to free that memory using a watchdog timer.
It sounds like a named pipe (see perlipc) would be
the easiest, most straightforward solution. (See
T.Zlatonov's suggestions though for other possible
non-IPC solutions which, depending on the exact
scenario, may be a better fit.)
With a named pipe though, each script just deals
with the named file for reading or writing while
the OS takes care of the messy IPC details for
you. The 2nd script will just block until data
is available so running order isn't a concern. As
long as the two scripts are running more or less
concurrently, I would guess memory use will be
manageable too since the reader will be draining
the pipe as the data arrives.
--
Charles DeRykus
------------------------------
Date: Mon, 11 Oct 2010 19:55:03 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Communication across Perl scripts
Message-Id: <87sk0ci61k.fsf@lifelogs.com>
On Mon, 11 Oct 2010 22:14:29 +0200 Martijn Lievaart <m@rtij.nl.invlalid> wrote:
ML> On Mon, 11 Oct 2010 14:17:58 -0500, Ted Zlatanov wrote:
>> If you need low latency, use a message queue.
ML> Speaking of message queues, what do people recommend on Unix/Linux?
I've heard positive things about http://www.rabbitmq.com/ but haven't
used it myself. There's a lot of others, see
http://en.wikipedia.org/wiki/Category:Message-oriented_middleware
Depending on your needs, TIBCO may fit. It's very popular in the
financial industry and in my experience has been a pretty good system
over the last 3 years I've used it. The Perl bindings
are... well... usable. The major headaches I've had were when the
process is slow handling incoming data. Unless you write your Perl very
carefully, it's easy to block and balloon the memory size (because
TIBCO's queue uses your own application's memory) to multi-gigabyte
footprints. So forget about database interactions, for instance--you
have to move them to a separate process and use IPC or file drops.
Threads (as in "use threads") are probably a bad idea too.
Ted
------------------------------
Date: Mon, 11 Oct 2010 19:59:52 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Communication across Perl scripts
Message-Id: <87ocb0i5tj.fsf@lifelogs.com>
On Mon, 11 Oct 2010 14:25:59 -0700 (PDT) "C.DeRykus" <derykus@gmail.com> wrote:
CD> With a named pipe though, each script just deals with the named file
CD> for reading or writing while the OS takes care of the messy IPC
CD> details for you. The 2nd script will just block until data is
CD> available so running order isn't a concern. As long as the two
CD> scripts are running more or less concurrently, I would guess memory
CD> use will be manageable too since the reader will be draining the
CD> pipe as the data arrives.
The only warning I have there is that pipes are pretty slow and have
small buffers by default in the Linux kernel (assuming Linux). I forget
exactly why, I think it's due to terminal disciplines or something, I
didn't dig too much. I ran into this earlier this year.
So if you have a fast writer pipes can be problematic.
Ted
------------------------------
Date: Mon, 11 Oct 2010 10:06:56 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Date difference in days
Message-Id: <4cb31756$0$2511$815e3792@news.qwest.net>
Paul E. Schoen wrote:
[...]
> The script can be seen in action as the hit counter in:
[...]
perldoc -q "I still don't get locking."
------------------------------
Date: Mon, 11 Oct 2010 16:15:09 -0700 (PDT)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: How can I check if two refs point to the same object?
Message-Id: <295c4962-a165-4c0d-b9f6-d7bd0425a2ca@n26g2000yqh.googlegroups.com>
Hi,
I was wondering if there was a way I could check if two references
are referencing the same object. For example, consider the following
code:
use Math::BigInt;
my $n1 = Math::BigInt->new(5);
my $n2 = $n1;
my $n3 = Math::BigInt->new(5);
In this code, $n1, $n2, and $n3 will all be equivalent as far as the
'==' and 'eq' operators are concerned, but how can I check to see
which ones are referencing the same object? In other words, how can I
tell that $n1 and $n2 are referring to the same object, and $n3 is
not?
The only way I know how to do this is to run the following code:
use Data::Dumper;
print Dumper $n1, $n2, $n3;
and check for lines like "$VAR2 = $VAR1;" but it seems like there
should be a more straight-forward way to do this.
Is there a way to see which references refer to the same object,
even when the '==' and 'eq' operators are overloaded?
Thanks,
-- Jean-Luc
------------------------------
Date: Mon, 11 Oct 2010 23:28:03 +0000 (UTC)
From: pacman@kosh.dhis.org (Alan Curry)
Subject: Re: How can I check if two refs point to the same object?
Message-Id: <i906i2$rr9$1@speranza.aioe.org>
In article <295c4962-a165-4c0d-b9f6-d7bd0425a2ca@n26g2000yqh.googlegroups.com>,
jl_post@hotmail.com <jl_post@hotmail.com> wrote:
>
> I was wondering if there was a way I could check if two references
>are referencing the same object. For example, consider the following
>code:
>
> use Math::BigInt;
> my $n1 = Math::BigInt->new(5);
> my $n2 = $n1;
> my $n3 = Math::BigInt->new(5);
[...]
>
> Is there a way to see which references refer to the same object,
>even when the '==' and 'eq' operators are overloaded?
Get their addresses with Scalar::Util::refaddr and compare.
use Scalar::Util 'refaddr';
sub sameref
{
my ($a1,$a2) = (refaddr($_[0]), refaddr($_[1]));
return defined($a1) && defined($a2) && $a1 == $a2;
}
use Math::BigInt;
my $n1 = Math::BigInt->new(5);
my $n2 = $n1;
my $n3 = Math::BigInt->new(5);
print "n1 sameref n2: ", (sameref($n1,$n2) ? "yes" : "no"), "\n";
print "n1 sameref n3: ", (sameref($n1,$n3) ? "yes" : "no"), "\n";
print "n2 sameref n3: ", (sameref($n2,$n3) ? "yes" : "no"), "\n";
--
Alan Curry
------------------------------
Date: Mon, 11 Oct 2010 22:26:59 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: How to make XSUBs thread-safe? xsubpp switches?
Message-Id: <slrnib73pj.cto.nospam-abuse@powdermilk.math.berkeley.edu>
Suppose I have an interface module to an external library with
hundreds (or thousands) of XSUBs, and I want to make it thread-safe.
The external library is not. So what looks like the simplest
first-stage solution is to automatically insert locking code about all
XSUBs. But we already have a preprocessor which massages XSUBs:
xsubpp.
So: is it possible to instruct xsubpp to insert locking code about
all/selected XSUBs? At least the docs of perl-5.8.8 one do not
mention anything like this...
Thanks,
Ilya
------------------------------
Date: Tue, 12 Oct 2010 01:20:20 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How to make XSUBs thread-safe? xsubpp switches?
Message-Id: <47mco7-eu82.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> Suppose I have an interface module to an external library with
> hundreds (or thousands) of XSUBs, and I want to make it thread-safe.
> The external library is not. So what looks like the simplest
> first-stage solution is to automatically insert locking code about all
> XSUBs. But we already have a preprocessor which massages XSUBs:
> xsubpp.
>
> So: is it possible to instruct xsubpp to insert locking code about
> all/selected XSUBs? At least the docs of perl-5.8.8 one do not
> mention anything like this...
I don't think so. It's not even clear what should be locked: the
ithreads locking code only allows you to lock a shared variable, so the
5005threads solution of locking the CV doesn't work any more.
Ben
------------------------------
Date: Mon, 11 Oct 2010 03:49:20 -0700 (PDT)
From: rock <step2hell@gmail.com>
Subject: LINDSAY LOHAN SEX VIDEOS
Message-Id: <5d1cf6a0-951c-4297-bc41-cf6d680d5068@q3g2000pra.googlegroups.com>
By premises of google i have hide the videos in an IMAGE......click
on the IMAGE below the SEARCH BOX to view the videos..........
http://lindsaylohansexvideo.tk/
------------------------------
Date: Mon, 11 Oct 2010 18:51:13 +0200
From: Josef <e9427749@stud4.tuwien.ac.at>
Subject: Re: toy list processing problem: collect similar terms
Message-Id: <4cb34083$0$11094$3b214f66@tunews.univie.ac.at>
Am 09.10.2010 00:22, schrieb Ertugrul Söylemez:
> Josef<e9427749@stud4.tuwien.ac.at> wrote:
>
>> Am 08.10.2010 04:38, schrieb Ertugrul Söylemez:
>>>
>>> [obfuscated code][...] But unlike Perl, it still looks beautiful.
>>
>> Ok, what i learned now, is that perception of beautifulness could be
>> very different.
>
> Well, in fact the code I posted is beautiful in a number of ways. It's
> easy to read, very fast and also elegant. [...]
I think contradict yourself.
But this is elaborately demonstrated by Peter already.
> In other words: It's beautiful, if you understand the concept it
> implements. =)
So if i understand the concept it is beautiful independent if i use
Haskel or Perl, or not?
>> Hey i say this only, so the perliatic pitbulls don't snarl to you
>> "that has nothing to do with perl" and tear you afterwards.
To be honest you was not really in danger.
I said this only to tease my perl colleagues.
And i assumed that the directly following sentences
"Oh, maybe i shouldn't have written this. Brave dog. brave.
search this nice ball. be a nice dog. no no no ...
"
and their comic-like style are enough to point out the irony.
(Farther I think that the posting from Rhodri James early explains
very well, why that was happen in this thread somewhere else.)
> It does have something to do with Perl, it's just like Perl people don't
> like to have their favorite language compared to others. =)
Why you thing so?
Have you taken my speech to seriously?
And if you are unsure, how to classify perl mongers,
an old local proverb say: "Barking dogs don't bite." ;-)
BTW comparing programming languages is difficult and need normally a
deep actual knowledge of the languages in the comparsion.
AFAIR Bjarne Stroustrup utter this in his book
"The Design and Evolution of C++" (Eiffel vs. C++).
(Except if the main purpose of a language isn't programming altogether.
Then it is sometimes simply to state but often nevertheless unfair.)
And beside that how you weight LOP vs. OOP vs. FOP vs. Multi Paradigm?
And what is more important orthogonality, feature richness, DWIMery &c?
And which learning curve is preferable?
Should the language try to guide the programmer?
> That's also the reason I'm still crossposting to c.l.p.m.
So you think functional programming in perl as topic, is not
enough to crosspost? ;-)
> Of course, readers are free to put me on their killfile,
> if they prefer to, but I see no reason.
Hmm, why you say this if you see no reason?
Or do you think some perl mongers can see this differently?
But is this kind of thinking not a reason by itself?
So you contradict you again ;-)
>> But yet to something completely different:
>> Maybe you like the following version more.
>>
>> ...
>> # charpter 1
>> sub fun
>> {@{+ reduce { my ($o,$map)=@$a; my ($k)=$b->[0];
>> my @k=exists $map->{$k} ? () : $k;
>> [[@$o,@k],
>> { %$map,$k =>
>> [!@k?@{$map->{$k}}:(),@{$b}[1..$#$b]] }]
>> } @_
>> }}
>> my ($order,$map)=fun [[],{}],@inp;
>> dump @{$map}{@$order};
>
> More functional, [..]
In what sense do you think this is more functional?
Because this version hasn't used closures?
Or maybe the use of map and filter (=grep in perl) functions in the
previous cinderella version are evil? Or recursion?
I always think this is all fine in functional programming, i'm wrong? ;-)
> but I still don't understand all those Perl symbols,
> but I'm not a Perl programmer anyway.
My Haskell knowledge is not more than yours about perl.
(I remember the meaning of the "->" *symbol* and
i think i guessed the "=>" *symbol* correctly. ;-)
bye,
Jos "not a native speaker" ef
PS: Even your Haskel examples does not stop me thinking that
Haskell is a nice interesting noteworthily language. ;-)
PPS: This time with extra smiley's.
------------------------------
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 3168
***************************************
