Re: Need suggestions for a module name
HI, Using ::Smart may not be so smart I have no idea for the module name but one or two about the functionality it coold offer. IMO, a module just for that functionality, although, welcome, is over the edge. maybe adding some functionality could make it worth istalling. i also wonder if there isn't another loggin module where your functionality could added. Other things that could be added: template to add information to the file name my $fh = temp_file(%M %S %s %d, 'some_text', $index) or die ... automatic addition of content within the file information about the call stack information about time or the number of iteration File::Temp::FromContext ... my less than 2 cents Nadim +++ Robert Rothenberg [Thu, Jun 16, 2011 at 09:23:50PM +0100]: While debugging a project that generated a lot of temporary files, I came upon a nifty idea: rather than name the temporary files the usual random strings, why not have the files named by the method/function that created them, e.g. instead of something like /tmp/Hf6254d85.txt, why not call it /tmp/Some_Package_Name/text_analysing_function-Hf6254d85.txt. Anyhow, I think this might be something worth uploading to CPAN. So what should it be called? I was thinking of something like File::Temp::Smart, for lack of a better name. But I am open to better ideas. Suggestions? Rob
Re: Module naming - Test::Import::DontRun
I must admit that I didn't get what you mean. Care to enlighten me with a piece of code, some flow, anything that doesn't make me feel stupid. Nadim.
Re: Module naming - Test::Import::DontRun
OK, I get what you want to do. I have seen this before. My brains being what they are lately, I don't remember where but it was not so long ago. Maybe Andy maybe someone else. Maybe even you ;) So before you go further, you can, if you so wish, look around a bit. I'm sure that other with better memory than I have will help. And, NO, it's not a stupid idea. Nadim.
Re: Module Naming
You should have what type of device in the name too. The fact that it works with serial port is not interesting and can be made clear in a sub module if multiple communication medium exist. Device::Inverter::Aurora Be more specific in the top classes if you can. The idea is to have a name for your module and still let other people use the top same classification Device::Inverter::Solar::Aurora::PVI-3 later you can make it clear that you support serial communication if it has any importance Device::Inverter::Solar::Aurora::PVI-3::Protocol::Serial IMO, Device::Serial::Protocol::Aurora describes a device which purpose it to be a generic serial interface. It _really_ doesn't matter if the module name is a mouth full. Nadim.
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 interface to cpan is one of the search engines (and the most used is not open!) and those search engines, which I'm very happy with, are as useful to applications as 2 1/2 wrench is to a Masserati retail booth. It doesn't look sexy enough. The question being, do we do something about it, and I believe it is time people realise application written in Perl exist, or do we just let it be. my favorit subject, if not the most frustrating, is why aren't there more applications that accept perl plugins? I believe this was were we lost a lot of ground to Python. It may not be important that other apps can be scripted with Perl. We have another niche. The real problem is that those plugins attract a lot of developers and we need a blood transfusion. We may be good at what we are doing ut we're not getting younger. Apps attract youngsters. As Damian said, Yes I'm getting older but also more cunning so not all hope is lost, Nadim. +++ Johan Vromans [Fri, Sep 10, 2010 at 01:04:39PM +0200]: Nadim Khemir na...@khemir.net writes: - too many apps are not under App:: - too many apps are not on CPAN That's because CPAN is module-centric and despite the heroic attempts of me and some others it has been proven impossible to get a concensus on how to write Perl applications (Real Applications, not semi-trivial scripts) and put them on CPAN. As a result, Real Perl Applications live their own, individual, cold and lonely lives instead of being welcome in the warmth of the Perl community. -- Johan
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 thinking about inheritance and traits. Were does one put a trait that can be used by unrelated classes? 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 Cheers, Nadim +++ David Cantrell [Fri, Sep 10, 2010 at 10:40:14AM +0100]: On Fri, Sep 10, 2010 at 10:44:23AM +0200, Nadim Khemir wrote: Devel::Tool::Capability But that's still not good enough. tell us more and we can help with better names. EG: is it just for tools? just development tools? ... So far, I only need to interrogate cp and tar (but would also do make too, cos so many other people hit problems with it), neither of which is particularly developmenty. But I can see either myself or others adding more in the future. -- David Cantrell | Official London Perl Mongers Bad Influence What a lovely day! Now watch me spoil it for you.
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 course it's blazing fast in any case. I did a minimal
work
in the subs. I'm not benchmarking king but the results surprised me. I
ran with a count of 10^6, 10^7 and 5 . 10^7
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?
Nadim.
Rate shift copy
shift 735294/s-- -1%
copy 740741/s1%--
Rate copy shift
copy 720461/s-- -3%
shift 739645/s3%--
Rate shift copy
shift 696379/s-- -6%
copy 742611/s7%--
with this code:
cmpthese
(
50_000_000,
{
'shift' = sub {_shift(@args)},
'copy' = sub {_copy(@args)},
}
);
sub _shift {my $self = shift; my ($x, $y, $z)=...@_ ; my $r = $x + $y + $z ;
return $r ;}
sub _copy {my ($self, $x, $y,$z) =...@_; my $r = $x + $y + $z ;return $r ;}
+++ Johan Vromans [Fri, Sep 10, 2010 at 01:06:23PM +0200]:
Eric Wilhelm enoba...@gmail.com writes:
So, say the first half of the innards of foo() are being refactored to
bar(), which will also take the original parameters in the same form:
sub foo {
my $self = shift;
my %bar = $self-bar(@_);
Don't forget SUPER:
sub foo {
my $self = shift;
my %bar = $self-SUPER::foo(@_);
-- Johan
Re: Name needed for a module to check whether a binary is GNU
Devel::Tool::Capability But that's still not good enough. tell us more and we can help with better names. EG: is it just for tools? just development tools? ... It would be nice if, someday, we agree on what Devel:: should contain. I'll hijack this thread a bit and point at one or two things I ahve noticed for some time now. Keep in mind that, as a perl dev, I don't want to force anything (not too much anyway) but since the number of PAUSE accounts has doubled lately, we may need some social coordination. - too many modules steal top levels - too many apps are not under App:: - too many modules are just one level down, eg: Devel::Something in place of Devel::SomeType::MaybeSubType::Something. - too many sub modules don't have proper documentation or could be made much more usable (I hate to say that I make the same error) - maybe we need a more dynamic naming scheme. I create NKH::XX but I want it under Devel::Tool::Capability but later the concensus is that it should be under ACME::BikeShed::Pump. We already have modules that do that but the other way around. - the taxonomy found on search.cpan.org or other is archaïc and makes findind modules more difficult than necessary. if CPAN is Perl's number two attribute then we may need to do something about it. - the search itself should allow for nearby words or misspelled words - too many apps are not on CPAN - YAPCs should have starting and naming your modules workshops (among other, and yes I'm volunteering not just complaining, and I think it can be a lot of fun too) - worst of all, authors don't fill the See Also section anymore Cheers, Nadim +++ David Cantrell [Fri, Sep 10, 2010 at 07:32:04AM +0100]: On Fri, Sep 10, 2010 at 07:11:18AM +0100, David Cantrell wrote: Sometimes you need to check whether a binary is a GNU or a normal version. For example, GNU tar has the -z option, and GNU cp has the -l option, and GNU make is Just Plan Weird. Any suggestions for how to name a module that would check this? It would be a very simple wrapper around: `$binary --version` =~ /(gnu|free software foundation)/i I'm thinking something like ExtUtils::CheckForGNUbinary. Scrap that. It should be more along the lines of checking for capabilities rather than merely for GNU-ness, with GNU-ness being just one of many capabilities. For example, GNU tar may *or may not* support the -j flag, depending on whether bzip2 support is available.
Re: Please advise before I submit to CPAN
Hi,
I see the same mistake in this module as in 99% of the modules (including
mine). Why did you write it, with examples of what was wrong with the other
modules. I said with examples.
The fathers of the CPAN nation were wise. They advised a See Also section
which should be very detailed since we never, ahem, write anything without
researching the subject thoroughly.
Were there other modules you could have enhanced?
# causes Illegal seek, but safe to ignore? Euu, well you tell us before you
release.
Did you run Perl::Critic on it?
IMVHO, because formatting issues are so not interesting,
my $self = shift;
my $name = shift;
is much better written
my ($self, $name) = @_ ;
sub get_names # return array of active processes by name
{
...
my @ret = []; #NKH, Hu!
You write:
The above example works but does not really demonstrate the full power
of the module. In a more useful implementation (e.g. using
Parallel::Jobs) the parent thread may continuously monitor all workers'
output and provide management such as spawning new workers or sending
signals to children by their pid. detach() and forget() could be called
from the run_on_finish() callback of Parallel::Jobs, depending on the
child's exit status or output.
That paragraph would totally remove any lust I'd have to use the module! If
you have a better example, give it instead for giving a lower usefulness one.
Then you go:
Note: only one pipe is created, with a pair of filehandles for uni-
directional communication, i.e. from child to parent. Bidirectional
IPC might be a nice enhancement for this module, or it may be an
indication that a more robust solution, such as POE, is called for.
Hmm, well, IMO, think again about the usefulness of the module and if you
should put it on CPAN. Frankly, I am not convinced and as you see above, I did
take some time to look around. Don't get me wrong, The more module authors the
better. Also, the better the documentation, the more users, the better.
Cheers, Nadim.
Re: Why are you releasing modules to CPAN?
What an interesting question! One that should be part of the Perl Survey. Let's face it. Most of us are ego tripped, self centric beings. In our community some are much more ego tripped than other. But the one thing that never cease to amaze me when it comes to the Perl community is how nice those islands are. I guess it's the therapeutic action of all those YAPCs, blogs, free stuff on CPAN (and maybe the large amount of consumed beer) that smooth the edges. While reading the answers I noticed that two other used the word 'Ego'. They were a bit more diplomatic as they used it for themselves while I'm piggishly using it for most. Ego is good! it's the only thing one really owns anyway. Why this long winded mail? Ego of course, I like to read myself :) but also a question that may be of interest to all of us. How do we help/make/force/lure _them_ to write modules? I'm not complaining about not enough people contributing (more is not always better anyway) just wondering why 99,% of the people using Perl are not contributing to CPAN. And what can/should we do about that? I'll leave it to Gabor to start a nice thread about that subject. In the mean time I'll go pat myself on the back a bit more. Cheers, Nadim. PS: Gabor, good initiative and great link
Re: Usage of wantarray
Hello everybody, recently, I read the following statement in a CPAN Ratings entry: this package also uses wantarray (a transgression amongst interface sensibilities). Hi Lutz, I've read that too and my reaction was what a totally ridiculous claim!. And it is based on ... nil or maybe http://www.perlfoundation.org/perl5/index.cgi?pbp_module_recommendation_commentary which is a total shame because it's like saying Let's not go to the Mars because it is already complicated to go to the Moon. If it was a a transgression amongst interface sensibilities then those sensibilities would belong to the people that have developed Perl. I believe the distinction between scalar, void and list context exists because it reflects the way we think differently in different contexts. Context differentiation is not only for core functionality. It's a pity module authors forgot that. If there was a need to defend context (a pillar of Perl) the simplest example would be the usage of @any_array in scalar context. Once you've learned that an array in scalar context returns the number of elements in the array you just can't think differently because it _makes_ sense even if it looks unreal. P6 is taking it further but maybe the P6 ppl have very bad API sensibilities. They certainly do but they correct, or will correct, them with time because that's how a language evolves. Look at http://search.cpan.org/~dconway/Contextual-Return- v0.2.1/lib/Contextual/Return.pm You can either say Wow! how do I use this intelligently or Eeek! I will never be able to master this so it is crap. This is the same kind of silly statement as Perl is not a real object oriented language. Give it a break. Perl is a complex language. You don't have to use all the tricks in the book at the same time but you still want to use a trick or two now and then. There are certainly examples of API's that got wild because of wantarray. But the ugliest transgression seen in modules is a crappy documentation and many more modules suffer of it. Again, Perl is a complex high level language. If it's too complicated, fuzzy, has bad APIs or doesn't fit one's way of thinking, is too slow or looks like line noise, we have been blessed (no pun intended) with many supra-efficient, controlling-freak, with laser-sculpted APIs, boring languages. People, take your pick. Cheers, Nadim.
Re: Yet another module naming suggestion query
To take perhaps a short break from mirror efficiency discussions, are people still up for module naming suggestions? :) I have a new module (which I'll probably release to CPAN soon enough) which basically scans a machine for information (like Puppet's Facter). The working title is Data::Scanner, but perhaps that doesn't really cover it. Perhaps Data::Collector would be better, since it collects information. I'd love for a name that also sounds like an application since it has a CLI frontend as well. I'd appreciate suggestions to make this more searchable and coherent. S. Hi, It's difficult to help you with any name as I lack information about what the module is really doing. As for Data::Scanner or Data::Collector, those would be very bad names as they are so generic they mean nothing. Most modern apps have moved to the APP::* root namespace although I believe that sub modules, part of the application, that are of general use should still be rooted in the relevant namespace. Please give us more information or better yet put the documentation on-line. Cheers, Nadim.
Re: configure_requires, build_requires, requires
pamphlet? did I miss something useful? Cheers, Nadim.
Re: module name for test data?
Hi, On Monday 28 September 2009 18.37.17 Smylers wrote: Jerome Quelin writes: - audio::mpd::common? (even if i don't think that's the best) - audio::mpd::test? this one is already used by a module in audio::mpd, but that's not a problem (i plan to move audio::mpd::test somewhere in t/lib/, so namespace would be free) - audio::mpd::testdata? - audio::mpd::common::test? - data::audio::mpd? - data::audio::mpd::test? - test::audio::mpd? I'd go for the latter (well, with some capital letters!) cos people are used to the idea that Test:: modules are used for testing rather than being part of the 'main function' of your program. But none of those names sound bad -- they're all pretty self- explanatory, so any of them would do. Smylers I'd desagree with Smylers. Test:: is for testing modules while your data is, well data, and very much special to Audio::Mpd. My vote would go to Audio::Mpd::Test::Data::+ whatever you want this would also allow you to keep your current test module where it is. I also believe that minimizing the need to upload the test data (even if it's not too much data) is a great idea. Now you could also delete the test data after the tests. Cheers, Nadim.
Re: should we still be registering module namespaces?
On Monday 17 August 2009 16.48.24 Jonathan Swartz wrote: Is there still a point to registering module namespaces on PAUSE? People registering a namespace are the exception. I don't see any need for it.
Re: Perl Critic and (honest) hash references
On Wednesday 18 February 2009 22.04.27 Dana Hudes wrote: The spelling issue in hash is resolved with the use fields pragma. That requires you predeclare (horrors!) your hash keys. That is in no way different from using strict and having to declare your variables. It might heavy but in no way horrible. And no, because I know that's the next smart thing I'm going to have to answer, I wouldn't declare array indexes. I've avoided using 'fields' till now because I didn't understand what impact it may have on run time (which is I guess negligeable) and all the nasty references to pseudo-hashes in the documentation. Anyone who hasn't mistyped a hash key can throw the first stone at 'fields'. Nadim.
Re: Module Proposal: Video::FourCC
On Thursday 08 January 2009 21.15.07 Jonathan Yu wrote: Hi all: I am looking into writing a module that will look up information on a Video file's Four Character Code (FourCC) and display some useful stuff, like a description of what the codec actually is. This will be useful for the Video::Info package in particular, because it only extracts those four bytes from the file and does nothing further. I have looked at two references [1], [2] for FourCC codes that are commonly used. These descriptions will let people figure out characteristics of video files, like the encoding that was used and the expected quality of that encoding - for instance, if the FourCC is CDVC, then we know that it was encoded using the Canopus DV Codec - thus the file was thus created on a digital camcorder, and that's the quality we can expect from it. The Wikipedia [3] page is pretty useful for explaining what FourCC is, and will hopefully establish some relevancy. What I am looking for are the community's thoughts on such a module, since it would really just be a large internal hash table with FourCC codes mapped to descriptions (or, optionally, an SQLite database, but I don't think it's really large enough to warrant that - it should fit mostly in memory). Aside from searching for the phase FourCC using the CPAN search engine, I haven't really done a whole lot of searching, and so I don't know if there is/are [a] package(s) that handle this type of thing. 1/ if it is only to provide information and no manipulation, call your module Video::FourCC::Info or something that makes it's intent clear. This also leaves the top level Video::FourCC open to other modules 2/ put all the references you found in the module, speciallyu those that will exist in the future (difficult to guess I know) and those you feel will be updated 3/ don not put all your data in the module. Although this module is very specific and unlikely to be loaded with a lot of other modules at the same time, it is good to conserve memory. Split your data and load it dynamically, compress the data if possible. We need more application oriented modules, I'd like very much to see video editing on CPAN. Maybe an idea for your future modules ;) Good luck with your module, Nadim.
Document::Aggregate
Hi, I have a little idea for a module and I'd like to get your input. When I run a project, be it a single perl module or full scale project with tens of modules and lots of documentation (user manual, requirements, analysis and design documents, ...) I always have a problem with structuring the documents together. The documents themselfs are no problems, only how they refere to each other and how to navigate in the structure. I've used wikis in the passed with various degrees of success depending on the setup and size of the project. Lately, I've been using git much more and I'm trying to have the projects self contained. This eliminates wikis that are too often have their own version control and keep things in a specific database and needs a server setup. I have looked at other type of wikis of wich Ikiwiki was close to what I want but not really the right thing. I believe that what is needed is just a way to structure the documents together and have a presentation layer. It might be useful to have the possibility to modify those documents through a wiki interface but that's not my main goal. My idea is to create set of module to: - search in the current project documents to be aggregated - apply a set of filters, eg: transform a DB to a txt file or multiple files in a single file - create the aggregation structure - render the structure in a specific format, HTML, PDF, ... If you have used the excellent http://search.cpan.org/~lyokato/Pod-ProjectDocs-0.36/bin/pod2projdocs, I want to do the same thing but on any document that might be relevant. Some of the documents will be written in wiki description language and I plan to support multiple languages (through the filters). What do you think about this idea? Is there already something out there? Would you like to join this project? What would you like to see in it? Cheers, Nadim.
Versioning modules
Hi, I never had much luck with the Version.pm module. Either because I wasn't in the mood to read the documentation or plain dumb. In any case the versioning scheme X.Y.Z is a non sense. It works nicely for someone not doing version control but for people using one a module version should not be different from what is checked in. SVK had one nice thing for it, the revisions start at 1 and grow upwards. I got fed up SVK bugs so I decided to go over to git. The problem is that git generates SHA1 as commit ids. Something like 37c8bee442237c6ccb7ad1d2cef9c2d3ac7de979 I like to generate a distribution automatically including the version number but I'm afraid the above is going to draw flames. How do you do? Cheers, Nadim.
Re: Idea: Test::Bundle module
On Sunday 23 December 2007 20.02.38 Robert Rothenberg wrote: I'm thinking that an alternative to N/A or UNKNOWN test reports for Bundle::* modules is to have a Test::Bundle module which does some rudimentary tests on a bundle: - check that NAME, SYNOPSIS, CONTENTS, DESCRIPTION and AUTHOR sections are present - check that all of the modules listed in the CONTENTS section exist on CPAN I'm assuming tests on the Pod would be done separately. The only issue with this is that CPAN will run the tests, which for some may be redundant (particularly with checking that contents exist). Comments? Rob The idea is good. I just have one simple bundle but I'd add that test to it. About testing that all the modules are available on CPAN: How do you test locally? What if the bundle gets into CPAN before the bundle? What if the installation is not done from cpan but from a local cpan or on a box without internet connection? My 2 cents, Nadim.
Re: Naming convention for thin wrappers around C libfoo.so ?
On Thursday 06 December 2007 23:11, Tim Bunce wrote: If there's a libfoo.so and I want to create a perl module/distribution that's just a very thin wrapper around libfoo, what should I call it? LibFoo Lib::Foo Lib::foo Lib::libfoo libfoo SomeCategory::Libfoo ??? Tim. Most people wrapping a library call it after what it does, hidding the fact that an existing library is used as implementation. That would eliminate anything with 'lib'. Which means that I'll go for '???' Cheers, Nadim.
Re: Module Proposal: Log::Any
Source filters can be a solution. very little overhead. I wrote
Filter::Uncomment just for that.
On Friday 07 September 2007 03:58, John Siracusa wrote:
On 9/6/07 4:14 PM, [EMAIL PROTECTED] wrote:
So why do CPAN modules eschew the use of these and invent their
own mechanisms that are almost guaranteed to be less powerful?
I agree with all your listed reason, but I think you missed one: minimum
overhead. Ideally, logging would disappear entirely from the code path
when disabled. Perl being Perl, this is rarely possible, but that doesn't
mean the other extreme--at least one method call per log line--is suddenly
attractive. Here's a brief microbench showing the range of overhead for
disabled logging:
package A;
sub a { 0 }
sub c() { 0 }
our $Debug = 0;
package main;
use Benchmark qw(cmpthese);
my $o = bless {}, 'A';
cmpthese(1000, {
method = sub { $o-a $o-a },
sub= sub { A::a() $o-a },
var= sub { $A::Debug $o-a },
#const = sub { A::c() $o-a },
});
Rate methodsubvar
method 1176471/s -- -13% -92%
sub 1349528/s15% -- -91%
var15625000/s 1228% 1058% --
As you can see, though sub vs. method is a small difference for the best
case (sub and method both returning a constant 0), the $Debug ... case
beats it by enough to be significant.
(I commented out the constant case because it's best case, as close as Perl
can come to actual code removal (depending on where/when the constant sub
is defined).)
So I guess what I'm saying is that the final thing that would stop me from
using Log::Any everywhere (meaning also in performance-critical code) is
the overhead for the common (production) case of logging being entirely
disabled. How about providing all three methods of checking as part of the
API?
$log-debug(...) if $log-is_debug(); # method
$log-debug(...) if Log::Any::is_debug(); # sub
$log-debug(...) if $Log::Any::Is_Debug; # var
Yes, a backend (maybe the default/built-in backend, in fact) could chose to
implement the sub by calling a method and the var with a tie, negating a
lot of the performance benefit, but at least the door is open for a simple
backend to implement the var and sub directly, yielding the full benefit.
-John
Re: Module Proposal: Package::Data::Inheritable
nntp.perl.org wrote: Hello all. I've written a module to deal with the issue of inheritable class data (yes, yet another one). What's peculiar with it is that it doesn't rely on accessor methods. After declaration, you can use the variables just like any other package variable but you can inherit and override those variables in other packages/classes. I'm thinking of calling the module Package::Data::Inheritable which should reflect the emphasis on package variables rather than on classes. Before uploading to CPAN I would like to check whether I missed some module that does the same and if the proposed name/namespace is good. Sounds like a bad idea to me. mainly because you do not explain what you want to achieve and why you want to achieve it that way. the explainations have been too 'high level' for _me_ to understand. In another mail you explain that you ccan't use constants but the excellent Readonly module does what you want. Nadim.
