Re: When CPAN shell cannot find a module
On Mon, 21 Nov 2005, Ken Williams wrote: Think about what would happen if Satan uploaded a malicious distribution called PathTools with a higher version number than mine. You'd want the whole world to get Satan's distribution by default, just so they can save a couple keystrokes? Any ambigious situations such as that could easily be handled by asking the user KWILLIAMS and SATAN both are providing PathTools, which would you like? or having it spit out a list of choices and let the user implicitly pick by then doing the install AUTH/dist...gz at that point. Is there some REAL chance of harm in what we're talking about here that couldn't be trivially ameliorated such as here? My previous suggestion of having an explicit mapping would help avoid getting the wrong person's PathTools. It wouldn't have to track versions in the map since PathTools could map to KWILLIAMS/PathTools and determine the latest from that. And as I pointed out the issue here isn't merely distnames, but common misimpressions. Being able to install Template::Toolkit won't cause the universe to blow-up. Also, lack of distname support is overblowing the situation. Distnames are supported perfectly fine as long as you put it in the proper syntax with author's ID and version. The proper syntax in this case is unnecessarily complex and utterly nonobvious to all but the Perl cognescenti. That seems a pretty harsh way to treat sysadmins stuck with installing Perl-based applications who may have no prior Perl experience whatsoever. If there were some real harm in making it easier it might make sense to me, but maybe somebody can share with me something that's not a red herring that will help me get it. -- /chris My aim is to agitate and disturb people. I'm not selling bread, I'm selling yeast. - Miguel de Unamuno, writer and philosopher (1864-1936)
Re: When CPAN shell cannot find a module
On Sun, 20 Nov 2005, Andreas J. Koenig wrote: I don't think many people would appreciate getting something installed they didn't explicitly ask for. Hmmm. I can have extra pain every time I'm installing something to avoid occassionally getting something I don't want or I can have pain every thousandth time I install something because oopsie I got something extra. It doesn't seem like a hard choice to me. Let's just say your many people aren't the same folks as my any people. ;-) The lack of distname support due to anal retentive accident avoidance in CPAN is utterly odd considering the culture of DWIMery that is so much a part of Perl. I'm not surprised that one person would think this was good, but the whole Perl community acquiescing to it is quite a shock. -- /chris Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. -- Dick Brandon Physics is like sex. Sure, it may give some practical results, but that's not why we do it. -- Richard Feynman, physicist and Nobel laureate
Re: When CPAN shell cannot find a module
On Mon, 21 Nov 2005, Chris Dolan wrote: If CPAN made it easy to install unintended software by mistake, that would be a huge security hole. Some people run cpan as root. Defensive programming is absolutely the right thing here. And how exactly would a shortcut that says oh you asked for something that isn't really a module name, would you like us to install THIS package which contains CERTAIN modules anyway? cause security issues? I run the cpan shell as root all the time. Its a pain to have to remember the CPAN caniptions every time I'm setting up a new random server and the less often you deal with it the more likely you will have forgotten it all. This is exactly the context where the sort of shortcut that Perl is known for should be eximplified but its not. It may be the individual's first exposure to the Perl world. Let's not make it suck because of weak fears. PathTools and Template Toolkit are both examples where the thing to type into CPAN isn't clear to the newbie sysadmins. If we had a list of things like that for the important modules that have such strangeness then there should be any security problem in doing this without prompting since those mappings would be official and Known To Be OK. If I say install TemplateToolkit or install Template::Toolkit having that map to install Template without too much fuss is not only harmless and significantly helpful it might even be a security benefit since I won't accidentally install three other templating things in the meantime hoping to find the right one. The amount of time saved for sysadmins all over the world without causing anyone one iota of actual harm is awe-inspiring. So, am I really missing something here? Is there really some chance for a harmful mistake being made that can't be trivially mitigated with solutions like I mentioned above? -- /chris There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
Re: Name advice: check license of dependencies
On Tue, 1 Nov 2005, Chris Dolan wrote: Thanks for the feedback Mark and Sam. I chose Module::License::Report and posted my implementation to CPAN this afternoon. Bravo and thanks. Further feedback would be VERY welcome, as the module uses a few sketchy heuristics to guess at the license. To mitigate the uncertainty, I made it report a confidence number so the user can set a sketchiness threshold. The confidence is just a guess, but it's better than nothing. I'm thinking the next version should use multiple algorithms to guess the license and report higher confidence if they all agree. That sounds even cooler. Perhaps a flag or a different function names could be used to get results as one license with one confidence value or multiple licenses per component with each having a seperate confidence. Each would have its place. On a side note, I discovered that using Data::Dumper on my output object causes memory use to go through the roof. I think Data::Dumper is chasing into the CPANPLUS data structures and thrashing my machine. Is anyone familiar enough with CPANPLUS internals to know whether Data::Dumper problems are well known, or if I've stumbled on some new bug? Data::Dumper is only good for looking at small chunks of stuff. Its very very very inefficient and there have been cases where Data::Dumper failed to produce something that could be eval'd back in once upon a time and eval'ing the result is inefficient too. Storable for the win here. Storable does everything Data::Dumper does poorly well and oopsy we don't care about presenting it visually. So use Storable for storing. Data::Dumper is just for glancing. -- /chris John Lundin once shaped the electrons thusly: Ah. Okay, on the nice to do list. (Which in practice translates to won't do unless it becomes inconvenient or is fixed upstream.)
Re: Perl6 goes where?
On Thu, 28 Jul 2005, Philippe 'BooK' Bruhat wrote: Le jeudi 28 juillet 2005 à 16:32, A. Pagaltzis écrivait: * Philippe 'BooK' Bruhat [EMAIL PROTECTED] [2005-07-28 16:05]: I thought I heard (or more probably read somewhere) that the name was 6PAN? That makes no sense. What is a ???6 Perl Archive Network Okay, visually, it roughly resembles ???CPAN,??? but I don???t see that as a good reason to pick a nonsensical initialism??? If found a reference to the name 6PAN here (that was in 2002): http://www.mail-archive.com/perl6-stdlib@perl.org/msg00135.html Anyway, isn't nonsensical a prerequisite in the Perl world? Many Perl names started as jokes : Parrot, ponie, CPANTS... You could have a camel with 6 pans hanging off of him as an icon. :) -- /chris There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author)
Re: Introduction Letter
On Mon, 28 Feb 2005, Torsten Schoenfeld wrote: http://lists.netthink.co.uk/listinfo/code-review-ladder That box was having hardware problems last week. The maypole lists were on the box (now they're on SrcFrg), so maybe this has moved somewhere else too. -- /chris There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author)
Re: CPAN cruft cleanup?
On Wed, 23 Feb 2005, Johan Vromans wrote: But from what I hear, I'm on my own -- Not completely. The cpancd[1] package has the functionality in it to find out the latest version of a series of versions. Although the package is obsolete (CPAN won't fit on a CD anymore), this function could be useful. But CPAN might fit on a couple of CD's or a DVD. -- /chris There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author)
Re: Subclassing a mailer
On Sun, 16 Jan 2005, A. Pagaltzis wrote: * Sam Holden [EMAIL PROTECTED] [2005-01-15 17:09]: Only inherit when you have an ISA relationship. I just want to chime in to agree. Inheritance is greatly overrated and widely abused. It is almost always the very last option you should consider. Aggregation is way underrated and should be used much more often. Do you have any evidence of this? I can guess that this may be the result of bulk of OOP education emphasizing inheritence so people presume that its the best way when its merely one choice. Given the complexities of inheritence it does require more educational space than aggregation. But I haven't seen the wide abuse you speak of. In my sphere of influence I have to hammer home the importance of semantics in OOP design and I've had to dissuade a few eager souls from inheriting where there's isn't an ISA, but in reviewing other folk's OOP code I would say that a total lack of design sense or standards is much more rampant than inheriting where it doesn't make sense. Since this is a list closely related to CPAN I'm particularly curious if there are examples where published modules are breaking this rule. -- /chris There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author)
Re: What name for a printer status supplies module?
On Sat, 18 Dec 2004, Terrence Brannon wrote: David Landgren [EMAIL PROTECTED] writes: The fact that it uses http is incidental. If HP bothered to supply a half-decent MIB, SNMP would be a good alternative. What does MIB stand for? Men In Black. ;) Oh, you mean the geek version... MIB stands for Management Information Base and encapsualtes an API within an SNMP context for a given type of device. Various RFC's have described this through various versions of SNMP: http://www.drunkandretired.com/snmp/ has some good links. -- /chris There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author)
RE: DBIx::DBH - Perl extension for simplifying database connectio ns
On Tue, 7 Dec 2004, Henrik Tougaard wrote: Maybe the number of responses on this thread come from people who have this itch to scratch. Huh? I've only been seeing what got cross-posted on this to module-authors until today, but I just subscribed to dbi-usres n I have heard Tim Bunce (DBI, DBD::Oracle etc) and Jonathan Leffler (DBD::Informix) raise 'Beware, thing are much more complex than you think' warnings. Yeah. I (DBD::Ingres) have'nt pitched in as Jonathan voiced my concerns quite precisely, saying: Beware - DBMS are more different than anyone would like. That's why DBI has the scheme it does have - it is flexible but not easily codified. Even if its not easy a solution for migrating DSN creation out of code and into a config file would be very worthwhile. Ingres, like Informix and (I think) Oracle, does'nt have the concept of 'host' or 'port', using other ways of adressing remote databases. Given that for most folks the support is needed for the FOSS databases ignoring the strange proprietary ways would be better than not having DSN's externalized. It seems to me that you are trying to force an extension onto the DBI based on what a small number of RDBMSs accept. When that small number just happens to be all the FOSS databases its a large enough small number. The people who want this seem to use only a few DBDs - perhaps it could be added to those? Maybe. Personally I'd like to see a solution based on AppConfig. We have our database configs in AppConfig. The config files look something like: [global] connpriority=dot,skippy,marita dbd=mysql tablespace=finilever user=blah pass=blah [dot] host=dot.fini.net [skippy] host=skippy.fini.net user=override pass=override [marita] host=marita.fini.net dbd=pg I don't care about Oracle or any of the rest. Making this work with PG and MySQL will solve 90% of the world's problems. I don't see why it couldn't be extended to include whatever parameters where necessary for any of the proprietary databases, but if not could somebody explain how? -- /chris Fans of Mozilla's free, open-source Firefox browser make the ardent Apple faithful look like a bunch of slackers. - Rebecca Lieb at clickz.com
RE: DBIx::DBH - Perl extension for simplifying database connectio ns
On Tue, 7 Dec 2004, Orton, Yves wrote: I was given the Henrik or some other hypothetical respondant the benefit of the doubt. I figured that out by the end of reading your email. :-) :-] I thought it was clear I think that this is both doable and worth doing. Yes yes. I didn't think there was much disagreement. -- /chris Fans of Mozilla's free, open-source Firefox browser make the ardent Apple faithful look like a bunch of slackers. - Rebecca Lieb at clickz.com
Re: Getopt::Helpful - online help and options
On Fri, 12 Nov 2004, khemir nadim wrote: Hi, I haven't tested your code (will do this week-end) and I think it's a good idea. Ya ya. We've been talking about extending AppConfig to do something similar for a while, but no progress yet. -- /chris The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. -Bertrand Russell, philosopher, mathematician, author, Nobel laureate (1872-1970)
Re: CPAN question
On Wed, 10 Nov 2004, Sean Quinlan wrote: How do we mark uploads as a dev release? Can it be done after it's uploaded or is it something in the release before upload that indicates it (I browsed YAML .49_01 and didn't see anything)? The underscore in the filename is the flag. (Its right there man! :) ) -- /chris The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. -Bertrand Russell, philosopher, mathematician, author, Nobel laureate (1872-1970)
Re: MySQL::Backup?
On Tue, 26 Oct 2004, Smylers wrote: 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? So that database-related things are kept together. 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. We have that for Oracle and Sybase, but does that make it easier on people trying to find related things? If something is database related and based on DBI I'd like to see it in DBIx. If its something that is database related and its based on some other interface it should be in Database:: or SQL:: In particular, there are already many in the MySQL:: namespace: http://search.cpan.org/search?m=moduleq=MySQLs=1n=20 Precedent means a lot more in a court of law than it should elsewhere. 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)? I don't think we can persuade all of the existing ones to move, but if we had a general agreement that database related modules should be in a handful of namespaces it would seem to be advantageous. I'd love to see see Alzabo. MySQL::Backup, and the other DBI-based modules with strange names paces all go in DBIx while the other things (oraperl, postgres, etc.) go into Database::. We have Spreadsheet:: to take care of spreadsheets. 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! How is doing a database backup any less of a DBI extension than DBIx::Copy or DBIx::HTMLView? -- /chris There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
Re: MySQL::Backup?
On Tue, 26 Oct 2004, _brian_d_foy wrote: In article [EMAIL PROTECTED], Smylers [EMAIL PROTECTED] wrote: I think the opposite -- that DBIx:: should be for things that are generally usable with DBI, where the I is independent. Things such as backing up tend not to be database-independent. if we work it right, DBIx::Backup could be independent, while DBIx::Backup::MySQL implements the MySQL bits. :) Exactly. If DBIx::Backup::MySQL has a clean interface it might even inspire a generic DBIx::Backup and become the MySQL implementation of DBIx::Backup and spark a revolution in database administration. :) -- /chris There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
Re: [rfc] File::Corruption
On Mon, 18 Oct 2004, Lincoln A. Baxter wrote: Ok, how about File::SATA::Integrity His motivation was SATA, but the resulting solution isn't SATA specific. -- /chris Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. -- Dick Brandon
Re: [rfc] File::Corruption
On Sun, 17 Oct 2004, Joshua Hoblitt wrote: is the namespace appropriate? I'd rather see it called something like File::DetectCorruption or something that makes it clear that your module isn't here to corrupt files. Otherwise: You've provided good documenation. That's wonderful and above average for a first release. I've had good luck with SATA, but I don't use RAID controllers since I'd rather put the money into more drives and let Linux do the RAID. My desktop box is an Opteron/SATA/Linux/LVM box with Linux doing RAID1 across two drives and its absolutely fabulous. :) -- /chris Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. -- Dick Brandon
Re: Let's eliminate the Module List
On Tue, 24 Aug 2004, Simon Cozens wrote: 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. Browsing and searching each have their place. It is conceivable that a powerful enough search could emulate browsing. Consider how much discussion has been generated by talk of removing a browse-oriented document like the module list. Some people and activities are more fond of browsing than searching. It may only be 10% of the cases where browsing works better than searching, but if I want to answer the question - what are all of the perl web applications it would take lots of searches and result munging to find out what a painless browse could produce. A hierarchical system that people can add into META.yml supplemented by an effort to fill in the gaps left by maintainers not motivated to fix their META.yml would be a wonderful thing. -- /chris There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
Re: Let's eliminate the Module List
On Tue, 24 Aug 2004, Simon Cozens wrote: Repeat after me: browsing is just searching metadata. For our current purposes I'm willing to go along with that. Once the metadata exists people can do whatever they want with it. I strongly suspect that one of those things will be making something that is vaguely yahooish. This brings to mind an interesting question - shouldn't there be some central file of meta data that's automatically generated? Maybe in Storable and XML? That way people that want to experiment don't have to have a full CPAN mirror or dig data out of all of the tar files. -- /chris There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
Re: Let's eliminate the Module List
On Wed, 18 Aug 2004, Randy W. Sims wrote: I made a suggestion regarding this before that I thought provided a fair solution http://www.nntp.perl.org/group/perl.module-authors/2615, but no one commented. Basically, upon submission of a new module, a notice would be auto-posted to some list. If no one replies to that posting within some time frame, the module is automatically accepted. If anyone does reply, then it requires moderator approval. The moderator(s) isn't required to do anything other than monitor the discussion and act according to the concesus reached in the discussion. The list members do what is currently done on a voluntary basis on module-authors; that is, they make name suggestions, discuss prior art, etc. That sounds good to me! Are you volunteering to implement it too? :) -- /chris There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
Re: module name for Wily (a text editor) interface client?
On Tue, 3 Aug 2004, Sam Holden wrote: I would argue that Wily is just as much a way of life as Emacs and Vi. No doubt. However, it certainly isn't anywhere near as popular - chances are you've never heard of it... I heard of it when I went to see what the heck a module called Wily was all about actually. I did this only a few days ago, but before this thread started. It doesn't warrant a toplevel namespace all to itself - though of course my current code uses one :) You're hardly the only CPANer guilty of this. There are two Wily modules in existance at the moment (that I know of), but they do the same thing - one uses XS to link with the wily libs, whereas mine uses pack/unpack to decode the messages itself. But yes, there's much less scope for multiple modules (due to the fact that the intersection of wily users and perl programmers is small...) How about TextEditor::WilyPP. Is PP recognized as pure perl widely enough? If the XS-based module owner could be convinced to switch to TextEditor::Wily you'd really be starting a trend. -- /chris
Re: module name for Wily (a text editor) interface client?
On Mon, 2 Aug 2004, Sam Holden wrote: Namespace wise, Text::Wily was suggested on comp.lang.perl.modules, but the module itself has almost nothing to do with text - it interfaces to a text editor which I think is a very different thing. 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::. Text:: may seem inappropriate in one sense, but in any classification system you're going to have things that almost fit one place, but don't fit anywhere else at all. Going with the almost fit is often the right choice rather than trying to create perfect categories for everything. The worst case for not going with almost fit is that you end up with /n/ objects in /n/ categories eventually and there's no point in the categories anymore. Speaking of categories, why do we have a Commercial Software Interfaces, but not a Noncommercial Software Interfaces? Is that intentional? -- /chris
Re: Ratings and Reviews ne Modules
On Sun, 1 Aug 2004, Eric Wilhelm wrote: If ratings are used to compare modules (as opposed to judging each according to its merrits), some modules might be overlooked, especially new modules. True, and the popularity metric that I was proposing would probably only worsen the situation. One of the good ideas in this thread to me was the application of them to search. I agree that new unreviewed modules might be hurt by this, but if the search order let both the review rating and the recentness influence its order people would tend to be directed to the right place sooner. Seems that a popularity metric and ratings would just help highlight this module. As much as helping you highlight the right module it would hopefully let you steer clear of the poorly documented unmaintained module as well. -- /chris
Re: module name for Wily (a text editor) interface client?
On Mon, 2 Aug 2004, Smylers wrote: 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. Plus I can see that there's more of a chance for multiple Emacs and Vi related modules than Wily-related ones. 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. Agreed. There are some 'Excel'-related modules in the Spreadsheet:: namespace. I think creating an Editor:: namespace for 'Wily' would be reasonable. I'd rather see TextEdit:: or TextEditor:: than the somewhat ambiguous Editor::, but I'd be happy to see a new name space for these sorts of things. -- /chris
Re: Renaming module - Algorithm::SkipList
On Sat, 31 Jul 2004, Eric Wilhelm wrote: Data:: does not seem to be the right place -- it seems to be about data formats more than data structures. What about Data::Dumper Data::Iter Data::Match Data::Grouper ? IMO, the stuff about formats is in the wrong place s/Data::(Encrypted)/Text::$1/ And, maybe we should also s/Data::(Iter)/List::$1/. Data:: seems like a good place for data structure things that aren't inherently lists, hashes, other standard CS things, or that cover several of those. Really, IMHO the tree modules and yours and probably others more should be in some sort of Datastructure:: namespace. Whoa! That is way too long. So, what if List::SkipList becomes Data::SkipList or even Data::List::SkipList? That'd be foolish. The common data types are used so often and widely they deserve their own top level names like List:: and Tree::. Well, I might want to create a tied implementation of it. Would that be named Tie::List::Skiplist, or Tie::Data::List::SkipList ? Seems that if we buy the first one, that List:: should be a toplevel namespace. Ya. The genius of you Americans is that you never make clear-cut stupid moves, only complicated stupid moves which make us wonder at the possibility that there may be something to them which we are missing. --Gamal Abdel Nasser That's great. -- /chris
Re: Ratings and Reviews ne Modules
On Thu, 22 Jul 2004, Eric Wilhelm wrote: Okay, but we have requirements for both search.cpan.org and cpanratings.perl.org, right? Yes. cpanratings could display more in depth statistics of the various modules and also allow for being to view a module as a whole and not just one particular verson of a module. search.cpan.org is the front-end to most module-searching, and I think it should stay that way, but should have more visible (read: not so deep) links to ratings/reviews and show the star-bar in more places. For instance it would be nice to be able to sort search results by ratings. Or it'd be nice if that were factored in somehow when doing search. Maybe this would iron out the greatest module since sliced bread that people who don't know the secret handshake have never heard about problem. If these sites have separate maintainers, we should be working on two requirements lists. Some requirements would seem to be related. For instance, cpanrating may need to provide a convenient way to get data that would the be utilized on search.cpan.org to make the impact less painful. Maybe some sort of local ratings cache would need to be maintained? -- /chris
Re: Ratings and Reviews ne Modules
On Fri, 23 Jul 2004, Gabor Szabo wrote: Do we really need reviews ? Short of some better sort of solution for helping guide people to the better choices of modules. I am afraid not many people will take the time to do a deep analyzis of a module. It doesn't take many people to provide a statistically large enough sample to be useful in helping perl newbies avoid the modules that somebody cooked up five years ago and hasn't updated since. What about a web based discussion board that is module specific ? Easy to search, categorized by modules, easy to post - no need to subscribe to a zillion mailing lists. That'd be useful. A lot of modules might form little communities to save them from author neglect if they could find each other. So many modules have no mailing list and the author never responds. Now I don't blame the author for not responding, but without some central place for people to congregate and trade patches thing die on the vine that wouldn't have to. -- /chris
Re: getting rid of some unmaintained modules
On Fri, 7 May 2004, Mark Stosberg wrote: I believe even if you delete them all from your directory, everything ever uploaded is still available on 'backpan': It may still be available, but it's still much less likely that a random Perl programmer will dig something out of backpan as compared to finding it on every CPAN site in the world. We can't prohibit people from shooting themselves in the foot, but we may be able to avoid dealing with a few less shot off feet. -- /chris No, no, you're not thinking, you're just being logical. -Niels Bohr, physicist (1885-1962)
Re: [Module::Build] Re: How to indicate a dependency in my module
On Wed, 12 Nov 2003, Sam Vilain wrote: On Tue, 11 Nov 2003 02:29, Michael G Schwern wrote; YAML was chosen because its human readable and writable, its data ^ ^ So long as you're a FREAK who likes INDENTING and WHITESPACE to signify STRUCTURE. Is it any surprise that YAML is supported by PYTHON?! /topicalButTechnicallyVoidRantIgnoringTheObviousReplyForComicalValue Considering the number of ugly languages that have been spawned from or inspired by Perl, YAML may turn out to be one of the most respectable in the long run. At least it's not procedural like the other ugly children - PHP and Python. -- /chris X Windows is to memory as Ronald Reagan was to money. -- Unix-Haters Handbook
[OT] chicksoprocity (was Re: module to access w3c validator)
On Wed, 29 Oct 2003, Jim Cromie wrote: OT - Chris, does your email address get you black-holed a lot ? Not really. It does raise eyebrows though. One client had a female staffer that felt sexually harassed by needing to use that e-mail address for tech support questions. [sigh.] But that inspired me to finally put a site up at my domain again to lampoon all those who just haven't gotten it. http://www.chicks.net/ with the amount of porn-spam these days, and not-quite-there filter-tools (mozilla anyway) Ive had to de-junk legit email periodically. Since this is a Perl mailing list, a plug for MailScanner ( http://www.mailscanner.info/ ) seems in order. It's helped us eliminate e-mail viruses and does wonderful spam tagging with the integration of RBL's, SpamAssassin, virus scanners, and it's own rule sets to manage it all. Very good stuff. -- /chris No, no, you're not thinking, you're just being logical. -Niels Bohr, physicist (1885-1962)
RE: module to access w3c validator
On Wed, 29 Oct 2003, [EMAIL PROTECTED] wrote: If you can get the source then why would you want to do anything using SOAP? Even if I can get the source that doesn't mean it's easy to install. If the source has a free enough license you could turn it into a module and that's that, if not then just run it locally as a command and capture the output. Either of these would be much more reliable than remotely calling the w3c's scripts, you wouldn't need to be connected to use it and you won't be pounding on the w3c's servers, All of this presumes that the effort required to install the validator locally is near zero. I just went out to look and it honestly doesn't look too hard to make work, but neither did their css validator which I gave up on getting installed locally because of fighting with all of the Java garbage. YMMV. Even if the HTML validator is easy to get going that doesn't mean that it still isn't often easier to not install it. Honestly I could see using this module when working on things at remote sites. It'd certainly be easier to get the original poster's module installed than trying to figure out whether OpenSP compiles on HP-UX or wait a month for my client to approve adding software to their production linux system. When working with a few TLA US goverment agencies the mean time from begging to getting actual software installed is about ten months. To whomever chose to lampoon the original proposal by your make it a SOAP service message, shame on you. I understand where you're coming from, but on an international mailing list where a lot of people aren't native or fluent English speakers, the humor gets lost in the translation. Beyond that, what ever happened to the spirit of TIMTOWTDI? What happened to correct Perl is any Perl that gets the job done before you get fired? People coming to this mailing list with earnest questions deserve honest answers, not harassment. -- /chris The first rule of Perl club is you do not talk about Perl club. -- Chip Salzenberg
RE: module to access w3c validator
On Wed, 29 Oct 2003, [EMAIL PROTECTED] wrote: Fair points except in this case you wouldn't be doing your clients any favours by making their production servers depend on a webservice that has no specified interface and no promises about availability. The whole point of my scenario was that I might need this thing real quick to fix a problem I'm seeing. How many people need long-term reliable access to an HTML validator? Those that need that sort of thing installed it all long ago, right? Otherwise, it's just some Perl guy trying to make a buck and trying to debug something on some unfamiliar system. -- /chris No, no, you're not thinking, you're just being logical. -Niels Bohr, physicist (1885-1962)
Re: what to do with dead camels ?
Sorry for beating the dead horse a little more, but here goes... On Tue, 5 Aug 2003, Nicholas Clark wrote: On Tue, Aug 05, 2003 at 01:27:47AM -0400, Christopher Hicks wrote: Maybe the e-mail should do something informative like list how many years, months and days it's been since a given module has been updated. Some weak souls might be guilted into pushing out bug fixes sooner. If there are no bugs, there is no need for bug fixes. Agreed. MJD gets very irritated with people asking whether certain of his modules are abandoned, simply because the most recent version is old. If all module writers wrote like MJD there'd be no need for this disussion or this list. :) Why are you assuming that all stable code has known but unfixed bugs? I'm not. But I've dealt with a variety of different CPAN modules that were avaiable as updated from the authors site that took ages (as in a few years IIRC) to make it to CPAN. How many months of watching this sort of thing go on is considered acceptable before taking the module and uploading it myself? If anything, have rt.perl.org send out ping messages about new (but unresponded to) bugs, or maybe open but serious bugs, because these do have content That's be nice to include and maybe the message could be sent more often to those with unassigned bugs in their modules. But *do not* send out an all's well message, which will get filtered with the spam to /dev/null, because crying wolf like this will cause people to miss subsequent real, serious, messages. Sheesh. It's not crying wolf. It's saying here's the status of your stuff. When you get a monthly statement from your bank they're not crying wolf. They're keeping you up to date. My accountant is hopefully more on top of things than the bank so the only purpose in the statement is to make sure the bank hasn't screwed up, but I don't accuse them of crying wolf because they want to keep me appraised of things. If people are this morally opposed to receiving an e-mail every few months maybe the implementor of this idea should let folks bury their head in the sand and stay happy. And presumably this would come from some fixed address used for solely this purpose, so who's really going to miss e-mail over this? -- /chris The death of democracy is not likely to be an assassination from ambush. It will be a slow extinction from apathy, indifference, and undernourishment. -Robert Maynard Hutchins, educator (1899-1977)
Re: What search.cpan.org PAUSE produce (Fork from: what to do with dead camels?)
On Mon, 4 Aug 2003, James E Keenan wrote: May I begin a separate thread for a line of discussion coming up under the dead camels? Sure. I'm going to present empirical observations only; it would be premature to make suggestions for changes until we heard from more contributors. It's never stopped us before. :) Bru-hahahaha. Searching via All: 1st distro appearing is Test::More as part of Palm-Progect-2.0.1 by Michael Graham. Schwern's Test::More appears 4th on list. (A) Do we have any idea what tha algorithm it's using is? (B) Could we make an exception/improvement to the algorithm which makes the real module come up first? Searching via Modules: 1st distro appearing is Test::More as part of CPAN-1.76 by Andreas J Konig. Schwern's Test::More does not come up at all among 471 entries found. Searching via Distributions: Test::More does not come up at all (C) Couldn't we have a seperate box that comes up on the side of the search results that shows the version/date of the last three releases of a given module X if the search string put in is reasonably obviously referring to a specific module. So it might look something like this when searching for Foo::Bar, Foo-Bar, or foo bar: 1) Irrelevant ResultModule Foo::Bar 2) Useless Result v0.1 4-1-1870 3) Misleading Result v0.2 4-1-1970 4) Ancient Result v0.3 4-1-2003 5) Irrelevant Result 6) Irrelevant Result 7) Useful Result too low to see 8) Distracting Result Issue 2: Which links PAUSE builds when an author uploads a module whose POD contains links? I'd love to know the answer to this too. Do others observe similar phenomena? Is it problematic for you? Ironically, search.cpan.org is phenomenal for browsing perl module docs, but it's really strange and bewildering when it comes to searching them. -- /chris The death of democracy is not likely to be an assassination from ambush. It will be a slow extinction from apathy, indifference, and undernourishment. -Robert Maynard Hutchins, educator (1899-1977)
Re: what to do with dead camels ?
On Mon, 4 Aug 2003, Johan Vromans wrote: Maybe a periodic 'ping' to module maintainers (e.g., once every two or three months) and mark maintainers (and their modules) that miss a couple of pings. Modules marked as such could be returned last by the search engines, and be clearly marked as being of 'undetermined' status. That'd be awesome. -- /chris The death of democracy is not likely to be an assassination from ambush. It will be a slow extinction from apathy, indifference, and undernourishment. -Robert Maynard Hutchins, educator (1899-1977)
Re: Binary File Modules
On Thu, 19 Jun 2003, Fergal Daly wrote: At the moment your only module is the PE module and that deals with a binary format but that's not to say that future modules won't deal with ascii formats too. Well ok, you said you'd be focussing on binary formats but some ASCII formats are none too simple and could probably use an Info modules. Maybe the framework and the PE module should be seperately named? -- /chris The death of democracy is not likely to be an assassination from ambush. It will be a slow extinction from apathy, indifference, and undernourishment. -Robert Maynard Hutchins, educator (1899-1977)
Re: UDPM name space finalization
On 3 Jun 2003, Kevin C. Krinke wrote: ...and the beat goes on... Would somebody give Kevin a cookie for his concerted effort to get this audiences' difficult approval? His persistance is admirable IMHO. -- /chris Programming is a Dark Art, and it will always be. The programmer is fighting against the two most destructive forces in the universe: entropy and human stupidity. They're not things you can always overcome with a methodology or on a schedule. -Damian Conway, Perl God
Re: rfc: a generic solution for dual-life CPAN packages
On Thu, 27 Mar 2003, Stas Bekman wrote: Please, can we stay focused in this thread on the generic problem that I'm trying to solve? I think this problem relates to the CPAN.pm bug we've seen reoocur several times where it tries to upgrade perl. This is one of the biggest complaints I've heard from sysadmins trying to use perl apps in the last few years. It seems like there should be some way to define certain modules as core - meaning don't install unless you're really sure. These core things are dangerous to install mindlessly and shouldn't be considered for installation by automatic tools. Can a flag be added via PAUSE or something else? -- /chris The death of democracy is not likely to be an assassination from ambush. It will be a slow extinction from apathy, indifference, and undernourishment. -Robert Maynard Hutchins, educator (1899-1977)
RE: New module; Exec-RSE?
On Wed, 27 Nov 2002, Hugh S. Myers wrote: Clever of you to miss the point entirely. That being to put it in the GetOpt namespace---the rest is up to the author... Clever of you to miss that I did get your point entirely. :) I agreed with you which is why I made my example in the GetOpt space. I read an article recently talking about not using strange acronyms in module names and that's why I commented. I responded to your e-mail since I was trying to build on what you had correctly pointed out! Sorry for not making that clearer. RSE just makes me think of some strange IBM acronym. VERA gives us Removable Storage Elements and Research and Systems Engineering as previous uses for RSE. Who could guess the difference between GetOpt::RSE and GetOpt::JCL? -- /chris Programming is a Dark Art, and it will always be. The programmer is fighting against the two most destructive forces in the universe: entropy and human stupidity. They're not things you can always overcome with a methodology or on a schedule. -Damian Conway, Perl God
Re: MakeMaker autoconversion of module linefeeds?
On Fri, 15 Nov 2002, Michael G Schwern wrote: On Fri, Nov 15, 2002 at 04:19:38PM -0800, Gurusamy Sarathy wrote: I'm not sure what it is we're trying to solve here--has there been a specific complaint we're trying to address? If nothing is broken, don't fix it etc. Yes, yours. :) http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-04/msg02168.html http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-04/msg02144.html [applause.] Its an old one. I happened to dig it up while researching what TO_UNIX is for in MakeMaker. The problem has largely been solved exactly as you suggested back that, Perl's newline handling has been made smarter. Just wondering if anyone is still having problems with this. If not, I'll leave it be. I might even tear out OS/2's special case. The only instance where I've personally seen trouble with Perl and different line-endings is in scripts. If a script's #! line ends with a CRLF many (maybe all?) UNIX's will give you command not found garbage. Despite the irritation that has caused me through the years, it doesn't seems worth leaving magical kruft buried in MakeMaker to fix it. -- /chris Camels may be nasty beasts, but they're the only way to get through the desert. -me
Re: RFC Text::UberText
On Tue, 15 Oct 2002, Terrence Brannon wrote: 1. developing a good language is very difficult. 2. why do we need a template *language*. What is it about templating that requires a new *language*? Templating entails a few simple operations that can be handled in any general purpose language - LISP, Perl, Python, C, C++. Terrence I love speaking to a brick wall Brannon I'm one of those lost souls that developed my own templating system only to find that it was more trouble to keep it working than not. I've been a Template Toolkit (TT2) user for two years now and I'm actually working on real stuff instead of dorking around with making the 'perfect templating system'. I've developed rather complex pages using TT2 to the point that some of them I've reverted back to generating internally in Perl since too much logic was involved. But beyond that fact that TT2 has allowed me to create some misplaced complexity it has held up extremely well. It's nicely documented and looking inside the code hasn't been too daunting. I've had no trouble adding directives that were highly relevant to my application which has made the pages that actually get edited as simple as I can imagine them being. Anyone want to start a mailing list for templating system authors anonymous? My name is Chris and I wrote my own templating system. [sniffle.] ;-) -- /chris The truth is rarely pure, and never simple. -Oscar Wilde, writer (1854-1900)
Re: howto mirror subset of CPAN?
On Mon, 10 Jun 2002, Scott R. Godin wrote: I too had a hard time believing how some of the internal versioning is done. crazy regex and substr reductions of long version strings instead of a simple package::VERSION = nn.nn.nn; *bemused headscratching* I'm sure a good percentage of that is done so that people can use the version number from cvs or (insert your favorite SCM here). -- /chris There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. - - C.A.R. Hoare
