use.perl journals

my new favorite irssi plugin

nobody@example.com (rjbs) — 2008-08-27T21:31:00

I don't like to use the /ignore command. First of all, I very rarely choose to frequent an IRC channel with anyone I really can't stomach. Also, as you ignore more people, conversation begins to become incomprehensible, because threads of conversation start and you can't tell why or who all is involved.

This came up today, and Matt Trout pointed me at /shitlist, which lets you still see messages from people you've listed -- it's just that the content is replaced with boilerplate.

Awesome.

Where have you been?

nobody@example.com (hide) — 2008-08-27T20:41:00

I had planned on writing a long entry as to where I've been, and what I've been up to for the last two years, however a cross between Fusion and Ubuntu killed that. So here is the abridged version.

The project I'd been working on for 3 years, finally received executive approval and funding, but the timeline was extremely tight. A management change brought a lot of finger pointing, and changes to how the department functions. Even though the department was successful for the 9 years prior.

So I left. Took a new job almost a year ago doing SQL development in a data warehousing, business intelligence, environment. Quite a bit different than the transaction based database work I had been doing.

What about Perl? Well I haven't done any real Perl work in about a year now. Although I have recently started a new project (more on that to come).

For some reason, I haven't been receiving emails for my PAUSE account. I was still getting lots of spam, so I didn't think there was anything wrong. Because I wasn't getting any emails, I figured no one was using the modules I wrote. Luckily David Bartle went out of his way to track me down over some issues with CPAN::Mini::Inject (and he supplied patches with tests!). I've now changed the email address that PAUSE uses, and am receiving mail again. brian d foy has since contacted me with an issue he's seen with Test::Output so I know it's really working.

To help things along, I've moved the repositories for these projects off of my subversion server (that no one seems to know about) onto github.

The repositories can be found at:

CPAN::Mini::Inject - http://github.com/ssoriche/cpan--mini--inject/tree

Test::Output - http://github.com/ssoriche/test-output/tree

Ubiquity

nobody@example.com (perigrin) — 2008-08-27T16:00:00

So Ubiquity was released today. This is the mozilla developers take on QuickSilver a popup sort of GUI version of the command line. I have to say Ubquity is slick as hell. I installed it this morning and in between work tasks I wrote out two quick and simple search scripts, and then set them up to distribute online. Note you can subscribe to my commands as a feed, and as I update them … you get the updates too.

The commands are written in Java script as chrome applications so they have full access to the harddrive … this is good and bad and the developers claim that in version 0.02 they’ll have a Web of Trust for the code setup.

All in all color me very impressed on a first date.

Smile, you're on candid Panopticon

nobody@example.com (nicholas) — 2008-08-27T14:12:00

As Chris and I were walking back to the office at lunchtime, running the gauntlet of the crossroads at the bottom of Castle Hill, I spotted a car with a suspicious black phallic contraption on its roof, coming down the hill and turning right into Northampton Street. So it's quite possible that in the near future there will be a picture of me on Google Street View, pointing at the camera. I didn't have a camera, so no picture of it.

YAPC::Europe, Day 3

nobody@example.com (jonasbn) — 2008-08-27T03:18:00

This is one of those journal entries, which should have been published a long time ago. Well the day after the last day of YAPC::Europe 2008 it should have been published, but the last day took a turn for the worse, which made me hesitate writing anything about the YAPC and the YAPC::Europe 2008 in particular until I had time to find out what to write.

I have been thinking this journal entry over and over again and I finally decided to sit down and just get it out of my system, the writing process would probably be good for me and for structuring my thoughts.

Day 3 went okay, I for one started feeling weary from the many days of conference. My dreams had begun to be extremely vivid, not your usual YAPC organizer nightmares, but just colorful crazy dreams, I expect to be a product to the exposure of so many people and inputs over such short time span. Anyway sleep was not sufficient and the organizing work is draining.

My wife call just after lunch, that they had called from the nursery that our youngest kid had a fever. We agreed she should pick him up, but I should come home as early as possible. I talked to tagg one of the other organizers and we agreed that I would leave in the afternoon, when things were slowing down.

The rest of the day went with practical duties and talking to attendees and speakers.

When I got home and the kids were activated and things was running smoothly I logged on to IRC so hear how things where going at the conference. The auction was still on and it just kept going... I was more focused on my fellow organizers being in charge of the clean up, so I phoned tagg and defekt and I was informed that it looked okay, there had cleaned up in the unused rooms and things did not look as if I was needed they were enough hands to close the venue down as soon as things died out.

The following days I was intensely scanning my RSS feeds for anything on YAPC::Europe, I skipped attending brian d foy's tutorial for which I was signed up, Sylvester was still having a fever and I was pretty tired too. I found this blog entry at first I thought, "What the guy never attended a YAPC before?", but it still bothered me, I heard that the auction had taken way too long and now this so I read some more blogs and talked to a few people attempting to get a picture of what had happened at the auction.

Attending Josh McAdams' 'Test Driven Development' tutorial I talked to some of the conference attendees and I got to see some pictures of the incident. A thread on Act users was also discussing the problem with the auction.

I have attended several YAPCs and I am of that opinion that the problems with auction has just been growing over the years. I am just incredibly saddened that it peaked at my YAPC. I will come back to the difficulties of being an YAPC organizer in a later journal entry.

