Re: Let's eliminate the Module List
[EMAIL PROTECTED] (A. Pagaltzis) writes: I object. Browsing is problematic when the amount of data becomes overwhelming, but it is useful as a concept. You're thinking in terms of use, I'm thinking in terms of implementation. -- It's usually // either for a good reason // or a bad reason - Larry Wall haiku
Re: Let's eliminate the Module List
[EMAIL PROTECTED] (A. Pagaltzis) writes: * Simon Cozens [EMAIL PROTECTED] [2004-08-24 15:37]: Repeat after me: browsing is just searching metadata. That is essentially correct, but beware of metacrap[1]. [1] http://www.well.com/~doctorow/metacrap.htm Niggly comments are great! I love the way they really motivate me to get this finished! -- In matters of principle, stand like a rock; in matters of taste, swim with the current. -- Thomas Jefferson
Re: Let's eliminate the Module List
[EMAIL PROTECTED] (Randy W. Sims) writes: Looks like you and Simon should collaborate. We've been chatting. Is it possible or realistic for it to have pluggable search browse engines. I think so. There are three things at issue, all of which can and should be implemented distinctly: 1) Viewing the contents of packages 2) Browsing by category 3) Searching I have no desire to work on 1), since I think search.cpan.org does this very well. (Andy agrees with this idea.) I have no idea to work on 2), since I think that all browsing is a subset of searching - for instance, browsing by keyword is just doing a search for a particular keyword; browsing all modules is just doing a search for type:module, and so on. (Andy... well, tolerates this idea. ;) 3) is the thing I want to work on, and Andy wants to work on 2), so my plan for the time being is to index all the CPAN module metadata and link search results to the current search.cpan.org pages for displaying a given module. Then Andy can come along and turn canned searches into a browse interface on top of that. I still think sourceforge-like hierchical catagories (Topics) in META.yml would make for good light-weight search and improved by-catagory browsing I disagree quite violently with this, but I'm not going to implement searching and indexing in a way that precludes it. I think that the world moved from browse to search some time in the mid 90s (hell, we're even being encouraged to search rather than browse email these days) and that this is because browsing is useful if your search engine isn't good enough. Even so, I recognise that everyone who comes to working on CPAN metadata has their own conceptual axe to grind, so I'll just index whatever the heck is in META.yml and let everone else sort out the details. -- Using Outlook is like running barefoot through a hot ward snogging all the patients - Peter da Silva
Re: Let's eliminate the Module List
[EMAIL PROTECTED] (Nicholas Clark) writes: Until someone does, nothing will change. No-one on this list is preventing anyone from trying this. I'm working on it. The only thing that sucks about search.cpan.org is the search engine, which is a shame since that's the major part of it. Thankfully, I have this really handy Perl search engine toolkit up my sleeve... -- And it should be the law: If you use the word `paradigm' without knowing what the dictionary says it means, you go to jail. No exceptions. -- David Jones
Re: Let's eliminate the Module List
[EMAIL PROTECTED] (Jose Alves de Castro) writes: I don't want to show the results of a search. I want to say Here is the link to the module list. See how long it is? It contains practically everything you need, doesn't it? http://www.cpan.org/modules/02packages.details.txt.gz -- yes /dev/kmem # Shutdown is broken. This'll have to do - plan9 has a bad day
Re: Finding prior art Perl modules (was: new module: Time::Seconds::GroupedBy)
[EMAIL PROTECTED] (Mark Stosberg) writes: I think part of the solution to fix that is to have more contributions to the CPAN ratings system, and consider the ratings in the search results. The searching in search.cpan.org is, unfortunately, pretty awful. At some point I plan to sit down and try using Plucene as a search engine for module data. This would, of course, be easier if the search.cpan.org code was more widely available. *cough* -- Death Damned electrons get into everything. Death I found them in my BUTTERDISH just the other day.
Re: Finding prior art Perl modules (was: new module: Time::Seconds::GroupedBy)
[EMAIL PROTECTED] (Scott W Gifford) writes: It would be interesting to calculate the importance of a module by how many other modules link to it, either via a use statement or by reference in the POD, much like Google does with Web page links. Someone's already done this for CPAN, but I can't find it at the moment. There's a project called Nutch that has abstracted out much of PageRank and that sort of thing that would be useful, if anybody is interested. Algorithm::PageRank has also abstracted out much of PageRank... :) -- Oh dear. I've just realised that my fvwm config lasted longer than my marriage, in that case. - Anonymous
Re: CPAN Rating
[EMAIL PROTECTED] (Khemir Nadim) writes: why do we have Savanna, Rubyforge and other? Because people are naturally fractious and would prefer to reinvent the wheel in order to do things Their Way instead of making use of the available resources. -- We use Linux for all our mission-critical applications. Having the source code means that we are not held hostage by anyone's support department. (Russell Nelson, President of Crynwr Software)
Re: CPAN Rating
[EMAIL PROTECTED] (Khemir Nadim) writes: But I can't live anymore with the low quality and release process that CPAN has!!! *sigh*. Is it that time of year again? We have this discussion every six months or so. Everyone talks about it. Nobody does anything about it. Nothing gets done. Goto 1. Personally, I have no problems with the low quality of modules on CPAN. If a module's bad, I don't use it. -- Congratulations, Simon - I think I've finally discovered someone with a mind that is more warped than mine. - Lionel Lauer
Re: Namespace convenions
[EMAIL PROTECTED] (Erik Norgaard) writes: I just browsed through the namespace guidelines and the concern about avoiding the namspace to clutter up. Namespaces had their day when there was no easy way to search CPAN, and we had to just browse to the modules we want. Now we have a full-text search of the module's documentation at search.cpan.org, browsing is considerably less important, and namespaces are just a quaint idea. Every few months, there's a discussion here about how to fix CPAN, with nobody really establishing that CPAN actually needs to be fixed; even if a concensus is reached, nothing ever gets done about it, and the things that do get done are generally the result of individuals having the right amount of JFDI and acting first and seeking forgiveness later. That said, I encourage people to continue debating what should be done about CPAN namespaces, because it keeps people busy. The intersection of the set of people who have interesting ideas about how to make CPAN better and the set of people who actually contribute a substantial volume of useful modules to CPAN is sufficiently small that I have no qualms about them continuing to be tied up in endless and fruitless discussion. -- COBOL is for morons. -- E.W. Dijkstra
Re: PerlHack - Adding new flag into a SV
[EMAIL PROTECTED] (Graciliano M. P.) writes: I'm working on a module that need to add a new flag to a SV that is stored by it. Urgh. Don't do it! Actually I just need to find a way to mark that SV by this module, so, will be possible to identify this SVs from the others. Piers Cawley worked out a system for using magic to annotate an SV, for his Pixie persistence code. See http://groups.google.com/groups?threadm=843ct6j4c1.fsf%40despairon.bofh.org.uk -- Writing software is more fun than working.
Re: running tests
[EMAIL PROTECTED] (Andy Lester) writes: Sure, and you can turn on HARNESS_VERBOSE to get the raw output of the .t file. prove puts all that stuff behind easy command-line switches, and lets you specify wildcards, and lets you specify a directory that implicitly does all the *.t within the directory, and lets you turn on taint checking, and... And, unlike the bizarre corners of ExtUtils::MakeMaker, is actually documented! -- Do you associate ST JOHN'S with addiction to ASIA FILE? - Henry Braun is Oxford Zippy
Re: AW: defining 'constants' at run time
[EMAIL PROTECTED] (David Nicol) writes: constants before you compile the code that sees them This must be some strange new meaning of the word runtime that I wasn't previously aware of. :) What is being asked for can't be done. -- God Save the Queen! And let Satan take the Prime Minister... - Tanuki, in the monastery.
Re: defining 'constants' at run time
[EMAIL PROTECTED] (Sam Vilain) writes: To the programmer who has some real reason not to use the regex engine, that you don't know about, none of the above are useful. However, if the programmer doesn't bother to explain what that reason is, it's natural to assume that he's just being weird. -- In space 'cat scream.au | tee /dev/null /dev/audio'... - Ben, in the monastery.
Re: defining 'constants' at run time
[EMAIL PROTECTED] (Rodent Of Unusual Size) writes: evidently the usage of DOH in the caller has already been fetched from the symbol table (and found wanting) before the method has been called. is there any way to defeat that? No. -- There seems no plan because it is all plan. -- C.S. Lewis
Re: AW: defining 'constants' at run time
[EMAIL PROTECTED] (Jochen Stenzel) writes: the base technique is to build a use constant statement at runtime and evaluate it via eval(). % perl -w -Mstrict -le 'eval use constant FOO = 3; print FOO' Name main::FOO used only once: possible typo at -e line 1. print() on unopened filehandle FOO at -e line 1. % Any other ideas? -- `And when you've been *plonk*ed by Simon C., you've been *plonked* by someone who knows when, and why, and how.' - Mike Andrews, asr
Re: Reshaping the modules list: a starting point, help remove the bias.
[EMAIL PROTECTED] (Leon Brocard) writes: I don't really see the point of the modules list any more. search.cpan.org and CPAN.pm/CPANPLUS don't use it. Most modules aren't on it. Shouldn't we just give up on it? That's weird. I said that too. But then, if people want to spend time on this, I don't see the harm. -- The best index to a person's character is a) how he treats people who can't do him any good and b) how he treats people who can't fight back. -- Abigail Van Buren
Re: [RFC] Text-Balanced 1.96 proposed interface changes: return failure in list context
[EMAIL PROTECTED] (Khemir Nadim) writes: Vagn Johansen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] How do you avoid breaking old programs when the interface changes? You don't. IMHO it's the users responsibility to check for what version they are using not the module author. It is, however, polite for the module author to inform the user that there's been a change. Imagine I change the interface of module X. You have some code which uses program X and it works fine. Now you write some completely different code that depends on module Z, so you use CPANPLUS or whatever to install module Z. Module Z depends on module Y, so CPANPLUS installs that too, and module Y depends on a new version of module X, so CPANPLUS installs that one as well. Boom, action at a distance. As a result of using a completely unrelated module, you've just broken a load of old code. This is why I tend to do something like this in Makefile.PL: print WARNING: This new major release is incompatible with previous\n; print releases. Please check any code which uses this module.\n; print Press enter to continue.\n; ; -- I think of AI as the study of programming situations where either don't know what you want, or don't know how to get it. - Sean Burke
Re: OK, so we've decided that the right modules are too hard to find.
[EMAIL PROTECTED] (Khemir Nadim) writes: Everything that was said in this thread was very interresting and I, too, belive things should get better and I encourage those that want to do things _now_. None of these ideas are new. - Any one can start whatever hierarchy This is not a problem, now we have search.cpan.org. - Anyone can load whatever piece of code to CPAN, good or bad I don't agree that this is a problem. - Documentation level is a catastrophy, check how many readme are those generated by h2xs But the generation was added to h2xs because people weren't putting in READMEs, and so an autogenerated one is better than nothing! - The document about how to use CPAN is not clear enough or I haven't found the right one yet You haven't found the right one yet. - 25 versions of the same module do no make it easy to look around in CPAN This is not a problem now we have search.cpan.org. - Authors don't answer or have given up on maintaining there modules THEY ARE VOLUNTEERS. - The same day, the same module can be uploaded to CPAN multiple times Yes, module authors can fix bugs quickly. How terrible! Far from me the idea to refuse uploading of modules to CPAN but 3 years from now, we'll have a useless module heap. If there is a need for curators, I believe it does, then those should be given a mandat and power to apply it or it will be useless. *We have been through this*. Innumerable times. Still nothing happened. The people most likely to act as curators got together (as they do periodically) and decided that better metadata would be the best short-term goal. I'll try and get some of them to write up the latest set of proposals. -- The best index to a person's character is a) how he treats people who can't do him any good and b) how he treats people who can't fight back. -- Abigail Van Buren
Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
[EMAIL PROTECTED] (Michel Rodriguez) writes: I guess it becomes a social (for lack of a better term) instead of a technical issue: this is what we should link to when we want to reference a module. This is in fact the policy I've been using for perl.com for a while now. -- A word to the wise: a credentials dicksize war is usually a bad idea on the net. (David Parsons in c.o.l.development.system, about coding in C.)
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: 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)
[EMAIL PROTECTED] (Smylers) writes: Let's get some good material written first, then worry about where to stick it ... Oh, I know a little Perl-related web site that would love any module comparison articles you were to come up with. -- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
Re: Finding the module you want (was: New module Mail::SendEasy)
[EMAIL PROTECTED] (Dave Rolsky) writes: On Tue, 10 Feb 2004, A. Pagaltzis wrote: * It's better to have comparative articles than module centric reviews; they're also less susceptible to manipulation. I think these are great. The problem is they're a lot of work. I've written two (POOP and date/time) and I know Perrin wrote one for templating systems. Hrm, there isn't an easy way to say this, but an issue with module reviews is that they're generally written by someone with a particular bias towards their own solution. (I say that as someone who wrote one too ;) That's not necessarily a problem if they're presented as a I took a look at the options and this is why I'm doing it my way, but is not all it could be if it is presented as an unbiased review. -- Life would be so much easier if we could just look at the source code. -- Dave Olson
Re: New module Mail::SendEasy
[EMAIL PROTECTED] (Smylers) writes: Personally I found Simon's commentary on some mail-sending modules to be very useful (and I didn't object to his choice of words: when he found something he didn't like he merely said so -- he didn't insult the code's author or make allegations about members of the author's familiar or anything). To be honest, I understand that people get very attached to their work, and in a sense, if you attack their modules, you're attacking them. I'm sure I'd get upset if someone wrote long scathing criticisms of something I'd spent many years working on, even if they did start writing a better alternative; such a criticism can easily be seen to be personal, rather than objective. Even if it's done with benchmarks. -- It is easier to fight for principles than to live up to them. -- Alfred Adler
Re: Need advice for new module for Fast CGI, for enverioments without mod_perl.
[EMAIL PROTECTED] (Graciliano M. P.) writes: The concept is very simple, just need to find a way to make all of this in a portable way. Soo, what name I can give for this? I just have no idea. - CGI::FastBridge? I'd call it pperl, for Persistent Perl. Oh, wait. http://search.cpan.org/dist/PPerl/PPerl.pm -- buf[hdr[0]] = 0;/* unbelievably lazy ken (twit) */ - Andrew Hume
Re: New module Mail::SendEasy
[EMAIL PROTECTED] (Yves Orton) writes: Well suggest a name. It seems like folks concur that the name is not so great so ill alias it to something else. Mail::Send::MIME? -- People in a Position to Know, Inc.
Re: New module Mail::SendEasy
Dave Rolsky: I think your article sort of misses the point. ... No, I think you miss my point. The slowness and amount of code are not nearly as important as the fact that the API is inelegant. However, the code is slow and bulky. But keep most of the internals, because he's dealt with a _lot_ of the niggling corners of mail handling, and there's no need to reinvent that wheel. There is a need to reinvent it. The wheel is square. The code is slow and bulky, and it is extremely buggy. I spent literally hours of my life last year working around bugs in Mail::Box. The fact that the API is horrible is a function of the fact that it's turned out be a leaning tower of OO Pisa, with slow and bulky code. But my point is not to rag on about Mail::Box, or any other mail handling module. It's to write smaller, cleaner, single purpose ones. Hey, Email::MIME came out the other day. Comments welcome. -- Um. There is no David conspiracy. Definitely not. No Kate conspiracy either. No. No, there is definitely not any sort of David conspiracy, and we are definitely *not* in league with the Kate conspiracy. Who doesn't exist. And nor does the David conspiracy. No. No conspiracies here. - Thorfinn, ASR
Re: Re3: Re: How about class Foo {...} definition for Perl?
[EMAIL PROTECTED] (Graciliano M. P.) writes: Well, this is why I made Class::HPLOO not dependent of HPL source. Then it should not be called HPL. It's nothing to do with it. Please call modules after what they do, rather than random unrelated projects that initiated them. I'm about to release a generic framework for web applications that I wrote to help me keep track of beer tasting notes, but I plan to call it Apache::MVC instead of BeerDB::MVC. :) I think that you should send some e-mail to [EMAIL PROTECTED] They are alwasy listening and working on Perl. ?! No. smokers is for discussing automated testing of Perl. -- It's difficult to see the picture when you are inside the frame.
Re: Re3: Re: How about class Foo {...} definition for Perl?
[EMAIL PROTECTED] (Terrence Brannon) writes: I'm sorry, but I must take the bait: is the framework Apache-dependant? At the moment, yes. It's also tied to Class::DBI. And Template Toolkit. At the moment. Once it's written and it works, I'll then abstract it. Does it not belong to the CGI::* namespace? I don't think it belongs in any namespace once it's finally abstracted, since it's sufficiently high level that it's more of an application than a module. (cf. AxKit, Struts, etc.) Then I get the fun of trying to think up a cutesy name! -- I don't understand how people can think SCSI is anything more quirky than a genius with peculiar dietary requirements in a world where the creators of Notes, and their new owners, are allowed to walk the streets without fearing for their very lives. - Graham Reed, asr
Re: would you$please shut the door?
[EMAIL PROTECTED] (Sam Vilain) writes: Acme::please is for randomly inserting please into your output via a tied scalar. The string and printing percentage are both configurable (see the documentation.) Surely this should be in Lang::Courtesy::Random::En? It certainly shouldn't in Acme, since this code would be really useful for INTERCAL code generation. -- DISCLAIMER: Use of this advanced computing technology does not imply an endorsement of Western industrial civilization.
Lingua::EN::Inflect extension name
I've just written an interesting extension to Lingua::EN::Inflect, but I can't think of a good name for it. It provides three extra functions, number, to_PL and to_S. These inflect a noun to its plural or to its singular form. Lingua::EN::Inflect, perhaps surprisingly, doesn't do this, and in fact does interesting things if you try to PL() something that's already plural. So, instead, we have this: print number(goat); # s - there's only one goat print number(goats); # p - there's several goats print number(sheep); # ambig - there could be one or many sheep print to_S(goats); # goat print to_PL(goats); # goats - it already is print to_S(goat);# goat - it already is print to_S(sheep); # sheep The best name I've heard so far is Lingua::EN::Inflect::Convert. Any better suggestions? I wanted to call it Normalize but that's horrible. Incidentally, this uses a very interesting trick to provide inheritance-like capabilities for importing subroutines from non-OO modules. But I'll write about that in another thread lest this one get diverted from finding me a good name. ;) -- IT support will, from 1 October 2000, be provided by college and departmental card locks. - J-P Stacey
Re: RFC: Date::Iterator
[EMAIL PROTECTED] (Marco Marongiu) writes:
my $i = Date::Iterator-new( from = [2003,10,3], to = [2003,11,10] ) ;
while (my $day = $i-next) { ... }
Marco, in case you're getting discouraged, I think there's certainly
a place for Date::Iterator; I like it a lot, and I *really* like modules
in the modular tradition that do one thing and one thing well, rather
than modules in the library tradition that do everything to a reasonable
degree.
I haven't looked at the code yet, but I'd still quite like to see it on
CPAN.
--
Wouldn't you love to fill out that report? Company asset #423423
was lost while fighting the forces of evil.
-- Chris Adams in the scary.devil.monastery
Re: RFC: Date::Iterator
[EMAIL PROTECTED] (Dave Rolsky) writes: No, but it's not easier, and it's _much_ less flexible. The difference between you and I is that you see that as a bad thing and I see it as a good thing. It's a philosophical difference when it comes down to it, such as between Windows programming and Unix programming, or more like GNU Unix and BSD Unix. I don't want to make a fuss, but if I did, I'd start talking about the cat(1) Reference Manual. ;) Really, there's room for both kinds of module on CPAN, and there's room for more than one philosophical viewpoint on CPAN too. Didn't someone famous say something about there being more than one way to do it? -- The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: Class::Accessor subclass
Richard Clamp: On Tue, Dec 09, 2003 at 06:32:01PM +, Simon Cozens wrote: So, uh, what would be a good name for it, then? Class::Accessor::Assert? Just ::Assert seems a little wide-ranging for what you have just now. Well, I also want to be asserting that some members exist in the hash that's been passed to new, for instance. -- ``Perl is the successfull attempt to make a braindump directly executable.'' - Lutz Donnerhacke in de.org.ccc
Class::Accessor subclass
I'm about to write a Class::Accessor subclass that allows validity checking
on the accessors it generates. For instance, you will be able to say
__PACKAGE__-mk_accessor(headers = Some::Header::Object);
and then this becomes a runtime error:
Foo-new({ headers = Completely::Different::Class-new() })
Really I want it just to make sure that certain things are defined when
the constructor is called, but additional assertions would be handy too.
So, uh, what would be a good name for it, then? Class::Accessor::Assert?
--
LARTing lusers is supposed to be satisfying. This is just tedious. The
silly shite I'm doing now is like trying to toothpick to death a Black
Knight made of jelly.
- Red Drag Diva
Re: Looking for help with Net::SSH::Perl Net::SFTP
[EMAIL PROTECTED] (Yves Orton) writes: I more meant that being the man with the Net:: Oh, you still believe that namespace ownership actually exists in practice? How quaint. Maybe I shouldn't have uploaded my latest module into Tie::, because that's owned by... -- Remember, any design flaw you're sufficiently snide about becomes a feature - Dan Sugalski
Re: Tie::Array::Sorted
Randy W. Sims: Sounds like a set/multiset/bag structure. I thought it sounded more like a sorted array, but I'm prepared to be persuaded otherwise. (Primarily because I've already released the module to CPAN. ;) http://search.cpan.org/search?query=Setmode=all Which of those were you thinking of? None of them seem to be obviously related. -- `After all, we're not all freaky perverts' - Thorfinn
Re: Tie::Array::Sorted
Randy W. Sims: Hmm, Jarkko has a nice set (err, no not those), but (and no not that either) your module is the only one I see that uses a tied array to implement a set; Sorry, I should have been more explicit. I can't see any connection between keeping something *sorted* specifically and having a set. And, no, I don't plan to add set operations. This is a module for keeping an array sorted. There are plenty of modules which handle sets, but this is not one of them. -- Rule 3: If the character is comprised of a container without another radical, then Rule 3 will not apply.
Re: Submitting a new module? (Linux::ForkControl)
[EMAIL PROTECTED] (Arthur Corliss) writes: 2) I almost thing that a reverse would be better (i.e., ForkControl::Linux, Alternatively, there are Unix and Proc top level namespaces already. -- The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: Tie::Array::Sorted
[EMAIL PROTECTED] (Struan Donald) writes: However, if I am looking for a module that makes it easy for me to have a sorted array I am not going to look at modules with Set in the name. The module's already uploaded, guys; the thread is dead. -- There seems no plan because it is all plan. -- C.S. Lewis
Re: name for a module that implements dynamic inheritance?
[EMAIL PROTECTED] (Dave Rolsky) writes: There's a lot of trickery that would need to be involved here, as you can't simply alter @ISA for the specified classes, and I'm not entirely sure how I'll implement it, but that's a separate problem. Sex.pm does this sort of thing, in case you haven't seen it yet. -- Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers
