In continuation to

• Re: Recap: The Future of Perl 5 (backwards comaptibility, RFC)
• Recap: The Future of Perl 5

The basic ideas are that:

Declaration of instance variable

• my on the class level with :attributes
• the TYPE is given right after the my
• attributes reflect the Moo(se-)model of has keys where possible
• the assigned values are defaults for the new-constructor

Access of instance variables inside methods

• an instance variable x is readable and writable via $$x
• this is automatically mirrored in $self->{x}
• $self->{x} is an alternative syntax for the same access

$self

• $self is already shifted from @_ and directly available

Methods

• all subs declared inside the scope of a class are methods
• imported subs (like pp) are ignored

 
{
     use Class BLA => ISA-LIST;

     use Data::Dump qw/pp/;

     my Int ($x,$y) :has :rw  = (10,11);
    
    
     sub set_x {
         my ($var) = @_;
         #warn  "set_x $$x -> $var \n";
         $$x = $var;
     }
    
     sub print_x {
         print "x = $$x \n";
     }

     sub print_self_x {
         print "x = $self->{x} (via \$self)\n";
     }


     sub dump {
         warn '$self:',\$self;
         warn pp '$self: ', $self;
         warn pp '$$x: ', $$x;
         warn pp '$$y: ', $$y;
     }
  
}
[download]

The implementation is done via a macro expansion from use Class which injects some boilerplate into the head of the class, which handles the creation.

Injecting is basically done via a source filter or alternatively via Keyword::Simple. NB: just injecting some code doing introspection. No parsing, regexing or modification of the code you see.

I'm supposing this concise syntax could be used as a front end for all current OO models in Perl and might help offering a stable backwards compatible syntax if it's hardcoded into the engine.

A rough proof of concept follows here:

NB: This example is pretty barebone, and not meant to be an alternative to other OO Frameworks, but rather a frontend. It doesn't create accessors and the constructor is only simplistic.

Comments?

A question came up here recently where a user wished to specify a minimum version for a parent class. base doesn't support specifying minimum versions, nor does parent. base and parent are core Perl modules. I don't think it would be appropriate to add complexity to the core Perl parent by adding this feature.

Perl facilitates setting minimum versions in use statements:

use Time::HiRes 1.9;
[download]

use has a compiletime effect, so that code behaves like this:

BEGIN {
    require Time::HiRes;
    Time::HiRes->VERSION(1.9)
    Time::HiRes->import
}
[download]

However, BEGIN blocks require us to consider the order of loading more than we may want to. This doesn't fit the model of keeping simple things simple, if the simple thing we want to do is fairly common.

For inheritance we can do this:

package MyAgent;

BEGIN {
    require LWP::Usergent;
    LWP::UserAgent->VERSION(6.39);        # Assert a minimal version.
    push @MyAgent::ISA, 'LWP::UserAgent';
}

[download]

To me that's too much boilerplate for a common need. Another way:

package MyAgent;

use parent 'LWP::UserAgent';
BEGIN {LWP::UserAgent->VERSION(6.39)}
[download]

But that's a little fragile; someone may refactor and forget to keep the BEGIN block after the call to parent causing things blow up. Sometimes code becomes complex, masking simple mistakes. I would prefer a solution that doesn't require the user to maintain several steps to set up inheritance while assuring minimal versions for parent classes.

parent::versioned makes the inheritance and compile-time version checking more convenient, and harder to get wrong. I uploaded it to CPAN a few hours ago.

package Myagent;

use parent::versioned ['LWP::UserAgent' => 6.39];
[download]

parent and parent::versioned behave the same for all import lists unless an element in the import list is an array ref. Any array ref passed to the import list will be treated as a tuple that specifies a module name, and a minimum version for that module. Multiple inheritance works like this:

use parent::versioned ['LWP::UserAgent' => 6.39],
                      ['Mojo::DOM'      => 7.2 ],
                      'Foo::Base';
[download]

