Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

hex (3272)

hex
  (email not shown publicly)
http://downlode.org/

Perl, RDF and wiki hacker, London, UK. This is my former Perl blog; I now write at Earle's Notebook [downlode.org].

Journal of hex (3272)

Tuesday April 08, 2008
04:36 AM

Weird spread of test failures

I recently released a new module, Encode::Base32::Crockford. While the tests for the module itself are fine, the two associated POD tests (validity and coverage) are resulting in a very strange distribution of failures (testers, matrix).

It looks like something may be objecting to my phrasing eval { something(); } skip $reason, $count if $@;. However it doesn't seem to be a single version of Perl or platform.

I think I'm going to rewrite the tests to use SKIP blocks, but I'm curious to know what's going on here - it certainly looks like a bug in something. Has anyone else encountered this?

Saturday March 29, 2008
11:05 PM

Oh joy! Firefox 3 is too secure for PAUSE.

Secure Connection Failed

pause.perl.org uses an invalid security certificate.

The certificate is not trusted because it is self signed.

(Error code: sec_error_ca_cert_invalid)

Luckily it - I'm using FF 3.0b4 - has a very nice new mechanism that lets you add an exception for specific servers, but really I don't think we should be seeing this in the first place... could our lovely PAUSE people please fix this?

Tuesday January 29, 2008
12:50 PM

Some people have the strangest ideas about version numbering

Monday November 12, 2007
06:46 AM

Simplified parseable Changes: draft 2

I got a lot of positive feedback about my proposal for a machine-readable Changes format. Following on from all the suggestions, this is the revised spec. The big difference from the first version is the expansion of the identifying tokens from single letters to full words, at Juerd's suggestion. The "@" symbol is also becoming overloaded these days, so I've dropped it.

  • Each release is represented by a block of lines. Double line breaks separate releases.
  • A line beginning with \s+ is interpreted as the continuation of the preceding line.
  • Each line begins with a token denoting what item of change metadata it describes, followed by a colon and \s+.
  • The token may be optionally suffixed with an exclamation mark importance indicator, implying the metadata item is important. When applied to a version number, it implies "major release". (Applying it to a date or comment is meaningless and should be ignored by any parser.) The rendition of an important item is down to parser authors.
  • Valid tokens are:
    • change - a change to the code of some kind
    • docs - a change to the documentation
    • fix - a bug fix
    • incompatible - an change that is incompatible with earlier releases
    • license - a change to the license
    • maintainer - a change to the maintainer(s)
    • new - an addition of something
    • security - a security fix
    • tests - a change to the test suite

[Changes to this post following comments: removed removed and re-added change.]

Following are two examples of valid documents in different styles.

# This version was codenamed Muffin because we were listening to Frank Zappa at the time.
version!:
    1.3
date:
    2007-11-08T11:15
maintainer!:
    This project is now maintained by ZIRCON (of Zircon Software fame).
license!:
    We have switched licenses. This software now uses the Greater Zork Software License.
    Please ensure that you have read the new license before using this software.
new!:
    New frobnitz() method - save 50 lines of manual frobnitzing by using this instead!
fix!:
    Fixed the error in quack() where it would actually moo instead of quack. [RT 1234]
incompatible!:
    The calling convention for rumpelstiltskin() has CHANGED. See perldoc.
tests!:
    Test coverage is now 100%! Please go nuts testing this release on your machines
    and let us know what happens.

This one has a more compact look:

version:      3.1
date:         1992-04-06
# You guys are going to love this one. -- billg
# Watch out for Kato, coming this October with native networking support! -- steveb
new:          TrueType font system. No more need for Adobe Type Manager.
new:          32-bit disk access.
new:          Awesome game called Minesweeper. Say goodbye to your productivity.
incompatible: We dropped Reversi. Minesweeper is better, trust us.
incompatible: Can't run in real mode.

Even more compact, without the nice alignment:

version: 1.2.3
date: 2007-11-12
new: beefsteak() gives you beefy goodness
fix: tracked down a memory leak in mtfnpy()
tests: added pod coverage
change: refactored ugly get/set methods into AUTOLOAD

Thoughts?

Friday November 09, 2007
08:04 AM

A simplified parseable format for Changes files

There's a lot of discussion going on at the moment about machine-readable Changes (or CHANGES) files: miyagawa, LTjake. hanekomu put together a new module, Module::Changes, to parse a "Changes.yml" file; RGiersig made some suggestions for the content of that file.

