Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Adam Kennedy]

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

Re: What am I doing wrong? (Perl, UTF-8 and cyrillic)

[Tels]

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 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/A-YA/;
>
> Here, with "a" I mean cyrillic "a" (1'st letter of the cyrillic
> alphabet), with "ya" - ciryllic "ya"
> (last letter of the cyrillic alphabet). I don't want to post ciryllic
> chars here - I don't know how
> they will show, but you understand what I mean.
>
> This doesn't work properly.  I suppose it should convert the characters
> to uppercase, but
> what happens is that some characters do not get converted to uppercase,
> while other get
> converted to wrong characters.
>
> Another thing is that when I say "substr($cyrillicString,5,1)", the
> character returned is
> always invalid (shows as a white question on a black diamond).  All
> other cyrillic strings,
> that are not manipulated show properly.  The problem happens when I try
> to get a character
> from a string, to split it, things like this.
>
> What am I doing wrong? If you reply RTFM, I'll understand and will not
> complain... :-)

Did you do:

binmode ':utf8', STDIN;

(or the equivalent) when reading UTF-8 from a file?

best wishes,

Tels

What Perl version do you use? You may have to upgrade, because things 
prior to 5.8.2 (or even later) are a bit buggy.

In addition, I think that tr/// doesn't work properly with unicode, have 
you tried uc($string)?

In additon, what is the output charset set by your CGI? You need to tell 
the browser that you output utf-8, or it will/might incorrectly guess a 
different charset.

Best wishes,

Tels


-- 
 Signed on Sat Jan 28 11:13:40 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Where shall I put you? Under H, like Hot, Sexy Mama?"



pgpblIVxtmahK.pgp
Description: PGP signature

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Tels]

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.PL uses YAML for me 
(e.g. the author) to create a META.yml file with a license field, 
something that MakeMaker (could?) can't do.

I used "require YAML;" to avoid that the user has to has it installed.

Unfortunately, YAML got changed, and now you also need "require 
YAML::Node;" for my Makefile.PL working properly. :-(

So you can either:

* patch my Makefile.PL
* patch YAML to work like the previous version, then update it on CPAN,
  then install it

The latter is way more work, and needs time and due to what you wrote 
above, might even not work.

I'd say keep the dependencies out of YAML ("KISS"!). Whether YAML should 
also load YAML::Node when you do "require YAML;" is a point for 
discussion, but it certainly tripped up a *lot* of existing Makefiles and 
I don't have the time to patch them all because that requires me to 
release a dozend or so modules.

Sorry for the problem, but it is only partly my fautl :)

Best wishes,

Tels

-- 
 Signed on Sat Jan 28 11:22:01 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 This email violates EU patent EP0394160:
 
   [ ## 66%    ]



pgpszp3R3ux7n.pgp
Description: PGP signature

Re: Binary distributions

[Tels]

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 the time to investigate and
> > check if I made a mistake or if there is a .deb repository with the
> > latest CPAN modules for Ubuntu. I reverted to use CPAN.pm.
> > BTW here is an article on how to build Debian packages of Perl
> > modules: http://www.debian-administration.org/articles/78
> >
> >
> > Anyway I think instead of trying to setup our own binary distribution
> > we might want to make sure there are up to date repositories of
> > Perl modules for the major distributions
> > (and I am not talking only about Linux distributions here).
> > It can be done by helping the people who already maintain some of
> > these distributions or by setting up repositories such as
> > debian.cpan.org, fedora.cpan.org, etc...
>
>   That is such an incredibly good idea. I've got plenty of bandwidth
> to burn and I'm willing to set up debian.cpan.org.

Of course you must reliaze that, except for pure-perl modules and very 
controlled environments, binary distributions are doomed to fail.

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.

There is a reason that modules are compiled/linked against the target 
system prior to installation, and there is also a reason to run the 
tests: to assure that that step really worked.

FreeBSD might get away with that because the user will ever only install 
their ports and they can make sure that they all play together. For 
everything else, this becomes a maintanance nightmare and I wish to be no 
part of that :)

PS: I just read that Adam Kennedy wrote basically the same things. OOps.

Best wishes,

Tels

-- 
 Signed on Sat Jan 28 11:16:38 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 This email violates U.S. patent #5,546,528 and EU patent EP0689133:
 
   
   | Header | Body | Attachements |   |
   |+  +--|
   |  |
   ~  ~



pgpk46VLNNPg9.pgp
Description: PGP signature

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Nicholas Clark]

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 believe that the following won't be a problem with PITA, but the general
smoke system really $expletive annoys me for sending FAIL reports when it
tries to build one of my XS modules on a system without a C compiler.