This example sets up triple inheritance: two modules that are version checked, and one that is not. As with parent, parent::versioned accepts the -norequire flag.

The parent module has 100% code test coverage. parent::versioned passes the parent test suite and maintains 100% coverage. It should work as a drop-in replacement for parent, but with the additional functionality exposed by passing an array-ref as part (or all) of the import list. Most of the code is a direct fork from parent. You can use it just like you use parent:

use parent::versioned qw(Foo);
[download]

I prefer keeping the module small, but if you're interested please do look at the GitHub repository. Patches, issues, and suggestions are welcomed. I hope it becomes useful.

It is often repeated that hashes in Perl do not preserve insertion order. Yet:

#!/usr/bin/perl

use strict;
use warnings;
use feature qw/say/;

my %hoh = (
    foo => { value => 'first' },
    bar => { value => 'second' },
    baz => { value => 'third' },
);

for my $elem (sort values %hoh) {
    say "value => " . $elem->{value};
}

[download]

Output:

value => first
value => second
value => third
[download]

Edit and clarification: I'm not saying that you should ever use this (in fact, I'm saying that you shouldn't, the comments below describe why). It looks like as if it really preserved insertion order, but actually the trick relies on implementation details (memory allocation) you can't (or shouldn't want to) control.

I recently took a job at a Python shop, helping out a friend. I have tried to be patient with the new-to-me language and to realize that there are different ways of doing things and that I should expect some mental friction simply due to my unfamiliarity. But, man, I just can't escape the idea that sigils were a good idea.

I needed to access a dynamically specified method and run a dynamically specified method against that method's result. Python can't tell the difference between a variable you created that contains a method name and a method name itself. You have to use a function called getattr to cumbersomely retrieve the reference you want. And if you go any deeper than one, it gets ugly very quickly. In my case, I have something like

getattr(getattr(object_identifier,variable_containing_the_name_of_meth
+od_one), variable_containing_the_name_of_method_two)
[download]

(I'm using ridiculously long variable names for clarity about what the variables contain.)

With sigils to let Perl know that I mean 'grab the contents of the variable and execute the method having that name', I can do:

$object_identifier->$variable_containing_the_name_of_method_one->$obje
+ct_containing_the_name_of_method_two
[download]

With the ridiculous names it may be less clear how much nicer this is, but look at:

$obj->$var1->$var2
[download]

vs

gettattr( getattr(obj,var1) , var2)
[download]

I hate going to the inside and working my way out, trying to remember what I picked up along the way.

I realize that Python people hate having to type sigils all over the place, and that they would find it ironic that this would be the thing I would write in praise of. But I am doing a lot of work right now with dynamic method/attribute names and it really seems to me that Larry made the right call on this.

GIven my new enthusiasm for the Perl community I dare to post an issue I was having to IRC on #perl-help and it all fell down. […] anyone posting in #perl-help, needs help and I'd forgotten that certain people view this channel as a shooting ground where you pour ridicule on posters "who don't understand their problem" - of course they don't or why would they post on #perl-help. I got some helpful comments but I also got the ridicule.

I decided to post the log because the Perl community as a whole was blamed, not individuals, and in order to provide accurate first-hand information so that anyone can form their own opinion.

2019-07-23 18:47:42     mje__   I have a strange warning that I cannot
+ provide a runnable example for. The code "if (defined($match->{in_co
+ntrol}) && ($match->{in_control} == 1))" ends up issuing a warning sa
+ying "Use of uninitialized value in numeric eq (==)" but I cannor und
+erstand how this can happen. $match is defined and even if it wasn't 
+I'd expect a warning saying trying to deref and undef. I don't think 
+it is autovivification as my tests show 
2019-07-23 18:47:42     mje__   defined doesn't do this. Any ideas?
2019-07-23 18:48:44     mje__   Perl 5.24.4
2019-07-23 18:56:48     alh     in_control could have operator overloa
+ding
2019-07-23 18:57:00     alh     Alternatively, the warning isn't happe
+ning where you think it is which seems more likely
2019-07-23 18:57:21     alh     Line numbers can be wrong if it's part
+ of a giant if () { } elsif () { } else {} block
2019-07-23 18:57:35     alh     So it could be a different conditional
+ triggering it
2019-07-23 18:58:54     mje__   Simple hash ref, so no overloading. Th
+e warning seems pretty good since the line mentioned contains an ==
2019-07-23 18:59:58     alh     Is it part of a multi-line conditional
+?
2019-07-23 19:00:02     alh     Can you show us more of the code
2019-07-23 19:00:08     mst     the warning is happening somewhere els
+e
2019-07-23 19:00:10     mst     99% chance
2019-07-23 19:02:28     mje__   Here is what it looks like now https:/
+/pastebin.com/fsTnLRaS, the only thing changed from when the warning 
+was output was defined changed to exists
2019-07-23 19:02:29     Repaster        Repasted text from mje__: http
+://perl.bot/p/mmydbc
2019-07-23 19:03:03     alh     That's using exists
2019-07-23 19:03:04     alh     not defined
2019-07-23 19:03:07     alh     So it can exist and e undef
2019-07-23 19:03:13     alh     Which is your problem
2019-07-23 19:03:46     mje__   I said, the original was defined when 
+the warning was issued and what I pasted was afterwards when it was c
+hanged to exists
2019-07-23 19:04:48     mje__   the change from defined to exists is l
+ikely wrong but the warning came from the defined case
2019-07-23 19:06:29     alh     Can you show more context?
2019-07-23 19:12:38     mje__   https://pastebin.com/sYC3XR31
2019-07-23 19:12:39     Repaster        Repasted text from mje__: http
+://perl.bot/p/t8p5x4
2019-07-23 19:16:48     alh     before line 18 warn the value of $exis
+ting_match->{in_control}
2019-07-23 19:17:01     alh     Beore line 14 do the same for $events{
+$event_id}->{event_status_id} 
2019-07-23 19:17:05     alh     That may be where the real warning is 
+coming from
2019-07-23 19:22:02     mje__   ok, so the crux of the opinion is the 
+line number is possibly wrong and so other == tests could be at fault
+?
2019-07-23 19:24:47     mst     the crux of the opinion is "you're con
+fused about *something*
2019-07-23 19:24:51     alh     Yes. And you can figure out by adding 
+debug everywhere
2019-07-23 19:24:57     mst     I'd probably apply warn + Data::Dumper
2019-07-23 19:25:12     alh     If you think $x->{foo} == 1 is warning
+, warn reight before that conditional, warn inside that conditional, 
+warn after that conditional
2019-07-23 19:25:31     alh     Where the unintialized value warning a
+ppears in regards to what you've added should help you track it down
2019-07-23 19:28:21     Grinnz  source filters are also known to screw
+ up line numbers
2019-07-23 19:29:32     mst     oh. yes. if you have 'use Switch;' in 
+that code, you can assume all line numbers are wrong
2019-07-23 19:30:00     Grinnz  (and in that case, that it also caused
+ the error)
2019-07-23 19:31:00     mje__   Unfortunately this is code working on 
+live data and although it is possible to play it back the playback is
+n't EXACTLY as it was live. We don't use Switch. I hadn't considered 
+the warning line number was wrong so I've got something to work on. T
+hanks
2019-07-23 19:31:43     Grinnz  there are still some core bugs that ma
+ke wrong line numbers too
2019-07-23 19:34:35     alh     Also if a comment like this is anywher
+e in the file:
2019-07-23 19:34:38     alh     # line 5 10
2019-07-23 19:35:07     alh     Or even:
2019-07-23 19:35:09     alh     # line 10
2019-07-23 19:35:12     mst     honestly I still thing you're just con
+fused about the data
[download]

