If you've discovered something amazing about Perl that you just need to share with everyone, this is the right place.

This section is also used for non-question discussions about Perl, and for any discussions that are not specifically programming related. For example, if you want to share or discuss opinions on hacker culture, the job market, or Perl 6 development, this is the place. (Note, however, that discussions about the PerlMonks web site belong in PerlMonks Discussion.)

Meditations is sometimes used as a sounding-board — a place to post initial drafts of perl tutorials, code modules, book reviews, articles, quizzes, etc. — so that the author can benefit from the collective insight of the monks before publishing the finished item to its proper place (be it Tutorials, Cool Uses for Perl, Reviews, or whatever). If you do this, it is generally considered appropriate to prefix your node title with "RFC:" (for "request for comments").

User Meditations
RFC: Test::Refute - extensible unified assertion & testing tool
1 direct reply — Read more / Contribute
by Dallaylaen
on Jan 05, 2017 at 03:28

    I would like to present a new assertion/testing tool project. Now there's excellent Test::More with a whole ecosystem built around it and a dozen assertion tools (typically optimizing themselves out in prod environment) available on CPAN. So WHY?


    1. It's more or less compatible with Test::More. Actually it aims to be 100% compatible condition-wise and somewhat compatible regarding the test flow, sans black magic like TODO: and SKIP:. (Saner substitutes planned).

    2. It has both functional AND object-oriented ("contract") interface. Contracts can be used in production code, say to check user input or plugin module meet requirements. Nesting contracts is possible (that's how subtest is implemented).

    3. It's very easy to extend (see below). A Builder is still required, but all it does is wrapping a given condition around for export AND OO-based usage. The internal check logic does NOT depend on it. Writing a custom Contract backend (e.g. outputting XML, or dying after a certain error count) is also possible.

    4. Built with testability in mind. Custom tests' failure modes can be easily checked.

    5. It's faster. Up to 5x-7x in a synthetic test (see t/speed.t) and up to 30-50% in real life test suite.

    I'd rather continue dreaming about the contract feature, if this rant wasn't the last drop.


    The test script usage is quite simple (read: ripped off Test::More):

    use Test::Refute; is 42, 42, "this holds"; like "foo", qr/bar/, "this fails"; done_testing; # this is mandatory, even if plan declared

    Or the object-oriented interface, runs just happily inside production code (on "oks" on STDOUT, no influence on return code etc):

    use Test::Refute::Contract; my $c = Test::Refute::Contract->new; $c->is($user_input, 42); $c->like($another_input, qr/f?o?r?m?a?t/); if ($c->is_valid) ...

    Or combining best of both worlds:

    use Test::Refute qw(no_init); my $c = contract { is $user_input, 42; like $another_input, qr/f?o?r?m?a?t/; }; # analyze $c here ...

    The project is in deep alpha stage right now, but I hope it evolves into something usable. Looking forward to your support, critique, suggestions, and prior art links.

Leap second coming up. Check your date handling code
5 direct replies — Read more / Contribute
by 1nickt
on Dec 25, 2016 at 16:18

    Hi all,

    A friendly reminder that a leap second will be added to the clock at the end of 2016. If you do date math at all, you may want to check that your date handling code is ready for it.

    For example, versions of DateTime below 1.34 won't handle it correctly:

    $ perl -MDateTime -E 'say $DateTime::VERSION' 1.33 $ perl -MDateTime -E ' my $dt = DateTime->new( time_zone => "UTC", year => 2016, month => 12, day => 31, hour => 23, minute => 59, second => 60 ); say $dt->datetime; $dt->add( months => 1 ); say $dt->datetime; ' Invalid second value (60) at -e line 2.
    $ perl -MDateTime -E 'say $DateTime::VERSION' 1.39 $ perl -MDateTime -E ' my $dt = DateTime->new( time_zone => "UTC", year => 2016, month => 12, day => 31, hour => 23, minute => 59, second => 60 ); say $dt->datetime; $dt->add( months => 1 ); say $dt->datetime; ' 2016-12-31T23:59:60 2017-02-01T00:00:00

    Hope this helps somebody :-)

    The way forward always starts with a minimal test.
