One of the most common sources of confusion for new Perl programmers is the difference between arrays and lists. Although they sometimes look similar, they are very different things, and many bugs and misunderstandings are caused by not having a full understanding of the differences. Even experienced Perl programmers sometimes think arrays and lists are the same, but they are quite different in several important ways.
So the other day in #p5-mop we were discussing how to handle meta layer extensions. For example, doing things like adding accessor generation support to attributes.
After a while I could convince our admin at $work to prepare a virtual machine for running a Pinto server inside our company network. The primary goals were to have a well-known set of CPAN distributions available for installing developer machines, for running CI tests and for provisioning all kinds of servers.
As authors on this site, you no longer need to be diligent about breaking your posts out among the misleadingly-named “body” and “extended” tabs of the new-entry screen. From now on, the front page will automatically truncate posts at a certain length, whether or not you thought to designate a section to place above the jump.
As readers, some of you have complained of unwittingly uncooperative authors in the past. You can now rest easy – this irritation is forever banished to history, and the front page will henceforth always be easily scannable.
Either way, you can now relax and enjoy your stay a little better.
PS.: the logic places the threshold at 225 words, but the exact cut-off point depends on your markup.
Everyone knows all that command-line stuff is for weirdo geeks, right? ;-) So let's bring Data::Dumper kicking and screaming into the 21st century and give it a pretty GUI!
Introducing Data::Dumper::GUI; a GUI for Data::Dumper. It allows you to view your data structures as a tree with collapsible nodes. Data::Dumper::GUI is built using Prima (a rather nice GUI toolkit designed specifically for Perl, that supports Win32 and X11, with no dependencies and compiles pretty quickly... for a GUI toolkit) and Moo.
I spent much of the last few days working on some syntactic improvements to the p5-mop. I had originally went with a fairly straightforward method for specifying things like inheritance, role composition, etc. It basically looks like this:
class Foo (extends => 'Bar', with => ['Baz', 'Gorch']) {}
This works well because it is basically just using a simple Perl list to pass in information to the underlying meta-objects. My only issue with this is that everything is a string, which is no different then what we have now using base or @ISA, but I wanted to see if I could improve this a little.
After wrestling with Devel::Declare for a while (yes, I know it is evil, but it is just for the prototype, the real version will not use it), I was able to get the following syntax to work.
Lately while there's been discussions of various new (for varying definitions of 'new') companies who have chosen Perl, there's not been a huge amount of discussion about how they use Perl. I contacted JT Smith of Plain Black Corporation and he graciously agreed to talk about The Lacuna Expanse, a MMORPG with a Perl backend.
There was no non-single threaded Plack server for Windows. It is because current implementations use preforking which is completly broken on this system. But wait, Perl already has threads which works better on Windows.
So I wrote Thrall: multithreaded Plack server for Windows. To be strict - it is hacked Starlet server with preforking removed, so now works with Perl on Windows correctly.
Well, I've noticed that threads are really stable and useful and its API is very nice. It is only one thing that breaks everything: threads::shared. It is horribly unstable and broken on Windows, so I avoided it as far as simple server might not to need it. Spawning new threads is very slow, so it is suggested to use large value for --max-reqs-per-child option.
It is interesting, that Thrall can be converted automagically to preforking server when it is started with -Mforks option/
Kegler apparently has a script to auto-spam this site with content from his blog, explicitly ignores replies here, and flouts the policy on front-page posts. Is there a chance we can automatically reject his abuse?
I announced that I want to parse 50% of the perl5 syntax within this summer with p2.
I think this goal is doable.
The last weeks since YAPC I spent most of my p2 time integrating libuv as external "aio" module. This implements asynchronous non-blocking IO and rudimentary cross-platform process support. libuv is essentially the node.js backend library, and MoarVM stated its goal to switch from apr to libuv also.
I needed libuv before the p5 syntax to check the ability to do fast and easy library bindings with lots of callbacks, and without a FFI yet. This gives me now the feeling how the FFI should be implemented, and if the current post-XS API is good enough or lacks some API support from core.
As it turned out only some class (=type)/OO features needed to be added to the public potion API, the p2 backend. Everything else went smooth.
I also fixed some more core bugs on my way.
Fennec is a testing framework on top of Test::Builder, one that reduces boilerplate, and solves many of the limitations of vanilla Test::More. It addresses issues such as forking during tests, breaking tests into smaller parts, test-group isolation (state leaks), and mocking. With Fennec in your unit tests, testing becomes a much more enjoyable experience.
A while back I needed to create a presentation for promoting Fennec. That presentation can be found here and covers most of what makes Fennec so great. It even includes a javascript debugger-emulator that shows the order of execution, and the parallelization provided by Fennec. Most examples in this presentation can be found in both vanilla Fennec, and Fennec::Declare, which uses Devel::Declare to provide nice sugary syntax.
These are the key features of Fennec
Concurrency
Predictability
Better Mocking
State Management
RSPEC and Workflows
Customizability
Supports OOP better
No need to manage test count
fork() just works in fennec tests
Fennec also does the work of tying together several popular test modules reducing your boilerplate code.
Over the years I have written a number of implementations of roles, it started with Class::Trait back in 2004, followed by a couple of attempts in the Pugs project, then came Moose::Role and most recently in the old p5-mop project - and I never really liked how any of them turned out. The implementations always felt overly complex and never seemed to gel in my head completely. Since I am really striving to keep things simple with this version of the MOP I decided to avoid the crazy bootstrapping gymnastics and start with the simplest hack possible (then clean it up in the bootstrap).
Abstract Syntax Forests (ASF's) are my most recent project.
I am adding ASF's to my Marpa parser.
Marpa
has long supported ambiguous parsing,
and allowed users to iterate through,
and examine,
all the parses of an ambiguous parse.
This was enough for most applications.
Even applications which avoid ambiguity benefit from better ways to detect
and locate it.
And there are applications that require the ability to select among
and
manipulate very large sets of ambiguous parses.
Prominent among these is Natural Language Processing (NLP).
This post will introduce an experiment.
Marpa in fact seems to have some potential for NLP.
Writing an efficient ASF in not a simple matter.
The naive implementation is to generate complete set
of fully expanded abstract
syntax trees (AST's).
This approach consumes resources that can become
exponential in the size of the input.
Translation: the naive implementation quickly becomes unuseably slow.
Marpa optimizes
by aggressively identifying identical subtrees
of the AST's.
Especially in highly ambiguous parses,
many subtrees are identical,
and this optimization is often a big win.
I'm about to do something. I'm going to release SOAP::Lite 1.0. And it may break on your implementation. But it may also just work. I've been struggling with how to approach refactoring the monster Makefile.PL, so I've decided to gut it and replace it with something simple. The test suite is robust, so if it does break on your usage, you probably know how to install the needed dependencies, and it will be no big deal.
Things will get a bit bumpy here, but I appreciate your patience. And patches. The new official SOAP::Lite source code repository is at https://github.com/redhotpenguin/soaplite
I had considered requiring every module, but I'd have to rename it to SOAP::Heavy, and that seemed to be a questionable approach.
UAV::Pilot, a Perl library for controlling the Parrot AR.Drone, has released version 0.4.
The big change for this update is streaming video to a file. Display in real-time is not yet
implemented--that's coming in 0.5.
There are also some API changes in how event loops are initialized to make the naming more consistent. There will probably be another API change in the video handling in 0.5. Once I do a complete release, API changes will have a proper deprecation plan, but for right now I think it's fine to change things willy-nilly.
From time to time I find myself needing to explain what OO programming is. I've written that Objects are Experts, but as usual, there's a deeper lesson to be learned here.
Imagine that you've hired a new barista (espresso bartender) and you're teaching him how to make a latté. You explain
how to pull the grounds and start the espresso brewing
how to steam the milk and get a good foam
pouring the milk into a cup
pouring the espresso through the milk (and maybe making a nifty pattern on top)
You explain this over and over. That's procedural programming. Finally, one day you can walk in and just ask for latté. You don't have to tell your new barista how to do it, you just ask. Congratulations: your barista is now an object.
Everyone knows how frustrating it can be to try and fail to install a Perl module. I'm writing an article that will help people troubleshoot the common causes of a module not installing. I've made a list below but have I missed any common installation issues that you've experienced?
Unmet Perl dependency (cannot find module in @INC)