Re: The passing of Spider Boardman
Sad news indeed. It's even more painful considering that the numbers of the infection are sinking but he could not benefit of it. My condolences to the family. -- bronto Il Mer 26 Mag 2021, 02:34 Neil Bowers ha scritto: > I’m sad to have to report that Raun "Spider" Boardman (SPIDB on CPAN) has > recently passed away, due to complications of COVID. > > Spider released several distributions to CPAN, one of which (Net::Dnet) is > still there. It looks like he tidied up older things. > > Spider originally worked at Digital, where his daughter told me he worked > on Unix (and presumably then Ultrix), and then stayed through acquisitions > by Compaq and then HP, where he had worked on security. > > Looking at early Perl 5 releases, I found that he not only contributed bug > fixes to Perl itself, but was also contributing tweaks to hints files as > well. > > Neil >
Re: rt.cpan.org is going away
Thanks for the effort you guys put into this Ciao -- bronto On Fri, 19 Mar 2021, 12:03 Aaron Trevena, wrote: > Hi All, > > As some of you may have noticed - rt.cpan.org hasn't gone away and has > been upgraded to RT5 with help and support from best practical - no > mean feat given the age and customisations of the cpan RT instance. > > It's looking nicer and much easier to use. > > Kind regards, > > A. > > On Thu, 21 Jan 2021 at 14:41, Paul "LeoNerd" Evans > wrote: > > > > > > > > rt.cpan.org, the bugtracker used by nearly 80% of all CPAN modules > > [1], is going to be shut down on 1st March this year [2]; 39 days > > from when I write this email. > > > > > > > > I am rather concerned about this, as there doesn't appear to be any > > sort of co-ordinated bailout plan or migration of the *huge amount* of > > CPAN modules this is about to affect. > > > > I am furthermore concerned at the total lack of discussion or response > > that has so far been generated; aside from Karen Etheridge I haven't > > seen any noise of upset being generated at all. Nor am I aware of any > > sort of effort to handle what will become a huge outage of a major > > component of the CPAN ecosystem. > > > > I personally have 189 modules in need of migration - somehow. As yet > > I have no clue what I am going to do about it. Existing bugs need to be > > moved somewhere else (and I have no clue how I'm going to fix up URLs > > that currently point to those, in code comments, documentation, blog > > posts, ... anywhere else), and a new for users to report new bugs needs > > to exist. Of special note are the numerous "in progress" tickets I have > > across my distributions, containing ongoing discussions about design > > issues and the like. To say that I am "concerned" is an understatement; > > I am fairly close to panicing about this. > > > > I am quite sure I am but the smallest tip of the iceberg here. Every > > time I mention it on Freenode's #perl or irc.perl.org's #p5p there are > > always new folks who were totally unaware of this fact. This is going > > to hit lots of people in a very hard surprise. > > > > I am therefore interested to know if anyone has any sort of thoughts or > > plan on what to do about this; either > > > > a) Attempts to take over maintenance of the system as it stands, or > > > > b) Find an alternative location and implement some sort of > > mass-bailout in that direction. > > > > > > To emphasise again: in 39 days time the bug tracker used by nearly 80% > > of all of CPAN is going to be shut down and become unavailable for > > either historic or newly-reported bugs. We *need* to find a solution in > > that time. It would be great if we all went the same way, thus making > > the lives of users (and metacpan.org) a lot simpler, rather than all > > scattering in 50 different ways, which will cause a huge splintering of > > what has been a very coherent service so far. > > > > > > 1: Add the "known to be RT" and "unknown" categories of > >https://cpan.rocks/; because metacpan.org defaults to RT in the > >latter case. > > > > 2: https://log.perl.org/2020/12/rtcpanorg-sunset.html > > > > -- > > Paul "LeoNerd" Evans > > > > leon...@leonerd.org.uk | https://metacpan.org/author/PEVANS > > http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ > > > > -- > Aaron J Trevena, BSc Hons > http://www.aarontrevena.co.uk > LAMP System Integration, Development and Consulting >
Re: Help w/ naming module
On 21/09/17 23:11, Karen Etheridge wrote: > Given that there is so much prior art in this space already -- is it > useful to release one more variant to the CPAN, vs. simply keeping it in > your darkpan? Is anyone likely to discover your module and choose it > over any other? For what is worth, I disagree with this approach. I have released a few tiny modules on CPAN, not because they were incredible pieces of software but in the hope that someone besides me would find them useful. As far as I/Google can tell, they are being used here and there, they are making other people's lives easier: that's a good enough reason to make them public. Sure, they will *never* reach the numbers of the greatest CPAN stuff out there: so what? > Please at least give a summary of the alternatives and how they differ, > in the documentation. This one, I can agree with. @Diab: please go ahead. Be sure to choose the right namespace based on the good advice you got here. Good to add the information suggested by Karen, too. Ciao -- bronto
Re: Mocking Net::Ping's ping method
Watch out Matthew, your module is showing up with the name of "v0.09" currently. Check your code. https://metacpan.org/release/MMUSGROVE/v0.09 Ciao -- bronto
Re: The module authors pledge
Il 08/11/2011 17:22, Neil Bowers ha scritto: > Should I die, then the time-limits in (1) and (3) do not apply. Drop this, as difficult to verify (for various reasons), and +1 from me. -- bronto
Re: Why are you releasing modules to CPAN?
Gabor Szabo ha scritto: > So why do *you* contribute to CPAN? Some years ago I released three little modules to CPAN. There's no great code in them, but I hoped that they could be useful to other people. Being helpful to others is the only reason why I hold myself up to public scorn :) Ciao --bronto
Re: HOW-TO for publishing a perl module?
Tim Bunce wrote: > But I'm sure there's decent docs somewhere with more details of 'best > practice' so I'm CC'ing this to module-authors@perl.org (not least > because I'll being uploading a new module myself soonish). What about "Writing Perl modules for CPAN" by Sam Tregar? Ciao --bronto
Re: Hash::HasKeys
Ovid ha scritto: > It's almost embarrassing to upload a Hash::HasKeys module to the CPAN, > but I rewrite this code *all* the time (and always forget about "die if > extra_keys()"). Before I embarrass myself by writing and uploading > something so simple and special-purpose, tell me there's something out > there already ... I uploaded Date::Calc::Iterator on CPAN, and if you read the code or the docs you'll notice that it is a trivial module. But there was none on CPAN that could do the same simple task in the same simple way, so I put it there; if it will be useful to someone, I'll be happy, if not, well: I did not lose anything publishing that. Come on Ovid, we know that you are a great Perl programmer, we won't be deceived if we see that little piece of software online :-) Don't worry too much about and put it in!!! :-) Ciao --bronto
Re: Fields in Makefile.PL
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 Cheers --bronto
Re: Date::Iterator, pollution, rating system, and how to make CPAN a better place [was: Re: RFC: Date::Iterator]
Happy new year A. Pagaltzis wrote: If you're gonna go that route and put Day in the name but as a separate namespace level, it should be Date::Calc::Iterator::Day so there isn't a new 3rd level namespace for every date iterator module with only one 4th level name in it. I read all the comments, with this one last. I see your reasons. If Steffen Beyer allows me to do so, I'll call the module Date::Calc::Iterator::Day, implement many of the proposed changes I had here and put it on CPAN. Thanks to everybody for the time you took to discuss this module. Ciao Marco -- Marco MarongiuEmail: [EMAIL PROTECTED] System Administrator Phone: +39 070 460 1684 Tiscali S.p.A.Fax: +39 070 460 9684 International IT Services
Date::Iterator, pollution, rating system, and how to make CPAN a better place [was: Re: RFC: Date::Iterator]
Oh my, oh my... what a mess! :-) Ok, it's time to have a few conclusions about this discussion. Some of these conclusions are more general than my module and involve the CPAN as a whole. Some like my module, some don't. Some would like to see it on CPAN, some don't. About *not putting* it on CPAN, the main reasons are: * there is already DateTime::Event::Recurrence that does the same job and a lot more with a standardized interface * the presence of many modules that do the same job leads to diluition of efforts and lowers the usefulness of CPAN * DateTime modules are designed to work together, mine isn't designed to work with anything * Date::Iterator is not easier than DateTime::Event::Recurrence and is much less flexible than it About *putting* it on CPAN: * Some people liked it * it's simple * it's useful And, last, there is a proposal to rename it to Date::Calc::Iterator (did I miss anything?) Now: I didn't find DateTime::Event::Recurrence on CPAN when I was looking for a solution for my problem, but I have to say that even if I had a clear and clean explaination like the one that Rick Measham gave on this list, I'd probably coded my module anyway. I have the feeling that the time I spent to write the module (not a lot, indeed: it took more time to document it than to write it) was far less than I had to learn the DateTime thing. The impression I get from the DateTime::Event::Recurrence is that even if you need to accomplish a simple task, you have to learn a lot about the DateTime framework, which is the exact contrary of the Perl philosophy as a whole: it is stated somewhere (the Camel Book? The Llama book?) that you can learn a few Perl to begin to make something useful with it. My impression could well be wrong. But, in that case, there is something wrong also in how the DateTime modules are explained and documented. About CPAN pollution, I feel that pollution as a wealth. The solution to that could be the recently added feature of rating modules, but we should have a "sort by rating" on search.cpan.org to make it more useful. Besides, there are good reasons to require a registration before you can rate a module, but the tradeoff is that not many people are rating modules at this time... The possibility of rating a module should be advertised by the CPAN module itself after a successful installation, IMHO (or does recent versions already do it?). Diluition of efforts is a real problem in CPAN, but not in this case: since there is DateTime::Event::Recurrence I had nothing to do to add this functionality to the DateTime project, nor I could contribute in any other way. My module *doesn't* want to be flexible. About the name thing, I'd call it Date::Calc::Iterator: * if my module was a subclass (like I did with Net::LDAP::Express) * if the "parent namespace" was needed to clearly illustrate what the module does (like I did with Data::Password::BasicCheck; it's not a subclass of Data::Password, but I felt that it was the right namespace to put a module that does basic password checking; moreover, Data::BasicCheck meant nothing!) Date::Iterator is not a subclass of Date::Calc: it *uses* it; and Date::Calc as a namespace for my module is just confusing: my modules Iterates over Dates, fullstop. The "Calc" part is confusing. For the reasons written above, I'd put Date::Iterator on CPAN after stating clearly in the docs that: * it *depends* on Date::Calc * there is already DateTime::Event::Recurrence that does this sort of things, and can do a lot more But before doing it I'll wait for more comments about this message. Maybe I am totally wrong, and you have good argumentations that will make me change my mind. Thank you for the time you spent in this discussion so far Ciao Marco
Re: RFC: Date::Iterator
Michel Rodriguez wrote: Polluting CPAN with modules that duplicate existing functionalities is definitely NOT responsible behaviour, especially in areas like Date:: and Time:: where there is already much confusion, and an coordinated effort to fix that confusion through DateTime:: In your case why not see if you can write a patch to one of the DateTime modules that would give you an interface similar to what you wrote? Dear Michel First of all, thanks for your advice. As I said in my first mail, Date::Iterator came out to solve a problem I had at work. And as it happened to you, I decide to write a new module after a lot of searching into cpan. DateTime modules didn't come out from those searches, unfortunately. But, as Dave Rolsky recognized, even if I found them the documentation itself doesn't encourage people to use it for simple tasks... Could I contribute to the DateTime project? I think I can't. Working with calendars and times would require me an effort bigger than I can take. If you look at the module code, it am just plain using a single function from a single module (Date::Calc): I have no experience on doing things like that myself. Proliferation of modules on CPAN is evil? Maybe. Maybe not. It could create confusion, you are right. But... well, I'll say in italian: "Cio` che hai in piu` non ti impoverisce"; I don't have a good translation in english, but it could sound like "things you got and don't need don't make you poor". It's a natural selection process: people search for modules that do the job, read the docs and make a choice. If my module is bad, they simply won't use it. Instead of hiding my module in my insignificant website, wouldn't it be better to write on top and bottom of the docs an advice like "this is a small module and does a few things; you probabily want to take a look at DateTime and DateTime::Event::Recurrence <http://datetime.perl.org>"? Waiting for a new advice... Ciao and thanks again --bronto -- Marco MarongiuEmail: [EMAIL PROTECTED] System Administrator Phone: +39 070 460 1684 Tiscali S.p.A.Fax: +39 070 460 9684 International IT Services
Re: RFC: Date::Iterator
Dave Rolsky wrote:
Really? But with DateTime::Event::Recurrence you very easily generate
these types of sets. For example, for a set of dates one per day:
use DateTime;
use DateTime::Event::Recurrence;
my $start = DateTime->new( year => 2003, month => 10, day => 3 );
my $end = DateTime->new( year => 2003, month => 11, day => 10 );
my $daily = DateTime::Event::Recurrence->daily( start => $start, end => $end );
while ( my $dt = $daily->next ) { ... }
How hard is that?
my $i = Date::Iterator->new( from => [2003,10,3], to => [2003,11,10] ) ;
while (my $day = $i->next) { ... }
Is this harder?
What does your module offer that makes it worth _not_ getting all the
other features DateTime.pm offers, like useful time zone support, lots
of formatting & parsing options, the ability to do set math on sets
(union, difference, intersection, etc.)?
Maybe the fact that I don't need all the other features?
However, I think the docs for DT::Event::Recurrence need some work,
because I don't the fact that you can do easy stuff with it is obvious.
--
Is there a "think" missing?
Anyway, I agree with you: from the docs you have the feeling that all
the framework is a lot complicated...
Ciao
--bronto
--
Marco MarongiuEmail: [EMAIL PROTECTED]
System Administrator Phone: +39 070 460 1684
Tiscali S.p.A.Fax: +39 070 460 9684
International IT Services
Re: RFC: Date::Iterator
Mark Stosberg wrote: 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. Good point :-) Is on my notepad now! Thank you Ciao --bronto -- Marco MarongiuEmail: [EMAIL PROTECTED] System Administrator Phone: +39 070 460 1684 Tiscali S.p.A.Fax: +39 070 460 9684 International IT Services
Re: RFC: Date::Iterator
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. Mine covers just one case. Ciao --bronto -- Marco MarongiuEmail: [EMAIL PROTECTED] System Administrator Phone: +39 070 460 1684 Tiscali S.p.A.Fax: +39 070 460 9684 International IT Services
Re: RFC: Date::Iterator
[EMAIL PROTECTED] wrote: On Fri, 19 Dec 2003, Marco Marongiu wrote: Date::Iterator - Iterate over a range of dates I like it! Thanks Josh! I recently needed to handle the same thing, but also needed to be able to handle hourly steps. Would it be possible to add support for something like the following: my $i1 = Date::Iterator->new(from => [2003,12,1,10], to => [2003,12,10,23] ); and have it return arrays (or refs) with [,mm,dd,hh] back? This could also be expanded in both directions, to handle: my $i1 = Date::Iterator->new(from => [2003,12], to => [2004,3] ); and: my $i1 = Date::Iterator->new(from => [2003,12,1,10,6], to => [2003,12,2,3,55] ); The latter to be a range of minutes from 2003-12-01 10:06 to 2003-12-02 3:55. I realize that probably wasn't your origonal intention at all, but that would be really handy. BTW - I'd be happy to contribute to Date::Iterator to add support for the above type of scenarios if you'd like. Yes, please, do it :-) You are right, your modification goes far beyond the scope of my work, but I'd be really happy to see that someone takes my code as a base to go one step further. Could we discuss in private on the release plan? Thank you! Ciao --bronto -- Marco MarongiuEmail: [EMAIL PROTECTED] System Administrator Phone: +39 070 460 1684 Tiscali S.p.A.Fax: +39 070 460 9684 International IT Services
Re: RFC: Date::Iterator
Andy Wardley wrote: Marco Marongiu wrote: NAME Date::Iterator - Iterate over a range of dates Nice! Thanks Andy! $i = Date::Iterator->new( from => [2003,12,1], to => [2003,12,10] ) As a matter of convenience, can I suggest that in addition to list references you also allow dates to be specified as strings? $i = Date::Iterator->new( from => '2003/12/1', to => '2003/12/10' ) Something like this should do the trick: $date = ref $date eq 'ARRAY' ? $date : [ split(/\D+/, $date) ]; If you split on any non-digit characters then it allows for different formats like '2003/12/1', '2003-12-1', '2003 12 1' and so on. Yup! Really nice idea! I'll go for it!!! Thanks a lot --bronto -- Marco MarongiuEmail: [EMAIL PROTECTED] System Administrator Phone: +39 070 460 1684 Tiscali S.p.A.Fax: +39 070 460 9684 International IT Services
RFC: Date::Iterator
Ciao a tutti
I created the module in subject for an application I had to create for
my job. I am planning to release it on CPAN
I already started to get some reviews from italian perl mongers, I would
also like to have yours.
Below you have the man page I wrote so far.
You can also download the module for testing it from
http://bugs.unica.it:/modules/
Cheers
--bronto
NAME
Date::Iterator - Iterate over a range of dates
SYNOPSIS
use Date::Iterator;
# This puts all the dates from Dec 1, 2003 to Dec 10, 2003 in @dates
# @dates will contain ([2003,12,1],[2003,12,2] ... [2003,12,10]) ;
my $i1 = Date::Iterator->new(from => [2003,12,1], to =>
[2003,12,10]) ;
my @dates1 ;
push @dates,$_ while $_ = $i1->next ;
# Adding an integer step will iterate with the specified step
# @dates will contain ([2003,12,1],[2003,12,3] ... ) ;
my $i2 = Date::Iterator->new(from => [2003,12,1], to =>
[2003,12,10], step
=> 2) ;
my @dates2 ;
push @dates,$_ while $_ = $i2->next ;
ABSTRACT
Date::Iterator objects are used to iterate over a range of dates,
day by day or with a specified step. The method next() will return
each time an array containing ($year,$month,$date) for the next
date, or undef when finished.
DESCRIPTION
new
Creates a new object. You must pass it the end points of a date
interval as hash references:
$i = Date::Iterator->new( from => [2003,12,1], to => [2003,12,10] )
"from" and "to" are, obviously, required.
Optionally, you can specify a custom step with the "step" key, for
example:
$i = Date::Iterator->new( from => [2003,12,1], to => [2003,12,31],
step => 7 ) ;
will iterate on December 2003, week by week, starting from
December 1st.
next
Returns the next date; in list context it returns an array
containing year, month and day in this order, or "undef" if
iteration is over; in scalar context, it returns a reference to
that array, or "undef" if iteration is over.
HISTORY
0.01Original version; created by h2xs 1.22 with options
-CAX
-b
5.6.0
--use-new-tests
--skip-exporter
-O
-v
0.01
Date::Iterator
SEE ALSO
The wonderful Date::Calc module
AUTHOR
Marco Marongiu, <[EMAIL PROTECTED]>
COPYRIGHT AND LICENSE
Copyright 2003 by Marco Marongiu
This library is free software; you can redistribute it and/or
modify it under the same terms as Perl itself.