My opinion is that this is a BUG IN THE SMOKE SYSTEM. The default for perl
is source distribution, so to build perl it's inferred you need a C compiler.
MakeMaker and Module build already automatically handle converting any .xs or
.c files that I ship into installable modules. When creating my package, I
don't need to do anything - it *already just works*. It's already supported.

So my opinion is that it's not necessary for me to manually add to my metadata
saying "I need a C compiler". If my module ships with .c or .xs files, it's
BLOODY OBVIOUS. 

So the smoke system should verify whether $Config::Config{cc} exists and can
run, and if it can't, N/A any package that isn't pure perl.

Yes, I really like valid smoke reports, pass or fail.
But FALSE NEGATIVES ARE PROCESS ERRORS.

Nicholas Clark

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Nicholas Clark]

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 failures even with the newest versions of Class::Spiffy
etc? I had failures with YAML not liking an existing installed Spiffy, but
upgrading everything seemed to resolve that.

If that's not it, then I don't know, but Ingy is often around on IRC.

Nicholas Clark

Re: Can Parrot and Perl6 run on z/OS UNIX?

[Jonathan Worthington]

"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),
Solaris (Sparc), FreeBSD (x86)."

a)Can Parrot and Perl6 run on z/OS UNIX as well?  If so what is the
support currently available?
At the moment I don't see anything specific with regrad to z/OS in the 
config system, so I guess we currently may not be able to build Parrot 
there.  If you have access to a z/OS box and wish to have a play to see how 
far you can get, please do - I imagine folks here, myself included, will be 
happy to offer hints to get around any tricky areas and apply patches you 
send in (provided they are sane) to support z/OS.  Please also see:-

http://www.parrotcode.org/docs/porting_intro.html
http://www-03.ibm.com/servers/eserver/zseries/zos/unix/bpxa1por.html


b)Are the features currently available will also be present for z/OS UNIX?
Again, with someone with sufficient time, skill and access to a z/OS box, 
any features that z/OS can support should be possible.



c)Are there any architecture dependency issues?
I'm not sure what (if any) EBCDIC platforms we support at the moment; there 
may well be issues here.


Hope this helps,

Jonathan 

Re: Binary distributions

[Gabor Szabo]

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 repositories of
> > > Perl modules for the major distributions
> > > (and I am not talking only about Linux distributions here).
> > > It can be done by helping the people who already maintain some of
> > > these distributions or by setting up repositories such as
> > > debian.cpan.org, fedora.cpan.org, etc...
> >
> >   That is such an incredibly good idea. I've got plenty of bandwidth
> > to burn and I'm willing to set up debian.cpan.org.
>
> Of course you must reliaze that, except for pure-perl modules and very
> controlled environments, binary distributions are doomed to fail.
>
> 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 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

> There is a reason that modules are compiled/linked against the target
> system prior to installation, and there is also a reason to run the
> tests: to assure that that step really worked.
>
> FreeBSD might get away with that because the user will ever only install
> their ports and they can make sure that they all play together. For
> everything else, this becomes a maintanance nightmare and I wish to be no
> part of that :)

This is for those who want specialized systems with non default versions
of libraries/applications etc. They should indeed install from source and run
the tests.

Others should be able to rely on the fact that the distributor has
already successfully ran the tests in a system with the same software
she has.

Gabor

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[David Golden]

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 version of your module, you lose a point.


Those two are not the same.  Leaving aside that Kwalitee tests don't run 
code, the ability of a vanilla version of the latest production release 
of perl to install a module and all of its dependencies with the vanilla 
version of CPAN for that release could be an interesting signal of quality.


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 actual quality?

What about if I list a prerequisite version of Perl and someone who 
tries it under an older version causes a "FAIL" on CPAN Testers?  Does 
that tell us anything?


There are so many special cases that I don't think the value derived 
from such a metric will be worth the effort put into it.


The vanilla testing is a more interesting idea in its own right.  I've 
had that on my back burner for a while -- installing a fresh perl and 
scripting up something to try installing my distributions to it, then 
blowing away the site library directory afterwards.  I just haven't 
gotten around to it, so I look forward to seeing what you come up with.


David

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Adam Kennedy]

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 reports 
anyway.


I believe that the following won't be a problem with PITA, but the general
smoke system really $expletive annoys me for sending FAIL reports when it
tries to build one of my XS modules on a system without a C compiler.

My opinion is that this is a BUG IN THE SMOKE SYSTEM. The default for perl
is source distribution, so to build perl it's inferred you need a C compiler.
MakeMaker and Module build already automatically handle converting any .xs or
.c files that I ship into installable modules. When creating my package, I
don't need to do anything - it *already just works*. It's already supported.

