A Blog of Very Little Brain

…maybe not “forever”, though, but it did (Eventually) did good.

I moved the installation to “c:\strawberry” as dictated by the manpage, and made sure to set the path variables to the correct places. (Also, I’ve added a path variable to MinGW’s bin folder, just to be on the safe side). Then, I tried installing the modules that were acting up originally, which was mostly successful, apart from Tk. Installing it turned out to be a bit of an issue.

A quick search later, and I got some general complains, and even more general solutions, until I hit pay dirt (http://rt.cpan.org/Public/Bug/Display.html?id=13923):

I built Tk via the strawberry perl distribution today. I also had the
“missing file”. The file was not missing, but rather there appears to
be a relative path in Xlib.h at line 1206

#include "../pTk/tkIntXlibDecls.h"

but xlib.h is at C:\Tk-804.027\pTk\mTk\xlib\X11
and there is not pTk dir up one directory.
if you create a pTk dir at C:\Tk-804.027\pTk\mTk\xlib\pTk
and put tkIntXlibDecls.h and lang.h there the build will complete just
fine.

Really weird stuff, but it actually worked. After performing the movement, and re-running Makefile.PL, I managed to build, test, and install Tk, which means I now have, hopefully, all I need.

Previously on “why I no longer think Windows users complaints about Perl are unjustified” I found that installing anything not in ActiveState’s PPM repos is altogether broken, and, while preliminary tactics worked, at least initially, it turned out that, in the long run, the house always wins. What I thought was a successful installation turned out to be a successful botch-up, with lower level dependencies, such as Moose, not being installed. Attempting to perform the same operation on Moose was apparently the last straw on the side of ActiveState Perl, and that failed miserably. In accordance, I gave up on them and removed the distribution from my machine.

Fortunately, there are other alternatives. Strawberry Perl is one of them. Unfortunately, many of those aren’t mature enough. Strawberry Perl is one of them. For starters, the installer file asks you for a Start Menu path, then begins installation in C:\Strawberry\. While I’m aware that Windows users are accustomed to their computer being treated like the local dump (i.e. everyone throws their garbage wherever they feel like), but I would like at least a minimal control over where I place (some) of the files. Extracting from the .zip file is no better, as all the paths have been hard-coded to the same “C:\strawberry” path.

It is often said that, when it comes to user-awareness, F/OSS projects show the same care and attention of a Soviet tank. Concepts like “Here’s the mailing list, the IRC Channel, the USENET group and the Bug-Tracker, good luck” tend to shirk away non-technical users. On the other hand, Windows users tend to fall on the less-savvy side, and, in accordance, Strawberry’s support page directs to the IRC page, the community site and the mailing list. Oh well.
Of course, users of Perl are, probably by definitions, tech-savvy, so this might not be a correct criticism. OTOH, even a bare-bones hardcore Perl programmer would appreciate some manner in which to reconfigure the distribution’s hard-coded paths, rather than search for every appearance of c:\strawberry (or c:\\strawberry, or c:/strawberry, etc), and replace them.

I’ve rummaged for a while in the files and folders in the distribution, and then checked the site. In the distribution’s CPAN page, I found these comforting words:

At present, Strawberry Perl must be installed in C:\strawberry.
Users installing Strawberry Perl without the installer will need to change the environment manually.

Oh dear.

(…to be continued)

Some things just don’t do what they are supposed to. Such as placing a link in the post title.

GoComics: Love the site, reading about 15 of the comics they post there, but they don’t seem to “get” RSS. I keep finding myself being sent to yesterday’s strip, or the day before, or even older than that, until I get a “you need to subscribe to read this strip from the archive”. I thought RSS update means the latest, but I guess somewhere along the way things got a bit off.

ActiveState Perl: They did a great job of bringing perl to the mush that is Win32, but when it comes to installing modules, usually a very transparent trip to CPAN via the commandline tool. With ActiveState’s flavour, cpan crashes with an odd message:

Alert: While trying to 'parse' YAML file
'.\Perl\cpan\FTPstats.yml'
with 'YAML::XS' the following error was encountered:
Usage: YAML::XS::LibYAML::Load(yaml_str) at .\Perl\site\lib/YAML/XS.pm line 70.

using AS own ppm is good, but to a point, there seems to be some funky issues with updating/upgrading modules, and naturally, it’s limited to AS own pre-compiled modules.

I eventually managed to get stuff to install and run, by downloading the module locally, and then running cpanp.bat (i.e. CPANPLUS) from the extracted directory. Such issues reinforce the CPANPhobia I occasionally encounter on Perl-related issues, and doesn’t do much good PR to neither Perl nor CPAN.

Also, I always wonder, I often remark that the Internet is not the Web and vice versa. The question is, how much of the Internet does the web take. Email traffic, naturally, takes a huge slice of the pie, in the sheer number of emails being passed each day. But, being mostly textual, this slice’s bandwidth is relatively lower (I’m guessing here). OTOH, File-sharing traffic is probably lower in its pie-slice (users and items), but way heavier in the actual bandwidth and packets transferred. And, there are many other protocols. I’ll try looking up some actual numbers.