[31967] in Perl-Users-Digest
Perl-Users Digest, Issue: 3231 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Dec 9 18:09:30 2010
Date: Thu, 9 Dec 2010 15:09:12 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 9 Dec 2010 Volume: 11 Number: 3231
Today's topics:
Order of evaluation of arguments in a subroutine <schaitan@gmail.com>
Re: Order of evaluation of arguments in a subroutine <kst-u@mib.org>
Re: PostScript::Simple - linedistance question <v.niekerk_@_hccnet.nl>
Re: PostScript::Simple - linedistance question (Jens Thoms Toerring)
Re: variables inside a string sln@netherlands.com
Re: Who will win the battle for control of the web? <cartercc@gmail.com>
Re: Who will win the battle for control of the web? <hjp-usenet2@hjp.at>
Re: Who will win the battle for control of the web? <cartercc@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 9 Dec 2010 03:08:15 -0800 (PST)
From: Krishna Chaitanya <schaitan@gmail.com>
Subject: Order of evaluation of arguments in a subroutine
Message-Id: <d0d63496-e3da-493e-b14e-375de9ca2a36@l34g2000pro.googlegroups.com>
In Perl, is the order of evaluating subroutine args L-to-R?
I saw in perlop that a comma operator in a list context evaluates from
L-to-R, and also in perlsub that all args to a subroutine are squashed
into 1 single list......can I deduce from these 2 statements that
order of evaluation of subroutine args is L-to-R as well?
I wrote some sample code like this, and would like to predict its
outcome (if possible):
====================
#!/usr/bin/perl
sub func { }
my $a = sub { print "Hello"; };
my $b = sub { print " world "; };
func($a->(),$b->());
====================
TIA,
Chaitanya
------------------------------
Date: Thu, 09 Dec 2010 11:49:14 -0800
From: Keith Thompson <kst-u@mib.org>
Subject: Re: Order of evaluation of arguments in a subroutine
Message-Id: <lnsjy6loat.fsf@nuthaus.mib.org>
Krishna Chaitanya <schaitan@gmail.com> writes:
> In Perl, is the order of evaluating subroutine args L-to-R?
>
> I saw in perlop that a comma operator in a list context evaluates from
> L-to-R, and also in perlsub that all args to a subroutine are squashed
> into 1 single list......can I deduce from these 2 statements that
> order of evaluation of subroutine args is L-to-R as well?
I believe so. "perldoc perlop" says:
Comma Operator
Binary "," is the comma operator. In scalar context
it evaluates its left argument, throws that value away,
then evaluates its right argument and returns that value.
This is just like C’s comma operator.
In list context, it’s just the list argument separator, and
inserts both its arguments into the list. These arguments
are also evaluated from left to right.
I'm fairly sure that subroutine arguments are evaluated as an ordinary
list, so the second paragraph would apply.
> I wrote some sample code like this, and would like to predict its
> outcome (if possible):
>
> ====================
>
> #!/usr/bin/perl
>
> sub func { }
>
> my $a = sub { print "Hello"; };
> my $b = sub { print " world "; };
>
> func($a->(),$b->());
>
> ====================
Consider whether you really need to do this? I'm not 100% certain
that my conclusion above is correct (though I'll be more confident
if nobody shoots it down in flames in the next couple of days).
And though it's not entirely relevant, there are plenty of other
languages in which the order of evaluation of subroutine arguments
is unspecified.
Even if the language guarantees left-to-right evaluation, I suggest
that your code would likely be clearer if it didn't depend on
this guarantee.
my $first = $a->();
my $second = $b->();
func($first, $second);
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: 08 Dec 2010 19:37:24 GMT
From: Huub <v.niekerk_@_hccnet.nl>
Subject: Re: PostScript::Simple - linedistance question
Message-Id: <4cffde73$0$4579$e4fe514c@dreader32.news.xs4all.nl>
On Wed, 08 Dec 2010 18:48:25 +0000, RedGrittyBrick wrote:
> On 08/12/2010 18:35, Huub wrote:
>> I have been using the PostScript::Simple package for quite some time
>> and initally with good results. However, after the necessary change of
>> printer (HP Deskjet 520 into DeskJet 690C), I noticed that the distance
>> between lines had changed slightly. When checking the code, I found
>> everything fine. BTW, the code also predefines A4 paper. Now, after
>> another necessary change of printer (Deskjet 690C into Epson Stylus
>> S21), I find that not only the distance problem persists, but the last
>> line is only printed partly. Can somebody please explain this to me?
>
> Assuming you have not changed your Perl program, the generated
> postscript must be the same. This means that this is probably not a Perl
> question.
>
> I imagine that Postscript::Simple may not take into account printer
> capabilities as expressed in a PPD file. Conceivavbly this might cause
> problems but I'd look elsewhere first.
>
> Probably there are small differences in the Postscript emulation in the
> three printers you mentioned. This could give rise to incorrect scaling.
>
> It is also possible that the last printer has a smaller printable area
> (due to the paper feed mechanism).
>
> The Epson S21 is a very cheap inkjet printer - if (as seems likely) it
> is not a postscript printer, you are probably using some other software
> (e.g. Ghostscript) to rasterise the output of your Perl program - this
> is another area where small differences in output might be introduced.
Thank you for your answer. I had not thought about the (possible lack of)
postscript support by the printer. I've contacted their support..
------------------------------
Date: 8 Dec 2010 23:37:50 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: PostScript::Simple - linedistance question
Message-Id: <8maj6eFparU1@mid.uni-berlin.de>
Huub <v.niekerk_@_hccnet.nl> wrote:
> On Wed, 08 Dec 2010 18:48:25 +0000, RedGrittyBrick wrote:
> > On 08/12/2010 18:35, Huub wrote:
> >> I have been using the PostScript::Simple package for quite some time
> >> and initally with good results. However, after the necessary change of
> >> printer (HP Deskjet 520 into DeskJet 690C), I noticed that the distance
> >> between lines had changed slightly. When checking the code, I found
> >> everything fine. BTW, the code also predefines A4 paper. Now, after
> >> another necessary change of printer (Deskjet 690C into Epson Stylus
> >> S21), I find that not only the distance problem persists, but the last
> >> line is only printed partly. Can somebody please explain this to me?
> >
> > Assuming you have not changed your Perl program, the generated
> > postscript must be the same. This means that this is probably not a Perl
> > question.
> >
> > I imagine that Postscript::Simple may not take into account printer
> > capabilities as expressed in a PPD file. Conceivavbly this might cause
> > problems but I'd look elsewhere first.
> >
> > Probably there are small differences in the Postscript emulation in the
> > three printers you mentioned. This could give rise to incorrect scaling.
> >
> > It is also possible that the last printer has a smaller printable area
> > (due to the paper feed mechanism).
> >
> > The Epson S21 is a very cheap inkjet printer - if (as seems likely) it
> > is not a postscript printer, you are probably using some other software
> > (e.g. Ghostscript) to rasterise the output of your Perl program - this
> > is another area where small differences in output might be introduced.
> Thank you for your answer. I had not thought about the (possible lack of)
> postscript support by the printer. I've contacted their support..
The printers themselves probably have no PostScript interpreters
built in at all (e.g. the Epson Stylus S21 seems to be a low-cost
ink jet printer) - that is (or was) typically in the realm of high-
end printers. It's rather likely that there's a PostScript inter-
preter somewhere in the chain of commands executed when you print
something that converts the PostScript to something your printer
understands.
You don't write what kind of system you're using. On Linux you
might be using e.g. ghostview behoind the scenes, and in that
case I wouldn't put too much hope on contacting the printer's
support guys - then the people that take care of ghostview are
the onces to ask. Also note that printers may not be able to fill
a complete A4 page, they may have some margins which always will
be left blank. And if you try to put more onto a page than the
printer can physically deal with you're going to lose some part
of what you want to print - either both at the top and the end
or, more commonly, all at the end.
If you're looking for a possibly simple fix then putting something
like
0.95 dup scale
somewhere at the top of the file to print could make go the problem
away (but it unfortunately might be quite a bit more difficult if
the PostScript created is rather complicated!) - it tells the Post-
Script interpreter to scale down the whole page by 5%. If that
leads to the page being not properly centered an additional
x y translate
could do the trick, where 'x' and 'y' are an x- and y-shift
that you have to find out by trial (better use a PostScript
viewer for experiments before you spend too much money on
ink;-)
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
Date: Thu, 09 Dec 2010 10:04:37 -0800
From: sln@netherlands.com
Subject: Re: variables inside a string
Message-Id: <fru1g6t78r84cp9ceg0ns4vlphev3uiol4@4ax.com>
On 8 Dec 2010 13:33:10 GMT, Tina Müller <use-net@tinita.de> wrote:
>sln@netherlands.com wrote:
>>
>> The fact is that if a user knows (or guesses) your statement form,
>> he/she will be able to splice in code, in any construction of eval "".
>
>not only then. it's way simpler.
>consider:
>@{[ system('rm ...') ]}
>or
>${\ system('rm ...') }
>
>
>always remember that interpolation in perl does more than just replace
>$foo with the value of $foo.
Yeah. I'm afraid there is no way around it.
The initial interpolation via form ' eval ""; ' is not the problem, its
the second interpolation during code compilation that does the damage.
use strict;
use warnings;
my @malicous = (
q(@{[ system 'dir a*.pl' ]}),
q( @{[ system 'dir a*.pl' ]}),
);
for my $user_data ( @malicous )
{
print "\n",qq($user_data),"\n";
eval "print '= '.qq(\\$user_data\n)";
print "--> $! - $@\n -------- \n\n";
}
__END__
-sln
------------------------------
Date: Wed, 8 Dec 2010 13:41:10 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: Who will win the battle for control of the web?
Message-Id: <ae6f6127-87e5-4cb4-b2d2-e72601b9f8ec@v17g2000prc.googlegroups.com>
On Dec 8, 1:41=A0pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> > Server side Perl emits files,
>
> No, it emits HTTP responses. A "file" is something on a disk (or similar
> storage device), an HTTP response is a message in a communication
> protocol.
My bad, I spoke informally and take your point. Maybe I should have
said 'stream' which when written to a filehandle becomes a file, and
when written as a response to an HTTP request gets sent out to the
requester.
> I don't understand what you mean by "a file that will produce a rich
> internet experience". You can of course create any file from Perl. =A0But
> for some it would be foolish: If you want a .class-file, you use an
> existing Java compiler, you don't write a new Java compiler from scratch
> in Perl (But you might write a Perl compiler which emits Java byte code
> in Perl). If by "a file that will produce a rich internet experience"
> you mean a single file which contains the application and can be put on
> a server and downloaded by the browser, then that consists mostly of
> code (which has to be written), auxiliary data like icons, animations,
> sounds, text, (which has to be produced) and a bit of packaging around
> that. There's is not much room for a server-side programming language in
> producing such a file: When the programmer is finished, its static
> (although the programmer may of course use scripts to automate the
> creation of some of its parts). The server side programming language
> only comes into play, once the browser downloads the file and starts
> executing it: Then the application will "phone home" and request data
> which may be delivered by a piece of Perl talking to a database, for
> example.
Yes. You will have to read the article -- I was responding to it, and
my context was that of the article. Quoting therefrom: "A series of
critical breakthroughs =96 massively increased bandwidth, the demand for
rich media, cloud computing, the advent of wireless connectivity and
the rise of mobile devices =96 has created the foundations for the next
generation of rich internet-based apps." Notice the words NEXT
GENERATION.
The technologies considered are very different:
*Flash - "Today, more than 75% of web video is delivered via Flash and
more than 99% of internet-connected desktop computers can view Flash
content, according to Adobe."
*Silverlight - "Crucially, Microsoft has also created a lightweight
subset of the full WPF specification called Silverlight and a cross-
platform, cross-browser Silverlight player that developers can target
primarily using C# or Visual Basic."
*Apple - Targets internet enabled devices, like phones and tablets, on
top of iOS, and really constitutes a category apart from our usual
concept of Wintels running browsers.
*Google - "But the strongest performer of all in terms of rising
market share =96 with a staggering 886% year-on-year growth in Q2 2010 =96
and the new US smartphone market leader with 34%, is Google Android."
*HTML5 - ... and all the rest of the open universe, including CSS and
JavaScript.
Obviously, these are very different technologies, using a variety of
tools: proprietary frameworks, C#, VB, Objective C, iOS and Android,
targeting different types of devices: computers, phones, pads, and who
knows what else. Not to mention that a number of these rely on Java
and even C and C++.
> > Seems to me that, in this brave new world of internet enabled devices
> > everywhere, that Perl needs to evolve or else become a niche language,
> > rather than the 'glue of the internet.'
>
> > It also seems to me that the Perl community is oblivious to these new
> > developments, fat, happy, barefoot, and dumb. OTOH, it wouldn't
> > surprise me to see a new PM that will produce something like this, but
> > I think it will come from a new generation.
>
> Again, you haven't provided the slightest reason why you think so.
What's missing in the discussion? A decade ago, I was writing dynamic
web pages tied to databases using Perl and CGI, basically rolling my
own, building my own 'framework.' Today, I'm still doing the same
thing, in another context, building graphical front ends to databases
that run on users' browsers. A good friend of mine, working for a
large employer, writes web apps using Flex (and swears by it) that I
can't touch with Perl, unless I hand roll my own with AJAX type stuff.
What's missing from this discussion is the role of Perl, and according
to Tad, has so little to do with Perl that the entire discussion is OT
in c.l.p.m. I don't suggest that anything written in Perl can rival
Flash, or iOS, or Android, or the like. I also don't suggest that Perl
has a place on the client (remember client side PerlScript?).
You can produce a lot of good stuff using MySQL, R, and Perl, and I
don't think this stack can be beat for statistical operations. What I
am thinking is some sort of stack involving a database, Perl, and some
other technology, might be able to compete head to head with some (if
not all) of the technologies considered in the article.
Quite frankly, I'm surprised that no one is talking about it.
CC.
------------------------------
Date: Thu, 9 Dec 2010 20:22:50 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Who will win the battle for control of the web?
Message-Id: <slrnig2b4a.l25.hjp-usenet2@hrunkner.hjp.at>
On 2010-12-08 21:41, ccc31807 <cartercc@gmail.com> wrote:
> On Dec 8, 1:41Â pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
>> >
>>
[...]
>
> Yes. You will have to read the article -- I was responding to it, and
> my context was that of the article.
That article is exclusively about the client side. It doesn't talk about
the server side at all. So it is almost completely irrelevant for perl,
except that some proprietary technologies (Flash, Silverlight) may be
more comfortable talking to a server side from the same vendor. However,
the article is very clear that HTML5 is to be considered one of the
major platforms, probably even the most important one:
| There’s a surprising degree of agreement between all the experts we
| spoke to that the best option for delivering a project is HTML5,
| wherever possible.
[...]
| However, with enthusiastic browser support from Apple, Google, Adobe and
| Microsoft, it looks safe to say that the HTML-based web will remain the
| dominant internet platform, and that HTML5 will take it into new
| territory.
And Perl (on the server side) plays nicely with HTML5 (on the client
side), so the answer for Perl programmers is to learn JavaScript (if
they don't know it already) and write hybrid Perl/JavaScript
applications. Probably nothing new for most web programmers, since - as
I pointed out earlier - there were always different languages on the
client and server side.
>> > Seems to me that, in this brave new world of internet enabled devices
>> > everywhere, that Perl needs to evolve or else become a niche language,
>> > rather than the 'glue of the internet.'
>>
>> > It also seems to me that the Perl community is oblivious to these new
>> > developments, fat, happy, barefoot, and dumb. OTOH, it wouldn't
>> > surprise me to see a new PM that will produce something like this, but
>> > I think it will come from a new generation.
>>
>> Again, you haven't provided the slightest reason why you think so.
>
> What's missing in the discussion?
A sense of how things fit together. You are throwing operating systems,
programming languages, SDKs, content formats, client- and server-side,
etc. all together, and the result is just a big mess with strange
conclusions.
> A decade ago, I was writing dynamic
> web pages tied to databases using Perl and CGI, basically rolling my
> own, building my own 'framework.' Today, I'm still doing the same
> thing, in another context, building graphical front ends to databases
> that run on users' browsers. A good friend of mine, working for a
> large employer, writes web apps using Flex (and swears by it) that I
> can't touch with Perl, unless I hand roll my own with AJAX type stuff.
Well, why don't you? Or use one of the gazillions of existing Ajax
frameworks? If you refuse to do any client-side programming you can't
complain that your apps don't look as nifty as those by people who do
client-side programming (and with a tool which is specifically intended
to produce eye-candy to boot).
> What's missing from this discussion is the role of Perl, and according
> to Tad, has so little to do with Perl that the entire discussion is OT
> in c.l.p.m. I don't suggest that anything written in Perl can rival
> Flash, or iOS, or Android, or the like.
Nobody would write a browser plugin or an operating system in Perl. Perl
isn't a systems programming language. Although I think Flash would hang
my browser less frequently if it was written in Perl :-).
> I also don't suggest that Perl has a place on the client (remember
> client side PerlScript?).
All the stuff the article is about is on the client. If Perl doesn't
have a place on the client (I agree with that) then there simply isn't
any competition between Perl and these technologies.
Perl has a role on the server. And by server I also mean cloud
computing. Perl has had frameworks for distributing tasks across the
network for a long time, maybe with cloud computing these will see more
use.
> You can produce a lot of good stuff using MySQL, R, and Perl, and I
> don't think this stack can be beat for statistical operations. What I
> am thinking is some sort of stack involving a database, Perl, and some
> other technology, might be able to compete head to head with some (if
> not all) of the technologies considered in the article.
Doesn't make sense since none of the technologies considered in the
article include a server or database part.
What you would do is combine one of the technologies considered in the
article (HTML5, most likely) with Perl and a database and build an
application framework. Actually, I think quite a few people have already
done that - at least always hear the web programmers I know (those that
use Perl) about using Catalyst together with this or that Ajax
framework.
> Quite frankly, I'm surprised that no one is talking about it.
Go to a Perl workshop and you will hear people talking about it.
I think there are just too few web developers in this group. But then
this group is about Perl, not about web development, and the questions
relevant to web development are mostly not Perl-specific, so they
wouldn't be on-topic here, anyway.
hp
------------------------------
Date: Thu, 9 Dec 2010 13:40:47 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: Who will win the battle for control of the web?
Message-Id: <3f9f7f34-ecbc-46d0-b200-d8ce60cca1cb@n2g2000pre.googlegroups.com>
I agree with almost everything you say. I think the POV of the article
was not server side vs. client side, or open vs proprietary, or
applications vs operating systems, or traditional computers vs
internet appliances. I think the POV of the article was providing
users (what has been called) a 'rich internet experience.' Whatever
that means, and I agree with you that it's more of a concept than a
clearly defined term.
On Dec 9, 2:22=A0pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> That article is exclusively about the client side.
In a sense, but it also considers iOS and Andriod, which are operating
systems, and the .NET platform, which allows development of
applications in the traditional manner. It also doesn't mention Java,
or the Adobe AIR, which I thought a little curious.
> And Perl (on the server side) plays nicely with HTML5 (on the client
> side), so the answer for Perl programmers is to learn JavaScript (if
> they don't know it already) and write hybrid Perl/JavaScript
> applications.
Where does this leave Perl for the iPhone, iPad, etc.? I read another
article in the last couple of days that speculated that the era of the
'personal computer' was over. I think that rather than consolidating,
the technologies are fragmenting. After all, we still have mainframes,
and people still write COBOL, along with Objective-C, and all the
Android apps. I'm not taking a position, and I certainly don't know
the answer ... I'm really just musing (to call it thinking out loud
would be too much.)
> Nobody would write a browser plugin or an operating system in Perl. Perl
> isn't a systems programming language. Although I think Flash would hang
> my browser less frequently if it was written in Perl :-).
Perl brings things to the table that other languages lack.
Specifically, I think Flash is over used and over abused. People who
know Flash think in can do anything and everything, and I know some
owners/stakeholders who insist on using Flash for everything.
Considering all the different kinds of jobs, I believe that Perl has a
lot more capability than Flash, but Flash gets a lot more press.
> All the stuff the article is about is on the client. If Perl doesn't
> have a place on the client (I agree with that) then there simply isn't
> any competition between Perl and these technologies.
Perl doesn't have a place on the client, but the work product of Perl
surely does. For example, I have produced work using a combination of
Perl and R which should be the envy of every Flash/.NET developer. If
you need to dynamically analyze a mass of data and produce a PDF plot
or graph, I honestly don't think you can beat Perl. The point is that
the PRODUCT of Perl has a place on the client, not Perl itself (which
agrees with your point.)
> Doesn't make sense since none of the technologies considered in the
> article include a server or database part.
Part of the Rich Internet Applications consist content, think Amazon,
eBay, Facebook, even Target, WalMart, and L.L.Bean. You are right,
except all the eye candy without content is meaningless.
> What you would do is combine one of the technologies considered in the
> article (HTML5, most likely) with Perl and a database and build an
> application framework. Actually, I think quite a few people have already
> done that - at least always hear the web programmers I know (those that
> use Perl) about using Catalyst together with this or that Ajax
> framework.
I hope that the number of those belligerents fighting the battle for
the control of the web will expand. I would hate to see a monoculture
of technology in this area. I also think that the capabilities of Perl
can be used to advantage.
Thanks for the discussion, 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 3231
***************************************