Discussion so far has mainly been around the use of of YAML. Points raised:

  • YAML is less expressive than RDF (me)
  • RDF is hard to write (miyagawa)
  • People want a simple format (everyone)
  • The format should be transformable from human to machine (everyone)
  • Even YAML can have too much chrome (Alias)

Thinking about all of these, I propose the following. Design constraints were (a) granularity (including Skud's suggestions of what to mention), (b) an absolute minimum of chrome, and (c) trivial to transform into other formats (such as RDF).

    v! 1.3
    @ 2007-11-08T11:15
    # This version was codenamed Muffin because we were listening to Frank Zappa at the time.
    m! This project is now maintained by ZIRCON (of Zircon Software fame).
    l! We have switched licenses. This software now uses the Greater Zork Software License.
    Please ensure that you have read the new license before using this software.
    a! New frobnitz() method - save 50 lines of manual frobnitzing by using this instead!
    b! Fixed the error in quack() where it would actually moo instead of quack. [RT 1234]
    c! The calling convention for rumpelstiltskin() has CHANGED. See perldoc.
    t! Test coverage is now 100%! Go us!

    v 1.3_01
    @ 2007-11-07T09:20
    # Developer preview for 1.3 and the CPAN testers.

    v 1.2.1
    @ 2007-11-02T20:08
    d Fixed some POD formatting mistakes.
    c Refactored accessors into AUTOLOAD. Makes no external difference.
    r Removed the deprecated honkhonkhonk() method as warned several versions ago.

As you can see, each version is represented by a block of lines. Double line breaks separate versions. Each line begins with a token denoting what it describes, optionally suffixed with an exclamation mark, which means "important". When applied to a version number, it implies "major release". (Applying it to a date or comment is meaningless and should be ignored by any parser.) The token is followed by \s+. If an item is split onto multiple lines, it is understood to continue until a new token or block break is reached.

These are the tokens:

    @  Release date. In W3C datetime format (ISO 8601).
    #  A comment.
    a  An addition to the code.
    b  A bugfix. Linking to a ticket here would be nice if it exists.
    c  A change to existing code.
    d  A change to documentation.
    l  A change to licensing.
    m  A change to the maintainer.
    r  A removal of something from the code.
    t  A change to tests.
    v  A version number.

I haven't gone quite as far as RGiersig did in his specification, as I felt that was a bit heavy. For example, release stability in my scheme is indicated by the version number - that should be implied from the existing convention of underscored version numbers for developer releases.

Vague other thoughts - case-insensitive tokens? And maybe a standard block of comments at the beginning of the file explaining what the tokens are to new readers.

Thoughts? I actually like this enough that I might start using it myself.

Update: There's a second draft now.

Tuesday September 25, 2007
08:16 AM

Huxley Associates: not malicious, just stupid.

A full fifteen days after emailing Huxley Associates to stop their spam, I just got an email from them with the subject "EZ CR DATA PROTECTION REMOVAL CONFIRMATION_10729672". It was empty apart from a massive (1K of text) signature - with a malformed signature separator, naturally. Attached was a 106K Word document called "DATA PROTECTION REMOVAL CONFIRMATION_10729672.doc". Here's what it said:

[Image: "Huxley Associates"] [hyperlinked email address]

Mr Earle Martin

London

E11 1BG

UNITED KINGDOM

Our Ref.: 10729672

25 September, 2007

Dear Mr Martin,

With respect to your recent request, I can confirm that we have removed your details from our Database.

If you require any further assistance please do not hesitate to contact us at the above email address.

Yours sincerely

Data Protection Controller

That was it. Two weeks' wait. And 106K of Word document for that. Not even an HTML email. Word document.

Some people should just be banned from using computers.

Friday September 21, 2007
09:05 AM

Locale::Object gets a community

Over the last few months, more and more people have been getting in touch with me to talk about using Locale::Object in their projects. As of today, Jess Robinson (castaway) has kindly provided a Subversion repository for the project in advance of some modifications she's planning. I've also created a #locale-object on irc.perl.org, and a mailing list at Google Groups. If you're using Locale::Object, please stop by and say hi.
Sunday September 16, 2007
01:13 PM

Claire O'Keeffe and Huxley Associates are spammers

A while back I put my CV on Jobsite because all the recruiters read it and there's plenty of good work to be found. In due course it got me a good gig. However, shortly after that I started getting recruitment spam from some company called Huxley Associates. For PHP jobs. As you can imagine, I didn't ask for it. Nor had I ever heard of them, let alone subscribed to any kind of mailings from them. Somewhere I found that to unsubscribe from their spam, you had to mail a certain address. Here's what I sent:

Date: Mon, 10 Sep 2007 15:17:43 +0100
From: "Earle Martin" <jobs(at)downlode.org>
To: audit.data(at)huxley.com
Subject: Data removal request

Please remove my name and email address (jobs(at)downlode.org) from your
system and do not email me again.

Here's what I just found in my inbox:

O'Keeffe, Claire     PHP DEVELOPER LAMP SKILLS GBP30,000     16:57
O'Keeffe, Claire     Situation Update     16:56
O'Keeffe, Claire     PHP / LAMP DEVELOPER Needed asap GBP30,000     16:56
O'Keeffe, Claire     LAMP DEVELOPER FARRINGDON URGENT     16:56
O'Keeffe, Claire     LAMP Developer Needed asap GBP30,000 FARRINGDON     16:46
O'Keeffe, Claire     LAMP Developer Needed Farringdon GBP30,000     16:46
O'Keeffe, Claire     PHP LAMP Developer Needed ASAP GBP30,000     16:45
O'Keeffe, Claire     PHP Developer with ASP Needed asap     16:45

[Pound signs replaced with "GBP" because I can't work out how to get this hateful piece of software to display HTML entities.]

Yes, that's eight pieces of spam in less than fifteen minutes. On a Sunday. Please boycott Huxley Associates. They are spammers.

Thursday September 13, 2007
05:45 AM

I'm not happy with the "gravatars" on search.cpan.org.

While I appreciate the intent behind the recent decision to add these "gravatars" to search.cpan, I feel that the execution has been poorly thought through. This is a summation of points raised so far.
  1. While it looks nice, Gravatar is slow as crystals forming on a frozen monkey's ass. This has led to the necessity of having to write a daily grab-and-cache system for the images. If it's that bad, why don't we just write something ourselves that doesn't suck?

  2. Poor URI design at gravatar.com: http://www.gravatar.com/avatar.php?gravatar_id=aae56c6a384319c00094d626845f6b6d

  3. It costs money ($10/year) to have more than one email address added to the system. Frankly, the commercial aspirations of the person who runs Gravatar are embarassingly transparent. That went out with the bubble, guy. If you're going to propose a "global" system like this, you have to do it for free, because that's what people expect - cf. OpenID. If you don't, somebody else will. (I wouldn't be surprised if someone in the Perl community up and does it, simply because of how poor gravatar.com is.)

  4. Talking of OpenID, I commented on one of the above posts that I'd only use Gravatar if it supported OpenID logins. I've been signing up to various websites for well over a decade now, and I'm dog tired. It's bad enough that I have separate PAUSE and BitCard and use.perl logins already; now we're going to throw in yet another incompatible system?

    Yes, I know, as Schwern points out, that implementing OpenID support in PAUSE and Gravatar would take some work. The burden here falls largely on Gravatar. PAUSE doesn't need to fully support OpenID logins yet, but it could simply have a field for OpenID URIs in user settings and query Gravatar on that basis.

  5. Not every search.cpan user reads use.perl.org. Adding this feature to search.cpan.org without wider consultation is, I feel, a mistake.

  6. Having a user picture on author pages is fine, but I don't want my ugly mug staring out at people from documentation for my modules. Sorry, but that just looks unprofessional.

  7. If you're going to add "social" features, you have to go the whole hog. Add user accounts to search.cpan, with preferences. One of those preferences must be "Display author pictures?"

  8. Where is Graham? Why has he not participated in any discussions on this site so far, and we have to email our comments to him? And why is the code that runs search.cpan.org not open? I've heard that question asked over and over, and we've never had a satisfactory response.

  9. Before we start adding new stuff, can't we get our own house in order first?

    • cpanratings.perl.org ratings.cpan.org
    • cpanforum.com forum.cpan.org
    • annocpan.org annotate.cpan.org

    Yes, I know these are all different projects, but even though they're all fairly-well accepted by now, there's barely any interconnection between them, and they don't even have similar URIs. We're a mess.

Until some more thought has been put into this, I think I'm going to follow the example of LotR on #perl and add gravatar.com (and search.cpan.org cached copies) to my AdBlock filters.

-- Earle

Monday August 06, 2007
04:03 PM

What happened to Perl in London bookshops?

I was in the Borders on Oxford Street today. Out of curiosity, I looked in the Computing section - it didn't help that it was abysmally organized, but I couldn't see a single Perl book. Not one. Zilch. I remember looking in Foyles a little while before that, and finding maybe two Perl books. Yes, two - and one of them was the one with the monkey on the front. I had a similar result at a Waterstone's somewhere (I forget which), and wouldn't be surprised if Blackwell's don't have any either.

What happened?