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: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule

[Leopold Toetsch]

On Feb 5, 2006, at 8:17, Allison Randal wrote:


On Feb 4, 2006, at 16:51, Joshua Isom via RT wrote:

 41 callmethodcc P1, "dump"  -
P1=Object(PAST::Node)=PMC(0x50ba68),
102 get_params PMC_C[29] (2), P0, I0 - , P0=PMCNULL,
I0=5289976
106 repeat S0, "", I0- , , I0=5289976


Okay, the problem seems to be that it's getting garbage values in 
"optional" integer parameters if the parameters aren't passed in. So, 
the PIR code is calling the 'dump' method with no parameters:


.sub "dump" method
.param int level

The level argument isn't optional at all. Turning on argument count 
checks would prevent such errors.

It has to be:

.sub "dump" method
.param int level :optional


Allison


leo

Param count checks

[Leopold Toetsch]

I've temporarely turned on [1] strict args/param count mismatch errors.  
Doesn't look too good. WRT return/results count mismatch, I think, this  
should be a little less strict and allow 'void' function calls of  
functions that return something [2]. But that's a different issue.


Failed Test Stat Wstat Total Fail  Failed  List of  
Failed
 
---

t/compilers/imcc/syn/objects.t 1   256111   9.09%  5
t/compilers/imcc/syn/pcc.t 1   256211   4.76%  7
t/compilers/tge/grammar.t  1   256 11 100.00%  1
t/examples/streams.t   7  1792127  58.33%  1-3 5-8
t/library/dumper.t 2   512272   7.41%  12-13
t/library/parrotlib.t  1   256 61  16.67%  6
t/library/streams.t8  2048208  40.00%  9-11  
13-16 19

t/library/test_builder_tester.t1   256128  66.67%  9-12
t/library/test_more.t  1   25620   40 200.00%  1-20
t/pmc/coroutine.t  1   256101  10.00%  2
t/pmc/mmd.t1   256301   3.33%  11
t/pmc/object-meths.t   1   256331   3.03%  12
9 tests and 710 subtests skipped.
Failed 12/228 test scripts, 94.74% okay. 48/4858 subtests failed,  
99.01% okay.


Punie is failing almost half of it's tests. I didn't check other  
languages.


Fixes welcome
leo

[1]

--- src/inter_create.c  (Revision 11421)
+++ src/inter_create.c  (Arbeitskopie)
@@ -175,9 +175,9 @@
 PARROT_ERRORS_off(interpreter, PARROT_ERRORS_ALL_FLAG);
 /* undefined globals are errors by default */
 PARROT_ERRORS_on(interpreter, PARROT_ERRORS_GLOBALS_FLAG);
+PARROT_ERRORS_on(interpreter, PARROT_ERRORS_PARAM_COUNT_FLAG );
 #if 0
 /* TODO not yet - too many test failures */
-PARROT_ERRORS_on(interpreter, PARROT_ERRORS_PARAM_COUNT_FLAG );
 PARROT_ERRORS_on(interpreter, PARROT_ERRORS_RESULT_COUNT_FLAG );
 #endif

[2] generalized: a function could be allowed to return more  
(positionals?) than get_results is using.

Re: A GraphViz eye view of Parrot

[Nicholas Clark]

On Sat, Feb 04, 2006 at 11:18:59PM -0800, Allison Randal wrote:

> It's just a Perl script, so yeah, could be done. Is it valuable  
> enough to spend the time? I was thinking of it as more of a one-off  
> for the heck of it.

I don't know, and I'm not in a good position to judge given that I've not
yet convinced any of my hardware to display it for me.