So my opinion is that it's not necessary for me to manually add to my metadata
saying "I need a C compiler". If my module ships with .c or .xs files, it's
BLOODY OBVIOUS. 


In most situations yes, but I forsee some situations where there are 
edge cases of this. Something that processess/scans C/XS files so it has 
a collection in t/ or has examples as part of doc/ or similar.


There's also some benefit to declaring you need a C compiler, in that it 
provides clearer hints to automated packaging systems (deb/rpm/ppm/etc) 
that you need to compile, so they can make judgements earlier, without 
every single autopackaging system being expected to go and scan the 
entire tarball.


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.


Adam K

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Adam Kennedy]

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 actual quality?


Yes, it tells us that the modules you chose to depend on are dodgy and 
don't install. Having your module drop a point when a module you depend 
on goes crazy is a desired behavior for the point of view of a 
clean_install point.


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.


A sign of a kwalitee module is when the installation of it Just Works, 
regardless of who is assigned the blame for any failure.


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.


If all of a sudden you lose the clean_install point, you can go find the 
problem, then either help the author fix the problem or stop using that 
module. Either way, your module used to not install, and now it does 
install.


What about if I list a prerequisite version of Perl and someone who 
tries it under an older version causes a "FAIL" on CPAN Testers?  Does 
that tell us anything?


I believe that that isn't classed as a fail. If the testing platform 
does not have a new enough version to match the listed Perl version, it 
counts as a Not Applicable and the testing system shouldn't be sending 
FAILs.


A testing system should only be sending FAIL reports when it believes it 
has a platform that is compatible with the needs of the module, but when 
it tries to install tests fail.


There are so many special cases that I don't think the value derived 
from such a metric will be worth the effort put into it.


I'm interested to hear what some the special cases might be though. I'm 
trying to put together a mental list of possible problems I need to deal 
with.


A FAIL should ONLY mean that some package has told the smoke system that 
thinks it should be able to pass on your platform, and then it doesn't.


Failures that aren't the fault of the code (platform not compatible, or 
whatever) should be N/A or something else.


The vanilla testing is a more interesting idea in its own right.  I've 
had that on my back burner for a while -- installing a fresh perl and 
scripting up something to try installing my distributions to it, then 
blowing away the site library directory afterwards.  I just haven't 
gotten around to it, so I look forward to seeing what you come up with.


If you want to help out, we'd love to see you in irc.perl.net #pita.

That's an open invitation to other interested people too.

I'll do a bit more announce+explaining once we get to PITA 0.20 and 
there's something other people can actually download, install and try out.


I tend to add to "Release early, release often", "... once it works"

Adam K

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[A. Pagaltzis]

* 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 here in your opinion?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Tels]

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_install metric. If there are any FAIL entries
> > in CPAN Testers against the current version of your module, you lose
> > a point.
>
> Those two are not the same.  Leaving aside that Kwalitee tests don't
> run code, the ability of a vanilla version of the latest production
> release of perl to install a module and all of its dependencies with
> the vanilla version of CPAN for that release could be an interesting
> signal of quality.
>
> 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 actual quality?

Yes :)

The more things your module depends on, the higher the chances are that it 
breaks.

Of course, determining what treshold is considered "good re-use of code" 
and what counts as "excessive dependency hell" is quite hard to decide.

> What about if I list a prerequisite version of Perl and someone who
> tries it under an older version causes a "FAIL" on CPAN Testers?  Does
> that tell us anything?

It shouldn't count as fail.

> There are so many special cases that I don't think the value derived
> from such a metric will be worth the effort put into it.

That might be well true.

Best wishes,

Tels

-- 
 Signed on Sat Jan 28 16:44:09 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 Like my code? Want to hire me to write some code for you? Send email!



pgpBBgrp8nV5s.pgp
Description: PGP signature

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[A. Pagaltzis]

* 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 because it will be
good if it did” fallacy. What is actually going to happen is:

