I 'downloaded ' PERL version 5 16, Active Perl , and I can NOT get "my " screen to match what...

[G+_Neil Tsubota]

I 'downloaded' PERL version 5.16, Active Perl , and I can NOT get "my" screen to match what I saw in this episode. Any help would be greatly appreciated.

[G+_Joe C. Hecht]

Half the battle is in knowing how to ask a question, and this is no exception. Since we cannot see your screen, we have not the slightest clue as to what might be wrong. You did a great job telling everyone what your screen is "NOT" showing. For all we know, the problem might be that you just need to turn it on. Why not try telling what your screen "IS" showing, so we might be able to help :)

[G+_Joe Maruschek]

Neil Tsubota It might help that all the code warrior stuff was NOT done with Active Perl; it was done on a Mac using the Perl that comes with OS X. The editor was Emacs and everything was done inside of Terminal.app.

To match Padre's computer as it looks during the ivory tower segment, set up Notepad with the font size set very big, and change the default color of the command window to have green text. Hope that helps.

[G+_Mike Swanberg]

Perl is extremely cross-platform, so "pure" perl that runs on a Mac will 99.99% likely also run on Windows. I write perl on both platforms and have few issues.

[G+_Joe C. Hecht]

Mike Swanberg I love Pure Perl code. It works everywhere, and installing a module is usually as easy as simply using it.

 

Perhaps my biggest gripe about Perl is installing new modules. While it is easy under Linux, it can be almost impossible under Windows or the Mac. If you are using ActiveState, it is easy, so long as they have already made it available, else you are on your own. Also, ActiveState often (understandably) lags way behind in offering updated modules for 3rd party modules. Using other Perl distros under Windows also means a lot of toolchains will get installed may mess with my development environments.

 

In short, I try to use modules that offer "Pure Perl" code wherever possible.

 

TJoe

[G+_Mike Swanberg]

Installing modules (and I'll add using more recent core features like 'say' and push-on-arrayrefs) is indeed the bane of most perl hackers. That was why I ponied up for the perl Dev kit, which includes a compiler (which works way better than PAR's pp). Much easier to distribute, but not cross-platform, of course.

[G+_Joe C. Hecht]

Mike Swanberg I make heavy use of Active State's PerlDevKit around here to do cross platform work (producing 32 and 64 bit modules for Windows, Linux and the Mac).

 

You say it's not cross platform, so I am wondering in what sense do you mean?

 

In reality, I do not think they actually compile the code into machine code, or perhaps, it is partially compiled into some sort of bytecode. I say this, because the "exe" produced will actually unpack a (sometimes large) number of temporary shared object files, containing a Perl interpreter,