No-one else has commented, let alone expressed interest in playing with the
script themselves, so current feedback seems to be "not really worth it".
Particularly as I'm inferring that time spent on this reduces time spent on
Punie. (And as I've not had occasion to say it before, thanks for all the
time you're donating to Punie and the tools it creates)

Nicholas Clark

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



pgptsfeBDEKvn.pgp
Description: PGP signature

Universal Roles, and deriving these roles for any class

[Yuval Kogman]

Background:

At work we have a big C++ project. I just added a new object, and
now $boss asked me to add the send/receive interface. These two
methods allow an object to be serialized to and from a stream.
Essentially it means

// superclass methods for core types
sendInt(int_member);
sendString(string_member);

// all object members need to also inherit Serializable
obj->send(socket);

and

receiveInt(int_member);
receiveString(string_member);
obj = new Object();
obj->receive(socket);

etc for each member, in the right order with the right type.

This is a dump example since we just do .perl, but let's say pretend
for a moment that we don't.

Perl 6 has some advantages over C++ that make this trivial (or so I
hope):

* a meta model (iterate attributes, know their type, etc)
* roles (no need to inherit Serializable, this is a bit cleaner)
* attitude (this is up for discussion ;-)

I'd like to be able to declare my serializable role as a univeral
role.

This basicaally means:

role Serializable {
method send ( Stream $fh ) {
# iterate all attrs
my Serializable $attr = $?SELF.meta.get_attr;
...
}

method receive ( Stream $fh ) {
# iterate all attrs
...
}
}

# core types
Num does Serializable {
method send ( Stream $fh ) {
$fh.print( "$?SELF" );
}
}

and then to never say that any class does it. Instead, i'd like to
have a duck typing like approach:

my Serializable $x = Monkey.new();
# or
my $x = Monkey.new but Serializable;

# and then
$x.send( $socket ); # no ambiguity

And then I'd like to have these features:

* Have type inferrencing type check the send and receive methods
* have it automatically infer that all the attrs of Monkey
  are also Serializable, due to the fact that send iterates
  them and declares that
* get nice errors that tell me that Moneky can't be
  Serializable because the member $stream deep inside an object
  within Monkey (for example, if Anus has Stream ;-) is not
  Serializable, nor can the Serializable role be
  automatically applied to it because it has opaque
  internals.

This probably makes more sense for other interfaces.

This also reminds me a bit of attribute grammars - i'd like to be
able to automatically derive node roles inside AGs by just
specifying a generic universal behavior, and behavior for the
leaves.

Err, comments please =)

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



pgpj8V2131aFs.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: Param count checks

[Roger Browne]

In another thread, Leopold Toetsch wrote:
> ... WRT return/results count mismatch, I think, this  
> should be a little less strict and allow 'void' function calls of  
> functions that return something [2]. But that's a different issue.

Some languages (including Amber) make a clear distinction between
queries (which return something) and commands (which return nothing).

If possible, please make the "little less strict" checking of function
calls be optional, so that fully-strict checking of the return count is
still possible.

Regards,
Roger Browne

Re: Param count checks

[Chip Salzenberg]

On Sun, Feb 05, 2006 at 07:35:17PM +, Roger Browne wrote:
> In another thread, Leopold Toetsch wrote:
> > ... WRT return/results count mismatch, I think, this  
> > should be a little less strict and allow 'void' function calls of  
> > functions that return something [2]. But that's a different issue.
> 
> Some languages (including Amber) make a clear distinction between
> queries (which return something) and commands (which return nothing).
> 
> If possible, please make the "little less strict" checking of function
> calls be optional [...]

Please detail this "query" vs. "command" distinction.  Note I'm doing
requirements gathering rather than asking you to do the design.  On
questions like:

 dynamic vs. static
 determined at call point vs. by called function
 over what scope
   by HLL?
   by namespace?
   other?

You can weigh in on those questions, but don't jump to Solution Land until
you've laid out the problem first.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Is S05 correct?

[Andrew Savige]

--- Larry Wall wrote:
> Yes, that's a typo.

Which reminds me, I noticed some Synopsis typos as follows.

S03:

1) "List flattening" section, sixth paragraph:

  ... call semantics as is does in scalar context

Change "is" to "it".

S04:

1) "The do-once loop" section, last paragraph:

  ... followed by a statment label

Change "statment" to "statement".

2) "Control Exceptions" section, third paragraph:

  ... or by falling of the end of it

Change "of" to "off".

3) "Control Exceptions" section, last paragraph:

  ... in current subroutine. then a fallback search

Change "then" to "Then".

S06:

1) "Parameter and arguments" section, last paragraph:

  ... need to be kept in the list until bound. an implementation

I assume "an" should be "An".

2) "Polymorhpic Types" section, second paragraph:

  Fancier type constrains ...

I assume "constrains" should be "constraints".

3) "Generic Types" section, first paragraph, last sentence:

  It declares the new type name in whatever scope the
  surrounding declaration is associated lexical scope.

I found this phrasing unclear.

4) "Return Types" section, fifth paragraph:

  ... but outside the sub it just we don't know anything

I found this phrasing unclear.

5) "Pairs as lvalues" section, second paragraph:

  ... provided you write hte left side

Change "hte" to "the".

S11:

Though only an example, in the interests of historical
accuracy, I'd like to see:

  use perl5:ACME::Bleach-1.0-DCONWAY;

changed to:

  use perl5:Acme::Bleach-1.12-DCONWAY;

Only Casey West (erroneously) spelled Acme as ACME (to annoy
Leon Brocard). And there never was an Acme::Bleach-1.0; it
was moved from Bleach to Acme::Bleach at version 1.12.

S12:

1) "Methods" section, eleventh paragraph:

  However, you can turn extend any of the legal forms...

