Re: Binary distributions

[David Golden]

Tyler MacDonald wrote:

3) Tests are failing because of ActiveState's build system

For 3), that could mean because the build system itself is screwed
or they don't have some library available.

Phillipe Chaisson aka "Gozer" (one of the mod_perl authors) is
responsible for the ActiveState PPM repositories now, and the he's told me
that if there's an issue with the build system that causes some particular
module's build to fail when it shouldn't, he'll fix it right away if it can
be identified. http://ppm.activestate.com/ contains full logs of every
single package build success and failure, so if a package isn't available,
have a look there and see why/how it failed and let him know.


I've been a little disappointed with "right away" (sorry, Philippe).  I 
sent an email to [EMAIL PROTECTED] just over a week ago about 
the build system using an outdated version of Scalar::Util that doesn't 
have "refaddr". (Which is surprising, since they offer an updated one in 
their repository.)  To date, I haven't even received a ticket response 
acknowledging receipt of my message, much less a fix.


A copy of my email follows:

David Golden wrote:
> Dear ActiveState PPM support:
>
> I am the author of Class::InsideOut.  One of the key features of
> Class::InsideOut is that it provides for robust inside-out objects under
> a win32 pseudo-fork (at least for Perl 5.8 which offers the CLONE
> method).  Given that I wrote it in part to work safely with my own
> ASPerl installation on my win32 laptop, I'm frustrated that I can't get
> it to pass your automated build tests and would like some guidance.
>
> In most cases, the problem appears a dependency failure on
> Scalar-List-Utils, and I suspect the other failures are similarly 
related.

>
> Class::InsideOut requires Scalar::Util 1.09.  My ASPerl 5.8.7 Build 815
> seems to have 1.14.  The PPM repositories themselves have
> Scalar-List-Utils 1.18.  However, it seems like the automated build test
> is using an older Scalar-List-Utils at version 1.07.  The list of
> modules at
> http://aspn.activestate.com/ASPN/Modules/Perl?module_name=S&order=name
> shows 1.06.
>
> I'm a little at a loss as to how to proceed.  Dropping my prereq version
> any further isn't possible as I need 1.09, which provides the refaddr
> function.  Could the automated build farm get an upgraded
> Scalar-List-Utils installed?  Even getting to 1.09 with refaddr might
> fix a lot of other distributions that depend on it, too.
>
> I look forward to your thoughts.
>
> Sincerely,
>
> David Golden
>

Re: Binary distributions

[Tels]

Moin Offer Kaye (sorry, can't identify which part of your name which is 
the one you are called by :-)

On Sunday 05 February 2006 07:59, Offer Kaye wrote:
> On 1/28/06, Tels wrote:
> > 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.
>
> This email, and the entire discussion that followed, was very Linux
> centric. Correct me if I'm wrong, but for Windows this argument is a
> non-issue, right? I mean, compile a module for Windows and it will
> most likely work for all versions. Or at least the latest ones
> (2000/XP).

This is a common pitfall :) While Windows doesn't have as many 
"distribution" as linux has, there enough to make the "compile once, run 
everywhere" thing to fail in the long run (but as murphy says, you 
realize this only after having spent considerable time to make it work :D

It will work for pure-perl modules (as least when the prereqs are meet), 
that is true. And I have successfully bundled these together with scripts 
and the "use lib" mantra and deploied them on various machines.

But as soon as you need to compile something or need certain libs, DLLs, 
or window components, you step up in the wonderfull world of different 
compilers, linkers, run-time libs, service packs etc. 

I think with linux this is more in the mindset of the developers (you know 
that the systems differ wildly), while a lot windows people tend to 
ignore these things thinking "it doesn't apply to windows right?" and 
then you end up with non-working apps because the author had MS Access, 
service pack 2, the SDK and a compiler (and some unspecified updates that 
came with an MS Office update) installed, while the user machine has none 
of this.

> Why not start off by providing ppm.cpan.org (as the OP suggested for
> linux distors), or something similar? There are many modules that I
> want to use where the PPM version provided by ActiveState or some
> other repository is badly of out date.

Are you talking about ppm for windows or linux?

For linux:

But what would be the point of distributing the binary versions when you 
can download the source and compile/link it yourself?