along with the other modules your code relies on (creating a great signature showing that even "that company in Redmond" sometimes uses it.

 

I do believe I recall situations where the PDK was unable to produce a executable for a given platform, complaining about a given module, leading me to replace the code with a PerlPerl implementation that fixed the error, so I would say that it cannot produce a cross platform executable for

a module that links to machine code that it cannot find a like "precompiled" module.

 

I'm thinking that when they say "compiled", they actually mean "slickly packaged".

 

The PDK is a GODSend around here. I have even had quite a bit of luck with ActiveState's VB Script converter (converts VB script to Perl code), and have often made very good use of the ability to create DLL's from Perl code that can interface with other languages and make fast work of many chores that are very easy in Perl.

 

TJoe

[G+_Mike Swanberg]

Joe Hecht Perhaps I need you to teach me something. So, the Windows version of the PDK can create executables for other platforms? I do realize that the PDK itself has different versions for different platforms, but I was under the understanding that my .exe could only be run on other Windows platforms. Please educate me if I'm wrong. Note: I've barely scratched the PDK... mostly the debugger is what I use. Would love to get into DLLs and services and such. But as such things go, I haven't had a pressing need for it yet.

 

I worry less about CPAN (or PPM) distributions than I do about perl versions and distributing my own modules. Creating application packages just makes things easier (and self-contained).

 

You are correct that it's just a self-extracting executable with the perl engine and the libraries packaged up, a la PAR or JAR. But the perl engine does actually compile the code (that it can) for execution in a just-in-time manner. Semantic argument, that, but true nonetheless.

 

There are other manners of distributing code... PARs themselves were created to aid in that endeavor. But it makes the execution far more kludgy, so if I'm making apps for others, I'd prefer they don't require manuals or shell scripts just to get them to work properly.

[G+_Mike Swanberg]

I have often wondered... What if I just copy my .pm files into my main .pl, add a 'package main;' before the main code and see if that works... thoughts?

 

I know it breaks the idea of .pm modules to begin with, but keeping a program that includes dozens and dozens of modules running properly is no easy feat. Especially when you look at old modules and think, "ugh, there are tons better ways to do that... but fixing this module would break many dozens of programs."

 

Note, my perl development is low-level down-n-dirty apps, so I don't get into 'require version blah blah'. Mainly, more headache than I need. But maybe I've reached that point.

[G+_Joe C. Hecht]

Mike Swanberg At one point in time, I used the Perl Developers Kit (PDK) in Windows to directly create executables for other platforms, I do things a bit differently these days, so I may miss making a home run during this explanation, and go ahead and prefix everything I say with "IIRC" (if I recall correctly). OK?

 

Hoep this helps:

 

The PDK is available for a number of platforms (Windows x32/x64, Mac "native", Linux x32/x64, Solaris, AIX, etc). The purchase of one license entitles you to copies (and license files) for the PDK on all the available platforms.

 

FWIW, I do not think that the PDK can produce a 32 bit executable for the intel oSX Mac (or is that a x64 bit - I forget - its one or the other, but not both).

 

The PDF requires one (or more) copies of ActiveState Perl to be installed, and the free "community edition" work fine. ActiveState keeps only the latest "community edition" (and at times perhaps one previous edition) available for download at any given time. Users who subscribe to the Business Edition (pricey) have access to all previous versions of

ActivePerl. Personally, I believe that perhaps when two versions of the "community edition" are available, they are still working out kinks in the latest one offered.

 

I believe (again IIRC) if you have the latest version of Active Perl installed, you can build an executable for a different platform than

the native platform you are building on. For example, you could build an executable for Linux under Windows. The executable will be named (and perhaps placed) differently. For example, under Windows, "MyProject.pl"

will compile to "MyProject.exe", and simply "MyProject" for Linux. I believe "MyProject" for Linux will end up in a different directory (something like \Linux-X32\MyProject). When you build for a different platform, the PDK will go and download the needed package source and binaries for the platforms needed (and again, it will only support the "current version"

of ActivePerl). I believe there is a way to use other versions if (a) You have a "Business subscription" or (b) you have previously downloaded and built an executables for every platform for each different Perl version using every installed module you ever will use. Painful and disk clogging, and intended to get you to buy the business edition, no doubt.

 

For me, it became a lot to keep up with (downloading, building, package version management etc, and the hiccups involved with all the downloading, installing, and failures). I mean, what happens when I get all settled in with a given Perl version, and I build a new project that uses a new module, and the PDK refuses to download the binaries for xyz platform, all because a newer version of Perl

becomes available). I really did not want to be forced to upgrade on ActiveState's timetable. I do like to stay current, but sometimes, a new version of Perl means code breakage, and that must happen on a schedule, not during a production build that is due out "tomorrow".

 

So, for me, it became a lot more convenient to install the PDK on every build machine we use (for example, with few exceptions, we generally build code for Linux on a Linux box, build Mac code on a Max Box, and so forth). I think the only real exceptions are when building iOS, Android, Windows RT, and Linux ARM based apps - something the PDK cannot do (yet) anyway. I simply install the PDK everywhere, and the version of ActivePerl that I want to live with (for awhile), and use scripts to do the builds, copying the resulting executable files to wherever they are supposed to go. It makes for a stable build environment, something that really counts on a large project.

 

Also, I will mention that when I say "box", I really mean "VM". With few exceptions, all development environments are virtual

machines (usually running on Macs running VMWare Fusion, and sometimes on Windows or Linux running VMWare Workstation). I think the only exception there is we do build code for the Raspberry PI and the BeagleBone directly on the boards themselves.

 

