Tomorrow's regularly scheduled Rakudo release is the first one since the long-running "ng" branch became master. It represents both a huge step forward and at the same time a fairly major regression. Internally, the changes are enormous; some of the biggest include:

• We're parsing using a new implementation of Perl 6 regexes by pmichaud++. It is a huge improvement, supporting amongst other things protoregexes, a basic form of LTM, variable declarations - including contextuals - inside regexes and more. The AST it generates is part of the PAST tree rather than having a distinct AST, which is a neater, more hackable approach. The issues with lexical scopes and regexes are resolved. Closures in regexes work.
• NQP is also re-built atop of this. It incorporates regex and grammar support, so now we run both grammar and actions through the one compiler. It's bootstrapped.
• In light of those major changes, we started putting the grammar back together from scratch. A large part of this was copy and paste - from STD.pm. The grammar we have now is far, far closer to STD than what we had before. Operator precedence parsing is handled in the same kind of way. We've started to incorporate some of the nice STD error detection bits, and catch and nicely report some Perl 5-isms.
• Since the grammar got re-done, we've been taking the same approach with the actions (the methods that take parse tree nodes and make AST nodes). Thanks to contextual variable support and other improvements, a lot of stuff got WAY cleaner.
• The list/array implementation has been done over, and this time it's lazy. There's certainly rough edges, but it's getting better every day. The work to implement laziness has led to many areas of the spec getting fleshed out, too - a consequence of being the first implementation on the scene I guess.
• All class and role construction is done through a meta-model rather than "magic". The Parrot role composition algorithm is no longer relied upon, instead we have our own implementation mostly written in NQP.
• The assignment model was improved to do much less copying, so we should potentially perform a bit better there.
• Lexical handling was refactored somewhat, and the changes should eliminate a common source of those pesky Null PMC Access errors.

Every one of these - and some others I didn't mention - are important for getting us towards the Rakudo * release. The downside is that since we've essentially taken Rakudo apart and put it back together again - albeit on far, far better foundations - we're still some way from getting all of the language constructs, built-in types and functions back in place that we had before. It's often not just a case of copy-paste; many of the list related things now have to be written with laziness in mind, for example.

So anyway, if you download tomorrow's release and your code doesn't compile or run, this post should explain - at least at a higher level - why. After a slower December and January, Rakudo development has now once again picked up an incredible pace, and the last couple of week's efforts by many Rakudo hackers have made this release far better than I had feared it was going to be. If we can keep this up, the March release should be a very exciting one.

A Swedish reader of my blog kindly took a moment to leave a comment on my last post, pointing out just how huge a selection of beers the Systembolaget has (it really is a big one - over 400 varieties). I figured I'd be able to pick from whatever my local store had but apparently, you can make custom orders too! So, what have they?

Amongst the English ones there's 31 beers. Picking those I know and like best, there's Abbot, Adnams, Bishop's Finger, Circle Master, Hobgoblin, Newcastle Brown Ale, Old Empire and Spitfire. That's not a bad selection of English ale at all, to say I'm out of England!

What if I get nostalgic for my time in Slovakia? There's Zlatý Bazant, which is my favorite Slovak beer. Of course, much of what I drink here is actually Czech beer, and there collection includes all those I especially like, including my favorite Starobrno, which I'm drinking as I write this post, as well as Pilsner Urquell and Staropramen.

Of course, there's a huge selection of Swedish beers on offer. I'll have to admit to massive ignorance here, though in a country that seems to very much value quality, I have a feeling that discovering Swedish beer will not be a disappointment. The range seems to include ales, stouts, pale ales, porters as well as lager, so it's pretty promising.

Glancing around at what else is on offer, I notice a couple of Weissbiers from Germany that I've enjoyed a few times in the past, the wonderful La Trappe from The Netherlands and a bunch of nice ones from Belgium (Hoegarden, Duvel, etc). Sadly, from India there is only Cobra, which is a very good beer to go with a curry, but I have a slight preference for Kingfisher. There's a bunch of American ones, which I don't really know, though "Double Bastard Ale" is a name win. Sadly, no Tsing Tao (or anything else) from China, a beer that I find strangely refreshing. Small lackings amongst plenty of awesome though. :-) Also, browsing the Systembolaget site is a good way to learn the names of various countries in Swedish!

There's also a Bishop's Arms pub in Lund. I've no idea if it's related to the Bishop's Arms in Malmo, though I do know that the Malmo pub of that name was a very nice - if pricey - place to have a few pints, not to mention a tasty bite to eat. Anyway, seems I may be not so badly off for beer after all.

Contracty bits are done, and I have a place to move to in Sweden! I'm going to be not all that far to the railway station (much closer than my place in Bratislava is), and thus near to the center. Oh, and the systembolaget (the place where beer is available - a curious quirk of Sweden is that the state has a monopoly on alcohol sales). Seems there's a couple of pubs where I'll be able to obtain ale too, which will in a way kinda make up for the Czech and Slovak beer I'll be missing here. Of course, what I'd pay to buy plenty of beer for an evening out here will buy me just one or maybe two in a bar in Sweden! In fact, things generally will be pricier - though I gather the quality is also generally good.

It also seems there's some good walking to be had in the area, and it's not that far to get out of the city and be in the countryside. So hopefully there'll be some nice opportunities, as the weather gets warmer, to get out and enjoy the natural surroundings. Of course, while living in Sweden, I must pay another visit to the Abisko National Park too. :-)

Anyway, I'm sure I'll be blogging plenty about how Sweden is as a place to be living once I get there, in under a month's time!

Here's some photos from a few recent trips to nearby places. First up, the lovely Trenčin in the north of Slovakia. Second, the smaller but also very pleasant Hainburg, a town not far over the Slovak border with Austria.

Trying to find a place in Malmo has been rather tougher than I expected. Lund, on the other hand, has proved an easier target, and it looks like something might well work out there. Lund is perhaps also a more "me" kinda place. It's smaller than Malmo, and home to Sweden's second oldest university. I've been there before, and it's got a pleasant center to hang around in. Like Malmo, it's got direct trains to all of Goteborg, Copenhagen (including it's airport) and Stockholm, so it's just about as easy to get around. There seems to be a decent bunch of places to eat and drink there too, though rather less in the way of Indian food - I guess I'll have to do the less than 15 minute journey to Malmo to get that (choice of 7+ restaurants there, versus only 1 with some quite bad reviews that I've been able to find out about in Lund...maybe there's another one that I don't know about though). Anyway, that's where I might be ending up. :-)

Today plenty happened in Rakudo land - in fact, it was my most active day's Rakudo hacking in quite a while. colomon++ also made some great commits, and between us a lot of things moved forward today. For my part, hashes and pairs are in much better shape.

I wrote before that I'd got some Rakudo days left to write up; there are two of them, but I'll cover them both in this post, since some of the work crossed the two of them anyway. Here's what I got up to between them.

• Filled out attribute composition logic for role application. A good chunk of this was written in NQP - in fact, all of the role appliers are. :-) Along the way I brought roles up to speed with the attribute part of the meta-object protocol - I'd forgotten that when doing it for classes, though since we couldn't compose attributes at that time it wasn't so interesting anyway. The end result was that we could pass S14-role/attributes.t again.
• The specification states that if in a role you do inheritance, then this is just passed on to the class that the role is eventually composed in to, and added to that class's parents. We never had any support for this in master; with a neat meta-model approach it became rather easier to get it in place in ng.
• Got BUILD/CREATE fixed up a bit and added back support for "has $.answer = 42" style declarations, again through the new attribute sub-protocol.
• Got us handling non-block where blocks again, and added Block.ACCEPTS back - in Perl 6.
• We had various "helpers" to let us do some of the low-levelish stuff in PIR. This is mostly for the places where we need those things in place in order to be able to compile the rest of the built-ins that are written in Perl 6. However, a couple of these helpers knew too much about Parrot and too little about the meta-model, which abstracts it away. So, I re-wrote some of those in terms of the meta-model. Much cleaner.
• Before we relied entirely on Parrot for our "do we do this role" checks. However, given the unfortunate semantic mis-match between Parrot's built-in role support and what we need for Perl 6 (I did try and influence things in a different direction back when we were doing Parrot's role support, but failed), I've been gradually working us towards not relying on those for Perl 6's role support. (In master, it felt to me like we have almost as much code working around the semantics of Parrot roles as we'll need to have to not use them.) Anyways, the divorce isn't quite complete yet, and it's not even a goal for the ng branch. However, I did make a notable step towards it by getting our .does checks implemented entirely in terms of the meta-model. In the long run, I'm hoping we may be able to write the entire role implementation in NQP, which helps with the even-longer-run dreams I have of Rakudo having additional backends. But that's for The Future. :-)
• Cleaned up and re-enabled sigil based type checking in signatures.

Thanks to Vienna.pm for sponsoring me to hack on Rakudo, not only for these two days, but also throughout 2009!

Several days before Christmas, encouraged by my mum asking, "when you're going to start your Christmas break", I stopped working and hacking on stuff and started relaxing. Until then, I hadn't realized just how tired I was. I slept quite a few ten hour nights in the following week, and had an enjoyable Christmas break. I'd figured I'd maybe take a week or so's break, and then get straight back to things, but a week on I had no motivation or energy to dig in again whatsoever. So, I decided my break would go on through New Years. New Year's celebrations this year involved curry - something I certainly wouldn't mind it involving again.

Early January brought several days in Sweden, part of planning for an upcoming refactoring of my work/location - there's details on my personal blog, but the short version is that I've accepted a job at a Swedish startup and will be moving there in March. It's not full time, so I'll continue to have time for Perl 6 development. They know about and, happily, are supportive of my involvement in Perl 6 and my continued attendance of Perl conferences.

I spent a weekend in Prague on the way home. I did it by train rather than flying, which was enjoyable. It snowed almost my entire time in Prague, and I caught a cold in the following week, but it was kinda worth it to wander around this beautiful city. Didn't bother studying Czech at all, and sorta got by with speaking Slovak, though some folks heard me speak and immediately concluded English would be easier. :-) Somehow it kinda felt like I was back somewhere I belonged, even though I'd never been there before. I love central Europe, and excited as I am about Sweden, I know I'll miss this part of the world a lot.

Anyway, I eased back into some work in January, but mostly took it quite easy. The happy result is that, come February, I'm finding myself recharged and ready to dig back into things again. I got some nice commits done to Rakudo yesterday, and today I meant to, but instead participated on an interesting thread on p6l and did some other useful meta stuff (like this post). Tomorrow should have plenty of hacking time though, and I'm looking forward to it. I also have a couple of blog posts to do about Vienna.pm-funded Rakudo Days I did in December, but never got around to writing up; thankfully I did make notes on what I did on them. :-) My main focuses from here on will be on:

• Continuing to get Rakudo's ng branch into shape - we'll make it master soon. A lot is missing, but things are going back fast and often very neatly. It's easy to focus on what it doesn't yet do that master does, but it has many things right that master does not - now including laziness!
• Finishing up my signatures grant. I really, really want to do that within the next couple of weeks.

Anyway, that's what's been up with me. If you take away anything, it's that you may not realize how much you need a break from something until you take it, and if it's not the only thing putting food on the table, then it's probably better to take the needed amount of break and come back revitalized. I guess the other option is to dig back in regardless, but I suspect that's the path to burnout, something I'm quite keen to avoid.

More technical blabbering here soon. :-)

With the incredible amount of hype around "that thing Apple will announce soon", whatever they did was just never going to match it. People I think expected something amazing and revolutionary, which I suspect Apple also quite like to play their product as. I'd describe it more as an evolution - a kind of next step from what they've had before.

At first glance, it felt to me like they'd essentially taken the iPod Touch and super-sized it. The iPod Touch is perhaps the nicest tech product I've ever owned. It started off for me as a really quite nice web browsing device that I could easily take anywhere with me, and it also provided a good way to listen to music. With the app store, it's become one of the key tools I use for language learning. But does a bigger device help or hinder me? (Oh my, I may have just got this flagged as spam...)

For web browsing, it's for sure that the extra space would be nice. I do, sometimes, sit on the sofa and surf the web on my iPod Touch, but after a while the small screen gets a bit too cramped. I'd really quite like to do more of my non-work, casual surfing away from my desktop, but it happens rarely because laptop = worst posture than the desktop and iPod Touch = awkward for extended browsing session, even if it's an excellent web browsing experience for a device of that size.

For music it makes no difference at all to have this over an iPod Touch and I very much doubt I'd use it to listen to music unless I was using it for something else anyway.

For apps - this will be interesting. Watching the video demonstration of the email app that will come with the device - everything done by touch - I have to say that it looked like a good user experience. Apple seem to be really pioneering touch and multi-touch interface, and as someone who did once suffer a bit from - and still gets aches now and then due to - repetitive strain injury, time using alternative input methods to do stuff is appealing. I doubt typing a lot on the device will really fly, so I can't see me really replying to emails on it, but reading my mail, tossing the stuff that doesn't matter, following mailing lists and so forth could easily be done without much typing. For the language learning stuff, just having things bigger will mean less eye strain, so I'd not complain about that.

The main issue with bigger is that it's then less portable. I have absolutely no qualms about carrying my iPod Touch and my laptop around with me. Carrying a laptop and an iPad? Hmm. No. Do Not Want. So in many ways, I expect if I had an iPad, it'd mostly stay at home, apart from on those occasions when I was going away and didn't need a laptop (e.g. pure vacation, not for conference) but could spare the space for taking something a bit bigger.

So anyway, cool bit of tech, look forward to playing with one, can imagine how I'd use it, but suspect it's going to be a luxury rather than a "must have".

XML supports UTF-8 so I check for valid UTF-8 string and use it in XML if valid. Right? No!!!

There are some "non-illegal" characters that are perfect valid in UTF-8 (or even in the plain old ASCII), but are invalid for XML. The most obvious 0x00. Here is what W3C XML 1.0 specification say:

[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */

I spend some time playing with it and the result is XML::Char->valid(). The dev Data::asXML is using it now. If you you want, have a look at the test suit and try to break it. :-)

Once I told potyl - "hey let's have a wiki it will be easy to use for everyone". He wasn't so excited, not at all. Why? What is so bad about wiki? Look at this table of 130+ wiki syntaxes. Anyone still complaining that there are too many simmilar choices on CPAN? The wiki community decided to solve the problem by creating yet another wiki syntax...

What this has to do with Perl6 regexp grammars? After Damian talk at YAPC::EU::2009 I really wanted to try out the Regexp::Grammars. Finally I found some time during the Christmas and here is the result:

use Regexp::Grammars;
use re 'eval';
my $parser = qr@
<Wiki>

<rule: Wiki> <[Block]>*
<rule: Block> <.EmptyLine> | <Code> | <Para>
<token: Para> <Heading> | <List> | <TextLines>
<token: EmptyLine> ^ \h* \R
<token: TextLines> (?:^ (?! <Code> | <Heading> | <List> | <EmptyLine> ) [^\h] .+? \v)+
<token: CodeStart> ^ {{{ \h* \v
<token: CodeEnd> ^ }}} \h* \v
<token: Code> <.CodeStart> <CodeLines> <.CodeEnd>
<token: CodeLines> .+?
<token: Heading> <HeadingStart> \s <HeadingText> \s =+ \h* \v
<token: HeadingStart> ^=+
<token: HeadingText> [^=\v]+
<token: List> <[ListItem]>+
<token: ListItem> ^ <ListItemSpaces> <ListItemType> \h+ <ListItemText> \v
<token: ListItemSpaces> \h+
<token: ListItemType> (\*|\d+\.|a\.|i\.)
<token: ListItemText> .+?
@xms;


It is probably not the best piece of regexp gramar, Perl6 experts will for sure spot some error, but hey it works! "Works on my computer". I've used it to transform TracWiki syntax to XHTML div and then using XSL to DokuWiki syntax. Here are the scripts that does it completely.

So for some reason I joined. I'm still not quite sure what to make of it, but my presence there seems to have made some people happy. Anyway, if you want to follow my semi-regular but thankfully length-restricted babble (it's like, SMS-length or so), then I can be followed - I guess a slightly better term than stalked. My longer babbling will, of course, continue to appear here. :-)

Povedz mi čo čítaš a ja ti poviem, kto si. Táto veta sa mi prednedávnom vybavila ako spomienka na detstvo. Už som ju dávno nikoho nepočul vysloviť. Ešte pár rokov dozadu platila na 100% na knihy, časopisy a noviny. Bolo ich veľa ale nie zas tak veľa aby sa v tom človek stratil. Dnes sa pojem "čo čítaš" skorej hodí na "aké stránky navštevuješ" a teda - Povedz mi aké stránky navštevuješ a ja ti poviem aký si človek.

Prečo mi to tak začalo vŕtať v hlave? Trochu som sa hral s vyhľadávačmi a zrazu sa mi otvoril nový pohľad na svet. Zistil som aký bol obmedzený. To sa počas života stava, je to príjemná zmena pozerať sa na svet inými očami. Doporučujem prečítať - Search Engines and Power: A Politics of Online (Mis-) Information.

Z iného smeru - čítali/prebehli ste si Ročenku Českého Internetu 2009? Jedna vec ma tam naozaj zarazila a to, že seznam.cz má už roky ~60% podiel na vyhľadávaní v ČR.

Na chvíľu zabudnime na všade prítomnú reklamu a naháňanie sa za návštevnosťou preto aby sa častejšie mohla zobraziť reklama. Keby tento aspekt zmizol z internetu čo by zostalo? Zostalo by ďalšie informačné médium ktoré formuje náš pohľad na svet. A či si to zoberieme z tej alebo inej strany vyhľadávače ho formujú a reformujú, lebo nám umožňujú (alebo znemožňujú) objavovať neznáme zákutia. Boli časy keď ľudia nechápali (alebo nechceli chápať), že kto nieje na internet ako keby ani nebol. To platí stále viac a viac v dnešnej dobe. Aj keď vývoj ide dopredu a platí, že kto nieje vo vyhľadávačoch ako keby ani nebol...

A na záver? Zamyslite sa a vyberajte si aké stránky navštevujete a aké (často zadarmo) služby využívate. Je to váš formujúci sa svet!

I finally got around to uploading some photos I took this winter in Riga and Prague. Not the best photos ever, partly due to lack of time and weather (it snowed just about my whole time in Prague), but they're offer an idea of these places, anyway. Oh, and that takes us up to 33 countries now. :-)

This is the name of the incredibly boring exam that you must take before you can take any of the possibly less boring exams that then make you a Microsoft Certified Technology Specialist. While I was in Sweden, I had a crack at taking this exam...and passed it. Not just passed, but passed quite strongly: I got 88%, while the pass mark is 70%. Not bad.

The really annoying thing is that even though I've been doing .Net development commercially for quite a while now, that only sort of helps. While you can get so far with a general understanding, the test is, in a large part, about memorizing a bunch of method and class names from the standard library. For bits of the standard library I've used quite a bit, that wasn't so bad; for the other bits, it was a case of madly trying to cram them into my brain in the few days before the test (because, being me, I didn't think to start preparing until a few days before).

As an aside, tonight I logged onto the Microsoft Certified Professional site. What a steaming pile of crap that is! Took me three attempts to log in, took me in a loop while entering the activation code, and once I did log in trying to view the list of exams I'd passed just to check the one I expected was on there gave...a .Net Application Error! Oops. Guess they shoulda got some ASP.NET certified technology specialists to write it for 'em... :-/ Ah well, one more exam and I'll have something shiny to wave at anyone who thinks such things matter...

It is only the beginning of 2010 and we already lost 3 men. Who? Why?

1. Emmanuel - a Perl guru now finally leaving Bratislava for booking.com in the Amsterdam
2. Jonathan - a Rakudo (and many other programming or human spoken languages) guru leaving for Sweden
3. Martin - network guru and manager that is programming in Perl, leaving for Sweden too

I would like officially say "Thank you!" to all three of them for what they have done and brought to the Bratislava.pm group.

While in Sweden, my friend Tore arranged for us to go and see Avatar. It's the first time I'd been to the cinema in a while, and the first full-length movie I've ever seen in 3D (the only other one was a short at the IMAX cinema in Bradford in England, years ago). It was a great film to have seen at the cinema rather than just at home: decent plot, lots of action but also insight into human nature. While there was something of a love story in it, it didn't dominate and detract from the key plot, which was good. Anyway, worth seeing in my view. Won't tell any more and spoil the surprise. :-)

It's time for me to be moving along again. I spent much of last week in Sweden, and the upshot is that I'm joining a startup company there. The work looks to be interesting, and less dominated by doing web development, which I'm mostly fed up of. It'll give me a bit more financial stability. I can still keep on going to Perl conferences, and it's not a full-time arrangement either, so I'll continue working on Rakudo, Perl 6 and other small bits. Overall, it was a hard offer to turn down, so I've taken it.