(Yes, I see the point, but it would bloody much work for a few selected 
distributions.)

For windows:

Why not fix activestates build system first? Their solution seems to be 
"80% there" :)

> I guess that many more people use Perl on Linux boxes, but there are
> still uses for Perl on Windows... ;-)

I pass the chance to make bad puns :)

> It would be wonderful to be able to fully use CPAN on Windows, with
> the same level of comfort that today's pre-packged PPM files already
> provide.

I thought that CPAN already works on windows?

Best wishes,

Tels

-- 
 Signed on Sun Feb  5 12:44:18 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 I'm a Sis-sis-sis-sis-sis-sis-sis-sinnahr...



pgpfRiXogmEY4.pgp
Description: PGP signature

Re: Binary distributions

[Adam Kennedy]

Tyler MacDonald wrote:

Offer Kaye <[EMAIL PROTECTED]> wrote:

Why not start off by providing ppm.cpan.org (as the OP suggested for
linux distors), or something similar? There are many modules that I
want to use where the PPM version provided by ActiveState or some
other repository is badly of out date..


ActiveState always serves the last available version where all tests
passed on a given platform. It attempts to build and test every package on
CPAN at least once a week. If something isn't available, it means the tests
failed, which could mean:

1) Tests are failing because it's windows

2) Tests are failing because they're failing everywhere else as well

3) Tests are failing because of ActiveState's build system

For 3), that could mean because the build system itself is screwed
or they don't have some library available.

Phillipe Chaisson aka "Gozer" (one of the mod_perl authors) is
responsible for the ActiveState PPM repositories now, and the he's told me
that if there's an issue with the build system that causes some particular
module's build to fail when it shouldn't, he'll fix it right away if it can
be identified. http://ppm.activestate.com/ contains full logs of every
single package build success and failure, so if a package isn't available,
have a look there and see why/how it failed and let him know.


How about 
http://ppm.activestate.com/BuildStatus/5.8-windows/windows-5.8/Scalar-List-Util-1.15.txt


I've mentioned this a number of times over the last 6 months, including 
in person at OSCON.


It passes tests, but still gets marked as FAIL, and then everything in 
CPAN that needs Scalar::Util (recursively) does an automatic shortcut 
FAIL without checking to see of the core version is new enough.


Adam K

Re: TODO test paradox: better TODO test management?

[demerphq]

On 2/1/06, chromatic <[EMAIL PROTECTED]> wrote:
> Having the test suite quit and say "Sorry, don't use this -- it works better
> than we expect" seems awfully silly.  Again, there's already a way to catch
> your (rare) catastrophic bonus tests -- capture and check their return
> values.

Yes it is silly.  But I never suggested that should happen.

What I said was that if a TODO passes then its an error. Its either an
error in the tests or its an error in the code. One of the two. And
thats not really something up for debate is it?

(Well, i guess maybe it is if we going to contemplate programmers
creating BS todo tests just so they can pass But thats just as
silly as what you said.)

So if there is an error presumably the test harness should be
indicating, in detail, what that error is. That is after all the
purpose of a test harness is it not?

The error need not be considered fatal, nor suggest the code shouldnt
be used (although i think a user would be entitled to be suspicious of
code like this) but it should be clear that the code didnt behave as
expected.

At the very least its something that can be communicated back to the
author so that he knows about the test passing successfully. This is
useful information to the author and given the wide range of
enviornments we build Perl and Perl modules in, its very likely that
such information is unavailable to the author directly.

I find the position that the test harness should NOT provide more info
on this subject incomprehensible. What damage would occur if the test
results provided a proper summary of TODO unexpected successes?

Yves



--
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: TODO test paradox: better TODO test management?

[demerphq]

On 2/5/06, demerphq <[EMAIL PROTECTED]> wrote:
> On 2/1/06, chromatic <[EMAIL PROTECTED]> wrote:
> > Having the test suite quit and say "Sorry, don't use this -- it works better
> > than we expect" seems awfully silly.  Again, there's already a way to catch
> > your (rare) catastrophic bonus tests -- capture and check their return
> > values.
>
> Yes it is silly.  But I never suggested that should happen.

Er, shoot, actually I did. I said:

> If they unexpectedly succeed IMO they should be treated as if a test failed.

