use Perl

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?

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?

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?

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.

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

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.

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

What happened?