For the first time I actually have work that needs me to base myself in a specific part of the world - specifically, south-west Sweden, around Malmo/Lund/Helsingborg. So, sadly, at the end of February/the start of March, it'll be time to say dovidenia to Slovakia and move over to Sweden. Unlike when I moved from the UK to Spain - which I gladly did to run away from hurt - and when I moved from Spain to Slovakia - which didn't feel so bad, since I didn't want to face the hot Spanish summer and was excited to be going to live in central Europe and to study a Slavic language - this isn't a move I'd have just spontaneously done without something to motivate it.

That isn't to say Sweden doesn't have many attractions; I have always very much enjoyed my visits there, there's some great scenery to be had, there's lots of places by the sea, I like the people, there's lots of good restaurants and the pro-conformity and confrontation-avoiding social attitude fits me well. Of course, it presents me with another languages to get to grips with too - Swedish in all its oh-no-you-have-HOW-many-vowels glory. On the other hand, the grammar - after Slovak - should be a good bit easier. That's kinda annoying in the sense that I'm good at grammar and suck at rendering tricky sounds. Ah well, I'll try and find a good teacher (my Slovak one will be a hard act to follow though) and see how it goes.

But despite all the attractions of Sweden, I'll certainly miss Slovakia. Being in central Europe has been really nice - I love the hearty food, the architecture and the scenery throughout the region. I'll also miss the language - I don't know why, but I'm somehow fond of, and fascinated by, the Slavic language family. And of course, I'll miss the people here, especially my friends from Bratislava.pm and those I've made through the international church here, which has been an enormous blessing to me. I've found it kind of sad to hear one Swede describe this as me "moving to a sane country", and one family member describe Sweden as "better than Slovakia". If there's any word for this part of the world, it's perhaps "misunderstood" or "under-appreciated" or some such. Sure, it's a bit rough around the edges here and there, but hey, so am I.

Anyway, I figure that since becoming an adult, I did a few years of work-focus at university, followed by a few years of traveling, living where I liked, and avoiding committing myself to things that would tie me to living in a certain place. Now it's time to do a chunk of work-focused time again, and accept the commitments that come part and parcel of that. Of course, there'll still be travel and fun - my university years had both of these. And I'd not like to imply any expected duration for my time in Sweden - that'll come out naturally, just as the right opportunity for me to kick off a work-focused chunk of time also naturally appeared. So when I say goodbye to my home here in a couple of months, I do so with an expectation that life stands a good chance of granting me another opportunity to live in this region again. And I'll most certainly be able to come and visit in the meantime - it's not all that far away. :-)

Spísal som rekapituláciu toho čo sa udialo v Bratislava Perl Mongers skupine v roku 2009. Tu k prečítaniu. Všetko dobré v novom roku 2010!

Google vs Cuil vs Yahoo vs ...

Wide screen offers a lot of horizontal space so why not to use it and search with two (or more) search engines at the same time? Try search.meonl.com (about).

Where is the Perl there? There in the back. In the name of static can be more the meonl.com files are pure HTML+CSS+JS generated using Template Toolkit ttree and some Makefile rules.

The search.meonl.com page is basically an input box and 1 or more iframes with search engines. Submitting a text in the input box results in reloading search engines with a search url.

Why was the search.meonl.com created? I got an idea how to do the web searches a little different way. But then I've realized - who the hell will try just another search engine??? Well no one of course :-), but if there will be a way to keep Google (or any other major search engine) next to the new one, may there will be a little chance... I will probably never have enough time, money, energy and the rest one needs to start and finish such a project, but at least now there is a way how to compare how good the current search engines are - side by side.

The few days that I'm playing and searching with multiple search engines at once made me realize that, yes - the search engines are different. And yes - the other (than Google in my case) search engines can give better results sometimes. :-)

I feel like no one ever told the truth to me
About growing up and what a struggle it would be
In my tangled state of mind,
I've been looking back to find where I went wrong.
-- Queen - Too Much Love Will Kill You

There are people that say reinventing the wheel is bad, that it shouldn't be done. That we should find an existing project and contribute there. Some even say that there are too many variants and choices of CPAN modules that are doing the same thing, and it is wrong. That it is contra productive and scary for the newbies. There are people that call them self CPAN police that hunt down new uploaders trying to show them how many mistakes they made...

Now look at the kids. Those experience deferred success 1000 times a day. Even if they don't fail they play most of the day. They play by repeating, copying from adults or other kids. They speak the same sentences wrongly over and over. They do the same things over and over. They fail over and over. They are just kids. Every one knows that this is how they learn. Next to the kids there is always some adult. Until the kids are really small, the adults seems like perfect to them, because they just do everything perfect.

After growing up, one day, kids finds out that the adults are not perfect. They don't do always the right thinks. And they don't know everything. The trouble is that there are many adults that think that they perfect are. But that is different topic. Let's go back to childhood.

To be precise the Perl programmer childhood. Perl programmer life. The difference is everyone is free to be born to the Perl world and grow up here. The other nice thing is that everyone is free to leave it and go and live a different life.

/me a Perl kid. I like to play, I like to try out things. I like to reinvent the wheel over and over. I don't mind that there are Perl grown-ups that do the same thing much better than I do. I don't mind that I will hit the ground while doing weird experiments. And? It's fun and everybody has to fall the first time. (and second and third and ...) And I'm just a kid!

The Perl world is different to the "reality". The biggest difference is that it's hard to see the age. Everyone is growing with a different rate and some will never grow up - like me :-P

So I would like encourage all kids to come play with toys, throw them away if they don't like them any more and not be ashamed that they "just" build "another" sandcastle. You can always destroy it and build another one, don't you?

Now back to the desert of the real. There is a plenty of legacy Perl code every where around us. Legacy sometimes mean undocumented, unmaintained, badly written or just not understood. Sending bad words and blaming people that wrote it will not fix the situation. Everyone is doing the best he can, considering his experience, mood, moon phase, weather conditions, ... at the time of writing the code. If the makes the job done, it is good. If it makes someone happy writing it, it is even better. And if there is no replacement, it is the best code ever!

So, the so called noughties have come to an end and a whole new decade lies ahead. So what exactly did I do in the last decade?

I finished school, college and university, and then called a halt to study. I may return to the academic world some day; I muchly enjoyed my time there. But I don't see that being in the very near future. Anyway, I came out with good grades through it all, and finished up with a first class honors degree in computer science. It goes without saying that I didn't see that as innevitable at the start of the decade. All the way through, I knew I was goodish, but always doubted whether I'd hold up at the next level. Turns out I did fine.

I visited 33 countries. That's something I'd most certainly not seen myself doing ten years ago. My love of travel evolved around hte middle of the decade.

I've lived in two countries other than the UK. I'd not seen that one coming either. Alas, no regrets, and I it'd not surprise me at all if I live the next decade out of the UK.

I've developed a love of natural languages as well as computer ones, and muchly worked out how to learn and cope with them. A decade ago, I was a competent but disinterested attendee of compulsary French classes at school, and didn't expect I'd ever long to learn a language. (Recently, I've been working on an article about some of how I look at natural languages today, which I hope to publish later on in the month.)

I've remained a Christian, despite many challenges, and a few times where I had to ask God, "seriously, why the f**k did you just let THAT happen?" I still don't really understand most, if any, of the things that caused me to ask such questions. Alas, there's been a great deal more blessing than pain. I've increasingly refused to identify myself with any tighter label than "Christian", come to advocate a non-denominational viewpoint, and lean to a fairly minimalistic view of what defines being Christian. Whether somebody has a different take then me on homosexuality, use of tongues, child baptism and so forth should absolutely not prevent me being willing to share in communion with them - because those issues actually don't matter that much compared to the core truths.

My music tastes switched from electronica to rock overall, through a stage of industrial and crossover style stuff. That said, a lot of the rock I like has electronic elements or, often, symphonic elements. These days I'm most interested in progressive rock/metal, power metal and symphonic rock/metal.

I also wrote some music, some of it for Christian worship, some of it not. It started off as electronica, but along with my tastes evolved towards more crossover and sometimes all out metal. I've moved more towards production of music using existing samples, and have enjoyed writing lyrics more than anything else. Sadly, the last year or so hasn't seen much new get completed, however.

I've come to appreciate beer and coffee. That is, good beer and good, strong, black coffee. I wasn't into either a decade ago. Then, I guess I was a bit young to be into beer anyway. :-)

Indian food is still my favorite type of cuisine. I was exposed to it from a fairly young age, so a decade ago I was already fond of it. While I've discovered much other great food in the meantime, Indian remains my favorite. Most, if not all, years, I've had curry as a key part of celebrating my birthday.

Importantly, I gradually became more comfortable with who I am. I'm me, with all my quirks. And now I'm quite comfortable with the fact that this is just fine - a view I found harder to take back in the days of school, where fitting in is somehow made to matter more. If people don't want to accept me as I am, that's fine - they can go hang out with people they can accept.

Over the last decade, I've had the pleasure of meeting, talking with, travelling with, working with and being taught by many great people. I'd like to finish off by saying a huge thank you to all those who have helped make this decade one that, amongst a large bunch of crap, has actually been an overall positive one. Here's to the next one. :-)

Still there after reading this and this?. What I would like to show next is Module::Build::SysPath and the usage for CPAN authors. What are the features?

• pre/post install paths (dev+test/prod)
• system paths configured once when Sys::Path is installed
• "Debian way" of handling configuration files
• automatic all files copying
• creating of empty folders (for state, log, etc. files)

The main reason for existence is to install files (configuration, templates, data files, ...) where FHS recommends and also to know where to put temporary files (like state, lock, cache, ...).

There are couple of stages that the CPAN distribution is going through. Development, smoke testing, pre install and install stage. In all of those it is good to know where our files are. :-P Before the final install the files are always inside the distribution folder, only after install the files are in the system folders. There for the Module::Build::SysPath requires a special module YouModuleName::SPc that gets overwritten with values from Sys::Path once installed.

There are, as always, couple of other ways how to store and work with non-perl modules files. Here are some that I'm aware of:

• storing data inside __DATA__ in .pm file
• storing files in the same folder as .pm files
• storing files in auto/ - File::ShareDir
• hardcoded system folders
• use Sys::Path paths directly
• ???

Everyone can choose.

There's things in England I miss. Like, my friends here, and ale, and the chippie. Today it was time to get some train tickets for a little trip down the country to visit some friends and family, and I remembered how much I didn't miss the railway ticketing system here. No, not the nice "buy online, collect quickly at a station" bit. That bit is quite good. But the price scheme is silly.

