London Perl Mongers organises technical meetings every two months. The technical meetings are a chance to find out what has been going on in the Perl community, what techniques people are using and how Perl integrates with other software.
The next technical meeting will be on the 19th February 2009 from 7pm to 9pm (you may arrive from 6.30pm, sign in at the reception) and the theme is "What is Moose and why is it the future?". You have to sign up to attend, see the website.
It will be held at BBC's offices near White City. Many thanks to Peter Edwards, the BBC and everyone involved for allowing us to use this wonderful venue.
To sign up and see more information, please visit:
Computer memory is sadly still finite. Sometimes it's interesting to know how much memory a Perl script might be taking at a particular time. If you install the GTop development headers and library you can use:
use GTop ();
use Number::Bytes::Human qw(format_bytes);
my $gtop = GTop->new;
my $proc_mem = $gtop->proc_mem($$);
my $size = $proc_mem->size;
print format_bytes($size) . "\n";
Which produces something like:
So you can find out that the module you were criticising isn't bloated code after all...
There are many technical groups out there. In London, I go to London.pm (Perl) meetings, LRUG (Ruby) meetings, DJUGL (Django and Python) meetings and various other one-off meetings. I'm pretty much the only person I know that does this (Hi Paul and Tom!). Why aren't you? All computer languages are essentially the same - with only minor differences in syntax and culture. Why not go to other meetings next month? You'll meet some new people, you will learn something and there may even be free pizza. Let's all be friends!
This book project will entail a number of important aspects, and its success will be determined by them:
1) Writing the bulk of the content, which will be derived not only from the various Synopses, but the official test suite and directly from the active developers. Information which is speculative (such as from non-finalized synopses) may be included but will not be the focus of initial effort due to their unstable nature. A successful book will include the information and examples necessary to teach the core language to a person who is not currently familiar with it, and bring that person up to a basic level of understanding.
2) Aggregating and integrating existing Perl 6 documentation which is licensed compatibly with Wikibooks, or for which the authors agree to grant a license for the use of their work at Wikibooks. While not a metric for the success of this project, being able to include a comprehensive listing of related resources and obtain small donations of content will help to make the book viable and to get a larger community involved.
3) Attracting readership and additional authors/editors/contributors to the book to ensure it remains viable in the long-term as an authoritative Perl 6 resource. Success in this is harder to gauge or estimate, but the net result should be that more readers are exposed to Perl 6 and able to learn it on their own, and that more volunteers are attracted to the Perl 6 project to aide in documentation and book writing.
Good luck Andrew! If you're interested in submitting a Perl 6 microgrant, you can at find more information about how to do so.
As the new London.pm leader, I have some plans. Most of those involve believing that London.pm can be a huge force for good in this world. So far, the first plan to come to fruition is a refresh of the the London.pm website by Andy Wardley. It has more content, it has a pleasing London skyline, it has a silly tagline and it is more orange. Thanks Andy!
"Like Perl, Git has lots of flexibility, TMTOWTDI, and extensibility", points out the Perl 5 Wiki page on Git. I've been looking at Git in somewhat detail recently. I even wrote Git::PurePerl to understand Git's repository format in slightly more depth. I think Git is a very flexible way to develop and I particularly like github as a way to socially share repositories (and forks). See the Git::PurePerl repository for example.
Why should you look at Git now? Well, I also have a secret...
The London Perl Workshop yesterday was a great success - lots of people turned up for three free tracks (and a tutorial track too). London.pm has a long history of leaders: Dave Cross,
Paul Mison, Mark Fowler, Simon Wistow and Greg McCarroll. At the last act of the day, Greg handed me the leadership of London.pm.
Many thanks to Greg for a fantastic year. I'll continue running London.pm as he has done and I have some wonderful plans for the next twelve months.
If there is anyone out there who still doubts that London.pm is a place where all things are possible; who still wonders if the dream of our founders is alive in our time; who still questions the power of our democracy, tonight is your answer. It's the answer spoken by young and old, rich and poor, CPAN authors and CPAN users, developers, hackers, creators, designers, Londoners and out-of-Londoners - mongers who sent a message to the world that we have never been a collection of object-oriented programmers and procedural programmers: we are, and always will be, London Perl Mongers.
I'm really looking forward to the London Perl Workshop next weekend. It's a free conference, so see you there
As Nicholas pointed out on the front page of use.perl.org, Perl 5.8.9 Release Candidate 1 has been uploaded to CPAN. It contains a whole bunch of changes since Perl 5.8.8. We have tested it on our machines. We have tested it on build farms. We have tested it with as much of CPAN as we could. What we haven't tested it with is the DARKPAN: your code, your computer and servers, your work code, or any of your modules. Blame Transfer Protocol initiated, as Nicholas points out slightly more informally on the London.pm mailing list: we would be very generous indeed if you could test the release candidate all code that you have to hand, and especially with work code. Think of it as your civic duty, if you lived in the city of Perl.