I hope the 2008 auction does not scare people away from attending future YAPCs. It seems the Perl community itself is addressing the problems and nobody blames the organizers, as written earlier I will get back to this in a later journal entry.

I finally got to put face on some people from the Perl community I have not met before. There were also people attending whom I would have loved to talk to, but never got the time.

I also got to meet a lot of old friends and there where friend not attending that I hope I will see next year or perhaps at some other Perl community event, a lot of these seem to be popping up all over the landscape.

In general I had a marvelous conference, we made a lot of mistakes and there were many things we could/should have done differently or at least done and I have a large responsibility in this.

I personally enjoyed the conference in the extent possible (practically not seeing any talks) and it seemed like most people had a good time. I attempted to talk to as many people I could using people I already know as hooks in the crowd.

YAPC::Europe 2008 - Some Observations

nobody@example.com (barbie) — 2008-08-27T03:05:00

So a couple of weeks ago, I was over in Copenhagen for YAPC::Europe. Putting on a YAPC::Europe event, or any YAPC event for that matter, takes up a lot of thought and preparation time before the event. The organisers want to put on the best conference they can and the previous organisers and the supporting team from the YEF Venue Committee try and help with documents, advice and the like every year, but we are all still learning. So it's understandable that sometimes we don't get everything right, or we miss something. Having said that, each year the organisers do try something new or build on previous ideas with the aim of making the whole event a better experience for everyone. This year the Copenhagen guys tried some new things, some worked some didn't, and built on ideas from previous conferences, again some worked some didn't. In between all that there were also a few areas that lapsed. Overall it was a good conference, but it also highlighted some areas we can improve on for the future. In the survey feedback, several have picked on the successes and pitfalls, and most so far have offered some very good feedback and offered suggestions and ideas where they can, which is great, and is part of the purpose of the survey.

However, I would say it's worth bearing in mind that this is a completely volunteer effort (i.e. we don't get paid), none of us are professional conference organisers and we largely do it because we're passionate about Perl and love to bring the European community together to share ideas and meet each other in person. If things go wrong, think about the positive ways to suggest improvements. We're all human, and don't necessarily remember some of the obvious things. I'm sure if the Copenhagen guys were to do it all again, there would be several alterations they would have made to their planning.

This year's event was slightly more subdued than normal, partly I think due to the growing contingent for whom this is the first or second YAPC::Europe. In some respects that is good, as it means we are encouraging new people to the event each year, however, it also potentially means we are losing those who only make it to their local YAPC::Europe. The latter happens at all the YAPC::Europe events, and I can understand several reasons why people don't return for a second or more year. However, some of the reasons are perhaps that the event wasn't quite what they were expecting. I'd like to help that and perhaps make it something more of what people are expecting. What follows are some observations that I took away from Copenhagen and are meant to be food for thought, partly for future YAPC::Europe conferences, but also for any conference. Some are small niggles, while others will need to be addressed more suitably.

Communication before the event wasn't the best and caused a number of people, particularly regulars, to not attend as it was far too late to arrange anything once they had confirmation of costs and the like. This was unfortunate and has emphasised how important a PR type person is needed in the organising team. The Copenhagen team were focused on getting many other aspects of the conference organisation tasks done, that promotion of the event fell behind. Plans are afoot to make the communication much easier in the future, to the point that Twitter accounts and the like have been created to keep the information flow going. But I would say that if anyone has questions for the organisers, please email them. If they've forgotten something, more often than not they'll be glad of the reminder.

The one thing that I'm really glad Copenhagen did, was to provide lunchtime bags of food. It worked very well in the main, and saved attendees the hassle of going out to the nearby shops to find food. However, it wasn't perfect, as unfortunately the bags for the vegetarian options were mixed with the regular bags, and meant a lot of searching through the bags was required. But it was something that could have been easily resolved, had the organisers been made aware of it. In a similar situation, a large number of us are tea drinkers and abhor coffee. Now while I'm sure some were delighted to see Earl Grey and some fruit infusions, many were a bit disappointed to not find any regular tea (it turns out they call it "Classic Tea" in Denmark). As such I made a request for more such tea bags were made available, and they were for the rest of the conference breaks. My suggestion is to try and resolve similar situations at the time, rather than wait until a survey comes out to criticise the organisers.

The venue itself was brand new, and as such made it a little difficult to find. One comment from the survey suggested doing as Birmingham had done (which in turn, we built on from the Braga guys), with pictorial references of how to get from the airport to hotels and the venue. It meant the attendees could find their way with little problem of taking the wrong route. Despite some confusion, everyone pretty much did find the right building eventually, but it would have been better to have provided some clearer signage from the Metro station to the venue itself. As a note to future organisers of any conference, pretend you've just landed in the country, have no guide book and cannot speak the language. This applies equally to English speaking countries too. Could you get to your hotel or the venue with the instructions you've provided?

