David Manura wrote:
> Speaking of my experience, it took me some time to discover that
>
>http://search.cpan.org/~pmqs/Compress-Zlib-1.33/Zlib.pm
>
> can be replaced with
>
>http://search.cpan.org/~pmqs/Compress-Zlib/Zlib.pm
>
> and it took me much longer to discover that this can be re
i want to test error checks in a module i'm working on. the
error paths carp() the problem and then proceed.
is there any way to capture the carp text (without using
some of Carp.pm's internal routines) for testing that they're
correct under the various error conditions?
--
#kenP-)}
Ken Coa
Andy Lester wrote:
I think having a convention to link to http://search.cpan.org/dist/* would
give these pages a chance to be more visible for programers who don't know
We should be using it ANYWAY. I'm so frustrated with URLs that point
to, say, search.cpan.org/author/Dis-Tro/1.74/ when Dis-Tro
Simon Cozens wrote:
[EMAIL PROTECTED] (Khemir Nadim) writes:
When I get the message above, I'll hit the return key faster than light
There's not really much a module author can to do help a user like that.
yes there is, it's the custom VERSION subroutine. Your legacy program
dies with t
Vagn Johansen wrote:
How are interface changes handled on CPAN?
They're not. I'm trying to promote a pradigm of including a VERSION
subroutine that
will croak (or at least die) when you ask for a non-forwards-compat.
version.
In theory, you change the name when you change the itnerface, instea
I was only talking about curators of the information about the
modules, not curators of CPAN. That sounds like far too nasty a job,
and as has been said, it has already been hashed and rehashed ad
nauseum.
We also can't go enforcing rules about namespace - the (non-CPAN.pm
indexed, search.perl.or
On Tue, 17 Feb 2004 02:53, A. Pagaltzis wrote;
> > (At least the Perl-XML folks got it right, props to Grant
> > McLean!).
> You don't put yourself in a particular spot on Google, you just
> get there by being linked from lots of places. You have zero
> control over whether and where you
> Everything that was said in this thread was very interresting and I, too,
> belive things should get better and I encourage those that want to do things
> _now_.
Please may we get a prototype of what your ideas are? Static HTML will
do. Having something to look at is far easier than everyone a
> I think having a convention to link to http://search.cpan.org/dist/* would
> give these pages a chance to be more visible for programers who don't know
We should be using it ANYWAY. I'm so frustrated with URLs that point
to, say, search.cpan.org/author/Dis-Tro/1.74/ when Dis-Tro is now a year
o
[EMAIL PROTECTED] (Khemir Nadim) writes:
> Simon, Can you please give us serious answers.
Congratulations, you earned a bozo bit in only three mails!
> > The people most likely to act as curators got together (as they do
> > periodically) and decided that better metadata would be the best
> short
On Mon, 16 Feb 2004, khemir nadim wrote:
> Please don't shout if it's note to show you're happy. Check the discussion
> we had about Roman.pm a few weeks ago. My point is not to force anyone to
> develop anything but that when a module is released and the author can't
> maintain it, the curators j
* Michel Rodriguez <[EMAIL PROTECTED]> [2004-02-16 13:43]:
> Then the problem is why don't those pages show up higher when
> you search on google? They come back fast enough, I suppose
> they are static, can anyone confirm this?
Again this is not a factor. All you have to do is make sure you
don't
On Mon, 16 Feb 2004, A. Pagaltzis wrote:
> * Michel Rodriguez <[EMAIL PROTECTED]> [2004-02-16 10:57]:
> > (At least the Perl-XML folks got it right, props to Grant
> > McLean!).
>
> You don't put yourself in a particular spot on Google, you just
> get there by being linked from lots of places. You
On Mon, Feb 16, 2004 at 10:37:12AM +1300, Sam Vilain wrote:
> On Mon, 16 Feb 2004 01:32, Tim Bunce wrote;
>
> > I'd like to see a summary of what those "needs of the community"
> > are. (Maybe I missed it as I've not been following as closely as
> > I'd have liked. In which case a link to a
Simon, Can you please give us serious answers. Writting to this list take
valuable time from me and from those reading the mails.
> > - Authors don't answer or have given up on maintaining there modules
> THEY ARE VOLUNTEERS.
Please don't shout if it's note to show you're happy. Check the discuss
* Tim Bunce <[EMAIL PROTECTED]> [2004-02-16 11:53]:
> (Meanwhile it could emulate the whole API and just return
> errors when interfaces it doesn't support are called.)
That's an excellent suggestion and nicely resolves the naming
issue as a side effect. Very nice.
--
Regards,
Aristotle
"If yo
* Michel Rodriguez <[EMAIL PROTECTED]> [2004-02-16 10:57]:
> (At least the Perl-XML folks got it right, props to Grant
> McLean!).
You don't put yourself in a particular spot on Google, you just
get there by being linked from lots of places. You have zero
control over whether and where you appear
On Wednesday, November 12, 2003, at 11:00 AM, Orton, Yves wrote:
Ach, dont be.
IMO there isnt much call to use these modules in real life.
They impose an overall performance penalty that outwieghs the
convenience
factor.
But it is nice to know (in that warm fuzzy way) that they are in
tool
Khemir Nadim on Mon, 16 Feb 2004 13:23:14 +0100 writes:
> "Simon Cozens" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> It is, however, polite for the module author to inform the user that
>> there's been a change.
> I too the question as being about what happends when the modul
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2004-02-16 10:14]:
> I don't think the other suggested names are appropriate, as
> they all deal with Gzip and Gunzip, which
> Archive::Zlib(_PP|::Perl) doesn't appear to implement.
gzip and zlib use the (exactly) same compression algorithm. The
zlib docs m
[EMAIL PROTECTED] (Michel Rodriguez) writes:
> I guess it becomes a social (for lack of a better term) instead of a
> technical issue: this is what we should link to when we want to reference
> a module.
This is in fact the policy I've been using for perl.com for a while now.
--
"A word to the
On 16 Feb 2004, Ask Bjoern Hansen wrote:
> [EMAIL PROTECTED] (Michel Rodriguez) writes:
>
> [...]
> > If size is a problem for mirrors, then a shorter version, with just links
> > to the docs, would work, maybe the search.cpan.org results for example:
> > http://search.cpan.org/~timb/DBI-1.40/ cou
Title: RE: OK, so we've decided that the right modules are too hard to f ind.
> [EMAIL PROTECTED] (Yves Orton) writes:
> > Afaik the only real reason for the modules list is to
> prevent people from
> > accidentally installing a module that is released under a
> known name, but by
> > an unk
[EMAIL PROTECTED] (Yves Orton) writes:
> Afaik the only real reason for the modules list is to prevent people from
> accidentally installing a module that is released under a known name, but by
> an unknown author.
>
> So if I release Email::Simple 1.4 no one using CPAN.pm to install it will end
>
[EMAIL PROTECTED] (Khemir Nadim) writes:
> When I get the message above, I'll hit the return key faster than light
There's not really much a module author can to do help a user like that.
--
In this talk, I would like to speculate a little, on ... the development
of intelligent life. I shall tak
"Simon Cozens" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> It is, however, polite for the module author to inform the user that
> there's been a change.
I too the question as being about what happends when the module interface
changes not how to handle the interface with the use
Title: RE: OK, so we've decided that the right modules are too hard to find.
> [EMAIL PROTECTED] (Elizabeth Mattijsen) writes:
> > I've released about 30 modules in the past 1.5 years. I _never_
> > bothered to try to register. I guess that means something.
>
> Likewise. (although slightly
[EMAIL PROTECTED] (Khemir Nadim) writes:
> Everything that was said in this thread was very interresting and I, too,
> belive things should get better and I encourage those that want to do things
> _now_.
None of these ideas are new.
> - Any one can start whatever hierarchy
This is not a problem
"Sam Vilain" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> - encourage curators to step forward, or groups of curators, for
> each category; possibly even create mailing lists for people with
> a general interest in the technology in that category; to field
> question
[EMAIL PROTECTED] (Khemir Nadim) writes:
> "Vagn Johansen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > How do you avoid breaking old programs when the interface changes?
> You don't. IMHO it's the users responsibility to check for what version they
> are using not the module a
[EMAIL PROTECTED] (Michel Rodriguez) writes:
[...]
> If size is a problem for mirrors, then a shorter version, with just links
> to the docs, would work, maybe the search.cpan.org results for example:
> http://search.cpan.org/~timb/DBI-1.40/ could be statically generated to
> just http://cpan.org/
Hi,
"A. Pagaltzis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Then maybe it needs to mention that it's an emulation, but
> besides Compress::Zlib::Emulated anything I come up with needs at
> least three words, and those are still incomplete.
>
> Maybe Compress::Gunzip::ZlibAPI?
"Vagn Johansen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> How do you avoid breaking old programs when the interface changes?
You don't. IMHO it's the users responsibility to check for what version they
are using not the module author. With Module Build you can ask for a
specifi
"Michel Rodriguez" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Generating the doc (from the POD) for each module (with a link to the
> tarfile or to the CPAN search page for the lates release of the module),
> and putting it on CPAN in something like cpan.org/docs/.
>
> Does this
On Sun, Feb 15, 2004 at 09:51:18PM +, Nicholas Clark wrote:
> On Mon, Feb 16, 2004 at 10:43:27AM +1300, Sam Vilain wrote:
> > On Mon, 16 Feb 2004 10:19, Nicholas Clark wrote;
> >
> > > Autrijus suggested Compress::Zlib::PurePerl, which I think is
> > > reasonable.
> >
> > ...but it doesn'
David Nicol on 15 Feb 2004 18:31:25 -0600 writes:
> On Fri, 2004-02-13 at 00:45, David Manura wrote:
>> [ the interface will change! ]
>
> I hope you are planning on adding a VERSION subroutine that will not
> accept requests for old, incompatible versions, while accepting requests
> for all late
Hi,
I think an interesting angle, first to get an idea of what the problem is,
and later (hopefully!) to see if we have improved the situation, is to put
ourselves in the position of a Perl programer that doesn't know the
community, maybe doesn't even know that CPAN exists.
Her first reflex would
On Sun, Feb 15, 2004 at 11:57:15PM +0100, A. Pagaltzis wrote:
> * Rocco Caputo <[EMAIL PROTECTED]> [2004-02-12 11:29]:
> > "Conveniently, I've written exactly the thing that provides the
> > features I need, in a way that's most convenient for my
> > purpose. Everything else pales by comparison, o
On Mon, 16 Feb 2004, A. Pagaltzis wrote:
> * Sam Vilain <[EMAIL PROTECTED]> [2004-02-15 22:44]:
> > ...but it doesn't use Zlib! :) Compress::Gzip?
>
> * Nicholas Clark <[EMAIL PROTECTED]> [2004-02-15 22:53]:
> > But it doesn't compress. Compress:Gunzip?
> > Uncompress::Gzip (Neither really mean
39 matches
Mail list logo
