Perl 5 has become pretty stable, but there is always room for small improvements. I would like to discuss yet another "missing" operator. Its purpose is to make expressions handle some edge cases more gracefully. It could render some other extensions that have been suggested before unnecessary.
I don't think I'd have to look for long for someone who'd agree that writing new code is much more fun that fixing bugs in old one. A cool new idea gets written up, while older code is still lacking tests. A new module gets shipped, while there's still that API improvement proposal from 6 months ago in the other. And while you're drafting a design document for the Next Awesome Thing, the rest of your code is being slowly consumed by bit rot.
Having written 250–300 Perl 5 modules and now 32 Perl 6 modules and other ideas, I'm more than aware of what it feels like to be leaving a decaying pile of code in your wake. The problems I notice are these:
Hi!
I have just released swat, version 0.1.80 to support JSON/XML applications testing with the help of so called response processors.
Regards
-- Alexey
Introducing Scheme in Perl 6: https://github.com/drforr/perl6-Inline-Guile
This is very much in its early days, and the interface is likely to change as I find the method(s) in the Guile library that I need. Specifically once I can figure out how to portably crack into a SCM return value the need for separate _i and _s functions should go away. Perl 6 is perfectly capable of making the distinction, but it's a segfault waiting to happen from C should I get the return values wrong.
Also I need to cleanly dispose of the returned string, as it is it'll leak memory.
Hey everyone,
Following is the p5p (Perl 5 Porters) mailing list summary for the past two weeks. Enjoy!
Are you waiting for a Rakudo * Christmas Release? Or an MSI installer for windows? Here's the story so far:
[This is a post in my latest long-ass series. You may want to begin at the beginning. I do not promise that the next post in the series will be next week. Just that I will eventually finish it, someday. Unless I get hit by a bus.
IMPORTANT NOTE! When I provide you links to code on GitHub, I’m giving you links to particular commits. This allows me to show you the code as it was at the time the blog post was written and insures that the code references will make sense in the context of this post. Just be aware that the latest version of the code may be very different.]
Last time I added Time::ParseDate support to our date class, which made it fairly usable, if still incomplete. This time I decided to concentrate on getting a first cut at our datetime class.
In many ways, the datetime class is simpler than the date class, because it doesn’t need to do anything fancy like truncate to midnight or try to ignore times and timezones when parsing. Of course, datetimes do have to consider timezones, but I decided to defer that thorny issue until next time.
With Exporter, and most exporter tools we have failed to separate concerns.
Exporting fundamentally involves 2 parties: exporter and importer. Historically
however we have only ever concerned ourselves with the exporter. The "standard"
way of dealing with this in perl has been to have a module that provides
exports use it's import() method to inject symbols into the importer's
namespace.
What if we did this with other similar concepts? What if instead of:
use base 'foo';
we had:
package My::Base;
# Gives us an import() method that sets @{caller::ISA} = __PACKAGE__
use base;
...
package My::Subclass;
use Base::Class; #Automatically sets @ISA
In the past I sometimes used XML::Tiny and I found it perfect for the job. Agreed, I had to struggle only with very little and under-control XML, so I knew I could do without a full-fledged XML Parser.
If you're a Perl developer in the UK, I will literally send you free money by email: http://eepurl.com/bNSF9P
For one client, I was told that our devs didn't have client access to a database with a problem, but they could connect via DBI. Thus, I whipped up the following to help them out.
It has command line history and mostly handles multi-line queries. It's not overly robust, but it's the sort of handy code you might just need in a pinch.
Today, I've done something strange.
No, there weren't drugs involved, I merely sent a patch for Rakudo for a bug I reported a few weeks back. But the patch is... interesting.
First, about the "bug." Newest JSON spec lets you have anything as the top level thing. I spotted a few modules in the Perl 6 ecosystem that still expected an object or an array only, and the vendor-specific (possibly to be made hidden in the future) to-json subroutine provided by core Rakudo behaved the same as well.
One of the modules got fixed right away and today, seeing as there were no takers, I went in to fix the bug in Rakudo myself. Since I'm a lazy bum, I merely went in to that one fixed module and just copied the fix over!
But wait a second... ain't the Perl 6 module written in Perl 6? How did I manage to "just copy it over"? What sorcery is this! Surely you lie, good sir!
Last year I attended the Programming the web with Dancer master class at YAPC::NA, taught by the awesome folks Sawyer X and Mickey. It was then I learned that a new way to access get/post/route parameters was being baked and the potential pitfalls of what had been the current practice.
At the time, I was busy evangelizing the use of Dancer2 in professional work, and that meant exposing other developers at various levels of Perl familiarity how to accomplish tasks in the Dancer2 framework. While I waited for the new DSL parameter keywords be released by the Dancer2 core team, I decided to extend the Dancer2 DSL with keywords for parameter access of my own and added that to company broilerplate rather than have to worry about making sure every developer on every Dancer2 project was fully educated (or remembered) the aforementioned pitfalls when doing their work.
Haven't posted anything for a while, but I'm not dead, just busy. Here's a quick recap of things that I think people might find of interest.
First and foremost, I'm going to be in Brussels, Belgium, next weekend for FOSDEM. If you can make it, check out the Perl track. I'll be speaking about why people are finding Perl 6 so exciting. In particular, ever since the Christmas release, there's been a fair amount of chatter about Perl 6 and I've been paying a lot of attention to people who are looking at it for the first time, without a lot of preconceived notions. The reactions often range from "wow, that's cool", to "oh my goodness, I want that!" What's even more interesting is that they're not focusing on a particular feature (which would be scary as it would pigeonhole Perl 6 as a "niche" language). Instead, plenty of people getting excited about different things which scratch their particular programming fetishes: grammars, gradual typing, concurrency, and so on. It's fun to watch.
But there's more ...
With the gracious collaboration with Cosimo,Text::Hunspell made the switch from ExtUtils::PkgConfig to Alien::Hunspell late late year. Despite the somewhat complicated dependency requirements, this immediately made the spell checker more reliable as reported by cpantesters, as many machines do not have pkg-config or hunspell installed.
The one major platform that didn’t work on the initial switch was of course Strawberry Perl, but after some debugging and patches I got Alien::Hunspell and Text::Hunspell to work there as well. I even submitted patches to upstream to the hunspell project, which were accepted, so that in the future less patching will be required. This is what is great about Open Source when it works.
The results as recorded in the cpantesters matrix are stark:
I'm still trying to get my head around how the concurrency stuff works. I had an idea for a simple script: sometimes I run a program that dumps a lot of output, so I'd like a script that would take that as input and just hold onto the most recent X lines of it, so that they could be read at any point through a named pipe.
So I figured I'd need one thread to read lines from STDIN ($*IN in Perl 6) and keep an array loaded with a certain number of the most recent ones, and another thread to open the fifo for writing and dump the current contents of the array to it whenever someone reads it. In Perl 5, I'd probably do it by forking off a child process for half of the work, or maybe use a single loop that does both things but has quite a few no-ops. I figure in Perl 6 I can do it with threads.
As a Perl 5 programmer of about a decade, I'm well aware of how it was referred to at some point or another as the "write-only" and "linenoise" language. With the newest addition of the baby Perl 6 language to the Perl family, I fear that I must declare (wildly speculate) based on my extensive research (a boring ride on a bus, while staring at my phone) that Python steals that title now!!
Why Python? Blame whoever made the Stackoverflow Python Report scroll through my Twitter feed. I merely picked two problems from that list and asked myself what would the Perl 6 solutions to them look like.
The top rated item of the week is interleaving two strings.
I am creating Validator::Custom from 2009. This is a validation module.
I add many features to customize validation but I can't solve many problems because Validation logic is more complex than I expect.
Mojolicious remove filter feature of validation module. It is maybe impossible to do three things(require, checking, filtering) at once.
And validation logic is complex because we want to see multiple values at once. for example, "high_price" param + "low_price" param.
Next, In html validation, we must think about fore cases.
1. name=foo
2. name=foo&name=bar
3. name=
4. (not exists)
And We want do filtering for blank containing value, for example, " Kimoto ".
And We maybe want to prepare default value when validation fail.
Above combination is very very complex.
At first programmer must to choice a value or values. By this, we don't need to thing "require" checking.
Howdy, peoples! I've written a few more posts on my blog about my adventures exploring Perl 6.
More posts are coming as I dive deeper into Perl 6 and learn more. Enjoy!
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
