Hello,

I have a humble request - that the mod local::lib be installed by default at part of CPAN, and not as a separate install. FTP and HTTP are supported "out of the box", we are asking the same for local file. This would allow a local repo of CPAN to be used out of the box via filesystem. This may mean that local::lib no longer exists, it is rolled into the base CPAN code.

It is a chicken/egg scenario, in order to install from fileshare, you have to have local::lib installed. This requires going to the net for CPAN install, which in our case is not allowed.

There are work arounds (boot strap, rpm's, etc) but it would be nice to use a local repo native to CPAN out of the box.

The use case, many servers (1000) in a commercial environment. We have no direct access to the internet, and we have to use a vetted source for CPAN on a local fileshare, not public repos via FTP or HTTP. We could bring up a local HTTP repo, but would prefer to use fileshare

Thanks for your time an consideration.

I asked if it was an error, and 1 version of perl might not be needed vs. 2 for python.

The reply I got:

Dear Linda,

It feels like Perl is not very trendy these days. Support for that man
+y languages was added because certain popular plugins are written par
+tly (or fully) in these languages rather than Vim Script. Python is p
+robably the most popular language for extending Vim right now, perhap
+s after Vim Script. Ruby goes next, then Lua. But I've never came acr
+oss a single plugin which would rely on Perl to be honest. May I ask 
+why you think that Perl is so important for that Vim distribution?

Regards,
Alexander
[download]

Hello dear monks!

to be clean in my speech: I just looking for my next telecommute contract with mojolicious and modern (sure depends on what you think modern perl are :)) perl.

And can not find anything real during last 3 months...

I am not too greedy (really my hourly rate are not huge),

