Perl needs modern garbage collection

Chromatic just wrote a list of important features that Perl 5 needs. While I agree with most of the listed ones (and in fact contributed to the new p5-mop proposal during the recent Hackathon), I found one feature curiously missing.

I mean, JWZ pointed this out in 1998; Perl garbage collection is a bad joke. That was 14 years ago, and the situation is the same. It is trivial to create a circular reference and trip it up. Especially when you are doing evented code where callbacks are common, it is quite easy to close over some variable and create a leak. Languages like C#, Ruby and Java has this sorted already with variants of mark and sweep-based systems, Python has built in cycle detectors in their ref count implementation, and even Objective-C manages to detect cycles fairly well with their new compile-time automated reference counting. 
Don’t worry so much about adding sugar to the syntax. This is a feature Perl really needs. 

Moving to Moose Hackathon 2012

This week, my excellent Perl Mongers group Oslo.pm, led by the excellent Salve,  has arranged an event we called the Moving to Moose Hackathon 2012. The purpose of this event was to promote the adoption of a MOP (Meta Object Protocol) in Perl development. To this effect, we had two groups, the Perl RDF community, looking to adopt moose in their modules, and Stevan Little and his merry gang of p5-mop developers, looking to create a proposal for a MOP in the Perl core itself, to replace the venerable blessed hash object model.

 
Unfortunately due to the arrival of baby Milla in June, I was unable to attend the entire event, which started on saturday. Thus I missed the walk to Pulpit Rock (did I mention the event was smack in the middle of the Norwegian fjords?) Luckily I’ve been there before (see pic on the right :-). I arrived early Tuesday morning by the night train. On the way there, I re-read the proposal for the p5-mop
 
Pulpit Rock
 
Since I’m not a mad hatter scientist like Yuval and Jesse, and don’t know the Moose MOP that well, I concentrated my efforts on tooling and real world triage of the prototype. For me, the most exciting idea of the proposal is adding first class ‘method’, ‘has’ and ‘class’ keywords, so that you can declare Perl classes like this:
 
    class Cat (extends => Animals) {
      has $claws;
      method meow { … }
    }
 
Since I’m an avid TextMate fan (specially since the Open Source release this fall), I started by extending the TM2 syntax to support these new keywords. This means getting proper highlighting, as well as easy navigation in classes and methods. You can find my fork of the official Perl syntax highlighter here.
 
I then started work on porting a few Mojo base classes to the new syntax. Being one of the Mojolicious core developers, I know these classes rather well, and they have the advantage of being light on dependencies and optimized for easy porting to Perl6, as well as having comprehensive test suites. This made them an ideal target for trying out features of the prototype. 
 
Of course I met some hardship underways. The biggest issue for me during the port was the lack of BUILDARGS, a class method to massage the constructor parameters into a hash, but all in all the experience was quite educational. I also found some small points of improvement in the specifications during my attempts, and submitted a simple doc patch. 
 
Together with Jan Henning, I also looked into the feasibilty of supporting overloading in the new p5-mop classes, and Jan Henning ended up writing a new meta class to support this. I believe this should be refactored into a meta role when the mop has been updated with support for that.
 
In the period that I was there, the main p5-mop developers struggled quite a bit with an issue in the dispatching that was giving bizarre errors and was really hard to track down. Unfortunately, this slowed down development, as we were unable to start using the new two-phase bootstrap code which  would allow us much easier development of the meta classes themself. 
 
However, I was really excited about the discussions about the new ‘meta’ keyword on the last night of the hackathon to allow meta defintions (and thus class methods, and roles) in the class defintions themselves.  I quite look forward to the updated prototype, and hope to resume my port as soon as BUILDARGS support has landed.
 
I think the crucial question now is if we can manage to maintain velocity in the development of the p5-mop prototype after this hackathon. I truly hope we can start seeing real world usage of it soon. This is the best way to figure out gotchas and problems with the specification before it lands in the core.

Debugging LWP with mitmproxy

Are you using an LWP app, and trying to debug it? My personal preferences is using mitmproxy.

To get LWP to use mitmproxy, set the following ENV variables:

PERL_LWP_ENV_PROXY=1 HTTPS_PROXY=’http://localhost:8080/’ ./script/myapp

Note, this also works for apps using Mojo::UserAgent, except you don’t need the first ENV variable.

Don’t animate scrollTo of the body on iOS.

Animate body.offsetTop and body.offsetLeft works great on the desktop, but  is hugely buggy on MobileSafari. Instead, make a viewport div that fills the screen, and animate the offset on that.

I hope this helps someone, as I spent 3 hours figuring it out.

Makers

You can start making something in seconds.
One simple idea is all you need before your brain
automatically explores problems, solutions, and dreams.
Turning that idea into something tangible and wonderful is harder.
You need structure, strategies, people, hard work.

The software world is young and we are still figuring out the most basic processes of the craft. For instance, we tend to label ourself architects or designers, inspired by people who build houses or work in mass production.

Designers tend to paint pictures, while engineers tend to make diagrams describing what they want to make. Both of these approaches are fundamentally flawed in software. They make a lot of sense in the trades that inspired them, where the cost of change is high and getting it right the first time is essential. Making software is pretty much the opposite.

