PrePAN had been running on my private server. oalders, the founder of metacpan, referred to PrePAN in his blog post, so I made up my mind to move the site to AWS to ensure stability.
Structure of PrePAN can be drawn as the diagram below:
I'm going to maintain and add features to it for future. I hope more of you join PrePAN and have discussion on modules to be newly uploaded to CPAN to make it much better place than now.
The code and chef cookbooks have been opensourced at GitHub. Check them and please send pull requests!
The latest version of
Marpa takes parsing "whipitupitude" one step further.
You can now go straight from
a BNF description of your language,
and an input string,
to an abstract syntax tree (AST).
To illustrate, I'll use an example from the
Gang of Four's (Go4's) chapter
on the Interpreter pattern.
(It's pages 243-255 of the
Design Patterns book.)
The Go4 knew of no easy general way to go from BNF to AST,
so they dealt with that part of the interpreter problem
by punting --
they did not even try to parse the input string.
Instead they constructed the BNF they'd just presented and
constructed an AST directly in their code.
The reason the Go4 didn't know of an easy,
generally-applicable way
to parse their example was that
there was none.
Now there is.
In this post, Marpa will take us
quickly and easily
from BNF to AST.
(Full code for this post can
be found in
a Github gist.)
This is an aid to present a packages module requirements by scanning the package, then displaying in a familiar format with the current version number from CPAN.
This started out as a way of generating the core for a Module::Install::DSL Makefile.PL, why DSL because it's nice and clean, so now you can generate the contents and check when you want, yes it's another PPI powered app.
All output goes to STDOUT, so you can use it as you see fit.
CPAN Version Number Displayed
NN.nnnnnn we got the current version number from CPAN (numify)
'undef' no version number returned by CPAN
'core' indicates the module is a perl core module
'!cpan' must be local, one of yours. Not in CPAN, Not in core.
Food for thought, if we update our Modules, don't we want our users to use the current version, so should we not by default do the same with others Modules. Thus we always show the current version number, regardless.
We also display some other info to complement the modules we have found.
Notes from a Newbie document the creation and deployment of yardbirdfanclub.org with Perl Catalyst on shared hosting. They are intended for a Perl Catalyst Newbie who would like to study the creation and deployment of a simple Perl Catalyst application.
We experimented then started over and now have a decent looking application with authentication/authorization features:
Create new member
Login member
Logout member
We also have other things going, such as a complete database with all tables and columns needed to record membership and create and use blog entries and comments. We know the difference between DBIC Row, Result and ResultSets, and how to use them to store and retrieve data. We've used both an HTML::FormHandler form and one we rolled ourselves. We have header and footer templates to minimize code duplication while providing an attractive, consistent look to our pages. We have a good start on a css stylesheet, with a few basic styles we've been using in our templates.
I'd like to make an announcement: after some serious thought, I decided that
from now on, being a software developer (which I am not too bad at) will only
be the means (but the absolutely necessary ones) to me being a writer /
entertainer / philosopher / Internet celebrity (a little bit of all those
and then some) whose main pride and passion is
his personal web site, which is full
of a lot of material, and various pages and material is constantly added to it.
Oracle is closing down the opensolaris.org site on March 24th, which is inconvenient for the rest of us. I wanted to grab the mailman archives for the mailing lists so I fired up a search engine and looked for any existing open source projects to do this. After trying two different scripts that did not quite work right I realized it would just be faster for me to write what I need.
I started by fetching the listinfo page which has links to all the lists archived and took a look at the data. Based on the page structure the easiest method was to iterate over all the links in the page and only go deeper if it lead to a mailing list's main page. On the mailing list page I follow the link to the archives page. Then just scan all the links in the page for .gz files and download them. WWW::Mechanize provides a save_content() function which handles saving the files locally with minimal effort. That was all it took.
The truth is "no, I really don't think there's a problem with CPAN modules github", but I do think you could make life easier for people trying to do `cpanm $git_url`.
If you haven't read these posts yet, I encourage you to do so. They've all got interesting things to say.
(As an aside, let me say that I think PAUSE authors could probably participate more on PrePAN. I've posted a few things there and found it quite helpful. Even if your module is already on CPAN and you just want feedback on it, post something on PrePAN. I've found the discussion to be of a good quality and actually quite positive.)
I'm proposing an explicit community convention where experimental code isn't released to CPAN, but is shared on github, perhaps with an associated blog post, or discussion on PrePAN.
This addresses just one of CPAN's problems, which have also been raised today by Brendan Byrd.
First of all, I love CPAN. CPAN was the first of its kind, to provide an extensive and official library of modules that support the language itself. CPAN is very much a part of Perl as much as regular expressions are. Without CPAN, Perl would never be as versatile or useful as it exists now.
But, CPAN is also very old. It's been around since late 1995, almost 20 years now. As such, it has grown to house many thousands of modules, 119,124 to be exact (as of today). Many would consider that virtue, as you can find almost anything you want on CPAN. However, it betrays a underlying problem with CPAN that only increases with age:
A hundred thousand modules is too much stuff to sift through.
Although YAPC::Europe::2013 preparations are well underway in Kiev,
it is time for the venue committee of the YAPC::Europe Foundation (YEF)
to think about the location of the 2014 conference. YAPC::Europe
wouldn't exist without dedicated teams of volunteers, and we are always
excited to see the enthusiasm and learn about the new ideas the
community has to offer.
Further information about preparing a complete application can be
found at http://www.yapceurope.org/organizers/index.html .
Proposals submitted to the venue committee will be added to this public
repository (you may provide private information separately) to benefit
future organizers.
The deadlines which apply to this portion of the procedure are:
Saturday, 13 April: Deadline for sending a letter of intent. This
letter simply expresses interest in hosting the conference and provides
contact information (both email and telephone) for at least two organizers.
This is an optional step but it can be to your advantage to alert the
venue committee of your proposal.
Thursday, 27 June: Deadline for sending proposals to host YAPC::Europe
2014.
If you do not receive a confirmation for your letter of intent or proposal
within a couple of days, please personally contact a member of the venue
committee.
Please send your questions, letters of intent, and proposals to
venue@yapceurope.org.
A couple of weeks ago I asked for a show of hands to gather interest in restarting the Thames Valley Perl Mongers. The positive response we received is an encouraging sign that TVPMs are still out there (at least 30 of you) and interested in meeting up!
The meeting will be held on Wednesday 20th March at 7pm, and for this first occasion we hope to have two talks with a short break.
The venue is Reading Enterprise Centre on the University of Reading main campus. Refreshments and light snacks will kindly be provided on the evening by our hosts, Opsview:
Please confirm your interest in attending by dropping a note to peter.finnan@opsview.com, including your full name (required for access to the building). If you wish to volunteer a talk of up to 25 minutes, please also provide a summary and the title.
I also urge you to join our mailing list to keep up to date with this and future plans:
I used to work with DBIx::Class::Schema::Versioned to upgrade my DBIC Schema but soon I needed more then it offered.
Starting with DBIx::Class::DeploymentHandler was a bit troublesome because I had a hard-ish time understanding the extensive documentation.
Now that I moved past that phase I want to present my way of using DeploymentHandler and hopefully spare you some of the burden.
Note: I write my DBIC schema resultclasses by hand and deploy to whatever database system I need.
Feature list
* each schema version should be installable to a clean/empty database
* single step upgrades of schema versions
* create pl scripts that do something on the schema before and/or after upgrade
Let's try to predict when we will be able to {conveniently,realistically,sensibly} use Perl 6 to build real-world applications. Note: this post is just the result of its author's pondering and is not meant to be negative towards Perl 6.
Jenkins - is well known continues integration server. One of it's great features - one may extend it by writing custom plug-ins.
Recently I have create one plug-in to build and make distributive of perl applications.
It implements standard build scheme:
look up source directory
install dependencies into local directory
create distributive
Other features are:
find 'tagged' directory with maximum version number ( implementing install from subversion tags )
applying different patches (install other cpan modules)
color output
... and some others
For now it's only Module::Build compatible.
Links:
New York Perlmongers held a successful hackathon this past weekend at an event hosted by Rubenstein Tech in lower Manhattan. By our count, at least 24 people participated, coming from as far away as Harrisburg PA and eastern Connecticut.. Participants ranged from people making their first contributions to Perl-related open source software projects to current and former Perl 5 release managers and pumpkings. Every participant contributed, in part or in whole, to at least one patch to an open source project. When all patches are applied, at least six people will have made their first contributions to the Perl 5 core distribution. Other projects receiving contributions included HTTP::Tiny, Term::Readline::Perl, Module::Metadata and Catalyst, along with more streamlined procedures for creation of .rpm files for CPAN distributions and improvements in PAUSE, the Perl Authors Upload Server.
Special thanks go to Jaron Rubenstein of Rubenstein Tech — they’re hiring! — and the five other Rubenstein staffers who participated in the hackathon.
OK,
so sometimes you decide you're going to stop using some module X,
maybe because something better has come along.
Let's say I want to track down all my CPAN modules that use Any::Moose because my goal is to port each of them to either Moose or Moo.
MetaCPAN has all the dependency information,
but I don't want to click through each of my distributions.
Enter the MetaCPAN API...