As with Birmingham and Vienna, Copenhagen utilised the "plasma screen" code, that Birmingham had in turn pinched from the LUGRadio guys. Projected on the main wall outside the main auditorium, the hourly schedule, together with a regular drop of Flickr photos, were highlighted for all to see. Even if you didn't have the schedule to hand, you could easily see what was coming up. I hope future organisers take this further, as it was a useful aid to remember what the time was, and what was coming up next. Plus it was nice to see the photos that people had posted without having to check on Flickr yourself. As the organisers chose not have any printed proceedings, some have mentioned that having something to hand that expanded beyond the title of a talk, such as a talk abstract, would have given them a much better idea of what to see. In future it might be interesting to see whether ACT can provide a simple PDF of all the talks and abstracts, which attendees can print out for themselves. Although, it does depend whether the author actually does include a decent abstract of course.

Although the main auditorium and first two rooms were more than adequate for their size, the 4th room, which proved rather popular for several talks, was more of a classroom size. Thankfully none of the talks I saw there were over subscribed, thanks partly due to the spread of attendees across 4 rather than 3 rooms, but it did highlight that getting the popular talks out of smaller rooms is important. In Birmingham we suffered with this, despite trying to rearrange some of the talks at short notice. This year, just before the conference, Éric Cholet managed to add a feature to ACT that enabled attendees to select the talks they planned to see. While a fun feature, it's usefulness for future organisers is likely to be a life-saver. Having the ability to see which talks are likely to generate the most interest, will mean they have more options before the event to juggle the schedule to get all the talks into the right rooms.

Regards the talks themselves, there was a good selection of talks, covering all sorts of interests and levels of ability. However, it isn't always obvious from the title or abstract what level of knowledge is required for the talk, and whether it is an introduction, in-depth or discussion type talk. As a consequence it makes it a little difficult when there are several talks to choose from, which one is most likely to be most appropriate for you. Hopefully speakers can be prompted better in future to describe their talks a little better, so beginners don't attend expert talks and visa versa.

The 30 minute length for talks also didn't work for me. I was fortunate, as my Understanding Malware talk was able to span two sessions, but I was the only one to do so, and the talk needed that time slot to cover the subject matter. There were several other talks that I felt would have benefited from more time and equally several talks that really only merited 20 minutes, as the extra 10 minutes felt like padding. We had a cross-section of experienced speakers and new speakers this year, and while some of the newer speakers handled their presentations well, some didn't. At more corporate conferences, I've seen Mark Jason Dominus and Damian Conway give excellent presentations on how to give presentations. There are some techniques suggested by both that I now use in my own presentations. Now while those presentations are on the web somewhere, it would be wonderful to get those guys to do a special session, particularly for new speakers, so they can help all speakers improve both their presentation materials and the way they present the subject matter. Some of the new guys just need that little bit of guidance, as their subject matter is interesting.

The four tracks idea can work, but it can also spread talks too thin. This year, I didn't feel there was a lot of benefit to having four tracks, apart from making sure everyone who submitted a talk got accepted. Although I would encourage new speakers to propose talks, I do think the acceptance of talks from new speakers needs a bit of a review. Is the speaker qualified to speak on the subject? Have other similar talks already been submitted by more experienced speakers? We should also get a stronger weighting of experienced speakers rather than new speakers, as in the main most want to be taught something. General interest talks or discussion talks are worth having, but they're usually better handled by experienced speakers. As mentioned above, some of the new speakers did have interesting subject matter to present, so there are definitely some that would still get through the selection criteria, but I feel it's more important to have a strong line-up of talks, than necessarily having a slot for everyone who submitted a talk.

Regarding this last aspect, one post on use.perl, has annoyed me perhaps rather more than it should have. I have no idea who was supposedly promoting themselves rather a lot, as it wasn't obvious to me (or maybe it was me!). But what offended me is the inference that once you've presented a talk, that you should never speak again! Perhaps that wasn't the intention of the original poster, but it does bother me that people assume that they can see all 70+ talks throughout the whole 3 days. In previous years the survey has been useful to see who attendees would like to have seen, both in terms of talks they missed, or speakers that were unable to attend the event. Usually it highlights a few talks that would be worth repeating, following several requests to see them. Surely knowing you've seen a few talks before, gives you more opportunity to see the other talks! A good portion of the attendees have never seen those talks, and as far as they are concerned everyone is fresh blood. Anyway why shouldn't experienced speakers have the chance to give others the benefit of their knowledge? If they're good presenters, get them back as much as possible, both to present new and interesting ideas, but to also help new presenters of the future see how well it can be done. I also wonder whether the OP has ever submitted a talk? If you want fresh blood, put yourself on the spot, and don't expect others to give you a comfortable life.

There are some talks I've given, which having gone down well I've considered repeating every so often, but hearing such comments from people that they've seen it all before puts me off. However, probably over half of the attendance have never seen some of the talks I've previously presented. Do we really have to have completely fresh talks every year? Personally I don't think so and I think there is some value in repeating talks, especially if they cover a worthwhile subject for new attendees. I was actually pleased to have Chris Williams speaking about CPAN Testers, as it gives others a chance to carry on the promotion, and not just me. Had he not have done so, I would have done it, as I think reminding people about CPAN Testers and encouraging people to get involved is important. There are other projects that are equally deserving of promotion and involvement, and talks at YAPCs are an ideal opportunity to repeatedly promote them.