I am not (suppose) too lazy or (really suppose :) ) too stupid ... but all proposed projects was related to old cgi style or (not interested) catalist framework :(

I just wanna my next project to be interesting and use tools that really interesting for me :( Am i dream too much? My wishes (work with fun) not real?

Please share you experience:
- are things are going really bad (for my expectations) in perl market? (support old/poor coded apps dominate)
- any success story?
- any mojo fans here? :)

Hello dear monks!

I regularly met the problem of arbitrary data structures validation, which comes in form either hierarchical config or JSON data. The substantial idea, I got from one of Perl books (I think, this is Hight Order Perl) is the following: the programming languages have tendency to be declarative (i.e. declaring/describing the result, but not the way, how to archive it) but they'll never completely be so, because it seems to be possible only in some local areas.

When such a local area is been invented, then an extremely useful micro-language will appear. For example, well known regular expressions for the area of arbitrary text data matching/extraction. Another successful example I know is the XPath (or XPointer?) technology for nodes matching in XML documents.

The last one seems to be very successful in addressing data nodes, that a lot modules appeared, that try to mimic XPath behaviour: Data::DPath, Data::SPath, Data::PathSimple, Class::XPath.

Well, XML seems to be not too modern, too heavyweight, too enterprisish. So, the minor brother, not overcumbered with namespaces and processing instructions, appeared. It is JSON. The related data extractions/matching technology appeared a bit later; this is JSON pointer: JSON::Pointer, Mojo::JSON::Pointer.

So, my intention was to develop module, which takes the best from the two worlds: declarative data path selection (a-la JSON Pointer and XPath, but not as simple as the first, and (yet) not as complex and feature-rich as the second), and from the perl (closures, flexibility, application agnosticism, DWIM and DRY principles).

Here come a few snipplets, from which you can judge about the module

use Data::DynamicValidator qw/validator/;

my $data = { ports => [2222] };
my $errors = validator($data)->(
  on      => '/ports/*',
  should  => sub { @_ > 0 },
  because => 'At least one port should be defined at "ports" section',
)->errors;

if(!@$errors){
    say "all ok";
}
else {
    say $_->reason for(@$errors);
}
[download]

So, it generally, it uses triplets: on (specifies data path), should (specifies testing perl closure for the results of data path selection), and because (defines human-readable string for administrator to say/describe him the errors in a config, or for HTTP client developer, that something is missing in JSON input data).

A bit more complex example. Say, you want to check that all declared ports should be available for the application at startup. So, you should do the following:

use Net::EmptyPort qw(check_port);

my $errors = validator($data)->(
  on      => '/ports/*',
  should  => sub { @_ > 0 },
  because => 'At least one port should be defined at "ports" section',
  each    => sub {
      my $port = $_->value;
      shift->report_error("The port $port is not available for usage")
          if(!check_port($port));
  }
)->errors;

[download]

The more complex examples are available in metacpan.

Constructive critique and suggestions are more then welcome!

In the meantime, other GUI toolkits, such as the short-lived Gtk, Gtk2, and currently Gtk3, and others such as Wx and KDE have come along. But they are always changing so fast, to incorporate such great new features as semi-transparencies, gradients, and whatever new themeing engines they might want compatibility with.

So, I look back at Tk, knowing that for the most part, all my scripts still run pretty much as I wrote them way back when. It is simple, and stable. My newer Gtk2 scripts, may not convert without some work, to Gtk3. Additionally, the docs for Gtk3, Wx and ( KDE ) Qt GUI's are hard to come by.

But just look at the Tk code base. It needs no pre-requisite libs to be installed, and is a very small module compared to the GUI potential, which it contains. In days of heightened security over code safety, Tk is an easy to module to deal with. Additionally, if you do need transparency and all the matrix operations like rotations, the Tk::Zinc module works great. It is now somewhat abandoned code, but the module still works, and it used to be used as the air-traffic display driver for some French airports. So you know it isn't junk software. It comes with a nice pdf manual, documenting all it's features.

It is kind of funny to me, that the entire drive to make more advanced toolkits, was so that the themeing engine of the host computer would decide how the window app would look. Many like the simplicity of Tk's ability to individually set each widget's colors and fonts with a few simple lines, like -bg=>'#112233', instead of needing a special style section to overide the system's style settings.

Anyways, I still reach for Tk whenever I need a GUI app. It is suitable for almost all small custom tasks. I would even trust it for digital guages and controls.

... and it's way easier to write code for, than any other toolkit out there

I'll bet Perl/Tk will still be around after Gtk5 and Wx99 are come and gone. :-)

A little while back there was a long discussion on p5p/RT about fatal warnings, a blog posting about fatal warnings by chromatic, and a long discussion about use VERSION; and related issues in here on PerlMonks.

All this got me thinking, and I realized that Perl gives you an incredible amount of control over features, strictures, warnings, best practices, and on and on:

• the #! line, use VERSION;, no VERSION; $] and $^V
• use/no feature ...; with currently 10 features
• use/no strict ...; with 3 categories
• use warnings FATAL=>..., NONFATAL=>...;
• use/no autodie ...; with 60+ categories/errors
• use/no warnings ...; with 50+ categories
• warn, die, Carp
• $SIG{__WARN__}, $SIG{__DIE__}
• eval {}, Try::Tiny, and more...
• Modern::Perl and more...
• Perl::Critic with 140+ default policies and 25+ extension packages on CPAN
• Perl::Tidy
• Pod::Checker, Test::Pod::Coverage, and more...
• ... and probably lots more I've missed...

This variety makes it pretty obvious that which of these apply will be different between people and applications. So the next time someone disagrees with a recommended practice or Perl's defaults, it might be helpful to point out the number of choices and level of control they have.

Original text taken from here

Given our community is a little... let's say cautious I feel the need to open with a disclaimer. I am in no way affiliated with Gittip, in the past, present and the foreseeable future. In fact I looked at their bugtracker for the first time this morning and am appalled that a site in production for 2 years can have so many outstanding basic conceptual issues.

In any case this entry is about the underlying idea, so if you can manage to not get distracted by a shoddy implementation - read on (NSFW language as always :)

It started yesterday when I looked here and asked Y U NO WANT BEER?!. While twitter did not manage to spark a conversation, IRC did (and boy, was that some conversation :) The chatter quickly evolved, climaxed and (painfully predictably) broke away for good. And also predictably it boiled down to a split into several distinct camps

• Some genuinely believe it is not worth bothering with chump change, since "we lack the hipsters in our community" and without them any kind of funding drive will not have an impact
• Some feel uncomfortable seeing their avatar among the current highest donors/receivers (after you look at the current top receivers you either instantly understand what the problem is, or you don't - there is no easy way to explain it)
• Some genuinely believe they rather get patches as opposed to chump change

I say FUCK THAT. And instead of explaining how and why you should do something you are not currently doing, I will instead explain why I am currently pledging $50 (possibly more in the future) per week, and distribute them among folks of my choosing.

First of all: it is easy for me to do so (and yes, this part is important). Connect my twitter / github / bitbucket / whathaveyou account, connect a credit card: done.

With that out of the way - let's take a simple example - Pumpkin Perl and the current Pumpkin (or Pumpking depends on what you like). At the time of writing Perl is #3 on the metacpan leaderboard, with 168 "backers". If these 168 decide to give our pumpkin $5/week each - that's roughly $3500 per month for him right there.

THIS JUST IN, BREAKING NEWS: chump-change adds up.

Now, am I confident he will use the cash to further my interests (that is keep Pumpkin Perl sane) in the foreseeable future? Yes, I am pretty confident, given track record and all that. But the more important question is - does it matter if he actually does? Not in the slightest. I am not sharing some chump-change with expectations of extra commitments and future results.

I am virtually buying my fellow colleagues a beer for EXCELLENT OUTSTANDING WORK *ALREADY COMPLETED*

What I particularly like about Gittip is that it does not require any extra effort to keep doing what I decided to do. Yes, I could go broke by oversharing my extensive wealth, but so could anyone with a non-dumb phone and an appetite for extra game content. At least I'd know there is an actual person (that I might even like) on the other end ;)

Will I feel cheated and sad if none of this goes anywhere? If the virtual beers do not motivate anyone, and if the Perl-portion of the Gittip community remains unseen and insignificant? Not really. $50 is the cost of a decent-but-not-spectacular dinner for two where I live. If this is cash that ended up being thrown away - shrug, it could have been a shitty dinner anyhow. And if I *do* feel bad about it - this means I am a petty shithead and I deserve to feel like that anyway :)

So to recap:

• It is easy
• It doesn't cost me much of anything
• It can make a real tangible difference on the other end
• It sends a clear continuous "Thank you!" message
• Makes Perl as a whole look good, without compromise of my values
• No hipsters required (though of course welcome)

What's not to like?

Cheers

Hi all,

this is not really a Perl related question but I would like to address the Perl community with it.

There is rex as a Perl based deployment tool which seems interesting as all is implemented in Perl and someone like me could get the feeling to be able to put hands on when needed. On the other hand there are well known and famous tool sets like Chef and Puppet written in a language not known to me.

So, I would like to hear whether some monks have experience with these distribution tools and whether using them seems worth it (I know, a really vague question).

Thank you in advance.

Best regards
McA

Hello fellow monks.

A few days ago I was working on type inference in both simply-typed lambda calculus and Hindley-Milner System. While I was trying to use hashtables to implement branches for getting rid of annoying 'if's, I realized that there's no quick ways to emulate pattern matching in ML or Haskell -- It is a fact that we could not easily do that due to the dynamic nature of Perl's type system. However, I managed to emulate some of the features I used in Erlang, ML, or perhaps Haskell and made a small CPAN module HOI::Match (where HOI means Higher-Order Imperative):

With the module, I am able to write such a sum function:

sub sum {
    HOI::Match::pmatch(
        "h :: r" => sub { my %args = @_; $args{h} + sum($args{r}) },
        "nil" => sub { 0 }
    )->(@_)
}
[download]

(Note that the arguments in @_ may be FETCH several times so it is dangerous to rely on side effects of FETCH on arguments.)

Any suggestion or criticism is welcomed. I am looking forward for your replies.

Today a have a moral issue to share with you. Let say that you are coming from a country that has 25% unemployment rate (even higher for young people) and though government is saying programmers are easily employable (which is true) they are highly underpaid. Let say that you are in your late 40's and you work for this company where you are the only programmer around. Your boss knows it and though he values your work the free market allows his competitors to higher young highly motivated people that are willing to work for half what you make. You know that most of the base work is done and maintenance is the only thing you lately do. That does not require a lot of experience nor deeper understanding (my personal view) of how stuff works but just requires of your to follow latest trends. Let say that lately you noticed that company code (that you wrote) is being downloaded by your boss frequently. You try to figure out why but don't get a strait answer. What are you to assume especially if the company is not that big and you know cuts needs to be made.
My question to you guys is: Would you be willing to do a dishonest thing in order to keep your job, like for instance, write unreadable code? I know people that do that and now they are using it as a bargaining leverage for negotiating raise or keeping the job. Also my question to you is . How often this happens? How often people write hard to maintain code just to keep others away? Is it something that is done frequently (in your experience) or not?
Of course big companies do not allow you to do something like that but small ones do. What is your opinion on the subject.

thnx

baxy

I had a lot of trouble getting started with Proc::Daemon because some things weren't completely obvious to me. Here's a practical example that I wrote for practice.

use strict;
use warnings;
use v5.10;

our $_cached;
sub somefunc
{
   $_cached //= do {
     say "Heavy calculations";
     42+($ARGV[0]||0);
   };
}

