Over the last few days I've put the Perl::Critic framework to a new use, that of upgrading old perl5 code to shiny new Perl6. The result of this is currently residing on https://github.com/drforr/Perl-Mogrify as it's not quite ready for CPAN yet. There's quite a bit of gruntwork to do replacing the existing Perl::Critic documentation, and I want to add a few more features, but the list of what it converts over is pretty extensive.
(I'm aware of Util's Blue-Tiger project and in fact cribbed some code from it, but I wanted the ability to let others contribute without having to make a pull request.)
As outlined in step 3 of the install notes file, we can now automatically compile our test program and see speed improvements of approximately 170x to 350x, depending on your system.
As usual, the RPerl technical team is in #perl11 on irc.perl.org so don't hesitate to reach out if you need help or have any questions. Let the bug reports begin! :-)
We've come a long way, and we've got a long way to go yet, this is just barely the beginning!
I released GitPrep 1.10. You can install portable GitHub system into Unix / Linux easily. It is second major release.
Because you can install GitPrep into your own server, you can create users and repositories without limit. You can use GitPrep freely because GitPrep is free software. You can also install GitPrep into shared rental server.
I recently asked around #perl6 as to a mailing list where I might discuss PDL features that I'd like to see in Perl 6. Synopsis 9 is supposed to discuss these features, but the PDLish ideas feels like a straight port of PDL, rather than a rethink of what's important. I wanted to discuss things a bit.
The answer was, "Write a blog post." This post contains what I consider to be the essential ingredients of PDL that I think are easily achievable for Perl 6 v1.0. I want Perl 6 to provide an expressive language for writing operations on high dimensional data. I believe that we (and I do include myself) can get this done by Christmas if others can help me out.
Yesterday I thought I might see whether Dancer2 could survive running inside Inline::Perl5 as a possible migration scheme. Roughly 100 of 120 files ran cleanly after wrapping them inside a perl6 heredoc, and as of 10:30pm I've only 6 files left to fix. The majority of the changes have been adding 't/' to the Dancer2 file paths as it apparently relies on FindBin, which reports a different location since I'm running test suites inside perl5 from inside perl6. The other changes have been caller() related which I'm skipping for the time being, and two files where it can't find the correct configuration location, again probably due to the nested interpreters.
I figure I can't go too far wrong with a test suite as extensive as Dancer2's, and yes, I do have an ulterior motive here, wanting to expose the interpreter to a different sort of load. At least this way I can migrate code piecewise and at the same time stress Inline::Perl5 in exciting and new ways.
This is good application for you to understand how to create BBS application which can run as CGI and Embdded web Server.
Features
This is BBS implementation by using Web framework Mojolicious
This use cpanm internally, you can setup by one comman
You can run this application by both CGI and Embdded web server
Pagination is implemented by Data::Page and Data::Page::Navigation
Email sending is implemented by MIME::Lite
This project purpose is rewriting old good Perl/CGI application by modern convention. I hope more people can write Web application by modern convention. It is easy to create application and get high maintenance ability.
This is Japanese project, but you can understand application structure easily if you see the file and directory names.
I know this is getting a lame excuse. But with lack of time, the patch I had time to prepare this month is, again, small. It is mostly some extra tests: https://github.com/szbalint/WWW--Curl/pull/10
This year's edition of the SPW will be amazing.
We are proud and happy that we have been able to attract so many Perl hackers (32 so far). A whole team of Perl 6 people will give us some more insights in the newest area of the Perl 6 development. And there is still plenty of room for more Perl 5 and Perl 6 topics. The CFP is not closed yet, so please bring in yourself and Submit your talk. Or consider to hold a workshop on Saturday. Just let us know.
Hey, Perl 6 hackers, if you like to join our Perl 6 hackathon which runs in parallel to the workshop, please sign up. It is starting already Thursday, 27. August.
Did I tell you already about our kitchen team? Their creations have been delicious! Attendees of 2014 know what I am talking about. So, give yourself a chance and join us on Friday, 28. August and Saturday, 29. August 2015.
Buy your ticket soon.
There is more than one way to make perl5 twice as fast, but this is what I did today. I fixed it on one machine.
My Macbook Air gives constantly better results in my hash function benchmarks than my big Linux Desktop PC, because it has a newer i7 Haswell, and the linux has only an older i5 CPU.
Both have fast SSD's and enough RAM.
But when I run the perl5 testsuite the linux machine is twice as fast.
Typically 530s vs 1200s. Which is odd and very annoying.
I was lucky enough to be able to attend YAPC::NA 2015 in Salt Lake City, this year.
First and foremost I have to applaud the organizers, the event was so well coordinated it looks positively effortless, which I’m sure masked the huge amount of effort that it takes to appear so.
After not being able to attend the last two YAPC::NAs, it was such a joy to be back.
As my new friend VM Brasseur has been saying in #yapc lately, “these are my people.”
The community feeling at all Perl meetings, and especially at YAPC::NA, is overwhelming and I loved meeting and reconnecting with so many fellow Perlers.
just to report there is an issue building Perl (v5.20.2) on Suse
# cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3
It seems it is an issue open since 2011, how it is possible that Suse devs do not report it and fix it? They build Perl on Suse, right? Why they did not contribute back?
$ git config --global alias.stashed "stash list --pretty=format:'%gd: %Cred%h%Creset %Cgreen[%ar]%Creset %s'"
$ git stashed
stash@{0}: 2d7f38b [19 minutes ago] On variable-travel-times-207: variable station travel times
stash@{1}: 1e4207e [6 weeks ago] WIP on custom-mission-actions-30-2: a00a646 Don't show intelligence since we're not using it.
Typically, git stash just shows you the items in your stash. Now, git stashed shows you how long ago an items was stashed (I had no idea I had a 6 week old stash item) and colorizes the relevant bits to make it easy to read (admittedly not visible in the bit above).
I uploaded File::Finder to the CPAN more than a decade ago. I was using it for a project today, and found a bug that has been in there in the beginning. I forgot to localize $_ in ->contains, which clobbered File::Find's $_, used by just about everything else.
I couldn't even remember where I had put the git repo for the distro source, and once I found that, I couldn't remember how to build and test modules.
I just released 0.30_1 of Net::Amazon::EC2 to CPAN. This test release contains support for AWS4 signatures. It is based on a pseudonymous patch on this RT ticket but I reworked it to support both v2 and v4 signatures because I know some of the people who use this module connect with Eucalyptus or other AWS-compatible-ish APIs which may not fully support v4 yet.
So if you've been itching to get stuff done with EC2 in the eu-central-1 region (which AFAIK only accepts v4 requests), please give this test release a spin. I plan to release it as 0.31 after a couple of weeks if no show stopper(s) pop up.
