Strawberry Perl 5.16.3.1 + 5.14.4.1 are available at http://strawberryperl.com
(all editions: MSI, ZIP, PortableZIP for both: 32/64bit MS Windows)
More details in Release Notes:
http://strawberryperl.com/release-notes/5.16.3.1-32bit.html
http://strawberryperl.com/release-notes/5.16.3.1-64bit.html
http://strawberryperl.com/release-notes/5.14.4.1-32bit.html
http://strawberryperl.com/release-notes/5.14.4.1-64bit.html
AFAICT SQLite's foreign_key_list($table_name) pragma returns a list of 8 elements in this order (i.e. with these interpretations):
1: COUNT
2: KEY_SEQ
3: FKTABLE_NAME
4: PKCOLUMN_NAME
5: FKCOLUMN_NAME
6: UPDATE_RULE
7: DELETE_RULE
8: UNKNOWN
If anyone can explain the last item, or offer corrections, please advise.
I love browsing and/or buying books on Amazon.com. Part of the reason is that there are no lack of ratings/reviews on the books, helping me decide on which books to choose on a certain topic. On CPAN however, despite cpanratings.perl.org having been online for more than a decade, most modules have no reviews.
I've done my share of commenting/reviewing modules, but some things could be improved.
First, whenever some other modules are mentioned in a review, it should perhaps be shown as reviews/mentions for that module. For example, just minutes ago I added four reviews each for Text::ASCIITable::TW, Text::CharWidth, Text::VisualWidth, and Text::VisualWidth::PP. Basically I just wanted to say that Text::CharWidth is my preferred way. I should've been able to enter just one review article, which mentions all 4 modules, which cpanratings could show for all those 4 modules.
Second, there should perhaps be an indexing service to index blog/web articles which mention Perl modules. Neil's articles, for example. All in all, those articles could translate to hundreds of module reviews/comments.
We're honored that we, PrePAN developers, can announce we just joined CPAN-API organization!
We're going to make the site better as possible. Please keep eyes on us and send pull requests to our repository.
Hi There,
this is my first post here. I never thought about blogging here, because i just didn't felt to do so. But the last weeks made me to think over this.
More and more i read negative stuff about Perl coming from the people using Perl. This irritates me. On the one side, i think it's a good characteristic to be critical about what you use, what you love and the tools you use. On the other side, i don't really understand why we keep to propagate the bad things about Perl and the economy around it all the time here in public?
If we wanted to attract new programmers to do some Perl coding, they probably don't want to read about all the quirks that exist. They want to read about cool stuff thats possible with Perl, success stories and the like.
So i would love to read more entries which are written in a more positive way than always complaining about stuff that doesn't work.
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.
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?
Yes, yes, and yes. And that's what's hard.
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.
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. :-)
The problem is that I only speak and read English (and maybe British). If you think you can help, or think you know somebody who can help, please check out http://science.webhostinggeeks.com/pdlpp-pdl-rutine. The original English can be found at http://pdl.perl.org/PDLdocs/PP.html.
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.
Thanks in advance!
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!
[ This is cross-posted from the new home of the Ocean of Awareness blog. ]
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
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.
For more info and sample output see wiki
Change to the root of the package you want to scan and run
midgen [options]
--help --output --core --verbose --parent --mojo --noisy_children --twins --zero --debug
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:
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.
A few weeks ago a casual exchange occured on irc... I might as well quote it rather than paraphrase:
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.
....Or, this entry is better titled as "Use cpanfile, and make sure to add it to your repository"
UPDATE: read miyagawa's comment (note, this linked comment has the summary, but make sure to read the others), and his blog post please.
This is a tongue-in-cheek addendum to being able to do `cpanm $git_url` described in "Dont' release experiments to CPAN".
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`.
Namely: use cpanfile and cpanm 1.6, which supports
Some interesting stuff has been said today on The Four Major Problems with CPAN, Don't release experiments to CPAN and CPAN is for experimentation and I hope that never changes.
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.
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