With software it’s so easy to reiterate that there’s no need to choose between ideas on the drawing board. You can simply build it and see for yourself how it would work. As long as you always make the simplest possible version, you can quickly verify if it’s a good idea or not, and it can be rather efficient too.

I’m not saying that you shouldn’t use Photoshop or OmniGraffle in the process of making. They are useful tools for making your software better. Refining it, making sure they play well with others. However, I believe that a lot of the
‘design processes’ that go on now are flawed.

In fact, I would like to remove all labels. Take a big magic marker, cross out ‘engineer’ or ‘designer’, and write one word on all of them:

MAKER

I sometimes hear people say ‘everything is design’. I do agree that everyone who is involved in making software needs to care about what it does, how it works, how it feels, and so on. The problem in my mind is that this definition
makes ‘design’ too generic.

It also tends to exclude programmers and gives the impression that they don’t need to care about the look and behaviour of the end result. In my experience, this pattern leads to massive amounts of suck.

Stop thinking about programmers and designers. We’re all makers, so don’t feel limited by such a poorly placed label. You’re job is to make the software. I don’t care what hats you wear as long as you’re contributing. We should always strive to learn more skills, to become better makers.

People with a classic IT background should learn more about writing, colors and traditional design principles. Those who possess these skills should learn more about markup, CSS, Interface Builder, or maintaining resources in version control systems and project files. The more you know about how software is made, the better you can help making it great.

This does not mean that I advocate design by committee. I do believe all software needs a director; one who maintains the vision of what we are making, and who instructs and directs the rest of the team. This person is ultimately
responsible for the shape of the product. But without good makers, that person is doomed to fail.

Let us all become better makers.

Onion browser – TOR on IOS

The Onion Router is a internet project that aims to anonymize your traffic by routing it through a darknet with various exit points to the Internet. Normally you would have to install a browser proxy on your machine to access TOR, but now there’s a browser available for the iPad and iPhone.

Of course, I had to test it by checking out the Silk Road, a much publicized “Amazon of illegal drugs” that only exists on the TOR network.

Great Tmux config.