For us, building with the PDK in Windows is a little different. We have two versions of ActivePerl installed (x32 and x64), and two versions of the PDK installed. As we installed each version, we hid the other, so each thought it was the only one on the system.

We then use batch files to set up the environment for each, as they are used. For the most part, builds are also done from the command line, by simply passing the PDK a .perlapp file to compile. We do command line builds of perlapps in other platforms (Mac and Linux) as well, but Windows is the only platform we do "dual" builds for. I believe the default Perl install for our x64 Windows systems is the ActivePerl x32 version, as I believe it may be more stable, and at least at one time, it's supported package list was more complete than the x64 version.

 

As far as using the PDF to make dlls (shared libraries), I believe this capability is (sadly) only available under Windows, and IIRC, must be in the form of an Windows com object. But still, some things can be done in Perl with so little code, and the solution is so elegant, that pushing out a small type library to interface with is a no-brainer compared to actually coding complex solutions that might even involve large scale purchases of specialized libraries. In short, this where the PDK can really shine (very) brightly, allowing you to quickly leverage a ton of 3rd party, freely available, and (usually) well tested code, and hook it up to any language or script that can talk to a com object (and most all do). Even under other platforms where shared object support is missing in the PDK, non time critical

code can be placed in an executable, and fired off from almost any language using an "exec and wait" approach.

 

For anyone needing to do any of the above tasks, the PDK may well be worth it's weight in gold, and should not be overlooked.

 

TJoe

[G+_Joe C. Hecht]

Mike Swanberg For most packages, it will be far more trouble than it's worth.

 

I have a seperate common "module" directory that I use, where I place commonly used modules that are either homemade, or hard to find, difficult to install, or just not part of most distros (across a lot of Perl vendors and platforms).

 

The modules are all "Pure Perl". I find that having to perform maintenance on them is almost non-existent.  I simply add the directory path to Perl's inc path at runtime, and use them at will (see example below).

 

I use this same code for running 19 websites running on shared hosting, plus websites running on 20+ machines that utilize many different Perl distros, all without issue.

 

Example of using lib "SomeModule" located in

 

'../../../common/mods/perl/SomeModule'

 

 

 

BEGIN {

  use lib '../../../common/mods/perl';

}

use SomeModule::SomePackage;

 

 

Hope that helps!

 

TJoe

[G+_Mike Swanberg]

Ugh, I loathe BEGIN blocks unless truly necessary.  I keep modules in a common location too, easily backed up.  I just make it part of my perl5lib environment variable (along with "." -- the current working folder -- for modules created for a very specific project).

 

I'm not doing perl near to the level you are, but this is some great info.  I'm a little confused about building for "other" platforms.  Will it only work on pure perl modules?  Otherwise, you'd also have to have a gcc and associated libraries for compiling non-perl modules into binaries for other platforms.

 

BTW, Neil Tsubota , sorry for hijacking your post  :-)

[G+_Joe C. Hecht]

Mike Swanberg Using a begin block works well to dynamically add a relative path to shared modules when you have a lot of dependent code from many virtual sites running on many different servers (some hosted), and on several different Perl distros, and when you may not have the access rights to make administrative changes on the system. At least that is how I solved the issue.

[G+_Mike Swanberg]

Yes, I suppose if you don't have access to manipulate the target environment, it might be the only real way to include your own modules.  But if that's the case, I would be petitioning my IT folks to get me access on that server, or else give "installation instructions" for whoever does.

 

I have full access to my server, and anywhere else I would just distribute a full executable wherever possible.

 

Incidentally, I think this is the trepidation for most shops to using perl.  Without a fully-compiled executable or at least an archive (e.g. PAR), there is potential for much mayhem in updating modules.  That could easily break a lot of working code.

 

Otherwise, I really can't imagine why shops detest perl so.  My application (written in COBOL on a mainframe) is moving to Linux soon and I told the boss-men that I could have them a working system in a week in perl.  But they would rather get contractors and make a huge deal out of the move, just to have it in Java.  Irks and confuses me.