Yitzchak Scott-Thoennes wrote:
On Fri, Jan 27, 2006 at 03:42:58PM +0100, Tels wrote:
On Thursday 26 January 2006 15:26, Thomas Klausner wrote:
I just uploaded Module::CPANTS::Analyse to CPAN. MCA contains most of
the previous Kwalitee indicators and some code to check if one
distribution tarbal
Yitzchak Scott-Thoennes wrote:
On Fri, Jan 27, 2006 at 03:42:58PM +0100, Tels wrote:
On Thursday 26 January 2006 15:26, Thomas Klausner wrote:
I just uploaded Module::CPANTS::Analyse to CPAN. MCA contains most of
the previous Kwalitee indicators and some code to check if one
distribution tarbal
On Sat, Jan 28, 2006 at 12:02:41AM +0100, Tels wrote:
> Moin,
>
> On Friday 27 January 2006 23:43, Tyler MacDonald wrote:
> > Jeffrey Thalhammer <[EMAIL PROTECTED]> wrote:
> > > Randy Kobes distributes Win32 PPMs for some of the
> > > modules that ActiveState doesn't provide. It is not
> > > enti
# New Ticket Created by Bob Rogers
# Please include the string: [perl #38348]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38348 >
It seems that Continuation needs the same set_address magic as
Exception_Handler in or
On Sat, Jan 28, 2006 at 07:52:55PM -0800, Darren Duncan wrote:
> Assuming no trouble, I propose that 6.4.1 is the minimum dependency
> for Pugs 6.28.0, if not 6.2.11 as well, the latter probably due any
> day now.
What's the benefit of bumping the ghc dependency up?
Jesse
>
> -- Darren Dunc
On 1/29/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
> ghc 6.4.0 works only with gcc 3.3, so those people that get 4.0 by
> default will have to downgrade to work with 6.4.0.
Wait---so if your proposal isn't effected, then people will be unable
to upgrade to ghc 6.4.1, and will instead have to dow
On 1/29/06, jesse <[EMAIL PROTECTED]> wrote:
> What's the benefit of bumping the ghc dependency up?
Well, if it helps, ghc-6.4.1 was a bugfix release from ghc-6.4.0, so
we're not getting any new features.
Luke
Moin,
On Sunday 29 January 2006 06:37, you wrote:
> Tels,
>
> Please forgive me for being blunt, but I think it's your fault for
> writing fragile META.yml creation code.
You are right for the code being fragile. (and no offense taken :)
But there was no other way I could get the license field
Moin,
On Sunday 29 January 2006 10:09, Yitzchak Scott-Thoennes wrote:
> On Sat, Jan 28, 2006 at 12:02:41AM +0100, Tels wrote:
> > Moin,
> >
> > On Friday 27 January 2006 23:43, Tyler MacDonald wrote:
> > > Jeffrey Thalhammer <[EMAIL PROTECTED]> wrote:
> > > > Randy Kobes distributes Win32 PPMs for
On Sun, Jan 29, 2006 at 12:04:22PM +0100, Tels wrote:
> Just witness Graph::Dependency, it will fail when their is no META.yml
> available, and what do you want me to do then? Parse Makefile.PLs?
The "correct" WTDI is to execute the Makefile.PL and parse the resulting
Makefile, looking for the PR
As I mentioned early, the obvious upgrade path from EU:MM, (apparently
if you don't care about 5.004 at least) is to Module::Install.
For example...
Makefile.PL
---
use inc::Module::Install;
name 'File-ShareDir';
all_from 'lib/File/Share
Moin,
On Sunday 29 January 2006 12:27, Adam Kennedy wrote:
> As I mentioned early, the obvious upgrade path from EU:MM, (apparently
> if you don't care about 5.004 at least) is to Module::Install.
>
> For example...
> As far as I can tell, it does what you want.
Except for the little fact that y
On Sunday 29 January 2006 12:51, Tels wrote:
> Moin,
>
> On Sunday 29 January 2006 12:27, Adam Kennedy wrote:
> > As I mentioned early, the obvious upgrade path from EU:MM,
> > (apparently if you don't care about 5.004 at least) is to
> > Module::Install.
> >
> > For example...
> >
> > As far as I
Tels did write:
Moin,
[...]
So, MakeMaker should be fixed to generate proper META.ymls without the
kludges nec that I needed. Of course, Schwern wills say "patches welcome"
and I am not up to patch MakeMaker :-(
(The other way would be the META.yml file for CPAN to be generated, but
that
Adam Kennedy wrote:
And therein lies the problem.
Working out when a dependency is important and when it's useless, or
vanity, or lazyness (good or bad) or whatever requires a human judgment
call.
So we can't really do anything about it.
Is it OK to use a lot of dependencies if they all wor
Chris Dolan wrote:
writing fragile META.yml creation code. YAML.pm is not even at 1.00
yet, so an API change is allowed by convention, and lack of
Convention? On CPAN? Are you kidding? By that logic, many of the
commonly used tools on CPAN could change API and your answer would be
"oh,
Adam Kennedy wrote:
> > Module::Install... 1) I'm allergic to this module, 2) I want to keep
> > the backward compatibility with Perl 5.004, and Module::Install is not
> > compatible with that version.
>
> Are you absolutely sure about that? It says it wants to be (and perlver
> can't pick up anyt
Perl6 will have macros. Good. Cool. But, sadly, that seems to be close
to the most specific thing anyone says about the subject. There is
some further discussion in Apocalypse & Exegesis 6, but nothing in the
Synopsis.
Now, considering that macros are a language feature and that the
Synopses are p
On Sun, Jan 29, 2006 at 18:53:25 +, Herbert Snorrason wrote:
> Perl6 will have macros. Good. Cool. But, sadly, that seems to be close
> to the most specific thing anyone says about the subject. There is
> some further discussion in Apocalypse & Exegesis 6, but nothing in the
> Synopsis.
>
> No
> On Fri, 27 Jan 2006 13:26:52 -0800, Luke Closs <[EMAIL PROTECTED]> said:
> This would allow non-perl people to install perl packages much easier,
> without having to mess with the CPAN shell and running tests. It
> would also make installing CPAN packages into hosted environments much
Hi Tels & John,
I'll try what you said (Monday) and will let you know if it works.
Thank you very much,
- Alex
On 1/29/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> Aside from that they are normal perl 6 subroutines, that simply get
> invoked during compile time instead of during runtime.
With one extra "feature". By default (my preference) or with a trait,
parameters can get passed in as ASTs instead of
> On Fri, 27 Jan 2006 15:42:58 +0100, Tels <[EMAIL PROTECTED]> said:
> I am still considering building something[0] that shows the
> module-dependency as a graph to show how "bad" the problem has become.
> Even "simple" modules like YAML seem to include everything and the
> kitchen-
On 29/01/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> Basically the plan is that when an internal AST language is decided
> upon, the macros will be able to get either the source code text, or
> an AST.
Two things. First, if the AST path is taken, doesn't that mean that
the AST representation has
On Sun, Jan 29, 2006 at 20:29:43 +, Herbert Snorrason wrote:
> On 29/01/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> > Basically the plan is that when an internal AST language is decided
> > upon, the macros will be able to get either the source code text, or
> > an AST.
> Two things. First, i
Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]> wrote:
> Did anybody here have played with CPANPLUS::Dist::Deb?
> http://search.cpan.org/dist/CPANPLUS-Dist-Deb/
>
> Believing its documentation, it should build a valid Debian package
> and take care of its dependencies (dunno if that means just li
Andreas J. Koenig <[EMAIL PROTECTED]> wrote:
> FWIW, we're using dh-make-perl to create debian packages from CPAN
> modules.
Andreas,
I've used this tool a few times when a CPAN module wasn't already
available in unstable/main, but I havent looked into it too closely. I'm
curious, does it
Darren Duncan wrote:
> ghc 6.4.1 works with any gcc version, both 3.3 and 4.0, so users with
> either gcc installed, the newer ghc will just work.
>
> ghc 6.4.0 works only with gcc 3.3, so those people that get 4.0 by
> default will have to downgrade to work with 6.4.0.
I've just committed r8839,
On Sat, Jan 28, 2006 at 11:21:24PM -, Jonathan Worthington wrote:
> Earlier today I checked in a change that lets you add a :non_volatile flag
> to a local or parameter.
>
> .param int i :non_volatile
> .local int j :non_volatile
>
> This says to the register allocator "don't re-use the regi
Except for the little fact that you have to bundle Module::Install in all
of your modules and need not to forget to add inc/* to MANIFEST -
Graph::Easy::As_svg increases from 27K to 47K gzipped
That concerned me for a little while as well.
But then someone pointed out to me that disk space
David Golden wrote:
Adam Kennedy wrote:
And therein lies the problem.
Working out when a dependency is important and when it's useless, or
vanity, or lazyness (good or bad) or whatever requires a human
judgment call.
So we can't really do anything about it.
Is it OK to use a lot of depende
And for the record, there are modules with incorrect C
concerning the Perl version. For example, some ask a Perl 5.005
while they perfectly work on 5.004, like File::Temp and
Test::Reporter. That's how I can send CPAN Testers reports
under 5.004:
http://testers.cpan.org/show/Net-Pcap.html
And t
32 matches
Mail list logo
