I have been working on a new release of Net::SSH2 that has undergone mayor, mostly internal, changes.
There are not too many new features. The aim has been to simplify the code, made it reliable and improve the overall consistency and behavior of the module.
Most important changes are as follows:
- Typemaps are used systematically to convert between Perl and C types:
In previous versions of the library, inputs and specially output values were frequently handled by custom code with every method doing similar things in slightly different ways.
Now, most of that code has been replaced by typemaps, resulting on a consistent and much saner handling of input and output values.
- Only data in the 'latin1' range is now accepted by Net::SSH2 methods. Previous versions would just get Perl internal representation of the passed data without considering its encoding and push it through libssh2.
That caused erratic behavior, as that encoding depends on the kind of data, but also on its history and even latin1 data is commonly encoded internally as utf8.
I want to write about subroutine signatures more.
This is previous topic.
I think subroutine signatures don't need arguments count checking
Current subroutine signatures contains tow difference features
- Syntax suger of my ($x, $y) = @_
- Arguments count checking
My opinion is that this two features has different purpose. First is for syntax sugar. Second is for aruments count checking.
I think it is good to separate two features because each feature has different purpose.
I don't hope "perl subroutine + (syntax suger + argument count checking)".
I hope "perl subroutine + syntax sugar + argument count checking".
It is not good that different purpose features is mixed into one feature.
I want syntax sugar and I don't need argument count checking in my program. This is natural for me.
but there are people who want also argument count checking.
We should not assume all people want arumengt count checking.
Syntax sugar is the feature most poeple wait, but argument count checking is not.
It is safe implementaion in the Perl future that any perfomance cost don't force to user
Following is the p5p (Perl 5 Porters) mailing list summary for April 5th week. Enjoy!
The QA Hackathon (QAH) will be kicking off on Thursday morning this week, starting 4 days of intensive work on the CPAN toolchain, test frameworks, and other parts of the CPAN ecosystem. The participants will be gathering from all over the world on the Wednesday evening.
The QAH wouldn't be possible without the support of all of our generous sponsors. In this post we acknowledge the silver, bronze, and individual sponsors. Many of the Perl hackers taking part wouldn't be able to attend without your support. On behalf of the organisers and all attendees, thank you!
Git::MoreHooks::CheckIndent is a plugin
for the Git::Hooks framework.
It checks that indentation is correct in the committed files.
Please read Git::Hooks documentation on how to use plugins.
Stop the press! Git Already has …
Yes, it does indeed! The not-so-well-known
Git configuration parameter
core.whitespace is quite versatile in this respect. It supports different
values, even tabwidth to tell how many space characters an indentation (tab)
must be equal to.
: A comma separated list of common whitespace problems to notice.
git diff will use color.diff.whitespace to highlight them, and
git apply --whitespace=error
will consider them as errors. You can use prefix ”-” to disable any of them (e.g. -trailing-space):
We're still hacking away on the Veure MMORPG and things are moving forward nicely, but I thought some folks would like to hear more about our development process. This post is about our test suite. I'd love to hear how it compares to yours.
Here's the full output:
$ prove -l t
t/001sanity.t ... ok
t/perlcritic.t .. ok
t/sqitch.t ...... ok
t/tcm.t ......... ok
All tests successful.
Files=4, Tests=740, 654 wallclock secs ( 1.57 usr 0.20 sys + 742.40 cusr 15.79 csys = 759.96 CPU)
Let's break that down so you can see what we've set up. You'll note that what we've built strongly follows my Zen of Application Test Suites recommendations.
[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.]
I talked briefly about the raft of failures that CPAN Testers threw up for me to look at. I mentioned that there were roughly 3 groups of failures, and that one of them was bigger than the other two. I even gave a hint as to what it was in one of my examples:
I'm a sucker for early access to free APIs. So I quickly went forward when
Backblaze opened up access to their B2 storage API, and implemented a client
for it, Backblaze::B2. I feel a bit guilty for releasing a module without having a use case
for it myself, but instead of letting it rot on my filesystem, I'm putting
it out for others to use.