Something that is becoming more and more obvious regarding the scheduling these days, is that we are trying to cram far too much into the day. The early starts were a trial for many, as they were fighting late nights (including hangovers for some), jet-lag and the general intensive mental focus of the day. Remember that most of us don't get away from our computers that much during the general work-day, so focused training, discussion and socialising can be extremely exhausting. While it may well mean that you have to accept less talks, I would rather see more time given to discussion periods. One such casulty were The Birds of a Feather sessions this year as due to over-running it left little time after the main event to hold them. On Wednesday the CPAN Testers BOF went ahead, and was reasonably well attended, but after an hour of discussion, at 7pm it made for a very long conference day. It also meant we were far too late for the Vertical Metre Of Beer Party that Adam Kennedy and Jos Boumans were hosting. On Thursday, again due to over-running, there was no time left for any BOFs, as we were supposed to be at the Conference Dinner venue by 6.30pm. I was disappointed that the Perl Mongers BOF didn't happen, as from previous versions of this BOF, it has been a good sounding board to get new groups started, and energize groups into thinking about organising a YAPC::Europe themselves. This year we didn't get that chance.

Speaking of the socialising aspect, the pub that was chosen for the pre-conference meeting point, and subsequent free evenings, wasn't really suitable for the large number of people that came along. Understandably finding one pub or bar that can accommodate everyone is going to be difficult, but if there is anywhere that has a selection, so that attendees can hop from one to the other is often much better. This worked well in Braga, as in the town centre, even if people disappeared off for food, they all came back later and there was plenty of room outside for us to chat and drink. Of course it helps that Portugal mostly has decent weather! The pub suggested by the Copenhagen guys, The Globe, was an Irish pub, and wasn't too bad. Certainly several of the UK contingent liked the food and beer served up. But it didn't allow for everyone to easily mingle and chat. As a consequence, after meeting there for a first pint, people organised eating parties and headed off to other restaurants. It meant there wasn't really a place where people could meet up together, drink, chat and socialise into the evening and night. There were several people I never quite felt I got the chance to really chat to over the week, and would have loved to have spent more time just relaxing in good company.

Although it might sound like I didn't have a great time in Copenhagen, I did. These are just observations that I thought were worth sharing, rather than just in the feedback form of the survey. There was a lot of things that I really liked about the conference, but there were several things that I do hope future organisers, whether a YAPC or any other conference, might bare in mind. I am now planning to completely overhaul the conference documents that have been on Google Docs, as although a lot of the content is still relevant, there is more to add, and I want to better present it for organisers. At the moment it's a long read and I'm not convinced it gets digested as it currently is.

I would like to thank all the Copenhagen crew for their efforts. While there were some problems and lessons to be learnt, the event itself largely did go well. The crew were very friendly and helpful, there were some great talks, it was a good venue and I'm glad I finally got to visit the city of Copenhagen. I had a great time, and would love to go back to Copenhagen for a longer sight seeing visit.

My biggest disappointment of the event though, is completely and utterly my own fault. As with Vienna I had plans to make a note of people attending who I would like to meet in person and find them and say hello. Once again this year I failed miserably. So next time around, in case I forget, can Aristotle, Diego, George and Steffen come and say hello :) On the plus side there were a few people I bumped into, that I was rather glad to have a chat to, including Marcel and Charles. It's one aspect of a YAPC that I like, being able to put a person to a name.

Next year I'm sure that they'll be other things that I'll be thinking didn't go as planned, but I'm pretty sure I'll still have a great time regardless, as I did this year. I guess I just worry too much :)

Wikiperl

nobody@example.com (Whiteknight) — 2008-08-26T20:19:00

With GSOC over, and the fact that I haven't posted a blog here in a while, I'm sure some people have assumed that I'm just going to disappear. After all, my project is over, right?

Hellz to the no, if you'll pardon my slang.

I spent the better part of the week working on Parrot still, I created a new clean branch to continue the GC work I started over the summer. I've also been doing some work on the pdd27mmd branch and I've been doing some documentation work to Parrot trunk.

Tonight though, I've taken a short break to work on a project that I started long before I even heard of Parrot. I call it a "Transform editor" for Mediawiki.

http://sourceforge.net/projects/wikiperl/

The program, called "Wikiperl" and available at source forge, allows an adept perl programmer to apply snippets of perl code directly to a page on a MediaWiki website. The editor loads the text of the page into the $_ variable. It loads your code and executes it. Then, it takes whatever is left in $_ and loads that back to the page. It's very similar in mechanic to Filter::Simple, for people who are familiar with that.

However, there are a number of other features that are very cool too:

1) You can loop the same code over a list of pages. You can enter this list manually, or you can load it in various ways from MediaWiki. For instance, you can load a Table of Contents from a book, or you can load a list of pages from a category, and a few other options.
2) You can store multiple transforms into an ordered queue, and execute the entire queue on a page. This helps you to keep complicated tasks split up into smaller portions.
3) You can set some arbitrary perl code to execute at the very beginning of a complex job, to load libraries, instantiate global variables, etc.

When I originally created this program, I designed the GUI with Perl\Tk. However, I learned when I switched from Windows to Ubuntu that Perl\Tk looks pretty lousy on Gnome. So, I've been starting the slow and arduous task of converting the program to use Gtk2. The program now looks much better, I've learned a cool new graphical API, and I've managed to apply some of this MVC methodology stuff I've been hearing so much about recently.