I`ve been working a bit on the iPad using Prompt, tmux and vim with a bluetooth keyboard, and this .tmux.conf is essential for efficient work.

 

 

 

 

New Oslo Skyline & Opera

Oslo Skyline

 

A Mojolicious 2011.

A new year is upon us, and I figured this would be good time to take a look at the improvements in the Mojolicious framework in the last year. There has been a dazzling number of releases, 122 in fact, including the current release, 2.42.

Some of the releases were mere bugfix releases, with nothing noteworthy to add, but I’ll try going through the major releases in the last year. When this year started, we already had a robust MVC Web framework, and through the year you will note that a lot of the work has gone into building a first class real time web framework. 2010 ended with 1.0, codename Snow Flake, released 26th of december 2010. 1.01 fixed a couple of bugs, and added TLS Authentication.

The next major release, code name “Smiling Cat Face With Heart-Shaped Eyes”, was released on 2011-02-14. This release deprecated wildcard route names in favor of automatically generated default names for all routes. There were several new experimental features, including a more Moose-like attribute generator, on_start attribute for Mojo::Client, support for setting the user agent, mode-specific built-in templates to easily add a production error template, and CSS selectors in the ‘get’ command. There were also a new image helper, and support for session cookies.

The next major change was in 1.13, which deprecated the ailing Mojo::Client for a much improved Mojo::UserAgent, which handled async requests in a much more coherent fashion.There were also features added like IPV6 support and the default Fail Raptor added in 1.17 and argument localization in 1.18 before 1.3 which was released the 5th of may1.4.

1.3 was codenamed “Tropical Drink”, and tried to deprecate 5.8 support, 5.8 no longer being supported by the Perl core developers, and having serious security issues. However, due to RedHat users with old Perls, we had to temporarily revert that decision, before finally removing 5.8 support in release 2.0; Mojo::Base was also updated to enable 5.10 features. This release also added an experimental “before_render” hook and exposed the hooks in Lite apps.

1.4, “Smiling Face With Sunglasses”, followed about a month later, 2nd of june, and contained a major update to the Mojo::DOM parser, adding an ‘append’ method, direct hash access for attributes, and child element accessor, as well as collections. The release also added an ‘eval’ command, improved long poll support and started serializing sessions as JSON, which is more efficient than Storable.

Several minor releases followed, including 1.42 allowing status as an argument to render and 1.44 adding Morbo, the fearsome restarting development server. (DOOOM) this release also added an application mount plugin. 1.47 included a new callback condition as well as a host condition for the routes. 1.53 added format support to Mojo::Log and 1.57 dramatically improved Hypnotoad hot restart, allowing you a hot restart just by running Hypnotoad again, as well as adding a —stop parameter.

1.65 changed the IOLoop to be event based, and added support for using the EV event loop, allowing for great performance and compability with AnyEvent modules. In 1.69, IOLoop::Trigger allowed grouping nonblocking requests easily, and Mojo::DOM added healing support, allowing it to parse most markup that renders in a browser.

To make Mojolicious more RESTish, 1.73 added the experimental respond_to renderer, as well as type detection. 1.78 added a cpanify command and plugin generator to allow easy plugin writing and sharing. 1.80 normalized the casing of plugins, and 1.82 added a grep method to collections, later joined by ‘first’, ‘reverse,’,shuffle’ and ‘sort’.

Web socket testing was added in 1.86, 1.87 added an app command and a ‘t’ helper, and 1.99 adding group support to Lite apps, as well as binary support for web sockets.

All this as well as several minor features, bugfixes and documentation updates adds up to Mojolicious 2.0, code named “Leaf Fluttering In Wind” which was released 17th of october. It also added slice support to collections and completed the transition from callbacks to events. Web socket support was updated to ietf-17.

2.01 followed two days later, adding upgrade and part events, and 2.03 adding new experimental ietf http status codes. 2.10 added a websocket send_frame method and frame event, 2.19 revised the hook system to use events, and 2.27 was a major streamlining of the core IOLoop, deprecating several methods.

2.29 added chained events from the plugin system, and a new around_dispatch hook. 2.35 added etag support to Mojo Headers, and 2.37 marked the change of Mojolicious to being maintained by a core team, adding me(Marcus Ramberg), Glen Hinkle and Abhijit Menon-Sen to the core. This release also worked around a serious memory leak in Perl itself.

2.39 was released just before the holidays, and updated the user agent to use an ‘error’ event, as well as exposing ‘local_address’ and adding a close method to IOLoop Streams. 2.40 was released on the 24th, adding JSON Pointer support, and finally 2.41 was released on the 28th stabilizing many of the experimental features mentioned above, and allowing session expiry to be turned off.

We now believe the real time part of Mojolicious to be as robust as the MVC part, and expect less frequent releases of the framework in 2012. If you want to learn more about the features in Mojolicious, check out our excellent guides.

Happy New Year, and thanks for 2011.

[All the information in this document was extracted from the Mojo Changelog.]

Beautiful Open Source

Earlier today, HP announced that they are open sourcing webOS, the mobile OS that they bought from Palm, inspired by BeOS, which Palm acquired a few years before that. Of course, these news comes as a consequence of HP canning their hardware platform, ending their tablet ambitions in a spectacular fire sale where they lost money on every device sold.

I’ve been a fan of the simplicity and elegance of webOS for a while. I even used BeOS back in it’s day. I didn’t really like the HP devices tho, and for me this is the optimal outcome. Provided that HP choses a liberal license, this means that webOS might actually get some adoption.

I even belive webOS would make a foundation for a nice Linux based desktop OS (Something Linux desperately needs), if provisions were made for a usable keyboard and touchpad multitouch gestures. Some of the leading internet pundits are less optimistic about this move than I am tho. John Gruber of Daring Fireball writes:

I hope I’m wrong, but I think this is just the difference between putting your dog down and letting it free on a distant mountain road.

Matt Gemmel takes it even further:

Want to know what happens when you make an operating system open? The same thing as when you leave your car open: sooner or later, it ends up smelling like a urinal.

Which I find a rather ridicolous notion. Certainly, a lot of Open Source apps were made by neckbeards with little or no design skills. However, WebOS is already very well designed, and even contains a nice style guide for apps. Just look how nice this Open Source twitter client for WebOS looks (phnx):

The distinguished interface style is already there, with gui widgets for app developers to use, which makes it more likely that usable and user friendly apps may be developed by an open source community. From running iusethis.com, I’ve noticed that when there’s already a defined style like on the mac, there’s a better chance of getting well designed open source apps.

Just look at QuickSilver, Cyberduck, Transmission and even Adium, widely used open source mac apps that are far ahead of their equivalent Linux-based apps. Being open source doesn’t have to mean design by comittee. It’s not like closed source is a guarantee of good design either.

What WebOS does need is improved performance, stability, better apis, and wider availability. The first things are absolutely things that we beardy Unix types are quite good at. Obviously Open Sourcing a codebase also means that professionals from several companies contribute, just look at the kind of boost this has given to Webkit. While on the subject of WebKit, the fact that WebOS apps are made using open web technologies is a very good fit for the open source community as well. Some of us that have been developing for the IOS platform are secretly yearning for a equally good open platform. Android is certainly not it.

Hopefully Open Sourcing with a liberal license will help with the last point too. I specially see Chinese cell phone producers as likely to pick up this opportunity, but possibly some of the existing android players as well. I’m even hoping there might be a distribution available for the iPad, and as I mentioned earlier, I am hoping to see webOS on prominent Linux distributions in the near future..

It’s not like this is a big closed source platform that is totally alien to the Open Source community. webOS already runs on linux, and uses a lot of the same open source technology we know and love (just check the open source information in the OS to verify this).

Hopefully HP will allow the current team to steward the OS forward. In my ideal world they would move the project to github and keep the contribution flow through pull requests where the core team is able to maintain a certain level of control.

If this happens, I see a bright future ahead for WebOS.

Copyright © marcus ramberg
nordaaker

Built on Notes Blog Core
Powered by WordPress