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/
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: 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: Announcement: Pod::WikiDoc
On Wed, Oct 12, 2005 at 10:17:19AM -0400, David Golden wrote: > Dear fellow Perl authors, > > I've recently released an initial version of Pod::WikiDoc to CPAN: > > http://search.cpan.org/dist/Pod-WikiDoc/ It's neat idea, and sounds a lot like "kwid", the wiki like documentation syntax that is based on kwiki's syntax and will be used as POD in Perl6. http://www.kwiki.org/?KwiD I see you mention Kwiki in your docs, but not kwid. What's the relationship between your project and Kwid? I'm surprised it's not easier to find Google docs about kwid. There was once a document called "perlkwid.kwid" which explained it in detail, but I can't find it now. If we could start using kwid in Perl5, that would be ideal to me. What you have seems very close. Thanks for your work on this! 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/
Re: Hash::HasKeys
On Sat, Aug 13, 2005 at 07:27:56AM -0500, Ken Williams wrote: > > > >This is simple, but I'm tired of rewriting it. Params::Validate can > >handle it, but I don't want to fire up a diesel engine when this is all > >I need. > > I wouldn't be so sure. Params::Validate is pretty nice for this kind > of thing, and has been tested for a long time. Before discounting it, > have you measured the actual resource impact? I would hope it would be fairly minimal, in it's mode of disabling validation: http://search.cpan.org/~drolsky/Params-Validate-0.78/lib/Params/Validate.pm#DISABLING_VALIDATION Mark
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: RFC - a module to generate README from POD
On Fri, Apr 29, 2005 at 12:16:40AM +0100, Robert Rothenberg wrote: > > =begin readmeinclude in README as POD > =begin readme podsame as above > =begin readme plain include in README as plaintext > > =for readme commands commands for the README parser, > some examples: > > =for readme stop stop including POD in readme > =for readme continue continue including readme > > =for readme include plain file > =for readme include pod file > include a plaintext or pod file > > =for readme include plain file mark > =for readme include pod file mark > include a text file until "mark" occurs? > > =for readme requirements insert a =head1 REQUIREMENTS section > which parses the META.yml for non-core > requirements > > =for readme install inserts a =head1 INSTALLATION section > which can tell if there's Makefile.PL, > Build.PL or both; also parses the > build_requires section of META.yml and > notes these I really don't want to do any extra work to generate the README file. Currently I'm happy with what Module::Build provides: create_readme This parameter tells Module::Build to automatically create a README file at the top level of your distribution. Currently it will simply use "Pod::Text" on the file indicated by "dist_version_from" and put the result in the README file. This is by no means the only recommended style for writing a README, but it seems to be one common one used on the CPAN. Beyond that, I wouldn't mind a little more boiler or auto-generated information, but I really want it to be That Easy. I would also just assume stick with what Module::Build provides unless the alternative was significantly better and just as easy. If your concern is about making a module that is widely used, I think it's important to find out: How much effort to do people usually want to put into a README file? Do they want the generation to be dead-simple / automatic, or are they willing to configure it more to have a more customized or powerful solution? I definitely fall into the first camp. 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: RFC: DBIx::Counter - Manipulate named counters stored in a database
On Thu, Apr 14, 2005 at 01:18:15AM +0200, Rhesa Rozendaal wrote: > > Here's my list of questions: > - what about the module name? is it good? > - code review would be nice > - documentation: clear enough? > - tests: for a module this simple? > - exception handling: should I do this myself, or let DBI throw them? > > The archive is here: http://www.rhesa.com/DBIx-Counter-0.01.tar.gz Rhesa, This looks extremely similar to DBIx::Sequence. http://search.cpan.org/~bbeausej/DBIx-Sequence-1.5/Sequence.pm I suggest updating your SEE ALSO section to mention this module, and list the key differences there. Mark
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/
Re: Should DSLIP codes be updated?
On Tue, Mar 29, 2005 at 03:49:50PM -0500, Ricardo SIGNES wrote: > * Robert Rothenberg <[EMAIL PROTECTED]> [2005-03-29T14:16:11] > > Some food for thought and debate. I'm wondering if the DSLIP codes [1] > > be updated, if revamped altogether. Note the following issues: > > I vote for "eliminated." I agree. I quit using them in my own modules because it's not clear that they are used for much at all. Perhaps they are used to 'browse' search.cpan.org (which I haven't done in years). If so, they are so widely ignored, that no one has bothered to classify any module as 'Pragma' or 'Perl6': http://search.cpan.org/modlist/Pragmas http://search.cpan.org/modlist/Perl6 Mark
Re: Parallel::Simple - bound args syntax
On Tue, Mar 01, 2005 at 02:40:36PM -0800, Ofer Nave wrote:
>
> # getting fancy with arg binding
> my @hosts = qw( foo bar baz );
> prun( map { my $host = $_; sub { test_host( $host ) } } @hosts )
> or die( Parallel::Simple::errplus() );
I think this is simpler, because I can guess what it does without
reading more documentation.
My idea of simple here is clarifying the call some:
my @host_tests;
for qw( foo bar baz ) {
push @host_tests, sub { test_host( $_ ) };
}
prun (@host_tests) or die( Parallel::Simple::errplus() );
It's not clear your code refs would interact with arguments that may
already be passed into them, before they get to prun().
It's also not 'normal' to mix hash and list calling styles, or to use a
code ref for a hash key.
In summary, I don't think the suggested addition would be 'simple'.
Mark
--
http://mark.stosberg.com/
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/
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
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: Module Name
On Sun, Dec 26, 2004 at 11:59:55AM +0100, Xavier Noria wrote: > > I don't see clearly the usage or purpose of the module from that > description. > > The module seems to be a source filter. One that allows the user to map > regular expressions from a given definition using rules. Those rules > can be joined into a Perl function that can be called..., I am lost. > > To get the picture. Can you give some usage example? Can you describe a > situation where the module can be useful? From that summary I would > expect kind of a wrapper of FILTER_ONLY regex => ... but then which is > the role of that function of joined rules? When would it be > constructed? Which code would use it? I'm curious about how it works, too. You can already map REs to REs using a simple hash. (I do it in Data::FormValidator). I imagine your module must be doing something more complicated. Mark -- http://mark.stosberg.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 Mon, Dec 06, 2004 at 07:53:01PM -0500, Matthew Persico wrote:
>
> And this, in fact is what I do at my place too.
>
> my $dbh = connectDBI(driver => 'Oracle', user => 'foo', server =>
> 'bar', database => 'baz'
> RaiseError => 1, PrintError =>0, AutoCommit => 0, driver_special =>
> {syb_show_sql =>1, syb_show_eed=>1});
Since you already have code like this, would like you to submit a patch
to DBI which works like this? :)
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: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Nov 30, 2004 at 07:38:34AM +, Terrence Brannon wrote: > > NAME > DBIx::DBH - Perl extension for simplifying database connections I suggest 'DBIx::DSN' as a better name, since database handles (DBH) are universally used in DBI-based projects. I like the idea, having written if/else chains in the past to solve the same problem. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: CPAN question
On Thu, Nov 11, 2004 at 11:17:50AM -0500, Sean Quinlan wrote: > > > > The underscore in the filename is the flag. (Its right there man! :) ) > > LMAO! If it had been a snake... > > Although maybe that should go into the PAUSE FAQ? It is in some FAQs, but apparently not the one you found. It's mentioned here, for instance: http://cpan.uwinnipeg.ca/htdocs/faqs/faq.html#03 Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
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: MySQL::Backup?
On Tue, Oct 26, 2004 at 02:22:53PM -0400, Christopher Hicks wrote: > On Tue, 26 Oct 2004, Smylers wrote: > >Chris Dolan writes: > >>Assuming it is based on DBI at its core, your module would fit better > >>in the DBI extension area. I think DBIx::Backup::MySQL would be good, > >>as it would leave room for expansions to databases other than ::MySQL. > > > >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. > > 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". Do we? It's not as if we find modules by walking down a namespace tree. Typically it's a keyword search. > The more I think about it DBIx would seem to be the winning > place for this sort of thing. I understood 'DBIx' to be "DBI extensions", which is not what this is. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: looking for Andy Wardley, AppConfig maintainer
On Sat, Sep 18, 2004 at 06:17:24AM -0400, Christopher Hicks wrote: > > I'm proud to say that I've gotten several programmers inside the National > Weather Service heavily using AppConfig. They've come up with a small > list of inconsistancies and possible bugs and a few missing features. > Having looked at the AppConfig source code I'm reasonably confidant that I > can make the changes cleanly, but it would seem to be smarter to get some > consent from the on-record maintainer before going to the trouble of > writing patches. I would go ahead and write the patches and publish them in the bug system for AppConfig: http://rt.cpan.org/NoAuth/Bugs.html?Dist=AppConfig Until the author pipes up, other people could find the patch there and use it and/or comment on it. Mark -- http://mark.stosberg.com/
Best Practice for renaming modules?
Hello, I'm seeking feedback on the best way to rename a CPAN module with an established user base. I was thinking of a process like this: 1. Release the module under the new name. 2. Make another release under the old name, leaving the functionality intact, but with a clear disclaimer near the top: "This is the last release under this name. Future development will happen under the name New::Name". Please use it when you write or update code." 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 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: 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 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: 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: 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/ . . . . . . . .
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=all&q=date&s=1&n=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: 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/ . . . . . . . .
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 . > > 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
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/
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 02:28:37PM -0200, Gabor Szabo wrote: > > > What I propose is: > > > My wish is to have a web forum where each module has its own category > and people can discuss the module, get help etc. without subscribing > to the specific mailing list of the module. Perlmonks sort of has this: http://www.perlmonks.org/index.pl?node=Module%20Reviews I say "sort of", because it's based on posting a a review, and then having comments below that review, so some comments apply to the module, while other comments are about the module. A Slashdot-style system would work better. The "story" would simply be the module name, and reviews could be posted as comments. The highest moderated reviews would become the most prominent. Maybe use.perl.org could help with something like this? 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: tables inside PDF
> I wonder if the openoffice format and libraries can be accessed > directly, that would be another way to produce arbitrary documents. To some degree, yes: http://search.cpan.org/~jmgdoc/OpenOffice-OODoc-1.106/ It seems this module could help you read and write the OpenOffice file format, but doesn't seem like it would help you convert it to/from PDF. I haven't tried it myself. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: [module-authors] tables inside PDF
On Wed, May 26, 2004 at 01:27:51PM +0530, Mohamed Parvez wrote: > Yes i am pretty much sure that there is no one module that lets me do > all 3 things > 1] Table > 2] Image > 3] Landscape size Have you looked at HTMLDoc? http://search.cpan.org/~mfrankl/HTML-HTMLDoc-0.07/lib/HTML/HTMLDoc.pm It clearly supports tables and landscape mode. The documentation indicates that it has some image support. I haven't tested how well that works myself. I have used it to transform HTML tables, and that works great. It can even run under mod_perl. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
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: getting rid of some unmaintained modules
On Sat, May 08, 2004 at 01:00:36AM -0200, Gabor Szabo wrote: > > I have released 3 modules to CPAN earlier, when I thought it is fun to > have some modules up there. Actually they don't do much there so I'd > like to get rid of them. > Two of them have never really worked so I can safely assume no one uses > them. I think I can just delete all of their copies from CPAN, right ? Right. I believe even if you delete them all from your directory, everything ever uploaded is still available on 'backpan': http://backpan.cpan.org/ ftp://pause.perl.org/pub/backpan/README Mark -- http://mark.stosberg.com/
Re: File::Path::Populate
On Wed, May 05, 2004 at 11:00:38PM -0500, Eric Wilhelm wrote: > Hi, > > I'm looking for a module which would operate similar to the following example. > If anyone has suggestions or feedback, I'd like to hear them. (I'd really > like to here "it's already been solved".) I recently implemented something like this using an MD5 hash, suggested by Randal Schwartz on perlmonks.org. It's perhaps too simple to make a module for, though: use Digest::MD5 (qw/md5_hex/); my $id = '123446'; my $ext = 'jpg'; my $md5_path = md5_hex($id); $md5_path =~ s|^(.)(.)(.).*|$1/$2/$3|; my $final_path = "$md5_path/$id.$ext"; My example depends on each file having a unique ID, which your case didn't. Perhaps you could use an MD5 of the file contents to generate unique strings for them, though. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.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)
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 (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: 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 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: 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 2>&1 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: 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 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 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: 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: Finding the module you want (was: New module Mail::SendEasy)
On Tue, Feb 10, 2004 at 09:59:32AM +0100, A. Pagaltzis wrote: > * Mark Stosberg <[EMAIL PROTECTED]> [2004-02-09 15:26]: > > 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. > > I like this proposition. However I'm just not sure I a) want it > used with no way to disable it b) want it used as the default. > > > This public prominence would also encourage more people to use > > the system, I believe. > > It would also encourage abuse, unfortunately. Not in my experience. I run http://www.skatepark.org/ , which allows for easy account sign up, at which point you can rate and review things. The most useful ratings and reviews are of the Skatepark developers. Skatepark contracts are typically for $100,000 or more, so selecting a skatepark contractor is a big deal. There was a lot of controversy when I launched the system. All the skatepark developers warned that their competitors would abuse it. Knowing some of their tactics and behaviors, I actually thought they might. :) But I was willing to try. That's been in place for some years now, and I personally look at all the ratings. I have no sense that the system has ever been abused. Sometimes people may rate themselves (once!). But that happens even less than with Perl module authors!. Sometimes I think developers ask clients to rate them, but the reviews seem fair enough, and I think that is reasonable. With Perl modules, I think there is typically less on the line than $100,000 contracts. I found in my own experience that people are generally trustworthy. I think it would be quite sufficient to have some way to flag reviews (or users) that appear to be abusive. From another angle, I see the current problem with the rating system is not abuse-- I've never noticed any beyond people rating their own modules with 5 stars with reviews like "It's my module". It's primary downfall now is that it's simply not being used a lot. Making further barriers to using it would only serve to work this worse. If the system is highly used and slightly abused (say 1%), the ratings should still remain useful. 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 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: VERSION as (interface,revision) pair and CPAN++
On Thu, Jan 29, 2004 at 07:04:52PM +, Adrian Howard wrote: > > On Thursday, January 29, 2004, at 04:08 am, Lincoln A. Baxter wrote: > > >Phew... Only one comment: KISS (Keep It Simple Stupid) > [snip] > >No fancy versioning emnumeration scheme can replace this testing, and > >what we have now works "well enough" (I think). Most module authors I > >think are pretty good about documenting what they change in the Changes > >file. > > Amen to that :-) I like simplicity as well. However, sometimes as a module author I made bad decisions, or don't have the foresight to see how the module will evolve. Thus, to create a "best" version of the interface would mean breaking backward compatibility in a number of ways. I think if the fundamental versioning scheme of Perl and CPAN supported that, I would be more courageous about making those kinds of changes, providing a better solution for old and new users. As it is, I tend to favor keeping backwards compatibility, which leaves some cruft exposed in modules. Perhaps the right kind of interface declaration system would help with this. Or maybe people have other ideas on what to do when the best design for the future is not backwards compatible? Mark -- http://mark.stosberg.com/
Re: New module Mail::SendEasy
On Mon, Jan 26, 2004 at 02:25:19PM -0600, Dave Rolsky wrote: > On Mon, 26 Jan 2004, Orton, Yves wrote: > > > But I suppose if people wanted it I could look into releasing such a beast. > > Or Graciliano could just include with the app he's distributing. That > makes a lot more sense. That's more what I want it mind. The MIME::Lite standard distribution would be unaffected, but another option would be available, at least for this one use. Isn't this kind of packaging sort of what the "PAR" project is about? http://www.perladvent.org/2003/25th/ 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? 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
cpan name spaces (was: Re: Re3: Re: How about class Foo {...} definition for Perl? )
On Mon, Jan 19, 2004 at 07:14:19AM -0600, Chris Josephes wrote: > > I think sooner or later, we're all going to have to bite the bullet and go > with Java class naming conventions, like > > org::simon-cozens::MVC > > or maybe Larry's recommendation of using CPAN id as a top level. > > simon::MVC (or maybe au::simon::MVC) > > Otherwise, CPAN will continue to grow wide at the top level. 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. I tend to look for new modules by keyword search anyway. I don't feel like I can depend on looking in any top-level name space and expect to find all the modules that belong there. Also, as long as names are sufficiently descriptive, I would just assume they be shorter, rather than having fewer top-level name-spaces with longer names. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: RFC: CGI::UploadDB
On Mon, Jan 12, 2004 at 09:38:27PM -0500, David Manura wrote: > Hi Mark, > > Taking a scan though this. The first issue concerns how the > documentation is is put forth. It's not quickly clear to me what the > module does. At first glance I thought "CGI::UploadDB - Manage CGI > uploads using SQL database" meant is was a module for automatically > uploading/replicating database tables from one database to a remote > database on your web site via CGI (probably because I recently wrote > that). The word "manage" itself in imprecise, especially when "using > SQL database" could modify either "CGI uploads" or the "management of > CGI uploads." Thanks for the thorough review David. I think I will add a "Tutorial" section to the documentation that will make the module easier to understand how it works and address many of your concerns. 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/ . . . . . . . .
Naming help for upload management system
Hello, I'd like to get some naming comments on a module I'm interested in uploading to CPAN. The working name I have now is "CGI::MediaDB". Working with Data::FormValidator and CGI.pm, it makes it easy to manage file uploads with the meta data stored in a SQL database (Postgres and MySQL are supported), with the actual files stored on the file system. A single function will create any needed thumbnails, and write out all files to the database and file system. There are also functions to remove files (from the filesystem and DB) based on web-form input. Finally, it create a hashref for a file, suitable for giving to a templating system for display and linking. I've mostly used it with images so far, but arbitrary file formats are supported. I chose to use the CGI top-level namespace because it does rely on a CGI.pm-compatible object to work. "MediaDB" seemed like a decent way to describe it provides functions relating to mananging a database of files. CGI::UploadDB perhaps is an even better match, since the files don't have to be "media" files. My working documentation is here: http://mark.stosberg.com/perl/mdb.html I plan to also write a tutorial to clarify things even further. Mark -- http://mark.stosberg.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: RFC: Date::Iterator
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. 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: ExtUtils::MakeMaker or Module::Build
On Wed, Nov 19, 2003 at 11:34:38PM -0500, Lincoln A. Baxter wrote: > > But as we start to put this together we run across Module::Build. In > the past I have always used ExtUtils::MakaMaker. Is there a preference > (if one were starting from scratch), to using one over the other? I maintain Data::FormValidator and switched to using Module::Build. I find it much easier and more intuitive to work with. I've gotten very few complaints from users about the switch. I recommmend evaluating it yourself. 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: 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 08:57:28AM -0500, [EMAIL PROTECTED] wrote: > > Original Message: > - > From: Struan Donald [EMAIL PROTECTED] > > > And if you're including the code in several CPAN modules then > > shouldn't the code be up to standard for general use? Just because you > > can't see anyone wanting to use it doesn't mean it shouldn't be > > documented. > > The code is fine, it's quite simple and doesn't really need docs, however I > don't really want anyone else using it because then it becomes a > responsibilty. There are plenty of similar modules contained within > existing distributions. They are not polished, have no pod etc. They are > only to be used from within the distribution itself and only need to be > understood by people changing the distribution in question. I don't think > this bothers people too much. My module is like these, it has previously > shipped inside another distro, undocumented, unexposed. I want to use it > with several other modules but I don't want to cut and paste. 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". It seems like the concern related to "MethodMaker" is similar. I also agree that "Authors::" seem ripe for abuse-- The point of CPAN is to share code. If good re-usable code starts to squirrelled aware in Authors:: where it's hard to find, this community system has lost some value. 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: sub-packages for object-oriented modules
On Sat, Oct 04, 2003 at 02:34:14PM -0400, James E Keenan wrote:
>
> .. that package Drawing is so huge that it's cumbersome to edit and you simply want
> to store some of its publicly callable methods in other packages. If so, then you
> could simply import the methods from the "sub"-modules using Exporter.
>
>package Drawing;
>use Drawing::Manipulate qw(Move Copy);
>use Drawing::Defined;
>...
>
>package Drawing::Manipulate;
>use Exporter;
>@ISA = ("Exporter");
>@EXPORT = qw(Move Copy);
While this is certainly more explicit, it also means that every time
you create or rename a shared routine, you have to declare and at least
two places. Perhaps being explicit is it's own reward. I know I've found
that maintaining export/import interfaces between highly related modules
to be cumbersome at times.
I can't see I have a better pattern to suggest for this case, rather
it's a question I've run into myself and haven't fully resolved.
Mark
--
http://mark.stosberg.com/
Re: creating a standard Perl module
On Wed, Oct 01, 2003 at 11:48:20AM -0500, Eric Lease Morgan wrote: > > My Perl Cookbook says I should use this command to initialize my project: > > h2xs -XA -n MyLibrary Eric, Here's a related recommenation. I recommend trying 'modulemaker' as more pleasant alternative to h2xs. Install ExtUtils::ModuleMaker, which includes the modulemaker binary. However, both techniques will produce a similar set of resulting files, so this doesn't directly address your question. I don't know of a slick solution o generate lots of boilerplate modules without generating a bunch of distribution framework as well. If you are thinking of your collection of modules as a group that would be distributed or used only as a collection, I would run h2xs or modulemaker just once. Then you could copy the contents of the boiler plate ".pm" file that's generated, changing references to the name as needed. Perhaps someone else will know a better solution and enlighten us both. :) Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: ExtUtils::MakeMaker PL_FILTER option
On Wed, Sep 10, 2003 at 09:31:58AM -0700, Robert Lehr wrote: > ...I do not see a good reason that these filters should spawn a separate process > to execute a regex for every filter for every file. > > Why not implement "the traditional unix sense" filter in perl? Or change the > module to do it in "the traditional perl sense". > > Or provide the option to do it with either method. I think you're right that there could be better way to do this, such as in "pure perl". This is one of the benefits of Module::Build. Since M::B uses regularly Perl scripts for the Makefile equivalent, you could just use File::Find and standard perl techniques to find and process files. No extra function would be needed. (Although some kind of syntactic sugar could still be desirable). Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: ExtUtils::MakeMaker PL_FILTER option
On Wed, Sep 10, 2003 at 05:14:21AM -0400, Kevin C. Krinke wrote:
> I have submitted a wish-list bug-report at rt.cpan.org for
> ExtUtils::MakeMaker regarding a compliment option to the PM_FILTER
> option for Perl Module files called PL_FILTER.
>
> I would like to get everyone else's opinions on the matter as well.
>
> If you don't have any idea as to what PL_FILTER would do, read the
> following POD and think of a ".pl" script instead of a ".pm" (or even
> ".PL") script.
How about a more general solution that allows to define a filter, as
well which kinds of files it applies to? For example, covering ".pl" and
".PL" doesn't cover ".cgi", or binaries that get installed without an
extension.
In Data::FormValidator, I addressed something like this by using a
regular expression as a hash key. I thinking of the following kind of
syntax:
FILTER_MAP => {
qr/.pm$/ => 'grep ...', # like PM_FILTER
qr/.pl$/ => 'grep ...', # like PL_FILTER
qr/.cgi|my_binary/ => 'grep ...', # ...very flexible
},
In Data::FormValidator, there's also code to support this
kind of syntax for older Perl's without "qr". It uses an RE to match
an RE. It looks more hackish than just supporting 'qr', but it works
reliably in that application.
I'd rather see something like this than a proliferation of "_FILTER"
options tied to different extensions.
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
