[32793] in Perl-Users-Digest
Perl-Users Digest, Issue: 4057 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Oct 17 00:09:37 2013
Date: Wed, 16 Oct 2013 21:09:03 -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, 16 Oct 2013 Volume: 11 Number: 4057
Today's topics:
Re: Can't Perl Be Event Driven Too? <jblack@nospam.com>
Re: Can't Perl Be Event Driven Too? <jblack@nospam.com>
Re: Dumper <rweikusat@mobileactivedefense.com>
Re: Dumper <gravitalsun@hotmail.foo>
Re: using File::Spec to figure out that Path::Class is <rweikusat@mobileactivedefense.com>
Re: using File::Spec to figure out that Path::Class is <cal@example.invalid>
Re: using File::Spec to figure out that Path::Class is <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 15 Oct 2013 11:00:23 -0500
From: John Black <jblack@nospam.com>
Subject: Re: Can't Perl Be Event Driven Too?
Message-Id: <MPG.2cc72290ce4f997598978d@news.eternal-september.org>
In article <vilain-6D0B37.01092714102013@news.individual.net>, vilain@NOspamcop.net says...
>
> In article <MPG.2cc532f3c40fb07d98978b@news.eternal-september.org>,
> John Black <jblack@nospam.com> wrote:
>
> > I keep hearing about how Javascript / Node.js is great for web servers
> > because its "event
> > driven" and "non-blocking"... Statements like this are often made:
> > "JavaScript happens to be
> > a great fit for writing servers due to its event-driven nature."
> >
> > But how hard is it to use Perl for an event driven application like a web
> > server. Seems to
> > me you can just have a main thread processing the event requests. For each
> > request, it
> > spawns a thread to go off and do the work which reports back when done. The
> > main event
> > queueing thread is not "blocked" while the other threads are doing the work.
> > Presto - event
> > driven... What am I missing?
> >
> > John Black
>
> What are you trying to do? You're asking general questions with massive
> assumptions behind them. It's like asking if a bus will get you to
> Detroit when all you may really need is to get to the library down the
> road.
For education, I wanted to learn to write a web based app on a cloud type of structure like
Heroku. I wanted to use Perl but now I notice Heroku doesn't even support it!
"Write apps in your language ? we support Ruby, Node.js, Clojure, Java, Play, Python and
Scala."
Why would they support Ruby and Python but not Perl??
John Black
------------------------------
Date: Tue, 15 Oct 2013 11:01:34 -0500
From: John Black <jblack@nospam.com>
Subject: Re: Can't Perl Be Event Driven Too?
Message-Id: <MPG.2cc722d7c5cb41ec98978e@news.eternal-september.org>
In article <MPG.2cc532f3c40fb07d98978b@news.eternal-september.org>, jblack@nospam.com says...
>
> I keep hearing about how Javascript / Node.js is great for web servers because its "event
> driven" and "non-blocking"... Statements like this are often made: "JavaScript happens to be
> a great fit for writing servers due to its event-driven nature."
>
> But how hard is it to use Perl for an event driven application like a web server. Seems to
> me you can just have a main thread processing the event requests. For each request, it
> spawns a thread to go off and do the work which reports back when done. The main event
> queueing thread is not "blocked" while the other threads are doing the work. Presto - event
> driven... What am I missing?
Thanks all who replied. I now have several CPAN modules to investigate as a starting point!
John Black
------------------------------
Date: Tue, 15 Oct 2013 14:53:59 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Dumper
Message-Id: <87r4bmwsg8.fsf@sable.mobileactivedefense.com>
George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
writes:
[...]
> # this is not
>
> use strict; use warnings;
> use Data::Dumper; $Data::Dumper::Purity=1;
> my $dmp;
> my %hash1 = ('k1'=>'v1','k2'=>'v2');
> $dmp = Data::Dumper::Dumper( \%hash1 );;
> my $hash2 = eval $dmp; print Data::Dumper::Dumper($hash2);
>
>
> what I am doing wrong
One could argue that the code should check whether the eval succeeded,
use strict;
use warnings;
use Data::Dumper;
$Data::Dumper::Purity=1;
my $dmp;
my %hash1 = ('k1'=>'v1','k2'=>'v2');
$dmp = Data::Dumper::Dumper( \%hash1 );;
my $hash2 = eval $dmp;
die($@) if $@;
print Data::Dumper::Dumper($hash2);
[NB: Don't put more than one statement on a line. That's going to make
debugging rather painful in exchange for nothing tangible]
But very likely, you should rather be using
use strict;
use warnings;
use Data::Dumper;
$Data::Dumper::Purity=1;
$Data::Dumper::Terse=1;
my $dmp;
my %hash1 = ('k1'=>'v1','k2'=>'v2');
$dmp = Data::Dumper::Dumper( \%hash1 );;
print STDERR ($dmp);
my $hash2 = eval $dmp;
die($@) if $@;
print Data::Dumper::Dumper($hash2);
so that $dmp contains the Perl code necessary to create an anonymous
hash with the intended content instead of the $VAR1 = { ... } strict
disallows.
------------------------------
Date: Tue, 15 Oct 2013 23:21:36 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Dumper
Message-Id: <l3k84n$vuj$1@news.ntua.gr>
> $Data::Dumper::Terse=1;
perfect
------------------------------
Date: Wed, 16 Oct 2013 13:39:36 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: using File::Spec to figure out that Path::Class is really what I want
Message-Id: <87vc0xcrue.fsf@sable.mobileactivedefense.com>
Cal Dershowitz <cal@example.invalid> writes:
[...]
>> There's lots to say here but it's not clear what you really want to
>> know. It looks like you might not have read the documentation for mkdir
>> which tells you that the mask you give it does not directly set the
>> permissions. It also directs you to the discussion of permissions in
>> the description of umask. Are still left with questions after reading
>> those two?
>>
>
> I would like to honestly say that I had no more questions about it,
> but that wouldn't be true. I man'ed mkdir and chased the explanation
> for umask, and to read it made it sound like an adjustment to what the
> OS might give you.
The traditional way to deal with permissions when creating a new
filesystem object would be to specify the maximally useful permission in
the creating call, ie
mkdir('/tmp/aktenordner', 0777);
and leave it to the user to use a umask value requesting that the bits
he doesn't like will be disabled. For the common umask value of 022
(disable other and group write permission), the call above would end up
creating a directory with 0755 permissions.
If you wanted the permissions to be exactly what was given in the mkdir,
you'd have to clear the umask first. It is usually sensible to use a
code sequence a la
my $omask;
$omask = umask(0);
mkdir('/tmp/aktendurcheinanderer', 0764);
umask($omask);
to avoid unintended interactions with code following the traditional
convention.
The umask can also be used to control the effective permissions of a
filesystem object created by some system call which doesn't take an
explicit permission argument but implicitly uses 0777. In this case, the
umask can be set to the inverse of the desired permission set in order
to create the directory entry with the desired permisson set. Eg,
--------
use Socket;
my $sk;
socket($sk, PF_UNIX, SOCK_DGRAM, 0);
umask(~0660);
bind($sk, pack_sockaddr_un('/tmp/strangers_no_trespass'));
--------
can be used to create a directory entry for a UNIX-domain socket which
won't be world-writeable.
------------------------------
Date: Tue, 15 Oct 2013 23:58:18 -0700
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: using File::Spec to figure out that Path::Class is really what I want
Message-Id: <YrqdnUaQfcVmpcPPnZ2dnUVZ_oednZ2d@supernews.com>
On 10/10/2013 06:20 AM, Ben Bacarisse wrote:
> Cal Dershowitz <cal@example.invalid> writes:
> <snip searching for questions...>
>
>> unless(-e $path_to_images or mkdir($path_to_images, 0755)) {
>> die "Unable to create $to\n";
>> };
> <snip>
>
>> Q1 = shift; that is, is there something less-kludgy than pasting
>> together paths with what the method call of File::Spec rootdir()
>> returns?
>
> catfile. There's no guarantee that rootdir() can be used to join path
> components. Did you not see catfile (and the related catdir) in the
> documentation?
Yeah. That's where I was when I made the original post, but I'm pretty
convinced That I want Path::Class instead.
>
>> Q2 I've been reading the development in the alpaca book and was pretty
>> sure that I could create a regex that would know that I want to have
>> an or among pm css and tmpl, but I couldn't achieve as a lexical
>> variable. Instead I have 3 pretty fortranny-looking controls. They
>> might be cute as a first effort, but I'd like to see what an old perl
>> pro might write instead.
>
> I can't tell what this means.
The other Ben reminded me that I was looking for (pm|css|tmpl).
>
>> Q3) Do I set permissions correctly? Since I set them to 755, what
>> situations would I do as well? For example, I could grant others in
>> the group write priveleges. What number would that entail, and how is
>> that best represented in perl?
>
> There's lots to say here but it's not clear what you really want to
> know. It looks like you might not have read the documentation for mkdir
> which tells you that the mask you give it does not directly set the
> permissions. It also directs you to the discussion of permissions in
> the description of umask. Are still left with questions after reading
> those two?
>
I would like to honestly say that I had no more questions about it, but
that wouldn't be true. I man'ed mkdir and chased the explanation for
umask, and to read it made it sound like an adjustment to what the OS
might give you.
That said, the permission I want is 764, where a group member can write
but does not have the execute permissions that "I" do. I don't look at
these permissions as any big deal, because it's all just me and whatever
automation means I can achieve.
$ perl kiwi5.pl leprechaun ursula
list is /home/fred/Documents/root/pages/yoga /home/fred/Documents
... (every file and directory in my template space) ...
/root/pages/pop46pl /home/fred/Documents/root/pages/uranus
base is pages
list2 is home fred Documents root pages
-------------
-------------
a is home fred Documents root pages
-------------
srd3 is /home/fred/Documents/root/pages/ursula/template_stuff
-------------
$ cat kiwi5.pl
#!/usr/bin/perl -w
use strict;
use 5.010;
use Cwd;
use Path::Class;
my ($from, $to) = @ARGV;
my $ts = "template_stuff";
my $images = "images";
my $captions = "captions";
my $current = cwd;
my $rd1 = dir($current);
my @list = $rd1->children();
say "list is @list";
my $base = $rd1->basename();
say "base is $base";
my @list2 = $rd1->dir_list();
say "list2 is @list2";
say "-------------";
# choose good lexical variable for directory list: @a.
say "-------------";
my $rd2 = dir($current);
my @a = $rd2->dir_list();
say "a is @a";
say "-------------";
# define the paths within the target directory
my $rd3 = dir(@a,$to,$ts);
my $srd3 = $rd3->stringify;
say "srd3 is $srd3";
say "-------------";
#my $rel = $rd3->relative; # Transform to relative path
#say "rel is $$rel";
$
I'm gonna use $rd(d*) to mean references to directories.
, otherwise apping out the capabilities here and trying to give
meaningful variable names to what will survive the next edit.
I like this syntax:
my $rd2 = dir($current);
my @a = $rd2->dir_list();
say "a is @a";
Trying it on both windows and *nix.
One thing I think I don't get is "stringifying,"
#my $rel = $rd3->relative; # Transform to relative path
#say "rel is $$rel";
I don't seem to be able to set up the circumstances for making this
method call something effective. (?)
--
Cal
------------------------------
Date: Wed, 16 Oct 2013 08:43:13 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: using File::Spec to figure out that Path::Class is really what I want
Message-Id: <hls1ja-fds1.ln1@anubis.morrow.me.uk>
Quoth Cal Dershowitz <cal@example.invalid>:
>
> That said, the permission I want is 764, where a group member can write
> but does not have the execute permissions that "I" do.
It's almost never sensible to give someone read permission on a
directory without also giving them search (execute) permission. (The
reverse is often useful.) I don't think you understand what the
'execute' bits do on a directory: see your system documentation or a
basic Unix tutorial. (On my system this is documented, rather briefly,
in intro(2), and also in chmod(1).)
> I don't look at
> these permissions as any big deal, because it's all just me and whatever
> automation means I can achieve.
If this will eventually be used on a machine serving HTTP to the
Internet then security is *always* a big deal. Get it right, or don't do
it at all and leave it to people who can.
> I'm gonna use $rd(d*) to mean references to directories.
Why on Earth would you do that? Give your variables sensible names.
> One thing I think I don't get is "stringifying,"
>
> #my $rel = $rd3->relative; # Transform to relative path
> #say "rel is $$rel";
Stringifying means 'treating an object as though it were a string'. Try
say "rel is $rel";
without the extra scalar-deref.
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 4057
***************************************