But in the context of

> Harness should provide better info. Todo tests are important.

I now realize that this misunderstanding is my fault. I apologize for that.

All i want is a proper report of TODO passes so the end user can
easily communicate that infromation to the author.  Without telling
end users that they should run the tests in verbose mode and grep out
the appropriate lines. I think thats the job of the harness in the
first place.

Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Binary distributions

[Shlomi Fish]

On Sunday 05 February 2006 13:54, Tels wrote:
> Moin Offer Kaye (sorry, can't identify which part of your name which is
> the one you are called by :-)
>

Just for everybody's information:

Offer is his first name. (Means "Bambi" in Hebrew). Kaye is his last name. 
(Don't know what it means - it's a name of foreign origin).

Regards,

Shlomi Fish

-
Shlomi Fish  [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/

95% of the programmers consider 95% of the code they did not write, in the
bottom 5%.

Re: Binary distributions

[Offer Kaye]

On 2/5/06, Shlomi Fish wrote:
> On Sunday 05 February 2006 13:54, Tels wrote:
> > Moin Offer Kaye (sorry, can't identify which part of your name which is
> > the one you are called by :-)
> >
>
> Just for everybody's information:
>
> Offer is his first name. (Means "Bambi" in Hebrew).

Moin Tels, don't blame you for getting confused :)

Shlomi, not sure everyone saw Disney movies as a kid ;)
"Offer" means a "young deer" in Hebrew is what Shlomi meant. Another
English word for that is "fawn". But I don't ;)


--
Offer Kaye

Default tests, beta testing, etc.

[Bryce Harrington]

Chromatic and I were discussing CPAN testing at a conference yesterday.
I made some comments about things that I thought would be useful and he
encouraged me to post them here...


Default tests - Like probably a lot of perl module writers, I don't
  write tests nearly as often as I should, but I have collected a few
  simple default tests that I can toss into a new module and reuse
  without modification.  For example:

  http://search.cpan.org/src/BRYCE/Test-Parser-1.00/t/00_initialize.t
  http://search.cpan.org/src/BRYCE/Test-Parser-1.00/t/01_script_compile.t
  http://search.cpan.org/src/BRYCE/Test-Parser-1.00/t/zz_dump_config.t

  It would seem to be useful if CPAN were to have a couple really basic
  tests like this to run for perl modules that haven't created any tests
  themselves.

  Obviously, this only benefits immature modules, but this might be a
  good way to motivate new authors to put more attention into testing.


Beta testing - CPAN tracks intra-module dependencies, and does automated
  testing, but only on released modules.  It would seem useful to allow
  an author to upload a "beta" version of their module, and then run the
  tests of a dozen or so modules that depend on it.  This way, you would
  gain confidence that your next release won't break everyone else's
  code (or be able to explain why, if it must.)

  Obviously, this testing would mostly just benefit core modules, but
  you could argue that those are probably the ones most in need of solid
  QA.  This could save worry time for the core module authors, allowing
  them to focus more of their energy into improvements.


Automatic module patching - Wikipedia has a process for creating "bots"
  to do certain mundane updates across a number of pages.  For instance,
  one bot inserts information from the CIA Factbook for all cities and
  nations.

  It would be interesting to have mechanisms like this that browsed
  through the module list looking for common omissions or errors in
  modules, and then automatically send the author a patch to fix it.
  For instance, if the author didn't properly fill out the COPYRIGHT,
  , or SYNOPSIS, a tool could generate a patch with some
  suitable guesses.  Or, a script could google for published articles
  about or mentioning the module, and create a patch that lists the top
  5 or so in the SEE ALSO section.

  I imagine this process could become extremely invaluable for doing
  large scale upgrades to bring modules forward into Perl 6.  For
  instance, if it is decided to switch MakeMaker or other low level
  modules, then the ability to programmatically generate patches to
  upgrade modules would probably help push authors to upgrade their
  modules much faster.

Bryce

Re: Binary distributions

[Offer Kaye]

On 2/5/06, Tyler MacDonald wrote:
>
>ActiveState always serves the last available version where all tests
> passed on a given platform. It attempts to build and test every package on
> CPAN at least once a week. If something isn't available, it means the tests
> failed, which could mean:
>