"Just sit right back and you'll hear a tale
a tale of a fateful trip,
that started from this simple term,
aboard this single slip."

Please, dear reader, learn from my mistake. (It will likely be less painful than repeating it yourself.)

Earlier today I did something I have done dozens of times before-created a command-line perl script (a "one-liner", for some very long definition of a "line") to create a file containing a subset of messages from a set of compressed logs, with the intent of pulling them back to my machine for additional processing. I launched it in a screen session, saw it was running and would take some time to begin generating output, and stepped away for lunch. I was rather surprised, however, when I returned to find it throwing "No space left on device" messages-especially when I looked to find that the partition's previous 40GB of free space was now zero. After cleaning up the space, I began trying to find the cause.

In digging through my code, I almost missed the issue-a line of the form if ( $str -~ m/some pattern/ ) { print $str; }. Notice the issue? An off-by-one-key error from a en.US keyboard, where [-/_] and [=/+] are beside one another. This was compounded by skipping the well-espoused logic of use strict; use warnings; because it was a "one-liner" (where "-Mstrict -Mwarnings" would have added a mere 19 characters in length). Had I have done so, instead of:

# made-up example with actual issue
$ perl -le 'my $str = q{zxcv}; if ( $str -~ m/some pattern/i ) { print
+ $str; }'
zxcv
[download]