To take one example, I looked up the price of a single ticket from Market Harborough to Scarborough, one leg of the journey that I need to do (actually the last one). Price: Ł56.40. Ouch. But of course, we can play with this. For example, break the journey at Sheffield. It costs Ł16.00 for an advance ticket to do that first chunk of the journey, and a ticket through to Scarborough from Sheffield sets me back Ł27.50. Wow. Buy two tickets that get me the same journey and I saved Ł12.90. Huh?

But wait. I apply the trick again to the second leg. Now I can get an advance from Sheffield to York for Ł9, and getting from York to Scarborough costs Ł8.50. That saves me another Ł10.00 on the second leg.

So in total, by buying three separate tickets to cover the same journey - and thus costing 3 times the amount of ink and paper for the ticket machine to print them all out - I save myself Ł22.90. I'd say "way to make a profit", but of course it is. Who would think of trying such crazy tricks? Well, not so many folks, I guess. So essentially the fare structure operates on people buying tickets needing to work out where train operating comapny boundaries might be, or where subsidised lines might be, and break their journey up into steps.

Of course, now I have a nice analogy for imperative vs declarative programming, and how the declarative "just say what you want" model can carry extra cost. If I can make people anywhere else in the world believe that it really does work this way, anyway. :-/

Reasoning why knowing the system paths is a good idea can be found here. Now let's see how one can guess (get?) them in Perl.

There are a lot of Perl installation made to non-standard paths. Like:

• /usr/local/bin/perl
• /home/$USERNAME/local/bin/perl
• C:\Strawberry\bin\perl
• /opt/bin/perl

I was trying to find out what do this installations share and what could be used to find out if the Perl is in file hierarchy standard folder - /usr/bin/perl. The simplest way, that I found out, was to:

use Config;
if ($Config::Config{'prefix'} eq '/usr') { ... do stuff ... }


That is basically all Sys::Path does. If the installation prefix was set to "/usr" (in all Linux distributions standard Perl packages it is), than the rest of system paths is by default set to FHS. If not all of the paths are based on the prefix - $PREFIX/etc, etc.

Just check the Pod of Sys::Path for all the different paths and their usage.

too simple? but works :-)

So the new laptop finally arrived. A little bit lighter and thinner than the one it replaces, which is a nice win. There's certainly thinner and lighter out there, but those weren't huge priorities. Perhaps the biggest weight improvement is in the power adapter, which is far lighter. Anyway, will be a little nicer for carrying. Happily, it's far faster, which was the main point of the upgrade. And apparently I should get around six hours of battery life out of it, but we'll see.

I also braved it and got Windows 7. First impressions are good. Of note, the task bar is far, far better for people like me who tend to have numerous applications open at a time. There's a nice unification between common apps placed on the taskbar and instances of them, which felt odd for the first hour, but now feels wonderful. Being able to hover over an app that's running and glance at a thumbnail of it is already being a big win. For example, I can quickly hover over the Firefox button and see clearly enough how far along a download has got. Overall things feel fairly snappy and responsive, despite these nice extra graphical bits.

There's far more placs to type and search rather than click through things. I already like being able to search out programs by typing in their name rather than browsing some huge start menu, and the cursor being focused there after hitting the Windows key means I can launch stuff without even moving my hand over to the mouse. Being able to search in a directory and those below it so trivially now - there's a search box right there in the explorer window - is also nice.

Anyway, that's first impressions. I didn't manage to crash it yet, and have been able to install all the initial bits I wanted, and it feels it'll make me more rather than less productive, plus it's a pleasing enough facelift. After the disaster of Vista, it seems Microsoft have somewhat got their act together and delivered something that actually may very well turn out to be an improvement on XP, on hardware that'll handle it anyway.

The UK is a funny old place. :-) This week saw a curious battle for the top spot in the music charts. One contender was from the winner of X Factor, as expected. The other was more of a surprise: a rock song from 1992 that a bunch of people started buying in response to a Facebook campaign. And...the song from 1992 won and is the Christmas number one.

I like the song (Rage Against The Machine's "Killing in the name of", for anyone who didn't follow the story); it has some nice guitar work in it and some catchy riffs. That said, I can appreciate it's not to everyone's tastes. But a lot of people's reaction is "but it's Christmas, this song is so unsuitable!" While I can agree that the expletive laden ending is not exactly family friendly, the song lyrics of the song are actually a cry out against corruption and injustice. And in a way, that makes it Strangely Appropriate. Christ didn't come to stay a cute baby, but to grow up into a man who would fight injustice. Granted He did it without the expletives as such, though claiming to be the Son of God was likely as offensive to many people of the day anyway. It's certainly a call to stop and think about what Christmas is really about anyway, and in that sense, I'd count it a win. (Also, the band said they'd donate a bunch of the windfall to a UK charity. And I'd count that as quite fitting with the Christmas spirit. :-))

Once upon a time I was a young system administrator. Having all the strange looking /usr, /var, /etc, ... all round me was scary and I was not sure what to "do" with all those folder trees. At some point I started to compile the extra programs that I needed. With a default prefix all ended up in /usr/local which looked safe to me. I knew that my stuff is there and the mysterious system stuff is everywhere else.

Well it worked. Having to maintain some more servers later I started to do some packaging. I was using Slackware at that time and the Slackware packaging system was really simple - just a tarball that got extracted to the root of the file system with some scripts that got executed during the package installation time. Simple and worked for me. Still I kept the stuff in /usr/local to be on the safe side.

And the time passed :-) and I'm using Debian now, but most important change is that I've lost all my respect to the file system and I've learned where and why to put files. Why to use /etc for configs, /var/log for logfiles, /var/lib for state files, /var/cache for cache files, /usr/share for templates or static data files, etc.? Simple because it is standard. Because it is standard, standard compliant distribution will stick to it. Besides being standard there are some really good reasons too. Helper tools will understand the files and then act based on the files category. Automatically rotating logs, backup-ing the important (non static distribution) files, cleaning up the temporary files etc. Well and there are also humans out there. Co-admins or newcomers, that will login to the machine and look for files or trouble shoot the programs. Knowing where to look for stuff really helps!

With today advance of virtualization techniques there is no reason to mix too many things (projects) on one server. So there is no reason to play safe with the paths and files should be put to the right place where they belong - FHS.

(to be continued with Perl part of the story...)

Have you ever had a Perl distribution extracted and wanted to install all it's dependencies afterwards? You can do it using:

cpan -i Test::Install::METArequires
perl -MTest::iMETAr -le 'Test::iMETAr->t'


The output will be TAP. One test per dependency. Is there some other (better) way to do it? Should be as always...

Reply to two commanets from "when virtualization is too expensive".

1st was from grantm. Thanks for pointing out the OpenVZ. It's much more professional tool than debootstraping and chrooting, but comes with more configuration and setting-up complexity. It's possible to share memory using OpenVZ which is the resource that we never have enough.

2nd was from Alias. Alias is pointing out the deduplication of disk data. Disk space is kind of cheep these days, comparing to memory, bandwidth and cpu processing costs when dealing with huge data. The deduplication can offer, besides saving the disk space, a better cache efficiency, that will increase disk read speed, that is never fast enough. ZFS should soon (first quarter of 2010) support deduplication. It seems that there will be no native ZFS support for Linux because of the licencing problems :-( . Easy Linux deduplication that can come in handy is cowdancer. `cp -al some-folder/ some-folder.copy && cd some-folder.copy && cow-shell` will copy "some-folder" via creating hardlinks which is really fast. Than any write operation under this shell and folder will result in removing the hardlink and creating a new file => copy-on-write. This works good with chroot-ed systems to test new Perl module versions or do some other experiments.

Work in the ng branch continues; this post is an update on some of the work I've done on a slightly broken-up Rakudo Day (things have been a tad disrupted while I've come over to England for the month).

Perhaps the most exciting bit of news is that I've done an implementation of the attribute meta-protocol. The main upshot of this is that we now don't hard-code the creation of accessors, but rather call a "compose" routine on the Attribute object - the meta-object that represents an attribute - and it does the accessor creation. Amongst other things, this opens the door for custom accessor generation, which I believe is something that many Moose extensions do, and so will be useful for Perl 6 meta-programmers. As a bonus, the Attribute class is implemented in NQP, not PIR.

I've also continued working on roles. I'm happy to say that, unlike in master, we implement the does and but operators - which do runtime mix-ins of roles - in Perl 6 now. They don't actually do much - the heavy lifting is done by the RoleToObjectApplicator class. That one is implemented in NQP, with only one small Parrot-specific bit. It feels great to be writing these bits in something higher level, and - importantly - means they're all building on a fairly small set of primitives rather than having deep magic everywhere.

In other smaller bits of news, I got the dotty form of .= working, and also implemented the .^ dotty operator too (which makes metaclass calls prettier).

All in all, I'm fairly happy with how things are shaping up. I'm hoping another Rakudo-day sized push and we'll be able to run many of the roles related tests again, but this time atop a much cleaner and more correct implementation, a large part of which is in Perl 6 (or NQP, which is a subset of Perl 6). Thanks to Vienna.pm for sponsoring this work.

Yes the thing that turns your single computer to multiple computers. Why should it be expensive? Simply because the virtual machines are not sharing one disk space and one memory. To make the the virtual system run smoothly, it needs some decent amount of dedicated memory and a disk volume with some reserve so it doesn't have to be resized too often.

First find the reasons for doing virtualization, why would anyone want to run multiple machines on a single hw? Most likely to clearly separate the programs and the whole operating systems. Give the strictly defined virtual hw resources, limit the access for security reasons. And also to add one level of abstraction which then allows systems to live in a cloud. But that is a different topic.

Let's search for the solutions how not to do virtualization and fulfil some (!) of the requirements of it. Mainly the clear files and whole system separation for Perl development.

If just Perl is in the play, then compiling and installing user own Perl is an option. Simply having the Perl binary and all the installed CPAN modules in the $HOME directory of the user.

If Apache is needed or some extra binary libraries, it is still possible to compile and install to the user home, but it is quite a lot of "hand work" and not every one has time and passion to do it. Much more simple way is to use chroot. What chroot does is that it sets root of the filesystem for the child processes to a folder. And as we are in UNIX, where (nearly) anything is a file, this means a different machine. Both systems, the parent and the chroot-ed, still share the same /proc, /dev, network devices etc., but the separation is enough to be able to install programs with standard distribution commands and run them. Fair enough to have chroot-ed machine as a development machine. Benefiting of shared memory and disks pace, easy file sharing (one filesystem) and not having to maintain virtualization sw.

