[31987] in Perl-Users-Digest
Perl-Users Digest, Issue: 3251 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jan 2 18:09:44 2011
Date: Sun, 2 Jan 2011 15:09:24 -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 Sun, 2 Jan 2011 Volume: 11 Number: 3251
Today's topics:
Re: Difference between solaris and linux <justin.1007@purestblue.com>
Re: Difference between solaris and linux <sherm.pendley@gmail.com>
Re: how do you make perl to c++ translater <hjp-usenet2@hjp.at>
seven languages <cartercc@gmail.com>
Re: seven languages <sherm.pendley@gmail.com>
Re: seven languages <apeiron@isuckatdomains.net.invalid>
Re: seven languages <cartercc@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 31 Dec 2010 12:00:34 +0000
From: Justin C <justin.1007@purestblue.com>
Subject: Re: Difference between solaris and linux
Message-Id: <28t0v7-25p.ln1@zem.masonsmusic.co.uk>
On 2010-12-30, James <hslee911@yahoo.com> wrote:
> Perl scripts with the following first line works in Solaris but fails
> in Linux. Is there a way to make it work in Linux?
>
> #!/bin/env perl -w
> or
> #!/bin/env perl # comment
Sure, move perl to /bin/env - what might be a little easier is building
perl on Linux with /bin/env as the target destination, then you can be
sure that everything is in the right place.
Good luck.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Fri, 31 Dec 2010 07:28:51 -0500
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: Difference between solaris and linux
Message-Id: <m2fwtef7ng.fsf@sherm.shermpendley.com>
Justin C <justin.1007@purestblue.com> writes:
> On 2010-12-30, James <hslee911@yahoo.com> wrote:
>> Perl scripts with the following first line works in Solaris but fails
>> in Linux. Is there a way to make it work in Linux?
>>
>> #!/bin/env perl -w
>> or
>> #!/bin/env perl # comment
>
> Sure, move perl to /bin/env - what might be a little easier is building
> perl on Linux with /bin/env as the target destination, then you can be
> sure that everything is in the right place.
Eh? /bin/env isn't a directory, it's an executable.
sherm--
--
Sherm Pendley
<http://camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Fri, 31 Dec 2010 13:09:03 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: how do you make perl to c++ translater
Message-Id: <slrnihrhuv.l2t.hjp-usenet2@hrunkner.hjp.at>
On 2010-12-31 10:24, Martijn Lievaart <m@rtij.nl.invlalid> wrote:
> On Thu, 30 Dec 2010 21:51:25 +0100, Peter J. Holzer wrote:
>> Once upon a time the answer was "because it's hard to do properly and
>> perl runs on many hardware platforms and you'd have to write a compiler
>> for each of them". Nowadays x86 and x86_64 are probably the only
>> important hardware platforms for perl, so what remains is "because it's
>> hard to do properly."
>
> So I must be doing something wrong with my Perl programs on PowerPC?
>
> (Hint, AIX is alive and kicking)
Yes, we considered buying a mid-range p-series system last year. The
Power architecture is especially interesting for Perl because it
supports base-10 floating point in hardware (though the perl port
doesn't take advantage of it yet, AFAIK).
But in pure numbers Power (and Sparc) are probably negligible compared
to x86-based systems (I have no idea about ARM - the market is huge, but
I don't think Perl is very popular on embedded systems). This is very
different from the mid-1990's, when PowerPC, Sparc, Alpha, MIPS, PA-RISC
and x86 all had roughly similar market shares on systems running perl.
So today, if somebody writes a compiler which works only on x86 and
x86_64, I think it would have a good chance of being accepted into the
core because it covers 90+% of the perl installations. If you want to
use Perl on Power, you'll be stuck with the good old interpreter - tough
luck.
hp
PS: There is a JIT compiler for Perl
(http://search.cpan.org/~rurban/Jit-0.04_09/), but it's in a very
early stage of development (doesn't even do loops yet). According to
Reini it's "really simple, just a lot of work".
------------------------------
Date: Fri, 31 Dec 2010 06:52:20 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: seven languages
Message-Id: <5e68512a-c82b-41c5-b05a-361e9840fe2c@k25g2000vbl.googlegroups.com>
Got 'Seven Languages in Seven Weeks' by Bruce Tate for Christmas and
have just finished my first quick read through. It's a pretty easy
read if you don't pay attention to understanding the code, and well
worth reading through.
My initial impression is that big, general languages for solving
general programs (like C++ and Java) will probably become less
important, while small, specialized languages for solving particular
problems will become more important. I can see developers knowing a
dozen languages, which they would use in their work, much as a
carpenter would use a saw, hammer, wrench, etc. In fact, we already do
(HTML, SQL, CSS, JavaScript, LaTeX, XML, etc.) The chapter on Prolog
really showed me how a hard problem is easy with the right tool.
I use Perl mostly for database stuff, munging data, producing reports,
etc. I am not a developer or programmer -- just someone who uses Perl
as a tool to accomplish everyday tasks. As I read through 'Seven
Languages' I thought about how I could use each language in my work.
Each language has its strengths, but for particular jobs, Perl can't
be beat. Obviously, each language can best solve the class of problems
it was designed for ... but this includes Perl as well.
The other thing that struck me was the problem of deploying programs
to users. If you can't compile a program to an executable (using C,
perhaps), or bytecode for the JVM or CLR, you are pretty much out of
luck. I think that languages like Scala and Clojure, which target the
JVM, will continue to attract new users. Unfortunately, you can't
write a program in Perl, have a lay user install it on the machine,
and have it run with nothing more (as you can an exe, or a program
compiled to run on the JVM or CLR.) This is a big obstacle for Perl.
Anyway, I enjoyed my first reading of 'Seven Languages.' I can't say
that I'll study all seven, but several have piqued my interest enough
to put them on my private calender for a closer look (Erlang, Clojure,
Ruby, and Prolog).
All the best for the coming New Year, CC.
------------------------------
Date: Fri, 31 Dec 2010 13:58:00 -0500
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: seven languages
Message-Id: <m262u93h3b.fsf@sherm.shermpendley.com>
ccc31807 <cartercc@gmail.com> writes:
> Unfortunately, you can't
> write a program in Perl, have a lay user install it on the machine,
> and have it run with nothing more
CamelBones users can do just that - although it admittedly helps a
great deal that Mac OS X (unlike Windows) already includes a copy of
Perl right out of the box.
Some apps that use it:
DVD Spanner: <http://photography.sergeant.org/dvdspanner/>
PerlPad: <http://perl-pad.sourceforge.net/>
Atlantis: <http://www.riverdark.net/atlantis/>
The Perl code, and all prerequisite modules needed by each app, is
packaged into a completely self-contained .app bundle, which can be
installed by drag-and-dropping it to wherever the user keeps his or
her apps.
sherm--
--
Sherm Pendley
<http://camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Sat, 1 Jan 2011 10:08:42 +0000 (UTC)
From: Chris Nehren <apeiron@isuckatdomains.net.invalid>
Subject: Re: seven languages
Message-Id: <ifmufa$ir9$1@news.eternal-september.org>
On 2010-12-31, ccc31807 scribbled these curious markings:
> Unfortunately, you can't write a program in Perl, have a lay user
> install it on the machine, and have it run with nothing more (as you
> can an exe, or a program compiled to run on the JVM or CLR.) This is a
> big obstacle for Perl.
Incorrect. There are packaging solutions like cava
(http://www.cava.co.uk/) and CPAN tools like PAR::Packer. Beyond this,
certain firms are working to make this even easier. And who said you
can't ship your program using the nullsoft installer or the like, and
just bundle a copy of Strawberry and your app code installed in a
local::lib? If your user can install winamp (whence the world got the
nullsoft installer), they can run a bundled installer of this sort.
Your statement may have been more accurate 10-15 years ago, but these
days it's simply not the case.
--
Thanks and best regards,
Chris Nehren
------------------------------
Date: Sat, 1 Jan 2011 07:03:48 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: seven languages
Message-Id: <2bf73466-4b78-46b5-b48b-984be67bb53a@z19g2000yqb.googlegroups.com>
On Jan 1, 5:08=A0am, Chris Nehren <apei...@isuckatdomains.net.invalid>
wrote:
> Incorrect. There are packaging solutions like cava
> (http://www.cava.co.uk/) and CPAN tools like PAR::Packer. Beyond this,
> certain firms are working to make this even easier. And who said you
> can't ship your program using the nullsoft installer or the like, and
> just bundle a copy of Strawberry and your app code installed in a
> local::lib? If your user can install winamp (whence the world got the
> nullsoft installer), they can run a bundled installer of this sort.
I stand corrected, and I should have known better. Several months ago,
I posted to c.l.lisp about this issue, specifically mentioning NSIS,
which I have used on a couple of occasions.
Firstly, using NSIS is certainly an acceptable solution. Not as clean
as using an environment already on the client's computer, and subject
to the criticism that you are demanding the user install other
software, but it's easy and it work.
Secondly, Lisps tend to have a way to do this built in to the
implementation. For example, clisp has ext:saveinitmem that will save
an image that a user without a lisp can install and run.
Unfortunately, every Lisp is different, but if it's important, you can
$$$ a commercial implementation that produces an exe.
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 3251
***************************************