# made-up example with actual issue, with strict and warnings
$ perl -Mstrict -Mwarnings -le 'my $str = q{zxcv}; if ( $str -~ m/some
+ pattern/i ) { print $str; }'
Use of uninitialized value $_ in pattern match (m//) at -e line 1.
Argument "zxcv" isn't numeric in subtraction (-) at -e line 1.
zxcv
[download]

I know this will probably be like the tone after the television broadcast day ended to a sleeping viewer, but maybe, just maybe, it will help someone. In the end, learning from others' mistakes is often less painful (but not necessarily as memorable).

(And yes, I do use the the duo on most every script I write-just not always on "one-liners".)

This is the long version of Re^2: open file error and Re^5: Unify windows filenames (from ten years ago), triggered by Re^2: perl script to compare two directories, plus a little bit of bean counting on the code for non-Unix systems.

File::Spec has a severe design problem that will cause wrong results on modern Unix systems (*BSD, Linux, MacOS X). It assumes that all filesystems are equal on any Unix operating system. And this assumtion is plain wrong since decades:

• Any modern Unix can mount FAT and NTFS, two filesystems that are commonly used in a case insensitive way, and so they are generally mounted in a case insensitive way.
• At the same time, the native filesystems (ext2/3/4, btrfs, ufs, ufs2, zfs) are mounted in a case sensitive way.
• ISO9660 is case insensive, Rock Ridge extensions make it case sensitive, so a CDROM / DVD-ROM / Blueray mounted on a Unix system may be either case sensitive or case insensitive.
• Mounting a case insensitive FAT filesystem on Linux is quite common: All Raspberry Pis boot from a FAT partition later mounted as /boot
• And to drive people mad, Linux 5.2 also can mount its native ext4 filesystem in a case insensitive way.

To make things worse, the code for at least Windows and cygwin is broken, too.

Alexander

open Best Practices

open my $fh, '<', $filename or die "$filename: $!";

You will see styles of open such as "open FILE, $filename;" or "open(LOG, ">$filename") || die "Could not open $filename";" in many places. These mainly come from versions of Perl before 5.6.0 (released in 2000), because that version of Perl introduced lexical filehandles and the three-argument open. Since then, these new features have become a best practice, for the reasons below.

1. Use Lexical Filehandles

Instead of open FILE, ..., say: open my $fh, ....

Lexical filehandles have the advantage of not being global variables, and such filehandles will be automatically closed when the variable goes out of scope. You can use them just like any other filehandle, e.g. instead of print FILE "Output", you just say print $fh "Output". They're also more convenient to pass as parameters to subs. Also, "bareword" filehandles like FILE have a potential for conflicts with package names (see choroba's reply for details).

2. Use the Three-Argument Form

Instead of open my $fh, ">$filename", say: open my $fh, '>', $filename.