Wikiperl relies on the MediaWiki module from CPAN, which contains a few flaws and bugs that currently manifest themselves in the operation of the program. I'm preparing a new release with the updated Gtk2 interface (once I get the remaining few bugs worked out, and a lot more documentation written).

One of my other projects is a Perl-based expert system shell, which I'll probably talk about in a future post (if I ever get around to working on it again). And of course, there's always Parrot.

b9jTest: Simplifying and enhancing YUI Test

nobody@example.com (grink) — 2008-08-26T19:22:00

YUI Test is a great tool for javascript testing, but it has a couple of small issues:

Setting up the HTML document requires many different .js and .css assets
The actual javascript code to set up the test environment is not trivial (setting up the TestRunner, setting up the TestLogger, etc.)
A failed assertion will abort the test function immediately, preventing later tests from running

b9jTest addresses the problems above by:

Bundling all the required .js and .css assets into just two separate files
Providing some boilerplate javascript so you can jump right into testing without a lot of setup

An example b9jTest document:<html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <title>b9jTest example</title> <link rel="stylesheet" type="text/css" href="http://appengine.bravo9.com/b9j/b9jTest.css"> <script type="text/javascript" src="http://appengine.bravo9.com/b9j/b9jTest.js"></script> </head> <body class="yui-skin-sam"> <div id="testLogger"></div> <script type="text/javascript"> b9jTest(function(test) { test.areEqual("xyzzy", "xyzzy"); test.areEqual("apple", "apple"); test.areEqual("banana", "banana"); }); </script> </body>

b9jTest() is a global function that accepts a function that is called with a testing object. The testing object provides access to the standard YUI assertions and more.

Documentation:

http://appengine.bravo9.com/b9j/documentation/b9jTest.html

Download:

b9jTest.js
b9jTest.css

b9jTest: Simplifying and enhancing YUI Test

Fixing RedHat Perl

nobody@example.com (nicholas) — 2008-08-26T15:26:00

Given that the fixes have been around since last November and RedHat are still unsure whether it's confusion between their left or right arse and their elbow that is getting in the way of fixing the problem, it strikes me that the most expedient solution to hastening the delivery of functional RPMs to their long suffering users would be to build some for them from released source, break into their master servers and simply sign some working RPMs. Job done.

Sliiiiiiiiiiight flaw in this otherwise cunning plan is that it's highly illegal. Probably in more than one jurisdiction at the same time. So I won't be doing it, and I'd recommend you don't do it either. Meanwhile RedHat are confident that no-one compromised the Fedora packages (unlike the admitted compromise of the RHEL 4 and 5 keys), and FC9 ships a pretty clean Perl 5.10.0 build, so you might want to swap to that. Or Ubuntu, whom as best I can remember haven't (yet) been broken into.

confessions of a headhunter at YAPC

nobody@example.com (sir_lichtkind) — 2008-08-26T12:17:00

jeah i was there listen to talks. even gave one, promoted Kephra but most importantly: i hunted a dozen heads down to organize or extract informations i needed. beside alias, renee, stefan, larry, damian, gabor, josh and so on. The topics where YAML::Tiny, Strawberry Perl, Kephra, Summer of Code, our upcoming WxPerl Workshop, an Interview about Kephra, Perl 6 OOP Parameter (Damian), my Talk and lots of other stuff. so I was busy while still had time to explore Kobenhavn and prepare my talk JIT.

On the back tour i was also visiting jens "jenne" neuwerk which drawn a new icons and revisited some other. there are also some issues with Kephra and i want to emulate the eval thing from padre so expect new version soon.

YAPC::Europe 2008 Surveys - Course Assessment Forms

nobody@example.com (barbie) — 2008-08-26T09:14:00

Following on from the release of the YAPC::Europe 2008 Survey, I'm pleased to have just launched a companion set of surveys for the Master Class tutorials. Although the Course Assessment Form is perhaps not as verbose as the main survey, I've collated several ideas from other assessment forms to get a brief idea of what attendees thought of the course, to allow them to make suggestions for improvement, and to highlight what they thought was good about the course.

With currently over 60% of responses in from those polled on the main survey, I'm hoping that a good proportion, if not all, will respond to the feedback for the individual courses. The results will be collated and sent to the presenters once all their attendees have responded, or just after October 30th (the closing date). This is essentially a trial, as suggested by Dave Cross, to enable the tutorial presenters to get some form of feedback on the courses they presented before and after YAPC::Europe in Copenhagen.

It has also been suggested that each regular talk should have a similar feedback mechanism. However, whereas the tutorials required a signup, so we have their exact attendees, the regular talk sessions are a little more ad-hoc. It could be opened up as a free-for-all to enter what they like about a particular talk, but there is no guarantee that the respondent saw the talk. Having said that, several of the respondents have chosen not to rate the talks in the main survey, so it's likely to improve feedback for the presenter at the very least.

My intention was to roll this into ACT, but for the YAPC::Europe surveys at least, I'm not so sure that it needs to be. Having the survey independent of the ACT system (although I do use the attendee lists from ACT), and the fact that one person (me) is currently controlling access to that data to ensure anonymity, may actually be providing a degree of confidence in the privacy of comments, etc. I'll have to see what the Lisbon guys want to do, but I'll be happy to provide the same setup (if not more extensive) for the surveys next year.

