Re: Name needed for a module to check whether a binary is GNU

There is a tendency to put apps under App::. I don't know if those meet the "more than trivial script" requirement or not and it's not all that important. The other problem is that Application support modules have historically been under App:: too. IMVHO, Apps are not unders CPAN because the inte

Re: Name needed for a module to check whether a binary is GNU

Maybe Devel:: is completely wrong; I'm starting to belive that. App::Capability for the framework and APP::Capability::* for the apps themselves. Maybe App::Capabilit::Toolchain::Gnu could load all thos apps and even tell you which one are available or not. While thinking abuot this I started th

Re: my $self = shift

Hmm, maybe I like this shift business and I'll use it. It makes sense. but I never thought about it because I don't like manipulating arrays without a good reason. It's micro optimisation and readability is better (sometimes) although that added line does disturb me a bit. So I benchmarked it. of

Re: my $self = shift

On Mon, Sep 13, 2010 at 08:00:01AM +0200, Johan Vromans wrote: > Aristotle Pagaltzis writes: > > You don???t want to reach inside an object just > > because it happens to be hash-based. > Interesting. For Getopt::Long (that can take an optional hashref as its > first argument) I got explicit reque

Re: Name needed for a module to check whether a binary is GNU

On Mon, Sep 13, 2010 at 12:53:24PM +0200, Nadim Khemir wrote: > IE: what you are looking for is to add a trait to the tar app so it can > give you some info about its capabilities No, I'm not. I really don't want to require that everyone in the whole world mess about with their tar for my benefi

Re: Name needed for a module to check whether a binary is GNU

I fail to see how you adding a trait to someone's App::Tar forces anyone to mess with anything. +++ David Cantrell [Mon, Sep 13, 2010 at 02:46:40PM +0100]: > On Mon, Sep 13, 2010 at 12:53:24PM +0200, Nadim Khemir wrote: > > > IE: what you are looking for is to add a trait to the tar app so it ca

Re: my $self = shift

On Mon, 13 Sep 2010, Nadim Khemir wrote: The surprise was that there was an up to 6% speed difference and the biggest surprise is the inversion of which method is fastest. I'm curious, someone care to comment? In any real application, it's highly unlikely that the spped will be affected by t

Re: my $self = shift

On 10-09-13 07:50 AM, Nadim Khemir wrote: I'm curious, someone care to comment? I'm surprised that a specialized variable like @_ is not optimized for shift. All that is needed is to more the pointer to the next item in the array. The space used by the previous first item need not be recov

Re: my $self = shift

Shawn H Corey said: > On 10-09-13 07:50 AM, Nadim Khemir wrote: > > I'm curious, someone care to comment? > > I'm surprised that a specialized variable like @_ is not optimized for > shift. All that is needed is to more the pointer to the next item in > the array. The space used by the previous

Re: my $self = shift

On Mon, Sep 13, 2010 at 11:48 AM, Ryan Voots wrote: > sub foo { >  my $foo = shift; >  $foo = "bar"; } > > would not doing a copy for shift like that cause it to act like > > sub foo {$_[0] = "bar"} does? > Well, you know what they say: Try It And See.

Re: my $self = shift

On 10-09-13 01:16 PM, Jonathan Yu wrote: Well, you know what they say: Try It And See. I thought that was: TITS (Try It To See) -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it

Re: my $self = shift

* Johan Vromans [2010-09-13 08:05]: > Aristotle Pagaltzis writes: > > >You don’t want to reach inside an object just because it > >happens to be hash-based. > > Interesting. For Getopt::Long (that can take an optional > hashref as its first argument) I got explicit requests from > users to allow