Re: bigint 5.6 vs 5.8
# The following was supposedly scribed by
# Dave Rolsky
# on Monday 21 June 2004 10:55 pm:
>Maybe, but the DateTime.pm code includes DateTime::Infinite, and this has
>all sorts of problems too.
Well, Math::BigFloat seems to work really well in this case. I just think it
could use some more overloading.
my @slopes = map({Math::BigFloat->new(abs(slope(@$_)))->ffround(-3)} @edges);
This just makes everything into a BigFloat, so if you multiply any of them my
5 or -1 later, they stay a bigfloat as long as they don't get stringified
first (e.g. as long as they stay blessed.)
--Eric
--
I arise in the morning torn between a desire to improve the world and a
desire to enjoy the world. This makes it hard to plan the day.
--E.B. White
Re: bigint 5.6 vs 5.8
On Mon, 21 Jun 2004, Eric Wilhelm wrote: > Oh well. I'm the only person in the world doing computational geometry with > perl anyway right? Maybe, but the DateTime.pm code includes DateTime::Infinite, and this has all sorts of problems too. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: bigint 5.6 vs 5.8
# The following was supposedly scribed by # Ken Williams # on Monday 21 June 2004 10:36 pm: >In my limited understanding, it's not really anything to do with how >perl is compiled, it's something about your underlying libc libraries. >Perl just detects whether your libc supports it, then gives you NaN and >Inf and such. Apparently the way it detects it changed between 5.6 and 5.8 because I built all eight (or 9) of these tonight on this machine: $for i in perl-* > do ls $i/perl && \ > $i/perl -le '$a = NaN; print "No NaN support here" if $a == $a' > $i/perl -le '$a = NaN; print "NaN support here" if $a != $a' > done perl-5.6.1/perl NaN support here perl-5.6.2/perl NaN support here perl-5.8.1/perl No NaN support here perl-5.8.2/perl No NaN support here perl-5.8.3/perl No NaN support here perl-5.8.3-atof/perl No NaN support here perl-5.8.4/perl No NaN support here perl-5.9.0/perl No NaN support here perl-5.9.1/perl No NaN support here I'm perplexed, but I'm not about to let a little regression stop me from moving forward. Besides, with Math::BigFloat we can divide by zero without error (maybe we can get that into the core as the default behavior in Perl6?) --Eric
Re: bigint 5.6 vs 5.8
On Jun 21, 2004, at 4:38 PM, Eric Wilhelm wrote: So, it's not my current system, but the state of the system on which perl was compiled? The 5.6.1 was a RedHat rpm, while the 5.8.3 is a .deb, but I'd happily build lots of things from scratch here if it would get this working again. If that's the case, what provides this support? All I'm seeing in the pods are "Infinity is now recognized as a number." since 5.6.1, but not how to enable it. Install some library and re-compile? Compile with some specific flags? In my limited understanding, it's not really anything to do with how perl is compiled, it's something about your underlying libc libraries. Perl just detects whether your libc supports it, then gives you NaN and Inf and such. There's a tiny bit about this in 'perldoc perlop' (search for NaN), and a somewhat troubling statement in 'perldoc perltodo'. Might be fruitful to poke around in the main Configure script, to see how the detection is done. -Ken
Re: bigint 5.6 vs 5.8
# The following was supposedly scribed by # Steve Grazzini # on Monday 21 June 2004 08:53 pm: >I believe this is because 5.6 used the C library atof() but more >recent perls provide their own portable implementation. Or maybe >the internal atof() didn't used to be the default, but now it is. > >Check the comments around USE_PERL_ATOF in perl.h. Thanks for the tip, but configuring with -DUSE_PERL_ATOF=0 isn't giving anything different. I think I'll just have to dig into Math::BigFloat and do everything that way. I suppose I'm probably better off that way, since the perl 5.6 behavior wasn't documented as such, so I'm not sure if it would have worked that way on other platforms. Oh well. I'm the only person in the world doing computational geometry with perl anyway right? Thanks, Eric
Re: bigint 5.6 vs 5.8
On Monday, June 21, 2004, at 09:04 PM, Eric Wilhelm wrote: In 5.6.1 and 5.6.2, any flavor of "inf" got converted to 'inf' and the math worked beautifully. I'm not saying that I agree with "infinity" eq "inf" eq "Infinity", but it sure beats the inf == 0 that we have now. I believe this is because 5.6 used the C library atof() but more recent perls provide their own portable implementation. Or maybe the internal atof() didn't used to be the default, but now it is. Check the comments around USE_PERL_ATOF in perl.h. -- Steve
Re: bigint 5.6 vs 5.8
# The following was supposedly scribed by # [EMAIL PROTECTED] # on Monday 21 June 2004 07:29 pm: >Note that the stringification of inf varies >a lot between systems - you have to take >this into account when writing tests: It's not the stringification that's bothering me, it's the de-stringification (conversion from a string to a number.) $for i in perl-*; do ls $i/perl && $i/perl -le ' $a = shift; $a += 1; print $a; $a = abs($a); print $a; print int($a); print $a + $a; ' Infinity ;done perl-5.6.1/perl inf inf inf inf perl-5.6.2/perl inf inf inf inf perl-5.8.1/perl 1 1 1 2 perl-5.8.2/perl 1 1 1 2 perl-5.8.3/perl 1 1 1 2 perl-5.8.4/perl 1 1 1 2 perl-5.9.0/perl 1 1 1 2 perl-5.9.1/perl 1 1 1 2 In 5.6.1 and 5.6.2, any flavor of "inf" got converted to 'inf' and the math worked beautifully. I'm not saying that I agree with "infinity" eq "inf" eq "Infinity", but it sure beats the inf == 0 that we have now. --Eric -- "Matter will be damaged in direct proportion to its value." --Murphy's Constant
Re: infinity in 5.6 vs 5.8
# The following was supposedly scribed by
# Eric Wilhelm
# on Monday 21 June 2004 05:48 pm:
>More fun with this:
Okay, I cannot get perl-5.6.1 to build out-of-the-box (some problem with
makedepend script and , etc) (I suspect that RedHat did a little of
what they do when they shipped it?)
Anyway, this is seven different releases, and nothing from 5.8+ has the
infinity handling that 5.6.2 does:
(5.8 and later require you to 'use bigint' to make this work)
$ for i in perl-5.8* perl-5.9*
do ls $i/perl && \
$i/perl -I$i/lib -le 'use bigint; $a = shift;
print (($a+1 == $a) ? "inf support here" : "no");' inf
done
perl-5.8.1/perl
inf support here
perl-5.8.2/perl
inf support here
perl-5.8.3/perl
inf support here
perl-5.8.4/perl
inf support here
perl-5.9.0/perl
inf support here
perl-5.9.1/perl
inf support here
(so it stringifies correctly, but it won't sprintf)
$ perl-5.6.2/perl -e '$a = shift;printf("%0.2f\n", $a);' inf
inf
$ for i in perl-5.8* perl-5.9*
do ls $i/perl && \
$i/perl -I$i/lib -e 'use bigint; $a = shift;
printf("%0.2f\n", $a);' inf
done
perl-5.8.1/perl
0.00
perl-5.8.2/perl
0.00
perl-5.8.3/perl
0.00
perl-5.8.4/perl
0.00
perl-5.9.0/perl
0.00
perl-5.9.1/perl
0.00
(but it's still not as consistent as it was in 5.6)
$ perl-5.6.2/perl -le '
print join(" ", sort({$a <=> $b} map({abs($_)} @ARGV)));
' inf -inf 0 1
0 1 inf inf
$ for i in perl-5.8* perl-5.9*
do ls $i/perl && \
$i/perl -I$i/lib -le 'use bigint;
print join(" ",
sort({$a <=> $b} map({abs($_)} @ARGV)));
' inf -inf 0 1
done
perl-5.8.1/perl
0 0 0 1
perl-5.8.2/perl
0 0 0 1
perl-5.8.3/perl
0 0 0 1
perl-5.8.4/perl
0 0 0 1
perl-5.9.0/perl
0 0 0 1
perl-5.9.1/perl
0 0 0 1
$ perl-5.6.2/perl -le '
print join(" ", sort({$a <=> $b} map({abs($_)} inf, -inf, 0, 1)));
'
0 1 inf inf
$ for i in perl-5.8* perl-5.9*
do ls $i/perl && \
$i/perl -I$i/lib -le 'use bigint;
print join(" ",
sort({$a <=> $b} map({abs($_)} inf, -inf, 0, 1)));
'
done
perl-5.8.1/perl
Ambiguous use of -inf resolved as -&inf() at -e line 3.
0 1 inf inf
perl-5.8.2/perl
Ambiguous use of -inf resolved as -&inf() at -e line 3.
0 1 inf inf
perl-5.8.3/perl
Ambiguous use of -inf resolved as -&inf() at -e line 3.
0 1 inf inf
perl-5.8.4/perl
Ambiguous use of -inf resolved as -&inf() at -e line 3.
0 1 inf inf
perl-5.9.0/perl
Ambiguous use of -inf resolved as -&inf() at -e line 3.
0 1 inf inf
perl-5.9.1/perl
Ambiguous use of -inf resolved as -&inf() at -e line 3.
0 1 inf inf
And here's why?
$perl -le 'use bigint; $a = inf; print ref($a)'
Math::BigInt
$perl -le 'use bigint; $a = shift; print ref($a)' inf
(nothing)
okay, so bigint is doing the infinity handling there, but what's this:
$perl -e 'print sprintf("%0.2f", 9**9**9);'
inf
$perl -le 'print abs(sprintf("%0.2f", 9**9**9));'
0
# ^-- here is where 5.6.2 differs (gives inf)
$perl -le 'print 1/ 9**9**9;'
0
$perl -le 'print abs( 9**9**9/1);'
inf
$perl -le 'print sprintf("%0.2f", abs( 9**9**9/1));'
inf
$perl -e 'print "ref: ", ref(10**10**10);'
ref:
$perl -e 'print "ref: ", ref(sprintf("%0.15f", 10**10**10));'
ref:
If this 9**9**9 inf is not the bigint inf, then what is going on?
Okay, I'll just start write hundreds of lines with ($n =~ m/^-?inf$/) or
should I keep pulling my hair out with trying to find a predictable behavior?
Is there a number such as 9**9**9 which is always guaranteed to return inf?
And once you have one, how do you get abs(), sprintf() and these others to
play nicely with it?
$ perl -le '$a = 9**9**9; $a += 1; print $a; $a = abs($a); print $a; $a =
sprintf("%0.2f", $a); print $a; print $a + $a '
inf
inf
inf
0
Thanks,
Hairless Eric
--
"It works better if you plug it in!"
--Sattinger's Law
Re: bigint 5.6 vs 5.8
Eric Wilhelm wrote:
> All I'm seeing in the pods
> are "Infinity is now recognized as a number."
> since 5.6.1, but not how to enable it.
from Set::Infinite -
use vars qw( $inf );
$inf = 100**100**100;
sub inf () { $inf }
Note that the stringification of inf varies
a lot between systems - you have to take
this into account when writing tests:
linux - inf
windows - 1.#INF
bsd - Inf
Some broken libraries also include spaces in the
name.
- Flavio S. Glock
Re: bigint 5.6 vs 5.8
# The following was supposedly scribed by # Eric Wilhelm # on Monday 21 June 2004 04:38 pm: >So, it's not my current system, but the state of the system on which perl > was compiled? The 5.6.1 was a RedHat rpm, while the 5.8.3 is a .deb, but > I'd happily build lots of things from scratch here if it would get this > working again. More fun with this: for i in perl-*;do ls $i/perl && $i/perl -le '$a = shift; print "inf support here" if $a+1 == $a' inf;done perl-5.6.2/perl inf support here perl-5.8.1/perl perl-5.8.2/perl perl-5.8.3/perl perl-5.8.4/perl I just built all 5 of these on this system with 'sh Configure -de && make' so maybe it's a change in the Configure defaults? or the interpreter code is behaving differently. --Eric
Re: bigint 5.6 vs 5.8
# The following was supposedly scribed by # Ken Williams # on Monday 21 June 2004 04:19 pm: >Notice that the 'inf' tokens are interpreted as strings, not Infinity. >This is because my OS X system, like your Debian system, has no support >for NaN and inf and all that stuff. It has nothing to do with the >version of perl. > >You can test your system's 'inf' support with stuff like this: > > perl -le '$a = inf; print "inf support here" if $a+1 == $a' okay, I just happen to still have the old /usr directory: 16:28:58: ~ $perl -le '$a = shift; print "inf support here" if $a+1 == $a' inf 16:29:00: ~ $/oldusr/bin/perl -le '$a = shift; print "inf support here" if $a+1 == $a' inf inf support here So, it's not my current system, but the state of the system on which perl was compiled? The 5.6.1 was a RedHat rpm, while the 5.8.3 is a .deb, but I'd happily build lots of things from scratch here if it would get this working again. If that's the case, what provides this support? All I'm seeing in the pods are "Infinity is now recognized as a number." since 5.6.1, but not how to enable it. Install some library and re-compile? Compile with some specific flags? Thanks, Eric
Re: bigint 5.6 vs 5.8
On Jun 21, 2004, at 1:59 PM, Eric Wilhelm wrote:
What happened? I was merrily using inf and -inf in 5.6.1 and now I've
got to
use the bigint pragma in 5.8.3?
I've just switched from RedHat 7.3 to Debian 'sarge', so that might
have
something to do with it.
This is the sort of thing I'm talking about:
sort({$a <=> $b} -inf, inf, 0, 1)
5.6.1 gives: -inf 0 1 inf
5.8.3 gives: -inf inf 0 1 (unless you 'use bigint')
That ain't doing what you think it's doing. ;-)
% perl -MO=Deparse -e 'sort({$a <=> $b} -inf, inf, 0, 1)'
sort {$a <=> $b} -'inf', 'inf', 0, 1;
Notice that the 'inf' tokens are interpreted as strings, not Infinity.
This is because my OS X system, like your Debian system, has no support
for NaN and inf and all that stuff. It has nothing to do with the
version of perl.
You can test your system's 'inf' support with stuff like this:
perl -le '$a = inf; print "inf support here" if $a+1 == $a'
-Ken
Re: bigint 5.6 vs 5.8
# The following was supposedly scribed by
# Eric Wilhelm
# on Monday 21 June 2004 01:59 pm:
>5.6.1 gives: -inf 0 1 inf
>5.8.3 gives: -inf inf 0 1 (unless you 'use bigint')
>
>Was some functionality removed from the core and put into the pragma? If
> so, what should I be reading?
It gets worse!
perl -e 'printf("%0.2f\n", inf);'
5.6.1 gives "inf"
5.8.3 gives "0.00" (even with 'use bigint')
What happened?
(maybe this should go to the porters?)
--Eric
--
"Insert random misquote here"
bigint 5.6 vs 5.8
What happened? I was merrily using inf and -inf in 5.6.1 and now I've got to
use the bigint pragma in 5.8.3?
I've just switched from RedHat 7.3 to Debian 'sarge', so that might have
something to do with it.
This is the sort of thing I'm talking about:
sort({$a <=> $b} -inf, inf, 0, 1)
5.6.1 gives: -inf 0 1 inf
5.8.3 gives: -inf inf 0 1 (unless you 'use bigint')
Was some functionality removed from the core and put into the pragma? If so,
what should I be reading?
"perldoc -q infinity" gives me nothing
Was the 5.6.1 behavior some undocumented thing that I wasn't supposed to be
using?
Thanks,
Eric
--
"Because understanding simplicity is complicated."
--Eric Raymond
Re: New module: CGI::Tooltip
* Orton, Yves <[EMAIL PROTECTED]> [2004-06-21 13:43]: > Er, actually I think it is pretty trivial. [snip example] > > For a pure OO module its even easier. Of course, if the programmer made sure to avoid "dirty" coding practices (or the module is trivial enough that s/he didn't consider those), then it's trivial. Problem is getting the edge cases right -- can you assume you can do that with any random package pulled from CPAN and have it still work? That's the kind of ground coverage I was thinking about. In Perl5, that's decidedly nontrivial if the module author doesn't cooperate. It would be nice if in Perl6, he wouldn't have to -- if it would Just Work, without anyone having to do anything special. Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: Perlforge?
Mark Stosberg wrote: 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. I agree. Too much dependency on SourceForge is not good. I have one (well, two) projects on sourceforge just because, when I created it, I didn't have anywhere to place it. I prefer to have a local CVS tree on a server nearby. I really do not use nothing more from sourceforge...well.. I use... domain redirection. If people can't host their projects, source-forge or savanna or similar are good choices. If you have a server, maybe I would use it. Sorry if this is offtopic... but the old CPAN Rating subject didn't attract my attention :-) Cheers, ambs -- Alberto Simões Python's syntax succeeds in combining the mistakes of Lisp and Fortran. I do not contrue that as progress. -- Larry Wall
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
Title: RE: New module: CGI::Tooltip
> Unfortunately, while it is possible in Perl5 to write code
> such that it works under multiple package names (or better
> yet, would work in any package regardless of the name), it is
> a not trivially supported scenario. It might be a good idea
> to think about these issues before Perl6 starts taking shape.
Er, actually I think it is pretty trivial. Here is code that aliases the package DDS to the package Data::Dump::Streamer
##This all has to be one line for MakeMaker version scanning.
use Data::Dump::Streamer (); BEGIN{ *DDS:: = \%Data::Dump::Streamer:: } $VERSION=$DDS::VERSION;
1;
For a pure OO module its even easier.
So I don't actually think this problem is with Perl, more like its an issue for CPAN.
Yves
Re: New module: CGI::Tooltip
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2004-06-19 20:35]: > Seems like a really good example of a module that could benifit > from meta data, and multi-category placement. If it weren't for > existing categories, and still needed a category structure, I'd > personally think something like the following would be more > suitable: > UI::ToolTip > With UI::ToolTip::HTML::JavaScript implementing a UI::ToolTip class. This is a really good point. It reminds me of a quote I always have to think about: Intertwingularity is not generally acknowledged -- people keep pretending they can make things deeply hierarchical, categorizable and sequential when they can't. Everything is deeply intertwingled. -- Ted Nelson Unfortunately, while it is possible in Perl5 to write code such that it works under multiple package names (or better yet, would work in any package regardless of the name), it is a not trivially supported scenario. It might be a good idea to think about these issues before Perl6 starts taking shape. Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: CPAN Rating
* khemir nadim <[EMAIL PROTECTED]> [2004-06-21 12:05]: > I think you missunderstood. I didn't ask for CPAN to become a > perl sourceforge. I asked if other wanted to have a source > forge that specilizes in perl like Rubyforge for ruby. Set one up. See what happens. People may use it. > In fact the most disturbing thing with Sourceforge is that it's > too big and it's difficult to find the perl gems in the > software bazaar. I don't see that. Most of the interesting stuff is also on CPAN. I concede it is a limited problem where Perl applications are concerned, which are not typically CPAN-ized, but Sourceforge *does* have a "Perl foundy"[1], so if people categorize their projects properly, this shouldn't be an issue. [1] http://perl.foundries.sourceforge.net/ Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: CPAN Rating
* khemir nadim <[EMAIL PROTECTED]> [2004-06-21 13:08]: > You mean we should all wear the same cloth comming out from the > same factory, eat the same food program in a single language > and all speak english only. I prefere bio-diversity. No, we should all grow our own cotton, sew our own clothes, make up our own cloth colouring chemicals. We should all grow our own food in our own backyard and invent our own cooking tools. Everyone should invent a new language and speak it exclusively. Welcome to Babylon. There is a balance. Leaning too far in the direction of diversity is no more desirable than leaning too far in the direction of conformism. Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: CPAN Rating
* khemir nadim <[EMAIL PROTECTED]> [2004-06-21 12:11]: > Can you fly without passport? Can you release a USB product > without certification? etc ... > > There is a diffrence between not wanting to do something and > being _unable_ to do something. Are you implying that you would disable autogeneration of READMEs and then make them a requirement? Then you'll get a lot of 0 byte READMEs. So next you make it a requirement that they be > X bytes length, and then you get a lot of READMEs with nothing but "This is Foo::Bar, for documentation see POD". You cannot make them. You CANNOT. > CPAN is a great idea and I am not blazé enough to accept the > that it is sometimes used as a garbage can. Garbage can is a strong word. I seriously doubt anyone uploads anything they're not using themselves. The problem is that people either do not care enough to put sufficient effort into what they upload or they are simply not educated enough. Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: CPAN Rating
"Simon Cozens" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > [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. You mean we should all wear the same cloth comming out from the same factory, eat the same food program in a single language and all speak english only. I prefere bio-diversity. Cheers, Nadim.
Re: New module: CGI::Tooltip
This is exactly wht I wanted to say in my previous post but my post was not phrased as good. I also think the abstract/real hierarchy is a good idea. My last point would be about the library that is used. Is it JavaCscript or something more specific? Cheers, Nadim. <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > This has been one of the best examples I've seen on the difficulties of > module naming. Many of the suggestions have valid reasons, and precidence > to back up the theory. > > Seems like a really good example of a module that could benifit from meta > data, and multi-category placement. If it weren't for existing categories, > and still needed a category structure, I'd personally think something like > the following would be more suitable: > UI::ToolTip > With UI::ToolTip::HTML::JavaScript implementing a UI::ToolTip class. > > It seems that the problem is that you could have ToolTip's implemented for > an HTML, or SVG, or Java, or GTK, or whatever type of display toolkit, and > they could be implemented using some other technology like JavaScript, > CSS, etc. Personally, I'm more a fan of listing the interface the tooltip > applies to first. If I were looking for a ToolTip module for GTK, I'd > expect to find GTK::ToolTip or ToolTip::GTK, not Python::ToolTip::GTK or > JavaScript::ToolTip::GTK. > But, to each his own. > > This has been an interesting thread. My vote's for "HTML::ToolTip". If > possible, it'd be nice if it was an abstract class, and > HTML::ToolTip::Javascript was an implementation of that class. > > -- > Josh I. >
Re: New module: CGI::Tooltip
My two modest cents, It seems to me that we'll never find __THE__ perfect name. The proposed names all have something right. Isn't the problem somewhere else? Why can't we name the same module differently? or (this might exist already) where do we put description strings for the module (like at the library)? Cheers, Nadim.
Re: Can't contact author. Abandoned module?
Hi David, It's just 10 days ago. The author might be on holidays or is too buisy to answer you right now. In the worst case, release you module under a different name for the time being. What about: Benchmark::Timer::Sampling. Cheers, Nadim. "David Coppit" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Greetings all, > > Back in Aug 2003, I talked with Andrew Ho <[EMAIL PROTECTED]> about > expanding his Benchmark::Timer module to support statistical sampling. > (The new feature would be to apply statistics to determine when to stop > timing something, based on user-specified confidence intervals and error.) > > At the time, he seemed to like my changes, and said that he would consider > adding them to the next version of the module. In the meantime, I > distributed my modified version of Benchmark::Timer along with my own > modules. > > I've since sent email to him in Feb 2004, and Jun 11, with no response. > There have been no releases to the module, and in my last email I offered > to take over maintenance if he's not interested in supporting the module > any more. I'm worried that the module has been abandoned (or worse, that > something has happened to the author). > > Should I wait longer? Or is it time to get the module maintainer gurus > involved in order to determine the module's disposition? I'd rather not > distribute an unofficial version of Benchmark::Timer with my code...
Re: CPAN Rating
[EMAIL PROTECTED] (Khemir Nadim) writes: > why do we have Savanna, Rubyforge and other? Because people are naturally fractious and would prefer to reinvent the wheel in order to do things Their Way instead of making use of the available resources. -- We use Linux for all our mission-critical applications. Having the source code means that we are not held hostage by anyone's support department. (Russell Nelson, President of Crynwr Software)
Re: CPAN Rating
"A. Pagaltzis" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > * khemir nadim <[EMAIL PROTECTED]> [2004-06-17 12:37]: > > The spirit of CPAN is quite straighforwardly described when it > > come to documentation but unfortunately a dummy (dumb) readme > > is generated instead for "forcing" the user to write one. > > Before we had autogenerated READMEs, such modules had no README > at all. You can't make someone do what they don't want to do. Really??? Can you fly without passport? Can you release a USB product without certification? etc ... There is a diffrence between not wanting to do something and being _unable_ to do something. CPAN is a great idea and I am not blazé enough to accept the that it is sometimes used as a garbage can. I'll try to wrap up what we (all) have discussed and see if there is something that can be done. Cheers, Nadim.
Re: CPAN Rating
"A. Pagaltzis" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > * khemir nadim <[EMAIL PROTECTED]> [2004-06-16 13:53]: > > I once wrote that it would be great to have the equivalent of > > sourceforge for perl module, the answer I got was "use > > sourceforge". Hmm talk about not answering the question. > > Maybe because it was the wrong question. CPAN is the > Comprehensive Perl ARCHIVE Network. I think you missunderstood. I didn't ask for CPAN to become a perl sourceforge. I asked if other wanted to have a source forge that specilizes in perl like Rubyforge for ruby. > > The most disturbing thing is that perl is Huge, lots of > > developpers, modules and projects but Ruby that is so small > > does have a rubyforge. > > Right, and how large is it? What does this have to do with my question? How large was CPAN when it started? how large was Sourceforge when it started? why do we have Savanna, Rubyforge and other? I ofound stuff in Rubyforge, I even had dinner with one of the guy having a module there so if I can't find software I can still have good times :-) In fact the most disturbing thing with Sourceforge is that it's too big and it's difficult to find the perl gems in the software bazaar. Cheers, Nadim.
