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.
Related
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 need to package a Perl Dancer application for installation using RPM. Pretty much all of the Perl module/distribution tools deal with installing files into Perl specific locations, such as /usr/lib/perl. I need to be able to create an installation in a self contained location, such as /opt/foo.
I know about App::Build, which looks like it might be useful, and provides facilities missing from Module::Build. I expect there might be a Dist::Zilla plugin to do this sort of thing but I've been unable to locate one.
What tools would you suggest using for building, testing and packaging a Perl 'application'?
The layout of the application would follow normal Dancer style, with /public, /views, /lib, etc
You are mistaken in saying that Module::Build is missing the functionality to install additional (non-lib) directories. See the Cookbook.
I don't know if this helps at all. It describes what we do at work:
http://www.slideshare.net/p3castro/packaging-perl
Caveat: we use a common Perl install across all applications.
cpan fails with this weird error as follows
Error: Unable to locate installed Perl libraries or Perl source code.
It is recommended that you install perl in a standard location before
building extensions. Some precompiled versions of perl do not contain
these header files, so you cannot build extensions. In such a case,
please build and install your perl from a fresh perl distribution. It
usually solves this kind of problem.
(You get this message, because MakeMaker could not find "D:\fbl_esc_bcd_tb\tools\perl\lib\CORE\perl.h")
Running make test
Make had some problems, maybe interrupted? Won't test
Running make install
Make had some problems, maybe interrupted? Won't install
Problem is I can't install new active perl versions in this environment and the tool I want to coverage on does not run outside this environment.
Short answer: The ActiveState PPM repository has a precompiled version of Devel::Cover you should be able to install.
Long answer: That's not a normal message from MakeMaker so I'm willing to guess its an ActiveState addition, but its probably true. The problem is exactly what the error message says; your distribution is missing some important files, specifically the C header files for Perl, so it cannot compile C code necessary for modules like Devel::Cover. This is often the result of an overzealous sysadmin or packager looking to save a few dozen K of disk space. You could probably take the header files from the 5.8.7 source, copy them into the CORE directory and it will probably work. It won't make anything worse.
I agree with Evan that, assuming this is a Windows machine, you should switch to Strawberry Perl which plays much better with the rest of the Perl community than ActivePerl.
Otherwise, ActiveState is a commercial company and they have paid Perl support. Give them a ring.
Active Perl does not use CPAN. If you want to use CPAN use Strawberry Perl. Active Perl uses binary distribution through its ppm system. There are a few third party repos for it if the official one doesn't have Devel::Cover -- though the official probably has Devel::Cover.
Most people these days are moving to Strawberry and away from AS. In my opinion, it is far more stable and CPAN-friendly, and surely less proprietary. Also, expect to be able to get stable versions of most everything - AS has been known to lag years in many occasions in the official repos. strawberry also comes with its own compiler and build environment so you can even get ::XS versions working with ease.
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
PLDelphi is a Perl project hosted on CPAN. I am currently working on a Delphi application and I am investigating the possibility of adding Perl scripting support and read about PLDelphi.
Ideally, I'd like my application to not require Perl to be installed. PLDelphi claims to support this:
To use PLDelphi from your Delphi
application without need to install
Perl you will need this files in the
main diretory of your application:
PLDelphi.dll - The PLDelphi
library that loads the Perl
interpreter. PLDelphi.pm - Perl
side of PLDelphi. Perl56.dll -
The Perl library in case that you have
Perl built dynamic. PLDelphi_dll.pas -
PLDelphi classes and DLL wrapper.
lib/* - A Perl lib directory with basic .pm files (strict, warnings, etc...)
I am aware of RemObjects PascalScript and embedding Python in Delphi, but in this instance, I am interested primarily in Perl support.
Has anyone used PLDelphi with success? Or have you found other ways to execute Perl scripts from Delphi without the full Perl installation available locally?
EDIT:
To be more clear, I found 1 potential solution and that is using PLDelphi. However, I'd like to know if anyone has used it (last updated in 2004) before, and how well it worked.
I'm also interested in hearing about any other options for embedding a Perl interpreter with Delphi.
You could use Windows Script Host (which comes with VBScript and JScript by default) and install PerlScript from ActiveState.
Sadly PLDelphi isn't updated for XE3 or 64 bits there for won't work with Perl 5.16
I was really looking for a solution that didn't require installing anything on the client. It appears that PLDelphi is not working with ActivePerl 5.10...so I don't believe there is a ready solution to embedding Perl within a Delphi application.