I'm looking for a light and portable perl release and found this one, but it seems there is no activity since 2003, which could be ok for me but I want to know if there is known issues.
So, if you can provide me some feedbacks, you're wellcome :)
From my experience, the best way to make distributable Perl scripts for Windows systems is to use a packager like PAR::Packer or ActiveState's PerlApp.
Of course this only works if you don't need to do anything on the fly. But it works really well if you have a collection of scripts that you want to move around and use on many systems.
As a replacement for .bat files, as you indicate in your comments, I have found that I can install enough CPAN modules with Strawberry Perl to make more-or-less cross-platform Perl scripts.
See also Is there a portable Perl? which points to the portable version of Strawberry Perl
There is also a Portable Perl from PortableApps
NB: I have used neither one
Related
I am using Crimson Editor as a text editor and I think it suports only Active Perl as a compiler. I downloaded some new CPAN modules for emailing etc etc. I added them in Perl library but program still doesn't recognize those modules. Can you please help me? Is Active Perl doesn't support any extra modules? If so, what do you suggest me for Perl compiler?
Is Active Perl doesnt support any extra modules?
It does, but it has its own way of doing it called PPM. Because many Perl modules require Unix tools and a C compiler, these are pre-built for you. Unfortunately these packages are often well behind CPAN release and are often missing CPAN modules altogether.
If so, what do you suggest me for Perl compiler?
On Windows, I'd recommend using Strawberry Perl. It comes with a full environment necessary for building and installing Perl modules, including a C compiler. Then you can install things using the normal CPAN tools like cpan or cpanm.
I am using Chrimson Editor
It doesn't look like that editor has been updated in over 10 years, and it's very Windows specific. I'd suggest an editor like Sublime Text. It's cross-platform, so you're not stuck with a Windows-specific editor, it has good Perl support, and it's kept up to date.
I would also not get too attached to relying on your IDE to do all your compiling and running of code for you. If you do, you're limited to what your IDE supports, and your IDE can get in the way of understanding your tools. Instead, I'd suggest getting used to using the tools directly. Learn how to use Perl on the command line rather than via the IDE.
I've done some research and it seems like ActivePerl had issues with earlier releases of it's product with certain CPAN modules not installing properly. However, I'm running the 5.14.x version and I've not had any problems.
According to some quotes I've seen:
ActivePerl is 100% compatible with the reference distribution of Perl.
Code tested with ActivePerl will run on any Perl installation that has the appropriate extensions installed.
I assume that the first statement refers to the standard modules you get with the Perl installation and for the second, I'm not sure what they are saying?
In any event, is there any way to find out how compatible ActivePerl is with the current CPAN modules or is that something that isn't known? I just don't want to spend time with it, only to have to switch to something like Strawberry Perl next month to avoid CPAN module build failures for the more common modules.
If ActivePerl is compatible with say 80% or higher with the CPAN modules I would feel more comfortable about using it, but I couldn't find any information on this.
I doubt a generic statistic will be that useful. In general I would expect all "pure perl" modules should work more or less out of the box. Keep in mind however that certain perl modules really are interfaces to lower level linux/unix style shared libraries (dlls in Windows terms), where availability is less certain. In my experience (having written a few perl applications being hosted on Windows, against my advice) most things will work, and/or are fairly easy to work around, and both ActiveState and Strawberryperl seem to have decent support for most common modules.
The first statement doesn't refer to modules at all. It says that ActivePerl is not based on Perl, it is Perl. As such, anything that will run on Perl will also run on ActivePerl.
This also means that all modules on CPAN are compatible with ActivePerl since ActivePerl is Perl.
Whether a module is compatible with Windows is an entirely different question, and it can only be answered on a module-by-module basis.
The second statement points out that if you had a script or module that runs on a pristine ActivePerl, it might not necessarily run on a pristine Perl because ActiveState includes modules in its distribution that aren't core modules (e.g. LWP). But all you'd need to do to make the script or module run on the other distribution is to install those modules.
You can check on the availability of PPM modules at http://code.activestate.com/ppm/. For example, one module that doesn't work well through PPM is PAR::Packer.
I want to practice Perl in Windows Vista 32bit, how can I do it ?
Thanks.
Just an alternative to active perl is strawberry perl, each has it's own merits to use, but I would say that the initially active perl is better implemented (for instance it implements the .pl extension by default, adds perl to the PATH variable etc.) but strawberry perl makes it incredibly easy to install new modules, and generally is really good to use as well.
download Active perl and enjoy
http://www.activestate.com/activeperl
You can use ActivePerl.
ActivePerl is a good Windows Perl interpreter
I've written any number of perl modules in the past, and more than a few stand-alone perl programs, but I've never released a multi-file perl program into the wild before.
I have a perl program that is almost at the beta stage and is going to be released open source. It requires a number of data files, as well as some external perl modules -- some I've written myself, and some from CPAN -- that I'll have to bundle with it so as to ensure that someone can just download my program and install it without worrying about hunting for obscure modules.
So, it sounds to me like I need to write an installer to copy all the files to standard locations so that a user can easily install everything. The trouble is, I have no idea what the standard practice would be for this. I have found lots of tutorials on perl module standards, but none on perl program standards.
Does anyone have any pointers to standard paths, installation proceedures, etc, for perl programs? This is going to be complicated by the fact that the program is multi-platform. I've been testing it in Linux, but its designed to work equally well in Windows.
Take a look at PAR and PAR::Packer. You can bundle all of your requirements (even non-Perl requirements) into one file. With PAR::Packer, the user doesn't even need to have Perl installed for it to work.
You might also look at how the various App::* distributions are setup.
The standard installers for modules (ExtUtils::MakeMaker, Module::Build, Module::Install) also work the same way for scripts.
Using such a standard Perl tool will help you to:
distribute your application on the
CPAN (and you'll benefit from
automated tests on various platforms
by CPAN Testers), and so your app
will be installable (with all its dependencies) from the CPAN
shell
help packagers of Linux/BSD distributions to make packages for your product
ActiveState Perl installs an IIS script mapping for the extension .plx. Is this actually used in real life or just something specific to ActiveState?
No, it's not just from ActiveState. O'Reilly's Learning Perl on Win32 systems recommends naming scripts with a .plx extension to disambiguate them from perl modules (with .pm) and non-executable perl libraries (.pl). Nowadays however I'd name anything that is going to be directly run as .pl.
This is a matter of personal preference. It is not something unique to ActiveState. PLX stands for Perl Executable Script which is perhaps a bit more defined then PL which stands for Perl Script (apparently originally Perl Library as another user wrote). However, on CPAN you see numerous places where PLX is used as extension so it is perhaps not so rare as it seems:
On CPAN acx.plx
kobesearch.cpan.org on SerialPort
tag.plx on CPAN
etc.
UPDATE: here's an earlier discussion of the same discussing whether *.pl or *.plx should be used. It also mentions that Prolog uses *.pl as well and playlist is yet another use.
Google shows some matches and there are quite a few of them on CPAN. In fact, originally, .pl stood for 'Perl library'.