Here is how to create a chrooted system on Debian and switch to it:

debootstrap lenny /usr/chroot/$MACHINENAME
echo ${MACHINENAME}_chroot > /usr/chroot/$MACHINENAME/etc/debian_chroot
chroot /usr/chroot/$MACHINENAME su -


CHI looks interesting - one Perl module interfacing to any kind of cache. The "L1 cache" + "mirror cache" is a technique worth looking at and it adds more value to the module beyond just an unified interface.

I wrote recently about feedback.cgi on Bratislava Perl Mongers page. It turned out to be useful only to deliver more spam. Today I've replaced it with a JavaScript bookmarklet to the new evil thing from Google - Sidewiki. So everyone has still a chance to annotate the pages and I have one less thing to maintain. Win-Win.

Btw this is how one can get the sidewiki RSS feed url for http://bratislava.pm.org/ page:

perl -MURI::Escape -le 'print "http://www.google.com/sidewiki/feeds/entries/webpage/", uri_escape($ARGV[0]), "/default?includeLessUseful=true"' http://bratislava.pm.org/

I got back from Latvia yesterday. The first Baltic Perl Workshop was very small, but also very enjoyable. I also very much enjoyed meeting up with masak++, who shares my love of good food - curry included! Riga turned out to be a great place for having a good nom, both in terms of local stuff and nice hot curry. And of course, amongst the workshop and some sightseeing, some hacking got done too.

Today was Rakudo Day, and it was time to get back to meta-model matters. I actually spent a while during my time in Riga reading a good bit of Moose and Class::MOP - I'd seen bits of them before, but this time gave the parts relating to roles a much closer look and got myself a refresher on some other bits. I also spent the plane ride home (pretty much the entire flight!) reading an interesting paper on composing meta-objects from traits, which turned out to be a much easier read than I had expected, but left me wanting to read many of its references too.

The first thing I worked on today was getting more details into metamodel.pod, which is the currently under heavy construction specification for Rakudo's meta-model. It will in the future become a proposal for inclusion in the Perl 6 specification too, at which point it'll be time to co-ordinate with other implementations to get something that we can all agree on. Anyway, if you have an interest in meta-programming, you may be interested to give it a read and leave comments, or catch me on #perl6. For those just wanting to see some code rather than read a spec, skip straight down to the example of how writing a module to support something AOP-ish could look. It'll no doubt evolve somewhat, and we won't be able to run it for a little bit yet, but I think it's a nice example of how easy it should be to implement such things in Perl 6.

After that, I dug into starting to get some implementation work done, with a focus on working towards having role composition working as spec'd in the metamodel document. So far I've got a lot of the foundations laid, and I'm now starting to build up on them. So far, it's mostly just plumbing, but composing a role into a class and the class then gaining the role's methods does now work, and a bunch of what we need for required methods and conflict resolution is stubbed in, though untested. I also was able to write a chunk of this in NQP rather than PIR, something I'd like to see us increasingly do in the stage 1 compiler, where it makes sense to do so (the stage 1 compiler containing the things we need in order to compile the setting; the smaller we can keep this part, the better it'll be for us overall...for now the goal is mostly getting the ng branch landed rather than small-stage-1-nirvana though :-)). Anyway, I think I can probably progress pretty fast from here and get our role stuff up and running in the next couple of days.

Thanks to Vienna.pm for sponsoring Rakudo Day.

There are 2625 XML modules atm on CPAN. (`zcat 02packages.details.txt.gz | grep -E '\bXML\b' | wc -l`) So why not create another one? There are number of modules that are trying to map XML structure to Perl data structures. This can never be perfect and sometimes needs custom hooks to adapt. What about the other easy (easier) way around? Serializing Perl data structures to XML? I've made an experiment. More about it here or in Pod of Data::asXML.

This is a summary of what I did on my Rakudo day on Monday as well as other little bits of random hacking since then on the Rakudo ng branch.

• Corrected dispatches on proto-objects, and along the way fixed a few things that were quite likely bugs in master.
• Got signature introspection back in place.
• Switched back on @ requiring the Positional role and & requiring the Callable role when binding parameters.
• Got parallel dispatch back in place, and we parse it a like STD now.
• Added back parsing of fatarrow, and its ability to be used to supply named parameters
• Added back submethods.
• Made .= parse and work again; we almost certainly need to re-visit the way I did it, though, since while I didn't find a better way yet, myself and Pm both agree the current way is not ideal.
• Put back Inf, -Inf, +Inf and NaN, which parse as literals.
• Brought .arity and .count back over from Rakudo master and simplified them a bit along the way, thanks to other refactors.
• Get placeholder variables parsing and mostly working again.

So, a whole grab back of little bits here and there. Things continue to come together nicely, but a source of some frustration is that our passing test count remains low. The issue here isn't that we aren't adding back lots and lots of things, but that the test files often require features aside from the things they're actually testing. This is part and parcel of having a Perl 6 test harness - indeed, one issue we have is that we didn't put back eval yet, so eval_dies_ok tests can't yet be run. But another issue is the temptation for test writers - and I'm just as guilty as anyone - to write tests using Perl 6 language features unrelated to the thing being tested themselves. For example, many of the tests for signature introspection rely on the parallel dispatch operator. The test file itself is beautiful and elegant, but unfortunately I'm still working towards putting back things we need - even though I have signature introspection back in place - because of other features it just assumes. So I expect we'll hit a point where we very suddenly get back loads of tests - the problem is that in the meantime, we don't have as much testing to tell us of regressions as would be ideal.

OK, time for me to fly to Latvia, for the first Baltic Perl Workshop, now! :-) Thanks to Vienna.pm for funding this work.

18 November 2009 18:00

Boli tieto tri prezentácie:

• Jonathan - Meta-models: the magic that makes OO less magical
• Jozef - IRC bots
• Emmanuel - Gtk2::SourceView2

This is a report on what I did on my Rakudo Day on Friday, but didn't manage to finish writing up until now.

It was time to switch focus from building up metamodel primitives in the Rakudo refactor for a bit and dig into the work of bringing back a bunch of the Perl 6 setting - the built-in classes and functions that are implemented in Perl 6. In doing so, I knew I'd discover lots of other little bits that would need putting back, which would guide my efforts. I chose to work towards bringing back Any-num.pm first - various bits relating to numbers. Preparing to do that led me to fix up a whole raft of other bits.

• Needed to bring the way we parsed method declarations more in line with STD.pm.
• Needed to update the identifier rule to match STD.pm so we could have identifiers with hyphens in.
• Got basic support for when/default blocks in place; mathw++ had already done given blocks.

After that, I could also bring Int.pm back into the setting. That went pretty smoothly, though needed a few tweaks since subs have "my" scope by default in Perl 6 now, something that we never updated master to handle, but have got right from the start in the ng branch. Adding that in allowed me to get rid of a few of the "cheats" that we'd had in place beforehand.

Continuing on the theme of number handling, my next act was to try and bring back Rat and Complex. Rat went in with a bit more hassle. I discovered that I'd managed to make a mess of declaration order mapping between source and the PAST tree we built. Happily, once I understood the problem, the fix was only a few lines of patching. However, then I hit on something else weird: we seemed to be calling wrong multi-candidates.

I was sure I'd made a mistake in the code-gen...but no, it all looked right. Bug in the signature generation? Nope, those looked good too. It wasn't going to be a multi-dispatcher bug really, given that this had been brought in practically unchanged from master - or at least, without any notable changes. After a lot of searching I discovered that we really weren't entering the multi-dispatcher at all, but instead always jumping to the same candidate - but only in other code in the setting, not in stuff done in the REPL. Realizing it was only an issue with code in the same compilation unit was a big clue. Due to changes in the way we're doing code generation now - in order to not create so many bogus objects of the wrong type at startup that we only then have to re-bless - a nasty Parrot issue had shown up to crash the party. Worse, while I'd call it an optimization bug, pmichaud++ correctly pointed out that a lot of existing code was almost certainly going to be relying on things working this way - the optimization was providing a feature, pretty much. Thus my proposal to just disable it wasn't quite going to fly. This issue still somewhat remains "to solve", but I'm hopeful we'll get some solution of some sort today, as I suspect it's going to become a bit of a serious blocker otherwise. Blocker as in, we probably can't pass any of the multi dispatch tests before it's fixed, even though the dispatcher itself is likely fine. What a PITA.

After hunting that down, I only really had time to get Complex.pm back in. There was much commenting out still, but that will guide me on what I needed to hack on next. And happily, having put these bits back led colomon++ to hack away on them a bit over the weekend. Thanks to Vienna.pm for sponsoring my work on Rakudo.

Does anyone knows of a Perl MVC implementation that is based on some event loop? Having non-blocking IO (filesystem/database) in web request handling would be nice to have. That will enable to have just one process per CPU. The IO is the only reason why "one process is NOT enough for every CPU"

enjoy! (ignore?)

1. make mehappy   # make for fun and profit
2. a hook for you
3. scraping my self
4. less can be more
5. dôveruj ale preveruj
6. feed us back
7. XSLT hammer
8. one Apache child must be enough for everyone

(hmm I was missing word Perl for IronMan here...)

So, a new week is here, and hopefully this will be a week of lots and lots of progress on the ng branch of Rakudo. We've made a pretty good start, and things are just about starting to hit the exciting stage now where we're starting - piece by piece - to bring back the Perl 6 setting. In there now we already have cases of operator and trait modifier definitions and well as some initial class declarations. Basically, that means that we've got a lot of the fundamentals in that we need for the rest of the setting. A lot of the bits we are still missing aren't actually that hard either. In fact, it's starting to feel like we might be getting to the point where this refactor is nearly "over the hump" and we can start winning back passing spectests quickly.

I continue to be happy with how things seem to be overall much cleaner now in the grammar and actions, as well as the general organization of the code base. My focus has been mostly on continuing to get things related to the object model and the type system back in place. Some of the highlights have been:

