PerlNet and The Perl 5 Wiki
A couple of days ago Schwern posted an announcement unveiling The Perl 5 Wiki. There's been a lot of discussions regarding this, including on mailing lists, use.perl and IRC. Throughout the discussions PerlNet is mentioned regularly. As PerlNet was my initial creation, I'm sure that some of you may be wondering what my thoughts are about all this. To be honest, so have I. ;)

PerlNet was founded in the spirit of openness and sharing. I wanted a place where members of the Perl community, in particular the Australia/New Zealand (ANZ) Perl community, could interact. I wanted businesses to show off what they were doing with Perl. I wanted individuals to talk about what they were creating. I wanted those just taking their first steps into Perl to able to find people they could ask for help, communities they could feel comfortable entering. Fundamentally, I wanted, and still want, the ANZ Perl community to grow.

In this regard, I feel that PerlNet has been a modest success. We host the content for Sydney.pm, and much of the content for Melbourne.pm. We've got a short list of businesses that offer Perl services, although it's not as big as the list of businesses who I know are using Perl. We get bunch of contributions after most Melb/Syd.pm meetings, depending upon the eagerness of the individuals present to do summaries and take notes.

PerlNet has also been successful in developing content on other topics. We've got a great page on Catalyst, an excellent page on testing, and a a list of IDEs and editors. I refer to these all the time, and refer my students to them as well.

Unfortunately, these pages aren't seeing much activity anymore. There still many stubs that have never grown, and are unlikely to do so any time soon. Having a wiki is about having a community, and about the creation of content. I think that PerlNet is still doing well with the creation of ANZ content, but it's stalled for material beyond that.

As such, I welcome the new Perl 5 Wiki. It's a chance to develop content that PerlNet's not been successful in creating, and a chance of taking existing good content and turn it into something really great. PerlNet was founded in the spirit of sharing, and sharing with The Perl 5 Wiki is a logical and natural continuation of PerlNet's ideals.

Schwern has given me enough reasons to believe that The Perl 5 Wiki will succeed, and I know from many years of working on wikis that the initial growth phase is critically important. I've had discussions with many of the more active contributors, and there seems to be almost universal support in the relocation of non-ANZ content to The Perl 5 Wiki where appropriate.

Our last real stumbling block actually deals with licensing. PerlNet and The Perl 5 Wiki solicit contributions under different conditions, and there are some incompatibilities between the two. We've got some good people working on the best way to overcome this, and I hope to soon have a way that PerlNet contributors can easily mark their content as Perl 5 Wiki friendly.

If anybody does wish to discuss this matter with me further, then I invite you to do so by getting in touch with me at pjf@cpan.org or catching me (pfenwick) on irc.freenode.net #PerlNet.

$?, system() and win32
Warning: Technical post ahead.

I've been working on improvements to IPC::System::Simple, and discovered a tricky problem while writing more test cases. Put very simply, when using system() under Windows I'm unable to tell the difference between a command that we can't find, and one that we can find, but returns an exit value of 1.

The problem is two-fold. Firstly, whenever we invoke a shell to spawn a process, we can't ever tell the difference between the shell returning a "can't start" value, and a command that runs successfully and returns the same value. This isn't a problem that's unique to Windows; the "can't start" value is 1 under Windows, and 127 under Unix.

The second problem is Windows-Perl specific. If it fails to start the command successfully, it tries to invoke it using the shell, even if the multi-argument version of system() is used. This means that under Windows we can never tell the difference between a failed command and a completed command returning -1.

I suspect that Perl invoking the shell when using a multi-arg system call is a bug. If not, then it needs to be explicitly documented. Time for me to fire up perlbug again.

In the meantime, I can get around most of these things problems in IPC::System::Simple by falling back on the Win32::Process module. This is almost certainly the correct solution regardless of what happens with Windows system(), since it allows us to access the full 16-bit return value, something that system() will never do. Unfortunately it means that I need to do a lot of the work by hand that would normally be handled in Perl's win32.c, and I'm not really looking forward to that.

For further reading, see $? set to strange values under Win32.

Killing linux with write-protect tabs
One of our servers is backed up to a 35/70 DLT drive. The other week it started giving us problems, and the drive stopped responding. I obtained a new drive (second-hand ones are cheap), replaced the old one, and everything worked fine... for about a week.

Then the second drive stopped responding. Same symptoms as the first, not showing up on the controller, and all the lights down the left hand side remaining lit after power-up. I'll spare you the details, but after a bit of investigative work I had reason to believe that perhaps our SCSI controller was having difficulty, and not the drive itself.

So, I shell out for a new controller, a sparkly new AHA-29160. These usually sell for $100+ retail, but using the wonders of eBay I picked one up for $20 including express delivery.

Drop in the card, attach the drive, power-up... The DLT drive still shows its lights all down the left-hand side. Damn. Then I notice the SCSI card isn't being recognised during boot. Re-seat the card (it's big!), power cycle. Everything comes up fine.

Boot into single user mode. Linux detects the new card and drive. Drop in an old tape in write-protect mode. Yup, reads it fine. Old data is still there. Happy happy day!

Wanting to perform a backup immediately, and the tape in the drive being the next one due for being overwritten, I wonder if I can flip the write-protect tab while the tape is in the drive... I can!

Sure enough, the light on the DLT panel extinguishes to indicate the tape is available for writing. Sweet. Time to rewind the tape and back-up.

# mt rewind
 
(scsi0:A:6:0): parity error detected in Data-in phase. SEQADDR(0x1a5) SCSIRATE(0x98)
(scsi0:A:6:0): parity error detected in Data-in phase. SEQADDR(0x1a6) SCSIRATE(0x98)
(scsi0:A:6:0): parity error detected in Data-in phase. SEQADDR(0x1a6) SCSIRATE(0x98)
(scsi0:A:6:0): parity error detected in Data-in phase. SEQADDR(0x1a6) SCSIRATE(0x98)

Oh bugger.

I guess I really do need to eject the tape before changing its write-protect status.

Perl tips: 400 subscribers
Our Perl tips newsletter hit 400 subscriptions today. Yay!

You can subscribe as well if you feel so inclined.

Cardiologist consult
Visited the cardiologist today, and was very happy with the service I received. The cardiologist was very patient, very thorough, and very willing to discuss everything. To my delight she was also willing to discuss matters in a more technical fashion at my request. I love learning about how bits of the body work, and the heart is a fascinating organ.

The end result is that yes, I have episodic SVT, and it is everything I could possibly hope for. It does not increase my risk of stroke. It does not exclude me from diving. It is not life threatening. It is not damaging to my heart or any other systems. It can be controlled without medication or surgery. In short, it's an annoyance, and not much more than that.

Woot!

And yes, I can still have caffeine. I should probably consume less than I used to if I want to remain asymptomatic, but I can still have coffee. Even if I do consume too much, then it will be merely annoying.

Double woot!

I've arranged for an ultrasound in a couple of weeks time, just to take a look at my heart to ensure it's structually sound. The cardiologist warned me that about one in three people have a patent foramen ovale (PFO), which is basically a hole between the atria that can re-open during pressure changes in the cardiovascular system. PFOs are associated with greater risks of decompression illness, and so it's recommended that people with PFOs should not dive.

Here's the crazy part. If someone is known to have a PFO, they can't normally be certified as medically fit to dive. If we don't know if someone has a PFO, then they can be certified as medically fit to dive, even though one in three of them won't actually be fit. Some individuals may actively avoid tests that may reveal whether or not they have a PFO, because if they discover they have the condition they won't be allowed to dive anymore.

This is madness, and I'm in agreement with some members of the medical community that a dive medical should include tests to indicate whether or not the patient has a PFO. Of course doing so would crush the diving industry, since they'd lose about one third of their customers.

Needless to say, I'm very happy to be screened for a PFO, and the only reason I haven't been already is due to laziness. If I have the condition, then I'm glad to be giving up diving in exchange for a longer life expectancy, or talking to a doctor of barometric medicine about how to best manage the condition.

Melbourne Perl Mongers AGM

Last night was the Melbourne Perl Mongers AGM. The most interesting piece of news is that Melbourne Perl Mongers Inc (the registered legal body) is likely to be merged into the Open Source Developers Conference Inc, thanks to an ingenious suggestion by Skud. This is somewhat ironic, since MPM Inc was originally created to run the OSDC conference.

The proposed merge has made me very happy. The existence of MPM Inc has made me uneasy for a while; I've felt that the separate committee has made it more difficult for regular members to be involved in meeting organisation, and the additional legal paperwork required is both difficult to understand and complete in a volunteer organisation of our size.

It should be noted that Melbourne Perl Mongers is not going away. Instead there'll be significantly less paperwork and tedious procedure required from those who help organise it, and hopefully a greater inclusion for anyone who wishes to assist in meeting organisation. Overall I view this as a Very Good Thing.