I found this phrasing unclear.

2) "Types and Subtypes" section, sixth paragraph:

  ... (takes away capabiliites)

Change "capabiliites" to "capabilities".

S13:

1) "Fallbacks" section, second paragraph:

  That is, you're specify the abstract operation...

I found this phrasing unclear.



Send instant messages to your online friends http://au.messenger.yahoo.com 

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: PGE vs bindings (was Re: embparrot still has two failures)

[Patrick R. Michaud]

On Sun, Feb 05, 2006 at 11:34:33AM +0800, Audrey Tang wrote:
> That seems to be a fatal error at PGE's side:
> 
>$ echo 'rule $x:=[]' | parrot demo.pir
>error:imcc:syntax error, unexpected ']'
>in file 'EVAL_2' line 79
 
I've now updated PGE (r11427) so that it provides a more 
useful exception:

p6rule parse error: Term expected at offset 5, found ']'

> The same error occurs if one replaces [] with <> or ().

The fix also updates the () case; I need to review the <>
case a bit more to get it to work correctly.

Thanks!

Pm

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: Param count checks

[Roger Browne]

I wrote:
> > Some languages (including Amber) make a clear distinction between
> > queries (which return something) and commands (which return nothing).
> > 
> > If possible, please make the "little less strict" checking of function
> > calls be optional [...]

Chip:
> Please detail this "query" vs. "command" distinction.

In some situations, just "looking at something" shouldn't change it. For
example you don't want side-effects in an "assert" statement or the
behaviour of your program will change when you enable or disable runtime
assertion-checking.

Some languages (such as Amber and Eiffel) make a formal distinction
between commands (which can change state but do not return a value) and
queries (which return a value but cannot change state). This is called
command-query separation
http://c2.com/cgi/wiki?CommandQuerySeparation
and is of course very different from the C tradition where "throwing
away the return value" is permitted and commonplace.

In a language where a query cannot change state but can only return a
value, it is necessarily a bug if the returned value is not used.
Therefore, I would like to be able to detect this situation and throw an
exception.

(In its current state, Amber for Parrot does not enforce command-query
separation - but I am moving towards enforcing it at least for
preconditions, postconditions and other assertions).

>  dynamic vs. static

Dynamic. The number of return values expected by the caller must match
the number of return values supplied by the dynamically-selected callee.

>  determined at call point vs. by called function

Determined at every call point, according to the rules of the calling
language.

>  over what scope
>by HLL?
>by namespace?
>other?

The scope is a single call point, in the sense that each test occurs at
a single call point and does not care about the rest of the program.

Furthermore, the test is at the caller's end. For example: if Amber code
calls a Python function, then the Amber code must use the Python return
value according to the rules of Amber. On the other hand, if Python code
calls an Amber function, the Amber function doesn't care what Python
does with the function's return value.

> You can weigh in on those questions, but don't jump to Solution Land ...

A solution is already defined. Leo suggested making it a little less
strict...
   Leo> > ... WRT return/results count mismatch, I think, this  
   Leo> > should be a little less strict and allow 'void' function
   Leo> > calls of functions that return something
... which would probably make life easier for implementors of many
languages, but I'm hoping to retain the option to use the strictest
checking (which will make life easier for me).

Regards,
Roger Browne

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