In the two-argument form of open, the filename has to be parsed for the presence of mode characters such as >, <+, or |. If you say open my $fh, $filename, and $filename contains such characters, the open may not do what you want, or worse, if $filename is user input, this may be a security risk! The two-argument form can still be useful in rare cases, but I strongly recommend to play it safe and use the three-argument form instead.

In the three-argument form, $filename will always be taken as a filename. Plus, the mode can include "layers", so instead of having to do a binmode after the open, you can just say e.g. open my $fh, "<:raw", $filename.

3. Check and Handle Errors

open my $fh, '<', $filename;                          # Bad: No error handling!
open my $fh, '<', $filename  || die ...;              # WRONG!1
open my $fh, '<', $filename  or die "open failed";    # error is missing info

open my $fh, '<', $filename  or die "$filename: $!";  # good
open(my $fh, '<', $filename) or die "$filename: $!";  # good
open(my $fh, '<', $filename) || die "$filename: $!";  # works, but risky!1

use autodie qw/open/;  # at the top of your script / code block
open my $fh, '<', $filename;                          # ok, but read autodie!

You should check the return value of the open function, and if it returns a false value, report the error that is available in the $! variable. It is best to also report the filename as well, and of course you're free to customize the message as needed (see the tips below for some suggestions).

¹ It is a common mistake to use open my $fh, '<', $filename || die ... - because of the higher precedence of ||, it actually means open( my $fh, '<', ($filename || die ...) ). So to avoid mistakes, I would suggest just staying away from || in this case (as is also highlighted in these replies by AM and eyepopslikeamosquito).

Note that open failing does not necessarily have to be a fatal error, see some examples of alternatives here. Also, note that the effect of autodie is limited to its lexical scope, so it's possible to turn it on for only smaller blocks of code (as discussed in kcott's reply).

4. Additional Tips