RFC: new.pm - a perl -e use/new shortener
7 direct replies — Read more / Contribute
by Dallaylaen
on Dec 24, 2016 at 06:20

    I tend to use perl one-liners extensively, mostly for testing purposes. In particular, I often load a module with a loooooooooong name only to instantiate it once. And it's boooooooring to type the whole name twice.

    So I came up with an idea of a one-liner shortener along the lines of:

    perl -we 'use new qw(My::Very::Long::Module x foo 42); print $x->get_f +oo;'
    Which is a rough equivalent of
    perl -we 'use My::Very::Long::Module; our $x = My::Very::Long::Module- +>new( foo => 42 ); print $x->get_foo;'

    And I have a proof-of-concept implementation that works as follows:

    • require module being called;
    • create a new instance;
    • create a package variable in the calling package (so that strict doesn't complain);
    • set that variable to instance from above.

    Here it is.

    package new; use strict; use warnings; =head1 NAME new - shorted require Foo; Foo->new(...) to just one call =head1 SYNOPSYS use new qw(My::Very::Long::Module x foo 42); is an exact equivalent of our $x; BEGIN { require My::Very::Long::Module; $x = My::Very::Long::Module->new( foo => 42 ); }; or a rough equivalent of use My::Very::Long::Module; our $x = My::Very::Long::Module->new( foo => 42 ); Not a big deal in a real program, but may save some typing in a one-liner test script. Works well under C<use strict;>. =cut $Carp::Internal{ (__PACKAGE__) }++; sub import { my ($self, $target, $name, @args) = @_; my $filename = $target; $filename =~ s#::#/#g; $filename .= ".pm"; require $filename; my $obj = $target->new( @args ); my $caller = caller; $name ||= 'new'; my $sym = join "::", $caller, $name; no strict qw(refs vars); *$sym = \$$sym; $$sym = $obj; }; 1;

    Made purely for fun, but maybe there's some point in it after all.

    UPDATE Available as gist.

Typing Perl with Speech Recognition
2 direct replies — Read more / Contribute
by Anonymous Monk
on Dec 22, 2016 at 17:43
Perl denormalized-to-normalized schema translation, maybe with DBIx::Class (maybe)
2 direct replies — Read more / Contribute
by gryphon
on Dec 20, 2016 at 12:09

    Greetings all,

    I have a strange situation, wondering if there's a DBIx::Class-ish option that might help me. We've got a very large, old, spaghetti, denormalized Oracle database and a sea of CGIs with embedded, hardcoded SQL. Ultimately, I'd like to refactor the schema, normalize it, add FK constraints, and all the usual good things. But I can't without considerable destabilization risk to the CGIs.

    The strategy at this point is to carve out chunks of CGI functionality and refactor each chunk into an isolated web service with its own data store. But in doing this, we'll need to maintain two data stores for a while: the existing legacy denormalized store and the new and smaller/better normalized store. We need to keep these in sync for a while until we have refactored enough to deprecate the old schema. So what we need then is a "translation layer" behind each new web service that sees changes to the local data store and pushes those changes to the legacy database (until we can eventually deprecate the legacy db).

    I'm envisioning this "translation layer" would need to understand both schemas (the new local store and the legacy Oracle), and would need to understand how to map data between the two. A lot of this will be heavily manual at the detail level, I understand. But I'm wondering if anyone knows of a scaffolding/framework option I should consider before starting something custom from scratch.

    The intent is to use DBIx::Class::Schema::Loader to auto-build the Perl schema classes from the legacy database schema, and we'll probably use it also for the new schema. But once we have these two sets of schema classes, I'd like a way to link them. Certainly, the details of this linking will have to be very custom.


The state of Perl
3 direct replies — Read more / Contribute
by FreeBeerReekingMonk
on Nov 30, 2016 at 15:01
    Some other monks made comments about the quietness on this site... here are some visual clues and trends:

    As measured by github changes and stackoverflow tags....

    Programming Language Popularity Chart

    And also:

    job-trends for perl and similar

    If you add C++ to the latter, you will see nobody is looking for C++ jobs (but they search for C instead).

(Placeholder) Imagine!
5 direct replies — Read more / Contribute
by BrowserUk
on Nov 29, 2016 at 22:24

    This place excels in starting with a single, clearly defined, abstracted problem, and refining the set of proposed solutions down to a clear, concise, efficient solution. Many hands make light work!

    Now, imagine if each of the Perl(5) opcodes was proffered here -- say: one per weekend -- on a Friday night - say: US West Coast time -- in the form of a hack-a-thon task for that weekend.

    What might result from that exposure of a clearly defined task to the assembled (and usually quite bored on weekends), diverse populous?

    If those more enlightened tolorant members of p5p were enthused to cast a critical eye over the proceedings -- to catch the less obvious pitfalls in the evolution of solutions -- then the results might be usefully fed back into the p5p process and result in benefits for all.

    Thoughts on: Is the idea viable?

    Thoughts on: Are any members of p5p willing to participate?


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
    In the absence of evidence, opinion is indistinguishable from prejudice.
Propose addition to use warnings?
6 direct replies — Read more / Contribute
by perldigious
on Nov 28, 2016 at 09:30

    I'm not sure what the official mechanism for making such a suggestion would be, but I recently had to go on a bug hunt in my code that left me surprised use warnings didn't give me some sort of, "are you SURE you aren't doing something silly here at line x?" message. Maybe it isn't practical to expect use warnings to save me from myself in this case, but I figured I'd throw it out here as a meditation for discussion and to get opinions from Monks far wiser than I am.

    I'm of course simplifying and paraphrasing, but essentially I had some code that did the following:

    open(my $first_fh, "<", "file1.txt") or die "Cannot open \"file1.txt\" +: $!."; open(my $second_fh, "<", "file2.txt") or die "Cannot open \"file2.txt\ +": $!."; my @file1_lines = <$first_fh>; close $first_fh; while (my $line = <$second_fh>) { my @data = my_sub($first_fh, $line); # copy/paste error, should ha +ve passed $second_fh here # and of course a bunch of non-relevant stuff here }

    So I accidentally passed the $first_fh that I had previously closed to my_sub, but as it turns out use warnings didn't make a peep about this. I did of course get warnings from inside my_sub when it attempted to make use of the filehandle, but the kicker was that any such use was wrapped inside of a conditional that actually made it very rare it would ever get used (maybe once every 100,000 lines or so of typical data).

    DISCLAIMER: The fact that I didn't have something in my standard test data that ensured the conditional that used the filehandle was exercised is entirely on me (forgive me, for I have sinned). I accept full responsibility for that mistake and the initial copy/paste laziness error that forced me to engage in my bug hunt. I'm only pointing out that usually use strict, use warnings, or perl itself is pretty good about preemptively saving me from myself, and in this case it didn't.

    Any thoughts from the Monastery?

    Just another Perl hooker - will code for food
storeBackup - A Gem of a Backup Solution
1 direct reply — Read more / Contribute
by wjw
on Nov 20, 2016 at 11:49

    I was recently in a position where I needed a backup solution that was flexible enough to handle my laptop as well as my home server. I back up to a couple of older USB drives; A 1.5T for my laptop, and a 750G for my home server. The plethora of options out there is daunting, and the most obvious like rsync (which I really like and use often) are very nice. But I wanted something that I could set up quickly and would meet a couple of other needs easily.

    • I wanted it to conform to a standard backup scheme where there are a couple backups each day, a daily backup for a week or so, a monthly backup, and a yearly.
    • I wanted it to delete outdated backups
    • I wanted it to be tolerant of the backup drive not being available, such as when I am out of town with my laptop, but don't have the USB drive to back up to.
    • and ... I also wanted it to do something like rsync in that it stores only the differences, not an entire copy of everything in each backup.

    What I found was a Perl application called storeBackup. It has been around for a while, claims to be production ready/stable, and it seems to me as if it is.

    I did a non-exhaustive search here on perlmonks and did not find a reference to this handy tool, so thought I would mention it here in meditations....as I was sitting here meditating about it. The darn thing works really well! It does exactly what I want it to do in that it meets all the requirements listed above, and has the added benefit that it is written in Perl.

    For anyone looking for a very sweet backup solution that is simple to set up, is tolerant of a dynamic environment, and provides efficient, accessible, and easily recoverable backup data, I would certainly recommend looking at this solution. From my perspective, it just plain rocks!

    ...the majority is always wrong, and always the last to know about it...

    A solution is nothing more than a clearly stated problem...

RFC: Potracheno - a technical debt issue tracking system
No replies — Read more | Post response
by Dallaylaen
on Nov 14, 2016 at 06:50

    Hello dear esteemed monks,

    Today I would like to present a tool of my own which I hope you'll find useful.


    Every once in a while I encounter a technical debt discussion on the internet. Each time there are generally two types of comments: (1) tech debt is bad, it leads to bugs, delays, downtime, top talent quitting and product rewrites, and (2) nobody pays for clean code, all you need is features here and now.

    Being a supporter of the first cause myself, I keep wondering if the damage can actually be measured. And it looks like there is a way.

    The tool

    Potracheno (a Russian adjective with a meaning close to "wasted" or "spent") is a specialized tech debt issue tracking system. Just like a normal bug tracker, it has tickets, ticket statuses and comments, search, and so on. It supports markdown and Stackoverflow-like tags. Nothing much to boast about.

    Also like a normal bug tracker it has time tracking facility. However, instead of recording time spent fixing a problem, it tracks time wasted on living with it. Copy-and-pasting, fighting bugs, doing manually what could be automated, waiting for long compilation/deployment, and generally being frustrated and posting about it on the net.

    Completely unlike a normal bug tracker, it has a special feature called solution proposals. A solution is a special comment with a time estimate to fix the issue. Multiple solutions can be proposed for the same issue.

    Finally, a report with numerous criteria can be generated. Including, but not limited to, the fix estimate / wasted time ratio.

    The project is written in Perl and SQLite with minimal dependencies (DBD::SQLite, Text::Markdown, and MVC::Neaf). It is designed to run from local directory on any network-enabled device, be it a dev's laptop, a test server, or a coffee machine in the office.

    Source: https://github.com/dallaylaen/potracheno.

    A little philosophy

    The supposed setting for this tool is a team sick of bad code and willing to refactor it - refactor in the broadest sense, including rewriting specific components, fixing architecture/preformance problems, writing missing tools etc - anything that improves the project on the inside.

    Also somewhere must be the project owner, who only wants features as soon as possible. Well, if they wanted something else, the team would be out in the street with a well written product that nobody uses.

    This tool is supposed to be installed alongside a normal ITS (if you don't have one, tech debt isn't your biggest problem for sure). As statistics and solutions accumulate, they either should be presented to the product owner and converted to usual tasks, or silently included with features touching the same component(s).

    I believe that, similar to performance profiling, 80% of the team's frustration are accounted for by a tiny subset of problems that can be numbered, weighted, and dealt with once and for all. Whether this holds, only practice can tell.

    And finally

    I would like to ask you, fellow monks, to try and follow the installation instructions of my project, and tell me (either here, or in the github bugtracker) what went wrong. I'm planning to release it onto non-Perl users (thus acting as a Perl-monger), so I would like the process to be as smooth as possible.

    Thanks for reading, and have a great day and a great week!

OT: Programming For Kids
6 direct replies — Read more / Contribute
by karlgoethebier
on Nov 13, 2016 at 13:41

    This is something i would like to share.

    The last two weeks i took care of a 14 year old trainee at the company i'm with.

    I needed to prepare something for him and by chance i stumbled over Scratch.

    IMHO this is real good stuff. We had a lot of fun. Highly recommended.

    Please see also Snap! It looks like Scheme is not dead ;-)

    Regards, Karl

    «The Crux of the Biscuit is the Apostrophe»

RFC: Shortening line length in HTML Emails
2 direct replies — Read more / Contribute
by LanX
on Oct 27, 2016 at 12:02

    My team is using TinyMCE in a web-application to create templates for HTML emails. (not my idea)

    We've been confronted with strange errors where whitespaces occasionally where introduced in the middle of the emails after sending.

    This was particularly ugly b/c sometimes HTML tags where broken, like in </sp an>

    A closer investigation revealed that by RFC lines in Emails are not allowed to have more than 1000 characters (only fair) and that TinyMCE sometimes tended to glue HTML code into one "physical" line, especially when

    • "visual" lines where separated by <br> tags
    • or when the text was introduced by cut&paste from other applications.
    So I need a pragmatic solution to avoid such "monster" lines after editing an email text.

    I came up with the following idea, which should be as safe as possible without starting to parse HTML

    1. prepend a \n before every <br> tag
    2. if overlong unbroken text-chunks remain, replace the last blank with a \n
    3. return an error to the user if the later fails
    The idea is to change a minimal amount of HTML code in a transparent way.

    (I suppose that <pre> -tags are not used with monster lines and that the inner code of HTML and CSS doesn't distinguish if a whitespace is a blank or a line-break)

    That's the code I came up with, comments are welcome! :)

    use strict; use warnings; use Data::Dump qw/pp dd/; my $body = <<'__HTML__'; <br /><br/><br><break> asdfghjk rtz ertzuiop rtzuiopu rtzuiop tzuiopu rtghljh AaaaaaaaaaaaaaABbbbbbbbbbbbbbbB __HTML__ #pp $body; my $err = FC012_shorten_lines_mail_body(\$body); #pp $body; print $err,$body; sub FC012_shorten_lines_mail_body { my ($body_ref) = @_; my $err = undef; # callback with closure for error my $replace_last_whitespace = sub { my ($chunk) = @_; # dd "CHUNK: $chunk"; my $ok = $chunk =~ s/ ([^\s]*)$/\n$1/; unless ($ok) { my $snip_length = 4; # for testing, should be 40 my $start_chunk = substr ($chunk,0,$snip_length); my $end_chunk = substr ($chunk,-$snip_length,$snip_length); $err .= "Failed to shorten chunk >>$start_chunk...$end_chunk< +<\n"; } return $chunk; }; # --- prepend all <br>-tags with real linebreak $$body_ref =~ s#(<br[ />])#\n$1#g; # --- find all reamining chunks in one line and # replace last whitespace with \n my $length = 15; # for testing, should be 998 $$body_ref =~ s/([^\n]{$length})/ $replace_last_whitespace->($1) /g +e; # --- return potential error message return $err ; }


    Failed to shorten chunk >>Aaaa...aaaA<< Failed to shorten chunk >>Bbbb...bbbb<< <br /> <br/> <br><break> asdfghjk rtz ertzuiop rtzuiopu rtzuiop tzuiopu rtghljh AaaaaaaaaaaaaaABbbbbbbbbbbbbbbB

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Je suis Charlie!

Testing Dancer applications with a custom database
No replies — Read more | Post response
by Corion
on Oct 24, 2016 at 13:10

    While developing a plugin for Dancer as a wrapper around one of my modules, I wanted to unit test my code using a mock database instead of the database I do interactive tests with. Surprisingly, I didn't find documentation on how to supply Dancer::Plugin::Database with your own test database.

    After some reading through the test suite of Dancer::Plugin::Database, it seems that the magic is in overwriting the configuration at the right time. To give this approach a broader exposure and to maybe invite some comments or better suggestions, let's look through the code:

    In the prelude, we load Dancer, Dancer::Test and the application I'm writing, tentatively named mychat. We plan for three tests:

    #!perl -w use strict; use warnings; use Test::More import => ['!pass']; use Data::Dumper; use Dancer ':syntax'; use DBIx::RunSQL; use Dancer::Plugin::Database; # the order is important use mychat; use Dancer::Test; plan tests => 3;

    Then, we set up our own in-memory database and create all tables and triggers from the SQL file stored in sql/create.sql. This gives us a pristine database that contains only initial data.

    # set up our own database instead of whatever is in the config my $conf = { Database => { dsn => 'dbi:SQLite:dbname=:memory:', connection_check_threshold => 0.1, sqlite_unicode => 1, dbi_params => { RaiseError => 0, PrintError => 0, PrintWarn => 0, }, }, }; set plugins => $conf; # Set up a fresh instance my $dbh = database; $dbh = DBIx::RunSQL->create( dbh => $dbh, sql => 'sql/create.sql', );

    Since what I really want to test is whether image upload and retrieval works, let's fake a PNG image and "upload" it into the application:

    my $payload = join '', "\x89", 'PNG', "\x0d\x0a", "\x1a", "\x0a", (map { chr($_) x (1024 * 256) } 1..3) ; # Insert image into database my $upload = Dancer::Request::Upload->new( filename => 'test.png', tempname => 'test2.png', size => length($payload), headers => { 'Content-Type' => 'image/png', }, ); # Insert into DB my $content = mychat::UserContent->store( config->{image_store}, $dbh, $upload, { extension => 'png', content_type => 'image/png', }, $payload );

    After all this setup, we can now run three tests as if we had a standard Dancer application and can check that URLs exist where we expect them and that we get the appropriate content from each URL:

    ok $content, "We successfully saved the user content"; route_exists(['GET', '/image_store/foo.bar'], "We find /image_store/fo +o.bar"); # Check that we can access it through /image_store/sha1.jpg my $name = $content->{digest} . ".png"; response_status_is ['GET',"/image_store/$name"], 200, "GET '/image_sto +re/$name' succeeds" or diag Dumper read_logs();
Why aren't you using Google::API::Client?
1 direct reply — Read more / Contribute
by mla12
on Oct 24, 2016 at 12:23

    I stumbled on this module a while ago. It has some rough edges and the docs aren't the greatest, but I've found it incredibly useful.

    It uses the Google Discovery API to interact with any of their services.

    So why isn't it more popular? Is there another module that serves this purpose better?

RFC: MVC::Neaf aka Not Even A Framework, part 2
No replies — Read more | Post response
by Dallaylaen
on Oct 18, 2016 at 16:10

    Hello dear fellow monks,

    After weeks of hesitation, I finally decided to share a piece of work called MVC::Neaf. Neaf [ni:f] stands for Not Even A Framework.

    It aims to keep things simple and straightforward, while maintaining some degree of separation between logic and presentation.

    Not to repeat myself, here's the original post.

    I know there's a lot to do, so I would appreciate any feedback. If you dare to try it out, please send bug reports and feature requests to github.


Add your Meditation
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.