Graph::Easy installation failing here with YAML 0.50 (newer versions of
YAML seem to be uninstallable at the moment due to Class::Spiffy +
Spiffy + Test::Base install failures...
Any suggestions?
Adam K
Moin Alex,
On Saturday 28 January 2006 01:35, [EMAIL PROTECTED] wrote:
> Hello,
>
> I was doing some I18N of a bunch of existing CGI scripts and
> encountered a problem.
> I guess I'm making some very basic error, but I'm stuck with this for a
> day and I thought
> I may ask. I have my strings in
Moin,
On Saturday 28 January 2006 11:08, Adam Kennedy wrote:
> Graph::Easy installation failing here with YAML 0.50 (newer versions of
> YAML seem to be uninstallable at the moment due to Class::Spiffy +
> Spiffy + Test::Base install failures...
Just what I said about dependecies etc. My Makefile
Moin,
On Saturday 28 January 2006 08:20, Tyler MacDonald wrote:
> Gabor Szabo <[EMAIL PROTECTED]> wrote:
> > I have just moved to Ubuntu and thought I will try to rely on apt-get
> > to install my Perl modules. Quckly I hit a wall and could not install
> > some of the basic modules. I did not have
On Fri, Jan 27, 2006 at 11:50:49PM -0800, chromatic wrote:
> Let me save you the trouble of writing it to find the biggest problem right
> now: fairly broken automated testing systems that can't even *run* the
> Build.PL file *or* the compatibility Makefile.PL yet send FAIL reports
> anyway.
I
On Sat, Jan 28, 2006 at 09:08:48PM +1100, Adam Kennedy wrote:
> Graph::Easy installation failing here with YAML 0.50 (newer versions of
> YAML seem to be uninstallable at the moment due to Class::Spiffy +
> Spiffy + Test::Base install failures...
>
> Any suggestions?
You're getting install fail
"Sastry" <[EMAIL PROTECTED]> wrote:
The Parrot documet says that "Parrot compiles and runs on a large
number of platforms, including all common ones. The Parrot team is
committed to supporting the following combinations as "core
platforms": Linux (x86), Cygwin, Win32, Tru64, OpenVMS (Alpha),
Sola
On 1/28/06, Tels <[EMAIL PROTECTED]> wrote:
> Moin,
>
> On Saturday 28 January 2006 08:20, Tyler MacDonald wrote:
> > Gabor Szabo <[EMAIL PROTECTED]> wrote:
> > >
> > > Anyway I think instead of trying to setup our own binary distribution
> > > we might want to make sure there are up to date reposi
Adam Kennedy wrote:
Likewise, if your module installs all the way from a vanilla
installation and all it dependencies go on cleanly, then I think that's
well and truly worthy of a point.
Something like a clean_install metric. If there are any FAIL entries in
CPAN Testers against the current v
Nicholas Clark wrote:
On Fri, Jan 27, 2006 at 11:50:49PM -0800, chromatic wrote:
Let me save you the trouble of writing it to find the biggest problem right
now: fairly broken automated testing systems that can't even *run* the
Build.PL file *or* the compatibility Makefile.PL yet send FAIL rep
Knocking off points for fails, however, might be due to things that are
completely idiosyncratic. For example, anyone whose module depended on
a test module that used Test::Builder::Tester when Test::Builder changed
and broke it could get dinged.
Does this really tell us anything about actu
* Adam Kennedy <[EMAIL PROTECTED]> [2006-01-28 09:00]:
>If a Perl module needs libfoo then it should be stated in the
>metadata somewhere so that the binary packaging system can
>resolve that generalised dependency into the appropriate action
>for that environment.
++
How does Alien:: stack up he
Moin,
On Saturday 28 January 2006 15:54, David Golden wrote:
> Adam Kennedy wrote:
> > Likewise, if your module installs all the way from a vanilla
> > installation and all it dependencies go on cleanly, then I think
> > that's well and truly worthy of a point.
> >
> > Something like a clean_insta
* Adam Kennedy <[EMAIL PROTECTED]> [2006-01-28 16:20]:
>More to the point, it should lead people to spend more time
>looking into WHY their module isn't installing, and help us nail
>down the critical modules in the CPAN toolchain that have
>problems.
Sounds to me like a case of the “it will work
Adam Kennedy wrote:
Whether or not that is a transient thing that lasts for a week, or a
serious and ongoing problem, I think it's still worth it.
But that would require regular scanning -- otherwise I might get the
point one week and then a dependency might upgrade in a way that is
borked.
As I understand it, Alien packs the module for you, or otherwise "does
what it takes". Having only done a quick basic reading of the Alien
docs, it seems that it's a brute force thing for when you REALLY want
the lib and you have only CPAN.pm with which to get it. (Although it
might shortcut in
A. Pagaltzis wrote:
* Adam Kennedy <[EMAIL PROTECTED]> [2006-01-28 16:20]:
More to the point, it should lead people to spend more time
looking into WHY their module isn't installing, and help us nail
down the critical modules in the CPAN toolchain that have
problems.
Sounds to me like a case o
* Adam Kennedy <[EMAIL PROTECTED]> [2006-01-28 17:15]:
>So do have any additional specific objections, or are we up to
>"grumble, just fucking do it then, but I won't care" :)
Actually, I like the effort, even if I share some of the concerns
of the people who ridicule it. But it won’t motivate *me
On Jan 27, 2006, at 6:06 PM, James E Keenan wrote:
Steffen Schwigon wrote:
Quite often -l (to read from lib/) is enough, depending on your
module
build complexity. For -b you have to call ./Build before "prove",
which can be annoying and/or difficult to remember.
I'll have to try that out.
Barbie <[EMAIL PROTECTED]> wrote:
> I'm one of the maintainers/developers for CPAN::YACSmoke. I was
> intrigued by your post about adding a Packager plugin to it. However,
> I'm unclear as to what purpose it would serve. CPAN::YACSmoke is purely
> about reporting on test results. CPANPLUS does the
A. Pagaltzis wrote:
* Adam Kennedy <[EMAIL PROTECTED]> [2006-01-28 17:15]:
So do have any additional specific objections, or are we up to
"grumble, just fucking do it then, but I won't care" :)
Actually, I like the effort, even if I share some of the concerns
of the people who ridicule it. But
(*If* the author fixes the problem. I still can't get my patches for
Sub::Uplevel high enough in Schwern's queue.
Have you considered offering to take it over, or just co-maint the
module for one or two releases? He's given away modules before to people
that have more time to give them love t
Gabor Szabo <[EMAIL PROTECTED]> wrote:
> > You simple cannot guess what libraries/compiler/system/kernel the user
> > has installed, unless you know the distribution and version *and* require
> > that the user never updates anything.
>
> I think I agree. That's what I would like to see solved. If
Changing these HTTP like codes, might okay for an internal
representation, but would require ALOT of work to change several CPAN
modules and ensure all the testers upgraded. There is also the fact that
all existing reports are in the system and not going to change. Although
I may have misunderstoo
* Adam Kennedy <[EMAIL PROTECTED]> [2006-01-28 18:45]:
>My point is really that CPAN Testers CAN be fixed, it's merely a
>case of how much effort is involved and finding someone that
>cares enough to fix it.
I wasn’t saying anything to the contrary; just saying that that
is where the effort should
Hi,
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 register that this
parameter or local goes in to", which is rather useful if you
On Sat, Jan 28, 2006 at 11:01:06AM -0500, David Golden wrote:
>
> You need to deal with N/A's down the chain. E.g. I prereq a module that
> can't be built in an automated fashion but requires human intervention
> or choices or external libraries. If you don't have it and the
> automated buil
At 4:35 pm -0800 27/1/06, [EMAIL PROTECTED] wrote:
Hello,
I was doing some I18N of a bunch of existing CGI scripts and
encountered a problemI have my strings in UTF-8. I read most of
them from file,do some processing and spit them out of the
CGI-script.
Let say I do this:
$x=~y/a-ya
On Sun, Jan 29, 2006 at 04:45:51AM +1100, Adam Kennedy wrote:
>
> I haven't been able to find (although I haven't looked to hard) for a
> documented set of result codes. But either DEPFAIL or N/A makes sense.
See CPAN::YACSmoke pod. Just before Christmas I completed the
TestersGuide pod, which a
Today I was reading S06 from
http://dev.perl.org/perl6/doc/design/syn/S06.html, and I have some
perplexities on what's written there.
1) it's written:
$pair = :when;
doit $pair,1,2,3; # always a positional arg
doit *$pair,1,2,3; # always a named arg
but also:
To pass pair
Adam Kennedy wrote:
> That said, I'd also like "I need libfoo 1.41" declarations and other
> similar things, so we can really make the auto-packagers work some
> hardcore magic.
/me takes the Net::Pcap maintainer hat
I'd really like to see something like that, this would allow for
a much simpler
Sébastien Aperghis-Tramoni wrote:
Adam Kennedy wrote:
That said, I'd also like "I need libfoo 1.41" declarations and other
similar things, so we can really make the auto-packagers work some
hardcore magic.
/me takes the Net::Pcap maintainer hat
I'd really like to see something like that, th
Gabor Szabo wrote:
> I think I agree. That's what I would like to see solved. If I stick to
> the standard apt-get (or whatever) of my distribution I would like to be
> able to get all the CPAN modules by saying
>
> # apt-get install Module::Name
Did anybody here have played with CPANPLUS::Dist::
Adam Kennedy wrote:
> > (*If* the author fixes the problem. I still can't get my patches for
> > Sub::Uplevel high enough in Schwern's queue.
>
> Have you considered offering to take it over, or just co-maint the
> module for one or two releases? He's given away modules before to people
> that ha
Adam Kennedy wrote:
> Could you have a look at the COOKBOOK section of the Module::Install
> docs on CPAN, is that File::HomeDir example sort of what you would need?
Module::Install... 1) I'm allergic to this module, 2) I want to keep
the backward compatibility with Perl 5.004, and Module::Instal
Sébastien Aperghis-Tramoni wrote:
Adam Kennedy wrote:
Could you have a look at the COOKBOOK section of the Module::Install
docs on CPAN, is that File::HomeDir example sort of what you would need?
Module::Install... 1) I'm allergic to this module, 2) I want to keep
the backward compatibility w
As far as I know, ghc 6.4.1 has been declared stable and existed in
package form for a full 4 months now, since mid-September.
Are there any platforms for which 6.4.0 packages exist but not 6.4.1 packages?
Will anyone be messed up if 6.4.1 becomes a minimum hard requirement?
Its not typically
At 10:55 PM -0500 1/28/06, jesse wrote:
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 depen
Tels,
Please forgive me for being blunt, but I think it's your fault for
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 backward
compatibility is to be expected. If you were to have wrapped your
whole custo
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 tarball conforms to those i
40 matches
Mail list logo