Note to self: Communicating with kids

nobody@example.com (jonasbn) — 2008-08-26T06:55:00

I reflected over a conversation I have ever so often with my oldest kid, since it resembled something I picked up when reading about GUI dialog design.

The conversation normally takes place at the dinner table.

Me: Do you want more dinner?

Villads: No

Me: Are you sure?

Villads: silence

Villads silence has many reasons, it can be that he has started to play LEGOs or watch TV.

If I continue inquiring he will most likely respond: No

Which is of course not what he means, but it is the easy response.

So I need to practice dialogue with him to I can give him a proper chance to respond correctly to my questions.

Same pattern is important for graphical GUIs where I sometimes find myself confused about a certain dialogue, where positive and negative answers are required to complete a certain action. You often click the wrong button because of this.

So I do not blame Villads for giving misleading answers - I blame myself for confusing him.

Blogs. The correct place to report bugs.

nobody@example.com (nicholas) — 2008-08-26T04:36:00

"Your random blog" has never been the right place to report a bug*. So to keep with the spirit, here's a fix to a bug, reported on my random blog.

It seems that there is still a problem with RedHat's packaged perl 5.8."8"**. RedHat seem to have an aggressive policy of incorporating pre-release changes in their released production code. This would not be so bad if they actually communicated back with upstream (i.e. me and the other people on the perl5-porters mailing list), or demonstrated that they had sufficient in-house knowledge that they didn't need to. But evidence suggests that neither is true, certainly for 5.8.x†

Let me stress that there has never been this problem in any released Perl, 5.8.7, 5.8.8, 5.10.0, and it won't be in 5.8.9 either when it comes out. The problem was caused by changes I made in the 5.8.x tree that RedHat integrated. End users reported the first bug something like 2 years ago, and RedHat closed it as "upstream patch" rather than reporting back "you know that pre-release change you made, that we integrated - well, it seems to have some problems". So I fixed the cases I was aware of.

I'm human, and it turns out that that it wasn't all the cases. Once I was made aware of this (by a RedHat user, note, never the RedHat maintainer) I fixed the problems he reported, and went on a 2 day trawl of CPAN‡ to locate every other idiom that was going to be a problem.

For their versions affected, RedHat merely need to put out a patch integrating changes 31996, 32018, 32019 and 32025 which FIX IT, are documented as FIXING IT, and are from NOVEMBER 2007.

Works on my machine. And anyone else's machine who is running my code. Particularly my released code.

Although, the better fix is not to use the vendor's Perl release for your production systems. Render unto Caesar the things which are Caesar's and for yourselves, compile your own, and your own module tree, from source you keep and control in your own version control system, which changes only when you change it. In particular, if you're not using ithreads anywhere you should compile without ithreads support, which most vendors choose to enable. (It's not the default, and it costs about a 10% slowdown). Anyone doing this would never even have known that there was a problem with some vendor's interpretation of perl.

Update

No, it's still broken in RHEL5. root had changed everyone's $PATH ("it is my machine, after all"), and in my haste I'd not realised that I actually just typed perl, not /usr/bin/perl. So to be fair they are still asleep on the job. Where's I'm awake and doing this stuff for free.

* Nor is your bug tracker. Upstream's own bug tracker is the O(1) place where upstream reads about bugs in upstream's own software. Not O(n) other people's bug trackers. The latter does not scale.

** At least in some of their distributions. The only RedHat box I have access to, and that's an account created 3 minutes ago, is "Red Hat Enterprise Linux Server release 5" and their supplied /usr/bin/perl doesn't have the bug.

† It has been a different matter for 5.10.0 in Fedora. For that, the maintainer has been very communicative, and so we were able to help him fix problems and get Perl 5.10.0 into Fedora Core 9.

‡ This was when I had a lot more free time than now, mainly because I was having a break between jobs.

moving on from collation

nobody@example.com (aurum) — 2008-08-25T19:32:00

It seems that I would much rather talk about software design issues than write this research proposal. Well, I may as well get something useful done.

So far, I have described the design of what I have been calling the "MCE", or the "manuscript collation engine". It works pretty well at this point, and when I run it on a bunch of transcribed text files, I get a bunch of arrays back, full of Word objects that are lined up neatly according to similarity and relative placement. Now I just have to use them. This is where I start speculating about what to do next.

I said at some point that I would talk about the structure of a Word object, but really there is little enough to tell. A Word is an object that will keep track of whatever I tell it to remember about a particular word—its matches, its variants, its original or normalized or canonicalized spelling, its punctuation, whether it should be considered the "base" word or a "variant" word or an "error".

Of course, many of the attributes I might want "remembered" can't actually be detected at collation time. Some of them are editing decisions, and others need the judgment of a human (or a set of rules) that understands things about the Armenian language. It's high time I wrote the editing interface.

