Suppose we use books as analogies for Perl (CPAN) modules.
Do we want CPAN to be some sort of an ISBN authority, where we merely dole out namespaces and unique IDs? There should be no requirements of content or any editorial activity on the modules. We should not discourage (nor encourage?) experimental modules or implemetations, modules for personal or semi-private use, etc.
Do we want CPAN to be some sort of a publisher? There would be some editors in charge to determine which modules are worthy of publishing and which are not (yet). The question is, who? There can hardly be a consensus and "CPAN publisher" will be forked into several publishers with differing guidelines/missions. Not that forking is a bad thing.
Do we want CPAN to be some sort of a bookstore? Where we can browse for modules or do comparison shopping, see buyer's ratings, and finally check out and bring some modules home.
Do we want CPAN to be some sort of a public library?
Do we want CPAN to be some sort of a personal library? Where we display our favorite collections for others to see?
Tong Sun, a user of GraphViz2, has drawn my attention to the test database Chinook, downloadable here.
He and I have both had great difficulty getting GraphViz2 to properly display the schema of this database. He's using Strawberry Perl, and I'm using Perl under Debian.
Among the various problems are files marked as ISO-8859-1 but containing UTF8 data, and the Postgres data using the string syntax N'...'. AFAICS my Postgres V 8 (printed) manuals don't use this. Perhaps the original Chinook data was prepared by someone using Postgres V 9.
So, I've created Postgres and SQLite files to simplify installation of the Chinook data.
Download the Postgres data from here, and the SQLite data from here.
See create.pg.sh and create.sqlite.sh for the installation steps.
Note also that Postgres' psql and SQLite's sqlite3 both fail to handle UTF8 files starting with a BOM, so I've rigged the code in both cases to generate a deliberate syntax error when the reader attaches the BOM to the first non-comment token.
This is an attempt to succinctly list all the different problems perceived with CPAN, and give them a name. No attempt at proposing solutions, or structuring a taxonomy / priority list, but data gathering.
I am writing to solicit help from anybody who knows Perl and can read Serbo-Croation. Vera Djuraskovic kindly offered to translate the documentation to PDL's threading engine, PDL::PP. Not light material, mind you. :-)
Of course, the original docs are written in pod, and I would really like to distribute the translation with PDL itself. However, Vera has not expressed any interest in distributing these docs as pod, possibly because she (he?) would actually like to drive some viewers to his (her?) site. For my part, I am most concerned about having the translation. If the translator can derive a fringe benefit from the translation, I'm OK with that.
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.
