Why I Didn't Submit A Patch

Currently RT cannot talk to PAUSE, so I can't submit a bug report for this:

perl -Mutf8::all -MDateTime::Tiny -E \
    'say DateTime::Tiny->from_string("୭୮୯௦-௧௨-௩௪T௫௬:௭௮:௯౦")'
0000-01-01T00:00:00

The problem are these lines from the DateTime::Tiny code:

unless ( $string =~ /^(\d\d\d\d)-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)$/ ) {
    Carp::croak("Invalid time format (does not match ISO 8601)");
}

Ignoring the fact that DateTime::Tiny uses Carp but doesn't load it, it also falls prey to the well-known problem problem where \d matches Unicode digits, not just ASCII ones. For example, this code:

use utf8::all;
my $num_matched = 0;
for ( 1 .. 2**16 ) {
    my $char = chr($_);

    if ( $char =~ /\d/ ) {
        $num_matched++;
        say "$_ => $char";
    }
}
say "$num_matched characters matched";

Will spew out a lot of strange characters before saying that you've matched 360 "digits".

The fix is to reply all of the \d with [0-9] or, in 5.14 or later, use the new /a modifier which tries to match ASCII only, when appropriate. See perlre for more information.

Since I can't log into RT, I can't file the bug report. However, Adam does offer a repo: svn.ali.as/cpan/trunk/DateTime-Tiny and that's why I didn't submit a patch.

I gave up on Subversion (and CVS) a long time ago. If you offer me a contract, I'll work with whatever source control you use. That's just part of being a professional. However, for the open source world, I am not getting paid and thus, when I contribute to open source, I have a few personal guidelines:

  1. The other devs should be pleasant to work with
  2. The code base should be relevant to me or at least fun
  3. The barrier to entry should be as low as possible

Adam's code passes 1 and 2, but it doesn't pass 3. Using distributed source control systems is, for me, so much easier that I no longer have any desire to work CVS and SVN for unpaid work. I'm not saying it's hard to do, and for this case, it's trivial, but here's what happens with git:

  • git clone $project
  • # make a change
  • git commit @files
  • # make a change
  • git commit @files
  • # make a change
  • git commit @files
  • Rerun all tests one last time (in case I screwed up)
  • git request-pull (or just do it on github)

With Subversion, that above workflow is a pain and, as a result, changes tend to come in one big chunk followed by a svn diff > path/to/monster/patch.

What's worse, if I want to send follow up patches, do I base them on my possibly unaccepted (and uncommitted) ones or do I throw everything away and start from scratch?

I don't need the added hassle. I just want to clone, fix, issue a pull request and have more time to spend with my wife and daughter. Ironically, I spent more time writing this than I would have spent making a patch and mailing him a diff and I feel awkward enough about this that I wrote a test, fixed the code, and am emailing him a patch now (making me a damned liar, I suppose). That being said, when I see open source repos in Subversion, I simply ignore them now. When I had mine in Subversion, I hardly received any patches (and invariably couldn't apply the patch!). Now I receive them all the time since much of my code's on github. I'm not the only one who refuses to mess with Subversion.

Update: ... aaaannnddd my email with the patch bounced. I sent it to two of my email addresses for Adam, but yet another reason to add to the above list.

7 Comments

Take a look at git svn clone, this makes working with svn almost pleasant.

You know you have commit to the repository right?

Adam, I see that you already have a github account. Whenever you're ready to jump on the bandwagon and convert your SVN repository to Git, I'm willing to help.

I know you have everything in a giant SVN repository. It's possible to split it in whatever arrangement of individual Git repositories, while keeping the history correct (with names, emails, tags, possibly branches, etc). I've done it for all of my SVN repositories, and also from some more complex ones, like DateTime-Format-Mail, which was part of the (now deleted) perl-date-time SVN repository on sourceforge.

I suppose the most straightforward would be to turn each subdirectory of trunk/ into an individual Git repository.

If time, motivation or Git skills were the resources you were missing to switch to Git... Well, at least I can offer the motivation and skill. ;-)

Hi,

Isn't more the problem that you're changing the definition of \d with -Mutf8::all than that \d was used wrongly?

Note that \d specifically matches characters with the Unicode General_Category property value Decimal_Number (a.k.a. Nd and Digit), not everything with the Number value (a.k.a. N), and nothing with the Letter_Number value (a.k.a. Nl) which you linked to. By the way, here's an example pull request (with tests) for when I fixed the same problem on someone else's GitHub project.

Leave a comment

About Ovid

user-pic Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you. And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/