Re: Perl on Windows Best Practices?
by BrowserUk (Patriarch) on Jul 30, 2012 at 21:14 UTC
|
About half the PCs are XP/x86, and the other half are Windows 7/x64
Put a 32-bit perl on a network share. Give anyone wanting perl access to that share and set their assoc .pl to point to that shared perl. 32-bit Perls run perfectly on 64-bit Windows.
If there are some scripts that need/benefit from using a 64-bit perl, install a 64-bit perl on teh same share (different) path and set up associations for that using a different file extension (say .p64).
A similar set of associations for files named .pl run the 32-bit perl.
You have 2 centrally maintained, universally accessible builds of perl that everyone can use.
Getting them to use them is then a matter of political will and company process.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: Perl on Windows Best Practices?
by roboticus (Chancellor) on Jul 30, 2012 at 20:53 UTC
|
KevinZwack:
Try using forward slashes instead of doubled backslashes for UNC names. That works just fine with cygwin--at least *here* it does:
#!/usr/bin/perl
use 5.14.0;
use warnings;
use autodie;
open my $FH, '>', '//npckfs01/users/301058/ZOOG';
print $FH "The quick red fox, etc. etc. etc.\n";
close $FH;
...roboticus
When your only tool is a hammer, all problems look like your thumb. | [reply] [Watch: Dir/Any] [d/l] |
Re: Perl on Windows Best Practices?
by bulk88 (Priest) on Jul 31, 2012 at 01:04 UTC
|
I personally use ActivePerl or self compiled VC Perl (same thing). As other said in the thread, more XS things compile on 32 bits than on 64 bits. Windows is kindda a deprecated platform for Perl. In the late 1990s and early 2000s, Microsoft (through AS) and ActiveState/Hip poured a ton of resources into creating Win32 Perl. All that went dead when .NET came out (AS Perl.NET was the last Perl thing MS ever funded I think), or when MS realized that Perl can't be compiled to .NET CLR bytecode and "embrace extend extinguish" wouldn't work with the Perl crowd.
Cygwin Perl I don't recommend, it seems to get less attention than Mingw and VC Perl from p5p. Between Mingw (GCC) and VC I'm not sure. VC is C89 and MS has repeatedly said since 2008 on their forums/bug trackers that they will not be added any C99 or C11, or any features at all, to VC plain C compiler (C++ is a different story with MS). Many non-Perl POSIX-ish FOSS projects (which can wind up as XS modules in Perl) have formally abandoned compatibility with VC and say "we only support and use GCC C [time for MS to grow up/peer pressure on MS to adopt C99/C11]". But with VC Perl, I think its easier to debug the Windows vs Perl interaction because of the VC debugging symbols MS offers. But because Mingw Perl is a much newer product in the history of Perl, and includes its own reverse engineered equivalent of Platform SDK, some things that compile for modern VC Perl won't compile for Mingw Perl. Not all VC C code (lvalue casts for example) is valid GCC C code. Mingw Perl's FOSS Platform SDK is often older than the latest MS Platform SDK, so things that want to use Vista/NT6/Win 7 APIs might not compile with Mingw yet (plus AS's PPM build farm uses circa 2002 headers). Then again, you said you want XP compatibility, so Platform SDK age is irrelevant for you.
I believe that Win32 Perl, can use a registry entry in addition to environment variables to determine @INC. Having 1 /site/lib and one /lib on a network share for everyone might be something you want to do. Beware of network latency though, My Network Places paths/mapped paths might cause unacceptably slow Perl interp startups. Then again you said that your IT department refuses to help. Have you considered portable perl installed on a USB stick and give one to each employee? Updating will be a chore. Considered writing a perl script that will update every PC's C: Drive Perl dir once a month over the network?
You don't want Perl Module hell (AKA DLL hell) between your different PCs. | [reply] [Watch: Dir/Any] [d/l] [select] |
|
Beware of network latency though,
Hm. Given modern network speeds, it would have to be a script with a huge number of dependencies for even a 10Mb/s network to require much more than a second or two to load. And does anyone run at less that 100Mb/s these days? Mostly, company LANs are substantially faster.
It would only be a problem if someone was trying to run high-frequency, short lived scripts -- say web-server CGIs -- across the network, but even then, filesystem caching would step in a remove the problem.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] [Watch: Dir/Any] |
|
SMB/My Network Places/CIFS handshaking/latency is slower than any HD IMHO or even HTTP. Look at it in wireshark one day, many handshake back and forth set up stuff, lots of metadata queries on the files, attribute reading and setting, file pointer setting, etc. Dozens or hundreds of sub 100KB files gets slow and will not saturate a network connection mbps wise in my experience between Windows computers. Of course copying files with Explorer and Perl interp starting up and loading PMs are both synchronous I/O. I tried copying my perl dir from 1 XP machine to a Server 2003 machine with Explorer, no HD light flashing on the source machine (the whole perl dir was in read cache from a recent grep of the dir), probably none on the Server 2003 machine (8 GB of RAM, 7 GB probably free), the average was 1-2 mbps up (to dest) and 500 kbps down (from dest) when copying .pl and .pm files, and jumped to 70 mbps and 500 kbps down (from dest) when copying .pdb files. I have a 100mbps ethernet network. I dont think file caching works over SMB connections, atleast with NT 5, since multiple clients or the server itself can read write the file at any time and SMB has no way of pushing cache invalidation messages across the wire or doesn't use them in most cases.
It seems things improved with NT 6, http://en.wikipedia.org/wiki/Server_Message_Block#SMB2. I have no NT 6 machines.
| [reply] [Watch: Dir/Any] |
|
|
|
Re: Perl on Windows Best Practices?
by kevbot (Vicar) on Jul 31, 2012 at 03:40 UTC
|
I have been using the 'PortableZIP editon' of Strawberry Perl to share scripts at work. I use it over the network. So, I uncompressed the Strawberry zip file into a directory on a network share. Now, users can run portableshell.bat from the top-level directory.
This way, one can install cpan modules or your own modules once and everyone will have access to them. The only problem I seem to have with this approach is the occasional cpan module that runs fine on unix but is broken on windows. I tend to develop on a unix machine so I just need to be careful when I start using a new dependency. It's a bit frustrating to introduce a dependency just to find out that it doesn't work on Strawberry.
| [reply] [Watch: Dir/Any] |
Re: Perl on Windows Best Practices?
by 2teez (Vicar) on Jul 30, 2012 at 23:38 UTC
|
I would like to standardize on a single Perl, but which one? (Cygwin, Strawberry, ActiveState?)
-
I presently use both ActiveState Perl and Strawberry on Win7 OS. I preferred Starwberry Perl, for the way it install cpan modules 'out of the box' with little or no effort. However, using ActiveState is also cool but sometimes installing cpan modules could be a nightmare, only that I know how to wake when having bad dreams :)!
-
Plus the fact that Strawberry Perl is A 100% Open Source Perl for Windows that is exactly the same as Perl everywhere else, while ActiveState Perl have binary distributions of Perl for Win32 which is also free.
-
Check this: http://www.perl.org/get.html
for more details.
| [reply] [Watch: Dir/Any] |
Re: Perl on Windows Best Practices?
by dasgar (Priest) on Jul 31, 2012 at 04:01 UTC
|
Others have covered most of the information that I could share on the topic of your post.
About half the PCs are XP/x86, and the other half are Windows 7/x64. Some CPAN modules work on x86 but not x64 (e.g., Win32::SerialPort).
It's been my experience so far that the Win32 modules that I've used on 64-bit Windows work just fine. I guess that could change with future Windows operating systems.
Also, since I personally don't have any scripts needing features like 64-bit integers from 64-bit Perl, I've been using 32-bit Perl on 64-bit Windows without any issues so far.
| [reply] [Watch: Dir/Any] |
Re: Perl on Windows Best Practices?
by sam_bakki (Pilgrim) on Jul 31, 2012 at 12:18 UTC
|
Hi
I also faced similar issues in Windows perl distribution. I have solved by using
1. Install & use ActiveState Perl - Windows x86 version - All the modules builds properly & Work properly in x86 (including Win32::Serialport) in my laptop (Which is Windows 7 , X64 but I have x86 version of gcc to compile CPAN modules which are not available in PPM)
2. Purchased ActiveState PDK - There is utility called perlApp, which will convert your .pl to .exe (and includes all dependencies like .ico, .pm , .dll etc etc..) , Which works perfectly with Active perl.
3. Create x86 .exe version of tools and distribute. (It will work on x86 & x64)
4. Note: Yes, I know, creating .exe will increase size. But there is a option to create a dependent exe which uses installed perl without bundling perl in .exe. But I am fine with the size (usually ~3 MB).
| [reply] [Watch: Dir/Any] [d/l] |
Re: Perl on Windows Best Practices?
by blue_cowdawg (Monsignor) on Jul 30, 2012 at 20:34 UTC
|
Personally I'm partial to ActiveState Perl on WinBloze. Having said that I also make use of the Perl that comes with Cygwin. Both are 5.14.2
Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
| [reply] [Watch: Dir/Any] |
Re: Perl on Windows Best Practices?
by gam3 (Curate) on Aug 01, 2012 at 14:55 UTC
|
| [reply] [Watch: Dir/Any] |
|
Thanks, that made me laugh.
| [reply] [Watch: Dir/Any] |
Re: Perl on Windows Best Practices?
by KevinZwack (Chaplain) on Jul 31, 2012 at 15:27 UTC
|
Thank you all, there are many good suggestions here. I will try these and see if we can get a smoother running Perl infrastructure. | [reply] [Watch: Dir/Any] |
Re: Perl on Windows Best Practices?
by mr.nick (Chaplain) on Jul 31, 2012 at 17:41 UTC
|
mostly in Perl (for over ten years, started with Perl 3)
Eh? Perl 3 came out in 1988 or 1989 and lasted only two years or so until the Camel book came out. Ten years ago would be around be 5.8 or so.
Don't mean anything by that, but "ten years ago" and "perl 3" really don't belong in the same sentence. Hell, "twenty years ago" and "perl 3" don't belong together.
| [reply] [Watch: Dir/Any] |
Re: Perl on Windows Best Practices?
by linuxkid (Sexton) on Jul 31, 2012 at 20:01 UTC
|
I use strawberry when i use windoze, and to install modules, you can do a use CPAN; install Some::Module; with an install Some::Module for each module you need.
--linuxkid
imrunningoutofideas.co.cc
| [reply] [Watch: Dir/Any] [d/l] [select] |