Just an example, IO::All [1] version 0.33 has been available since Dec
17, 2004. It passed testing many times, at least according to its
testers page [2]. My default 5.8.7 ActivePerl distribution lists
IO::All version 0.17 .

I'm not sure which of the reasons you listed are valid, as a user I
have no real way of knowing... that's why I thought an automated
Windows-PPM sub-domain on CPAN which would be updated automatically
for every new package would be great. What you are saying, that
ActiveState already have such a system, is news to me, especially in
view of examples such as the above... I would rather use CPAN, but the
PPM works fine for me, only it's not as updated as CPAN.

[1] http://search.cpan.org/dist/IO-All/
[2] http://testers.cpan.org/show/IO-All.html#IO-All-0.33

>
>Phillipe Chaisson aka "Gozer" (one of the mod_perl authors) is
> responsible for the ActiveState PPM repositories now,

Hi Gozer, nice to meet you. Gratz on ActiveState's move to a new
company, good luck :)

> and the he's told me
> that if there's an issue with the build system that causes some particular
> module's build to fail when it shouldn't, he'll fix it right away if it can
> be identified. http://ppm.activestate.com/ contains full logs of every
> single package build success and failure, so if a package isn't available,
> have a look there and see why/how it failed and let him know.
>
>Cheers,
>Tyler
>

Cool! Didn't know about the http://ppm.activestate.com/ . Looking at
the IO-All package, I see it failed because of the prereq Spiffy.
Looking at Spiffy, it failed because of Scalar-List-Util [3]. Which is
funny because it turns out to be a problem for other people, who
mentioned it in other replies to this thread... :)

[3] 
http://ppm.activestate.com/BuildStatus/5.8-windows/windows-5.8/Scalar-List-Util-1.15.txt

I'd like to clarify something - I don't really expect Gozer to handle
this problem... or a problem with any other module... there are so
many, how can a single person keep up?
It would be better if the system were automated... and worked :)

BTW Gozer have you looked at the first line:
Cannot forceunlink D:\cpanrun\build\5-8-0\lib\auto\List\Util\Util.dll:
Permission denied at D:\cpanrun\build\5-8-0\lib/File/Find.pm line 874

Maybe the script is trying to delete a file that the system thinks is
in use? Or something similiar? Windows has that annoying habit of
refusing to delete things it thinks are in use...

Moin Tels,
Regarding what you said, of course the problem is with non pure-Perl
modules. For pure-Perl ones, I can use CPAN... and yes, I'm only
talking about Windows. Forgot there was PPM for other archs until you
reminded me :)
I would rather not use 2 seperate package installation schemes...
either CPAN or PPM (or something else), not both.
As for the problem of different DLLs etc., I don't think any of
Blizzard's 5.5 million customers have ever had a problem installing
WoW because they were missing a DLL from some Office version... Just
to give an example... why should a PPM package be any different? Yes,
I'm a noob when it comes to these things, sorry :)

Cheers,
--
Offer Kaye

Re: Binary distributions

[Tyler MacDonald]

Offer Kaye <[EMAIL PROTECTED]> wrote:
> Just an example, IO::All [1] version 0.33 has been available since Dec
> 17, 2004. It passed testing many times, at least according to its
> testers page [2]. My default 5.8.7 ActivePerl distribution lists
> IO::All version 0.17 .

According to
http://ppm.activestate.com/BuildStatus/5.8-windows/windows-5.8/IO-All-0.33.txt
it is not being built because Spiffy failed it's tests. According to
Spiffy's log, *it* did not build becuase Scalar-List-Utils failed to
build... Which is the same module that both Adam Kennedy and David Golden
are complaining about. (I wonder how many modules are being held back over
this one bug?)

> I'm not sure which of the reasons you listed are valid, as a user I
> have no real way of knowing... that's why I thought an automated
> Windows-PPM sub-domain on CPAN which would be updated automatically
> for every new package would be great. What you are saying, that
> ActiveState already have such a system, is news to me, especially in
> view of examples such as the above... I would rather use CPAN, but the
> PPM works fine for me, only it's not as updated as CPAN.

I think it's a combination of "too much to do, too little time" and
the QA philosophy of ActiveState. On ppm.activestate.com, if the unit tests
fail, you don't get a PPM; I guess this "protects" ActivePerl users from
installing modules that won't work properly on their install.