say somefunc();
say somefunc();
__END__
Heavy calculations
42
42
[download]

use strict;
use warnings;
use v5.10;

sub somefunc
{
   state $var = do {
     say "Heavy calculations";
     42+($ARGV[0]||0);
   };
}

say somefunc();
say somefunc();
__END__
Heavy calculations
42
42
[download]

However I see one problem here: unit testing.

With first example it's easy to test somefunc with several possible inputs.

{
  local $_cached = undef;
  local @ARGV = (3);
  say somefunc();
}
{
  local $_cached = undef;
  local @ARGV = (5);
  say somefunc();
}
[download]

and with "state" it looks impossible? Once you call somefunc() from your test, it's result cached forever.

Looks like a missing important feature, which can encourage people not using unit testing? What do you think?

I had quite a long discussion with Lady_Aleena in the chatterbox, as I wanted to fully understand her wishes. She had a number of complaints about Text::CSV (and Text::CSV_XS) being to complicated for simple end-user tasks.

We - as module authors - should always take remarks like that serious, even if the end user might not exactly be the target audience we had in mind when writing functionality.

<cbstream> [Lady_Aleena] My problem is that modules like Text::CSV_XS 
+doesn't open the files for me too.
<cbstream> [Lady_Aleena] Tux, I might use Text::CSV if it becomes a on
+e liner.
[download]