People will grumble about “arbitrary stupid Kwalitee criteria”
and ignore the problem. Kwalitee is going to be ridiculed, more
than it already is. Noone will be motivated to fix the problem
just to fix CPANTS, although someone will eventually do that for
unrelated reasons, those reasons being that the smoke system is
of immediate use for authors while Kwalitee provides nothing but
moralizing undertone in the first approximation.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[David Golden]

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.  (Test::Exception did this to me a while back for some 
particular version of it -- actually related to CPANPLUS not recognizing 
Module::Build's build_requires... and on we merrily go.)


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.


I agree. I've been stripping Test::Exception.  The syntactic sugar isn't 
worth the headache of diagnosing build failures.


If all of a sudden you lose the clean_install point, you can go find the 
problem, then either help the author fix the problem or stop using that 
module. Either way, your module used to not install, and now it does 
install.


(*If* the author fixes the problem.  I still can't get my patches for 
Sub::Uplevel high enough in Schwern's queue.  But that goes back to your 
point about dodgy dependencies, so I'll score that argument to you.)


A testing system should only be sending FAIL reports when it believes it 
has a platform that is compatible with the needs of the module, but when 
it tries to install tests fail.


General question: Are failed prerequisite versions a FAIL or a Not 
Applicable if the smoke tester isn't set to automatically try to upgrade 
them?


I'm interested to hear what some the special cases might be though. I'm 
trying to put together a mental list of possible problems I need to deal 
with.


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 build to try to get it fails, that really isn't my problem -- 
I've been clear about the dependency: "If you have version X.YZ of 
Module ABC::DEF, then I promise to pass my tests".


Think about the GD modules -- if the GD library isn't installed, GD 
won't build and anything depending on it fails.  Should that fail a 
"clean_install"?


(Contrast that with SQLite, which installs it for you.)

A FAIL should ONLY mean that some package has told the smoke system that 
thinks it should be able to pass on your platform, and then it doesn't.


Failures that aren't the fault of the code (platform not compatible, or 
whatever) should be N/A or something else.


I think better granularity would be: "FAIL" -- failed its own test 
suite; "DEPFAIL" -- couldn't get dependencies to pass their test suites; 
and "N/A" -- incompatible platform or Perl version or not automatically 
chasing dependencies.



If you want to help out, we'd love to see you in irc.perl.net #pita.


Between tuit shortages and the day job (side q: what's this whole $job 
thing I keep seeing in people's posts/blogs), a realtime channel like 
IRC is hard to keep up with.  Is there a mailing list or wiki or some 
such?  (Subversion repository?)


Regards,
David

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Adam Kennedy]

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 the appropriate cases)


I'd hoped for something much more simple and declarative. Something 
where we (Perl) don't actually do anything, but provide enough hints for 
others to be able to make it the appropriate cross-language dependencies 
of their own in each environment.


So needs_lib entries result in a debian module using libfoo on Debian, 
or on RPM, or etc...


Adam K

A. Pagaltzis wrote:

* 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 here in your opinion?

Regards,

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Adam Kennedy]

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 of the “it will work because it will be
good if it did” fallacy. What is actually going to happen is:

People will grumble about “arbitrary stupid Kwalitee criteria”
and ignore the problem. Kwalitee is going to be ridiculed, more
than it already is. Noone will be motivated to fix the problem
just to fix CPANTS, although someone will eventually do that for
unrelated reasons, those reasons being that the smoke system is
of immediate use for authors while Kwalitee provides nothing but
moralizing undertone in the first approximation.


So do have any additional specific objections, or are we up to "grumble, 
just fucking do it then, but I won't care" :)


Adam K

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[A. Pagaltzis]

* 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* to fix
the smoke system, and I assume most other people who might care
about CPANTS in an “I’m just a user” sort of way will feel the
same. I also don’t see how those involved with the smoke system
but not CPANTS will be motivated by CPANTS to fix the smoke
tests.

So right now, the metric will not contribute in any useful way to
anything. If you want the smoke system to be fixed, well gee,
you’ll have to fix the smoke system.

I’m not trying to discourage you. My point is just that if you
want to achieve what you want to achieve (and it’s a good thing
to want to achieve), you’ll need to spend your effort
differently.

I’d volunteer to help if I didn’t already have my plate full with
more committments than I can manage. Let’s not waste our limited
tuit bugdets on things that won’t help.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Test Script Best-Practices

[Matisse Enzer]

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.  My modules all use MakeMaker rather  
than Module::Build.  And I'm generally using 'prove' to trouble- 
shoot individual tests after I've already run 'make test' and  
identified which test files have failures.


For modules that are in {src_dir}/lib/ I have often had my  
individual .t files do this:


use FindBin qw($Bin);
use lib "$Bin/../lib";

I often have a situation which probably doesn't come up for most Perl  
developers - I usually develop these days using the EPIC plugin for  
Eclipse, and it doesn't have an easy way to execute 'prove' or 'make  
test', but it can execute Perl scripts in my source directory, so, it  
is useful for me to be able to have each .t file be executed by a  
process whose $PWD might be outside the source directory. Usually I  
use a little script 'run_tests.pl' that basically does what 'prove -v  
t' does, and have Eclipse execute that. The run_tests.pl script uses  
FindBin so it knows where lib/ and t/ are.

Re: Binary distributions

