Take back your modules! (was: Re: Give up your modules!)
Ovid wrote: Hi all, No names, but if you happen to be sitting on a module which other people depend on and you're not going to fix bugs, give up the module, offer someone co-maintainership or figure out *something* which gives users a way out. I realize that not everyone has a pile of free time to constantly upgrade and maintain modules, but if it's something widely used and you don't have time for it, isn't the responsible thing to find a way to get those bug fixes out there? I just want to point out that giving maintainership involves two consenting parties, and this a author-centric approach. The user-centric approach works too. Leave patches in RT. Follow-up on the other bug reports until you reach resolution. Leave a note in RT that says I recommend this issue be resolved because... Go ahead and prepare a next proposed release with tests/docs/code and ChangeLog updates and tell the author they can simply sign-off on it. I now help maintain Data::FormValidator, CGI::Session, CGI::Application, and WWW::Mechanize, none of which I wrote. In all cases, the existing maintainers have been appreciative of my pro-active approach. From my perspective, there aren't enough users acting like the software is theirs. Considering the licenses on CPAN, they have equal right to work on it. I'm not sure what the hang-ups are for getting users to be more active, though. I say: If you are care about a module's maintenance, start acting like you own it, being considering that others, especially the current maintainer, may feel the same way. Mark
Re: Take back your modules! (posted to Perlmonks)
David Landgren wrote: Andy Lester wrote: On Sep 7, 2006, at 9:08 AM, Mark Stosberg wrote: I say: If you are care about a module's maintenance, start acting like you own it, being considering that others, especially the current maintainer, may feel the same way. Nice. Worthy of a use.perl.org post so others can see it. Maybe perlmonks too. Done. Here's the link in case anyone wants to follow the comments there: http://www.perlmonks.org/?node_id=571832 Mark -- http://mark.stosberg.com/
Re: I think we can just scrap CPAN Ratings altogether
On Fri, May 26, 2006 at 12:32:48PM -0500, Ken Williams wrote: I think the real value that most people find in the ratings is not the quantitative data but the qualitative written reviews. Making that more integrated with various other search/browse sites might be cool, but even then it might help turn CPAN from a collaborative sharing space into a competitive, bashing, NIH space, which would be too bad. Perhaps at least the number of reviews could be factored into searches, or the at least the presence of /any/ reviews. I always find it easier to evaluate a module when I can see what others think about it as well. Mark
Re: I think we can just scrap CPAN Ratings altogether
On Thu, May 25, 2006 at 03:25:46PM +0200, A. Pagaltzis wrote: * Sam Vilain [EMAIL PROTECTED] [2006-05-25 09:05]: Can't we just move the site to cpanrantings.org? That's the spelling I've always used :-) Works for me??? Well, actually, I???d *like* to think it could be more useful than that??? but I am wondering if there is any hope. :-/ I already find CPAN ratings useful, and would find it even more useful if it was further integrated with search.cpan.org. For example, allowing to sort results by rating. I did this on Skatepark.org, and include the unrated items at the bottom. (Which encourages people to rate things they like!) Alternatively, it could be useful if cpanratings.perl.org allowed some way to browse modules by topic or keyword, with a sorting by rating. Mark
Re: [RFC] Data::FormValidator::Filters::HTMLScrubber - new module proposal
On Fri, Mar 24, 2006 at 04:54:05PM +0100, Enrico Sorcinelli wrote:
Hi all,
I just realized Data::FormValidator::Filters::HTMLScrubber, a simple
DFV filter that allows to scrub/sanitize html in form field values.
I've attached a temporary POD at the end of the message.
I searched on CPAN and I've not found any similar module (the reason
why I wrote it). Also I searched over Data::FormVAlidator mailing list
archives with same result.
Since I would put it on CPAN, any suggestions about the module and/or
namespace are welcome.
use Data::FormValidator::Filters::HTMLScrubber qw(html_scrub);
# Data::FormValidator Profile:
my $dfv_profile = {
required = [ qw/foo bar/ ],
field_filters = {
foo = [ 'trim', html_scrub( allow = [qw/b i em strong/] ) ]
}
};
I like the API and as the Data::FormValidator maintainer, I welcome this
addition to the Data::FormValidator name space. I suspect I'll use this
contribution myself!
Mark
Re: Assume Co-Maintainership of Mail-Webmail-Gmail
On Fri, Mar 10, 2006 at 04:18:36PM +0200, Shlomi Fish wrote: You have to contact the 'owner' directly. Only the owner can make you a co-maintainer. This mailing list does not directly affect ownership. The owner is not responsive, and hasn't been in quite a while. Besides, this email was directed towards modules@perl.org, where the CPAN administrators are, and from what I understood they _can_ make me a co-maintainer. You can always upload a fork in a new name-space if you want to get something on CPAN immediately. If the author becomes responsive, they can choose to merge your fork, or simply update the docs of the first branch to recommend the branch you maintain. Mark
Re: Naming advice for a templating module
On Sun, Feb 26, 2006 at 12:22:55AM +0100, A. Pagaltzis wrote: BTW: I don't really like XML::XMLTemplate... *What* about it do you dislike? Any objective reason, or is it just a matter of taste? I don't like the repetition. Repeating XML adds no value to the name for me. Why not go shopping among the many HTML::Template variations? I'll suggest XML::Template::Strict, since your approach seems to be stricter about validness than XML::Template. Mark
Re: Business::AAPOS?
On Fri, Feb 10, 2006 at 08:38:36PM -0600, Jay Hannah wrote: [3rd try. Posting to nntp.perl.org isn't working?] Actually, it seems to be working. At least, this is the fourth identical copy we've all gotten of the message. Please wait patiently and your request will processed in the order it was received. Thank you. Customer Service
Re: Another CPANTS/pod_coverage.t rant - FULL VERSION
On Mon, Nov 14, 2005 at 08:56:32AM -0500, David Golden wrote: A. Pagaltzis wrote: But at this point, I think even this is not quite the right approach. Rather, the tests should be built directly into Module::Build itself à la the `testcover` target. Test::Pod needs no parametrisation, so it would be trivial to integrate, and it also is the really valuable test. (At least I can?t think of *any* case where letting malformed POD through is desirable.) I think this is the way to go. Pod syntax checking is there already as testpod. It would be fairly trivial to add testpodcover, but I suspect that never happened because testcover does it already through Devel::Cover. I would rather these were rolled into 'disttest', so I have less API to remember. The pod tests could possibly be reported in a separate result, so there would be a distinction between the functional tests and the kwalitee tests. I do realize there is merit the alternate viewpoint that from the user's perspective the functionality and overall quality contribute a single overall impression. Mark
Re: Module abstract: Is its length still limited?
On Mon, Nov 07, 2005 at 09:08:40PM -0500, Ricardo SIGNES wrote: * Andreas J. Koenig [EMAIL PROTECTED] [2005-11-07T17:29:50] I will be very happy if you guys decide something and let me know. I'll adjust the code for the forms on PAUSE then. Here's my official vote: (length $module_name + length $abstract + 3) should be under 80. This means that the whole header and abstract will fit in one line. That's more than 44 characters for short module names. Longer module names, which should be pretty descriptive, need shorter abstracts. Wombat - a framework for building reusable fruit-counting applications Application::Framework::FruitCounting - for reusable produce applications That seems sensible. Perhaps to further relax it, it could be noted that longer values will be accepted, but they will truncated with an ellipse (...) when displayed in a space constrained format, such as a e-mail, or other documents meant to be read in a terminal. I'm fine with rjbs proposal as-is for the simplicity. My refinement would likely require effort of several tool writers to implement, instead of having the authors simply be concise. Mark
Re: Name advice: check license of dependencies
On Mon, Oct 31, 2005 at 10:08:53AM -0600, Chris Dolan wrote: I'm toying with starting a new module and would like some naming advice. My module will accept the name of another module and, using CPAN metadata and/or package contents, determine the license of that module's package and the license of all non-core packages that it in turn depends on. This module would be useful for determining redistribution rights for aggregations of code, like PAR files. It will probably employ CPANPLUS, YAML, Module::Depends, Module::Corelist and a bunch of heuristics to make its determination. For example, my module CAM::PDF is Artistic/GPL but it depends on Text::PDF which is just Artistic. This new module would help me to discover that fact. I don't like any of the names I've come up with so far. It seems clear that it should be in the Module:: namespace, but beyond that I'm unsure. Possibilities: Module::GuessLicense Module::License Module::LicenseChain Module::DistributionRights From your description, this is much as about a module's dependencies as it as a about a specific module. So I'll suggest: Module::Depends::LicenseReport Including Report signifies that the module has a read-only purpose. Mark
Re: Tests needing user parameters
On Wed, Oct 19, 2005 at 10:50:04PM +0100, Jess Robinson wrote:
I'm writing a module which will need user account data for it's tests,
and
I'm wondering if there's a standard way (or module) for doing this..
What do you mean by user account data?
Perhaps UNIX/Linux UIDs and GIDs?
Oops, sorry, thought it made sense ;)
My module will login to a web service and manipulate data
programmatically.. Nothing critical I assure you, just a tool ;) Since
theres no dummy/test account that I know of, I'll need the users
account/email address and password to login.
Using an OO approach is one way to go:
my $t = Test::Foo-new(\%my_params);
$t-wobble_ok('zoop');
Mark
Re: Hash::HasKeys
On Sun, Aug 14, 2005 at 06:18:38PM -0500, Dave Rolsky wrote: I'm very much wishing that P::V can disappear entirely in Perl6, and I'm probably going to confirm that on the p6l list, because in the end it's just a nasty hack. I find P::V quite useful, and more elegant that the longer-winder parameter processing I've done as an alternative. I, too, I am looking forward to enhancements in this area in Perl 6. Mark -- http://mark.stosberg.com/
why not SourceForge? (was: Re: Perl6 goes where?)
On Thu, Jul 28, 2005 at 09:50:17AM -0400, Buddy Burden wrote: Brian, Sourceforget sucks. Don't start using it just because I did. :) I'd be really curious to hear your opinions on Sourceforge (there may be a push to force us to start using it here at work). If you don't think you could sum it up and briefly and/or think it's too off-topic here, maybe you could post it somewhere else. But I'm sure lots of folks could benefit from your accumulated wisdom. :) I think one issue is that the only still offer CVS for SCM, while many people want something else now: Subversion or darcs for example. ( Although people have figured out how to publish darcs repos into their SF web space: http://darcs.net/DarcsWiki/FrequentlyAskedQuestions#head-d5a5bbdfabe810765004987ace054cb5e90e9ab8 ). There's also the ads. It's nice to work in ad-free environment whenever possible. It's still nice that SourceForge bundles several services that somewhat integrated and ready-to-go. Mark
Re: Bootstrapping a module community
On Sun, Apr 24, 2005 at 10:48:28AM -0400, John Siracusa wrote: What's the best way to spread the word about a new module? I've got a few modules that I think a lot of people would find useful. They're still in active development (pre-1.0) but I'd like as many people as possible to try them so I can get feedback from the community. How do I spread the word about these modules? There's always 'freshmeat.net', 'perlmonks.org', and your 'use.perl.org' journal. There is also the old fashioned network of personal networking. Hang out on other module mailing lists (or Perlmonks or use.perl.org) and become a respected contributor. Then people will be interested it check it simply because /you/ wrote it. Perhaps you already have that reputation, but hang out on different lists than I do. :) Mark -- http://mark.stosberg.com/
Re: Should DSLIP codes be updated?
On Tue, Mar 29, 2005 at 11:03:09PM +, Robert Rothenberg wrote: I'm sympathetic to the idea, but some of the information in DSLIP is useful and shouldn't be thrown away (such as how supported, alpha/beta/mature, and license). What isn't in META.yml should go there. I'm much less interested in whether the author thinks the work is mature, than what the users thinks. We already have a mechanism to create version numbers that indicate a developer release. For me, having a development/stable indicator than an alpha/beta/mature label. How many times have you found a module with a version less than '0.10' that was actually stable mature? On the other hand, sometimes 'mature' modules get overhauled, abandoned or forked and aren't really 'stable'. Mark -- http://mark.stosberg.com/
better SEE ALSO sections (was: Re: Introduction Letter)
On Mon, Feb 28, 2005 at 08:57:04AM -0500, Christopher Hicks wrote: This is a phenomenal initial cut of a POD. The review of relevant other modules in SEE ALSO and the philisophical differences with each deserves particular note. Bravo. I share your appreciation. I agree that this part of the documentation is frequently sub-optimal from a users perspective, especially when a new alternative appears when they are several standard options. For example (and not to pick on a particular module), here's one that was just released today: http://search.cpan.org/~jbuhacoff/Data-SimplePaginator-0.1/lib/Data/SimplePaginator.pm I was hoping for more of a comparison with Data::Page, which is similar but already established. Mark
a Perl/CPAN wiki (was: Re: better SEE ALSO sections)
On Mon, Feb 28, 2005 at 04:36:34PM -0800, Ofer Nave wrote: Valid points, but I disagree on one - I think it IS partly a technical problem. Jimmy Wales tried to start a free online encyclopedia called Nupedia before Wikipedia was a twinkly in his eye, and it failed miserably after getting 24 articles total. The problem was a technical one - you had to submit articles, have them reviewed and approved, etc. When Wikipedia was launched, it had 1000 articles within a month, because the form factor was right - want to change something? The edit button is right at the top. Go for it. I agree that the wiki format can be a great one for creating a low barrier to entry for collaborative documentation writing. I've witnessed work really well for darcs ( http://www.scannedinavian.org/DarcsWiki/ ) and CGI::Application. ( http://www.cgi-app.org/ ). After working a good deal on both of those wikis, I've convinced that even more subtle details of the format can make a different. The darcs wiki is much more pleasant to work on-- it feels easier to use. I'm more likely to contribute there. I'm rather satisifed as user of that software-- it's running the MoinMoin wiki: http://moinmoin.wikiwikiweb.de/ So what does it take to get wiki.cpan.org or wiki.perl.org set up? I suppose a first order of business would be to arrange hosting space, and one more volunteers to set up and administer the wiki. Mark -- http://mark.stosberg.com/
Re: Name for GStreamer bindings
On Tue, Feb 22, 2005 at 09:20:19PM -0500, Kevin C. Krinke wrote: On Wed, 2005-02-23 at 01:20 +0100, Torsten Schoenfeld wrote: Aloha, GStreamer is a powerful and pretty popular media framework. GNOME already uses it extensively, and KDE just started to. It's based on GLib and uses its object oriented C API style. The objects have names like GstQueue or GstElement. ... Gnome2::Gst:: makes sense to me. Except it's not tied to Gnome. KDE users it too. One option would be to use a very clear top level name space and used 'aliased' internally to call it 'Gst'. http://search.cpan.org/~ovid/aliased-0.11/lib/aliased.pm Mark
Re: Subclassing a mailer
On Thu, Jan 13, 2005 at 10:02:32AM -0500, Scott R. Godin wrote: For a project I'm on, I'm pondering whether or not to subclass one of the various Mail::* implementations out there, with an eye for Mail::Mailer. Does anyone have any recommendations in this regard? gotchas things I should watch out for ? pointers? examples? :) I subclassed MIME::Lite::send in order to implement a do not contact list. I check to see if the to, cc and bcc addresses are the on the list and return 'undef' is so. Otherwise, I just call MIME::Lite::send to finish the job. That has worked well for me. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Dec 07, 2004 at 12:38:12PM +, Tim Bunce wrote: --- The simplest fix is to standardize one set of driver DSN attribute names so that at least the host, port, and database (schema) can be specified in a portable way. Most drivers already support the foo=bar;... style in the DSN string. They'd just need to support alternative names for some attributes. As for what names to use, host and port are easy choices. For the database there's db, dbname, and database. I'd probably go with db. --- So now what all you zelots out there need to do is (gently) nag the authors of your favorite drivers to implement this change. The most gentle and effective way of doing that is to send them a patch. Shouldn't DBI proper at least have a documentation patch explaining what which parts of this should be considered 'standard'? I see that each DBD module can translate the hash into an old-fashioned DSN string themselves. Mark
Re: DBIx::DBH - Perl extension for simplifying database connections
On Wed, Dec 01, 2004 at 06:39:00PM +, Tim Bunce wrote: FWIW, the reason I'm digging here is because I agree there may be some value in the DBI supporting something along these lines, but I need a better understanding of the underlying issues. More real- world examples would help. I agree solving this in DBI is ideal. DBI is about abstraction, and this is one commonly used bit that varies from database to database. It'll always come down to the issue of why not store complete DSNs? and so far that's not been well covered by the feedback I've got. I've always stored each piece as as separate config variable. Maybe it's because that's the way my brain works. I don't think what's the DSN?, I think What's the username? the port number? the host name?. I like for the software to work how I think, rather than bending my head around the format that's easiest for the computer. Mark
Re: DBIx::DBH - Perl extension for simplifying database connections
On Wed, Dec 01, 2004 at 09:46:24AM +, Tim Bunce wrote: Do you generally pass URLs around as a string or broken up into a hash? If I have to deal with query strings in Perl, I do prefer to deal with them as hash, and then use CGI.pm to re-stringify it for me as needed. Mark
Re: Suite of modules to be released - the name game
On Sat, Nov 06, 2004 at 12:29:23AM +, Smylers wrote: Nonetheless I feel it would be worth doing this for anything completely independent. It may be a little more hassle for you to release a few separate distros rather than one -- but it would be a lot more hassle for a potential user who just wants your DateTime or URI module to have to grab the entire suite. More to the point they are unlikely to be noticed as part of a suite, so your work won't get the attention and usage they deserve, and it's more likely that somebody else will repeat them (only slightly different, and incompatibly) elsewhere. I can second this. When I found Data::FormValidator, it was only distributed as part of a larger framework...I didn't want the larger framework, I just wanted the form validation. This module was not well known at the time. Since Data::FormValidator has been released on it's own, there's been a lot more activity around it. I've also released a project that sounds more like the scale of yours. The small modules I've released end up getting hacked on a lot more by others, who returns the improvements to me. So the extra effort to release bits separately has definitely paid off. Mark -- http://mark.stosberg.com/
Re: Fields in Makefile.PL
On Tue, Nov 02, 2004 at 01:07:11PM +0100, Marco Marongiu wrote: Jose Alves de Castro wrote: I'm trying to normalize some modules, regarding tests, Makefile.PL, etc. I have a question: what fields do you find required or advisable in every Makefile.PL? I usually have NAME, VERSION_FROM, PREREQ_PM, AUTHOR... am I missing something important? Run h2xs, they very needed fields will be into the Makefile.PL You may also be interested in one of the new, friendlier alternatives to h2xs which are no CPAN: module-starter modulemaker Mark -- http://mark.stosberg.com/
Re: Let's eliminate the Module List
On Fri, Aug 27, 2004 at 12:53:15PM +0100, Simon Cozens wrote: [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. I've done the same thing that Simon is doing here-- implementing browsing and searching with the same code. I still had explicit browse options like browse by date and browse by size. They simply had hard links to a search result set. I think Simon is proposing the same-- the concept of browsing wouldn't have to go away, it could easily be implemented by creating explicit search links using the meta data in the system. Mark -- http://mark.stosberg.com/
Re: Circular dependencies in PREREQ_PM
On Fri, Aug 27, 2004 at 09:52:16AM -0400, John Siracusa wrote: If module A uses module B, but module B also uses module A, what do I put in PREREQ_PM? Will the CPAN shell be able to handle a circular dependency? As I understand, module A is downloaded before it is unpacked to discover that it depends on module B. So even if B depends on A, you already have A, so it's not a problem. Assuming that I'm correct, the problem is only avoided because of the current system design. If the meta data of both was downloaded first, that could be a potential problem. Mark
Re: Let's eliminate the Module List
On Mon, Aug 23, 2004 at 10:43:38PM +0100, Nicholas Clark wrote: There is nothing stopping anyone on this list prototyping their own improved substitute for search.cpan.org. (although it helps if you have a public facing webserver if you want to show it to others). Yet no-one does. Randy Kobes did: http://kobesearch.cpan.org/ But apparently it's not sufficiently better or sufficiently well known to come up in future of CPAN conversations much. At least the code for it is easily available: http://cpan-search.sourceforge.net/ It uses mod_perl and Template Toolkit. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: Let's eliminate the Module List
On Wed, Aug 18, 2004 at 04:54:32PM -0500, Andy Lester wrote: I propose eliminating the Long Module List. I'm talking about http://www.cpan.org/modules/00modlist.long.html (2998 modules), not http://www.cpan.org/modules/01modules.index.html (6800 modules). As a long time CPAN module author and user, I second this proposal. Mark
Re: Future of the Module List
On Tue, Jul 20, 2004 at 10:10:02AM +0100, Fergal Daly wrote: On Tue, Jul 20, 2004 at 06:15:49PM +1200, Sam Vilain wrote: I nominate the Review::* Namespace for author-submitted module indexes and in-depth reviews, in POD format. I think this has a number of advantages. Let's use the infrastructure we already have, no? Interesting, but what comes after Review:: if it's Review::Text::Balanced then how do we get multiple reviews Text::Balanced Maybe the convention could be: Review::Text::Balanced::CPANUSERNAME I'll let someone else suggest what should happen if the same person decides to review the same module multiple times. (Perhaps there would be an early negative review, and then a later positive review after the module improved with feedback.) Mark
Re: Future of the Module List
On Tue, Jul 20, 2004 at 03:57:10PM +0100, Fergal Daly wrote: The more I think about it, the more I think that it's not a great idea using the real CPAN to do things other than distribute code. Reuse the infrastructure by all means but the idea of mixing bundles, code, reviews and whatever else comes up in the same hierarchy with just naming conventions to tell them apart does not appeal to me. If we weren't dependent on collapsing all the relevant information down into a :: delimited list it would be much nicer (fantasy land, I know), I realize it's not a clean solution, but there are some things I like about it: - I can check http://search.cpan.org/recent for new modules and new module reviews. The means one less place to check for new and interesting Perl things that have been published. (OTOH, perhaps using an RSS News reader / aggregator would solve this just as well. ) - I like the idea of searching for a term and finding modules and reviews coming back. OTOH, we already have CPAN ratings for this. [ Thinks more. ]. OK, I'm changing my mind. I think it makes more sense to have a way to integrate longer reviews with cpanratings.perl.org. Perhaps a simple solution would be provide a field to link to longer review, which could be anywhere in any format. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: new module: Time::Seconds::GroupedBy
On Tue, Jul 13, 2004 at 09:01:30PM -0300, Bruno Negr?o wrote: Ah, so you reinvented DateTime::Format::Duration. use DateTime::Format::Duration; my $fmt = DateTime::Format::Duration-new( pattern = '%H hours, %M minutes, %S seconds', normalize = 1, ); print $fmt-format_duration_from_deltas( seconds = 7341, ), \n; Oh, what a sadness. Indeed i never saw the DateTime project before. But still my module is far easier to use than DateTime::Format::Duration. Do you believe it is worth to publish it in Time::Seconds::GroupBy? I would rather see more standardization on the use of the DateTime project, in much the same way that people think of DBI when they think of accessing databases through Perl. In this case, perhaps some clear documentation and examples (just like the one above) would be the best solution. I think if such a solution was easy to find on Google and clearly documented, people would use it, especially once there is more awareness of DateTime as a comprehensive date time solution for Perl. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Finding prior art Perl modules (was: new module: Time::Seconds::GroupedBy)
On Wed, Jul 14, 2004 at 01:24:43PM -0300, Bruno Negr?o wrote: I agree Mark, i've posted my module on the DateTime mailing list. Let's see what they say about it. But i think the DateTime project is not gaining fair promotion once their modules are not even appearing on the main Module List in the cpan's site at http://www.cpan.org/modules/00modlist.long.html. If people should concentrate effort in making this framework the solution for Dates and times related problems, the DateTime namespace should at least appear on the Module List, right? I think there is a separate more general issue that the module list is losing relevance. I think a lot of people (like myself), use http://search.cpan.org as a primary method for finding useful modules. As a CPAN user, I don't consult the list when looking for modules. As a module writer, I have abandoned caring if my modules appear on the list, because I have the perception it's not used much anymore. So I would say a more important issue is that the DateTime modules don't show up in the first 100 results for Date on that website: http://search.cpan.org/search?m=allq=dates=1n=100 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. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: META.yml keywords (was: Re: Finding prior art Perl modules)
On Wed, Jul 14, 2004 at 03:11:11PM -0400, Randy W. Sims wrote: Fergal Daly wrote: Does META.yaml have a place for keyowrds? The spec doesn't currently provide for keywords. I do think it would be a good idea, BUT I think it needs to be done in a way to avoid abuse. I'd hate to see META.yml files grow by the kb as authors add every conceivable keyword they can think of and try to manipulate the search. The search algorithm could pay attention to the first X keywords and ignore the rest. Or at least, it could heavily weight the first few. I think this is part of how search engines prevent the same kind of above of the meta-tag keyword system. You can put as many keywords as you want into the list, but I think the search engines only really care about the first few. I would prefer something like this over the choosing from the fix list idea. Having free-form tags is a feature I like on: http://del.icio.us/ It allows new classifications to spontaneously appear. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: New Module: HTML::DragDrop
HTML::DragDrop::Javascript HTML::DragAndDrop::Javascript Is there a way to implement Drag and Drop with HTML /without/ using JavaScript? I suspect not. Thus, I think it could be appropriate to drop 'Javascript' from the name HTML::DragDrop HTML::DragAndDrop Including 'And' in the name is how people usually refer to the technique. However, for a module name I think it may be clear enough to exclude the word 'And' in favor of a shorter name that is 'good enough'. Mark http://www.summersault.com/
Re: New Module: HTML::DragDrop
On Thu, Jun 24, 2004 at 12:12:05PM -0300, SilvioCVdeAlmeida wrote: Hello, you all. I suspect that if drag_and_drop depends on javascript, so do tooltip. That's of course in the HTML context. And also, I'm excluding from tooltip the direct, obvious, plain img alt= Please tell me if it isn't so. Tooltips can be implemented purely in CSS, as documented here: http://www.madaboutstyle.com/tooltip2.html I can't think of how drag'n'drop could be implemented without JavaScript. Mark
Perlforge? (was: Re: CPAN Rating)
On Mon, Jun 21, 2004 at 11:12:25AM +0100, Simon Cozens wrote: [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. One benefit I see of a extra forges like rubyforge is decentralization. Right now open source has a huge dependency on SourceForge. If it goes away or becomes unavailable, that's a major loss to recover from. I'm more comfortable having a number of similar sites available. Personally, I haven't gotten a lot of benefit out of SourceForge hosting so many sites. Usually I use the tools related to one specific project. Rarely do I use any tools that benefit from having lots of projects there. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: New module: CGI::Tooltip
On Thu, Jun 17, 2004 at 08:13:08AM -0500, Ken Williams wrote: Yeah, HTML::Tooltip and CGI::Tooltip seem like the obvious names. I don't think you need to put Javascript into the name, that's too much information. Actually, I like JavaScript::Tooltip. If the the code is not HTML-specific, it may well be useful in other places JavaScript is used. It's my understanding that JavaScript also is used with SVG, PDF and Scribus documents. So I think a good name might be JavaScript::Tooltip::HTML. Then people could implement the same API with different backends: JavaScript::Tooltip::SVG JavaScript::Tooltip::PDF (I'm not even sure that PDF would support this kind of tooltip, but I imagine SVG would.) Mark
Re: CPAN Rating
On Wed, Jun 16, 2004 at 01:17:51PM +0200, Michael Peppler wrote: Why don't you start by rating those modules that you feel are horribly lacking with 0 stars? Part of the issue here is that cpanratings.perl.org doesn't expose the individual component ratings (Documentation, Interface, Ease-of-Use), only the summary rating. In some cases I have given a module high marks for all three categories, but the lowest rating overall, but the module is implementing that a new module (or yet another module) doesn't make sense for. Another perspective: I do see signs that the current rating system is helping. After receiving several negative ratings, CGI::NeedSSL has been pulled from CPAN. Mark
Re: Application framework namespaces
On Fri, May 14, 2004 at 03:17:50PM -0400, _brian_d_foy wrote: In article [EMAIL PROTECTED], Michael A Nachbaur [EMAIL PROTECTED] wrote: The thing is, these are free-standing applications, and for the most part aren't developer tools. So, I was thinking an App:: namespace would work well, (e.g.. App::WWW::NachoMusic, etc). I'd rather see top-level namespaces for complete applications. I don't think the App::* adds any information. :) I would imagine that you meant to qualify this statement with an assumption that the applications have decently unique names, and not generic ones that might look like an existing standard use of a top-level domain (CGI, HTML, Data, WWW, etc). Mark
Re: Duplicated modules
On Thu, May 13, 2004 at 07:38:51PM -0400, Randy W. Sims wrote: It would be much nicer if [perlmonks] was readable as a nntp or at least a mailing list; I've always found http-based discussion boardss awkward to navigate and difficult to figure out what I have and haven't read. Wonder why this hasn't been done? There is an RSS feed: http://www.perlmonks.org/headlines.rdf RSS readers often help you manage what you have and haven't read. I like to use 'snownews' in a terminal. Also, you can the voting feature to help keep track of what yo've read. Just vote everything you read up or down. :) Admittedly, that strategy works best once you've been there a while and have lots of votes to use. Mark -- http://mark.stosberg.com/
Re: Duplicated modules
On Tue, May 11, 2004 at 12:33:00PM +0100, Jose Alves de Castro wrote: Take a look at the CPAN. Search for Roman. There's Roman, Math::Roman, Text::Roman, Convert::Number::Roman, etc... Isn't this duplicated effort? :-| Besides, this may prevent the user from having all the available functionalities without installing all of those modules... :-| And I'm sure this isn't the only case. What can be done about it? I'm a fan of using the 'rating' system available from each module page. As ratings and comments accumulate, it will become easier for future visitors to figure out which modules are worthwhile and why. (It's certainly not a total solution, though! ) Mark
Re: CGI::Uploader (was: CGI::FileManager)
Thanks for the feedback Andy. On Sat, May 01, 2004 at 09:00:36AM +0100, Andy Wardley wrote: Mark Stosberg wrote: I think I want to make some slight tweaks to the API, but it's about ready for 1.0. It's built around my own common usage: Uploading images and storing meta data in a database. However, it works fine for non images as well. I think this module should be called CGI::Image::Upload, or perhaps even CGI::Application::Image::Upload. Except it works great for managing uploads of PDFs and other non image uploads as well. It's not a generic module for uploading images (it makes assumptions about the fact that you're using DBI for example). CGI.pm, CGI::Simple, Apache::Request, etc already handle the basics of file uploading. I go a step further to allow management as part of a web application. And there's certainly far too much image specific functionality to warrant such a general name. The facility to create image thumbnails, for example, certainly doesn't belong in a generic CGI::Upload module. It creates thumbnails by calling Image::Magick. That's it. It's really just a module that implements your particular image upload web application, IMHO. There's nothing wrong with that, and there's plenty of room on CPAN for it, if you want to upload it. But please give it a name that reflects what it actually does. I'm open to suggestions. I won't give it an image-specific name, because it's not image specific. [Ponders]. Perhaps I could name it CGI::Uploader::DBI. If the storage scheme becomes uncoupled from DBI in the future, CGI::Uploader could be that base class. BTW, I looked at CGI::Upload too and don't currently recommend it. Check out the bug reports currently filed against it. I can see two minor bugs that require little more than a line or two of changes to fix them, and one feature request which includes code. Are there some other bugs I'm missing? This bug is not minor: http://rt.cpan.org/NoAuth/Bug.html?id=1854 Uploads from Windows are not being detected properly. (Which is a much broader issue than the bug name implies.) They are easy fixes, but they are unfixed now, which is why I can't currently recommend it. With one important bug being open for over a year, it doesn't seem promising that it will get fixed Real Soon Now. Personally I would rather see efforts made on fixing these bugs than releasing a new module with an almost identical name that does something less useful for most of the people, most of the time. I like CGI::Upload as a concept and would like to see it's bugs fixed as well, which is why I contributed to the bug reports. CGI::Uploader is much more extensive in the functionality it offers, rather than a direct competitor. Mark -- http://mark.stosberg.com/
Re: CGI::Uploader CGI::Upload (was: CGI::FileManager)
On Sat, May 01, 2004 at 11:12:48AM -0700, Austin Schutz wrote: Having multiple modules which appear to provide parallel benefit can end up confusing the users as to which module is the best. It can. This is also an area where the cpan rating sytems can be very helpful: ( http://cpanratings.perl.org ). It can be helpful in some cases to give the less useful module a low rating with a comment that includes a pointer to some other module, which may actually be more useful. Of course, if the author is cooperative, this could also be appropriate in a SEE ALSO of the documentation. Mark -- http://mark.stosberg.com/
Re: CGI::Uploader (was: CGI::FileManager)
On Fri, Apr 30, 2004 at 04:47:49PM -0200, Gabor Szabo wrote: I am looking for a module that can be used as part of a web based application which requires management of a (partial) file system. If there is no such module I wonder if it would be interesting to add to CPAN ? So my questions are: - Is there such a module that someone could recommend ? I'm now polishing a module which manages file uploads: http://search.cpan.org/dist/CGI-Uploader/ I think I want to make some slight tweaks to the API, but it's about ready for 1.0. It's built around my own common usage: Uploading images and storing meta data in a database. However, it works fine for non images as well. It doesn't meet all of your requirements, but may be useful as a component. The distribution includes a Cookbook with walk-through examples, as well as a complete (very simple) application. While I store the meta data in a database, I have some interest in supporting other storage schemes as well. The API is only lightly tied to need a DB now, but should be able to be un-coupled fairly easily. BTW, I looked at CGI::Upload too and don't currently recommend it. Check out the bug reports currently filed against it. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: New Wrapper API for Data::FormValidator
On Tue, Apr 06, 2004 at 01:38:17PM -0500, jason scott gessner wrote: I have written a wrapper API around Data::FormValidator and it is getting close to being sharable. I think I can summarize the primary difference between this interface and the current one. With the current one, you define your validation profile with concepts like these are all the constraints that will be applied and these are all required fields, and so forth. This new API is based around fields instead. So you have concepts like this field is required or this field as a particular constraint. That clarification doesn't lead me to great name though. Here are some which seem to have right meaning, but I'm don't really like them anyway. Data::FormValidator::FieldBased Data::FormValidator::ElementAPI Data::FormValidator::Elemental Out of those, I like Elemental the best. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: running tests
On Mon, Apr 05, 2004 at 05:05:34PM +0100, Simon Cozens wrote: [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! 'prove' has really made a big difference for me. With 'make test', I had the sense there were ways to fine tune the output. But how to do that seemed different to discover, and difficult to remember. With prove, there's 'prove -h' and 'perldoc prove', making things much easier to learn and lookup. Since it is 100% compatible with the test files already in use, there is nothing to lose by trying it or using it. It's not as if it's a new dependency that module users have to to have to install it. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: Module::Starter released
On Mon, Apr 05, 2004 at 02:15:30PM -0500, Andy Lester wrote: I've just released Module::Starter 0.02, meant as a replacement for h2xs. I think h2xs is very out of date as far as current best practices for modules. It's also very intimidating for people who just want to create a module, and have no need for all the compiler hoohah that h2xs throws at you. Module::Starter is meant to make things much eaiser. Here's a sample run of Module::Starter's command-line program: Thanks Andy. Here's an initial comment: I think would useful to include ExtUtils::ModuleMaker in a SEE ALSO section, and explain the key differences. At first glance the projects seem quite similar. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: running tests
On Fri, Apr 02, 2004 at 01:52:12PM -0600, Andy Lester wrote: No. But there are certain classes of functions of the module that don't work until others have been run. So others should have been tested So some tests are setting up other ones, then? One of my goals when writing tests is to make everything as independent as possible, so that I can run a single test (using prove) as part of my development process. Andy, So how do you recommend handling the case where some tests depends on other things being in place? For example, with DBD::Pg, a lot of tests depend on having test data in the database, and having the database connection working and open. One idea would seem to be have a testing module that provides the setup and tear-down functionality. Then each individual test could load the testing module, and setup and teardown for itself. Is that what you do, Andy? Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: running tests
On Fri, Apr 02, 2004 at 02:02:24PM -0600, Andy Lester wrote: For example, with DBD::Pg, a lot of tests depend on having test data in the database, and having the database connection working and open. Every one of our *.t and *.phpt files is self-contained. If it needs a connection to the database, it opens one. If it needs test data in the database, it creates it. If it needs to delete the data, then it deletes it. Does that mean the test scripts are full of copy/paste coding? So if there is a bug in the test up routine, it would be propagated everywhere. It seems reasonable to break with the ideal of self contained tests a bit and put shared test setup/tearcode code into a re-usable testing module. (which itself might have a single set of tests run against it). Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: running tests
On Fri, Apr 02, 2004 at 02:12:46PM -0600, Andy Lester wrote:
I don't know what you mean by using prove?
prove is a command-line utility that ships with Test::Harness. It
allows you to run a specific test or tests, as specified on the command
line, without having to go through the make test rigamarole.
I use 'prove' as well and find it to be very useful. Here's a command I
mind use to run all the 'base' tests, plus those for milestones 1
through 3:
prove -I../perllib --ext=.pl base m{1,2,3}
Then if one fails, I can zero in one it and turn on the verbose option:
prove -v -I../perllib m1/shelter_add_edit_func.pl
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark StosbergPrincipal Developer
[EMAIL PROTECTED] Summersault, LLC
765-939-9301 ext 202 database driven websites
. . . . . http://www.summersault.com/ . . . . . . . .
Re: running tests
On Fri, Apr 02, 2004 at 03:48:12PM -0600, Andy Lester wrote: A smokebot is a script that runs your test suite at regular intervals, kicked off by cron. It checks out a given CVS branch, and then runs the entire test suite. For us, it runs once an hour, and if any tests fail, the entire department gets notified. Very helpful Andy. smoke $@ /home/smoke/smoke.out 21 And what does the inside of this 'smoke' script look like? Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: How do I prohibit analyzis for packages for certain files on CPAN upload?
On Tue, Mar 23, 2004 at 08:11:00AM -, Rafael Garcia-Suarez wrote: [untested] Put those files under inc/, eg/ or t/ (depending on what it is exactly) and include in a top-level META.yml file: (which should be autogerated by recent makemakers) private: directory: - inc - eg - t Assuming this works: Since the file is auto-generated, how do you make the change persistent? It seems something would need to be added to Makefile.PL or Build.PL. Mark
Re: Finding the module you want (was: New module Mail::SendEasy)
On Tue, Feb 10, 2004 at 05:27:11PM +0100, Eric Cholet wrote: Le 10 f?vr. 04, ? 16:16, darren chamberlain a ?crit : I agree with you, but, if you are already investigating software to handle a task, wouldn't you look at as many alternatives as possible? I certainly wouldn't. Rather, I would look at as many alternatives as necessary until I find the module that does what I want with an API that suits me. More often than not it's been the first candidate. Likewise, considering projects have budgets and timelines, I'd likely stop at the first one that seemed good enough. Mark
Re: New module Mail::SendEasy
On Sun, Feb 08, 2004 at 07:18:38PM +, Smylers wrote: The Cpan rating thing may help somewhat in this regard -- I will log on and give MIME::Lite a good review sometime, honestly! What would really be useful is a comparison of the various mail-sending modules available, listing which features and interfaces each has and in which situations it can be used -- in the hope that by sticking to facts rather than including opinions it will not be too controversial; perhaps the various module authors could even link to it in each of the modules' docs? I think the CPAN rating system could be of further help here as well. It could be integrated with the search.cpan.org search engine. The rating could appear on the results page, with top-rated modules appearing first. So, just searching for a module named mail should be begin to give you a sensible result. This public prominence would also encourage more people to use the system, I believe. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: New module Mail::SendEasy
On Mon, Jan 26, 2004 at 06:05:27PM -0300, Graciliano M. P. wrote: Second, the self contained module counts a lot for me and the framework that we develope! We really can't ask to the user to install soo many modules to can use it. If the author of MIME::Lite is interested to change it's MIME::Lite architecture (just talking about dependencies) I will be interested to add some resources to it, since as I can see now, is a popular module. I'm als a user and fan of MIME::Lite. Perhaps there is an easy way to create an alternate distribution of it that contains all its dependencies, but is easily installable. That seems like a good solution to me. Mark
Re: cpan name spaces
On Tue, Jan 20, 2004 at 12:23:09PM +, Fergal Daly wrote:
Not that this would ever be agreed upon, the old way is ingrained. Modules
will continue to do for example
PREREQ_PM = { Parse::RecDescent = 1.80 }
then fall over because 1.90 satisfies this requirement but is not actually
compatible,
This is addressed to some degree in the Module::Build system, which allows you
to specify required module versions like this:
Ken::Module = '= 1.2, != 1.5, 2.0',
So there /is/ currently way to specify exactly which versions you expect
to be compatible. Unfortunately, unless the author of the required module
has made clear version numbers like you suggest...it make take some
digging to figure out exactly which versions should be required.
Mark
Re: cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
On Mon, Jan 19, 2004 at 08:42:09AM -0600, Chris Josephes wrote: On Mon, 19 Jan 2004, Mark Stosberg wrote: I would rather CPAN be wide at the top level than have un-intuitive names. The author based system will also become more difficult when authors change hands, disappear, or there are multiple authors. There's kind of a trade-off here. Right now, when module authors disappear, it's very difficult for a new author to take over that namespace because it's registered to an author/email address that may not be active anymore. With author namespaces, they can just create a new namespace under their CPAN id. And then the 1000 people who use their module can all do a find and replace on all places where they have referenced the the module name with the other authors ids. And what happens when module author gets married and get a new hyphenated last name? /sarcasm I have enough trouble remembering APIs without trying to remember whether I need to load something in namespace of William, Will, Bill, Willie, or Willy. I can't say I'm a fan of this idea. Mark
RFC: CGI::UploadDB
Hello, I'm interested in feedback on a module I've developed to manage file uploads, which I'm calling CGI::UploadDB for now. CGI::UploadDB manages file uploads with a SQL database. It handles generating thumbnails, file installation, deletion, and display. Files are stored on the file system with meta-data in the database. MySQL and Postgres are supported. I'm interested to know: OK Name? Useful idea? Useful interface? Clear documentation? Other suggestions? Full documentation [1] and source code [2] are available. It currently depends on the brand new Data::FormValidator 3.50 release. 1. http://mark.stosberg.com/dfv/doc/CGI/UploadDB.html 2. http://mark.stosberg.com/perl/CGI-UploadDB-0.10_03.tar.gz 3. http://search.cpan.org/perldoc?Data::FormValidator Thanks! Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: Namespace suggestions for new module submission
On Thu, Jan 01, 2004 at 06:15:49PM -0900, Arthur Corliss wrote: Greetings: In the near future I'd like to submit a module for inclusion on CPAN. I need some advice on the appropriate namespace, however, since I don't want to pollute top-level namespace. Unofficial module name (as it's being developed): PerlDBM Synopsis: Pure-perl implementation of a dbm engine. Supported only on platforms with 64-bit filesystems. Database files are portable (all data is stored in network-byte order), with record-level locking and transactions. Has it's own API for low-level control, but also will support tied hashes. I did notice that most of the XS wrappers for C-based implementations were all in top-level namespace, though. Any suggestions/preferences? Will this be implemented with the DBI interface? Then DBD::YourProject seems appropriate. DBD::SQLite seems to be a related case, although it's not Pure Perl, it just allows you install it as a standard DBI driver. Mark
Re: RFC: Date::Iterator
On Fri, Dec 19, 2003 at 03:44:51PM +0100, Marco Marongiu wrote: Mark Stosberg wrote: Dosn't DateTime::Set and DateTime::SpanSet already address this problem-space, but in a more flexible way? http://search.cpan.org/~fglock/DateTime-Set-0.14/lib/DateTime/Set.pm It allows span sets to be non-contiguous, such a set of meetings occurring every Wednesday. It also returns DateTime objects, giving you all the flexibility of formatting and features that a such an object implies. I'd be interesting in hearing a bit more about cases where this new module would be a better choice. I took a look at the page you mentioned. My module does just one, very specific thing. DateTime::Set is flexible, powerful... but when you just need to iterate over a range of days with a constant step, it looks overkill to me. DateTime::Set covers about all cases one could need to handle. Thanks for the response. I can appreciate the distinction. Sometimes big and powerful is a better approach, sometimes simplicity is better. You might add a mention of this module to your SEE ALSO section if you haven't already, though. Mark -- http://mark.stosberg.com/
Re: Simple multi-level tie
On Wed, Dec 17, 2003 at 02:00:23PM -0600, Andrew Sterling Hanenkamp wrote: Therefore, I went in search of a solution to automate the stringification. I didn't find anything other than MLDBM for doing something like this and it seems like a little much for my purposes. All I need is something like this: When I want to do this, I just use CGI.pm. With it, you can pass a hash to the 'new' constructor, and use query_string() function (I think) to get back a stringified version. Likewise, you can pass a query-string to the constructor, and get a hash structure back. Keys with multiple values are supported, although I usually don't have that case. Your solution may well be cleaner for general cases. Mark
Re: Geography Specific Namespace
On Thu, Dec 04, 2003 at 09:26:04AM -0500, Aran Deltac wrote: Allright, well, Geography is a great namespace to start! I think it would be a good idea to plan out the namespace a little. I would like to propose coming up with a logical structure to the modules contained within Geography::. This would really just be a list of directories and module names and how they relate if at all. It would also describe justifications for choosing one name/structure over another. Then as module authors need geography functionality they can just write a module that fits in with the structure. Of course plans never quite fit the bill in practice, so it would just be a guideline. Comments, questions, moral support? A plan sounds like a good idea to me. Mark
Re: Author's namespace
On Fri, Nov 14, 2003 at 01:33:01PM -0600, Eric Wilhelm wrote: I think I have a similar concern. Here's my own case: I use a custom sub-class of CGI::Application that I base most of my web-applications on. Eventually, I would like to distribute some of these on CPAN, with several of them referring to the same custom sub-class itself. However, it don't think the sub-class module itself would be especially interesting to others-- it might-- but it mostly seems like a set of personal style choices about how I like to design web-applications. If it didn't go under an Authors:: namespace, it seems like it would get some other un-descriptive name like CGI::Application::MarksSubClass. You could fully-document the helper module (and maybe make it more configurable?) I like this one the best, and maybe others who work in the same manner could benefit from it. Do you think it is possible to boil-down the you-specific parts of your module into a config file in your home directory? It would be interesting to see how this would work. You could inline all of the helper module functions at the end of your regular module (maybe a dist target in your makefile can automate this for you.) I think some other people would probably find some of my personalizations useful as well. I'm open to cleaning it up some as you suggest. Still that leaves the issue of naming it. It's still best described as a module for building CGI applications Mark's way. I could give it some generic name like CGI::Application::TurboCharge, but that seems to be of limited usefulness. What's a good way to name these kind of personalization modules? It's these kind of cases that make Authors:: begin to make sense. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: Author's namespace
On Fri, Nov 14, 2003 at 02:19:44PM -0600, Eric Wilhelm wrote: The following was supposedly scribed by Mark Stosberg on Friday 14 November 2003 02:02 pm: Still that leaves the issue of naming it. It's still best described as a module for building CGI applications Mark's way. I could give it some generic name like CGI::Application::TurboCharge, but that seems to be of limited usefulness. If your way isn't the best way, there must be something wrong with it or your ego:) Maybe you should name it according to how you would describe your style, so that others with a similar style could find it more easily. CGI::Application::Terse ? This seems like the best option in my case. I'll start discussing specifics on the CGI::Application list and see where it goes. Thanks for the nudge. Isn't it possible to distribute it under the front-end module? This would be OK if there was only one front-end. The code is re-usable enough that is probably supporting a dozen or so projects already. I would hope that over time I would release at least two projects to CPAN that require it. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: Yet another naming question
On Mon, Nov 10, 2003 at 03:06:30PM -0500, darren chamberlain wrote: be the TLD since it is mail related? Mail::Mutt::Parser is my guess, but I don't know much about mutt. Though the idea and syntax originate with mutt (as far as I know, at least), the general idea is not mutt-specific, or even mail-specific. The idea occured to me because I was writing a (non-mail-related) curses-based interface to a database, and needed functionality similar to mutt's Limits. This my initial MuttStylePatterns name. The mutt docs simply call them patterns, but that's much too generic a name for this module, I think. They seem like a kind of regular expression to me. Something under one of these name spaces makes sense to me: Regexp::Mutt Regexp::MuttPatterns Having Patterns in the name might repeat the idea of what RE's are, though. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: FAIL AFS-Command-1.3 darwin 6.8
On Thu, Nov 06, 2003 at 10:17:45AM -0500, [EMAIL PROTECTED] wrote: This particular module can NOT be tested automatically, without some manual configuration. The tests can not automatically determine the configuration of your AFs infrastructure; you have to tell me. Therefore, everytime I post this module, these tests are going to fail. The same is going to be true for DBD::Sybase, or any of the RDBMS modules which need to be configured with a data server, and/or database name. Is there a mechanism for telling the automated CPAN testing to skip this module? I do NOT want to hack the code to make the test skipped by default, because then unsuspecting administrators who install the module without reading my documentation will be give a false positive. You may be interested in how the DBD::Pg test suite works. As you point out, it does need a bit configuration for the tests to run. (In this case, setting a single environment variable usually works). If the environment variable isn't present the tests are skipped. Recently some of the configuration has been automated by using App::Info. The specific module used in this case is here: http://search.cpan.org/~dwheeler/App-Info-0.24/lib/App/Info/RDBMS/PostgreSQL.pm Perhaps a helper module like this could simplify the needed configuration in your case as well. Mark
Re: Namespace for common datatypes
I'm going to be creating a set of wrapper classes that presents a common interface to some of the CPAN modules that supports the above datatypes and just does the Right Thing???. Could you say more about what the Right Thing is, or give an example? That might help the discussion of the appropriate name. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: RFC Format::FileSize
On Wed, Aug 27, 2003 at 05:55:49PM +0100, Orton, Yves wrote: Does this make sense or does this already exist and I have missed it? Is Format::FileSize a proper name? Do a search for units on search.cpan.org and i think youll find this somewhere. And no I dont think the name is that great. I agree FileSize is not a good name, because the module appears to deal with unit conversion and display, which could be for something besides file size. I think like idea of checking the unit name space. Mark
Re: Getting permissions to close bugs when you have taken over a module
On Tue, Aug 26, 2003 at 11:25:53AM +0200, Yves Orton wrote: Anyway, my immediate issue is to close the bug reports against MIME::Lite. How can I do so? In RT, The current owner can give a bulk of tickets to you at once. Here's how the owner can do that: 0. Log-in 2. Use the Search function. Search with the queue and owner may find all the wanted tickets. 3. Once you've found all the tickets you want to update, using the Update all these tickets on the search results page. 4. On the Update All screen, there will be a field to put in an owner for all the new tickets. That's it. Mark -- http://mark.stosberg.com/
Re: Getting permissions to close bugs when you have taken over a module
On Tue, Aug 26, 2003 at 02:57:51PM +0200, Yves Orton wrote: So I can't close these bugs until Eryq intervenes? Does this really make sense? Surely if he assigned ownership of the module to me the RT ownership should be transferred as well? First, I'll add that I'm not directly involved in the policy making or code for CPAN. I do use RT (v3) at my business and am familiar with it. So my answer is not official. :) I think you are correct that as a /policy/, it makes sense to have the tickets transferred to you when the module is transferred. I doubt this a policy hang-up, but rather a technical one. I get the sense that RT and CPAN are fairly separate pieces of software, and this integration code hasn't been written yet. Out of curiousity, what happens if Eryq isnt around to take care of this? How can the tickets be closed if he is off on safari somewhere, not to return until 2007? ;-) Someone who is an RT administrator has the ability to make the change. The website mentions you can contact this address for help: [EMAIL PROTECTED] Somewhat related, rt.cpan.org is based RT version 2, when RT 3 has been released, a major upgrade. I'm interested to know in generate what plans there are to enhance this RT installation. It's certainly proven to be very useful! Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: [chris@clotho.com: Re: What are the dead camels?] (HOWTO take over a module)
On Thu, Aug 07, 2003 at 03:00:36PM +0100, Leon Brocard wrote: Actually, I meant to list. Looks like Chris has done the right thing in trying to contact the author. Elaine, could you enlighten us on the steps for taking over a module? It's in the FAQ: http://www.cpan.org/misc/cpan-faq.html#How_maintain_module Mark
Re: What search.cpan.org PAUSE produce (Fork from: what to do with dead camels?)
On Wed, Aug 06, 2003 at 04:06:34AM -0500, elaine wrote: On Tue, Aug 05, 2003 at 01:09:52AM -0400, Christopher Hicks wrote: (A) Do we have any idea what tha algorithm it's using is? Soundex for everything but Authors and Docs which then uses CPAN::WAIT. I suppose that explains why searching for lbdb with All takes me directly to Acme::Pr0n. (by contrast: kobesearch just returns no results on the default search. ) Is there is a Soundex::FamilyFriendly::Filter out there? I wasn't expecting the Pr0n to popup there like that on my innocent query. :) Mark
Re: what to do with dead camels ? work on CPANTS
Hello, As long as we are discussing ways to improve the quality of CPAN, this seems like a good time to mention CPANTS. While addresses Dead Camels does patch a hole in CPAN, Schwern's CPANTS proposal provides a complete solution for quality control for CPAN. Here's a link to more information about it: http://use.perl.org/~markjugg/journal/13121 This project is already underway and in its early stages in the form of Module::CPANTS. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: Unix::Dialog vote (+1 for ::Backend)
On Fri, May 30, 2003 at 09:24:17AM -0400, Kevin C. Krinke wrote: Mind you though I don't really care all that much (it's only a 9 more keystrokes), and so I'll put it to a module-authors list vote (reply +1 with your choice): Unix::Dialog::Backend::* +1 Unix::Dialog::* After following the discussion, I'm in favor of ::Backend, because it's clearer. It sounds like it will frequently be used indirectly, so it won't need to be typed out much anyway. Mark -- http://mark.stosberg.com/
Re: Filesys::DiskFree
On Fri, May 30, 2003 at 03:00:25PM +, Martyn J. Pearce wrote: I would like to apply to take over maintenance of this module. To whom do I send the relevant mail / what form do I fill in to achieve this? Martyn, For starters, there's this: http://www.cpan.org/misc/cpan-faq.html#How_maintain_module This document doesn't answer the question ...if all else fails, then what?. That is, I'm still unclear how namespace authority is transferred, or if it is enforced at all. Mark -- http://mark.stosberg.com/
Re: Detecting updates to installed modules?
On 24 Mar 2002, Jason W May wrote: Has anyone created a tool to determine what modules are installed locally, and check CPAN for updates to any of those modules? I don't want to reinvent the wheel here, but I can't find anything that does this. CPAN.pm does a fine job of download-and-install, but there's no inventory function or query-for-update. I thought that's what the r (for reinstall) function in the CPAN shell does. It appears to emit a list of your currently installed packages compared with their latest versions. -mark http://mark.stosberg.com/
Re: for review: Elapse.pm
Scott R. Godin wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Dominique Dumont) wrote: [EMAIL PROTECTED] (Scott R. Godin) writes: Thanks. First seriously constructive response I've gotten. Was beginning to think no one reads this list anymore :) just a bit of silliness I conconcted while reading Damian's OOP... Your thoughtful appraisal and suggestions would be most welcome. I'm still experimenting with it off and on. :-) This module could be useful. I don't see any reason to not upload it. Except that the name would be better as Time::Elapsed (which would fit with the other Time::* modules). Hello Scott, It seems to me this module covers the same problem space as the Benchmark module, as it's used like this: use Benchmark; $t0 = new Benchmark; # ... your code here ... $t1 = new Benchmark; $td = timediff($t1, $t0); print the code took:,timestr($td),\n; If I recall, your module took a slightly different approach by reporting the time it takes for a variable to change. -mark . . . . . . . . . . . . . . . . . . . . . . . . . . Mark Stosberg Principal Developer [EMAIL PROTECTED] Summersault, LLC v: 765-939-9301 ext 223website development . . . . . http://www.summersault.com/ . . . . . . .
Re: Request for help with naming module
On 10 Jul 2001, William R Ward wrote: I have written a module that supports login authentication for CGI apps. It has the following main operations: Register a new user Log in Change password Change user profile Forgot my password This sounds similar to an existings module: DBIx::UserDB Maybe yours could be DBIx::Auth? I'm new at module naming myself. -mark http://mark.stosberg.com/
Re: Namespace for an application?
We could, alternatively, use Tracker. I like that cause its less typing. I prefer Apps::Tracker for being more descriptive. -mark http://mark.stosberg.com/