(Nomenclature will be the death of this project, incidentally. It's bad enough that the computer world and the critical-text-edition world use the word "collation" differently. Now I want to write a program that, in the terminology of the humanities, ought to be called a "text editor." Great.)

So. I start with a bunch of arrays of words, and the superficial relationships between them. The end result should be a base text, and an apparatus that records the set of variants that I have judged to be worth recording. In the meantime, I should have had to do as little work as possible. This means several things:

I need to remember which word goes with which manuscript.
I need a way of marking a word as "base", that is, the accepted main reading.
I need a hierarchical series of categories of "variant", including but not limited to:
- Grammatically sensical differences
- Apparent grammatical errors
- Orthography variations
I need to be able to "smooth" strings of variant words into a single variant.
I need a means of "teaching" the program about my decisions, so that I am never asked more than once about an orthographic variation.
I need a way of saving the decisions I've made.

But those are just the easy things. Two aspects of the problem are particularly tricky. The first is punctuation. The punctuation in Armenian manuscripts is all over the place. Do I mostly disregard it? Do I treat punctuation marks as words in their own right? Do I show it all on a case-by-case basis, and thereby give myself more work?

The second is the issue of partial-word readings. Remember that a "reading" is a "minimally distinctive unit of sense"; that means that a single word may contain multiple readings. Prefixes can have grammatical effects. For example:

աշխարհ (ashkharh): "land", but
աշխարհն (ashkharhn): "the land", and
յաշխարհն (yashkharhn): "into the land".

The last is especially tricky, as it can either be written as the single word յաշխարհն, or as two separate words ի աշխարհն. If I am standardizing the orthography across manuscripts, I should separate the prefix յ, converting it to the preposition ի; I'll have to split the Word object, and align the resulting pair of Words with the Words in my other arrays. The alignment and word matching is a problem I have already solved with the MCE, but this means that the editing program will have to call back into the MCE to re-align the words in question.

As usual, I've launched into a whole raft of explanation, and not even asked for anyone's opinion on specific questions yet. Maybe tomorrow.

Speaking to Atlanta Perl Mongers Thursday (before D*C)

nobody@example.com (merlyn) — 2008-08-25T17:16:00

Join me for A special night with Randal Schwartz where I'll be talking about "Perl second-best practices", which I describe as:

So, you don't have time to read Damian Conway's "Perl Best Practices" book, to understand his "256 guidelines on the art of coding to help you write better Perl code"? Hear Randal Schwartz provide the executive summary, including pointing out where Randal disagrees with Damian, and why. This high-speed overview will help you understand "code layout, naming conventions, choice of data and control structures, program decomposition, interface design and implementation, modularity, object orientation, error handling, testing, and debugging." But using shorter words.

If everything goes well, I'll be recording this and putting it into my Vimeo feed in HD.

Why did I not know this Firefox trick?

nobody@example.com (btilly) — 2008-08-25T15:01:00

Start typing into a form and it creates an autocomplete popup list of things you've typed there in the past. That's nice. But your past typos show up as well. The solution? Navigate to that entry and press shift-delete. Bye bye entry.

I only discovered this by accident. Polling coworkers, most people don't know about it.

What other really useful functionality does Firefox have that nobody knows about?

Recent rakudo news

nobody@example.com (pmichaud) — 2008-08-25T14:09:00

Given that most of July and August for me was spent attending conferences, travel, vacation, and periods of limited network connectivity, it's been a while since I've been able to update Rakudo progress. So, this is a very brief update, to be followed by a longer post in a day or so.

First, we continue to make progress on passing more spectests. As of this writing Rakudo is passing 2278 spectests. A graph of our progress is available from http://www.pmichaud.com/perl6/rakudo-tests-2008-08-25.png. Much of the credit for passing tests over the past few weeks goes to Jonathan Worthington, Moritz Lenz, and Carl Mäsak (again, apologies if I've overlooked anyone). It's really good to see progress coming from so many sources.

OSCON and YAPC::EU were both excellent conferences, my compliments to the organizers of each of those. In particular, Jonathan, Allison, and I were able to use our time together at YAPC::EU to discuss and map out many of the outstanding issues for Parrot and Rakudo, which we can now begin documenting and implementing over the next few weeks and months. These include things like code initialization, handling Perl 6 parameter passing and signatures, MMD, strings, and many other issues.

One of the outcomes of this was that early last week I finally got the code in place to enable pre-compiled Perl 6 modules to function properly. At the moment this has a quite dramatic effect on running the spectest regression suite, because we aren't having to parse and recompile Test.pm on each test file execution (and parsing is still our biggest bottleneck). So, running the regression suite dropped from twelve minutes to under four minutes on my system, which isn't quite so interminable.

Of course, the next step will be to enable Rakudo to compiler Perl 6 programs into standalone PIR or PBC files that can automatically load the Perl 6 runtime. I expect to accomplish this sometime this week -- at present we need some refactors to the signature generation code that is blocking this from happening.

We're also working on enabling parts of the standard runtime library ("Prelude") to be written in Perl 6 and precompiled by Rakudo, instead of having it all written in PIR. As part of this we may implement a Perl 6-with-inline-PIR capability to help with the builtins, to make it easier to attach MMD signatures to the builtin functions and make sure they're exported properly.

We also have more of the interface for loading external modules (written in PIR or otherwise) specified, and will be working on that over the next couple of weeks.

At the YAPC::EU hackathon, Jesse Vincent and I also spent some time updating the Rakudo ROADMAP document. This newer version of the ROADMAP identifies some of the specific components that are left to be developed, along with estimates of their complexity and dependencies. If you look at the document you'll see some notations about how long it will take to develop each feature; these estimates are all in "idealized programmer units". An "idealized programmer unit" here assumes that the people involved have no interruptions or distractions, has all of the needed prerequisites in place, is mentally charged and ready for programming, doesn't have to wait to coordinate questions or answers with others, etc. As such, the times given should be taken only as relative estimates of task difficulty, and not how long a particular task will take in real-world time units.

The major subsystem redesign coming up for Rakudo will be changes to the parser and grammar engine to support protoregexes and longest token matching. This will enable us to support even more of the STD.pm "standard grammar". I expect much of this work to take place over the next four calendar months, as many elements are likely to require some intensive and sustained design and development effort (while trying to maintain progress in other areas). More on this as it progresses.

Dear lazyweb

nobody@example.com (Matts) — 2008-08-25T12:23:00

How do you get your iPhone 3G wallpaper onto the "Home" or "Applications" screen? There's a screenshot of this on the iphonefaq web site, but my "Wallpaper" just seems to apply to the iPhone "lock" page.

IO

nobody@example.com (acme) — 2008-08-25T12:05:00

I was microoptimising. I admit it. I was trying to get a little bit of code which read a part of a file going quickly, and I got slightly sidetracked. I noticed that PerlIO had layers, so I played around with the layers and benchmarked things. I noticed that :stdio was quite fast for my one test case, so I compiled a new Perl with ./Configure -des -Uuseperlio -Dprefix=/home/acme/perl-5.10.0-stdio/ to ignore PerlIO and use stdio instead, then benchmarked things (didn't really help). I eventually thought about using unbuffered IO, and noticed that it was much faster than all the others. Aha! I suddenly remember about buffered and unbuffered IO. Buffered IO using seek, read, and write is very handy when reading or writing the whole file. If you are actually doing random access in files then you should use sysseek, sysread and syswrite, doh!

As I Ffwd Through The Closing Ceremonies

nobody@example.com (pudge) — 2008-08-25T01:03:00

ONO THE DOUBLE DECKER BUS IS A TRANSFORMER! RUN FOR YOUR LIVES!

IT ATE JIMMY PAGE. SORRY JIMMY.

Cross-posted on <pudge/*>.

Chinese tech

nobody@example.com (grantm) — 2008-08-24T20:16:00

Following news that chinese scientists have completed a face transplant, I commented that next time China hosts the Olympics they'll be able to have a six year old singer with a good voice and a pretty face. A colleague immediately came back with "Well they'll claim she's six".

variations on "variants"

nobody@example.com (aurum) — 2008-08-24T19:11:00

Now that I've explained this much of my design, I am going to have to apologize for confusing my readers, because I'm about to overload a term. (This just goes to show how terrible I am at nomenclature when programming.)

Anyone who has ever looked at a critical edition of any text will see the word variant tossed about casually, alongside the word reading, under the assumption that both of these words are self-explanatory. I have told the manuscript collation engine (MCE) that a "variant" is any word that is not a "match" to its base word. Now I'm going to have to tell the rest of my program something else.

From the point of view of the reader of a critical edition, a "variant" is a chunk of text (be it one word or several) that does not appear in the base text, but appears in the apparatus below the base text. An apparatus is a specially formatted block of footnotes below the main text of an edition. The footnotes encode information about the "variant readings" found in manuscripts. Peter Robinson, who worked on this sort of thing long before I did, defined a "reading" as a "minimally distinctive unit of sense". (ref) A "unit of sense" is usually a word, but could be, say, half of a compound word. On the other hand, when you have several "units of sense" lined up in one sentence in one manuscript, it is most efficent and understandable to present them as a single reading. The "variant" readings, therefore, are the ones that vary from the base text.

So you may begin to see the problem. I've been talking about a variant as if it were always a single word, always defined in reference to the first text in which I saw any word at all in that position, and always significantly different from the first word encountered. This is great for a first pass of difference detection, but if I published that information unmodified my edition would be incomprehensible rubbish.

As an editor, therefore, a variant is defined in relationship to what I've chosen as the "right" word, and it is any difference at all within reason. And then I have to define what my bounds of reason are. Those bounds are often defined arbitrarily by the editor. One editor may choose, due to space constraints, to publish only those variants which he judges "substantial". Another may choose to publish all variants that aren't simply orthographic variations. Another may choose to publish all variants that make some sort of grammatical sense, and omit the ungrammatical ones. Editions of the New Testament usually include everything, because minute differences have a huge impact upon theological study. There are a few online editions appearing; they tend to include everything, because space constraint is not an issue.

What's more, Armenian is an inflected language. The same word can have a different grammatical meaning with a different suffix. The MCE will record the two words as a fuzzy match, but in fact I am going to have to review them and decide whether this "match" represents a sensical variant, a nonsensical (ungrammatical, or misspelled) variant, or simply a variation in orthography.

In fact, the only reason I told the MCE to pay attention to "variants" in the first place is to make my editing job easier in the future. It is useful for me to only have to consider the "similar" words together, and for the computer to reserve the "different" words in the same position for separate consideration. The MCE is only the core of the larger editing program I need, and that editing program must be able to learn from my decisions. That is, if I mark հա՛ոց as an orthographic variation of հայոց in one place, I should not be asked again about that pair of words. This will not only save me a lot of trouble; it will allow me to construct a more consistent, and therefore better, edition.