[Tyler MacDonald]

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 actual work. 

Barbie,

From what I gather, CPANPLUS is a linear package building
system, whereas YACsmoke is a wrapper around that that tries to build as
many packages as is humanly (er, computerly) possible on a system, with the
side effect of sending it's results through Test::Reporter. YACsmoke also
can maintain a database of what it has built and what it hasn't, allowing a
YACsmoke system to eventually exhaustively build every single package on
CPAN without building the same one twice. Is this correct?


> What would the plugins for .deb, .rpm and .ppm do? Currently we just
> pass the path to CPANPLUS and let CPANPLUS unwrap, make and test the
> distribution. We then just interrogate the results.

These plugins would execute *after* YACsmoke/CPANPLUS has done it's
work, but before it's cleaned up after itself, and generate the actual
.deb/.rpm/.ppm files.

> Perhaps this is something you meant for CPANPLUS to handle, in which
> case I'm sure that's something Jos would be interested in, as he has
> previously looked at some kind of binary support.

Well, maybe the actual low-level package generation could be kicked
down a level, but the whole reason I thought of using YACsmoke for this was
because of it's "grab everything and try to build it" nature.

> I plan to find time soon to complete the tests required for the next
> release of CPAN::YACSmoke, so if what you want does relate to
> CPAN::YACSmoke I can start taking a look and see what needs to be done
> to implement it.

Sounds good :)

Thanks,
Tyler

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Adam Kennedy]

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 it won’t motivate *me* to fix
the smoke system, and I assume most other people who might care
about CPANTS in an “I’m just a user” sort of way will feel the
same. I also don’t see how those involved with the smoke system
but not CPANTS will be motivated by CPANTS to fix the smoke
tests.

So right now, the metric will not contribute in any useful way to
anything. If you want the smoke system to be fixed, well gee,
you’ll have to fix the smoke system.


That may not be that hard as you might think. Since PITA provides a 
superset of the current testing options we may be able to just duplicate 
the entire current set of CPAN Testers on a single $400 PC.


But that's really blue sky at the moment, I have absolutely nothing 
concrete to back up that statement, nor do I wish to engage in 
discussion or speculation on that possibility till I have something more 
useful to contribute and not just vapour.


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.


Adam K

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Adam Kennedy]

(*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 than he has.


General question: Are failed prerequisite versions a FAIL or a Not 
Applicable if the smoke tester isn't set to automatically try to upgrade 
them?


Well purely logically they aren't a FAIL... I think testers currently 
does email in a FAIL for the dep itself. Not sure what happens to the 
parent module.


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.


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 build to try to get it fails, that really isn't my problem -- 
I've been clear about the dependency: "If you have version X.YZ of 
Module ABC::DEF, then I promise to pass my tests".


Think about the GD modules -- if the GD library isn't installed, GD 
won't build and anything depending on it fails.  Should that fail a 
"clean_install"?


(Contrast that with SQLite, which installs it for you.)


I _think_ that's current also dealt with ok. I can't say for sure 
though. But it's such a common case I don't see why it wouldn't be.


If not, I certainly plan to deal with it that way. N/As cascade.

A FAIL should ONLY mean that some package has told the smoke system 
that thinks it should be able to pass on your platform, and then it 
doesn't.


Failures that aren't the fault of the code (platform not compatible, 
or whatever) should be N/A or something else.


I think better granularity would be: "FAIL" -- failed its own test 
suite; "DEPFAIL" -- couldn't get dependencies to pass their test suites; 
and "N/A" -- incompatible platform or Perl version or not automatically 
chasing dependencies.


Without knowing how many exist now, I hope to define a more 
comprehensive set of HTTP-like codes, but that design element is still 
flexible.


Is there a mailing list or wiki or some 
such?  (Subversion repository?)


No infrastructure for now, until it's actually announced, but the IRC 
channel is logged ala #perl6, so you can visit when you wish, and catch 
up when you care.


Adam K

Re: Binary distributions

[Tyler MacDonald]

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 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

Well in debianland it's actually apt-get libmodule-name-perl :)

The solution to this sounds straightforward, although probably not
simple to implement. Your build box is running the distribution+arch you
want to release the modules for. After building the packages, "ldd" any
binaries found within. This will give you a list of library filenames. In
debian's case, /var/lib/dpkg/info/*.list contains a list of files supplied
by each package on the system. Use that to match dependancies up.

If a package requires something on the system that it *doesn't* link
against (say, a certain executable), that problem won't be solved, but I
think that case is a bit rarer.

- Tyler

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Adam Kennedy]

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 misunderstood your intentions.


Well, our reports are in XML, so we will already have to do an XSLT 
translation to get them down into something that the current stuff can 
handle.