[perl #38438] r11402 tcl failures

[via RT]

# New Ticket Created by  Will Coleda 
# Please include the string:  [perl #38438]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=38438 >


in r11401, all tcl tests passed on my machine. in r11402, I get  
several test failures:

Failed Test  Stat Wstat Total Fail  Failed  List of Failed
 
---
t/cmd_break.t   1   256 21  50.00%  1
t/cmd_continue.t1   256 21  50.00%  1
t/cmd_for.t 2   512 72  28.57%  6-7
t/cmd_info.t1   256211   4.76%  15
t/tcl_misc.t1   256231   4.35%  21
Failed 5/54 test scripts, 90.74% okay. 6/664 subtests failed, 99.10%  
okay.

(These failures match current status on a few other platforms, as well.)

I've attached the diff between 11401 and 11402 - no changes in tcl in  
that rev, though.



11402.diff
Description: Binary data

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: Param count checks

[Chip Salzenberg]

On Sun, Feb 05, 2006 at 09:37:39PM +, Roger Browne wrote:
> Some languages (such as Amber and Eiffel) make a formal distinction
> between commands (which can change state but do not return a value) and
> queries (which return a value but cannot change state).

Interesting terminology.

> A solution is already defined. Leo suggested making it a little less
> strict...
>Leo> > ... WRT return/results count mismatch, I think, this  
>Leo> > should be a little less strict and allow 'void' function
>Leo> > calls of functions that return something

That's a sound idea.  It's even an optimization.  In pasm:
   get_results

with no parameters, not even a string, should express that the subsequent
call is a void call, without our having to create a new void-call opcode.

I'm struggling with good PIR syntax for it, though.  A simple call without
an '=' is, AFAIK, already taken to mean a call where the get_returns was
already spelled out by the user in some way.  Void calls will be common, so
it'd be nice to express them easily.  Hm.

...

On a tangential matter: To address the question of describing parameters and
return context, Audrey, Leo, and I considered a "signature" abstraction in
Austria lo these many months ago.  A Signature object would describe all the
parameter and return information for a subroutine.  Sadly, describing return
contexts that way is dauntingly expensive.  You don't want to go to the
expense of creating a Signature pmc to describe every single call/return,
not to mention the effect on cache coherency.  Thus, it's possible we'll
have signature objects for subs and more limited introspection on return
signatures.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

overloading the variable declaration process

[Darren Duncan]

All,

Speaking briefly, I would like it if Perl 6 provided a way for a 
class (or role, or meta-class, etc) to declare that all variables 
declared to be of that type are automatically/implicitly set to a 
particular value at declaration time, so that they are not undefined 
if the programmer using them doesn't explicitly set a value.


Here are usage examples:

  my NumType $foo; # implicitly contains a defined NumType of value 0
  my StrType $bar; # implicitly contains a defined StrType of value ''

Sure, the user could say ".= new()" or such, but I wanted a fallback 
if they didn't do that.


Then when they come to just use that not explicitly set variable, it 
contains some type-defined reasonable default value.


Presumably, the object meta-model would have an appropriate function 
defined for use at that time, which returns undef by default, and 
this function is what individual classes can override.


Part way through writing this, I had a brief chat on #perl6 with 
stevan (and apparently the meta-model is still quite in flux) and he 
said my question was related to Larry's "class but undef" idea, and 
that Larry should talk more about the subject.


Thank you. -- Darren Duncan

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



pgp5ZdeQI5sSt.pgp
Description: PGP signature

Re: A GraphViz eye view of Parrot

[dakkar]

Nicholas Clark wrote:

On Sat, Feb 04, 2006 at 11:18:59PM -0800, Allison Randal wrote:

It's just a Perl script, so yeah, could be done. Is it valuable
enough to spend the time? I was thinking of it as more of a one-off
for the heck of it.

I don't know, and I'm not in a good position to judge given that I've not
yet convinced any of my hardware to display it for me.


I did, and the big problem is that it has a size of 106967 x 2031 pts,
which I think translates to 1485 x 28 inches. This not only makes it
hard to display, but also hard to follow...

I might try to convice dot to lay it out a bit more clearly. I don't
promise anything (I'm not a GraphViz expert by any stretch of the
definition), but it might be fun to try.

--
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: overloading the variable declaration process

[Audrey Tang]

On 2/6/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
> Speaking briefly, I would like it if Perl 6 provided a way for a
> class (or role, or meta-class, etc) to declare that all variables
> declared to be of that type are automatically/implicitly set to a
> particular value at declaration time, so that they are not undefined
> if the programmer using them doesn't explicitly set a value.

In a somewhat related note, Perl 6 allows this form:

my Dog $fido .= new;

which may be treated as a special form (as is currently the case with Pugs).
However if it's not, it would desugar to:

my Dog $fido;
$fido = $fido.new;

which seem to imply that $fido is set to ::Dog (the dog class) as its
initial value.
However, that would potentially make this a no-op:

my Dog $fido = Dog;

which may make sense except that defined($fido) may need to be regulated
as true even for the "my Dog $fido" case.

If so, your use case can be satisfied by declaring that ::NumType (the
class object)
numifies to 0, and ::StrType stringifies to "", via the coerce form.

Audrey

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: PGE vs bindings (was Re: embparrot still has two failures)

[Audrey Tang]

On 2/6/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 05, 2006 at 11:34:33AM +0800, Audrey Tang wrote:
> > That seems to be a fatal error at PGE's side:
> >
> >$ echo 'rule $x:=[]' | parrot demo.pir
> >error:imcc:syntax error, unexpected ']'
> >in file 'EVAL_2' line 79
>
> I've now updated PGE (r11427) so that it provides a more
> useful exception:
>
> p6rule parse error: Term expected at offset 5, found ']'

Er, what about the originally reported bug though. :-)

$  echo 'rule $x:=[x]' | parrot demo.pir
error:imcc:syntax error, unexpected ']'
in file 'EVAL_2' line 79

(This is of r11427. Compare "rule $x:=x" which works.)

Audrey

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



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