I've heard remarks like that before, but so far always ignored them, as the function/method to do so is so simple that including something like that in the module itself feels like bloat.

Now that I understand what Lady_Aleena actually wants with her data - to directly create a hash of hashes from a CSV-like file, I tried to come up with a far more generic function. Having rfc7111 fragments now, that only makes more sense :)

After a few iterations, I came up with a function that support all basic needs, yet still allows a lot of flexibility. Without going into the implementation, what I currently have done supports:

my $AoA = csv2list (file => "file.csv");
my $AoA = csv2list (data => $io, sep_char => "|");
my $AoA = csv2list (file => "file.txt", sep_char => "|", fragment => "
+col=3;5-6;0-*");

my $AoH = csv2list (file => "file.csv", headers => "auto");
my $AoH = csv2list (data => $io, sep_char => "|",
    headers=> [ "Name", "Hobby", "Age" ]);
[download]

When I apply that to the code on Lady_Aleena's scratchpad, the difference would be somethink like

la.txt:
Jan|Birdwatching|7
LA|coding|25
Tux|skiing|52

code:

my @gdr = qw( Name Hobby Age );
my %la  = lady_aleena (file => "la.txt", headings => \@hdr);
my $aoh = csv2list (file => "la.txt", sep_char => "|", headers => \@hd
+r);
my %hoh = map { $_->{Name} => $_ } @{$aoh};

result for both:
{   Jan              => {
        Age              => 7,
        Hobby            => 'Birdwatching',
        Name             => 'Jan'
        },
    LA               => {
        Age              => 25,
        Hobby            => 'coding',
        Name             => 'LA'
        },
    Tux              => {
        Age              => 52,
        Hobby            => 'skiing',
        Name             => 'Tux'
        }
    }
[download]

I'll let this sink in a bit. Obviously a function like this has a lot of potential, but should it be auto-exported? And is it flexible enough as it is like this?

The XP Nodelet informs me that I've been a member of the Monastery 10 years as of today, but it feels quite melancholy in the wake of the most recent Tiobe Index. Perl was ranked as the 9th most popular language in January 2013, but has fallen to 13th one year later.

A look at their long term history reveals that perl has fallen from an average ranking of 4 when I first entered the Monastery, to an average of tenth now, and my own experience has confirmed this: most of the work I do in perl these days is prototyping for fuller development in other languages.

What saddens me most is that I have learned a lot about software development from perl as a language, and as a community, and now it's beginning to feel that this world has increasingly little relevance for those who live outside of it.

I taught myself C++ and have used it off and on as the interest took me - as an amateur mind you, no damned professionalism here - for the last 18 years. And then I decided perl was a good idea!

I wondered how many of you other chaps had made the same change over the years and what pushed you? For me I can identify the three primary factors - (lack of) strings, (the inherent complexities of) templates and the proliferation of commercial sub-dialects like MFC or (absolutely worst of all) .NET.