ppm.cpan.org would be a good idea and probably not too hard to
implement. What would it's mandate be? Provide every package out there, even
if unit tests fail, so long as it acutally built? Who is going to provide
the icky sticky windows box with VC++-compiled versions of all the libraries
people expect to be able to use with perl (libgd, libmysqlclient,
apache2, etc)? I certainly don't want to lay my hands on any windows box.
;-)

> I'd like to clarify something - I don't really expect Gozer to handle this
> problem... or a problem with any other module... there are so many, how
> can a single person keep up? It would be better if the system were
> automated... and worked :)

I think if the module is close to the metal and a lot of other
modules depend on it, it would be worth ActiveState's time to investigate
the problem and either fix the build system or fix the module. It's a big
payoff if fixing one module means that all of a sudden another 30 or so
automagically build.

> I would rather not use 2 seperate package installation schemes...
> either CPAN or PPM (or something else), not both.

I think those two schemes are exactly what we need for perl. It's
analogous to building and installing a source package, or just installing
the latest RPM/.deb/whatever.


- Tyler

Re: Binary distributions

[Tyler MacDonald]

Offer Kaye <[EMAIL PROTECTED]> wrote:
> >Phillipe Chaisson aka "Gozer" (one of the mod_perl authors) is
> > responsible for the ActiveState PPM repositories now,
> Hi Gozer, nice to meet you. Gratz on ActiveState's move to a new
> company, good luck :)

It's a Good Thing for all companies involved, but as a developer for
Sophos, I'll certainly miss having them upstairs. (Not to mention the
@activestate.com email addy ;-)

- Tyler

Re: Default tests, beta testing, etc.

[Chris Dolan]

On Feb 5, 2006, at 2:36 PM, Bryce Harrington wrote:


[snip]
  It would seem to be useful if CPAN were to have a couple really  
basic
  tests like this to run for perl modules that haven't created any  
tests

  themselves.

  Obviously, this only benefits immature modules, but this might be a
  good way to motivate new authors to put more attention into testing.


I recommend Test::Distribution for this type of "default" tests.  It  
looks for .pm files in blib and performs a bunch of tests on them --  
POD, compile, version, etc.



[snip]


Chris
--
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: Default tests, beta testing, etc.

[Michael Peters]

Bryce Harrington wrote:

> Beta testing - CPAN tracks intra-module dependencies, and does automated
>   testing, but only on released modules.  It would seem useful to allow
>   an author to upload a "beta" version of their module, and then run the
>   tests of a dozen or so modules that depend on it.  This way, you would
>   gain confidence that your next release won't break everyone else's
>   code (or be able to explain why, if it must.)
> 
>   Obviously, this testing would mostly just benefit core modules, but
>   you could argue that those are probably the ones most in need of solid
>   QA.  This could save worry time for the core module authors, allowing
>   them to focus more of their energy into improvements.

I like this idea, especially running tests on an uploaded distribution before it
becomes a "real" release. I know I've caught myself several times when my tests
run just fine, I upload to CPAN and then differences in the way the CPAN shell
runs my tests cause it to fail. It would have been nice to catche these failures
before others start upgrading.

-- 
Michael Peters
Developer
Plus Three, LP

IPC::Run or something else?

[Tamas Dober]

Hello,

I'm a beginner, please forgive me b/c of the simple questions.

I'd like to test that that a batch file (starting a Java app) gives me the 
expected output or not.

What I have now:

use strict;
use warnings;   
use IPC::Run 'run';
my $out;
my @ls = ( '\/perl\/Feb\/packager\/bin\/package.bat' ) ;
run [EMAIL PROTECTED], \undef, \$out or die "bat returned $?" ; 
like($out, qr/Usage/, 'Usage message'  );
is( $out =~ /config/, 'this is like that');

--

The outcome:

C:\perl\Feb\packager\bin>prove -v Run2.t
Run21..2

Usage: 
-config[Configuration XML URL]
-request   [Request XML URL]
--help

not ok 1 - Usage message
#   Failed test 'Usage message'
#   in Run2.t at line 8.
#   '
#
#
# '
# doesn't match '(?-xism:Usage)'

