While not quite as busy as I would like, the #win32 IRC support channel has so been highly successful. Having fixed most of the obvious flaws in Strawberry uncovered by people in the support channel, things have started to stabilise now.
In this steady state, we are seeing three specific problems surface against and again on a daily basis (for the type of user that clicks on the "Live Chat" link on the front page of a Perl distribution's website).
1. Nobody is there to answer, or not there fast enough.
The pattern we seem to be seeing amoungst the most need users (who don't change their nick from mib_$hexstring to something else) is that they have a typical tolerance for silence of around 3 minutes.
They will join the channel, ask their question, wait three minutes, then leave.
The existing infobot dipsy is almost worse then useless, because about a third of the time it creates the apparent situation where the user thinks that someone IS there to answer their question, but is intentionally ignoring them after the initial greeting.
There's a clear need here for a customer support bot. Something that monitors new arrivals for questions and informs the user that nobody is there right now, and they should lurk for a little bit (and provide information on when the most recent conversation was and how long they should wait).
2. Users expect Perl to come with an IDE.
"I've installed Perl, but I can't find where to edit/run/etc Perl files" is a major complaint. We even get some people that thing that the "CPAN Client" start menu entry is a Perl shell of some kind, then get confused when Perl code they type in doesn't work.
The editor part we plan to fix shortly with Strawberry Professional, but the other half suggests the need for some kind of shortcut to a "Perl Command Line", or at least something LIKE this so at least we can place an obvious-looking Start Menu entry for their perceived need.
I've been playing with Perl::Shell a bit more lately, to turn it into something suitably dumbed down and approachable, so this shouldn't be hard to solve.
3. Can't find Net/LDAP.pm in @INC ( giant wall of text )
The first two problems we can fix at a project and distribution level.
This problem, on the other hand, is a different kettle of fish.
This ordinary Perl error message is an endemic cause of complete failure on the part of the user.
Perl scripts are all over the place, most of them NOT part of a well structured CPAN distribution or PPM package.
The smarter Windows people can survive not having an editor, and they work out how to run the script.
This cryptic error, however, stops them completely in their tracks.
"Can't find Net/LDAP.pm in giant set of paths" (which is the specific case that happened to our Windows admin team in meatspace at work today) actually means "You need to install the distribution perl-ldap, using the PPM tool listed in the start menu entries".
That an error message like this even exists, instead of being at least something like "The Perl class 'Net::LDAP' is not installed on your machine: Can't find Net/LSAP in ..." is the real icing on the cake, because we don't even provide the poor guy running the Perl script with a useful error message that describes the failure in high level terms, let alone provide some suggestion on how to fix it.
For Strawberry Professional, I'm pondering the idea of adding a "Run a Perl Script" start menu program, built using perl and Wx, who's only job is to run a named perl script in a way that turns the cryptic stuff into vaguely useful instructions on what probably caused the problem, and how to fix it (and ideally, to automatically fix it for them).
I end up letting people run Perl by completely preventing them from ever running perl.
But since lots of people don't use the command line (they hit Perl via a batch script or similar) now I might also need to hijack perl.exe entirely to deal with it (except that breaks things that do pass-through code to child Perl's for process isolation reasons).
It's not surprising that Perl has some of the reputation it does, if a Perl coder can't reasonably give a .pl script to an admin and reliably have them be able to run it. Unable to know that they have to install one tiny PPM package, the code becomes "That shitty Perl script".
I posit that there's a whole swath of people that don't hate Perl for it's syntax, since they don't read all kinds of other ugly languages they use day to day.
They have it because running a typical Perl program as an untrained user is hard when it works, and impossible to setup when it is missing dependencies.
But I'm not really sure what, if anything, the core team could do at this point to fix this problem.
A Google search for Can't locate in @INC turns up 128,000.00 hits. That is a large number but even more telling is the wide range of forums that they appear in. The "@INC" message is clearly a hinderance to new users.
An example of a similar but much clearer error message from perl is "Can't locate object method 'new' via package 'Foo' (perhaps you forgot to load 'Foo'?)". A Google search for Can't locate object method "new" via package give only 25,000 hits by comparison.
I don't imagine that anyone would have the appetite to change the "@INC" message at this stage but it clearly doesn't work as it is, in any sort of useful way.
John.
--
Perl::Shell is a minimalist module and as such it would be easier to support and maintain, but I've been using Devel::REPL with great success as my command line perl.
You really like to goad me to put my "evil hat" on. This is a crude example to show the concept -- it would need to be a bit more helpful and a bit more robust for real use.
package Nice;
use strict;
use warnings;
no warnings 'once';
*CORE::GLOBAL::require = sub {
my $mod = shift;
eval { CORE::require($mod) };
if ($@) {
if ( my ($mod) = $@ =~/\ACan't locate (\S+)/ ) {
$mod =~ s{/}{::}g;
$mod =~ s{\.pm$}{};
$@ = <<"END";
Can't locate $mod in your Perl library. You may need to install it
from CPAN or another repository. Your library paths are:
END
$@.= " $_\n" for @INC;
}
die $@;
}
return 1;
};
1;
Here's an example:
$ perl -MNice -MFoo::Bar -e 1
Can't locate Foo::Bar in your Perl library. You may need to install it
from CPAN or another repository. Your library paths are:
/opt/perl/5.10.1/lib/5.10.1/x86_64-linux-ld
/opt/perl/5.10.1/lib/5.10.1
/opt/perl/5.10.1/lib/site_perl/5.10.1/x86_64-linux-ld
/opt/perl/5.10.1/lib/site_perl/5.10.1
.
Could be done via PERL5OPT or perhaps the site-customization file.
-- dagolden
Re:hacking in a nicer error message?
Ovid on 2010-01-22T17:45:27
Also, maybe try to trap the file and line number where they tried to require the module?
Re:hacking in a nicer error message?
vek on 2010-01-22T21:53:22
Nice first hack though. Seriously.
Re:hacking in a nicer error message?
patspam on 2010-01-24T07:31:43
It'd be nice if Padre detected this in its console output too - and automatically opened a CPAN GUI to help the user install the dependency (http://padre.perlide.org/trac/ticket/70#comment:2)
But since lots of people don't use the command line (they hit Perl via a batch script or similar) now I might also need to hijack perl.exe entirely to deal with it (except that breaks things that do pass-through code to child Perl's for process isolation reasons).
Eh, no, you don't have to patch perl.exe. Instead, put it in a module. Just like diagnostics does nothing but explaining warnings and errors better.
You can load this module on the command line using -M, or you could set an environment variable like PERL5LIB, so it gets used in every Perl script that gets run from the batch file.
Re:Put it in a module!
chromatic on 2010-01-22T22:51:27
... you don't have to patch perl.exe. If the executable supported localization and translation files, swapping in other error messages would be easier. (Replacing them entirely might not be as easy though.)
Re:Put it in a module!
Alias on 2010-01-23T15:47:21
I can't load this module on the command line, as I am neither the person who wrote this code nor am I the person running this code.
The people doing both the writing and the running are not on this website, and do not have the benefit of this suggestion (which is why any answer that involves eduction doesn't work in general).
I can't modify the site perl script, because I'm only the vendor of the Perl distribution, not the site.
And I'm a teensy bit dubious about PERL5LIB, one because it won't work under tainting, but also because modifying PERL5LIB like that smells of evil (and if there are more than one Perl on a host, they could get screwed up by it).
sitecustomize.pl
mauzo on 2010-01-23T18:19:54
So build Strawberry with-Dusesitecustomize, and put it in there. That's exactly what it's there for, and anyone who knows enough to know they don't want it can turn it off with the-fswitch.
> I posit that there's a whole swath of people that don't hate Perl
> for it's syntax, since they don't read all kinds of other ugly
> languages they use day to day.
>
> They hate it because running a typical Perl program as an
> untrained user is hard when it works, and impossible to setup
> when it is missing dependencies.
So about the same as EVERY OTHER LANGUAGE. Python, Ruby and Java all have the same problem of not making it at all clear how to resolve missing dependencies. Certainly my approach to all three is that if it doesn't Just Work, then I just delete the program and find something better.
Re:[insert useless subject here to placate use.per
Alias on 2010-01-23T15:44:25
Perl doesn't even really make it clear there IS a missing dependency.
It just says it can't load some file
Re:[insert useless subject here to placate use.per
tgape on 2010-02-04T03:36:32
The fact that so many other languages get it wrong does not excuse us for getting it worse.
It *does* mean we have an opportunity, *if* we can get it right. And, given CPAN, we *can* get it right. All we need to do is send the right patch to the core maintainers, and convince them it's right. Alternatively, we could produce a module, and convince them to have the normal build process include that in a location that will normally get loaded in as core (maybe as sort of a 'usecorecustomize'ish type thing.)
The ideal solution would not only tell them it's not apparently installed, it would optionally probe using a local system tool like mlocate to see if it's merely installed elsewhere, and it would optionally prompt them to go to CPAN to get it.
