Re: Is Sort:Naturally a Little Off?
Shawn H Corey writes: > And my environment is: > > $ env|grep LC_|sort > LC_ADDRESS=en_CA.UTF-8 > LC_IDENTIFICATION=en_CA.UTF-8 > LC_MEASUREMENT=en_CA.UTF-8 > LC_MONETARY=en_CA.UTF-8 > LC_NAME=en_CA.UTF-8 > LC_NUMERIC=en_CA.UTF-8 > LC_PAPER=en_CA.UTF-8 > LC_TELEPHONE=en_CA.UTF-8 > LC_TIME=en_CA.UTF-8 I think that if you don't have LC_COLLATE or LC_ALL set, then the value of LANG is used, so that could also be relevant here. I can reproduce your results when I use en_CA.utf8. So it appears that en_CA.utf8 and en_GB.utf8 sort ‘a’ and ‘A’ the opposite way round to each other. I wonder why. (Not relevant to any bug in Sort::Naturally, but it's now intriguing me.) Smylers
Re: Is Sort:Naturally a Little Off?
Shawn H Corey writes: > I was testing different sort routines and I think I stopped a bug in > Sort::Naturally (see attached script). It's output is: > > unsorted : 4 A X i 1 x 10 a B ä y z į C Ä b c Į Y Z än and ÄND > And Any ant Äm Äs > > no locale, perl : 1 10 4 A And Any B C X Y Z a and ant b c i x y z Ä > ÄND Äm Äs ä än Į į > no locale, naturally : 1 4 10 A a ä Äm And and Ä än ÄND ant Any Äs B b C c > i Į į X x Y y Z z That does look odd. Which locale are you running this under, which version of Perl, and which version of Sort::Naturally? Also, when I first ran your script I initially got lots of: Wide character in say at ./naturally line 23. Adding this made Perl encode the output properly and the warning go away: use open ':locale'; But that you didn't need to do that makes me think there's something different about your set-up. Also, even your ‘no locale, naturally’ line apparently *is* affected by the locale! With LC_COLLATE=C, I get: no locale, naturally : 1 4 10 A a And and ant Any B b C c i X x Y y Z z Ä ä Äm än ÄND Äs Į į Whereas with LC_COLLATE=en_GB.utf, it's: no locale, naturally : 1 4 10 a A ä Äm and And Ä än ÄND ant Any Äs b B c C i į Į x X y Y z Z Note that still isn't the same as your output, because capital letters are sorting after lower-case, rather than before in yours. That's with Perl v5.30.0 and Sort::Naturally 1.03. > Is the Ä out of place for the Sort::Naturally line? It looks it to me. But there's clearly far more going on here than I understand. Smylers
Re: Module naming -- processing 3D JPEG files...
BC writes: > I'd like some feedback and advice for naming some modules I am > contemplating. > >Image::Stereo::MPO >Image::Stereo::JPS >Image::Stereo::JPG Sounds good to me — you've clearly considered this carefully, and your explanations make sense. Smylers -- http://twitter.com/Smylers2
Re: A funny module that shortens one-liners - is it worth global namespace?
Konstantin S. Uvarin writes: > Hello everyone, > > > 1perl -e '$x = My::Very::Long::Module->new( foo => 42 ); print $x->foo' > > Good point. And there's also L module https://metacpan.org/pod/L which > does more or less what I propose. L looks to be the equivalent of Class::Autouse :superloader, but slightly different from your proposal — it still requires typing the ‘new’. > So I think this topic is covered. =) Your variation is as valid as anybody else's. If you prefer the syntax or particularly way of working with your module rather than the existing ones, then others might too. Don't be discouraged from publishing yours as an alternative for users to choose from. Smylers -- http://twitter.com/Smylers2
Re: Namespace advice for Git-related package
James E Keenan writes: > I am in the process of developing a CPAN library which I am > considering calling Git-Multisect-Perl. ... > > 'Multisect::' is chosen to contrast with 'bisect'. That hadn't occurred to me. I read it as a contraction of ‘multiple sections’ or similar. > When we speak of bisection in the context of, say, Perl 5 core > development and use of Porting/bisect.pl, we're usually looking for a > single answer to a question, e.g., at which specific commit did this > test file start to experience failures. Recently, however, we have a > case where a file failed in different ways over many months. That's > the actual use case which led me to develop this library. However, ‘bisect’ is a well known word for this activity. Sometimes with naming things it's clearer to be familiar-but-approximate rather than accurate-but-obscure. Once the name has got somebody's attention, the docs can explain nuances. I think Git::MultiBisect or Git::Bisect::Multiple get the idea across more obviously. > The '::Perl' in the namespace is intended to say, "This is a way to > apply the concept of multisection to typical needs in Perl development Unfortunately I don't think it does that. A suffix of ::Perl usually indicates that it's implemented in Perl — either because there's also an ::XS variant, or it's a port of a library that originated in Java or some other language. I'm not sure there is anything which indicates ‘typical for Perl development’. I'd omit that aspect from the name. > we don't want to foreclose the possibility of future libraries which > use git to perform multisection in other problem spaces." Let any hypothetical future rival Git-multi-bisect distribution — and there may not be one — come up with an adjective that distinguishes itself from yours. Alternatively, Devel::Git::MultiBisect would indicate that this is a tool for Perl development use. Good luck! Smylers -- http://twitter.com/Smylers2
Re: Naming stuff is hard.. Data::Topology::JSON
Aaron Trevena writes: > On 24 October 2016 at 09:49, Smylers <smyl...@stripey.com> wrote: > > > If your module is Json-specifiec and there already exists a JSON:: > > top-level namespace, then I think it's much better to put it > > somewhere under JSON:: than Data::, which is so generic it tells > > users very little about the module's purpose. > > The main idea/purpose isn't json specific - this could apply to mongo > or any other nosql data source, I'm using it for postgres jsonb data > in this project. OK. In that case Data::Topology::JSON probably doesn't work either, for the same reason. > If I was looking for a way to get RDF or other metadata from mongo I > wouldn't be looking for JSON::Schema::Inferred. True. There's an awkward balance between picking a name that is too specific, and therefore misleading, and one that's so general that it's too abstract for readers to glean what situations it does cover. Smylers -- http://twitter.com/Smylers2
Re: Naming stuff is hard.. Data::Topology::JSON
Aaron Trevena writes: > I don't have a clean-room data set I can use as an example right now, > but essentially I'm parsing json, making a note of the names and > hierarchy of the fields, using dot-notation (i.e. like mongo) to name > nested fields, infer their type (i.e. ip address, mac address, epoch > time, etc) from data, and get a sample of the data. From that I can > then output a JSON::Schema or other documentation describing the data > itself. If your module is Json-specifiec and there already exists a JSON:: top-level namespace, then I think it's much better to put it somewhere under JSON:: than Data::, which is so generic it tells users very little about the module's purpose. How about JSON::Schema::Inferred? Smylers -- http://twitter.com/Smylers2
Re: Boolean As a Top Level Name
Paul Johnson writes: > To be clear, my tongue was firmly in my cheek for that last > suggestion, but that doesn't seem to travel too well over SMTP. Sure, I realized it was a cheeky suggestion. But there are enough UK folk about who complain about -ize being “an Americanism” that there might've been readers who genuinely thought ‘minimize’ is wrong in the UK. > And the myriad smileys which adorned my initial message seem to have > been similarly lost. Since my previous mail, my MP3 player started playing this podcast at me, on the linguists of “maths”: http://relprime.com/thelexicon/ So maybe Math::Boolean::Minimise would be the best name, to annoy everybody equally? Smylers -- http://twitter.com/Smylers2
Re: Boolean As a Top Level Name
Paul Johnson writes: > - The Logic namespace looks like a mess, but I think this module would >fit better in there: Logic::Minimize > - The correct spelling is Logic::Minimise UK English allows both -ize and -ise endings on many verbs*; USA English only has -ize. So picking the one that's valid in both makes more sense. There are plenty of cases (like ‘colour’/‘color’) where UK and USA spellings are disjoint and you just have to pick one which will be ‘wrong’ somewhere, but this isn't one of those cases. Smylers * I believe -ize was the original UK form, in use at the point when the USA forked English. The UK later took on -ise as an alternative, influenced by French, but the USA didn't cherry-pick that patch to their branch. Oxford dictionaries use the -ize spellings in headwords and list -ise as acceptable alternatives; other UK dictionaries tend to do it t'other way round, but all allow both. http://www.oxforddictionaries.com/definition/english/minimize -- http://twitter.com/Smylers2
Re: Comment on module name Data::ETL
Robert Wohlfarth writes: > I'm weighing 3 ideas... > 2. Create a top-level namespace for ETL. > > Idea 2 looks like so... > * ETL > * ETL::Extract > * ETL::Extract::Excel > * ETL::Extract::DelimitedText > * ETL::Extract::XML > * ETL::Load > * ETL::Load::MSAccess Not necessarily. That would be effectively claiming the ETL:: namespace is for your suite of modules. An alternative would be to create the ETL:: top-level namespace and then put your framework under another level of hierarchy there, leaving space for other ETL modules to share ETL::. As in: • ETL::$Brand • ETL::$Brand::Extract • ETL::$Brand::Extract::Excel • ETL::$Brand::Extract::DelimitedText • ETL::$Brand::Extract::XML • ETL::$Brand::Load • ETL::$Brand::Load::MSAccess — where $Brand is a word/phrase of your choice (either just a fanciful name you like, or one you think sums up your particular ETL module suite over other (potentially yet to be written) options. > #2 is short and sweet. On the downside, acronyms are context > sensitive. If potential users of your module are likely to know the term ETL and that's something they'd search for, then it's still a useful name. That probably matters more than for somebody outside the field randomly encountering the name of your module being able to tell instantly what it's for. Obviously a name having both of those qualities would be ideal, but at least somebody who encounters the ETL::Taupe::Extract module can look up its docs, whereas it'd be sad for a would-be fan of your module never to learn of its existence. Smylers -- http://twitter.com/Smylers2
Re: Comment on module name Data::ETL
Robert Wohlfarth writes: > I am looking to release a collection of modules for converting data. > The modules read data from a source, convert the data, then add it > into an SQL database. > > The modules are named like this... > * Data::ETL > * Data::ETL::Extract > * Data::ETL::Extract::Excel > * Data::ETL::Extract::DelimitedText > * Data::ETL::Extract::XML > * Data::ETL::Load > * Data::ETL::MSAccess > > In my mind, ETL means "Extract-Transform-Load". That wouldn't've occurred to me, but the Wikipedia page for ‘Extra, transform, load’ is the top link when searching DuckDuckGo for “ETL”, so it seems reasonable to use it in a module name if your target audience is people already working in the field and familiar with its jargon. > Is "Data" an appropriate place? Yes ... and no. Data:: is appropriate for pretty much every module on Cpan, in that an awful lot of code does stuff with data. That makes it a suboptimal namespace, because it doesn't define what's specific about this particular module. In particular, it didn't to me suggest databases, or even data warehousing (which the ETL Wikipedia page suggests is the main use of ETL). It'd be good for the name to indicate that field in some way. > Thoughts on the naming convention "Data::ETL"? The combination of a very broad namespace and an acronym makes it hard to guess at the area of the module — for instance that would be an equally good name for a module that processes data searching for extra-terrestrial life ... If the database-loading part uses DBI connections then the DBIx:: namespace would be good for indicating that. Unfortunately for you, DataWarehouse::ETL is already used by another module. Ideally you'd mention that module in your docs, explaining to new users the difference between them. If your name can help to indicate the distinctive feature of yours, so much the better — but often that isn't possible if they are simply different approaches to the same problem. One possibility for a suite of connected modules that only really work together is to concoct a ‘fanciful’ brand name for the framework, like Moose or Catalyst and put all your modules under either $Brand:: or something like DataWarehouse::$Brand::. A framework name works well if, say, your $whatever::Extract::Excel module is only intended to be used with other modules in your framework and doesn't really make sense as a standalone module for somebody just wanting to extract data from an Excel spreadsheet (and get back a Perl data structure they can do what they want with). The brand name indicates that it's part of the framework and to be used with that. Hope that helps. Smylers -- http://twitter.com/Smylers2
Re: throw away module namespace
Neil Bowers writes: You could put the modules in Acme::, which is another way of saying “you can’t rely on this in any way”. For example if you think the module is going to be Yak::Shave, you’d create Acme::Yak::Shave. If the name settles down, then you can release a non Acme version. Then down the road you can delete the Acme:: version. Some good suggestions in this thread, including from Neil, but the above strikes me as an abuse of Acme::. If I encounter a module in Acme:: I expect it to be a genuine silly module, not a work-in-progress of a serious module. If everybody starts putting unfinished serious modules in Acme, it makes it harder to find the fun! Smylers -- http://twitter.com/Smylers2
Re: MetaCpan SEO (Was: How to add your avatar to Google search results involving CPAN modules)
Gabor Szabo writes: I tried to collect my thoughts and your comments on getting more people to use MetaCPAN instead of search.cpan.org. It is not going to be easy and thus it got a bit long: http://szabgab.com/moving-from-sco-to-metacpan.html Thanks for writing that. I'd be glad to read your opinion on this! I think part of the problem is that Google's algorithms need to change — not just for MetaCpan, but for various content. The situation is basically this: • A site has existed for many years, over which time many people have linked to it, including putting links in automated systems and directories. • A rival site appears, and many people start linking to it in places where previously they would've otherwise linked to the old site. Some of this will be changing links from the old site to the new one, but much of it will be simply when creating new links. • Because of the history, the old site still has many, many more links to it than the new one does. And automated systems linking to it mean that new links are being generated to it. That should be something Google's algorithms can detect, and use to favour the new site over the old one. It can spot the introduction of the new site and realize that it has similar content to the old one. If it spotted links being changed from the old one to the new one (but not t'other way round, or at least in far greater numbers in one direction) that should be a sign that people overall deem the new one to be superior. Spotting that new links are going to the new site instead of the old one is harder, but not impossible to detect. Until now this I'm guessing this hasn't been a big problem for Google, because ‘website has been popular for a decade then a better rival comes along’ requires at least a decade to elapse. But as time goes on, Google is going to have to do something like the above detection to avoid becoming an archive of websites that used to be useful. Of course that doesn't mean that Google will fix this in a timely manner for MetaCpan. So an alternative course of action would be: • Get a job at Google (they seem to always be recruiting). • Join the search algorithm team. • Enhance the algorithm to address the above. Any takers? Smylers -- The UK gov's proposed gagging law will suppress protest and campaigning by charities and political groups. Read more: http://civilsocietycommission.info/ Please sign this petition: http://38d.gs/1cJ9ViA Oxfam • BHA • Quakers * Countryside Alliance • League Against Cruel Sports • CND
Re: How to add your avatar to Google search results involving CPAN modules
Gabor Szabo writes: In this article I explain how you can get your avatar to Google search results involving your CPAN contribution: http://szabgab.com/claiming-your-cpan-authorship-at-google.html I hope many CPAN authors will implement this (if you already have a G+ account it takes less than reading this e-mail) as I believe this can drive more people searching on Google to better results on MetaCPAN. So Google are now giving enhanced appearance in search results listings to people who are prepared to sign up to a Google+ account? That doesn't sound very different from Google giving prominence in search results to people who pay them for that privilege. (Not criticizing your article at all, Gabor — given that Google are doing this, it makes sense for Cpan authors who are on Google+ to link their accounts as you describe.) Smylers -- The UK gov's proposed gagging law will suppress protest and campaigning by charities and political groups. Read more: http://civilsocietycommission.info/ Please sign this petition: http://38d.gs/1cJ9ViA Oxfam • BHA • Quakers * Countryside Alliance • League Against Cruel Sports • CND
Re: please help me name a module
Greg Lindahl writes: On Thu, Sep 12, 2013 at 05:38:00PM +0100, Smylers wrote: How about Vehicle::Tesla::ModelS then? Does putting Device:: in front of that lot actually add anything, other than to the unwieldiness of the name? Vehicle:: doesn't generalize very well to toasters, refrigerators, etc. Does it have to? If modules for such household goods come along, how much does it help users for those modules to share a namespace with modules for vehicles? (Note they can share implementation, or not, independently of whether they share a namespace.) If a new top-level name is a good idea, It isn't a good idea _per se_; it's only a good idea if none of the existing ones seem to fit. I'd suggest an Internet-of-Things top-level, Thing:: or IoT:: or IOT:: Would somebody who has a Tesla car (or indeed a toaster) think of searching for IOT? Would somebody seeing IOT in a module name realize what it means? (I don't think I would.) “Thing” is such a generic word that I don't think prepending Thing:: adds any meaning at all. While you're using “thing” in quite a specific way, almost anything could be thought of as a thing. I'd say Device:: is more meaningful than Thing::. This particular module, btw, will probably be good for future Tesla vehicles; it's anyone's guess how the API will evolve. In that case go with your instinct and name it ::Tesla. If other Tesla APIs come into being (either for different cars or later versions for the Model S) your module can always be extended to cope with those somehow. Smylers -- Stop drug companies hiding negative research results. Sign the AllTrials petition to get all clinical research results published. Read more: http://www.alltrials.net/blog/the-alltrials-campaign/
Re: please help me name a module
David Precious writes: On Thu, 12 Sep 2013 12:15:22 +0100 David Cantrell da...@cantrell.org.uk wrote: I'd go for Device::Car::Tesla(::ModelS)?. Car, not Auto, because in most of the English-speaking world auto means automatic, not automobile. Also, I would suggest including the ::ModelS, as it's entirely possible that Tesla will release budget modules in future which won't support all the cool stuff. Bill Ward writes: I'd suggest Vehicle instead of Car since future instances might be trucks, vans, motorcycles, etc. How about Vehicle::Tesla::ModelS then? Does putting Device:: in front of that lot actually add anything, other than to the unwieldiness of the name? Smylers -- Stop drug companies hiding negative research results. Sign the AllTrials petition to get all clinical research results published. Read more: http://www.alltrials.net/blog/the-alltrials-campaign/
Re: What to call a module that rewrites Perl code
Robert Rothenberg writes: So what should it be called? I'm thinking Perl::Rewrite is the best name. Hi Rob. Hope Yorkshire is treating you well. Perl::Rewrite sounds reasonable to me. - Perl::Refactor - except refactoring has a technical meaning that I don't think applies I think that's OK, too. It's better for a module name to be generally helpful in indicating its purpose rather than precisely correct in all circumstances. If you see the major use of your module to be for refactoring Perl, then I think you should feel free to use this name. Smylers -- Stop drug companies hiding negative research results. Sign the AllTrials petition to get all clinical research results published. Read more: http://www.alltrials.net/blog/the-alltrials-campaign/
Re: Module naming and a couple other questions
Joshua Megerman writes: I'm a new member of PAUSE, looking to upload my first module. Hi Josh. Thanks for sharing with the Perl community. 1. I have developed a module that provides an XS interface to the WMI library (libasync_wmi_lib.so) that is generated by building the Zenoss WMI software and provides a method of calling the WMI client without forking to use the wmic binary. My initial inclination was to just call the module WMIClient, but I'm starting to think that WMI::Client or some other name would be better. The only 2 modules I currently see on CPAN that provide similar functionality are DBD::WMI and Win32::WMIC, both of which collect and parse the output of `wmic`, which is what my module is designed to avoid. Suggestions on the best way to name it would be greatly appreciated. After reading that, I'm afraid I'm still unclear on what your module does; WMI isn't something I've heard of before. If it's something only of use with Windows, then putting under the Win32:: namespace would be useful, to clearly demark that. Using a suffix ::Client is probably better than Client, if you think a suffix is needed at all. Could an equivalent ::Server module ever be uploaded? Or are all users of WMI effectively clients of it, so ::Client is redundant. 2. Said module currently has 1 function, wmiclient, which I was planning on exporting by default. I see that it's generally recommended not to do that, Make uses import the function explicitly. If you later regret that decision, you could change to exporting it by default. Whereas if you initially export it by default, you're stuck with continuing to do that in later versions, so you don't break code of people relying on it. 3. The module uses several chunks of C code from the WMI package itself, which are distributed under the GPL. My initial license thought was to distribute the .xs file as GPL with the rest of the module package under the same terms as Perl itself, but I don't know if that's a valid licensing model. Can I do that, or do I need to distribute the entire module as GPL (which is OK with me). Is this a problem for distribution via CPAN? Distributing the entire thing as GPL is certainly fine by Cpan, and would definitely comply with the WMI package's terms. You could put a note in the doc asking people to contact you if they would find your module more useful under a different licence. That way you can postpone researching the matter further until somebody does (or possibly never). Cheers Smylers -- New series of TV puzzle show 'Only Connect' (some questions by me) Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/onlyconnect
Re: RFC: the Author:: namespace
Pedro Melo writes: On Sat, Sep 8, 2012 at 6:18 PM, sawyer x xsawy...@gmail.com wrote: On Sat, Sep 8, 2012 at 9:49 AM, Pedro Melo m...@simplicidade.org wrote: * the author can include that module as a dependency on his projects like he does with all the other CPAN dependencies. The second one is the most important to me. Just because it is a module that you might not use, it might be a module that is installed on your system as a direct dependency of other modules I have on CPAN. That's a terrible thing to do! Please, for the love of all that is good and holy, never put any project to depend on a personal distribution of your favorite modules. I will most likely refuse to use it entirely for that reason alone. Declare what you're using, not what you like to have installed! huhs?? I'm telling you that I'm reusing modules under A::M::something on other CPAN distributions. It's not a personal distribution, I'm not depending any dist on my Task::BeLike::MELO. I just have small reuseable modules, Hi Pedro. If you have a small reusable module which is used by several other Cpan distributions then of course it belongs on Cpan. What I don't understand is why you want to have your username as part of the module's name. Surely it's better to upload it with a name that simply indicates what it does, then your other distributions can use it on that basis -- and perhaps other people will see that, like it, and start using it too? I'd feel wary about using anything which is named with its author's username (except in a situation like Dist::Zilla or BeLike where I'm explicitly trying to be like a particular author), cos that sounds like it's personal to that author. that I don't think have a proper place on CPAN right now, What do you mean by that? If you aren't sure whether something would be worthwhile, upload it anyway. If necessary write in the Pod that the interface is subject to change and anybody using it should e-mail you to let you know. Cheers Smylers -- New series of TV puzzle show 'Only Connect' (some questions by me) Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/onlyconnect
Re: How do I arrange for Makefile.PL to create a modulino instance script?
Buddy Burden writes: Guys, It's fairly unusually for a piece of code to be appropriate both as a stand-alone program and as a module loaded by other programs. ... Perhaps David's original question would have been more clear with a slightly more targeted footnote reference: http://www.drdobbs.com/scripts-as-modules/184416165 Thanks. Yes, I was unaware of that. But ... I'm not still not clear on the advantage of having the run function and the if caller test be in the module itself, rather than a separate file which use-s the module. Apart from anything else, it seems hard to come up with a filename which makes both a good command name for users and works well as module name in a use line by something else which wants to use the module. Cheers Smylers -- http://twitter.com/Smylers2
Re: sudo in Const::Fast
Shawn H Corey writes: On 12-07-19 01:07 PM, Smylers wrote: Please can you run: $ cpan -J | grep sudo 'mbuild_install_build_command' = 'sudo ./Build', 'make_install_make_command' = 'sudo /usr/bin/make', Great, so we've found where sudo is coming from. Your cpan command has been configured to use sudo for the actual 'install' step of installing modules. The puzzle is now where this is coming from, given that you couldn't find sudo in your cpan config files. Let's first be sure precisely what commands cpan should be running. Please can you post the output of running this: $ grep 'install.*command' ~/.cpan/CPAN/MyConfig.pm Smylers -- http://twitter.com/Smylers2
Re: sudo in Const::Fast
Shawn H Corey writes: On 12-07-19 10:43 AM, Leon Timmermans wrote: On Thu, Jul 19, 2012 at 1:38 AM, Shawn H Corey shawnhco...@gmail.com wrote: I tried installing Const::Fast and it runs sudo. Why is such a blatant security risk in a CPAN module? And are there more? Like others have already said, I'm not using sudo in Const::Fast. It has a very boring and default installer. If you had checked the Makefile.PL or tried installing it without a cpan client you would have realized this ;-) I didn't authorize any use of sudo, so someone else put it in there. Do you have a file called ~/.cpan/CPAN/MyConfig.pm? If so, are there any lines mentioning sudo in there? Smylers -- http://twitter.com/Smylers2
Re: sudo in Const::Fast
Shawn H Corey writes: On 12-07-19 11:34 AM, Smylers wrote: Do you have a file called ~/.cpan/CPAN/MyConfig.pm? If so, are there any lines mentioning sudo in there? No, none. Well that rules out one possibility, so we must be getting closer! Please can you run: $ cpan -J | grep sudo and: $ env | egrep -i 'perl|sudo' and paste the output of both back here. Smylers -- http://twitter.com/Smylers2
Re: Naming of Perl module
Bill Ward writes: File::RegexMatch? I think having ::Find:: in there would be better, so that it's immediately obvious that this module performs a similar task to the other modules already named like that. File::Find::Regexp, perhaps? (Note that 'Regexp' with a 'p' appears to be the canonical Perl way of spelling it: % perl -E say ref qr// It's also a superset of the spelling 'Regex', so searching for 'Regex' should still find it, whereas searching for 'Regexp' wouldn't match 'Regex'. On the downside, 'Regexp' is considerably harder to say than 'Regex'.) Smylers
Re: Naming of Perl module
Bill Ward writes: On Wed, Dec 14, 2011 at 3:46 AM, Smylers smyl...@stripey.com wrote: Bill Ward writes: File::RegexMatch? I think having ::Find:: in there would be better, so that it's immediately obvious that this module performs a similar task to the other modules already named like that. File::Find::Regexp, perhaps? I like that, but that implies that its interface is similar to File::Find. Not really. File::Find::Rule doesn't have a similar interface to File::Find, for instance. Smylers
Re: avoid running CPAN as root
Andy Armstrong writes: On 12 Jan 2010, at 16:59, dhu...@hudes.org wrote: sudo requires that you enter your password each time you invoke it. Often sudo will be configured with a 15 minute grace period which means you only need to authenticate for the first make install / ./Build install. Though that can be irritating if your install hangs at that point, waiting for you to provide a password. An alternative is to pre-authenticate sudo with the -v flag, so that even the first install will become root without prompting: % sudo -v cpan Acme::MetaSyntactic Smylers -- Watch fiendish TV quiz 'Only Connect' (some questions by me) Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/programmes/b00lskhg
Re: module name for test data?
Ovid writes: If these corpuses (corpi?) Corpora (similar to opus - opera). Smylers
Re: module name for test data?
Jerome Quelin writes: On 09/09/28 20:08 +0100, Paul LeoNerd Evans wrote: ... I'd make sure to include the word Test (capitalised) ... yes, i never capitalize when i'm writing (except code, of course). so the proposed module names would be capitalized correctly, of course. That's what I guessed; apologies if it came across as overly pedantic. But in some ways module names _are_ code, and I've previously encountered users on case-insensitive file-systems writing code with module names all lower-case -- which runs for them, but not elsewhere -- so I thought it worth checking. Smylers
Re: module name for test data?
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
Re: Name for barcode-reading module?
Keith Ivey writes: Okay, it seems like Barcode is the best namespace for it. ... the module is essentially OCR for barcodes Barcode::Reader ... could give people the idea that it's for use with barcode readers ... Right now, I'm leaning toward Barcode::Finder, or maybe Barcode::Recognizer. Anyone have any better ideas? Barcode::OCR? Barcode::Decode or ::Decoder? Barcode::Interpreter? Barcode::Read? Barcode::Image2Numbers? Smylers
Re: Name for barcode-reading module?
Keith Ivey writes: (It seems like object-oriented modules should have names that are nouns, I agree. (The non-noun suggestions were in case your module isn't object oriented.) Smylers
Re: Module::Install is a time bomb
Ken Williams writes: I'll say it again though: there is no such thing as inc::Module::Build. We're not just putting M::B in an inc/ directory and loading it. The semantics we're working on for people to use are: use lib 'inc'; # Where latest.pm lives use latest 'Module::Build'; # Knows to look in inc/bundled/ The general-purpose logic for doing version comparisons lives in latest.pm . But what if the bundled version of latest.pm is buggy and I already have a later latest.pm installed on my system? That will use the wrong one!! Smylers
Re: Naming help - XML plist (Apple/Mac/iTunes)
Jenda Krynicky writes: From: Aristotle Pagaltzis [EMAIL PROTECTED] * Jenda Krynicky [EMAIL PROTECTED] [2008-06-14 01:25]: I don't like XML::Plist. I would not have any idea what kind of list is it supposed to mean. And I bet there's quite a few others in the same situation. If it's something Apple specific, let's say that in the name. Whether it'd be Apple, Mac or iTunes I don't care. If you don´t know what a plist is, you are not part of the target audience for the module in any case. Maybe XML::ApplePlist. I know I'm not in the targeted audience if it meantions Apple, Mac or iTunes, I don't know I'm not if it says just Plist and is in a namespace that's inhabited mostly by all kinds of XML parsers, general and specific alike. Quite. Which in itself is a problem. I think the specific parsers should actually never been included in that namespace. I think the XML:: namespace should be inhabited by general XML processing modules and by formats and technologies that are more or less part of the XML suite of standards. DTD, Schema, XSLT, XPath, RSS?, ... Using XML:: makes sense if the purpose of the module is to do something with XML (Hmmm, I've got this XML data -- I know, a plist would be a good way of handling that). Whereas if it's purpose is to handle a particular Apple format (I've got this plist; how can I deal with that in Perl?), then that should be what is emphasized in the name. Smylers
Re: Naming help - XML plist (Apple/Mac/iTunes)
Bill Ward writes: And being used on the NeXT argues even more against Mac:: or Apple:: as a prefix. Maybe. But I don't think it's a problem if a module doesn't precisely fit into the namespace its using. It's better to have a recognisable namespace which many people would associate with what your module does, than something so esoteric (or generic) that it conveys very little to most people. If plists are generally an Apple-y thing, and most people would associate them with Apple, then it isn't terrible to put them a namespace which labels them as such. I think I like this best... Data::PList::XML (I'd use caps for the L). Because it is generically Data:: Most things computers touch are data! XML is generally used for data, so all XML::* modules could be Data::XML::* instead, but that wouldn't really help. Most existing modules under Data:: seem to be more generic than dealing with a particular format (though there is Data::ICal). Only thing is, my utility only parses them, it doesn't write them. That's definitely worth including in the name somewhere. Apart from anything else you want to leave room for somebody else to create and name a module which does write them. Smylers
Re: How to challenge a cpan-testers test result?
Eric Roode writes: On Mon, May 26, 2008 at 5:22 PM, David Landgren [EMAIL PROTECTED] wrote: Eric Roode wrote: On the first line above, we see that the tester is not sending a test report to the author (me). Why? Because if there's one thing that makes an author even more irate that finding out that their module failed on someone else's setup, it's having their nose rubbed in the fact and having their inbox spammed. We stopped doing that a long time ago. No! Spam me, spam me! :-) If you're into RSS, you can get a feed of all your modules' test results: http://testers.cpan.org/author/ROODE.rss Smylers
Re: Naming convention for thin wrappers around C libfoo.so ?
Tim Bunce writes: Re the choice of name for the low level library... Lib::Memcached Lib::memcached Lib::libmemcached My preference is for Lib::libmemcached because it emphasises the name of the library that it's a wrapper for. (Think of libmemcached as a brand name. easily find Lib::libmemcached. Your proposed Lib:: namespace would be just for Perl modules which are thin wrappers around external compiled libraries -- which are all named libsomething. This would mean that every single module in the Lib:: namespace would start Lib::lib That seems redundant: either one of the libs in the name should be suffice. Or, to put it another way round, either Lib:: is intuitive enough that people know what it means (in which case the second lib isn't needed), or it isn't (in which case it isn't that useful as a name-space). ... I want people searching for libmemcached to also I think 'the set of all modues relating to caching' is more useful than 'the set of all modules that are thin wrappers around a library which was first implemented in a compiled language', so suggest Cache::libmemcached. Yes, Cache:: has some other modules in it you don't want to be associated with, but then so do most Cpan namespaces -- I'm sure you won't be tainted by them! Or if you want Lib::, then Lib::memcached makes the most sense. Smylers
Re: (OT) Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)
Ovid writes:
With the lovely ok.pm module, I still have the following clunky
construct:
my $CLASS;
BEGIN {
$CLASS = 'Customer';
}
use ok $CLASS or die;
can_ok $CLASS, 'new';
ok my $cust = $CLASS-new, '... and we can call it';
isa_ok $cust, $CLASS, '... and the object it returns';
Those BEGIN blocks really annoy the hell out of me at times :(
Well don't have them then -- put the assignment in the use statement,
which is run at BEGIN time anyway:
use Test::More tests = 1;
my $CLASS;
use ok $CLASS = 'DateTime';
Smylers
Re: Module Proposal: Log::Any
A. Pagaltzis writes: * John Siracusa [EMAIL PROTECTED] [2007-09-07 13:15]: Ideally, logging would disappear entirely from the code path when disabled. Perl being Perl, this is rarely possible, Will be easy in 5.10 Is that still the case? The most recent development release has this in its changelog: The assertions pragma, its submodules assertions::activate and assertions::compat and the -A command-line switch have been removed. The interface was not judged mature enough for inclusion in a stable release. -- http://search.cpan.org/~rgarcia/perl-5.9.5/pod/perl595delta.pod#Module_changes Smylers
Re: CPAN testers machines that lack Module::Build
Jonathan Rockway writes: Why don't y'all just use Module::Install? As has been mentioned before on this list, because it involves bundling an installer with your module. So if the installer changes (to fix a bug that affects the ability of (some) end users to install your module), you have to redo your distribution. Which for some people is fine, and, on balance, their prefered way of working. But it doesn't suit everybody. Smylers
Re: CPAN testers machines that lack Module::Build
Paul LeoNerd Evans writes: On Tue, Mar 13, 2007 at 03:19:09PM -0400, David Golden wrote: I think if you use M::B and have it create a traditional Makefile.PL, it will just promote all those build_requires to full prereqs. So people that have M::B will get the build_requires behavior and those with only EU::MM will get a big prerequisite list. In my view, working with lots of dependencies is better than not working at all. Yes, but doesn't that produce end results that depend on too much..? Yes. But only for people using the Makefile.PL (who currently can't install your module at all, it seems). Those using Module::Build still get the Build.PL, so shouldn't be any worse off than they are at the moment. Smylers
Re: Custom extensions to META.yml
A. Pagaltzis writes: * Smylers [EMAIL PROTECTED] [2007-03-02 22:55]: A. Pagaltzis writes: * Smylers [EMAIL PROTECTED] [2007-03-01 21:45]: ... how do you tell whether `bastract` is a typo or extension field? You can't. But equally you can't tell if hints: test-reporter: cc_arthur is a typo or not. (Admittedly if it's a typo for abstract then it's a particularly _bad_ typo ...) Yes, you can’t know anything about extension elements. That’s a given. But if you contain them in an extension hook and disallow arbitrary placement of extension elements, then you can at least validate the rest of the document with strict rules. Unless the mistake somebody makes is it forget whether a field is in the 'officially sanctioned' category or is an extension. I think adding a `hints` field which is a hash of hashes, where the key in `hints` acts as a namespace, is the best proposition so far. ... I still think that the 'hints' level is unnecessary: for any key in 'hints', can you imagine a situation where it's _also_ a key top-level key? Think how confusing it would be to have both 'test-reporter' and 'hints: test-reporter'. I’m not sure this would be particularly common problem? Exactly my point! If any 'hints: foo' field gets widespread use then the spec would avoid defining a clashing 'foo' field, because that would be far too confusing. So in practice a given field is only going to exist either at the top level or in 'hints'. And from a user's point of view that distinction can look quite arbitrary -- it's basically an artefact of which process somebody went through to get the field added. That doesn't seem like a useful distinction to inflict on users. The point of `hints` is simply to contain extensions such that every part of the document other than what’s under `hints` is precisely specified. There are other ways of achieving this, possibly even going further and specifying which extension fields being used. For example there could be a field 'extension-fields' which lists them (with their types?). Smylers
Re: Custom extensions to META.yml
A. Pagaltzis writes: * Smylers [EMAIL PROTECTED] [2007-03-01 21:45]: Can't we just start using cc-author as a field, then if it takes off get it blessed as part of the official spec? Then how do you tell whether `bastract` is a typo or extension field? You can't. But equally you can't tell if hints: test-reporter: cc_arthur is a typo or not. (Admittedly if it's a typo for abstract then it's a particularly _bad_ typo ...) I think adding a `hints` field which is a hash of hashes, where the key in `hints` acts as a namespace, is the best proposition so far. The extra name-spaces avoid clashes. But I still think that the 'hints' level is unnecessary: for any key in 'hints', can you imagine a situation where it's _also_ a key top-level key? Think how confusing it would be to have both 'test-reporter' and 'hints: test-reporter'. Smylers
Re: Custom extensions to META.yml
David Golden writes: In response to other questions about X-foo, I was mirroring the RFC 822 email spec Yeah; that's why I'm so hostile to the idea! Mail headers have X-Mailer: but User-Agent: without the X-; and X-Mailing-List: but Posted-To: and List-Id: -- from a user's point of view it's arbitrary which headers have X- and which don't, and very hard to remember. Smylers
Re: Custom extensions to META.yml
David Golden writes: Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. X-cc-author: no Does putting X- in front of such fields really help? X- isn't really a namespace; having 2 people separately inventing the X-Hair-Colour field isn't any better than them clashing over Hair-Colour. And if your X-cc-author field takes off can you really envisage a separate CC-Author field being created? Having them both in existence would be really confusing. So in practice all the X- achieves is making users have to remember which field names have an X- in front of them and which don't! Alternatively, what would people think about adding a field in META.yml like notes for this kind of extra information. E.g.: notes: cc_author: no Similar kind of problem: notes is very generic (like other or misc), such that it's arbitrary which is a 'proper' field and which is a 'notes' field. Can't we just start using cc-author as a field, then if it takes off get it blessed as part of the official spec? Smylers
Re: James Freeman's other modules
Andy Armstrong writes: For that reason attempting to do any completely automated garbage collection on CPAN would be fraught - but it might be possible to automatically identify modules that /might/ be dormant and then manually sift through them. Trying to change Cpan is likely to be hard: think of who's approval you'd need (technically and socially) and how wide-ranging the effect would be. You're basically proposing a subset of Cpan. Or possibly a subset of Cpan Search. Or maybe a heuristic for putting 'this module seems to be abandonware' notes on AnnoCpan. You can do any of those without the agreement or blessing of anybody else. If your hunch turns out to be correct then your service (or whatever) will turn out to be more useful than the existing one. People will start using it. At that point in can be blessed with more 'official' status. For example, consider JJ's Perldoc project: it's something that he did, and is now running 'officially' as perldoc.perl.org. I guess there are essentially three categories of module 1 active, maintained 2 actively used, abandoned 3 not used, not maintained It'd be nice to be able to weed out some of the modules in category 3 and identify cat 2 modules with a view to flagging them as abandoned so that when/if a new maintainer came along the takeover processes could be fast tracked. Because in your experience of the past week or so the current process is too slow? I'm not entirely sure what problem you're trying to solve here. But that's largely irrelevant -- because however good your idea is, there's bound to be somebody in the Perl community questioning it or objecting to it! So don't wait for approval: just do it, whatever it is, then show folks. Good luck! Smylers
Re: Module DNS::ZoneParse
brian d foy writes: In article [EMAIL PROTECTED], Dariusz Dwornikowski [EMAIL PROTECTED] wrote: Sincu You seem not to be interested in updating the module anymore ... Hi Dariusz, You might also send this to the module author. :) Erm, I think he did -- on 2 separate addresses. I'm reading this on the Module Authors mailing list, where Dariusz's original message had these headers: To: [EMAIL PROTECTED], [EMAIL PROTECTED] CC: module-authors@perl.org, modules@perl.org Smylers
Re: no contact with author
Darek Dwornikowski writes: Dave Rolsky napisał(a): On Tue, 2 Jan 2007, Alberto Simões wrote: Accordingly with http://search.cpan.org/~simonflk/, Simon last release date for all modules is 25 Mar 2005. I would say the best approach is to fork it... In this case, if the author is AWOL, the best thing is to ask for ownership of the module so that he can upload a new version. Six months is a reasonable waiting period for this, IMO. how can it be done? Mail Simon one more time, saying that since he doesn't seem to be interested in updating the module any more you would like to upload a version with your fix in it. CC modules@perl.org on your message, to provide evidence that you've done this. If Simon hasn't responded to your message within a few weeks then write to modules@perl.org drawing their attention to this and asking to be made a co-maintainer of the module. and what is AWOL ? Absent without leave -- a military term for somebody who is missing without permission. Good luck! Simon
Re: RFC: new module Finance::MortgageCalculator
On November 1st Chris wrote: Is this discount completely unique to the UK? I wouldn't've thought so. But I only know UK mortgages, and the things I mentioned weren't included by Dmitri in the description of what his module does, nor on the webpage he linked to about how to calculate USA and Canadian mortgages. So the module as described is insufficient to deal with UK mortgages. It presumably is sufficient for those in other places. So I think it should avoid having a name which overstates its remit; other modules on Cpan have done that. Here's one which recently renamed itself to include EN in its name, on the basis that the 'natural' dates it deals with are only natural to the subset of the world that speaks English, not the entire population: http://search.cpan.org/src/SCHUBIGER/DateTime-Format-Natural-EN-0.07/Changes The US has adjustable rate mortages which affect the rate based on economic conditions. I think that's common, but it's also common to ignore it -- basically because as soon as you have a formula which includes 'what interest rates will be in a decade's time' you end up with a function which always returns undef, and that isn't very interesting! Smylers
Re: RFC: new module Finance::MortgageCalculator
Dmitri Tikhonov writes: I intend to write a new module, Finance::MortgageCalculator, with the express purpose of calculating mortgages. Does anyone foresee any problem with the name? Which country's mortgage markets are you familiar with? Do you have confidence that whatever calculations you are doing will be appropriate in other countries? Something like Finance::Mortgages::ZZ may be more appropriate, where ZZ is your country code. Smylers
Re: RFC: new module Finance::MortgageCalculator
Chris writes: On Wed, 1 Nov 2006, Smylers wrote: Dmitri Tikhonov writes: I intend to write a new module, Finance::MortgageCalculator, with the express purpose of calculating mortgages. Does anyone foresee any problem with the name? Which country's mortgage markets are you familiar with? Do you have confidence that whatever calculations you are doing will be appropriate in other countries? What are the differences likely to be encountered in other countries? I don't know what countries other than the UK do, so I wouldn't know what the differences from elsewhere are. But I have friends and work colleagues who've moved here from other countries and asked about how mortgages work in this country, and found them different. And I do know that in the UK you have to take the mortgage provider into account: different providers have different way of converting headline interest rates into monthly payments. Exactly how they do this (and how they are permitted to do it) has had several changes over the past decade or so (and probably before). At least many of those changes are prompted by the financial regulators, who outlaw certain practices or insist on things being done in particur ways. I would be surprised if each country's regulators were imposing exactly the same restrictions simultaneously. Isn't a basic mortgage calculation based on principle times interest, and then determining monthly payments? Ah, if the module is just doing a basic interest calculation, then yes, that's just a simple matter of mathematics. But in that case I reckon Finance::LoanCalculator or Finance::InterestCalculator would be a better name, because it isn't including any of the aspects which make a mortgage distinct from any other sort of loan. Smylers
Re: RFC: new module Finance::MortgageCalculator
Dmitri Tikhonov writes: Mortgages may compound differently -- monthly (the most common in the USA), biweekly, or semi-annually (Canadian). Or indeed daily: http://www.nationwide.co.uk/mortgage/homebuyers/intro.htm The common thing between them is that there's still a fixed number of payments. Sure. But that still sounds like it's common to all loans, not just mortgages. In the UK mortgages many also have a discounted rate for the first few years. I had one which had a discount of 1.2% points for 2 years followed by a premium of 0.8% points for 3 years (so paying out less during the first couple of years after buying a home, but making up for it in years 3-5, by which time you've hopefully got a payrise). And there are interest-only mortgages, where in theory you only pay the interest each month, leaving the main part of the debt exactly the same size, and then also pay into an entirely separate fund to build up some capital to pay off the debt at the mortgage expiry. In practice of course folks mainly seem to get the money to pay it off by suing their financial advisors for persuading them to sign such risky deals in the first place. There have been studies which showed how in the UK it is basically impossible to compare credit card rates, because every supplier has a different way of doing their calculations (and not really making public what they are). It wouldn't surprise me to find something similar going on with mortgages -- certainly I have been in the position of having a choice between two mortgages and the one with the lower rate had the higher monthly payment. I will make the interface support all of these methods. Great. The following web site has some formulas and derivations: http://www.hughchou.org/calc/formula.html That page mentions amortization, and despite its title I still don't see anything which makes it apply only to mortgages and not to other sorts of loans. Using Loan or Amortize would seem more sensible to me -- then somebody wanting to look at, say, amortized student loan payments might still think of using the module, whereas she could be put off by having mortgage in the name. I guess I could do Finance::MortgageCalculator and Finance::MortgageCalculator::US (which would be an empty subclass) and then people could inherit from Finance::MortageCalculator and create their own country-specific calculators. Only do that if it makes sense! You asked if anybody could see any problems, and I suggested being specific to a particular country as being a potential one. If your module isn't actually USA-specific then don't bother. My only concern was not to have a module which is only applicable in a particular country not having that as part of its name. (Note that having the ::US module as an empty subclass doesn't really solve this: you still have the problem of a module with a generic name not applying outside the USA.) (I'd still like the word Calculator being present in the name. When I look at module named Finance::Mortgage I think to myself -- mortgage *what*?) Finanace::Mortgages obviously deals with mortgages; what else could it do but calculate them? Calculator is a little like Process or Do or Library or so on: given that without any help from the name we already know this is a Perl library that does something, it doesn't really add anything. Smylers
Re: Give up your modules!
Johan Vromans writes: First of all, one needs to know that there are bugs. Currently, only bugs that get reported via RT are automatically transmitted to the author. Are they all? I'm pretty sure I've encountered a case of not getting them for a module I took over maintenance of. When reporting a bug I always look at the module's doc and if the maintainer doesn't specifically mention RT then I instead use the e-mail address he does provide. But failed CPAN tests are not reported automatically. I think I've had reports from there mailed to me. Neither are discussions on annocpan, That was discussed on this list soon after it launched. My memory is that we decided that it was OK for AnnoCpan to alert an author the first time a comment is made on her module, and then give the option of subscribing to future alerts. Smylers
Re: Fwd: Indexing for AI-Prolog-0.735_01?
Joshua ben Jore writes: PAUSE says to send problems to modules@perl.org but perl.org's web page says that's a closed list?! Closed in the sense that only the Pause admin folk can subscribe to it. Think of it as less of a mailing list and more of a generic address for contacting all the Pause volunteers at once. Smylers
Re: Preserving Supplementary Documentation, Take 2
John M. Gamble writes: It appears that I got shot down at PAUSE: You mean by [EMAIL PROTECTED] Is this a separate distribution from Math::Polynomial::Solve? (It shouldn't be.) Even if not, why not put the documentation as POD in Math::Polynomial::Solve? That isn't being shot down; it's being asked to justify what you've done. Many people upload stuff without really thinking about certain aspects of it or the impact it will have. One of the services kindly provided by the enthusiastic volunteers on modules@perl.org is to question things which look a little odd and make sure that authors have thought about all the relevant issues. If presented with a reasonable reason for doing something they usually accept it. I pointed the respondent to the conversation at http://www.nntp.perl.org/group/perl.module-authors/4558, which includes both the reason why not, and the suggestions to solve this. However it looks like you didn't CC modules@perl.org in your response, so to the rest of the volunteers it looks like you didn't answer the questions. I got no response. I'm presuming silence does not equal consent, Actually given the nature of modules@perl.org silence often does indicate consent: the various volunteers will likely respond if they can spot a potential problem, so if no questions are raised within a couple of days that likely indicates collective acceptance. ... so I have to find a different solution. Not necessarily. Try again; follow-up to the thread, making sure you include the entire list, and see what happens. Smylers
Re: ISO8601 Module: Would this be worth writing?
Ron Blaschke writes: DateTime::Format::ISO8601 feels rather heavyweight, with dependencies on DateTime DateTime _is_ quite heavyweight, but it's also generally right, and there's a whole suite of modules which work with it, meaning that you can live almost entirely in the DateTime world for all your date- and time- stuff. For any one individual task you can likely come up with a module which just does that and does it more leanly, but there is an advantage in having various date- and time-based modules working together, and also in having them being based on something which gets right all the really awkward bits (such as leap seconds, time zones, and daylight-saving time); even if you don't need that, somebody else will. It's a bit of a chicken-and-egg thing, but obviously DateTime is only an awkward prerequisite of a module if you don't already have it installed. And the more people who embrace DateTime, the more it will be seen as a reasonable module for othewr things to be based on. ... and seems to be able to parse, but not format. I haven't looked at DateTime::Format::ISO8601, but if that is the case then I suspect it's because DateTime emits in ISO 8601 format by default, so you don't need to do anything special to get it. Smylers
Re: RFC: Set::Partition
Xavier Noria writes: But that's a good point, instead of requiring the user to pass [keys % set] if he works with a hash, I could add a little sugar and accept hashrefs in addition to arrayrefs. ... Also there'd be lack of symmetry about the input and output structures... Why? In the case where the user supplied a hash surely you could remember this and return the results as a hash too? Smylers
Re: I think we can just scrap CPAN Ratings altogether
A. Pagaltzis writes: * Adam Kennedy [2006-05-23 11:10:13] Data-Pageset (1.03) ??? 1 star: This is reciprocal karma for the author one-starring a competing module and advertising his own. Bad form. (not a commentary on how this works) This sort of thing is lunacy. What???s the point of MODULE REVIEWS if they???re going to be turned into crusade vehicles? I agree: I only care about whether a module is good enough to use, not what else the author may've done elsewhere. Fortunately I don't think this matters too much. At the moment a typical module has so few reviews that if I'm investigating it I will bother to read all of them, so I can easily discount comments such as the above. If Cpan Ratings becomes so popular that this is no longer feasible that'll mean a module's overall star rating is an average of so many ratings that the odd bogus rating will have little impact. Adam, dude: there are ???Was this review helpful to you voting links on each review for exactly this purpose. I voted ???No??? on Leo Lapworth???s review, (I hadn't read Leo's review (on Data::Page::Set) until now, but I don't see what's so terrible about it. He's providing the information to a potential user of Data::Page::Set that he considers Data::Pageset to be much more flexable[*0]; that's useful to know. And he even admits to being the author of the module he's recommending, so that readers can see his potential for bias and take that into account; not mentioning this would be sneaky, but as it is nobody can read Leo's review without realizing it's just his opinion and that he isn't a disinterested party. People who have encountered Leo or his work before can also use that to help them decide how much to trust his opinion of a rival module. which at the time of this writing has a count of 0 out of 8. If I were in the market for a module dealing with pagesets I'd appreciate the existence of Leo's comment -- so I've just made the above 1 out of 9!) But ... the above is all in brackets because it's irrelevant to having an opinion on Adam's 'reciprocal karma' rating: it isn't that I don't think Adam should've attacked Leo because I don't see the problem with Leo's actions, but that I simply don't think it's an appropriate use of Cpan Ratings to launch attacks like this at all. [*0] And also that he can't spell flexible; that's less useful to know. Smylers
Re: Testing an FTP module
Nicholas Clark writes: In the general case, having module tests make external network connections is a bad idea There are distributions which offer these sorts of things as optional tests, prompting for whether they should be run or skipped. So long as you default to skipping them this shouldn't mess things up in automated environments. Smylers
Re: Naming advice: parse info out of Build.PL/Makefile.PL
Chris Dolan writes: I'm going to write a module that uses PPI to parse Build.PL and Makefile.PL files without executing them. The goal of the project is to deduce information like version, dist name, author, abstract, prereqs, etc. from packages that have incomplete or absent META.yml files. Sounds useful. My current ideas for names: PPIx::Buildfile PPIx::BuildPL/PPIx::MakefilePL Module::Info::PPI::Buildfile Module::Info::PPI::BuildPL/Module::Info::MakefilePL Those don't sound sensible to me: it's what your tool does that matters, not which technology it happens to be implemented using. Package::Buildfile Module::Info::Buildfile Module::Info::BuildPL/Module::Info::MakefilePL The latter pair has the advantage of being more intuitive; I'm not sure that I'd immediately realise what a buildfile is without more context. Really this project analyzes packages, not modules, but the Module:: namespace seems to be preferred over Package:: on CPAN. (or am I mistaken?) Namespaces are approximations, not hard contraints. Having the namespaces fit exactly would likely mean either the namespaces' names being unwieldily long or fragmenting each namespace into lots of separate namespaces for each of the niches. If Module:: is what's being used then use it, and don't worry that sometimes packages don't contain any modules. Smylers
Re: New Module Proposal - Math::Interval
Orton, Yves writes: Thus, having some math background one would identify Math::Interval::Arithmetic (or maybe more proper, Math::IntervalArithmetic) at a glance in a search for interval. Imo the former form should be heavily preferred over the latter. Math::Interval admits the possibility that there could be a wide range of modules related to intervals. Math::IntervalArithmetic Does not. I completely agree with you if all of these (perhaps theoretical) modules _are_ related to intervals, and intervals in the same sense of the word as each other. But if these modules are actually dealing with different concepts (I've only been skimming this thread -- I'm not really mathsy enough to understand it -- but I think that might be the case) that only co-incidentally share a name then actually there's nothing to be gained in grouping them together. Actually, quite the reverse: there's benefit in splitting them by name into their 2 concepts. So having Math::FooInterval and Math::BarInterval as name-spaces would work for me, for suitable values of Foo and Bar which help to disambiguate the words. But similarly, if one of the meanings of interval is in more common use such that it's the concept mathematicians tend to refer to by that name without any disambiguating adjectives then it also makes sense to have Math::Interval for that concept and Math::FooInterval (or Math::InvervalFoo) for t'other one. So I think Math::Interval::Arithmetic or Math::IntervalArithmetic could be better, depending on whether it's dealing with arithmetic on the same concept as Math::Interval deals with, or whether it's a different concept entirely. Not only that but CamelHump identifiers are considered to bad style in the eyes of much of the community. It is harder for a coder to enter style-heaven than it is to fit a CamelHump through the eye of the community? Smylers
Re: Naming advice for a templating module
A. Pagaltzis writes: * Dr Bean [EMAIL PROTECTED] [2006-03-04 10:05]: What about Template::XML? Except that it might be thought to be part of Template Toolkit. Yeah, the Template:: TLNS is nominally reserved for the Template Toolkit like DBI:: is for the DBI, even though some people have put other modules in those namespaces. The difference is that DBI is a branded-type name, in that it didn't have any meaning as a word until the DBI module were created, so it's reasonable that it takes a namespace to itself. Whereas template is an ordinary generic English word which is useful to many modules, so it isn't as reasonable for one particular templating module to snaffle that entire top-level namespace from everybody else. Smylers
Re: Perl editing support in Vim (was: FF:: namespace)
A. Pagaltzis writes:
* Smylers [EMAIL PROTECTED] [2005-12-04 03:35]:
That's because the default ftplugin/perl.vim sets iskeyword to
include the colon, so that all gets treated as a single word.
Until now I hadn't seen a disadvantage of removing that colon,
but now you've pointed that out I'm going to have to choose
between putting up with that bug in syntax highlighting or
making namespaces more awkward to complete ...
Another disadvantage, and a reason I could never live without
that colon: move the cursor on top of a module name, then hit
[Ctrl-W][f] or [g][f].
That's the colon in isfname (which I do have), rather than the one in
iskeyword (which I don't, but perhaps I should).
Neat, no?
Indeed (though there's an irritating bug where if I have something like
~/lib/perl/ early in my path and CGI::Lite is installed there then when
Perl searches for CGI will find the _directory_ ~/lib/perl/CGI/
(necessary for CGI::Lite), rather than CGI.pm (which is later in the
path). There's some magic which says also check for this filename with
'.pm' on the end, but we really want that to be only rather than
also.
The last time I looked at that I couldn't see a way of fixing it.
It could be smarter yet (it only works relative to @INC or the current
directory; hmm, now that I think about it I may have an idea for to
fix that?)
I have this in ~/.vim/after/ftplugin/perl.vim:
let l:path = system('perl -I, -Ilib -I../lib -e print join q[,], @INC')
That adds in ./lib/ and ../lib/. But it'd be good to look for use lib
statements and similar in the code and add those in too.
Smylers
--
May God bless us with enough foolishness to believe that we can make a
difference in this world, so that we can do what others claim cannot be done.
Re: New module: FLV file parsing
A. Pagaltzis writes: * Smylers [EMAIL PROTECTED] [2005-12-02 22:10]: Eric Wilhelm writes: I'm working on CAD::DXF for now, Cad is a well-known acronym. I have no use for anything cad-related in my life at the moment, so I know that I can safely ignore that module. But as it happens, referring to DXF in the context of cad is enough to prompt me into recollecting that .dxf is an AutoCad file extension. Are we reinventing MIME types now? No. Mime media types only apply to file formats; Cpan modules cover much more than that. Let?s just stick with Process::video::x_flv Process::application::x_shockwave_flash Process::image::x_dxf Snip But that's still grouping together all file-format-related modules (under Process::), rather than grouping them by function. It does make sense for CAD::DXF and CAD::Calc to be in the same namespace as each other, and grouping all the file-format modules together prevents that from happening, whether it's the truly awful FF:: or the mostly meaningless Process:: (surely nearly all Cpan modules perform some kind of processing?). DateTime::Format::Mail is a good name for a module; you can see that it is part of the DateTime project and is for processing dates as used in e-mails. Naming it Process::RFC822::DateTime (or similar) is not an improvement. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: New module: FLV file parsing
Austin Schutz writes: On Fri, Dec 02, 2005 at 04:04:11PM -0600, Chris Dolan wrote: The FF:: namespace is a terrible idea, in my opinion. I expect that it will be meaningless to the majority of module searchers. The argument that search makes names irrelevant is just silly. ..because? There are several places where somebody could first encounter a module name: Ok, I want to do something with my flash file. I search for 'flash file'... Oh look, there's a flash file parser. Do I care what it's called? A large search results listing is one such place. You want to be able to pick out the potentially useful modules from the list, so having their names be as meaningful as possible helps with this. No. I concur that the module name is effectively meaningless, Since FF is meaningless, why bother including it at all? It's just noise. but I don't see that it makes any difference to the searcher. I'm much more likely to spend time investigating modules whose names I can understand. I suspect I'm not alone on that. It's marginally helpful to have a useful name when including it in a module so code doesn't look like $flv = new ASDFsdafs::sjhsdlk, That's a second place module names are encountered, and I'd say that's beyond marginal. Lots of code is read by people other than the original author, and it's good if the approximate use of a module is guessable just from the calling code. but beyond that, what tangible and practical difference does it make? Another place I encounter module names is the RSS feed for Cpan uploads; I'm interested in seeing what sort of things people are making available, and looking out for things that are of interest. There are also feeds for AnnoCpan and Cpan Ratings -- if you see a comment on or a review of a module it's better if you know vaguely what the module is about (or at least if can see what field it's in, so you can dismiss it if it isn't anything of interest to you). People mention modules at PerlMonks, on mailing lists, and in the pub at Perl Mongers meetings and conferences. In all of these places a meaningful name helps everybody identify the module being discussed. Or to put it another way round: if a meaningful name is available, what's the advantage of going out of your way to pick an acknowledged meaningless one? If that were true, the practice of bouncing name ideas off this email list would cease, and I'd just name it FLV.pm. As I understand it there's some rationale for keeping the top level namespace small, so that would probably not be a good choice. Almost. I think that it's cos if you call it FLV it's effectively claiming to be _the_ module for FLV. It's more future proof to call it FLV::Something, anticipating other people contributing FLV::SomethingElse later. Unfortunately there seems to be a meme going round where the advice not to use a single-level name for a module has morphed into not using a multi-level name where the first level is new. I submit these long threads about which module name is better than some other similar name are a waste of time, If you don't care what modules are called then don't participate in them! By definition whatever a module ends up being called you will be satisified! If some of the rest of us (including a modules' author) are fussy it doesn't make module names worse for you ... Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: New module: FLV file parsing
Austin Schutz writes: On Sat, Dec 03, 2005 at 08:30:20AM +, Smylers wrote: [Austin wrote:] Do I care what it's called? A large search results listing is one such place. You want to be able to pick out the potentially useful modules from the list, so having their names be as meaningful as possible helps with this. If the module description is included the actual name provides some debatable amount of additional benefit. But module names tend to be headings, what draw your attention in first. Yes, descriptions often help to clarify things, but a good name is obviously more useful than a poor one. Sometimes it's hard to find a name that is intuitive, but there doesn't seem to be any point in choosing to 'waste' part of the name on an abbreviation that nobody at all thinks is meaningful. FF:: is a good example. ... it should make little difference as long as the description is concise, descriptive, and accurate. You say If ... above. Not everywhere that mentions a module name has its description next to it (in code, for example). In the same way that it's better to code clearly without comments, than to code obscurely and have to add comments explaining what you mean, it's helpful for module names to be clear even without their descriptions. Since FF is meaningless, why bother including it at all? It's just noise. For two reasons - grouping of related modules under the FF:: heading, But I'm claiming that they _aren't_ related merely by being file formats. The fact that they are file formats isn't the most relevant thing about them. and to avoid the top level issue you state below. Except that I pointed out that this isn't an issue: it's a meme that has been misinterpreted from what the advice on Pause says. There in general isn't a problem with inventing a new top-level namespace for a new category of modules. What's frowned upon is giving a module only a single-level name. So hogging FLV is antisocial, but opening up FLV:: by using FLV::Something is perfectly acceptable, even encouraged. it's good if the approximate use of a module is guessable just from the calling code. Yes, I agree, but would emphasize approximate. Right, so let's try to make module names as meaningful as possible, and not include meaningless bits in them. Or to put it another way round: if a meaningful name is available, what's the advantage of going out of your way to pick an acknowledged meaningless one? I have not suggested going out of your way to pick a meaningless one. I'd claim that renaming FLV::Info to FF:FLV would be -- the module already has one name and changing it would be putting effort in to including the term FF, which everybody agrees is meaningless. I believe the ongoing debates reduce the utility of the module authors mailing list, and therein lies my concern. If there were a separate mailing list dedicated to module naming those concerned with proper names could debate to their satisfaction and allow the authors list to concentrate on other module related issues. Would that be an equitable solution? I wouldn't object to it, but I suspect it isn't worth the hassle of setting it up (and that having 2 lists would just add to the levels of confusion, and people would end up posting the 'wrong' sort of question to each list anyway). This mailing list isn't very high traffic as it is. Nearly all participants are using decent mail or news clients, such that proper threading is preserved. This makes it relatively easy to avoid an entire thread that you're not interested in -- there have been plenty of threads here that I've skipped cos they don't happen to be my kind of thing, but I don't doubt that this is a good place for them to exist. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: FF:: namespace (was: New module: FLV file parsing)
Eric Wilhelm writes: use My::Really::Long::Module::Name; my $obj = My::Really::Long::Module::Name-new(); ... is just _almost_ tedious enough to warrant copy/paste, but not quite. A decent editor should provide some sort of completion facility on previously typed terms, so that you don't have to retype them. For example in Vim having first typed: use My::Really::Long::Module::Name; you can then type: my $obj = M Pressing Ctrl+P (P for previous; you can guess what the keystroke for next is) completes this, incorrectly, to: my $obj = Module But simply keep Ctrl pressed and tap P a second time and you get: my $obj = My And from there press Ctrl+X Ctrl+P to type the word following the one you've just completed, giving: my $obj = My::Really Do that a few more times and you've got the whole name: my $obj = My::Really::Long::Module::Name That sounds tedious when written down like this, but basically it just involves holding down Ctrl and pressing P and X a few times. I believe that Emacs has an equivalent feature, and I'm sure I've seen some kind of tooltip completion feature on a gui Windows editor. Picking a decent editor and learning how to use it well is far better than trying to use unnaturally short identifiers throughout your code! That said, I would much rather see all file-format parsing/writing modules go under FileFormat:: than Parse::. But why group them under either? Why group them at all? IMO, a distribution shouldn't have to break out of a single root. Starting with Parse, Info, ... means you're stuck (maybe just stuck looking silly, but still stuck.) That's along the same lines of why I'd prefer CAD::, Graphics::, Video::, and whatever -- cos those are the sorts of modules that work together (even if only some of them are to do with file-types), rather than all the modules dealing with file-types. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: FF:: namespace (was: New module: FLV file parsing)
Eric Wilhelm writes: # from Smylers # on Saturday 03 December 2005 03:41 am: That sounds tedious when written down like this, but basically it just involves holding down Ctrl and pressing P and X a few times. Neat. My vim does it all at once if the syntax mode is perl :-) Ah, so it does. That's because the default ftplugin/perl.vim sets iskeyword to include the colon, so that all gets treated as a single word. It seems that I override that in my ~/.vim/after/ftplugin/perl.vim, removing the colon, with a comment which says this is because with the colon in iskeyword the interpolated variable name doesn't get highlighted in qq-quoted strings like: print qq[$variable: with colon straight after it]; Until now I hadn't seen a disadvantage of removing that colon, but now you've pointed that out I'm going to have to choose between putting up with that bug in syntax highlighting or making namespaces more awkward to complete ... That said, I would much rather see all file-format parsing/writing modules go under FileFormat:: than Parse::. But why group them under either? Why group them at all? Why group IO-related modules under IO:: ? B:: ? DBIx:: ? Those are are generally more generic, lower-level operations. A module for working with an AutoCad drawing has a much more specific and focused use, and has almost nothing in common with a module for working with Macromedia videos (or whatever). Or, how is abbreviating FileFormat to FF bad and Input/Output to IO good? Because IO, or at least I/O, is a well-known abbreviation used outside Cpan; it's the kind of term that is used in our office and everybody knows what it means: http://en.wikipedia.org/wiki/I/O Whereas we'd be synthesizing FF specifically for Cpan. Why is it a good idea for all-things-input/output to live under IO, Actually not all input- and output-related things are under IO:: -- only the generic fundamental modules are there. Lots of other modules deal with input or output in some way or other but are under a more specific namespace. Seems like everyone who says FF means nothing would probably get used to it in less time than that consumed by this thread There are also lots of people not on this list who would also have to get used to it! (and certainly less time than the cumulative value of typing ile ormat.) Module names should be chosen for meaning, not purely shortness. That's along the same lines of why I'd prefer CAD::, Graphics::, Video::, and whatever -- cos those are the sorts of modules that work together (even if only some of them are to do with file-types), rather than all the modules dealing with file-types. 1) Not all domains have a TLNS. Sure, but most modules are in _some_ field. Given that the first code to happen in a domain often involves accessing the data, the authors may have a hard time figuring out where that parser/writer should live. Given an existing convention they can just settle into the standard location. Except that given that FF:: isn't particularly meaningful, FF::FLV is almost as poor a name as just FLV. 2) Rooting a tree of file-format modules at FF:: allows all-things-file-format But what are those things? I still don't see what the situations are where it's helpful to make this grouping! to be handled as a single entity (in your mind, on disk, in search engines, etc.) I could see the benefit to that if FF:: were along the lines of DateTime::Format:: where are lots of different modules for different formats but they share a common interface, but not with lots of completely independent modules. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: New module: FLV file parsing
Eric Wilhelm writes: # from David Nicol # on Wednesday 30 November 2005 02:18 pm: isn't there a multimedia name space? ame spaces per-product that is being supported make sense --- Flash::parseFLV perhaps? What else will appear in the Flash:: namespace? It doesn't matter if nothing else appears there -- the module would still have a name that's readily understandable. What all file format parsers and dumpers have in common is that they deal with File Formats. Yes, but that isn't more relevant than the particular file format each deals with. For example, I'd be much more likely to first think that I'd be working with Flash files, and then realize that I need to parse them, than to start by thinking that I'm working with files that have a format, and only then that the format is Flash. In a lot of cases, the only module that is going to be created is for that format. And that causes what harm? I'm working on CAD::DXF for now, Cad is a well-known acronym. I have no use for anything cad-related in my life at the moment, so I know that I can safely ignore that module. But as it happens, referring to DXF in the context of cad is enough to prompt me into recollecting that .dxf is an AutoCad file extension. but would rather name it FF::DXF, Whereas if I saw that I wouldn't know what either set of letters mean; DXF is sufficiently meaningful in my brain to make me think of AutoCad without any context. And FF could be one of many things: recently I've seen it used to abbreviate Firefox in quite a few places; if I'd just been reading some music (or trying to solve a crossword) I might think of it meaning very loud. similarly with FF::SVG, FF::XAR, FF::PDF, etc. What does that achieve? Putting all the cad-related modules makes good sense to me, and similarly for other things. FF::FLV sounds best to me. I wouldn't have a clue what that means. I hadn't heard of FLV before this thread, and I wouldn't guess FF without this thread either. With Flash::FLV I still wouldn't know what FLV stands for, but I'd have a clue as to its context -- enough of a clue to know whether I'm interested in investigating the module further if it I see it in the 'recent uploads' list. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: New module: FLV file parsing
Chris Dolan writes: So, I already published it as FLV::Info, but this discussion has convinced me that FileFormat::FLV is the best option. I still don't see what's to be gained from having all modules that deal with specific file-formats grouped together -- or more specifically why that makes more sense than grouping them in Cad:: or Graphics:: or Spreadsheet:: or whatever else they are actually useful for. The FF:: namespace is a terrible idea, in my opinion. Ditto. I expect that it will be meaningless to the majority of module searchers. Exactly -- even if you search by FLV, seeing FF::FLV in the results list doesn't help you at all. As for the Flash:: namespace, I don't think that's best. While FLV is primarily used in the Macromedia Flash Player ... However it's preferable for module names to be 'best fit' rather than 'pedantically accurate'. We want something that's meaningful to most people, even if technically it does more than that. ... it is not Flash but is a standalone video format. Well how about Video::FLV or Video::Format::FLV then? (Or even Video::Flash::FLV?) That would be like naming a CSS parsing module HTML::CSS::Parser, Yes, and I wouldn't object to that -- especially if CSS were a much less-well-known technology, such as when CSS clearly has utility beyond just HTML, despite its dominant usage. Yeah, but dominant usage is a great way of finding something. Anybody who wants to use CSS for something else is bound to know that HTML is its dominant usage. CSS has recently been used to format a book using Yes Logic's Prince ... but HTML was still used for the mark-up. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: RFC - Data::SelectWithoutReplacement
David Landgren writes: ... my main question concerns the name. Is it good? Did you understand what the module would do when your saw the subject of this message in your inbox? No. And I still don't understand what WithoutReplacement means in this context -- after reading those terms in the title, I was expecting them to crop up again somewhere in the synopsis or the description. The implication is that ordinarily when selecting something it is replaced -- but I've no idea what that means. Is there a better name(?:space)? for this? It looks to me that this module when given a set returns its power set: http://en.wikipedia.org/wiki/Power_set so perhaps Data::PowerSet is appropriate. Except that it isn't clear what your module does if the input list contains duplicate items. Sets can't contain duplicates; if your module just sees a list with 5 items in it and permutes those items by their indices then it wouldn't even notice the dupes, so obviously it isn't (solely) working with sets. But the module name is supposed to be best fit rather than perfect, so even if your module also provides analogous behaviour on things that aren't sets, I don't think that would bar it from using PowerSet in its name. (I rule out Algorithm::*, since the you're not actually supposed to care how it does its business, only that it does it). That's a good point, and I completely agree with you on it. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: Apache::Reload on Cpan
Andreas J. Koenig writes: If there was ever a Apache::Reload that was newer than the one in MSERGEANT/Apache-Reload-0.07.tar.gz and that other distribution has then been removed, that would explain the current state of affairs: That sounds like the most likely explanation then; thanks for confirming it. I've just scheduled MSERGEANT/Apache-Reload-0.07.tar.gz for reindexing ... Thank you! Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: Apache::Reload on Cpan
Matt Sergeant writes: On 22 Aug 2005, at 09:55, Smylers wrote: ... there seems to be something odd about the Apache-Reload-0.07 distribution. I first noticed that my usual way of jumping to a module's documentation on the Cpan Search website doesn't work: http://search.cpan.org/perldoc?Apache::Reload But doing a full search clearly shows that it is available: http://search.cpan.org/search?query=Apache::Reloadmode=module And when trying to install Apache::Reload it seems that the CPAN module can't find it either: $ sudo cpan Apache::Reload CPAN: Storable loaded ok Going to read /root/.cpan/Metadata Database was generated on Sun, 21 Aug 2005 20:58:22 GMT Running install for module Apache::Reload The module Apache::Reload isn't available on CPAN. Either the module has not yet been uploaded to CPAN, or it is temporary unavailable. Please contact the author to find out more about the status. Try 'i Apache::Reload'. I think this is because Apache::Reload is now shipped as part of core mod_perl, but only as part of mod_perl 2.x Hi Matt. That's possible, except that I'd then expect the above Cpan Search URL to turn up the Apache::Reload that's in mod_perl 2, rather than nothing. Anyway, mod_perl 2 includes Apache2::Reload, which is a different name. Before the Apache - Apache2 renaming did mod_perl 2 include a module called Apache::Reload? If so, then that's probably the most recent module of that name which has been uploaded to Cpan. But that distribution has since been deleted, so it looks like the most recent version of Apache::Reload is no longer available. Apache-Reload is over 4 years old; perhaps if you just uploaded a new version (without any changes) then this would trick the various indexers into knowing where to find Apache::Reload? Sometimes the intricacies of how CPAN works confuse me though. Me too, which is why I've CCed the module authors list, in case anybody else can offer an explanation of this. Cheers. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: IO::ALL (Was: check for errors on close())
Sam Vilain writes:
Smylers wrote:
Sam (or any other IO::All users reading this), what's your
experience of IO::All? How much effort has it saved you? Does it
make your code look
Hi Sam -- thanks for taking the time to answer.
I've only just begun to reap the benefits of it.
After how long of using it? Does that mean that initially you found it
more hassle?
Now, it seems that the built-in ways of doing these things are just
too awkward.
That strengthens my feeling that Ingy is on to something with his
shorter syntax, and that Perl 6 should benefit from many of his ideas.
Just this morning I cursed as I had to change;
While that strengthens my feeling that in Perl 5 the benefits of IO::All
typically aren't enough to make it worth having the module as a
dependency -- it isn't yet ubiquitous, and there are situations where
it's easier not to bother installing it and make do without instead.
my @mp3s = grep { -f } @ARGV, ($m3u?io($m3u):());
The behaviour of that line wasn't immediately apparent to me. Obviously
it does the same as the line below that you replaced it with, but even
after looking at the IO::All docs (well, the synopsis anyway -- they're
too long for me to be bothered to read all of them!) I can't work it
out. I'd've expected you to need to write something like:
my @mp3s = grep { -f } @ARGV, ($m3u?io($m3u)-chomp-slurp:());
to:
my @mp3s = grep { -f } @ARGV, ($m3u?(map{chomp;$_}`cat $m3u`):());
Hmmm, that does look rather messy (as well as having the platform-
dependent cat and the potentially insecure backticks). I'm not sure how
I'd've written it; perhaps like this:
use Path::Class qwfile;
# ...
push @ARGV, (file $m3u)-slurp if $m3u;
chomp @ARGV;
my @mp3s = grep { -f } @ARGV;
But the fact that Perl's built-in way of slurping isn't convenient shows
that there is a desire to use a module (whether IO::All, Path::Class, or
File::Slurp), and IO::All's chomp method looks nice -- that the built-in
chomp function doesn't return the chomped list makes my version above
more awkward than I'd like.
Perhaps Path::Class::File should steal IO::All's chomp method? (Or
perhaps that would start to bloat what is currently a very clean and
elegant suite of modules -- and if we keep doing things like that we'd
just end up turning Path::Class into IO::All, thereby proving that Ingy
was right in the first place.)
Clearly, there are two fairly opposite morals to read from that story.
Indeed!
And I think I've just about listed all that Spiffy does, so don't
worry about it! :)
Fair enough -- I wasn't really worrying about it, just a little curious.
Also, I'm open to being persuaded to start using it myself (but haven't
yet 'got it' sufficient to see what it'd do for me).
Smylers
--
May God bless us with enough foolishness to believe that we can make a
difference in this world, so that we can do what others claim cannot be done.
Re: IO::ALL (Was: check for errors on close())
Sam Vilain writes: Eric Wilhelm wrote: Just spent way too much time trying to find a bug when it turns out that I just had a full disk. So, food for thought for today: close() does not always return true. close(FILE) or die file error: $!; You don't already check the return value of every system call? I don't. Too tedious? That, and it makes the code look messier than needs be; a lexical variable going out of scope is very clean. Just use IO::All. I've looked at IO::All a bit, but never actually tried it -- it looks sufficiently daunting that I've never put the effort in to learn it rather than using something I was already familiar with. Possibly, if it really is as easy to use as it claims, it just suffers from too much documentation. I'll consider it the next time I'm writing a script that does a lot of stuff with files, but if reading from one file once is the only IO a script does then this seems like a massive prerequiste to pull in: suddenly I've added a big prereq to a project, and confused other coders in the team who know Perl but don't know IO::All, just to write 2 lines of code instead of 3 -- that doesn't seem worth it. Normally I don't buy the but I don't want to use a non-standard module cos that adds dependencies argument, but in this case I think it makes a big difference. Some of the things Ingy's doing in IO::All do look to be more Perl-ish than the current built-in Perl ways of achieving them, and I think I read Larry saying he'll incorporate some of them in Perl 6, which would be mos welcome. Sam (or any other IO::All users reading this), what's your experience of IO::All? How much effort has it saved you? Does it make your code look too confusing for other coders (I'm thinking of the overloaded comparison operators being used for something other than comparison, for instance)? Have you ever found it to be 'too clever', automating something in an inappropriate way? And finally, an implementation question, which, while not strictly relevant to a user of IO::All, does seem on-topic for a module authors' mailing list: does the Spiffy thing make sense to you? (I get the feeling that there's something I'm missing, or that I'm not clever enough to understand it.) For comparision, I've recently started using Path::Class, which is an excellent module. This also adds a non-standard dependency to file-handling tasks that other coders on my team may not have met before, and it doesn't do anything that isn't possible with core modules. But it's sufficiently well focussed that I could grasp it in one go, and see clear benefits; it feels natural, with objects representing obvious things and having intuitive interfaces: my code is definitely cleaner for using it, and I'm not worried that my co-workers will have trouble with it. (Actually, possibly one of the reasons I'm liking using Path::Class is that while it theoretically is a better interface to using File::Spec, we weren't using File::Spec previously, but concatenating and interpolating strings, awkwardly and non-cross-platformily; so it's a definite improvement.) Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: Bootstrapping a module community
John Siracusa writes: The first is my object/relational database mapper thingie. ... The second is an object-oriented interface to HTML, with a focus on HTML forms and fields. I developed this one because there was nothing like it in CPAN at all (which surprised me). Ah, now you mention those, I remember this morning reading your reviews of them on the Cpan Ratings RSS feed -- so that bit of marketing reached at least me! OK, so I haven't used either of them, but at least I had a look at them to see if they were the kind of thing that'd be of use to me. It's quite possible there are other people also reading that feed who did likewise and then actually went on to use the modules. Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: RFC: DBIx::Counter - Manipulate named counters stored in a database
Rhesa Rozendaal writes: Smylers wrote: my %opts = (countername = $countername, @_); [...] bless \%opts, $pkg; But supplying the default values for each individual option means this technique doesn't avoid having a line listing each option -- it just saves having to mention the keyname twice on each line -- so may not be worth doing. That's one reason; the other is that the way I do it now doesn't introduce unwanted data in my object. Any unknown key-value pairs are silently discarded. I considered that, and decided it didn't matter. Theoretically people shouldn't pass unknown named params to your method; it's undefined what happens if they do, so I wouldn't worry about it (your way ignores them straight away; my way stores them in the object for ignoring later, but the end result is pretty much the same) and just do whatever seems simpler. (Arguably silently ignoring them is not the best thing to do -- the user's done something pointless, probably a typo or a misunderstanding, and it might be helpful to tell them, and perhaps using something like Params::Validate would be better than either way.) Question: Consider the point of view of the author of a module that subclasses your module; such a module could well add further named params for its additional functionality -- is it more useful for the constructor in the superclass to store 'unknown' named params in the object or not? (I can think of arguments either way, and I'm feeling too lazy today to work out which I'd prefer.) But I'm thrilled that a class with only four methods and very little functionality can generate this discussion. I really like this :) ... You've made me aware of a number of shortcomings that I hadn't given much thought. But most importantly, you've given me the confidence that it's quite doable, though by no means trivial, to put a good package together. And I very much enjoyed our conversation too :-) Good! I've enjoyed it too -- you've asked questions very politely, and you've given good consideration to suggestions, that I'd've felt it rude for me not to put the effort in and examine your code! I think this is what open source is _supposed_ to feel like! Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: Forgot password, outdated address
Chris Josephes writes: Any idea of what it would take to get a password reset on a CPAN account? Mail modules@perl.org and ask what you can do to persuade one of the people there that you are who you say you are. Smylers
Re: Namespace Advice
Philippe 'BooK' Bruhat writes: Le mercredi 06 avril 2005 à 12:11, Smylers écrivait: Also PropertySet makes it sounds that it _sets_ properties, whereas you said your module reads them. It all depends if you hear set as a noun or as a verb, doesn't it? Yes, but it's quite common for modules to be Noun::Verb, such as Email::Send for instance. My point was that it's ambiguous, and therefore less preferable than a similar name that couldn't cause such confusion. Smylers
Re: Should DSLIP codes be updated?
Ricardo SIGNES writes: I assume you mean What isn't in META.yml should go in DSLIP. Why not What isn't in META.yml should go in META.yml? META.yml sounds much more sensible to me. It wasn't around when DSLIP was created, but it is now. Of course, even if we change _where_ this metadata is stored, we still have to address Robert's original points about the data itself. Smylers
Re: Name for GStreamer bindings
Torsten Schoenfeld writes: On Wed, 2005-02-23 at 00:26 -0500, Randy W. Sims wrote: I don't see any advantage of using Gst over GStreamer as a name, they both describe the same thing and GStreamer is a tad more helpfull (to google a description). It's all about the length. It always is. Obviously everybody would prefer the modules that they use frequently to have the shortest possible names. The trouble with that is we all work with different things in our daily lives, and abbreviations which are customary in a particular field are unfathomable to those outside the field -- indeed, it's often not even possible to work out what the field is. If all modules have really short names then nobody knows when anybody else's modules are for, which rather defeats the purpose of Cpan. Cpan is a global namespace, and as such names have to be chosen carefully to be as meaningful as possible to people who don't share the author's context. I need something that is easy and fast to type. Why? I can see why you'd _like_ something that's less to type, but why is there a need that applies to this module rather than other modules. You only have to type the module name in the use line and in any class methods, often just a constructor. GST can mean many things (try Googling for it) -- even within the context of Gnome it has another meaning: http://www.gnome.org/projects/gst/ Smylers
Re: Algorithm::RootFind Request for Comments
David Landgren writes: Spencer Ogden wrote: Any other suggestions as to how to handle sort of 'config' settings? Use named parameters. bisection( \func ); bisection( \func, min = -100 ); bisection( \func, min = 20, max = 40 ); That's probably what I would do. It's still irritating if you want to make many calls to bisection all with the same (non-default) values of epsilon and max_iter, because then you have to specify them on every call, or use the global accessors to change the package variables, changes which will still be in affect elsewhere in your program (or in other modules, or in other programs you're sharing a mod_perl process with, or whatever). In some ways it'd be better to encourage people to modify the package variables directly, rather than using accessor functions, because then the changes can be localized: local $Math::RootFind::epsilon = 0.01; Another option when you want some data to be associated with some function calls is to put the data into an object and make method calls on it: my $thingy = Math::RootFind-new(max_iter = 12); $thingy-bisection(\func, 20, 40); For the typical case, using the default values, you can avoid constructing an object and just use a class method: Math::RootFind-bisection(\func, 20, 40); But while that solves the problem I don't like it: there are many modules on Cpan which provide similar OO interfaces, and I find them annoying to use. Having to call a class method when what you want is a function is rather tedious, and a little misleading. In this particular case we've avoided the unusual case of having to specify optional params multiple times at the expense of having to spell out the full class name on all calls in the usual case -- that's hardly a win. That can be addressed by making bisection be a hybrid that works as either an instance method call or a direct function call that can be imported, like CGI::param is. That's kind of messy though, and I'm not convinced the complexity is worth the effort: merely documenting the ways in which your module can be used then makes it look much more complicated than it actually is, which can be offputting. And the other reason why I don't like OO here is that I want an object to be modelling something tangible. Here we can have a Math::RootFind, which doesn't really make sense, and I called the variable above $thingy because there isn't an obvious name for what it represents; that is often a red flag that such an entity is representing an artificial entity. Smylers
Re: When the prophet won't go to the mountain, the mountain must go to the prophet.
A. Pagaltzis writes: it's an Atom newsfeed for cpanratings.perl.org: http://plasmasturm.org/feeds/cpanratings/ Thank you -- I'd thought it a little odd that the Cpan Ratings site provides feeds for individual module and author pages, but not for its main page. Your scraping is very much appreciated. Smylers
Re: MySQL::Backup?
Sean Quinlan writes: On Tue, 2004-10-26 at 14:40, Mark Stosberg wrote: I understood 'DBIx' to be DBI extensions, which is not what this is. Correct. This module specifically uses tools provided with MySQL for managing administration (mysqladmin and mysqldump), and does not use DBI at all. Right, so DBIx:: definitely seems like the wrong place for it. However, there is no reason the basic concept could not be expanded such that others could provide similar backup managers for other database servers. Would Backup::MySQL be better, allowing for Backup::PostgreSQL, etc. down the line? I don't think a generic Backup:: namespace makes much sense -- the set of things that can be backed up is not particularly meaningful. Or should such things stay under specific server namespaces? Something like Database::Backup::MySQL would make sense. But there isn't really an existing Database:: namespace (there, unfortunately, some database things in the DB:: namespace, but that _ought_ to be kept for the debugger, so let's not make that problem worse) whereas there is a MySQL:: namespace. Yes, it might've been better if everything in MySQL:: had been called Database::MySQL::whatever. But if we get too idealistic over this, nothing would ever get named (or everything would be constantly being renamed). MySQL:: is in use, and isn't terrible[*0], so let's keep using it. [*0] Perhaps my standards are too low, or I'm too jaded from exceedingly badly named modules, if not being terrible is now my criteria for naming? Smylers
Re: MySQL::Backup?
Christopher Hicks writes: On Tue, 26 Oct 2004, Smylers wrote: ... DBIx:: should be for things that are generally usable with DBI, where the I is independent ... I agree with Chris much more than Smylers here, but if we go along with Smylers perspective for a minute then we need /some/ hierarchy for database-related things that aren't avertising they're using DBI for some reason. Why? There are several top-level namespaces on Cpan that are simply the names of some external software that the modules in that namespace work with. In particular, there are already many in the MySQL:: namespace: http://search.cpan.org/search?m=moduleq=MySQLs=1n=20 It may not be a perfect namespace, but it certainly isn't terrible, it's unambiguous, and surely it's better to keep on using it for similar 'MySQL'-related modules than to put new ones elsewhere (or persuade all the existing ones to move)? The more I think about it DBIx would seem to be the winning place for this sort of thing. When I read Mark's message I realized his point is what I'd been wanting to say in the first place; so the more _I_ think about it, the more DBIx:: seems like a completely inappropriate place for this module! Smylers
Re: advice for Perl 6 module
[EMAIL PROTECTED] writes: I'm starting to rewrite a module (Set::Infinite) for Perl 6. Um ... OK! I'd like to know if there are already guidelines on how to proceed. I don't think so. Some options I've thought of: - don't put it on CPAN That's possible. If you do put it on Cpan then people may try to download and install it, and current perls will trip up over even the first line of a Perl 6 module. - change version to 2.00_00 I reckon that'd look like a newer version for Perl 5. - use Set::Infinite::Perl6 namespace Possibly. However that would only be a short-term measure: once Perl 6 is in use that'd be an inappropriate name. But obviously the problem needs solving generally for Perl 6 modules, and if you just want something circulating now for playing with and testing it doesn't matter if you use a temporary name that has to change later. Except that the purpose of releasing such a module now would not be of any use for people wanting to do stuff with infinite sets. But it would be of interest to people wanting to experiment with Perl 6, even if they've got no particular interest in sets. That would suggest: - use Perl6::Set::Infinite namespace But don't do that: there are already things in the Perl6:: namespace, and they are Perl 5 modules that implement (approximations of) Perl 6 features. There is a definite expectation that modules in the Perl6:: namespace will run on Perl 5 interpreters! Sorry, I don't have any good ideas about what to name it; it seems to me that, as an incompatible language, Perl 6 modules should be entirely parallel to Perl 5 modules without infecting the current Cpan. Even after Perl 6 is released there are still going to be many people requiring Perl 5 modules; having the CPAN module download Perl 6 modules is not going to be any better for them than downloading Python or Ruby modules would be. Currently CPAN always grabs the latest version, something that often leads to problems on a new FreeBSD 4 server we have running at work, which has perl 5.005_03: many current Cpan modules (understandable) require 5.6 or newer and so refuse to install. But we already have those modules running on existing FreeBSD 4 servers -- they were installed a few years ago with what was then the latest versions. So we have to go hunting for old versions to install on the new server. I realize we're quite unusual in having a new server with such an old perl on it. But even several years after Perl 6's release I don't think it'll be unusual to have Perl 5 around. Smylers
Re: Mail::Vacation abondoned?
Adam Monsen writes: Hmm, maybe Email::AutoReply would be better? I think so. But talk to Simon and others in the Email Project first, to make sure that your interface fits in with what others are doing. If you haven't read it, Simon's article on Perl's mail modules is worth reading: http://www.perl.com/pub/a/2004/06/10/email.html Smylers
Re: Mail::Vacation abondoned?
Adam Monsen writes: I need a vacation autoresponder that can (at least) be used within ~/.procmailrc. I'll write one unless someone knows of a useful one. I'd like to take over the Mail::Vacation namespace and fill it with some code that works. If you're writing a new e-mail-related module, it's worth liaising with Simon and Casey who have recently been doing much good work in the Email:: namespace, writing a bunch of simple-to-use modules that work well together (along the lines of how others have been doing in the DateTime:: namespace). It would be good for your code to work with theirs. Smylers
Re: module name for Wily (a text editor) interface client?
Christopher Hicks writes: I would think the existing examples might provide some light on this but the modules to interface to emacs seem to be in their own Emacs:: space and the vi-related modules seem to be in Vi::. I'm not sure what the received wisdom is for the right way to do this would be, but the option based on precedents could only be Wily::. But 'Vi' and 'Emacs' are arguable more a Way of Life than a mere editor -- also they are so widely known by many people (especially those with a Unix background) that there isn't much chance of confusion or ambiguity with their names. That possibly doesn't apply to 'Wily'. Or, more to the point, it certainly doesn't apply to every possible application that anybody could ever want to create a Perl interface to. There are some 'Excel'-related modules in the Spreadsheet:: namespace. I think creating an Editor:: namespace for 'Wily' would be reasonable. Smylers
Re: perldoc cgi script
Eric Wilhelm writes: This allows you to access the documentation for all installed modules and scripts via your browser ... if anybody knows of similar scripts, I would like to hear about them. Apache::Perldoc does this (though it requires mod_perl, not just a CGI-enabled web server). Smylers
Re: [Module::Build] requires_one_of
David Wheeler writes: On Jul 17, 2004, at 1:09 PM, A. Pagaltzis wrote: In fact you are arguing against virtual packages if the script only works with DBD::Pg or ::mysql, but not other DBDs -- because you'll need to depend on ::Pg or ::mysql explicitly even if there was a virtual package for any DBD. Then I would require the Pg_or_mysql virtual package. Another point to consider is how such lists of alternatives could be added to, and whom should be doing the adding. If you've written something that depends on the Pg_or_mysql virtual package then your application will only install with either of those DBD drivers, even if somebody else later comes up with a compatible driver that your code would actually work with. This isn't far-fetched -- DBD::PgPP exists, for example, and has the aim of being compatible with DBD::Pg. Rather than the dependent app (or module) having a list alternatives that are known to work, it could instead depend on some 'abstract' package. Other distros are then able to say that they 'provide' that abstract package. So if another module is writtent that has equivalent functionality and the same interface then it just needs to label itself as 'provide'-ing that 'abstract' package, and the dependent app will just work with it. That nicely puts control of whether a distro provides certain functionality in control of each distro's author; the knowledge is in the system as a whole, and no one person has to keep an exhaustive list up to date. Also, David has an app that depends on something Pg-or-mysql-like; suppose I do too, as do several other people. When another Pg-or-mysql-providing module appears it doesn't make sense for every single one of us app authors to have to note this, tweak our install settings, and upload a new version to Cpan; that's lots of duplicated and redundant effort. The obvious flaw in my proposal for this particular instance is that Pg and mysql don't provide identical interfaces, so I'm guessing that David hasn't written code that just happens to work with either of them but has conditions in it specifically to deal with their differences. To make a 'provides' feature work, those differences would have to be abstracted out elsewhere. For example, something like this could work: David determines exactly which features are needed from a DBMS by his app, and specifies the interface that his app will use to access them. DBD::mysql::Wheelerish is written; it depends on DBD::mysql and provides DBD::Wheelerish; the code puts the defined interface on the 'MySQL'-specific stuff. Similarly DBD::Pg::Wheelerish does the same thing for 'Postgres', depending on DBD::Pg and providing DBD::Wheelerish. David's app then depends on DBD::Wheelerish; it doesn't care about (or even know) which DBMS is being used, and will happily work with anything that has those features. In the future somebody writes DBD::Oracle::Wheelerish. David's app will now just work with Oracle without him having to do anything with it at all. Almost certainly Wheelerish isn't the best name here, but without knowing what the features in question are I couldn't think of anything more specific. Smylers
Re: META.yml keywords
Ken Williams writes: I think we could get far more mileage out of tuning the search engine better for the needs of perl-module searching, You speak great sense. Now it's back to Simon's point about the source code for it not seeming to be available. Smylers, I think your proposal is interesting ... Proposal is flattering to my message -- thinking out loud was more like it. I wasn't seriously expecting anybody to start implementing any of the things I said, but was just pointing out that there are many different ways of approaching the problem which don't involve keywords ... Smylers
Re: Cpan Ratings (Was: Future of the Module List)
James Keenan writes: Pardon my ignorance, but ... What is the 'default phone-home behavior' in the Makefile.PL's about which Randal was complaining? The author wished to keep track of how widely his modules were used -- at least partially as motivation for bothering to write them. Originally he had something in Makefile.PL which downloaded a file from his own website then executed the contents of that file. (Among other things, it warned the would-be-installer if a newer version of the distro was available.) People pointed out how insecure this is, and the damage that could be done by somebody hijacking his server and substituting a malicious Perl script at that URL. Others simply didn't like the idea at all of being counted and monitored without their consent; this phone-home behaviour happened by default, without warning. Somebody merely running Makefile.PL (or the CPAN shell or whatever) wouldn't expect it. The author responded to the security problem by changing his installers to download a dynamically generated data file, not a Perl script, which still allowed him to do counting and have the installer warn about old versions, but didn't have the security risk. But this still happened without warning, and would be unexpected to most users. Several people, Randal included, found this intrusive and unacceptable. I see that a few weeks ago the author removed all phone-home behaviour, so even this is no longer an issue. Smylers
Cpan Ratings (Was: Future of the Module List)
Randy W. Sims writes: Not long ago I was exploring the cpanratings site and discovered the unhelpful rampage by one particular reviewer http://cpanratings.perl.org/a/181. Why do you think Randal's comments are unhelpful? Personally whenever I'm (considering) downloading a module I haven't used before I read any reviews it has. It would never've occurred to me that an author would've have put default phone-home behaviour into a distribution's installer, but on reading Randal's review of a module I'd then be aware of it in advance. That's certainly useful information to have. Admittedly when you look at the page giving all Randal's reviews there is a fair amount of repetition going on, but the information he gives is pertinent to every one of those modules, so it's the only way of ensuring the message reaches potential users of all of the modules. Actually I'm much more concerned by the opposite problem, that people give 5 stars to modules they use lots and don't bother reviewing other modules, or ones they tried a bit but gave up on -- partly, I suspect, cos if you never quite got into a module properly then you feel it'd be unfair to review it. Look at one of the modules that Randal reviews, CGI::Builder: http://cpanratings.perl.org/d/CGI-Builder That's a flurry of 5-star reviews in a very short space of time. I suspect that isn't a co-incidence -- perhaps there's a CGI::Builder mailing list somewhere that had a recent post encouraging users to review the module? There isn't anything wrong with that[*0], but it could distort the value of reviews over all. Cpan Ratings is still young. Let's give it some more time to pan out; I think it's one of the better ideas out there. There's also some degree of a chicken-and-egg situation going on, but once the site has more reviews in it there'll be more reason for people to consult it and for places to link to it more prominently. [*0] Well, there are ways in which such a mail could be phrased that would be wrong; but simply soliciting genuine reviews from genuine users can hardly be faulted. Smylers
Re: ANNOUNCE: WWW::Map 0.01
Dave Rolsky writes: I'm still trying to decide between sticking with WWW::Map or switching to WWW::MapService. How about WebService::Map? Search the [EMAIL PROTECTED] archives for WebService and you'll see that there have been recent attempts to distinguish between modules that help implement generic webby things (in WWW::) from those which are an interface to a service which just happens to be provided by websites (in WebService::). Admittedly there are web-servicey modules in the WWW:: namespace, mostly from before anybody had thought to make the distinction, but that isn't a reason for making the situation any worse. WWW::MapService is odd from a hierarchical point of view, cos then it encourages other modules to be named along the lines of: WWW::ISBNService WWW::PriceCompareService WWW::TrainTimesService (And sorry for not saying this earlier -- I mentally composed something like the above message when I saw your original mail, but it took me a couple of days to find the time to type it out!) Smylers
Re: New module: CGI::Tooltip
A. Pagaltzis writes: The HTML generation code in CGI.pm is misplaced. Agreed. CGI::Tooltip I vote against this. I'm not sure that there's a poll going on ... but using the CGI:: namespace would just seem to be making the problem worse. HTML::Tooltip Could (barely) live with that, That's rather an extreme reaction -- it can be annoying when so many modules are badly named, but I don't think it's ever been the cause of death. if you must pick this, but it would IMHO be mistaken. I think it's the best name anybody's suggested -- it's a module for generating HTML tooltips, so HTML::Tooltip describes exactly what it does on the tin. JavaScript::Tooltip::HTML See previous mail and above explanation: this is perfect. That makes the mistake of emphasizing implementation over purpose (as with so many of the modules in the Tie:: namespace). If somebody wants HTML tooltips then they aren't necessarily bothered how they are implemented. Or, the module could be called HTML::Tooltip::JavaScript, allowing for somebody else to create HTML::Tooltip::CSS in the future. That puts the purpose first and the implementation last. Putting this in the JavaScript:: namespace because it uses JavaScript for its implementation would be like putting all object-oriented modules in the Class:: namespace, or saying that Net::SSH::Perl should be in the Perl:: namespace becase it's implemented in Perl, or ... Smylers
Re: Reshaping the modules list: a starting point, help remove the bias.
Sam Vilain writes: I've performed an initial re-work of the modules list. Please look over the sections of the list that you are most in touch with and provide feedback. After this stage, I'll try and fit the modules from the existing lists and the Phalanx project into it one by one, and see how I get on. Obviously this is a moving target; it won't be possible to change the list once now and then stick to it forever more: as modules are written the categories inevitably will have to adapt. In general it's much easier to see as new modules come along where to create (or split) categories; that also prevents premature over-splitting, to make a theoretical distinction between modules that are never written. In other words, try going through your next step of taking the Phalanx and existing list and putting the modules there into categories -- that'll show how well the categories work in practice much better than people reading though it here will be able to do. Presumably modules are allowed to be in multiple categories if they happen to do something that pertains to them? (If not the whole thing is very likely to be doomed -- people will think differently about classification, and indeed how to navigate the tree, and having to pick only a single category will lead to many people not finding what they were looking for.) Related to this, are categories allowed to make multiple appearances? This is the only sane way to deal with categories that have multiple inheritence -- DMoz (Google Directory) does this with some kind of 'symbolic link', where among a particular's category's subcategories are links to elsewhere in the tree. For example some people might think of web interfaces being under 'interfaces', so put a link there. Again this helps reduce disputes, and avoids the fruitless search for One True Hierarchy. Networking - raw communication, including IPC: You have 5 categories that all start Networking -, which suggests they collectively are really another level of hierarchy. Networking - providing services: - Server and Daemon Utilities - Web Services Frameworks: - Apache: - OpenFrame - etc, submissions welcome :) - Web Services Components: - Lots of the Apache sections from above could be moved here - Authentication, Security and Encryption: - Authentication Systems - Encryption algorithm implementations - Security interfaces It isn't clear to me exactly what these are (except for the 'Apache' stuff), and where CGI-related modules would go, including the 'bigger' run-an-entire site modules such as HTML::Mason, CGI::Application, and the wiki things. There are also many modules which exist to provide an interface to a particular website (banks, URL-shortners, search engines). Smylers
Re: Paging Dr. Barr...
Austin Schutz writes: ... I have had no luck in contacting either the author (Graham Barr, [EMAIL PROTECTED]) or the maintainer (Arun Kumar, [EMAIL PROTECTED]). While it's likely and understandable that they're just ignoring me, there's also the possibility they just aren't getting their mail. Anyone have any email addresses they know (through actual use, not perldoc XXX.pm conjecture) are good for either of these folks? Graham Barr posted to [EMAIL PROTECTED] the day before yesterday, ostensibly using the address you quote above: http://www.nntp.perl.org/group/perl.modules/28606 Smylers
Re: Finding the module you want (was: New module Mail::SendEasy)
Rocco Caputo writes: On Tue, Feb 10, 2004 at 08:19:14PM +, Smylers wrote: Similarly an author doesn't need to understand all of the problems, just so long as they state exactly what they are looking at, preferably stated upfront. So the article starts by saying I'm looking for a something that does ..., and these are the features that I'd like it to have ..., and this is the way it'd be convenient for it to operate. Conveniently, I've written exactly the thing that provides the features I need, in a way that's most convenient for my purpose. Everything else pales by comparison, otherwise I would not have written it. Here, let me show you. Yeah, that could happen. But such a review would likely be discredited, and may well provide impetus for somebody else to provide a better one. Starting with an explicit list of 'requirements' like that has several advantages: * It makes the subsequent review more objective (and, just as importantly, makes it be seen to be objective), as modules are being compared against defined criteria rather than just on feelings. It's easy to tailor criteria to suit one module over others. True, but by explicitly listing the requirements it means this can be seen by everybody: if you've got a need for a particular type of module and your criteria don't match well with those in the review then you know not to reject (bits of) it. If the review mentions additional criteria then it should make you pause and evaluate whether they apply too you. If you haven't got any criteria then, yes, you're at the mercy of reviewers' whims. But is that really worse than the current situation? Should we get swamped by obviously biased reviews then let's address that. But it isn't a problem we have yet ... Smylers
Re: Finding the module you want
David Manura writes: Smylers wrote: But yes, as the CGI::Lite maintainer I do have an interest in a review of CGI-related modules: I'd like it to put people off using CGI::Lite so that I can stop trying to maintain it and everybody can use something saner instead ... Of course, we'd never know that from the current POD and ratings system ;) That wasn't meant entirely seriously. But there did seem to be an underlying assumption that module authors have a vested interest in persuading people to use their modules, even when they are not the most appropriate for the job. So I was questioning that assumption by highlighting the potential for bias in the opposite direction. If I were selling modules I might think like that, but since I'm giving them away I don't see the point of persuading people to use 'my' modules: if something else suits their needs better then blatantly they should use it. (Apart from anything else it reduces the number of requests for features that I don't deem a good fit with what I see as the core purposes of my modules ...) I've wondered myself whether I should move some CGI programs to CGI::Lite for improved performance. I took over the maintenance of CGI::Lite because I was using it, I had a bug-fix for it, and the previous maintainer was no longer active. I have some issues with it. Yes, you can't (yet) work that out from the current Cpan ratings. I thought it'd be silly to give rate my own module pointing out obviously bad things without at least attempting to fix (or document) them. For example a major problem is that it has no licence; I need to contact its author asking about that, and either documenting what its licence is or putting in a big warning that it's unknown. But I will do this, and update the docs so that the areas where the module falls down are mentioned, and rate it -- honest. Smylers
Re: Finding the module you want (was: New module Mail::SendEasy)
Mark Stosberg writes: From another angle, I see the current problem with the rating system is not abuse-- I've never noticed any beyond people rating their own modules with 5 stars with reviews like It's my module. It's primary downfall now is that it's simply not being used a lot. Making further barriers to using it would only serve to work this worse. Yes. My biggest problem with CPAN Ratings at the moment is the amount of hero-worship and mutual backslapping going on. The modal score for individual ratings is clearly 5 stars -- sometimes the homepage can be seen with 15 or more consecutive reviews all with 5 stars (from a variety of different 'raters'). It looks like the next most-common rating is 1 star, for the people panning the completely worthless modules. Possibly just because that's easier to do, compared with other ratings. But I've seen 5-star reviews say things such as will be a great module when it's finished or this is quite good, once you've worked round the docs which are far from easy to follow -- where even within a single review the comments don't match the number of stars! Often the problem with ratings is that the rater hasn't used alternative modules sufficiently to know what else is out there. I really ought to rate more of the modules I use. Part of the problem is that I think of some niggle I could mention in a review, then it seems unfair on the author to complain about it without raising it as a bug report first, but then I'd have to come up with a test-case and ... then I put the whole thing off for later. Smylers