• Adding the augment scope modifier, which is for adding extra bits to a class definition. This is especially useful when we want to define most of a class in Perl 6, but need to have some of the low-level bits available in the stage 1 compiler, which we use to compile the setting. This hadn't used to be a scope declarator, but rather a compiler-handled trait; we've regressed on various tests for quite a while since the spec changed, but we'll be able to have those back when the branch lands.
• Getting multi-methods back in place again. This wasn't too much work at all, and I'm quite happy with the end result, which no doubt does some better error detection. We use these in the setting heavily, so they - along with augment - were another big roadblock removed.
• Getting sub traits back in place, which unblocked pmichaud++ to work on export things. I'll leave him to blog the details, but we've made some nice wins there, in terms of handling things better than we have before.
• Being able to pretty much copy-paste the error handling for bad type names in scoped declarators from STD.pm into Rakudo's grammar. STD is really pretty good at giving decent diagnostics when things go wrong, and with the new grammar engine we're being able to bring a bunch of these into Rakudo. "In "my" declaration, typename Monkey must be predeclared" is such a nicer error to get than the rather less informative "Malformed declaration", which doesn't even tell you what sort of declaration it was, let alone what was wrong with it.
• Adding back a couple of things that we were writing in PIR before but with Perl 6 implementations this time. Strangely enough, they're much nicer to look at. :-)

Thanks to Vienna.pm for sponsoring this work. I'm now done with catching up the Rakudo days I didn't do in September while wandering around Asia, so now it's into the ones I didn't do in October. Given how much there is to do, I'm glad I've had a nice store of them to draw on at this point! :-)

I've spent most of my waking hours today (and a bit of yesterday) starting to build things out on top of the metamodel foundations in Rakudo's ng branch. It's feeling much cleaner that what we had before, and I've not found anywhere yet where it's feeling like I'm having to stick magic into the actions that is specific to a certain type of package. In fact, compared to before, the package_def action method is really quite compact and clean. The whole process of constructing a class (or role or grammar) is just a series of method calls on the metaclass.

Here's a list of things that I've got done since the last blog post.

