Learning Perl

[Sherm Pendley]

Is this Usenet?

Didn't you get the memo? It's Usegoogle Netgroups now.

sherm--

 

[Joe Smith]

Yes, yes, yes. I am trying to reach to that stage of having a PC with
Linux. It's not $$ issue. Long story.

FYI: On a PC still running Windows 2000 (or anything else using VFAT
instead of NTFS), you can run 'parted' to shrink the size of the C:
partition, then install Linux on the same disk. The boot process
will then ask if you want to run Linux or Windows at startup time.

The XP machine I use at work has VMware installed, with three
virtual machines. One for RedHat-AS2.1, one for RedHat-ES3, and
one for Fedora Linux. That's one way of being able to run Linux
and XP at the same time.
-Joe

 

[Tassilo v. Parseval]

Also sprach John Bokma:

"Tassilo v. Parseval" <[email protected]> wrote:

You might be right. However, it works most of the times here. I rarely
have to use nmake. As for a C compiler, only recently with PAR.

Once a module is not (yet) available as ppm package you'll most likely
need nmake.

Huh? And AFAIK, you can use the CPAN shell with ActiveState. I stick
with ppm for now.

Quite so, often enough I ended up using the CPAN shell. I've had
numerous problems with ppm in the past: IIRC it doesn't follow
prerequisites so those have to be installed manually. For each
installation you first need to issue a query before installing a
package. I've had cases that a query returned multiple hits for a
module. When I was lucky they had different versions but I also had
cases that a release was reported twice in which case ppm was so
confused that it wasn't able to install any of those. This can happen if
you have specified more than one ppm repository to search.

Upgrading modules often turned out to be a nuisance. Apparently ppm uses
two different commands for installing and upgrading. Even when using the
correct one it didn't reproducibly work for me. Furthermore, ppm never
gives any visual feedback of its doings.

The best part was of course when I upgraded Storable and ppm would no
longer allow me to start its shell. Mind you, I was still able to use it
via command-line ('ppm install ...'). But in this mode ppm is stateless
and you can't first search for a module and then install it. I had to
download the .ppd file along with the .tar.gz and do a local install
instead.

I am citing from memory here and there were some nasty and inordinately
unhelpfull error messages that I no longer recall for a few of those
incidents. Those things date back to the times when I was using Windows
and ActivePerl for learning Perl. Sometimes I still need to fire up
Windows and ActivePerl again for testing things with my modules. With
respect to ppm things haven't improved a lot and so I've stopped
making ppm packages for my modules lest I have to deal with other
people's ppm troubles.

Yup, the reason that I removed it was that it was confusing to me most
of the time

I only used it for Perl. The last time I used it it had wrecked CPAN.pm
for me. Apparently my username (default name given during cygwin
installation) contained a space. So CPAN.pm dowloaded a distribution but
was then not capable of finding it because a path such as

/home/username with space/.cpan/build/Module-$VER.tar.gz

was evidently too tricky to deal with.

Tassilo

 

[A. Sinan Unur]

Also sprach John Bokma:



Once a module is not (yet) available as ppm package you'll most likely
need nmake.

I was lucky(!) enough to have bought MSVC4 way back when, so I did not
have to figure out where to download that: The only time I felt good
about that purchase.

Quite so, often enough I ended up using the CPAN shell. I've had
numerous problems with ppm in the past:

ppm has worked for me without major problems. That does not mean there
was no problems, but rather, no problems I can remember off the top of
my head.

IIRC it doesn't follow prerequisites so those have to be
installed manually.

I don't think this was true by the time I started learning Perl a few
years back.

Upgrading modules often turned out to be a nuisance.

That still seems to be true.

Apparently ppm uses two different commands for installing
and upgrading.

I found life to be easier if I first remove the package, and install the
new version.

....

I have been using cygwin for longer than I care to remember. As a Unix
environment in Windows, it has been extremely useful. You just need to
keep the two worlds apart. The easiest way I have found of doing so was
to add all the cygwin paths to the end of my usual Windows path.
However, when I start the cygwin shell, the batch file adds those paths
to the front as well.

This way, I can use all the cygwin command line tools while working from
cmd.exe, but use ActiveState Perl.

When I am in cygwin bash, OTOH, the cygwin perl is first in the path.

I have had zero problems with this set up (including running native
Apache + mod_perl and cygwin Apache + mod_perl simultaneously - using
different ports, obviously).

I only used it for Perl. The last time I used it it had wrecked
CPAN.pm for me. Apparently my username (default name given during
cygwin installation) contained a space. So CPAN.pm dowloaded a
distribution but was then not capable of finding it because a path
such as

/home/username with space/.cpan/build/Module-$VER.tar.gz

was evidently too tricky to deal with.