not ok 2
#   Failed test in Run2.t at line 9.
#  got: ''
# expected: 'this is like that'
# Looks like you failed 2 tests of 2.


It seems I couldn't redirect the output.
Maybe IPC::Run is not a good choice?
If I try it under LINUX (using package.sh instead of package.bat) I'm having 
the same issue.

Could you please help me what direction I should go, what module should I use?

Thank you

Tamas



-
 Yahoo! Mail - Helps protect you from nasty viruses.

Re: IPC::Run or something else?

[Tyler MacDonald]

Tamas Dober <[EMAIL PROTECTED]> wrote:
> Hello,
> 
> I'm a beginner, please forgive me b/c of the simple questions.
> 
> I'd like to test that that a batch file (starting a Java app) gives me the 
> expected output or not.

I really like IPC::Run, but it is a bit of a heavy package to make
users install just for your test cases. If your module is already using it
for something else, go for it! Otherwise i'd suggest just opening a pipe if
you don't need bidirectional communication;

open(my $fh, '-|', "@ls");
my $out = join('', <$fh>);
...

Cheers,
Tyler

> use warnings;   
> use IPC::Run 'run';
> my $out;
> my @ls = ( '\/perl\/Feb\/packager\/bin\/package.bat' ) ;
> run [EMAIL PROTECTED], \undef, \$out or die "bat returned $?" ; 
> like($out, qr/Usage/, 'Usage message'  );
> is( $out =~ /config/, 'this is like that');



> 
> --
> 
> The outcome:
> 
> C:\perl\Feb\packager\bin>prove -v Run2.t
> Run21..2
> 
> Usage: 
> -config[Configuration XML URL]
> -request   [Request XML URL]
> --help
> 
> not ok 1 - Usage message
> #   Failed test 'Usage message'
> #   in Run2.t at line 8.
> #   '
> #
> #
> # '
> # doesn't match '(?-xism:Usage)'
> 
> not ok 2
> #   Failed test in Run2.t at line 9.
> #  got: ''
> # expected: 'this is like that'
> # Looks like you failed 2 tests of 2.
> 
> 
> It seems I couldn't redirect the output.
> Maybe IPC::Run is not a good choice?
> If I try it under LINUX (using package.sh instead of package.bat) I'm having 
> the same issue.
> 
> Could you please help me what direction I should go, what module should I use?
> 
> Thank you
> 
> Tamas
> 
> 
>   
> -
>  Yahoo! Mail - Helps protect you from nasty viruses.

Re: IPC::Run or something else?

[David Golden]

Tamas Dober wrote:

I'd like to test that that a batch file (starting a Java app) gives me the 
expected output or not.
Could you please help me what direction I should go, what module should I use?


I've had good experiences with IPC::Run3.  It's pretty lightweight and 
intuitive.


If you would like to see examples of how I have used it, look at the 
test files for ExtUtils::ModuleMaker::TT -- particularly 
t/20_makeperlmod.t and t/CLI.pm.


Best of luck,

David Golden

Re: Default tests, beta testing, etc.

[Sébastien Aperghis-Tramoni]

Bryce Harrington wrote:


Default tests - Like probably a lot of perl module writers, I don't
  write tests nearly as often as I should, but I have collected a few
  simple default tests that I can toss into a new module and reuse
  without modification.  For example:

  http://search.cpan.org/src/BRYCE/Test-Parser-1.00/t/00_initialize.t


A similar one is created when creating a distribution with  
Module::Starter.


   
http://search.cpan.org/src/BRYCE/Test-Parser-1.00/t/> 01_script_compile.t

  http://search.cpan.org/src/BRYCE/Test-Parser-1.00/t/zz_dump_config.t

  It would seem to be useful if CPAN were to have a couple really basic
  tests like this to run for perl modules that haven't created any  
tests

  themselves.


Might be useful, but you can unfortunately assume very little as you  
don't know anything about the distribution. For example,  
Test::Distribution (as someone else mentioned it in another mail) is  
very useful, but doesn't work in every cases. I had to disable some of  
its tests for some of my modules because of the way the distribution  
are made.


Beta testing - CPAN tracks intra-module dependencies, and does  
automated

  testing, but only on released modules.  It would seem useful to allow
  an author to upload a "beta" version of their module, and then run  
