Re: OK, so we've decided that the right modules are too hard to find.
On Sun, Feb 15, 2004 at 03:56:39PM +1300, Sam Vilain wrote: ___ / _ \ | | | |_ _ | |_| ||\ | ||___ \___/ | \| |___ |___ upon a time, the Perl 5 modules list was an excellent resource for those seeking to do anything non-core with Perl. However, it has not kept pace adequately with the needs of the community. I'd like to see a summary of what those needs of the community are. (Maybe I missed it as I've not been following as closely as I'd have liked. In which case a link to an archived summary would be great.) It's very important to be clear about what the problems actually are. I propose, what we do about this situation is : - expand the modules list into a new section of the www.cpan.org site, by; - deciding if the current categories are good enough 'in this day and age'; using the current list as a starting point, go through each category and decide whether it is a useful grouping any more. This will ideally also involve individuals with experience with other languages trawling over the appropriate CPAN equivalents, ie PEAR, RAA, etc, and providing nice, *brief*, informative reports on their structure. We will then hopefully have a half-decent list of categories. This process should be quick, perhaps reporting back its progress to the list every few days until there is a general consensus. Okay. - encourage curators to step forward, or groups of curators, for each category; possibly even create mailing lists for people with a general interest in the technology in that category; to field questions about naming for new modules to fit into each category. These curators must have the power to update the contents of the relevant portions of the www.cpan.org site. The idea would be to have each category something like the http://poop.sourceforge.net/ site - but on a standard template to lend it more credibility. Ideally with space for user feedback. I would hesitate to seed the listing of actual modules on the current long Perl 5 modules list. Factors such as the usage that the module has seen, whether long standing bugs were ever fixed, whether a better module has come along since and gained widespread acceptance, etc need to be taken into consideration. I disagree. You're mixing different goals that ought to be kept separate. Originally the Module List had two goals: 1: to help people find perl modules for a particular task. 2: to provide a second-tier of modules above the 'anarchy' of people uploading half-baked ideas with half-baked names. You could argue that Goal 1 is now largely addressed by searching search.cpan.org (although that's certainly not without problems). However the limited integration with the Module List's hierarchical categories and other metadata is unfortunate. I think that's partly due to Graham Barr's view (as I remember it, I might be wrong here) that the Module List was too incomplete relative to the whole of CPAN to be useful and he's right. So let's fix that - see below. Goal 2 is still important - as you can see from archives of [EMAIL PROTECTED] when there have been discussions leading to a better choice of module name. But [EMAIL PROTECTED] has it's own set of problems (that I hope will be addressed when it's integrated with RT so requests don't fall between the cracks). Many popular modules are missing from the list altogether. The text file is out of date. The underlying database isn't: http://www.cpan.org/modules/03modlist.data.gz (Though it is incomplete because not enough authors take the steps to get listed, but that's a different set of issues.) Please work with the PAUSE system, and Andreas and myself, to enhance what already exists (which includes a UI for module authors to pick which category they want the module in). Here's what I'd suggest: 0. Don't underestimate how difficult and subtle naming issues can be. 1. Split and extend the list of categories aiming for about 2 to 3 times the number to keep it managable, perhaps grouping the categories into a two-level hierarchy (but the top level is just for human use, the 2nd level names should be self-descriptive without the 2st level names). 2. Map modules from the old categories to the new ones This needs to end up as a sequence of SQL statements that can be run on the PAUSE mysql db to update the category number for each module that has one. 3. Write a script to generate http://www.cpan.org/modules/00modlist.long.html from http://www.cpan.org/modules/03modlist.data.gz or ideally from the underlying mysql database (with simpler formatting and focussing on just the modules) and give it to Andreas for PAUSE to use automatically. 4. http://www.cpan.org/modules/03modlist.data.gz is actually a perl module called CPAN::Modulelist but
Re: OK, so we've decided that the right modules are too hard to find.
Tim Bunce [EMAIL PROTECTED] writes: For those modules that are not on the Module List, (i.e., not in http://www.cpan.org/modules/03modlist.data.gz) and which have a 'significant' existing user base, develop a Fast Track process to get them added to the Module List. Good idea, but don't we need to solve the current module registry problems as well? Many module authors issue submission requests and never get a reply. -- Johan
Re: OK, so we've decided that the right modules are too hard to find.
At 13:57 +0100 2/15/04, Johan Vromans wrote: Tim Bunce [EMAIL PROTECTED] writes: For those modules that are not on the Module List, (i.e., not in http://www.cpan.org/modules/03modlist.data.gz) and which have a 'significant' existing user base, develop a Fast Track process to get them added to the Module List. Good idea, but don't we need to solve the current module registry problems as well? Many module authors issue submission requests and never get a reply. I've released about 30 modules in the past 1.5 years. I _never_ bothered to try to register. I guess that means something. Liz
pure perl Zlib
Ton Hospel has written a pure perl implementation of gunzip. (no mean feat) Autrijus sent to the PAR list and asked if anyone could refactor it to emulate Compress::Zlib's interface sufficiently to allow Archive::Zip (and therefore PAR) to work with it (to unpack zip files). It seems that the only 2 functions from Compress::Zlib's API actually need implementing - inflateInit and inflate. I'm partway through this, and I'm wondering what the name should be. Autrijus suggested Compress::Zlib::PurePerl, which I think is reasonable. Are there further suggestions? Nicholas Clark
Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
On Mon, 16 Feb 2004 01:32, Tim Bunce wrote; I'd like to see a summary of what those needs of the community are. (Maybe I missed it as I've not been following as closely as I'd have liked. In which case a link to an archived summary would be great.) It's very important to be clear about what the problems actually are. I don't really want to argue this side of things, I think that the problems pretty much speak for themselves. But I hate unspoken consensus, so let me suggest a few from my perspective; this applies to the combined Perl 5 modules list / using search.cpan.org: a) searching for modules for a particular task takes a long time and unless you get your key words right, you might not find it at all. Refer the recent Mail::SendEasy thread. b) it is very difficult to find good reviews weighing the pros and cons of similar modules; they exist, but are scattered. CPAN ratings was a nice idea, but has too many First Post! style reviews to be useful in its current form IMHO. c) it is nearly impossible to tell which modules are the wisest choices from a community size point of view; using modules that are more likely to fall out of maintenance is easy to do. Keeping involved with user communities helps, but many professional Perl programmers are not in a position to join general language discussion groups, hang out in IRC channels and attend conferences where this information is widely discussed. use.perl.org and perlmonks.org are great, but in my experience, they still involve a large time sink to get the simple reviews of the community. d) some great modules are not registered (I am referring of course to such masterpieces as Pixie, Heritable::Types, Maptastic :), Spiffy, Autodia, Want ... and those are just the ones missing in my bag of tricks) Originally the Module List had two goals: 1: to help people find perl modules for a particular task. 2: to provide a second-tier of modules above the 'anarchy' of people uploading half-baked ideas with half-baked names. Honourable goals, which it solved adequately for a period of time, and full credit where it is due. But now let's look at where we are. We've got masses of modules, truckloads of categories and thousands of contributors. This task cannot be left in the hands of a handful of hackers, no matter how much awe they inspire, they probably still have lives and day jobs ;) I will maintain that the current format, or even simply adding some more fields to the database is *not* enough information to give uninformed people looking for a module the information to make an informed decision. It is my gut feeling that only editorial content, managed by people who are experts in the field, will truly perform this task - and that to gain maximum support, that it should be included in the content mirrored along with the rest of cpan.org. I think we're mature enough as a community to be able to produce this content without it disolving into flamewars or being too one-sided. In particular, I really think that as little red tape should be applied to this system as possible. Let's just set up a few CVS / subversion accounts, to edit content that is autopublishing to the www.cpan.org site, with a few disclaimers chucked on the bottom. LARTing the naive and troublesome as appropriate. Goals will provide editors with guidance, and I suggest some goals below. How the CVS accounts, and auto-publishing is implemented and administered is a non-trivial detail, but I do not think that it is yet the correct time to thrash that out. Let's just let the concept stew. I would personally like to see goals like; a) the content should be *helpful* for programmers, that are: - new to programming - or just new to Perl - or just trying to pick up that field/category of Perl as quickly as possible. b) the content is *concise*; refer to and summarise the gist of reviews, don't duplicate them. Reading content should *save time*. c) Each module was written with particular goals in mind; therefore, the editorial content should attempt to identify what *distinguishes* modules. In this way, a prospecting author can decide which is best suited for their particular purpose. In particular, conflicts of opinion about modules are largely down to differing views on which goals of the module are most important. Don't argue, try to understand your fellow programmer's viewpoint. d) The cargo cult effect is both glorified as a way of helping the community gather steam and establish common practice, and humourously regarded as sometimes meaning that much of the community misses the simpler approach. So, content should be written that pays attention and refers the programmer to communities that have chosen to thrash out a particular
Re: pure perl Zlib
On Mon, 16 Feb 2004 10:19, Nicholas Clark wrote; Autrijus suggested Compress::Zlib::PurePerl, which I think is reasonable. ...but it doesn't use Zlib! :) Compress::Gzip? -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) If cars had followed the same developmental path as computers, a Rolls Royce would cost $100, get a million miles per gallon, and explode once a year, killing everyone inside.
Re: pure perl Zlib
On Mon, Feb 16, 2004 at 10:43:27AM +1300, Sam Vilain wrote: On Mon, 16 Feb 2004 10:19, Nicholas Clark wrote; Autrijus suggested Compress::Zlib::PurePerl, which I think is reasonable. ...but it doesn't use Zlib! :) Compress::Gzip? But it doesn't compress. Compress:Gunzip? Uncompress::Gzip (Neither really meant as serious suggestions) Problem is that it's an emulation of bits of Compress::Zlib's interface, so I feel that a clue should be in the name. As should the bit that it's pure perl, as otherwise it's like huh, why another front end to some C code? Nicholas Clark
Re: OK, so we've decided that the right modules are too hard to find.
[EMAIL PROTECTED] (Johan Vromans) writes: Good idea, but don't we need to solve the current module registry problems as well? Many module authors issue submission requests and never get a reply. Tim also wrote: But [EMAIL PROTECTED] has it's own set of problems (that I hope will be addressed when it's integrated with RT so requests don't fall between the cracks) -- Oh dear. I've just realised that my fvwm config lasted longer than my marriage, in that case. - Anonymous
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: OK, so we've decided that the right modules are too hard to find.
[EMAIL PROTECTED] (Elizabeth Mattijsen) writes: I've released about 30 modules in the past 1.5 years. I _never_ bothered to try to register. I guess that means something. Likewise. (although slightly more than 30 ;) I just don't see the point of the modules list, especially now we have search.cpan.org. -- When Simon Cozens writes code, I always think twice about whether something is a bug or an esoteric implementation. - Daniel Packer
Re: Finding the module you want (was: New module Mail::SendEasy)
* Rocco Caputo [EMAIL PROTECTED] [2004-02-12 11:29]: 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. Are you picking a bone with someone particular? :-) -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: pure perl Zlib
* Sam Vilain [EMAIL PROTECTED] [2004-02-15 22:44]: ...but it doesn't use Zlib! :) Compress::Gzip? * Nicholas Clark [EMAIL PROTECTED] [2004-02-15 22:53]: But it doesn't compress. Compress:Gunzip? Uncompress::Gzip (Neither really meant as serious suggestions) Problem is that it's an emulation of bits of Compress::Zlib's interface, so I feel that a clue should be in the name. As should the bit that it's pure perl, as otherwise it's like huh, why another front end to some C code? Then maybe it needs to mention that it's an emulation, but besides Compress::Zlib::Emulated anything I come up with needs at least three words, and those are still incomplete. Maybe Compress::Gunzip::ZlibAPI? -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
On Mon, 16 Feb 2004, Sam Vilain wrote: who are experts in the field, will truly perform this task - and that to gain maximum support, that it should be included in the content mirrored along with the rest of cpan.org. I like what you're proposing, but I think the best way to do this is to simply start it, and then try to get the CPAN folks to buy into it once it's established as being useful. Or instead of cpan.org, maybe it could be a *.perl.org site. There's a lower barrier to entry here, I think. I think we're mature enough as a community to be able to produce this content without it disolving into flamewars or being too one-sided. We shall see ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [RFC] Text-Balanced 1.96 proposed interface changes: return failure in list context
David Manura wrote:
As the current maintainer of Text::Balanced,
And *thank-you* for taking on that role, David! :-)
(2) extract_multiple will recognize only the empty list and (undef, ...)
return values from extractor functions as match failures. This is what
the POD currently states, but ('', ...) was previously also recognized
as a match failure in the actual code. Under the new proposal, ('',
...) is not returned by any built-in extractor either on success or
failure, so it usually will make no difference. Custom extractors will
be allowed to return ('', ...) on success in the trivial case even
though I don't see much practical application for that.
Actually, there's an important one -- deleting extracted parts. That is,
accepting as a valid match will allow us to create custom extractors that
effectively throw away the data they've successfully extracted. That's handy
for dealing with comments, for example.
I would have prefered the return value on failure in list context to be
the empty list (like the private _match_* functions) since that would
permit code like
elsif ($grammar =~ m/(?=$ACTION)/gco
and do { ($code) = extract_codeblock($grammar); $code })
in Parse::RecDescent to be rewritten as
elsif ($grammar =~ m/(?=$ACTION)/gco
and ($code) = extract_codeblock($grammar))
but some code actually does rely on the $$textref in (undef, $$textref,
undef) being there. Perhaps a 'use' option code be given to enable this
behavior.
Returning the remainder text supports the extract-and-remove metaphor:
($extracted, $remainder, $pre) = extract_whatever($remainder, @opts);
which, if we just returned empty list would have to be:
($extracted, undef, $pre) = extract_whatever($remainder, @opts);
substr($remainder, 0, pos $remainder-1) = ;
which I felt was rather a high price to pay.
I would be fine with a Cuse option to toggle the behaviour though.
Damian