Sadly, that might still be true. Whenever I get a new XP system, I
create a D:\Home. My userid is always a string with no spaces in it. In
addition, I move the "My Documents" folder to D:\Home\userid. I can then
change the user name displayed by Windows using the "Users" option in
Control Panel.

OTOH, I gave up using CPAN with either of cygwin or AS Perl after a few
tries. The XS modules I have compiled (using msvc command line tools for
AS Perl, or gcc for cygwin) always worked without a hitch. on FreeBSD, I
use the ports collection except in the few cases where a module is not
in the ports tree (in which case, I go the command line compilation
route, rather than CPAN).

I don't know where I am going with this. Just my experience, FWIW.

Sinan

 

[John Bokma]

Also sprach John Bokma:



Once a module is not (yet) available as ppm package you'll most likely
need nmake.

Yup, but that's just a very small download, and easy to find ;-)

Quite so, often enough I ended up using the CPAN shell. I've had
numerous problems with ppm in the past: IIRC it doesn't follow
prerequisites so those have to be installed manually.

It does follow them

For each
installation you first need to issue a query before installing a
package.

Unless you know it's name, I mean: install some-name works for me.

I've had cases that a query returned multiple hits for a
module. When I was lucky they had different versions but I also had
cases that a release was reported twice in which case ppm was so
confused that it wasn't able to install any of those.

Weird, I have seen this too, and IIRC it always installed the highest
version number.

This can happen if
you have specified more than one ppm repository to search.

I have never had problems with this.

Upgrading modules often turned out to be a nuisance. Apparently ppm
uses two different commands for installing and upgrading. Even when
using the correct one it didn't reproducibly work for me.

Weird, since it does for me, for years If it was that broken, it
would have been fixed ages ago.

Furthermore, ppm never
gives any visual feedback of its doings.

My best guess is you have a ppm program that does something completely
different.

The best part was of course when I upgraded Storable and ppm would no
longer allow me to start its shell. Mind you, I was still able to use
it via command-line ('ppm install ...'). But in this mode ppm is
stateless and you can't first search for a module and then install it.
I had to download the .ppd file along with the .tar.gz and do a local
install instead.
???

I am citing from memory here and there were some nasty and
inordinately unhelpfull error messages that I no longer recall for a
few of those incidents. Those things date back to the times when I was
using Windows and ActivePerl for learning Perl. Sometimes I still need
to fire up Windows and ActivePerl again for testing things with my
modules. With respect to ppm things haven't improved a lot and so I've
stopped making ppm packages for my modules lest I have to deal with
other people's ppm troubles.

As I already wrote, if ppm was that bad, it would have been fixed ages
ago. I use it very often, and haven't seen any of the above problems.

[ Cygwin ]

I only used it for Perl. The last time I used it it had wrecked
CPAN.pm for me. Apparently my username (default name given during
cygwin installation) contained a space. So CPAN.pm dowloaded a
distribution but was then not capable of finding it because a path
such as

/home/username with space/.cpan/build/Module-$VER.tar.gz

was evidently too tricky to deal with.

LOL, neither ppm nor CPAN likes you ;-)

 

[John Bokma]

Didn't you get the memo? It's Usegoogle Netgroups now.

Was the memo posted via the Usegoogle Netgroups site? It might have been
kill filed :-D.

 

[John Bokma]

"Tassilo v. Parseval" <[email protected]> wrote in

[ ppm ]

That still seems to be true.

upgrade -install works for me The only exception seems to be PAR.
But even after installation it had problems which forced me to compile it
myself, so I blame this on PAR, not ppm.

 

[Damian James]

[cygwin]
I only used it for Perl. The last time I used it it had wrecked CPAN.pm
for me. Apparently my username (default name given during cygwin
installation) contained a space. So CPAN.pm dowloaded a distribution but
was then not capable of finding it because a path such as

/home/username with space/.cpan/build/Module-$VER.tar.gz

was evidently too tricky to deal with.

To be fair, it's very unclear whether that's cygwin's or CPAN.pm's fault.
Or whether it's some artefact of the manner in which CPAN.pm passes the path
to the environment.

I've used both (cygwin and ActiveState) for years, though. Initially, I got
cygwin just for Perl, because at that time the ActiveState version did not
do the various low-level emulations needed for fork() and select(3) to
work, while obviously cygwin provided these in the environment.

I've generally used ActiveState for stuff sitting on the network that users
need to have available, though at times I've used cygwin for that too,
juggling paths and dlls and so forth. Things that need GUIs under Windows
that users other than me will use, obviously I do with ActiveState perl,
otherwise is Just Too Hard. Of course, most of these end up growing into
web-based thingummies, and can therefore live on a real unix machine.

--Damian