the
  tests of a dozen or so modules that depend on it.  This way, you  
would

  gain confidence that your next release won't break everyone else's
  code (or be able to explain why, if it must.)


Using CPANTS to know what modules depend upon yours and PITA for the  
testing subsystem will be a way to test such things.



  Obviously, this testing would mostly just benefit core modules, but
  you could argue that those are probably the ones most in need of  
solid

  QA.  This could save worry time for the core module authors, allowing
  them to focus more of their energy into improvements.


For core modules, there's already a better system: we can send patches  
to P5P and ask for test on the smoke boxes. They cover more systems  
than CPAN Testers, including commercial Unix like Solaris, HP/UX and  
AIX, and even rare systems like OSF and VMS.



  I imagine this process could become extremely invaluable for doing
  large scale upgrades to bring modules forward into Perl 6.  For
  instance, if it is decided to switch MakeMaker or other low level
  modules, then the ability to programmatically generate patches to
  upgrade modules would probably help push authors to upgrade their
  modules much faster.


For core modules, there're only two words: backward compatibility.
Micheal Schwern has already expressed several times why he mostly  
couldn't add new feature in ExtUtils::MakeMaker: because all the  
Makefile.PL that currently exist must continue to work with any new  
version of EU::MM, and unfortunately, many use it in strange and  
twisted way that could easily be broken by new features.



Sébastien Aperghis-Tramoni
 -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]
Close the world, txEn eht nepO

Re: Default tests, beta testing, etc.

[A. Pagaltzis]

* Bryce Harrington <[EMAIL PROTECTED]> [2006-02-05 21:40]:
> http://search.cpan.org/src/BRYCE/Test-Parser-1.00/t/01_script_compile.t

I know this is beside the point, but I have to point out that
this script will break on at least Windows – and probably every
other non-Unix OS as well.

* Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]> [2006-02-06 02:25]:
>you can unfortunately assume very little as you  don't know
>anything about the distribution. For example, Test::Distribution
>(as someone else mentioned it in another mail) is very useful,
>but doesn't work in every cases. I had to disable some of its
>tests for some of my modules because of the way the distribution
>are made.

Well, at the base level, you know *nothing* about a distribution,
because CPAN doesn’t actually require any particular structure at
all – it could be a tarball with exactly one .pm file for all you
know. But I think it’s still useful to try to test a distribution
enough to automatically determine that “this cannot be installed
from the CPAN shell” and let users know about the result.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Binary distributions

[Offer Kaye]

On 2/5/06, Offer Kaye wrote:
>
> [3] 
> http://ppm.activestate.com/BuildStatus/5.8-windows/windows-5.8/Scalar-List-Util-1.15.txt
>

Something funky here...
Last night I looked at "Scalar-List-Util"... but the correct name as
Tyler said is "Scalar-List-Utils", with an "s" at the end.

Looking at [1] I see listed both "Scalar-List-Util" version 1.15, with
a status of "FAIL" of Windows, and "Scalar-List-Utils" version "N/A",
with a status of "CORE" on Windows. If you look at the report for it,
it also fails.

"Scalar-List-Utils" seems to be the correct one... CPAN doesn't know
about any "Scalar-List-Util"... Gozer, maybe if you removed the false
entry (Scalar-List-Util) it will solve the problem and let
Scalar-List-Utils pass correctly?

OT question - why is Scalar-List-Utils listed as "CORE"? It is not
part of the Perl5 core, does it mean it is part of ActiveState's core?
Just wondering...

[1] http://ppm.activestate.com/BuildStatus/5.8-S.html

Cheers,
--
Offer Kaye

Re: IPC::Run or something else?

[Yuval Kogman]

On Sun, Feb 05, 2006 at 15:42:26 -0800, Tamas Dober wrote:

> It seems I couldn't redirect the output.

This is probably because the program prints on STDERR. Look into the
redirect examples, and try to also capture \$err after \$out - see
if that helps

> Maybe IPC::Run is not a good choice?

I think it's a very good choice.


-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me does a karate-chop-flip: neeyah!!



pgpBJNCaqSLbk.pgp
Description: PGP signature

Re: Binary distributions

[Yitzchak Scott-Thoennes]