• Got classes inheriting from Any again by default, which took me on a detour into getting the add_parent method of the metaclass working. We can't quite do inheritance again yet though - that needs traits to be completed too.
• Added handling of the grammar package declarator back in. Now the "inherit from Grammar by default and not Any" stuff is just done by us having a metaclass for grammars - GrammarHOW - that subclasses the metaclass for classes - ClassHOW. It simply overrides the compose method (what we call when we're finished defining a package) and checks if there are any explicit parents, and if not adds Grammar as a parent, then delegates up to the superclass to do the rest of the work.
• Got us parsing trait modifiers and building AST for them. We have protoregexes now, so I could make it just pretty much just like STD. There were also some tweaks to synchronize with. Much of it was just brining code in from the existing actions and re-organizing it a bit.
• One I had those in place, I got attribute accessor generation done. I had wanted traits so I could straight away add the "is rw" variant too. Again, the accessor method is added thorugh the metaclass, and this time it got a proper signature (I suspect there was probably a bug in the previous implementation to be found - maybe even a ticket - over this).
• In doing the above, I realized that I needed to sort out handling of the invocant. Before, we were having Parrot handle it for us, which meant it was handled out of band with respect to the signature binder. In ng we just handle it like any other parameter, apart from we also make it available through "self" (or only make it available through self if the invocant is not specifically requested). This fixes the "can't put where clauses on the invocant" issue that came up a while back - now (in theory at least - didn't test it) you'll be able to write a bunch of multis that dispatch based on constraints on the invocant.
• I started preparing to put roles - parametric ones too - back in place, again built around the metamodel approach. I'm hoping things get cleaner again as a result of that.
• Helped Patrick with working out why compilation is so painfully slow. I timed all of the stages, and it turns out - at least on my box - that we're spending about 10/11ths of the time in the very final stage, turning POST (a tree representing the Parrot opcodes) to PIR. Since that just walks a tree and builds up a string, that's all rather strange. pmichaud++ is investigating.

Basically, my aim is to get us able to start bringing the Perl 6 setting back as soon as possible. Today Patrick did the infrastructural work for that, which was a great start. I was close to us having inheritance working by writing a trait modifier in there, but then realized that while lexical subs now work great (like, way cleaner than in master), package ones don't. Fail. Ah well, it's 3am and I need sleep. Thanks to Vienna.pm for sponsoring this chunk of work.

It's taken me pretty much a whole Rakudo day to figure out how to go about the package declarator support in the ng branch, but I think it's been worth it. The result is not only a design, but some initial code that starts to re-build our classes and modules support in terms of it.

There are a couple of big things to take away from this. The first is that we're going to have the vast majority of things in place for custom meta-classes when the ng branch merges. This is something we were rather more distant from in master, and something that people were hoping we'd get in place by Rakudo *, so I'm glad that we're going to be getting most of the way there on this. The really big deal here is that we're getting rid of a lot of stuff where things "just worked somehow" and re-building it all on top of calls to the meta-class. We're re-building how stuff happens with the new grammar and actions anyway, so it is a fitting time to get it in place.

So what are your options if you want to write a custom metaclass? First, you go and write the class - possibly subclassing one of the existing built-in metaclasses if you just want to do some small customization (for example, I expect GrammarHOW, the metaclass for grammar packages, will just be a very simple subclass of ClassHOW that at class composition time checks if we have a parent and if not makes Grammar the default parent rather than Any, then delegates to the super class). Second, you declare a sub-language and introduce a new package declarator to the grammar; if we want to support "controller" we'd add something a rule to our sub-language like:

token package_declarator:sym<controller> {
    :my $*PKGDECL := 'controller';
    <sym> <package_def>
}


Note that you're actually adding a new type of package to the language here that will be associated with your metaclass. So how do we make this association? There's a context variable %*HOW which contains the mapping from the value set in $*PKGDECL to the name of the metaclass to use. You'll notice this means that we could actually just want our controller keyword for documentation, and just map it straight through to ClassHOW, and not write a metaclass, or we can associate multiple package declarators with the same metaclass.

While this covers the common cases, there's a few times where we need to do some slightly different code generation in terms of different packages. There's some hooks for this too, and while those will not be spec, but rather Rakudo specific, it does mean that the overall implementation will get a lot cleaner, with the Actions.pm file that maps parse tree to abstract syntax tree now not having to know the details of different types of package.

Already it feels a lot cleaner with the few bits that are in place so far, and I think as we start to build out on top of this, it's going to lead to something that overall is a lot less magical, and a lot more maintainable and extensible, than what we had before. All of which make a pause for thought, rather than a charge into the code, very much worthwhile. Thanks to Vienna.pm for making it possible for me to take the time to do these things. :-)

"5. trust but verify" - some time ago I've promised to do blog series and a lot of water went down the river since then so it's really time to full fill the promise.

Why starting with part 5? As there was just one comment, from andy.sh that he likes the $title, on the schedule announcement, I assume it is the most interesting one. :-)

All (most?) CPAN authors are writing tests. Tests are cool, let us sleep well, let us discover "oh I forgot" thinks.

While code is once written and remains that way for a while, most pages these days are generated on the fly to put personalized information, banners or what ever fancy shiny stuff. This may make the testing a bit more difficult. Having the pages statically generated allows to easily test and most important validate pages still on dev system.

Let's have a look at vxml script. It will validate any xml file or a folder with .html, .xml, .rdf files using XML::LibXML for validation. In addition all internal links (a href, img src) in HTML files are extracted and tested if their target files exists. The output of testing is TAP. What else will be better if TAP can test anything? ;-).

While ba.pm.org can be generated statically some pages can not, especially the once requiring users to login. Lot of them have a high load and testing every request will kill (already loaded) machines. One technique is to take randomly only every Xth request and test that one as the part of response to the client. When put to PerlCleanupHandler than it has no effect on user experience.

I wanted to get a little rest and seeing friends in this weekend alongside helping move ng along - that is, the branch where we're re-building Rakudo atop of the new regex engine. Thus I took a Rakudo day and split it up over the two days, yesterday and today, so I could get a nice combination of work and play. Here's some of what I've been up to; I expect Patrick will blog later on today some of the outstanding work he has been doing too.

I guess the work we've done over this weekend could be divided into two overlapping tracks. Patrick has taken on a lot of the language fundamentals and had a key focus on us being able to run Test.pm again, which will open up the rest of the sepctest suite to us. It's currently looking fairly likely that we'll reach that milestone within the next 24 hours, which is amazing progress. I've also been doing some things that will help us on the way to that, but my focus has on getting some key infrastructure in again so we can soon start bringing parts of the Perl 6 setting back into play.

One of the things I had to get back in place was type name handling, so we can differentiate our types from our other names. That was a lot neater this time, since it could just go in much more STD-ish as an assertion - written in NQP rather than PIR (there's a lot of this now). After that, it was easy to get typed signatures parsing again. I fixed up our name parsing along the way a bit too - the NQP grammar did something simpler, whereas we needed something a bit more complex for Perl 6.

One of the big changes we've had in from the start - in order to bring ourselves in line with the spec - is that subs are lexically scoped rather than package scoped by default. After some pondering, I realized that we could handle lexical multis in a far, far nicer way than we had been doing in the past, so I got that implemented. In fact, I'm now expecting I can follow the same pattern for methods too. It's a lot, lot cleaner than what we were doing before, and additionally avoids a lot of start-up reblessing, which was one of our big startup costs before. We really are taking the opportunity to apply our past experience and the new grammar engine features to build the grammars actions up in a much neater way, and I'm really happy with the results so far.

One of the things Patrick has been working to get in place is the Parcel data structure. Along with that, we've been reshaping our approach to issues like flattening. I've mostly been involved with that at the level of discussing the approach with Patrick, and he's led the implementation charge on it. Today he hit on the need for a small tweak to the method dispatcher, which was familiar ground for me, so I got it patched up. A silly fail on my part later, it was all working rather nicely. Finally, I got some pieces of roles patched back in to the new build.

One thing I've been preparing for is getting our class and role declaration support back in place. I'm planning to approach it in a rather different way than we have been up until now, the motivation partly being neater and more maintainable code, but also getting us on track to handle custom meta-classes. I'm not saying we'll actually have those when the ng branch lands, but equally I'm aiming for us to be a whole bunch closer. The other big difference in approach here is that I'm aiming for us to be able to keep a lot of the package information trivially introspectable during the building up of the class or role, which will make some things much easier and better encapsulated. Further, we can also keep that information around for assisting a future optimizer/type checker. (As an aside, I've been arranging signature things in a similar way during the course of my signatures grant. I guess the general principle is that while PAST is pretty much sufficient for expressing the semantics of the program, sometimes it's desirable to keep some higher level information around for entities that don't have a specific type of PAST node dedicated to them - mostly because languages tend to care about them in very different ways, so they don't belong in PAST anyway.)

Thanks to Vienna.pm for funding my work at this important stage in Rakudo's development.

Recently Patrick wrote about some major upcoming changes to Rakudo, which will be a huge step along the way towards Rakudo *. If you didn't read Patrick's post, I suggest you do so first and then come back to mine - it gives a lot of detail on why we're doing what we're doing at the moment. Anyway, after much hard work - on Patrick's part getting nqp-rx ready and on my part getting us building and running on top of the updated Parrot Calling Conventions - today we were finally ready to start on step 7 of the plan. Essentially, that involves a complete re-do of Rakudo's grammar and actions.

nqp-rx was already in a pretty awesome state at the start of the day. It was missing a make install target, which is the first thing I worked on. With that in place, I was curious to see if it could build the current Rakudo NQP files. Given that it was a ground-up re-implementation of NQP on top of a new implementation of the regex engine, which had changed in many ways, I was really quite impressed how little effort it took to build Rakudo's NQP parts on top of it and have us make it through the test suite mostly passing. This wasn't actually the goal - it was well beyond what Patrick and I had guessed we would manage - but it did shake out a couple of missing features in nqp-rx, which we were able to add quickly between us, as well as a bug, which I fixed. It was nice to have them out of the way early on, before we dug into really using nqp-rx to re-build Rakudo on top of.

With those fixes in place, Patrick then ripped a bunch of stuff out of the Rakudo makefile and added the NQP grammar and actions as a base for us to start building up from again. This means we've gone back to having something that won't even run the sanity tests completely yet. However, what's there so far is also far, far closer to STD than we were before, using protoregexes in various places as well as contextual variable declarations inside regexes and an operator precedence parser alike the one from STD. Certainly, the bits that I have put back in so far have gone in far, far cleaner than they appear in current Rakudo.

Unlike NQP, which just uses Parrot's default signature binder, Rakudo running on the new grammar just from today's efforts is already switched over to building Perl 6 signatures and is using the signature binder I've been developing as part of my current Hague Grant. Multi-dispatch and operator parsing should hopefully be landing tomorrow - since this is just a re-write of the way we parse and build up the AST, rather than all of the other guts and the setting - we're being able to put back major features in a short time-frame. All of that said, we're not shying away from using this as an opportunity to deal with other a couple of other refactors we've been wanting to do for a while along the way. Generally, they are fairly fundemental things that would have been quite a pain to deal with individually, and are easy to get in as assumptions from early on as we build things up again.

This is the first Rakudo day I've done in a while - I was wandering around Asia for a month, and then have been focused on my grant. That means I've got a nice little stash of Rakudo days to spend during the next couple of weeks, which will be great in getting Rakudo back on its feet, more featureful and stable than before, and with a grammar much closer to STD. Thanks to Vienna.pm for funding Rakudo Days, and I'll keep you posted on how things are progressing in the ng branch. :-)

One of my Hague Grant tasks was to get a signature introspection interface into the specification and get Rakudo conforming to it. While there may still be some minor tweaks to come, this part is essentially done now. You can read the spec additions in S06.

First off, you can call .signature on any block to get hold of its signature object - an instance of the Signature classs. Calling .params on a Signature object will in turn give you a List of Parameter objects, which describe each of the parameters specified in the signature. We are able to introspect the types, the names, whether the parameter is optional, get a closure that returns any default value and more. Here's an example.

sub example(Int $x, Str $y?) { }
my $sig = &example.signature;
for $sig.params -> $param {
    say "Name: {$param.name}, Type: {$param.type}, Optional: {$param.optional}";
}


This gives the output:

Name: $x, Type: Int(), Optional: 0
Name: $y, Type: Str(), Optional: 1

To make sure that all of the information was really there and accessible, I then went and re-implemented the .perl method on a Signature in Perl 6 in the setting, using the Parameter objects. The new version lacked several of the bugs that the previous version had, which cleared up a few RT tickets. And finally, moritz++ wrote a bunch of spectests for signature introspection, following the new spec.

I've finally packaged the Pexeso game as a CPAN application: Game::Pexeso. Now there are no excuses for not playing it!

The source code is available on github: pexeso git repo.

Remember that if you want your face to be in the game that you have to create a CPAN account!

Benjamin Zander on music and passion

In case of Perl, you ain't seen nothing yet!

Myslím, že komentáre to presne všetko vystihujú takže nieje treba blog entry

Since I got back from my travels in Asia - actually, as soon as I'd got a good night's sleep after the long flight - I've been busily hacking away on my latest Hague Grant. In fact, I've done rather little else. After a couple of weeks of work - with many late nights debugging - I've finally reached the first major milestone of the grant: the new signature binder has landed.

So what is a signature binder anyway? It's the thing that takes the signature on a block (or some more interesting type of code object, such as a sub or a method) along with the arguments that it was invoked with and - if possible - binds them against the signature, such that the arguments passed end up in the correct variables. It sounds relatively simple, and in some senses it is. However, Perl 6 signatures offer a lot of powerful features, making things rather less trivial.

If you've been using Rakudo before now, you'll probably have been writing things with signatures and passing arguments along to them quite happily, and be wondering, "why a new binder?" It's a fair enough question, and the simple answer is because we'd reached the point where the approach Rakudo had taken so far had gone as far as we could sensibly take it. We've often used the defaults provided by Parrot in the past to allow us to make progress on developing a useful compiler; we did so with multiple dispatch, method dispatch, objects, roles and so forth. The approach has paid off: people are writing cool stuff with Rakudo today (I played a board game online with masak++ earlier today; the game itself was implemented in Perl 6, used the Web.pm framework and was being served by a web server written in Perl 6 too). In the meantime, we've been replacing those Parrot defaults with things that get the more subtle and/or powerful parts of the Perl 6 specification correct, and usually that do so in a more efficient manner.

The main things that prompted development of a custom binder were:

• While Parrot could bind the arguments to registers, we then had to follow that up with code to put those into lexical variables. We then had to make a second pass over the arguments to do type checks and enforce context. This was inefficient - we had to do a lot of extra lookups as well as two passes over all of the arguments. It was really also quite bad if we were just binding the signature because we had a multi-dispatch candidate that needed a bindability check: we'd have already got a lot of the work done before we could figure out that actually, the first argument had a constraint on it that immediately ruled it out.
• Perl 6 allows binding of named parameters to positional variables - that is, even positional variables can be passed as named parameters too. Parrot didn't support this, and was going to be really quite hard to layer onto the existing model we had. Doing it efficiently was fairly out of the question. Getting Parrot to support it was also an option, but bulking up the VM for a feature only one language really wants is not really optimal.
• If multi-dispatch had already decided that a candidate's types matched those of the arguments being passed, there wasn't a good way to avoid the argument type checks. At the same time, we had to be sure to enforce them if a multi candidate was somehow invoked without going through the multi-dispatcher.
• If multi-dispatch depended on a bindability check, we'd like to just keep the candidate around, and not re-bind everything. There wasn't an easy way to do that either.
• Nor was there a particularly easy way to implement nested signatures. These allow powerful functional-style matching as well as deep data structure unwrapping.
• Signature binding in Perl 6 isn't just done when calling a routine. For example, you can use a signature to bind and unpack return arguments too. These return unpack signatures can be just as complex as those used when calling a routine. Heck, you can even have a signature literal and just smart-match against it to attempt binding. We needed something that was going to support these use cases too, which argued against having Parrot doing half the work and us patching it up later.

The new signature binder I have merged into master this evening either supports or is designed with later supporting all of these needs in mind. It handles binding named arguments to positionals right out of the box, for example. So now if you declare a sub:

sub plot($x, $y) { }


Then you can call it as any of:

plot(4,2);
plot(x => 4, y => 2);
plot(4, y => 2);
plot(2, x => 4);
plot(y => 2, x => 4);


Under the new signature binder, it was also trivial to add the code to avoid re-doing the type checks for a multi-dispatch candidate. While I didn't yet add the "don't re-bind when we did already passed a bindability check" improvement, that's mostly because it requires a slightly less trivial refactor to the multi-dispatcher - there's some stuff stubbed in to support it when I get that done though. And also there's a stub for nested signatures, which will be coming along later. Those are going to be way cool.

A couple of other things came up during the refactor that also led to some on-the-side bonus improvements. The most immediately useful one is that lexical variables declared outside of packages are now visible inside them - a source of much past frustration.

my $dips = 0;

class Chip {
    method dip() {
        $dips++;
    }
}

my @chips = Chip.new, Chip.new, Chip.new;
@chips>>.dip for 1..10;

say $dips; # 30


I also fixed the bug with junction auto-threading and for loops, so if the signature of your for loop declares a non-junctional type then you'll get the body run multiple times, once for each thingy in the junction. Also, signatures can now be written as literals, without getting weird errors.

Finally, I mentioned that one goal was getting better performance. I've not yet started to optimize the new binder - yes, it has some built-in by design performance improvements, but I didn't really dig in to the real effort of making it faster yet. Even so, the gains are notable. The figures below are the percentage of time it now takes to run some micro-benchmarks on specific language constructs compared to before I started working on the signature and binding improvements. So for example, 10,000 method dispatches now take about 26% of the time they used to.

Startup: 76%
10,000 sub dispatches: 45%
10,000 multi dispatches: 35%
10,000 method dispatches: 26%
10,000 multi-method dispatches: 20%
10,000 operator dispatches: 33%
postfix:<++> 10,000 times: 57%


These figures sure don't mean that Rakudo is fast yet - we've a long way to go until I'd say that - but I think for the "we didn't start optimizing the new binder yet" phase, these are an encouraging start.

More as the grant progresses. In the meantime, enjoy the improvements. :-)

Last Thursday we have had a Bratislava.pm meeting with two topics.

1st one, thanks to Andrew Shitow, was about code generation or if you want compiling for compilers. He demonstrated this on a finding primes with Perl6 program. It was nice and you can still enjoy this talk on many places that Andrew has on his this year's roadmap. It is an example of reusability, the beauty of code generation and a showcase of a way which to try when doing optimizations. It's also a really good example how we, Perl hackers, want to always do thinks our own way ;-) The speed is nice, but not always and the Rakudo project should not get tied with premature optimization at this stage.

2nd talk, thanks to Emmanuel Rodriguez, was about a game made with CPAN authors - Pexeso. Most of Perl developers don't like to do graphics, JavaScript, web design and graphics effects. Seeing 3D OpenGL effects animating, rotating, zooming in and out done in couple of lines of Perl code looked impressive. And showing this to someone that is asking "why Perl?" might do the trick of convincing.

effect++ # is selling

