use Perl

I agree that "Can't locate Foo.pm in @INC" is a very poor error message. For a new user is must be worse than meaningless and as an experienced user the handful of times that it has been useful to me (i.e. messed up paths and not missing modules) I could have figured out anyway with perl -V or similar.

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.
--

The Pod and the generated wiki output both have a double dash but it is being rendered by Github as a Html "em dash" (code 8212). This is in accordance with the Textile spec. It does the same with quotes and other punctuation.

It isn't a feature that I particularly like but it is the way Textile is intended to behave.

John.
--

The language is an in-house language with a syntax that is a little like Pascal.

Thanks, for the tip about matchit. That looks interesting.

Dera Lazyweb,

In vi/vim is it possible to match if/endif in a non-standard language so you can toggle between them using %? I know that this feature is usually reserved for parentheses and braces but this particular language doesn't use them.

I can see, from reading around, that you can set regions via ":syntax region" but I'm not sure if that applies to this case.

I am not a vi user. I'm asking mainly for a colleague.

John.
--

Sorry, I don't understand the context. What is the problem exactly?

John.
--

If you'd like I can have a look at creating a pod2trac filter based on Pod::Simple::Wiki.

John.
--

As a mentioned recently I added Pod to Textile support to Pod::Simple::Wiki. It is now up on CPAN.

This lets you to convert a Pod document to Textile markup as follows:

pod2wiki --style=textile Some::Module.pm > some_module.wiki

I installed Snow Leopard and everything went okay. As usual the first thing that I do on an OS is to check the perl version:

$ perl -v

This is perl, v5.10.0 built for darwin-thread-multi-2level

Good start.

I've moved Spreadsheet::ParseExcel to github: http://github.com/jmcnamara/spreadsheet-parseexcel

It had previously been on Google Code but I didn't find it conducive to collaboration. Hopefully github will be better. I already like the clean look and feel.

Here is a rough indicator of perl version being used with Test::Harness based on the test report for the module:

Test::Harness 3.15

    Version  Tests  Percent
    5.6          7    6.6 %
    5.8         46   43.4 %
    5.10        52   49.1 %
    5.11         1    0.9 %
    Total      106

    <  5.8       7    6.6 %
    >= 5.8      99   93.4 %

Test::Harness 3.16

    Version  Tests  Percent
    5.6         18    6.7 %
    5.8        126   47.2 %
    5.10       123   46.1 %
    Total      267

    <  5.8      18    6.7 %
    >= 5.8     249   93.3 %

So, as a very rough metric, among people who use automated installers and report tests, perl 5.6 usage is approximately 7%.

If you are going to drop 5.5 support I'd suggest the your drop 5.6 as well and only support 5.8 as a minimum.

I'd guess that the only people still using 5.6 are on Solaris 8 which also puts them in the category of non-ugraders.*

John.
--

* I use Solaris 8 from time to time but I generally install modules into a perl 5.8 build in /opt and not into the core perl 5.6.

Either way it comes down to the diligence of the maintenance programmer so I don't see the advantage.

What I do see is the disadvantage. The blocks of Pod that you say "quickly becomes annoying".

If you step back from this don't you get one of those smells that you like to look out for. What it looks like to me is that a method of documenting a module is "annoying" and that the solution is to change the behaviour of the tool for viewing the code. That doesn't look like a good solution to me since it only works for one user.

John.
--

"Almost all of my modules are written with inline POD because I believe it's very important for the documentation to be next to the code, but if you've worked on a codebase for any length of time, that POD quickly becomes annoying".

You like to have the Pod by the code but it is annoying. So this fixes it for you by making it not annoying.

What about the next person who reads your code and doesn't have a Vim Pod folding macro. They are going to find it annoying, right?

Inline Pod *is* annoying. It make code difficult to read, especially if it contains code snippets. But you could avoid the annoyance by putting the Pod after the __END__. Then no-one will have to make their editor, or their brain, jump through hoops.

Putting the documentation near the code is no guarantee that it will get updated when the code does.

John.

--

it does alignment on => too

Does it? I tried a few examples, including the one in the docs above, and it doesn't seem to.

Anyway, I guess the point is that while there are several modules that dump data structures effectively (at least for my needs) there is only one module that does the pretty printing the way I want it (at times when I do want it) and that is Perl::Tidy. That is really what I was aiming for. :-)

John.

--

I was aware of it. ;-)

From the Pod of the above module: "Data::Dumper also provides a certain level of pretty printing via the $Data::Dumper::Indent variable but it isn't quite as nice as the Perl::Tidy output".

In particular, it doesn't do any hash element alignment on => which I find helpful when debugging.

John.

--