So simplifying the status flags to make it palatable to the existing 
system should be fine.


As for future-proofing, the XML reports abstract data collection from 
data analysis, so we $should be able to upgrade the analaysis and rerun 
them on the old reports in our database.


Adam K

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[A. Pagaltzis]

* 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 be concentrated. :-)

For the record, PITA sounds like a really cool hack. Kudos if you
can pull it off.

Once the smoke tests are fixed so that “installs cleanly” can
actually be determined meaningfully, then I agree, it will be a
useful kwalitee metric.

Regards,
-- 
Aristotle Pagaltzis // 

[svn ci] :non_volatile

[Jonathan Worthington]

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 are creating a 
reference to the register in question and expecting it not to be re-used for 
something else.


Jonathan 

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Barbie]

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 build to try to get it fails, that really isn't my problem -- 
> I've been clear about the dependency: "If you have version X.YZ of 
> Module ABC::DEF, then I promise to pass my tests".

With CPAN::YACSmoke, if you require a distribution that results in a NA
report, your distribution is also classed as NA. Part of this is the
Perl version issue. CPAN and CPANPLUS will not install your distribution
if a pre-requisite up's requirement of Perl. This happened a lot in the
last year as ExtUtils::MakeMaker and Module::Starter insert the authors
version of Perl when they create a new distributions. As other authors
decide to use those distributions without meaning to, they also require
that version of Perl.

This is the reason I'm looking at developing SDKs for core modules that
don't have a life outside the core distribution, to help relieve some of
those dependencies.

The issue with external libraries and C compiler is awkward to reliably
do, as different platforms put them in different places, and often name
them differently according versions. This is something I want to try
either include into CPAN::YACSmoke, or have a way for authors to create
a dependency on an Alien:: or similar distribution, which can determine
a version of the require 3rd party software, as well as whether it is
installed.

> Think about the GD modules -- if the GD library isn't installed, GD 
> won't build and anything depending on it fails.  Should that fail a 
> "clean_install"?

A report should either not be submitted, or it is classed as something
that indicates that 3rd party software was not available to complete
testing. I'm leaning towards the former.

> (Contrast that with SQLite, which installs it for you.)

That's because the license enables Matt to do that. Plus it's the kind
of self contained release that you can get away with bundling it with
the distribution. libgd is used by plenty of other apps.

> >A FAIL should ONLY mean that some package has told the smoke system that 
> >thinks it should be able to pass on your platform, and then it doesn't.
> >
> >Failures that aren't the fault of the code (platform not compatible, or 
> >whatever) should be N/A or something else.
> 
> I think better granularity would be: "FAIL" -- failed its own test 
> suite; "DEPFAIL" -- couldn't get dependencies to pass their test suites; 
> and "N/A" -- incompatible platform or Perl version or not automatically 
> chasing dependencies.

With CPAN::YACSmoke, a "DEPFAIL" is marked as "ABORTED" and no report is
sent.

> >If you want to help out, we'd love to see you in irc.perl.net #pita.
> 
> Between tuit shortages and the day job (side q: what's this whole $job 
> thing I keep seeing in people's posts/blogs), a realtime channel like 
> IRC is hard to keep up with.  Is there a mailing list or wiki or some 
> such?  (Subversion repository?)

I'd like to see a mailing list specific for developers of the smoke
systems, as currently the ideas for CPAN::YACSmoke are usually just
discussed between Robert Rothenberg and myself. If we going to improve
reporting it would help to have a wider discussion group. Whenever
Robert or I have posted here, it hasn't really reach the right audience.

I'm glad that the AUTOMATED_TESTING flag is getting picked up now, but
it would be nice to throw those ideas around more often, and getting
them refined quicker.

I'm looking forward to evaluating PITA, but it will likely have to be on
a Perl 5.8.7 Windows box, as my 5.6.1 box can't install any of the PITA
distributions on CPAN at the moment, due to the dependency issue ;)

Cheers,
Barbie.

Re: What am I doing wrong? (Perl, UTF-8 and cyrillic)

[John Delacour]

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/A-YA/;



What about this? :

#!/usr/bin/perl
use open ':encoding(UTF-8)';
binmode STDOUT, ":utf8";
my $file = "/tmp/aja";
open TEST, $file;
for (1072..1103) { print TEST chr() };
close TEST;
# # # # #
open SOURCE, $file;
while () {
  for (split //) {
$lower .= $_;
s~.+~\U$&~;
$upper .= "$_";
  }
}
print "$lower$/$upper$/";
print
  substr($lower, 5,5) . $/ .
  substr($upper, 5,5);



