My new article show how to use Marpa::R2's new Scanless (SLIF) to have Marpa discard whitespace by default, and yet preserve whitespace within various types of usually-paired delimiters.
Yeah! Preview is fixed (or will be if Save now works. Testing...).
So, for the first time in several years, I'm travelling though North America on a speaking tour. It's great to be back here, and I'm very much looking forward to the various Perl Monger events we have planned. I dearly wish I could get to more places around the continent, but these days I'm more-or-less restricted to the cities where I have clients or some other kind of funding.
This year's German Perl Workshop (GPW 2013) in Berlin marks a 10 year timespan of me attending Perl events. Good enough of a topic for my first blog post here. It all started way back when in 2003, having just switched cities in pursuit of a new and fulfilling Perl job. By that time I already had 7 years' worth of Perl experience under my belt, but never attended any Perl conference.
So my first Perl show was the then 5th German Perl Workshop in St. Augustin near Bonn. I was quite excited, had no Idea what would await me. After all, this was my first programming conference, ever.
CPANfile is a simple way to declare your project's dependencies in a build system independent manner.
In recent versions of cpanminus, it makes your entire project installable from a git repository, and,
it also allows you to "pin" your dependencies on a specific CPAN release in a very sophisticated way, rather than "this version or newer" which is the typical Perl dependency resolution.
Why would you want to install a project from git instead of the normal CPAN download/build/test/install process? There are a lot of use cases, but the one I care about most is experimentation, followed fairly closely by patching. Finally, there are pieces of projects which are too trivial to go through the whole "PAUSE packaging/upload" process.
The git representation of a Perl module may be weeks or months ahead of its most recent CPAN release. Also some developers maintain branches of the project which add (or remove) features not available in the CPAN release.
Using CPANfile makes using such code much easier to download and install correctly. If you haven't started using it already, please consider adding CPANfile to your normal development activities, especially if you host your code on a service like Git Hub.
Read more here. I'd also be happy to answer any questions in the comments here, sent from twitter or by email.
Sometimes it's useful to know who exactly is relying on your CPAN distribution - for example, if you're planning an incompatible API change for a module, and wish to contact people using it to give them advance notice. MetaCPAN handily includes a "reverse dependencies" link for every distribution. However, sometimes that might not be enough; you may want recursive results. In which case you need to dig around in the MetaCPAN API.
Thankfully there's a little module called MetaCPAN::API that helps you do just that. Here's how I've used it (plus Moo) to retrieve recursive dependencies starting at a seed...
Not sure if you already noticed that Dancer2 is already on CPAN. It is usable and in fact I know some people using it in production.
Unlike other modules that just evolved until a version 2, the Dancer team decided that Dancer2 will be a different module, and Dancer (version 1) will continue to be maintained. I do not want to discuss on whether this decision is good or bad, but it was a decision.
Now, Plugins for Dancer and Dancer2 are different. In one hand it makes it easier to write plugins for each of the Dancer versions. At the other hand, it makes it more difficult to have shared plugins.
With Dancer::Plugin::Database we wanted to have the less possible work on maintaining two versions. With that in mind we decided to create a shared core module, named Dancer::Plugin::Database::Core with most of the code. And now, Dancer::Plugin::Database and Dancer2::Plugin::Database just use the specific Plugin syntax to glue the Core with the running Dancer version.
Although we think this is working pretty well, if you are a Dancer::Plugin::Database user, please test the latest version, and let us know of any problem it might have.
If you've not read already, the latest YAPC Survey results are out. It seems at least one quantitative interpretation (here and here) of the data is that we're all dead and/or dying.
Is this a new remark?
No.
Would these remarks go away if suddenly every human developer on Earth started programming in Perl.
This week’s post was right on the line as to whether it should be posted here or on my Other Blog. In the end I put it over there because it’s not really a technical post; it’s more about business. In particular, it’s about technical debt and developer efficiency and those sorts of things. But, especially since most of the business experience which inspired this post was gained at Perl shops, it may hold some interest for you fellow Perl’ers. So pop on over there and check it out, if you’re so inclined.
Welcome to Perl 5 Porters Weekly, a summary of the email traffic of the
perl5-porters email list. Sorry this summary is a little short on the
summary part. It's more of a link-o-rama this week.
Object::Simple is simple class builder, Mojo::Base porting. Mojo::Base is simple and useful, but This is a part of Mojolicious. I port it as single module.
package Point;
use Object::Simple -base;
has x => 1;
has y => 1;
package main;
my $point = Point->new;
print $point->x;
1;
Generally speaking, You can write any program using single inheritance and delegation. If you want simple class builder, Object::Simple is good choice.
Friends
It was early days of my college life in 2002, I was into Engineering of Electronics and communication stream in a decent university in India. I wanted to explore things, surfing on internet and downloading and learning applications were my hobby , It were the days of dial up, where i need to download at 56.6 kbps line, where i can download 1 MB in i guess 20 min or so,
However i managed to made my collection of internet softwares.
It was mostly installable software on Windows 98 which allows one to create a form which will email all the fields filled.
So it works on cgi-lib.pl , create a script which if placed in cgi-bin folder will email all the fields filled on form in browser.
The software will create this form.
I liked it, then i installed windows frontpage, which will actually allow me create real websites.
The tests* for indirect-object and bareword disambiguation can be run online at http://perlcabal.org/~fglock/perlito5.html (you need to copy-paste the tests, it is not automated).
GitLab is widely used to view the git repository in a web browser.GitPrep is repository viewer I create lately.
Both are tools to visualize the remote Git repository, but I try to compare these features to understand these difference.Both are web applications that install GitHub system into into own server.
GitPrep have features that can be used in CGI and easy to install and small.GitLab have features that implement many useful features such as Wiki, tickets.
GitPrep support Cygwin on Windows.You can also run GitPrep on Windows.
GitPrep is developed by Perl, GitLab is developed by Ruby. Web framework is, GitPrep is Mojolicious, Ruby is Ruby on Rails.
Two new articles for my blog. The first is on creating a trim() function and its test. The second, is on creating a friendlier interface to Data::Dumper.
The philosophical, social and financial constraints on a project will often guide the direction of the system far more than actual technical constraints do.
Decision makers will choose to defer perceived complexity and cost till they see a need for it.
As technologists our goal is to set ourselves up so that we have the opportunity to implement successive generations of systems when it they needed. This is best done by implementing simple incremental changes than by paying a high cost up front for features and dimensions that are not yet understood.