On Mon, Feb 06, 2006 at 08:16:11AM +0200, Offer Kaye wrote:
> OT question - why is Scalar-List-Utils listed as "CORE"? It is not
> part of the Perl5 core

http://perldoc.perl.org/perl58delta.html#New-Modules-and-Pragmata

Re: Binary distributions

[Offer Kaye]

On 2/6/06, Yitzchak Scott-Thoennes wrote:
>
> http://perldoc.perl.org/perl58delta.html#New-Modules-and-Pragmata
>

I see what you mean... what threw me off was that it is not listed under:
http://search.cpan.org/dist/perl-5.8.8/

Cheers,
--
Offer Kaye

Re: Default tests, beta testing, etc.

[Adam Kennedy]

Beta testing - CPAN tracks intra-module dependencies, and does automated
  testing, but only on released modules.  It would seem useful to allow
  an author to upload a "beta" version of their module, and then run the
  tests of a dozen or so modules that depend on it.  This way, you would
  gain confidence that your next release won't break everyone else's
  code (or be able to explain why, if it must.)


Using CPANTS to know what modules depend upon yours and PITA for the 
testing subsystem will be a way to test such things.




In fact, what you just asked is already listed in the PITA documentation 
as within it's scope.


For lack of a better name, I've called it Fallout Testing.

As opposed to Rot Testing, which is when your module doesn't change, but 
makes sure it still works as Perl is upgraded and your dependencies evolve.


Since I've got a terribly bad habit of inventing things that have 
existing names, I'm sure someone will correct my on the two above namings.


Adam K

Re: IPC::Run or something else?

[Adam Kennedy]

David Golden wrote:

Tamas Dober wrote:
I'd like to test that that a batch file (starting a Java app) gives me 
the expected output or not.
Could you please help me what direction I should go, what module 
should I use?


I've had good experiences with IPC::Run3.  It's pretty lightweight and 
intuitive.


If you would like to see examples of how I have used it, look at the 
test files for ExtUtils::ModuleMaker::TT -- particularly 
t/20_makeperlmod.t and t/CLI.pm.


Best of luck,

David Golden



I second this. IPC::Run3 has treated me well on a few occasions, and I'm 
gradually porting various things of mine over to IPC::Run3 as they come 
to my attention for other issues.


Adam K

Re: IPC::Run or something else?

[Yuval Kogman]

On Mon, Feb 06, 2006 at 18:38:32 +1100, Adam Kennedy wrote:

> I second this. IPC::Run3 has treated me well on a few occasions, and I'm 
> gradually porting various things of mine over to IPC::Run3 as they come to my 
> attention for other issues.

It looks like the ugprade path from IPC::Run3 to IPC::Run is quite
easy. If you sever do need weird callbacks, several processes at a
time, or PTY support it should be an easy switch. However, for the
mean while IPC::Run3 is probably just what you need.

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: *shu*rik*en*sh*u*rik*en*s*hur*i*ke*n*: neeyah



pgpSkk9Ri9Pkg.pgp
Description: PGP signature

Re: Binary distributions

[Adam Kennedy]

Tyler MacDonald wrote:

Offer Kaye <[EMAIL PROTECTED]> wrote:

Just an example, IO::All [1] version 0.33 has been available since Dec
17, 2004. It passed testing many times, at least according to its
testers page [2]. My default 5.8.7 ActivePerl distribution lists
IO::All version 0.17 .


According to
http://ppm.activestate.com/BuildStatus/5.8-windows/windows-5.8/IO-All-0.33.txt
it is not being built because Spiffy failed it's tests. According to
Spiffy's log, *it* did not build becuase Scalar-List-Utils failed to
build... Which is the same module that both Adam Kennedy and David Golden
are complaining about. (I wonder how many modules are being held back over
this one bug?)


Certainly hundreds. Even within just my modules it's several dozen, 
including the entire PPI tree, and everything related.


Including all recursion, possibly as many as 1000+ distributions are 
dead over that one problem.


And it keeps hanging around, and it keeps not getting fixed...

And the only thing that makes the situation worse, is that it never 
seems to be acknowledged, and we don't get any information.


But I'm not really too worried any more, the CamelPack means it's much 
easier not to just install from source than use the PPM system.


Adam K