YAPC is always a special time - for all of us. YAPC::EU was my first YAPC and no matter which YAPC I attend, I always remember it as the first YAPC I had (back in Italy), where I met Ovid, Aristotle, and other people I nowadays get to call friends, for the first time. It was my first community event.
I had not been expecting to attend YAPC::EU this year. In fact, I have never been to YAPC anywhere. But about a month ago, the announcement in Perl Weekly caught my eye. Skimming through the program of talks, I became more intrigued. The location in Granada also looked enticing.
The main obstacle was that I live on the southern tip of Africa. The journey would be long, arduous and expensive. Nevertheless, plans were drawn up, family and colleagues consulted, and funding secured. This was going to happen.
Twenty four hours after setting out from Cape Town, I arrived in Granada. Over the next five days I got various doses of Perl education, folklore, insights, whizz-bang craziness, and inspiration. I was also struck by the diversity and camaraderie of the Perl community, and the cultural richness of Granada.
But perhaps the most uplifting take-away for me was the realisation that Perl is a state of mind, an approach to problem solving, more than it is a particular language, and that this transcendent aspect will probably be as present in Perl 6 as it was in all the previous Perls. As I prepare for the long journey home with my bag of virtual goodies, it is this one that I treasure most.
The Swiss Perl Workshop was recently hosted in Olten, Switzerland, at the end of August, 2015. The Perl 6 team is targeting an official release by Christmas of 2015, and the workshop provided a great opportunity for core Perl 6 developers to complete a lot of Perl 6 development and training.
One of the last big changes before we're ready for Christmas is the Great List Refactor - an effort to improve performance, syntax and semantics of lists (especially lazy lists) in Perl 6.
At the workshop, we were working hard on the GLR - finalizing any outstanding design decisions, going through the ticketing system, the design docs, and the test suite. By the time the workshop was over, we were down to 100 failing tests (out of over 100,000), and the module installer (panda) was working with the newest version. Many new tests were added supporting the new behavior.
RPerl v1.1, codename 'Jupiter', has been released to CPAN!
Jupiter supports fully-automated compiling of the long-awaited N-body application software, which is a solar system simulator used by the Alioth Benchmark Game to rank programming languages by speed.
RPerl and the new PhysicsPerl software suite enable the N-body app to run at the speed of C++, dropping from over 19 minutes runtime to barely 13 seconds!
For now, see the INSTALL notes file for instructions on running N-body using RPerl & PhysicsPerl.
Also, take a look at the pre-release user documentation, Learning RPerl!
Please visit us on IRC for real-time tech support:
At this year's YAPC::EU, we've been having a blast in Granada, Spain, an incredibly beautiful city. The conference has been fun and Dave Cross gave a great lightning talk about Modern PERL (sic). These are devs who are using 5.8, often aren't allowed to use modules, and use CGI.pm for param handling, but print cookies manually. In a similar spirit, I present a subroutine from some client code. It's here with their permission, and it's one of reasons they've hired All Around The World to fix their system. Pay close attention to the sprintf lines.
About a year and half ago, the CPAN community started to join Gratipay (formerly known as gittip), possibly under the influence of this post and that mashup.
Since then, laws and regulations have caught up with Gratipay, forcing them to radically change their model
(there's something to be said about doing a little bit of bibliography/research on the problem area before diving into the code).
So if you joined Gratipay at that time, and received some tips, you should read this.
Since receiving co-maintainer for BZ::Client about a year ago, I have been gradually sprucing things up with code style tweaks, including patches from RT etc.
Over the last few days I've gotten quite stuck in, taking the time to convert to Dist::Zilla releases, tweaking and stripping out a lot of Pod (left to Dist::Zilla to insert), removing subroutine prototypes. Which has resulted in a couple of new minor releases interspersed with dev releases.
Version 5.0 of the popular bug tracking software Bugzilla was recently released and in so doing sent the 4.0 series to EOL. It's actually one of the few examples of software that RedHat has not re-written in Python (then started rewriting yet again in Ruby)
If you're at YAPC::EU, please blog about the conference and your experience, and preferably do that before the end of this weekend: (1) the thoughts are still fresh in your mind, and we'll get your raw unedited thoughts, and (2) you stand a better chance of getting a mention in PerlWeekly :-)
Once you've published your blog post, tweet about it with the #yapceu and #perl hashtags — that will increase your audience. For extra credit, please add a link to your blog post on the list of blog posts.
Writing your own commify function may well be right up there with writing your own web framework or templating system. Most of us have done it and it probably wasn't worth the effort. Enter CLDR::Number. (I should note here that it's not obvious from the name that this module will commify for you -- that's one of the reasons I'm writing this up.)
A long while back (I’ll find the reference if I can) Stevan Little, author of Moose, commented that part of what he wanted for a p5mop was the ability to have truly private data in classes. Much in the way Perl 6 has $!data attributes that are simply private data, he wanted to just be able to use Perl’s regular variables in this same way.
I took this as a bit of a challenge and several iterations later, I had a working system. I then spent months trying to decide if I wanted to put it on CPAN. I kept weighing utility vs practicality. Though it is an interesting thought exercise, I have no idea if its a good idea.
Time::Moment 0.27 introduces the concept of $tm->with($adjuster). The adjuster is a CODE reference which is invoked with an instance of Time::Moment and is expected to return the same.
Time::Moment comes with Time::Moment::Adjusters which currently only provides routines for navigating/finding the day of week.
I use Dist::Zilla with a few plugins, including NextRelease and Git::Check. I was always nagged by the fact that committing actually left the Changes file uncommitted... until now. Read it here.
ModuleSpecific::Exporter - Reads @EXPORT and @EXPORT_OK to add 'is export' attributes to your subroutines
ModuleSpecific::Moose - Adds Perl6 style attributes to your Moose class based on C.
Quieting the application - use '--detail 5' to see what's been done
Bug fixes to refactoring - The current binary handled 32000+ files including perl5 core and several gnarly Matt's Script Archive escapees
After my previous post I received quite a bit of really good, constructive feedback. Thank you all who responded to my request for comments! I would say the gist of the feedback was this:
Make the interface simpler for middleware and to a lesser extent, servers.
Consider always requiring the Promise interface.
Consider using Supply instead of Channel as it is non-blocking and likely to perform better.
After wrangling and playing around with various things and learning more about Perl 6 than I knew before, I have come up with what I think will be a stable interface that satisfies all of these suggestions.
First, since Promises are easy to do, I agree, let's just always require them. This means that the basic Hello World app now looks like this:
a real usable Perl6 is imminent. So this weekend, I decide to play it around (the last action is 10 years ago). After one day playing, I feel it has evolved greatly! it's already a much fantastic language than perl5 even than I image it. of . It's cleaner, more logical, more consistent and built-in some important feature which perl5 hasn't.
Implicit parallel is one of the features I eager to have. In perl6, you can use 3 key words to speed up list operate(in parallel way):
eager: force non-lazy list processing
hyper: requests (but does not require) parallel evaluation. In any case, it declares that you don't care about the evaluation order, only the result order. (means it would block when one thread is not ready I think)
race: forces parallel evaluation of any iterator, hyper, or junction, such that if any single thread dies or hangs its computation, it does not block any other thread from returning its results to the race list.
It looks fantastic! doesn't it?
Sadly, when I tried:
my @c = 1..10;
eager @c.map: {say $_};
hyper @c.map: {say $_};
race @c.map: {say $_};
it throws some errors
and seems not implemented yet. or maybe I made some mistakes? anyway, I want use it in 2016! ;)
Along with:
Quieting the application - use '--detail 5' to see what's been done
New refactoring tools in Utils::PPI
Unused options trimmed out
Bug fixes to refactoring - The current binary handled 32000+ files including perl5 core and several gnarly Matt's Script Archive escapees
ModuleSpecific::Exporter - Reads @EXPORT and @EXPORT_OK to add 'is export' attributes to your subroutines
ModuleSpecific::Test-More - Changes 'Test::More' to 'Test', moves 'tests => 42' out into a proper function call, and properly hyphenates Test-specific function names.
ModuleSpecific::Moose - Adds Perl6 style attributes to your Moose class based on C.
The submission deadline ends August 31th, midnight CET.
Please use the online form for submitting your talk or write to 2015@perl.dance if you need help or more time to prepare your proposal.
We already confirmed a number of interesting talks and there are a few more prominent speakers like Peter Rabbitson and Russell Jenkins which are going to present at the Perl Dancer Conference.