Chromatic as a good post on Declarations and Scope. I'm glad to see that I'm not the only one that follows this best practice. Which by the way I was surprised to not see in Damian Conway's Perl Best Practices.

What I find the most strange is that I get constantly asked why I'm wrapping all my scripts into functions and that I don't have just plain executable code from the beginning. One of my posts in StackOverflow raised a lot of critics just by following this simple best practice: Scope bashing.

I think that all conscious perl programmers always employ use strict; and use warnigns. So I find that localizing all our code in scoped blocks (let it be a do {};, a function or even a simple code block {}) is just too practical to be overlooked. I don't think that doing this adds too much noise nor distractions to the original source code. Yet the benefits gain are huge!

Not only does this technique protects your variables from becoming global but it also helps when the code needs to be refactored. There's nothing more annoying that having a monolithic script without functions that can't be refactored easily because the code assumes each single variable to be a global!

V prípade search.google.com sú dve miesta na diskusiu. Prvé je, že pri zobrazených výsledkoch vyhľadávania sa zobrazujú kratučké úryvky zo stránok. Druhé je Google cache, kde sa dá pozrieť obsah pôvodnej stránky v určitom čase keď práve Google prišiel na návštevu. Obe zobrazujú cudzí obsah pod doménou vyhľadávača.

Ako sú na tom RSS feed agregátory? Napríklad pre ba.pm.org som vytvoril planétu. Zrazu sa na tej stránke zobrazujú príspevky z "cudzích" blogov a keď má ba.pm.org vyššiu váhu vo vyhľadávačoch, je veľmi pravdepodobné, že sa vo výsledkoch vyhľadávania ocitne planéta na vyššom mieste ako samotný originálny blog. V tomto prípade je to so súhlasom a vedomím majiteľov blogov, ale čo takto zagregovať české a slovenské stránky o Linuxe na planéte? Čo tak zagregovať rôzne periodiká? Čo tak ešte "zabezpečiť" to že sa zobrazí celý článok a nielen úryvok? Je RSS abstract legálne zobraziteľný na cudzej stránke? Je celý článok nelegálny? Či v prípade Googlu je to tak, že povie že "sa to robí" automaticky a keď príde sťažnosť, tak odstráni "nelegálny content", ktorý sa zobrazuje na ich stránkach?

Ako je na tom translate.google.com? Zobrazuje cudzie preložené stránky. Môžem zobrať cnn.com, "automaticky" preložiť do slovenčiny a zobrazovať u seba na stránke?

Príklad Googlu je len príklad. Samozrejme je na nete nepreberné množstvo vyhľadávačov, agregátorov, feedreaderov, translatorov a všetci sme radi, že môžeme využívať ich služby. Ale nieje to len tikajúca bomba pre firmy čo sú za nimi? Viem si predstaviť, že v krajine neobmedzených možností, pri dobre nastražených obrázkových banneroch s výstrahou o copyrightovaných materiáloch, by mohli vyhľadávače dostať pokutu za opätovné porušovanie autorských práv a dostať nariadenie na kontrolu všetkého obsahu ktorý indexujú.

15 Október 2009 18:00

Tentoraz sme mali špeciálneho hosťa - Andrew Shitow, ktorý mal prezentáciu "Perl 6 compiler". Druhá prezentácia bola od Emmanuela s názvom "Pexeso". Skončili sme (asi už pomaly tradične) v Bastione, kde sme si užili dobré pivo, dobré jedlo a free WiFi.

It has a long time agon since I've posted here. Until YAPC::EU (for 3+ months) I'he tried to keep up with one post per week even it was not easy. The Iron Man competition (challenge?) has a good intention to make a lot of noise, but this can also slip to become an low-quality noise. On the other hand, not every post has to be crowded with information. Does it? After all it's just a blog. Or? Still it takes time and it is suppose to take time every week. Hopefully it's a good investment (payback?) to Perl community.

Another, or different kin, Iron Man issue is that it aims for English blog posts. Yes I know that there are also Russian, Japanese blogs, but those are minor and look strange, in the middle of the English flood. Still blogging (or doing noise) in local language can be much more useful for the purpose or bringing (enlightening) to Perl new people than writing in English where the information flow is plentiful. The same reasoning as for translating perlpod.

Jet another reason was that I was busy doing different things than blogging. Actually working :-) besides the day job, I did an experiment to bring FHS to Perl which is not ready to blog about. Or should we blog also about things that are a total drift to unknown? Than when it turns out to be "no so great" (read stupid), the internet will never forget... I've also managed to install a MT4 on my server (which was not without a, still unresolved, issue) and created not one but two blogs! One for things that are not sane and one for more serious stuff. The main reason, among others, for not using use.perl.org is that there is no way to post entries with images. Still I'll post my Perl blog entries here, but I'll post different not-just-Perl related there. After all this blog is registered to the Iron Man competition not those. :-)

The photos from my month-long trip to Japan and South Korea are now on the site. Check them out, and enjoy!

Also, I've done a few small site improvements, including switching to a different and slightly more user-friendly photo browsing thingy (and moving to JQuery along the way). I like the way it makes it obvious there are lots of photos to browse through, and I'm also rather happy it fixed the bug on the per-location pages. Also, the list of countries under the Browse now uses the space on the page better than just a boring bullet list.

I'm just back from my yearly autumn backpacking trip, and once again I took in a few Perl things amongst my vacation. I attended YAPC::Asia for the first time, and gave a couple of talks; you may be interested to see the slides. I think they were both quite well received, though one of them had a couple of bugs. I muchly enjoyed staying with the Pauleys - thanks for the hospitality...and introducing me to tonkatsu!

Other than Japan, I also visited South Korea. I gave a talk at Seoul.pm, and many of the Perl mongers there were kind enough to take time out to show me around and have dinner and beers with me, which was really great. As well as great Korean hospitality, I can't not mention that Korean food is SO good - I'm missing it lots already.

So, it was a great time (thanks to everyone who made it so - too many to mention here), and now I'm back, re-energized and ready to dig back into hacking on Rakudo. In fact, this is my last real vacation before Rakudo *, so I made the most of it. The next few months are going to be a serious amount of work - but never fear, I'm hacking on it already. :-)

My signatures Hague Grant got approved. I've started on that already, and I'll try and blog some progress in the next few days (for now I've done nothing more exciting than some refactors in preparation for the changes that will really make a difference...but with my current uncommitted bits they seem to shave roughly 10% off Rakudo startup time anyway, and that's before I begin the changes I expect to make more of a difference.) Also, during a Rakudo day before my trip and some hacking at YAPC::Asia, Blizkost made some more progress. I'll blog about that soon too. :-)

OK, back to hunting down bugs in my latest changes...

I use a MacBook as my main computer. I work on that laptop and do all my random hacking on it as well.

What might seem odd is that I run Linux on that hardware. Installing Linux there and getting it to work properly requires a lot of work and sacrifice: the web cam doesn't work and the OS sees a single CPU. Otherwise all is working fine and if the proper software (fan control) is installed the laptop won't overheat. I can even play an OpenGL game in Perl!

One thing that I have noticed since I work on this MacBook is how clumsy I can be while typing. I would always hit the huge track pad and destroy my own work! OS X has a feature to disable the touch pad when a mouse is plugged and I would like to have the same feature in Linux. I think that the next version of Gnome will have this feature, but I want something like that now.

Luckily in Linux we have all the tools to implement this. What's missing is something to put all the pieces together, something like a glue language. So I wrote a small Perl script that can toggle the touch pad for me: toggle-touchpad. I binded the script to a keyboard combination through my window's manager keybindings and I can now enable/disable the touch pad at will!

This script will only work if the synaptic touch pad is configured to use shared memory. This means that the following option has to be set in the synaptic's driver section of your X11 configuration file:

Section "InputDevice"
        Identifier      "Synaptics Touchpad"
        Driver          "synaptics"
        Option          "SendCoreEvents"        "true"
        Option          "Device"                "/dev/psaux"
        Option          "Protocol"              "auto-dev"
        Option          "HorizScrollDelta"      "0"

        # Use shared memory
        SHMConfig       "On"
EndSection

Once the driver is configured to use shared memory the touch pad settings can be modified at runtime without needing to restart the X server. The program synclient can be used for playing around with the touch pad's settings. Once that done disabling the touch pad is as simple as doing:

synclient touchpadoff=1

Voila!

Nejaký ten čas už ubehol od YAPC::EU::2009 a stale (až doteraz) som sa nedostal k tomu napísať čo bolo k videniu. Tento rok to bol po tretí krát čo som sa zúčastnil na YAPC - Viedeň, Kopenhágen a teraz Lisabon. Bol dobre, bola zábava a prišlo veľa ľudí, konkrétne 328 čo sa zaregistrovali a zaplatili.

Čo je to YAPC? Yet Another Perl Conference. Usporiadava sa raz ročne na rôznych svetadieloch. Ten náš je Európa, YAPC::EU je najväčšia každoročná "stretávka" Perl programátorov z Európy. Je to naozaj zážitok vidieť na vlastné oči ľudí ktorých poznáme len z CPAN-u alebo IRC a môcť s nimi prehodiť pár slov a zistiť že sú to ľudia z mäsa a kostí.

Čo bolo k videniu?

Moja prvá prezentácia na ktorej som bol bola o AI::CBR (Darko Obradovic). Jeho modul sa dá použiť na pridanie trochu inteligencie napríklad do vyhľadávania, alebo výberu vhodných kandidátov - čo ponúknuť. Príkladom bol výber dovolenky na základe požiadaviek budúceho dovolenkára. Páčilo sa mi že to bola veľmi praktická prednáška.

Tohtoročný "topic" konferencie bol 'Corporate Perl'. Dalo sa vidieť veľa prezentácií o tom ako sa Perl používa v korporátnom prostredí a s čím musí bojovať aby prežil, keďže jediný korporátne uznávaný jazyk je Java, tak ako jediná korporátne uznávaná databáza je Oracle.

Z nových, alebo horúcich vecí ktoré sa dali vidieť boli:

• MooseX:Declare (pdcawley)
• KiokuDB (nothingmuch)
• Regexp::Gramars (Damian)
• Perl 5.10.1 (rgs)

Čo ešte? Že sa dá rozpoznávať reč (Thomas Netousek), ako písať reusable kód - prvé pravidlo nepísať (domm), ako na diaľku ovládať dobrovoľníkov Karen) a že to nieje až tak zlé mať vlastnú prezentáciu na YAPC...

Čerstvo (od včera) sú dostupné štatistiky od účastníkov - http://yapc-surveys.org/html/ye2009-survey.html