• Make sure that the filename you're opening always matches the filename in the error message. One easy way to accomplish this is to use a single variable to hold the filename, like $filename in the above examples (as described in Eily's reply).
• Consider putting the filename in the error message in quotes or similar, such as "'$filename': $!", so that it's easier to see issues arising from whitespace at the beginning or end of the filename (as suggested in Discipulus's reply).
• In addition, consider adding even more useful details to your error message, such as whether you're trying to read or write from/to the file, and put quotes around $! as well, so it's easier to tell everything apart (as suggested by haj).
• On Windows, consider also displaying $^E as part of the error message for more information (as suggested in Discipulus's reply).
• If you're setting global variables that will affect reading the file, like $/, it's best to use local in a new block (as mentioned in stevieb's reply).
• Remember that it's possible for multiple processes to access the same file at the same time, and you may need to consider a way to coordinate that, such as file locking (as mentioned in davido's reply).

"If my google alerts don't mislead me Perl is growing nicely in India, China, Russia and Germany... I can testify to growth in Romania, based on the pressure the HR people are putting on me to recruit people from the places I worked before."

I share this good news hoping it will make you happy; and also seeking confirmation from those who know where to find such information.

https://old.reddit.com/r/perl/comments/btt9e9/every_time_i_hear_perl_is_dead_i_think_of_the/eqdno37/

Fellow monks, I humbly submit this basic testing tutorial for review. All comments are welcomed - feel free to send a personal message instead of posting a reply if you so wish.

Rationale: There are only a couple of tutorials about testing here in the Monastery and both of them concern mocking. What is missing IMHO is a nice, gentle introduction to testing with some example code to help take out that first massive leap on the learning curve. I was late to the testing game in Perl and it's a regret that I did not get into it sooner. Hopefully this will be useful to those in a similar situation.

Updates: Add examples of is, like and skip as suggested by haukex and stevieb. Add mention of the t/ directory with prove as suggested by haukex. Add mention of done_testing() as suggested by many respondents.

Now published in the Tutorials section as Basic Testing Tutorial.

Basic Testing Tutorial

One of the widely-acknowledged strengths of Perl is its use of testing as a cornerstone. Almost every module on CPAN comes with its own test suite and there are many modules available to help with testing and to make it as painless as possible. For those looking to add testing to an existing code base or looking to get started with TDD here is a guide to the basics.

Test scripts and TAP

Tests in perl are, at their heart, simple scripts which evaluate a series of boolean expressions and output the results. No doubt you could write such a script in a few minutes and the output would tell you how your test criteria have fared. However, there is a standard form to the output of the test scripts which is best adhered to. This is the Test Anything Protocol or TAP for short. By having your script output the results in this format, they can be analysed by a wealth of other programs called TAP Harnesses to provide summary data, highlight failures, etc.

TAP is an open protocol but was written for Perl originally. It is very simple at its heart. The first line of output is a range of test numbers starting at 1 and each subsequent line consists of three fields: a pass/fail flag which is either "ok" or "not ok", the number of the current test and an optional description of that test. Thus a script containing a single, passing test might output this when run:

1..1
ok 1 The expected file "foo" is present
[download]

A first test script

So, let's write a simple test script which will output TAP. Suppose we want to check that nobody is running our code far in the past. Here would be a trivial test.

use strict;
use warnings;
use Time::Piece;

print "1..1\n";
print localtime(time)->year > 1999 ? 'ok' : 'not ok';
print " 1 Not in a previous century\n";
[download]

When we run this without time-travelling we see this output:

1..1
ok 1 Not in a previous century
[download]

and we see that our test has passed.

Test modules

Of course there are modules on CPAN to help with testing. The simplest of these is, appropriately enough, Test::Simple which is a core module. It is little more than a wrapper with 2 handy functions to ensure that your TAP output is in the correct format. We can rewrite our simple century test with this module:

use strict;
use warnings;
use Time::Piece;
use Test::Simple tests => 1;

ok localtime(time)->year > 1999, 'Not in a previous century';
[download]

Now there are no print statements because the module takes care of all the output. The tests => 1 on line 4 sets the number of tests we expect to run, so we no longer need to print "1..1\n" ourselves. Similarly, the ok function evaluates the first argument as a boolean expresssion and outputs the correct TAP line as a result. The second argument is the optional description.

Technically it is optional but I would encourage you very strongly to include a description for any test. If you have a script with say 50 tests in it and test 37 fails but has no description, how will you know what is wrong? Make life easy for yourself (and your collaborators and even the users) by describing each test in the TAP output.

Other testing functions

While the ok function is useful, the output is a simple pass/fail - it doesn't say how it failed. If our century test fails we don't know what year it thinks it is. For that we would need to write more code or use code someone else has written. Fortunately there is a plethora of other testing modules to choose from, the most common of which is Test::More (also in core). This gives us a heap of other functions so that we can easily perform different types of evaluations and receive better feedback when they fail.

Let's use Test::More and its handy cmp_ok function in our script.

use strict;
use warnings;
use Time::Piece;
use Test::More tests => 1;

cmp_ok localtime(time)->_year, '>', 1999, 'Not in a previous century';
[download]

Note that I've introduced a bug here (using _year instead of year) so that the test will likely fail. Now our test output looks like this:

1..1
not ok 1 - Not in a previous century
#   Failed test 'Not in a previous century'
#   at /tmp/bar.t line 6.
#     '119'
#         >
#     '1999'
# Looks like you failed 1 test of 1.
[download]

We can see at a glance what is being tested and that the year we actually have (119) is clearly wrong so we need to fix the bug. All lines in TAP which start with a hash (#) are comments for the reader: Test::More and friends use this to give us verbose reports about how things have gone wrong.

There are a number of other useful comparator functions in Test::More such as is for simple equality, like for regex and so on. These are fully explained in the Test::More documentation, but their usage is quite straightforward. Let's add a couple of other tests to see how they are used.

use strict;
use warnings;
use Time::Piece;
use Test::More tests => 3;

my $now = localtime (time);
cmp_ok $now->_year, '>', 1999, 'Not in a previous century';
is $now->time, $now->hms, 'The time() and hms() methods give the same 
+result';
like $now->fullday, qr/day$/, 'The dayname ends in "day"';
[download]

There are also control flow structures such as skip to avoid running tests in certain circumstances such as an invalid underlying O/S or absence of a particular module. We could use this here to skip the test of the dayname if a non-English locale applies.

use strict;
use warnings;
use Time::Piece 1.31_02;
use Test::More tests => 3;

Time::Piece->use_locale;
my $now = localtime (time);

cmp_ok $now->_year, '>', 1999, 'Not in a previous century';
is $now->time, $now->hms, 'The time() and hms() methods give the same 
+result';

SKIP: {
    skip 'Non-English locale', 1 unless substr ($ENV{LANG} // 'en', 0,
+ 2) eq 'en';
    like $now->fullday, qr/day$/, 'The dayname ends in "day"';
}
[download]

Further still there are other modules in the Test::* namespace to help with all manner of scenarios.

Working to a plan

It may be the case that the precise number of tests in the script is not known or may change frequently. In those situations, specifying the number of tests like use Test::More tests => 3; can become unwieldy or problematic. Instead we can just use Test::More; and then specify the plan later.

One method of doing this is to call plan () as a stand-alone statement. If the number of tests is dependent on an array which is only computed at run time we could write

plan tests => scalar @array;
[download]

once the array has been populated.

Another approach is to use done_testing (scalar @array); but as its name suggests this must only be called after the final test has been run. The number of tests can even be omitted entirely here but that removes the check that all the tests expected have indeed run, of course.

done_testing ();
exit;
[download]

Using a harness

If you have installed a module from CPAN you will probably have noticed the test phase running. You can use the same harness on your own test scripts by running the prove command. By default this condenses the results of tests and at the end provides a summary of which tests in which files have failed, how long the run took, etc. eg:

$ prove /tmp/bar.t
/tmp/bar.t .. 1/3 
#   Failed test 'Not in a previous century'
#   at /tmp/bar.t line 8.
#     '119'
#         >
#     '1999'
# Looks like you failed 1 test of 3.
/tmp/bar.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/3 subtests 
        (less 1 skipped subtest: 1 okay)

Test Summary Report
-------------------
/tmp/bar.t (Wstat: 256 Tests: 3 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=1, Tests=3,  0 wallclock secs ( 0.03 usr  0.00 sys +  0.06 cusr 
+ 0.01 csys =  0.10 CPU)
Result: FAIL
[download]

This is particularly useful for larger projects with many scripts/modules each of which has many tests. If prove is run with no arguments it will look for files matching t/*.t and run all of those in sequence.

Test Driven Development

Now that you can test your code you can consider TDD as a methodology. By writing the tests before the code you are setting out what you expect the code to do - it's a formal representation of the specification. Doing so is a skill in itself and many people make a career out of being a tester.

See Also

• Modern Perl: Testing
• https://testanything.org/
• How to ask better questions using Test::More and sample data
• Test::Tutorial for another viewpoint
• [RFC] Discipulus's step by step tutorial on module creation with tests and git for incorporating testing into development processes
• Re: Winning people over to better development practises (TDD)

Hello everyone.

I wrote the following subroutine recently using map and grep in the BLOCK LIST style. Line 4 had gotten long, so as you can see, I put the map, grep, and sort on separate lines. After doing that and seeing how good it looked, I began thinking about all the times I used map and grep in the EXPR, LIST format and that I may want to rewrite all of them.

Most, if not all, other people I have chatted with over my years here use the BLOCK LIST format instead of the EXPR, LIST format. I stubbornly stuck with the EXPR, LIST format. Now I am not sure if I am thinking of refactoring to use the format is normally used or if this is refactoring just to refactor. So, I am on the fence on whether or not I should do it.

What do you think?

To celebrate leveling up today, I dug through my code archives and picked one of the oldest full scripts I could find. Although I wrote my first Perl scripts in about 1995, unfortunately those appear to be lost on an old MacBook that won't boot up anymore. Maybe I'll get around to recovering it someday, but for now, here's a script with a modification date of October 1998.

I guess we all have to start somewhere ;-) Can you spot all the bad practices? What does your old Perl code look like?

Since 2016, I've been doing a lot of work regarding the Raspberry Pi with Perl.

Everyone has their interests, engagements and excitement, but I've been working very hard on a significant test platform for my Perl software against the Pi, but I'm starting to understand that there's few others besides me who uses it.

Yes, it's totally a hobby, and I'm happy doing the datasheet translation, soldering of ICs, calculation of resistors and capacitors etc, but is there any real reason to continue to do this for Perl if it isn't being used by anyone else? I enjoy doing this; I enjoy writing the low-level code and bringing it to front so that there's a Perl API. I enjoy this community.

Is it only us old-timers here anymore? What if I sold hardware kits to put together? Does it matter anymore?

I am not saying I will stop writing code for stuff for the Pi in Perl (because Perl is, and will always be my favourite language), I'm just questioning my moves forward. Python clearly has its shit together, but script writers in Python are (typically) not that great, so I'm at a loss here.

This is a mind-fsck question, so answers be damned. I'm as lost as you are ;)

Hi,

I write here so people can find the problem when they search.

XLSX is a Zipped file format with XML. When some applications (it seems Libre Office and others) save as XLSX, they set the dimension size bad. And all the Perl modules I could find failed on that.

A typical example is that in a sheet file (like xl/worksheets/sheet1.xml, after unpacking) you find

<dimension ref="G2296"/>

Spreadsheet::ParseXLSX use Spreadsheet::ParseExcel objects for worksheets etc, so the API is compatible. The get_cell() method there just returns undef if the asked cell is outside the dimension boundaries (which it of course is).

A temporary fix would be to set the MinRow/MinCol/MaxCol/MaxRow values in the spreadsheet object:

for my $s ($parsed_document->worksheets() ) { 
  $s->{MinRow}=0;
  $s->{MinCol}=0;
  # $s->{MaxCol}=100;   (Edit: Not needed)
  # $s->{MaxRow}=7000;  (Edit: Not needed)
  ...
  my $c = $s->get_cell($row, $column);
  ...
[download]

I don't really know enough about the XLSX format. I assume the easy solution is a few lines. Like keeping up max/min column numbers when reading the file. I'll send in a bugfix when I get so far. (With tests so I don't get any grumbles back this time. :-) )

Given are 16 equidistant points in a 4x4 grid.

The coordinates are given with with @set = ([0,0],[0,1],...[3,3])

  y
 
  3  o  o  o  o <- [3,3]

  2  o  o  o  o

  1  o  o  o  o

  0  o  o  o  o <- [3,0]

     0  1  2  3  x
[download]

Task: Find a polygon° with 6 edges, crossing each grid-point exactly once.

@polygon = ([x0,y0],...[x6,y6])

Example: the edge ([-1,4],[3,0]) is crossing 4 points.

Hints:

• The vertices [x_i, y_i] don't need to be part of the integer grid.
• There is a solution where the polygon is closed - i.e. [x0,y0]=[x6,y6] .
• Use fractions or a scaling factor in case floating-point accuracy is posing problems.

Disclaimer: I didn't code it yet, but I saw existing solutions.

Have fun! :)

PS: Extra points for generalized solutions for bigger grids. While this can be solved with paper and pen, I'm expecting code to solve it.

update

Changed orientation of coordinate system to have 0,0 at the left lower corner like in math convention.

your questions:

• bliako: Are polygon sides allowed to intersect? -> Yes !
• bliako: Aren't all polygons closed? -> in math: yes, in computer graphics: depends ;-)
  s/Polygon/Polygonal_chain/ if you want.

footnotes

°) or rather Polygonal_chain

*) See Coding challenges to PM