What am I doing wrong? If you reply RTFM, I'll understand and will not
complain... :-)


Plenty to read here:

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Barbie]

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 also explains it in more detail. That version
has been released to CPAN, but is available via CVS on SourceForge.

> If not, I certainly plan to deal with it that way. N/As cascade.

Agreed.

> Without knowing how many exist now, I hope to define a more 
> comprehensive set of HTTP-like codes, but that design element is still 
> flexible.

There are only 4 that are submitted to cpan-testers, PASS, FAIL, NA and
UNKNOWN (no tests supplied with the distribution). CPAN::YACSmoke also
deals with ABORTED and UNGRADED, which are referenced internally, as
well as IGNORED (a subsequent version PASSes) and NONE (where a version 
has been cleared of it's previous grade by manual intervention.

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 misunderstood your intentions.

> >Is there a mailing list or wiki or some 
> >such?  (Subversion repository?)
> 
> No infrastructure for now, until it's actually announced, but the IRC 
> channel is logged ala #perl6, so you can visit when you wish, and catch 
> up when you care.

I use IRC very rarely, as due to work and family taking up most of my 
time ... when I'm not organising a conference ;) Now that more tools are
being created, it seems more appropriate to discuss these elsewhere than
on a QA list. I'll investigate setting something up on the Birmingham.pm
server, unless there is somewhere else that would be more appropriate.

Cheers,
Barbie.

Some perplexities on S06

[dakkar]

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 pairs out of hash without their being interpreted as named
parameters, use

  doit %hash:p,1,2,3;
  doit %hash{'b'}:p,1,2,3;

instead.

   I interpret the last sentence as meaning that:

 $hash=:a<2>; doit %hash;

   would be equivalent to:

 doit :a<2>

   which contradicts what is written earlier... I'd assume I'd have to
write:

  doit *(%hash);

   for the pair to be used as a named argument. What am I missing?

2) Consider:

 doit %*hash;   # 1 arg, the global hash
 doit *%hash;   # n args, the key-value pairs in the hash

   I think I'll use a lot of C-t while writing Perl6 code...

3) What does the second line in:

  push @array, :a<1>;
  say *pop(@array);

   mean? I'd parse it as 'say (*pop)(@array)', that is, call the global
'pop' subroutine. But the text around this example seems to imply that
it is to be parsed as 'say *(pop(@array))', i.e. execute 'pop' and splat
the result. What gives?

4) It's written:

   (Conjectural: Within the body you may also use exists on the
parameter name to determine whether it was passed. Maybe this will have
to be restricted to the ? form, unless we're willing to admit that a
parameter could be simultaneously defined and non-existant.)

   Ok, this is 'conjectural', but... if i don't pass a parameter in an
invocation, and that parameter had a defined default, that it would be
both defined and non-passed... here I'm sure I'm missing something

5) while talking about pipes, it says that

 (0..2; 'a'..'c') ==> my @;tmp;
 for @;tmp.zip { say }

   produces

  [0,'a']
  [1,'b']

   etc. Right. But then it says:

 for @;tmp.each -> $i, $a { say "$i: $a" }

   as far as I understand, this should say

 0: undef
 'a': undef

   etc., since 'each' is visiting the multidimensional array 'by rows',
and producing 1 value at a time, which when bound to the 2-ary signature
would leave the $a parameter without a value, and so undef (I'm assuming
that pointy sub positional parameters are implicitly optional, otherwise
that statement would be a run-time error). I'm pretty sure I don't know
what 'each' does...

6) It's written:

 Every lexical scope gets its own implicitly declared @; variable,
which is the default receiver.

   To me, that is a variable with a null name ('@;' being a twigil).
Should it not be @;_ ?



I'll continue reading...

--
Dakkar - 
GPG public key fingerprint = A071 E618 DD2C 5901 9574
 6FE2 40EA 9883 7519 3F88
key id = 0x75193F88


signature.asc
Description: OpenPGP digital signature

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Sébastien Aperghis-Tramoni]

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 Makefile.PL (and maybe avoid rants on use.Perl or
elsewhere), but as I discovered with Net::Pcap and the need to
support 4 different versions (2 on Unix, and 2 on Windows) at the
same time it's not really easy to cope with every situation
(although I agree it wasn't that hard since it now somehow works).
But I currently see now simple way to allow for automated build
under Windows, because of manual interaction it requires.

--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Adam Kennedy]

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, this would allow for
a much simpler Makefile.PL (and maybe avoid rants on use.Perl or
elsewhere), but as I discovered with Net::Pcap and the need to
support 4 different versions (2 on Unix, and 2 on Windows) at the
same time it's not really easy to cope with every situation
(although I agree it wasn't that hard since it now somehow works).
But I currently see now simple way to allow for automated build
under Windows, because of manual interaction it requires.


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?


Adam K

Re: Binary distributions

[Sébastien Aperghis-Tramoni]

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::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 listing
or actually adding them in the package).

--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Sébastien Aperghis-Tramoni]

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 have more time to give them love than he has.

And for some modules, he's even eager to give them away :)

> > General question: Are failed prerequisite versions a FAIL or a Not
> > Applicable if the smoke tester isn't set to automatically try to upgrade
> > them?
>
> Well purely logically they aren't a FAIL... I think testers currently
> does email in a FAIL for the dep itself. Not sure what happens to the
> parent module.
>
> 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.

N/A status is already available with Test::Reporter:

  grade meaning
  - ---
  pass  all tests passed
  fail  one or more tests failed
  nadistribution will not work on this platform
  unknown   distribution did not include tests

CPANPLUS only sends FAIL for the module that failed, not for the module
which depended upon the module that failed.


--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Sébastien Aperghis-Tramoni]

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::Install is not
compatible with that version.

The COOKBOOK section is fine for pure Perl modules, but in the case of
XS modules that interface to a library with a varying API, it's of no
use. Take a look at Net::Pcap's Makefile.PL

--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Adam Kennedy]

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 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 anything obvious in it).


But don't worry too much for now, conclusive version-dependency prooving 
is on the to-do as well, so I'll deal with it later on.


Adam K

raising Pugs' minimum GHC to 6.4.1 from 6.4.0

[Darren Duncan]

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 like there are system bundled versions to be 
concerned with, unlike perl 5 where it can be a not install vs 
install; with ghc its install A vs install B.


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.


-- Darren Duncan

Re: raising Pugs' minimum GHC to 6.4.1 from 6.4.0

[Darren Duncan]

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 dependency up?

Jesse


Then we don't have to bump the gcc dependency down.

AFAIK, gcc is pre-installed on many systems, but ghc is not.

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.


If ghc 6.4.1 is required, then users don't have to worry about what 
version their gcc is.


As Luqui pointed out, the only people that my proposal would make 
more work for is those with 6.4.0 already installed.


They would have installed that explicitly, and so knowing how to do 
that, installing 6.4.1 explicitly is a well known path.


And people that use the recommended (by ghc folks) of using the 
binary packages, this will only take a few minutes time.


So we get simpler install situation over all, and pugs can be free to 
exploit 6.4.1 additions if it wants to, and not work around 6.4.0 
bugs.


-- Darren Duncan

Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Chris Dolan]

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 custom META.yml creation code in a big eval, there would not  
have been a problem.  Furthermore, it seems to me that you are  
reinventing the wheel by adding custom META.yml code to the  
Makefile.PL of every package you write instead of, say, using  
Module::Build or just omitting the non-essential META.yml customization.


The ultimate solution, of course, is that there will be a standard  
way to generate proper META.yml.  In the meantime, however, it is my  
opinion that we're better off lacking META.yml than having a  
proliferation of different solutions to the META.yml issues.


Chris

On Jan 28, 2006, at 4:26 AM, Tels wrote:


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.PL uses YAML  
for me

(e.g. the author) to create a META.yml file with a license field,
something that MakeMaker (could?) can't do.

I used "require YAML;" to avoid that the user has to has it installed.

Unfortunately, YAML got changed, and now you also need "require
YAML::Node;" for my Makefile.PL working properly. :-(

So you can either:

* patch my Makefile.PL
* patch YAML to work like the previous version, then update it on  
CPAN,

  then install it

The latter is way more work, and needs time and due to what you wrote
above, might even not work.

I'd say keep the dependencies out of YAML ("KISS"!). Whether YAML  
should

also load YAML::Node when you do "require YAML;" is a point for
discussion, but it certainly tripped up a *lot* of existing  
Makefiles and

I don't have the time to patch them all because that requires me to
release a dozend or so modules.

Sorry for the problem, but it is only partly my fautl :)

Best wishes,

Tels

--
 Signed on Sat Jan 28 11:22:01 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 This email violates EU patent EP0394160:

   [ ## 66%    ]



--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: Fwd: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz

[Yitzchak Scott-Thoennes]

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 indicators. It also includes a
> > script calls cpants_lint.pl which is basically a frontend to the
> > module.
> 
> Very cool.
> 
> However, I am _really really_ starting to wonder whether we need a 
> Kwalitee rating based on *excessive usage of prerequisites*.

How about two; one, a point for not having lots of prerequisites,
and another, a point for having lots of prerequisites.  Where
lots is defined as the same number in both cases.