Re: First (developers) Release of Test::Shlomif::Harness

[Michael G Schwern]

On Tue, Nov 01, 2005 at 03:16:01PM +0200, Shlomi Fish wrote:
> > I'd like to see 
> > that sort of thing as patches to Test::Harness rather than in a fork.
> 
> Well, I started with Test::Harness and gradually revamped it. The problem is 
> that some aspects of the T::H interface suck, and I had to change the 
> interface in a non-backwards-compatible way.

Given that the existing interface is pretty simple, I really don't see why 
one has to completely fork the code base just to put on a new interface.  
Surely any new code with a fancy new interface can continue to emulate the 
old one.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Don't try the paranormal until you know what's normal.
-- "Lords and Ladies" by Terry Prachett

Re: $_ defaulting for mutating ops

[Michele Dondi]

On Fri, 28 Oct 2005, Ruud H.G. van Tol wrote:


Or RPN-like:

 $x #= 2* 1+ 3/;


Being a big fan of RPN myself (and considering it quite natural), I'd 
appreciate very much such a feature. I had asked myself about RPN features 
in P6, albeit in a probably unreasonable fashion:


http://www.nntp.perl.org/group/perl.perl6.language/17556


Michele
--
[about penis-enlargement spam]
Suppose you (applies to male readers only!) had taken advantage
of every offer of the above type received, and all had worked as claimed.
Estimate how long it would be.
- Derek Holt in sci.math (slightly edited)

Re: should roles be parameterized?

[Michele Dondi]

On Sat, 29 Oct 2005, Christopher D. Malon wrote:


For the non-mathematically inclined:
A field is a set with two binary operations, + and *.
Under either operation (+ or *), the set is an abelian (= commutative) group,
and a field has a distributive property: a * (b + c) = a*b + a*c.
An easy example is the set of real numbers, with + being addition
and * being multiplication.


Not exactly. With the exception of _the_ trivial case (up to a natural 
isomorphism there's only one!) a field is _not_ a multiplicative group wrt 
its multiplication, given that the identity for the addition can't have a 
multiplicative inverse.


This is of some relevance of so called Universal Algebra in which some 
commonly used structures (e.g. a group, a ring) can be described in terms 
of sets of n-ary operations obeying a set of algebraic identities, whereas 
certain other just as common structures (e.g. a field) can't - and a more 
complex approach is needed.


This may be of some interest here too, since there's been some talking 
about the algebra of methods of a role that any class which C that 
role guarantees to obey by doing so. So this should take into account the 
possibility of algebrai relations "not defined everywhere", which may 
bring a new level of complexity in realistic situations...



Michele
--
I'm finding now in my 40s that the less makeup I wear, the better. I think
softer is better as you get older. With everything. Except men.
- Kim Cattrall

Re: $_ defaulting for mutating ops

[Michele Dondi]

On Fri, 28 Oct 2005, John Williams wrote:


But IMHO the reduction in typing for this relatively minor issue is not
really worth the surprise to newbies at seeing operandless operators.


I don't buy that argument as newbies are already exposed to all sorts of 
surprises including operandless operators. Including mutating operandless 
operators. What is s/// after all? Or is there a good reason for an 
asymmetry between different classes of operators?



Michele
--
=> (But it is impossible to even imagine an operating-system which would
=> not crash before the sun has burned all of its hydrogen, let alone not
=> crash before the end of the universe.)
I find it hard to imagine an operating system which would not crash 
before the end of the week

- Gerry Myerson in sci.math

Re: PGE problem with non-greedy quantifiers

[Patrick R. Michaud]

On Tue, Nov 01, 2005 at 10:22:03AM -0800, Allison Randal wrote:
> On a grammar that worked in a recent version of PGE, I'm now getting  
> an error when I try to construct the grammar. The error disappears  
> when I eliminate all non-greedy quantifiers from the grammar (though,  
> of course, the constructed grammar parses the text incorrectly with  
> greedy quantifiers).

Oops, I left out a "goto" -- now fixed in r9687.  Surprisingly, there 
don't seem to be any tests for non-greedy quantifiers in t/p6rules/  :-( .

> Also, the README file in compilers/pge needs to be updated to reflect  
> the fact that the "dump" method is gone (replaced by dumper.imc).

Yes, there are several documentation-related updates that need
doing; I'm trying to get the code back up to a fully functional
state and then will tackle the docs again.

Thanks,

Pm

Re: Devel::Cover not DWIMming on upgraded Perl -- but problem solved

[Chris Dolan]

James,

The explanation is that D::C saves a copy of your @INC at build time  
in a .pm and subsequently uses that list to filter out the code perl  
libraries.  That @INC probably had some /5.8.4/ subdirs in it.  With  
the new Perl, the @INC now has /5.8.7/ subdirs and those aren't being  
filtered.


When I first discovered that detail, I thought "Why can't D::C just  
look at @INC at runtime?"  The answer, of course, is that you've  
probably changed @INC with -Mblib or -Ilib or 'use lib qw(.);' or  
something.  So, there has to be a pristine @INC to reference.


I haven't fully thought this out, but it seems to me that some  
combination of @INC from %Config and $ENV{PERL5LIB} should cover  
pretty much all of core, so perhaps D::C can do away with the hard- 
coded @INC filter list in the future?


Chris

On Nov 1, 2005, at 7:25 PM, James E Keenan wrote:

When I began to write this posting, it was to get an answer to a  
question.  But I figured out a workaround halfway through, so now  
I'm posting an answer.


I have happily been using Devel::Cover for more than a year on Perl  
5.8.4 on Darwin (Mac OS X 10.3).  Recently I upgraded to Perl  
5.8.7. Tonight I went to use Devel::Cover (v0.55, as previously)  
for the first time since that Perl upgrade.  At first, it no longer  
DWIMmed. Specifically:


1.  When I ran 'make test HARNESS_PERL_SWITCHES=MDevel::Cover', I  
got this message:


t/01_test..
This version of Devel::Cover was built with Perl version 5.008004.
It is now being run with Perl version 5.008007.
Attempting to make adjustments, but you may find that some of  
your modules do
not have coverage data collected.  You may need to alter the +- 
inc, +-ignore

and +-select options.

t/01_test..ok

I'd never had to set these options before; previously, D::C just  
worked.  Also, D::C took much longer to run.


2.  I was testing coverage of a new module I'm developing called  
File::Save::Home.  When I called 'cover', I got a report on this  
module, but also on every core module as well:


[snip]
 -- -- -- -- --  
-- --
File   stmt   bran   condsubpod  
time  total
 -- -- -- -- --  
-- --
...perl5/5.8.7/AutoLoader.pm0.00.00.00.00.0  
n/a0.0
...l/lib/perl5/5.8.7/Carp.pm0.00.00.00.00.0  
n/a0.0
...erl5/5.8.7/Digest/base.pm0.00.0n/a0.00.0  
n/a0.0
...b/perl5/5.8.7/Exporter.pm   50.0   57.1   44.7   33.30.0  
0.3   44.8
...5/5.8.7/Exporter/Heavy.pm   10.48.8   12.5   11.10.0  
0.19.8
...l5/5.8.7/File/Basename.pm   28.2   25.87.7   50.0  100.0  
0.1   27.8

[snip]
8.7/warnings/register.pm  100.0   50.0n/a  100.00.0  
0.1   89.5
blib/lib/File/Save/Home.pm 77.1   44.4n/a  100.0  100.0  
0.3   73.4
Total  10.86.24.3   12.3   14.0  
100.09.0
 -- -- -- -- --  
-- --



Writing HTML output to
/Users/jimk/work/fsh/File-Save-Home/cover_db/coverage.html ...
done.

This problem of excessive output is the same one I typically  
experience using D::C (v0.47, I believe) on Windows.  This is much  
more output than I want or need.


I hypothesized that if I were to upgrade to a new version of D::C,  
it would be compiled against Perl 5.8.7 and these problems might go  
away. But 'cpan' did nothing because it detected that I was using  
the most recent version of D::C.


So I downloaded the latest version of Devel::Cover from CPAN and  
installed it manually.  (I did call 'make install UNINSTALL=1'.)   
This solved the problem.  The message described above went away,  
and 'cover' reported only the results for the module under  
development.


Jim Keenan



--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703

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: Devel::Cover not DWIMming on upgraded Perl -- but problem solved

[Steve Peters]

On Tue, Nov 01, 2005 at 08:25:36PM -0500, James E Keenan wrote:
> When I began to write this posting, it was to get an answer to a 
> question.  But I figured out a workaround halfway through, so now I'm 
> posting an answer.
> 
> I have happily been using Devel::Cover for more than a year on Perl 
> 5.8.4 on Darwin (Mac OS X 10.3).  Recently I upgraded to Perl 5.8.7. 
> Tonight I went to use Devel::Cover (v0.55, as previously) for the first 
> time since that Perl upgrade.  At first, it no longer DWIMmed. 
> Specifically:
> 
> 1.  When I ran 'make test HARNESS_PERL_SWITCHES=MDevel::Cover', I got 
> this message:
> 
> t/01_test..
> This version of Devel::Cover was built with Perl version 5.008004.
> It is now being run with Perl version 5.008007.
> Attempting to make adjustments, but you may find that some of your 
> modules do
> not have coverage data collected.  You may need to alter the +-inc, 
> +-ignore
> and +-select options.
> 
> t/01_test..ok
> 
> I'd never had to set these options before; previously, D::C just worked. 
>  Also, D::C took much longer to run.
> 
> 2.  I was testing coverage of a new module I'm developing called 
> File::Save::Home.  When I called 'cover', I got a report on this module, 
> but also on every core module as well:
> 
> [snip]
>  -- -- -- -- -- 
> -- --
> File   stmt   bran   condsubpod 
> time  total
>  -- -- -- -- -- 
> -- --
> ...perl5/5.8.7/AutoLoader.pm0.00.00.00.00.0 
> n/a0.0
> ...l/lib/perl5/5.8.7/Carp.pm0.00.00.00.00.0 
> n/a0.0
> ...erl5/5.8.7/Digest/base.pm0.00.0n/a0.00.0 
> n/a0.0
> ...b/perl5/5.8.7/Exporter.pm   50.0   57.1   44.7   33.30.0 
> 0.3   44.8
> ...5/5.8.7/Exporter/Heavy.pm   10.48.8   12.5   11.10.0 
> 0.19.8
> ...l5/5.8.7/File/Basename.pm   28.2   25.87.7   50.0  100.0 
> 0.1   27.8
> [snip]
> 8.7/warnings/register.pm  100.0   50.0n/a  100.00.0 
> 0.1   89.5
> blib/lib/File/Save/Home.pm 77.1   44.4n/a  100.0  100.0 
> 0.3   73.4
> Total  10.86.24.3   12.3   14.0 
> 100.09.0
>  -- -- -- -- -- 
> -- --
> 
> 
> Writing HTML output to
> /Users/jimk/work/fsh/File-Save-Home/cover_db/coverage.html ...
> done.
> 
> This problem of excessive output is the same one I typically experience 
> using D::C (v0.47, I believe) on Windows.  This is much more output than 
> I want or need.
> 
> I hypothesized that if I were to upgrade to a new version of D::C, it 
> would be compiled against Perl 5.8.7 and these problems might go away. 
> But 'cpan' did nothing because it detected that I was using the most 
> recent version of D::C.
> 
> So I downloaded the latest version of Devel::Cover from CPAN and 
> installed it manually.  (I did call 'make install UNINSTALL=1'.)  This 
> solved the problem.  The message described above went away, and 'cover' 
> reported only the results for the module under development.
> 

I don't know if that is in the documentation for Devel::Cover or not,
but an upgrade in Perl usually requires and reinstall of Devel::Cover.

Steve Peters
[EMAIL PROTECTED]

[perl #37537] [BUG] coroutine segfaults

[Patrick R. Michaud via RT]

Fixed in r9591.  Thanks, Leo

Re: Apache-Test and Devel::Cover

[Stas Bekman]

Geoffrey Young wrote:


2) at the end of run it gives:

All tests successful, 1 test skipped.
Files=7, Tests=22, 140 wallclock secs (134.28 cusr +  5.51 csys = 139.79
CPU)
server localhost:8529 shutdown
make[1]: Leaving directory `/home/stas/apache.org/Apache-Test'
make: cover: Command not found
make: [testcover] Error 127 (ignored)

I don't use a standard perl, so 'cover' is not in the path. So it should
probably do which(cover) and run it only then? Also could check the
directory perl lives and add that to PATH, since that's where 'cover'
lives if not installed global-wise.



I don't use a standard perl either, so cover is one of those things I need
to add to my path.

really, I'm not sure how much I want to run through hoops for people wrt
stuff like this - if you're a developer and you care about coverage you have
Devel::Cover (and its components) installed and ready for use, otherwise you
don't.  almost nobody will be running testcover who doesn't have things
installed properly, so I'm not sure it makes too much sense to go poking
around looking for stuff.


Sorry Geoff, but my things are installed properly. It's just that you 
shouldn't run an application that's not there. How hard it is to run 
which("cover") and run the executable only if found.



3)

I do get segfaults and they are quite inconsistent. Even on
Apache-Test's test suite. Of course this probably has nothing to do with
your work, since have happened before as well. I wonder whether
Devel::Cover is just as unstable under plain perl.



under plain perl it works out very nicely.  I think something about the
embedded perl environment is causing problems.  actually, until a recent
version (0.48 IIRC) it didn't work under mod_perl at all.  my own personal
experience wrt mod_perl is that it seems to work ok with mp1.  the mp2 +
Devel::Cover combination behaves very erratically, but I have better luck
with unthreaded perls and prefork than threaded perls (and horrible results
with worker, if it works at all which I don't think it does).

but we're getting closer each time, and paul has been outstanding creating
D::C at all, so there's not much to complain about :)


It's true that there is not much to complain about other than it just 
doesn't work. I get segfaults on any apache based test suite, even with 
prefork/non-threaded perl so it's of no use whatsover :(


--
_
Stas Bekman mailto:[EMAIL PROTECTED]  http://stason.org/
MailChannels: Assured Messaging(TM) http://mailchannels.com/
The "Practical mod_perl" book   http://modperlbook.org/
http://perl.apache.org/ http://perl.org/ http://logilune.com/

Re: Apache-Test and Devel::Cover

[Stas Bekman]

Geoffrey Young wrote:

hi all :)

I just commited a patch to Apache-Test in svn that removes all the
additional work involved with getting Devel::Cover to work for server side
tests.  now a simple 'make testcover' should be all you need to do to get
coverage results from code within handler() subroutines - no more adding
modperl_extra.pl entries or other associated foo.

so, for the few here interested in this kind of thing, I'd like to hear
people's test results for completeness sake.  on my own system (which is
slowly dying), I get random core dumps and Devel::Cover failures both in the
way I used to do it and the way it works now, so in that sense things work
out "the same."  but if other people who used to have stuff working now have
increased problems I'd love to hear about it.  but hopefully all this patch
does is lower the barrier to getting coverage in the apache world.

for those not terribly svn savvy, you can get Apache-Test from svn like so

  $ svn checkout \
  > http://svn.apache.org/repos/asf/perl/Apache-Test/trunk Apache-Test

thanks, and enjoy.

--Geoff


Nice work, Geoff

A few issues:

1)

% make testcover
Cannot run testcover action unless Devel::Cover is installed

and after installing Devel::Cover it still gives the same error, since 
it's hardcoded in Makefile.PL. May be adding a check and suggesting to 
rebuild Makefile if Devel::Cover is now installed?


2) at the end of run it gives:

All tests successful, 1 test skipped.
Files=7, Tests=22, 140 wallclock secs (134.28 cusr +  5.51 csys = 139.79 CPU)
server localhost:8529 shutdown
make[1]: Leaving directory `/home/stas/apache.org/Apache-Test'
make: cover: Command not found
make: [testcover] Error 127 (ignored)

I don't use a standard perl, so 'cover' is not in the path. So it should 
probably do which(cover) and run it only then? Also could check the 
directory perl lives and add that to PATH, since that's where 'cover' 
lives if not installed global-wise.


3)

I do get segfaults and they are quite inconsistent. Even on Apache-Test's 
test suite. Of course this probably has nothing to do with your work, 
since have happened before as well. I wonder whether Devel::Cover is just 
as unstable under plain perl.




--
_
Stas Bekman mailto:[EMAIL PROTECTED]  http://stason.org/
MailChannels: Assured Messaging(TM) http://mailchannels.com/
The "Practical mod_perl" book   http://modperlbook.org/
http://perl.apache.org/ http://perl.org/ http://logilune.com/

Re: Role Method Conflicts and Disambiguation

[Rob Kinyon]

On 11/1/05, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> Rob Kinyon wrote:
> > > 1. choose one of a set of available methods to call its own.
> > > 2. create a version of its own.
> > > 3. pass the buck.
> >
> > #1 and #2 are identical. Stevan and I have always viewed #1 as a
> > special case of #2. If you want to choose a method to call, then
> > create a method of your own and have it wrap the one you want to call.
> >
> > The benefit here is that you can do more than just pick a method.
> > Let's say that you have a conflict and the correct behavior is to do
> > them all, but in a certain way. Or, maybe the correct behavior is to
> > provide a limited API over one version.
> >
> > Maybe, there'll be some sugar to allow #1 to be its own syntax, but it
> > should be viewed as a #2.
>
> You're right.  But this obscures the point that I was trying to make:
> we need to decide what set of methods are available when
> disambiguating.  Is the DOESA list public or private?  Should the role
> be able to look up any public method that any of its ancestors have,
> or should it be restricted to just the methods that its parent roles
> have?  Given the flattened nature of composition, I feel that the
> latter is more appropriate.

Actually, given the flattened nature of composition, any role should
have access to -every- method that a class would be given through
doing that role. So, the DOESA list should be all the public methods
that the role is acting as a gateway for.

Rob

Re: $_ defaulting for mutating ops

[Rob Kinyon]

On 11/2/05, Michele Dondi <[EMAIL PROTECTED]> wrote:
> On Fri, 28 Oct 2005, John Williams wrote:
>
> > But IMHO the reduction in typing for this relatively minor issue is not
> > really worth the surprise to newbies at seeing operandless operators.
>
> I don't buy that argument as newbies are already exposed to all sorts of
> surprises including operandless operators. Including mutating operandless
> operators. What is s/// after all? Or is there a good reason for an
> asymmetry between different classes of operators?

I think the difference comes from the Principle of Least Surprise. The
various operators being discussed in this thread are all operators
which are in languages that have common use - C, C++, Java, the .Net
stack, etc. Regexen and the various built-ins are generally considered
to be Perl-specific, so if they're weird, this is just a Perl-ism. The
PoLS doesn't apply.

Yes, from a consistency point of view, ALL operators should default to
$_ or some other sensible item ($*STDIN for <>, etc). However, the
PoLS does need to guide our decisions.

Rob

syntax-variants, RPN (was: Re: $_ defaulting for mutating ops)

[Ruud H.G. van Tol]

Michele Dondi:
> Ruud H.G. van Tol:

>> Or RPN-like:
>>
>>  $x #= 2* 1+ 3/;
>
> Being a big fan of RPN myself (and considering it quite natural), I'd
> appreciate very much such a feature. I had asked myself about RPN
> features in P6, albeit in a probably unreasonable fashion:
>
> http://www.nntp.perl.org/group/perl.perl6.language/17556

I understand that Perl6 allows blocks with changed/enhanced syntax, so
it is or will become possible (to add it) as if it was in the core
language.
Do I understand that right? Something as simple as a 'use RPN' in a
block? (assuming that someone created such an RPN-pre-processor
or -compiler)

-- 
Grtz, Ruud

Re: Test Suite Slowing Down My Development

[Marcello]

Tels ha scritto:

-BEGIN PGP SIGNED MESSAGE-

Moin,

On Friday 28 October 2005 22:34, Christopher H. Laco wrote:


Ovid wrote:


The code is designed well enough that adding new features is quick
and easy. Unfortunately, whenever I need to change my code I fire up
a Web server and view the results in the browser and then write the
tests after I've written the code (this is closely related to When
test-driven development just won't do). This is because XML and XHTML
are just text. I need to see the output. I've been finding more and
more that small changes in my code are making huge changes in the
output and trying to continuously update the tests to exactly match
the XML, XSLT and XHTML using Test::XML and XML::XPath has led to a
serious productivity drop.

I'm considering just using Test::WWW::Mechanize to do integration
testing through a Web server I run in the tests. This will be much
faster and allow me to get my development speed back up. However, I'd
be skipping the unit testing of the output. I'll catch the bugs but
it will likely take me longer to track them down.


I feel your pain. The test suite for Handel has xml/tt output tests for
its AxKit and Template Toolkit plugins. I've got oodles of template
pages using the components whos output I compare to static  .out files
that contain the expected output.

Everytime I write a new plugin, or a new tag in the plugin, I waste
tons of time just writing the tests for them. So far, I've been good
about writing the tests before I write the code, but it takes forever
and I rarely get the tests right the first time.

I'm curious to see what comes out of your question. I'm in the same
boat.



I am somewhat in the same boat with Graph::Easy - the t/ascii.t script 
tests rendering of graphs in ASCII, ala:


[ A ] -> [ B ]

is transformed into:

# echo "[Test] -> [This] ..> [ Now ]" | perl examples/as_ascii
+--+ +--+ +-+
| Test | --> | This | ..> | Now |
+--+ +--+ +-+

While this works mostly fine for ASCII, the HTML/SVG is undertested 
because the text/code output can change quite radically, while still 
rendering/representing the same graph. And of course I do want to test 
that the end result is the right one, not that the generated SVG/HTML 
code is a specific example.


If the output is valid xml, couldn't one "semantically" compare the 
expected output and the actual output with something like 
XML::SemanticDiff ?


Just my 0.2 eurocents...



So everytime I change the HTML template/output, I need to fiddle back a 
host of tests...


Best wishes,

Tels

- -- 
 Signed on Fri Oct 28 23:33:31 2005 with key 0x93B84C15.

 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Ok, a shiny copper piece to the first person who can tell me why Elan
 is running around naked." - "Giant moth attack?" - "Maybe a bad guy
 casted 'Dispel clothes'?" - The Order of the Stick issue #26

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQ2KZ9ncLPEOTuEwVAQEZxAf/Rz/gxvA3w2bbD7D1CfT2HaFe+glj37kT
WkJUQ7pj9bEZA/o74WJwpdZyL7MfTe3K6MhqohstrNDL9XxvN0C0ScSQiHlagHny
zVl6gdZ9DDhxWBOzHZc5oEdrsV6qhkHkdvusADC3mTb0UZEqgE50RbgERw1Wlu1v
08O5NWmqJTI+KDujqdY5FZ6pBSGUR72eiaWw8UxN7HkSi42DP8/dmnw+23FsVTmc
z3sJhNuhaNsVorMHdPHxUs9n5WuXRP/h1cemrrzpx2o3SfP4DBiDoxt0GKMdeRiB
s29F8bWWQ4CLUsQqAgk9L4P7fOp00+tqDBLr/9t/ECLiVxWDFTxcWg==
=b8rX
-END PGP SIGNATURE-




--
Marcello Romani
Developer
Spin s.r.l.
Reggio Emilia
http://www.spinsoft.it

Re: Proposed Kwalitee tests: has_license and/or has_meta_yml_license

[David Landgren]

Chris Dolan wrote:
In the last year as a Fink maintainer (Mac OS X debian-like package  
manager), I've come across a couple CPAN modules that have no license  
information at all.  It's very frustrating.  I've submitted RT bugs,  
but one of them has been fixed (thanks Ken Williams).


To encourage authors to correct this oversight, I propose a new pair  of 
Kwalitee tests.  Both would be nice, but if either of them were  
implemented, I'd be thrilled.  I'd prefer that someone else implement  
the test (lack of tuits), but if there is approval for the idea  without 
a motivated implementer I will take a hack at it.


 1) has_license -- check for the presence of a file named something  
like LICENSE or COPYING or COPYLEFT or GPL or ... (each test case  
insensitive, with or without .txt extensions).  Alternatively, the  test 
can be more liberal by looking for the string "copyright" in  README, 
*pm and *.pod.


 2) has_meta_yml_license -- check for a META.yml field named  
"license".  Module::Build supports this.


That would suck, you may as well propose a Kwalitee bit for modules that 
use Module::Build.


I know that the current alpha of ExtUtils::MakeMaker supports this, but 
until it is released as stable *and* module authors have the time to 
upgrade EU::MM *and* release a new version of their module(s), those 
authors will be penalised through no fault of their own.


David

These tests should not care which license is claimed, just that there  
is a license present.


Chris


--
"It's overkill of course, but you can never have too much overkill."

Re: Test Suite Slowing Down My Development

[Tels]

-BEGIN PGP SIGNED MESSAGE-

Moin,

On Wednesday 02 November 2005 16:45, Marcello wrote:
> Tels ha scritto:
> > -BEGIN PGP SIGNED MESSAGE-
[snip]
> >>>I'm considering just using Test::WWW::Mechanize to do integration
> >>>testing through a Web server I run in the tests. This will be much
> >>>faster and allow me to get my development speed back up. However,
> >>> I'd be skipping the unit testing of the output. I'll catch the bugs
> >>> but it will likely take me longer to track them down.
> >>
> >>I feel your pain. The test suite for Handel has xml/tt output tests
> >> for its AxKit and Template Toolkit plugins. I've got oodles of
> >> template pages using the components whos output I compare to static 
> >> .out files that contain the expected output.
> >>
> >>Everytime I write a new plugin, or a new tag in the plugin, I waste
> >>tons of time just writing the tests for them. So far, I've been good
> >>about writing the tests before I write the code, but it takes forever
> >>and I rarely get the tests right the first time.
> >>
> >>I'm curious to see what comes out of your question. I'm in the same
> >>boat.
> >
> > I am somewhat in the same boat with Graph::Easy - the t/ascii.t
> > script tests rendering of graphs in ASCII, ala:
> >
> > [ A ] -> [ B ]
> >
> > is transformed into:
> >
> > # echo "[Test] -> [This] ..> [ Now ]" | perl examples/as_ascii
> > +--+ +--+ +-+
> >
> > | Test | --> | This | ..> | Now |
> >
> > +--+ +--+ +-+
> >
> > While this works mostly fine for ASCII, the HTML/SVG is undertested
> > because the text/code output can change quite radically, while still
> > rendering/representing the same graph. And of course I do want to
> > test that the end result is the right one, not that the generated
> > SVG/HTML code is a specific example.
>
> If the output is valid xml, couldn't one "semantically" compare the
> expected output and the actual output with something like
> XML::SemanticDiff ?

Might be, but I am not generting XML, but HTML...

And there are many ways to write code that looks visually the same, and 
yet is wildly different. More so for, lets say SVG.

Sometimes I resort to "soft" tests, like looking if I find certain strings 
in the output, like for "[ Bonn ] -> [ Berlin ]", you expect "Bonn" and 
"Berlin" in there somewhere...

Best wishes,

Tels

- -- 
 Signed on Wed Nov  2 17:17:05 2005 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Build a man a fire, and he'll be warm for a day. Set a man on fire, and
 he'll be warm for the rest of his life." -- Terry Pratchett

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQ2jm5HcLPEOTuEwVAQFI1Af+J5xwJopUDR/eLJ/AtyeVPrAxiwcF5Mt+
ikOj8jmLI0uwQ5bqrj74Ad+XNQxTOIoiu7ItecF0aAjQRMBWBm4wp+/bsSIgFdBr
6substw3TSNYaCeQTU95IVXQV1CNcerpnuC5SVdmIE9l+PJOUAZHWSa3QJLcLD7e
bFg9Fj4WlJsdc1FY9+l+qzXnfFwTSpZoF9ExvVQlBsilEJNOfcUgbHzXnqE/Kt0i
GTuNHrxPse+Lt+j25Kv2vBygQ94opiH/MEVM2jIED68nUESYhGJGNPZm23gvXRy7
CQw2qdmB6mHfXw3fEYB5E99nQn0rLP45KCcdm4AkEjBuSNNkBnuzpw==
=5jrY
-END PGP SIGNATURE-

Re: Test Suite Slowing Down My Development

[Marcello]

Tels ha scritto:

-BEGIN PGP SIGNED MESSAGE-

Moin,

On Wednesday 02 November 2005 16:45, Marcello wrote:


Tels ha scritto:


-BEGIN PGP SIGNED MESSAGE-


[snip]


I'm considering just using Test::WWW::Mechanize to do integration
testing through a Web server I run in the tests. This will be much
faster and allow me to get my development speed back up. However,
I'd be skipping the unit testing of the output. I'll catch the bugs
but it will likely take me longer to track them down.


I feel your pain. The test suite for Handel has xml/tt output tests
for its AxKit and Template Toolkit plugins. I've got oodles of
template pages using the components whos output I compare to static 
.out files that contain the expected output.


Everytime I write a new plugin, or a new tag in the plugin, I waste
tons of time just writing the tests for them. So far, I've been good
about writing the tests before I write the code, but it takes forever
and I rarely get the tests right the first time.

I'm curious to see what comes out of your question. I'm in the same
boat.


I am somewhat in the same boat with Graph::Easy - the t/ascii.t
script tests rendering of graphs in ASCII, ala:

[ A ] -> [ B ]

is transformed into:

# echo "[Test] -> [This] ..> [ Now ]" | perl examples/as_ascii
+--+ +--+ +-+

| Test | --> | This | ..> | Now |

+--+ +--+ +-+

While this works mostly fine for ASCII, the HTML/SVG is undertested
because the text/code output can change quite radically, while still
rendering/representing the same graph. And of course I do want to
test that the end result is the right one, not that the generated
SVG/HTML code is a specific example.


If the output is valid xml, couldn't one "semantically" compare the
expected output and the actual output with something like
XML::SemanticDiff ?



Might be, but I am not generting XML, but HTML...


Valid XHTML is also valid XML.



And there are many ways to write code that looks visually the same, and 
yet is wildly different. More so for, lets say SVG.


My point was that 'semantically' comparing XML data structures instead 
of their ascii representations is an improvement.


Of course this doesn't take into account specific cases like SVG, where 
you have 'semantically' different xml documents producing the same 
(visual) output.


To address this specific case one would need a way to test the 'visual' 
equivalence of two svg documents.




Sometimes I resort to "soft" tests, like looking if I find certain strings 
in the output, like for "[ Bonn ] -> [ Berlin ]", you expect "Bonn" and 
"Berlin" in there somewhere...


Best wishes,

Tels

- -- 
 Signed on Wed Nov  2 17:17:05 2005 with key 0x93B84C15.

 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Build a man a fire, and he'll be warm for a day. Set a man on fire, and
 he'll be warm for the rest of his life." -- Terry Pratchett

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQ2jm5HcLPEOTuEwVAQFI1Af+J5xwJopUDR/eLJ/AtyeVPrAxiwcF5Mt+
ikOj8jmLI0uwQ5bqrj74Ad+XNQxTOIoiu7ItecF0aAjQRMBWBm4wp+/bsSIgFdBr
6substw3TSNYaCeQTU95IVXQV1CNcerpnuC5SVdmIE9l+PJOUAZHWSa3QJLcLD7e
bFg9Fj4WlJsdc1FY9+l+qzXnfFwTSpZoF9ExvVQlBsilEJNOfcUgbHzXnqE/Kt0i
GTuNHrxPse+Lt+j25Kv2vBygQ94opiH/MEVM2jIED68nUESYhGJGNPZm23gvXRy7
CQw2qdmB6mHfXw3fEYB5E99nQn0rLP45KCcdm4AkEjBuSNNkBnuzpw==
=5jrY
-END PGP SIGNATURE-




--
Marcello Romani
Developer
Spin s.r.l.
Reggio Emilia
http://www.spinsoft.it

Re: Test Suite Slowing Down My Development

[Adam Turoff]

On 10/28/05, Ovid <[EMAIL PROTECTED]> wrote:
> The code is designed well enough that adding new features is quick and
> easy. Unfortunately, whenever I need to change my code I fire up a Web
> server and view the results in the browser and then write the tests
> after I've written the code (this is closely related to When
> test-driven development just won't do). This is because XML and XHTML
> are just text. I need to see the output. I've been finding more and
> more that small changes in my code are making huge changes in the
> output and trying to continuously update the tests to exactly match the
> XML, XSLT and XHTML using Test::XML and XML::XPath has led to a serious
> productivity drop.

I'm in a similar boat, and I do the same thing.

It's pretty easy to the idiot tests -- XML well-formed-ness and XHTML
validity -- but testing the content of the output is obviously more
difficult.  At the very least, you need a mockup of your expectations,
and creating that mockup by hand is *much* more error-prone and tedious
than grabbing the initial output.  Especially so when things like whitespace
sensitivity enter into the discussion.

While this isn't test-first development, it works well with the
test-early-test-often mindset.  Instead of testing your expectations
(which are quickly met or dashed by visual inspection) you refocus on
regression testing.  So while you're not proving that your initial
output is exactly as you expect, you *are* proving that your tests are
the canary in the coal mine when you mess up.

The other legs of this three-legged stool are version control and brute
force.

The project I'm working on at the moment involves parsing queries and
converting them into SQL (involving a bizarre and baroque set of
business rules).  The only way I can keep my sanity here is to
md5^Wcheck each and every input and every output to make sure that
nothing changes.  The only way for these tests to be meaningful is to be
rigorous -- identify all possible things to test, and generate all
possible combinations and permutations.  When you break a corner case,
you'll know.

(HOP really helps here -- iterators, odometers and such really help when
writing a few dozen lines of Perl that generate a few thousand inputs.)

Keep in mind that all of your sources and tests are in subversion, so
when things break, the regression two-step is a quick 'diff -b' and
'diff' to see if the changes are meaningful and/or expected.  When those
checks fail, there's a bug.  (Alternatively, you may want to run a
constant pre-processor on your test data to normalize it, but that's
both trickier and riskier.)

Of course, be ready to throw out previous test results when
the expectations change radically.  ;-)

HTH,

Z.

Re: Test Suite Slowing Down My Development

[Tels]

-BEGIN PGP SIGNED MESSAGE-

Moin,

On Wednesday 02 November 2005 18:02, Marcello wrote:
> Tels ha scritto:
> > -BEGIN PGP SIGNED MESSAGE-
> >>>While this works mostly fine for ASCII, the HTML/SVG is undertested
> >>>because the text/code output can change quite radically, while still
> >>>rendering/representing the same graph. And of course I do want to
> >>>test that the end result is the right one, not that the generated
> >>>SVG/HTML code is a specific example.
> >>
> >>If the output is valid xml, couldn't one "semantically" compare the
> >>expected output and the actual output with something like
> >>XML::SemanticDiff ?
> >
> > Might be, but I am not generting XML, but HTML...
>
> Valid XHTML is also valid XML.

But valid XHTML doesn't work well in the praxis. (It offers nothing what 
HTML can't do, but creates more problems) 

And it still doesn't solve the problem, because a:

* div with 1px border
* table cell with 1px border

look exactly in the browser, but have much different (X)HTML source.

> > And there are many ways to write code that looks visually the same,
> > and yet is wildly different. More so for, lets say SVG.
>
> My point was that 'semantically' comparing XML data structures instead
> of their ascii representations is an improvement.

> Of course this doesn't take into account specific cases like SVG, where
> you have 'semantically' different xml documents producing the same
> (visual) output.

> To address this specific case one would need a way to test the 'visual'
> equivalence of two svg documents.

The same for HTML documents. Hm. Maybe one could convert them to PNG and 
compare the outputs. But this is also hard. *thinks*

Best wishes,

Tels


- -- 
 Signed on Wed Nov  2 18:06:15 2005 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "We're confident that DNF will be one of the greatest, if not the
 greatest, game of 1998. And this confidence is not misplaced." -Scott
 Miller, 1997 (http://tinyurl.com/6m8nh)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQ2jy+ncLPEOTuEwVAQGOTQf9FDcLaYVVoYdgfq41pcqQK9avi1oqaqmp
GKKMVnYT1PsDkhYxxgCj2MYJd7+nVZ+v5n+nW0PN2pjfHzPvDOq5bIHTbqqZaJ4s
k14oUBk0JRLx78k9jQORdWhGbgWR2vAtcRtN6thI1IqANRGNX9kMQscSPl1gVaEG
Wwz/NYY6JJJ5+DWZORa3xOPp3daE4lFY+pJl2ENSmcpqNBLlMBPm2/ajw0aa6Zkv
Iz0TOh3pyXxzPwT7c4lP3kwdySc1yikUftan753yvAErCEaFmXEFbNYZE8L2xal5
o/d+aQ1uBh1r2ycCG918y6z04CL9Y5QA0GRW1ztKFbLLhSXA+5Sq4A==
=M0v6
-END PGP SIGNATURE-

Re: Proposed Kwalitee tests: has_license and/or has_meta_yml_license

[Chris Dolan]

On Nov 2, 2005, at 10:19 AM, David Landgren wrote:


Chris Dolan wrote:

In the last year as a Fink maintainer (Mac OS X debian-like  
package  manager), I've come across a couple CPAN modules that  
have no license  information at all.  It's very frustrating.  I've  
submitted RT bugs,  but one of them has been fixed (thanks Ken  
Williams).
To encourage authors to correct this oversight, I propose a new  
pair  of Kwalitee tests.  Both would be nice, but if either of  
them were  implemented, I'd be thrilled.  I'd prefer that someone  
else implement  the test (lack of tuits), but if there is approval  
for the idea  without a motivated implementer I will take a hack  
at it.
 1) has_license -- check for the presence of a file named  
something  like LICENSE or COPYING or COPYLEFT or GPL or ... (each  
test case  insensitive, with or without .txt extensions).   
Alternatively, the  test can be more liberal by looking for the  
string "copyright" in  README, *pm and *.pod.
 2) has_meta_yml_license -- check for a META.yml field named   
"license".  Module::Build supports this.




That would suck, you may as well propose a Kwalitee bit for modules  
that use Module::Build.


I know that the current alpha of ExtUtils::MakeMaker supports this,  
but until it is released as stable *and* module authors have the  
time to upgrade EU::MM *and* release a new version of their module 
(s), those authors will be penalised through no fault of their own.


David


What penalty?  The whole point of Kwalitee is not to reward authors  
who jump through hoops, but to encourage authors to live up to  
community expectations.  That includes good packaging, good POD and,  
I say emphatically, clear licensing.  Anything we can do to encourage  
authors to more clearly state their license is a good thing.  If that  
in turn means encouraging them to 1) use Module::Build, 2) upgrade  
EU::MM or 3) hand-edit META.yml, then I think that's a burden worth  
bearing.


You're complaining that its too big a burden to clearly state your  
module's license?  To me that's just crazy.  To some people, the  
license is actually more important than the module (e.g. if I can  
only redistribute Artistically license code).


After all, Kwalitee is not an entrance barrier to CPAN.  It's a tool  
to let authors know what is important to the rest of us.


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703

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: Test Suite Slowing Down My Development

[Marcello]

Tels ha scritto:

-BEGIN PGP SIGNED MESSAGE-

Moin,

On Wednesday 02 November 2005 18:02, Marcello wrote:


Tels ha scritto:


-BEGIN PGP SIGNED MESSAGE-


While this works mostly fine for ASCII, the HTML/SVG is undertested
because the text/code output can change quite radically, while still
rendering/representing the same graph. And of course I do want to
test that the end result is the right one, not that the generated
SVG/HTML code is a specific example.


If the output is valid xml, couldn't one "semantically" compare the
expected output and the actual output with something like
XML::SemanticDiff ?


Might be, but I am not generting XML, but HTML...


Valid XHTML is also valid XML.



But valid XHTML doesn't work well in the praxis. (It offers nothing what 
HTML can't do, but creates more problems) 


And it still doesn't solve the problem, because a:

* div with 1px border
* table cell with 1px border

look exactly in the browser, but have much different (X)HTML source.


Testing 'visual equivalency' of two ([x]html|svg|whatever) documents is 
unfeasible IMHO. We need a compromise, like deciding to use a div or a 
table to produce some visual effect.


This is required anyway, because while it's true that there are a dozen 
ways to generate the same page, they will differ wildly on some relevant 
aspects (e.g. browser compatibility, table- or css- based layout, etc.), 
so you have to make a decision at some point and choose one.






And there are many ways to write code that looks visually the same,
and yet is wildly different. More so for, lets say SVG.


My point was that 'semantically' comparing XML data structures instead
of their ascii representations is an improvement.




Of course this doesn't take into account specific cases like SVG, where
you have 'semantically' different xml documents producing the same
(visual) output.




To address this specific case one would need a way to test the 'visual'
equivalence of two svg documents.



The same for HTML documents. Hm. Maybe one could convert them to PNG and 
compare the outputs. But this is also hard. *thinks*


Interesting...



Best wishes,

Tels


- -- 
 Signed on Wed Nov  2 18:06:15 2005 with key 0x93B84C15.

 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "We're confident that DNF will be one of the greatest, if not the
 greatest, game of 1998. And this confidence is not misplaced." -Scott
 Miller, 1997 (http://tinyurl.com/6m8nh)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQ2jy+ncLPEOTuEwVAQGOTQf9FDcLaYVVoYdgfq41pcqQK9avi1oqaqmp
GKKMVnYT1PsDkhYxxgCj2MYJd7+nVZ+v5n+nW0PN2pjfHzPvDOq5bIHTbqqZaJ4s
k14oUBk0JRLx78k9jQORdWhGbgWR2vAtcRtN6thI1IqANRGNX9kMQscSPl1gVaEG
Wwz/NYY6JJJ5+DWZORa3xOPp3daE4lFY+pJl2ENSmcpqNBLlMBPm2/ajw0aa6Zkv
Iz0TOh3pyXxzPwT7c4lP3kwdySc1yikUftan753yvAErCEaFmXEFbNYZE8L2xal5
o/d+aQ1uBh1r2ycCG918y6z04CL9Y5QA0GRW1ztKFbLLhSXA+5Sq4A==
=M0v6
-END PGP SIGNATURE-




--
Marcello Romani
Developer
Spin s.r.l.
Reggio Emilia
http://www.spinsoft.it

CPAN Testers results

[Ovid]

Hi all,

I've noticed that http://search.cpan.org/~ovid/HOP-Parser-0.01/,
amongst other modules, has no CPAN test results appearing even though
CPAN tester reports are coming in.  I've seen this for other modules,
too.

Is there an announced reason for this I missed or is something down?

Cheers,
Ovid

-- 
If this message is a response to a question on a mailing list, please send
follow up questions to the list.

Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Re: CPAN Testers results

[Christopher H. Laco]

Ovid wrote:
> Hi all,
> 
> I've noticed that http://search.cpan.org/~ovid/HOP-Parser-0.01/,
> amongst other modules, has no CPAN test results appearing even though
> CPAN tester reports are coming in.  I've seen this for other modules,
> too.
> 
> Is there an announced reason for this I missed or is something down?
> 
> Cheers,
> Ovid
> 
I've often wondered this myself. It seems like it builds up some sort of
delta or count of reports, then does a build; as to avoid rebuilding
stats for every report email that comes in.

Or, somethings just broken. :-)

-=Chris


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Proposed Kwalitee tests: has_license and/or has_meta_yml_license

[chromatic]

On Wed, 2005-11-02 at 17:19 +0100, David Landgren wrote:

> I know that the current alpha of ExtUtils::MakeMaker supports this, but 
> until it is released as stable *and* module authors have the time to 
> upgrade EU::MM *and* release a new version of their module(s), those 
> authors will be penalised through no fault of their own.

At least that's consistent with many other Kwalitee tests!

-- c

Re: Proposed Kwalitee tests: has_license and/or has_meta_yml_license

[David Landgren]

Chris Dolan wrote:

On Nov 2, 2005, at 10:19 AM, David Landgren wrote:


Chris Dolan wrote:

In the last year as a Fink maintainer (Mac OS X debian-like  package  
manager), I've come across a couple CPAN modules that  have no 
license  information at all.  It's very frustrating.  I've  submitted 
RT bugs,  but one of them has been fixed (thanks Ken  Williams).
To encourage authors to correct this oversight, I propose a new  
pair  of Kwalitee tests.  Both would be nice, but if either of  them 
were  implemented, I'd be thrilled.  I'd prefer that someone  else 
implement  the test (lack of tuits), but if there is approval  for 
the idea  without a motivated implementer I will take a hack  at it.
 1) has_license -- check for the presence of a file named  something  
like LICENSE or COPYING or COPYLEFT or GPL or ... (each  test case  
insensitive, with or without .txt extensions).   Alternatively, the  
test can be more liberal by looking for the  string "copyright" in  
README, *pm and *.pod.
 2) has_meta_yml_license -- check for a META.yml field named   
"license".  Module::Build supports this.




That would suck, you may as well propose a Kwalitee bit for modules  
that use Module::Build.


I know that the current alpha of ExtUtils::MakeMaker supports this,  
but until it is released as stable *and* module authors have the  time 
to upgrade EU::MM *and* release a new version of their module (s), 
those authors will be penalised through no fault of their own.


David



What penalty?  The whole point of Kwalitee is not to reward authors  who 
jump through hoops, but to encourage authors to live up to  community 


I don't know how to distinguish between someone who likes to jumps 
through hoops and someone who cares about their modules. I choose to 
achieve the highest possible Kwalitee for my modules because it's a way 
of showing people that I care.


expectations.  That includes good packaging, good POD and,  I say 
emphatically, clear licensing.  Anything we can do to encourage  authors 
to more clearly state their license is a good thing.  If that  in turn 
means encouraging them to 1) use Module::Build, 2) upgrade  EU::MM or 3) 
hand-edit META.yml, then I think that's a burden worth  bearing.


My licensing terms are clearly stated in the POD, using the more-or-less 
canonical "licensed under the same terms as Perl itself" term.


I am not going to use Module::Build. I've tried it but I prefer EU::MM, 
at least for the time being. I'm all for the concept, but I wanted to do 
something really basic with it for a new module a while ago. I forget 
the details, but after futzing around for a while I just found it easier 
to go back to EU::MM.


Hand-editing META.yml doesn't work. It gets overwritten when I make 
tardist or something. If there's a way around that, I'm all ears.


You're complaining that its too big a burden to clearly state your  
module's license?  To me that's just crazy.  To some people, the  
license is actually more important than the module (e.g. if I can  only 
redistribute Artistically license code).


No. I'm complaining that there's no need for two different Kwalitee 
points for this, that's all. I think one is sufficient (and a very 
worthy one I should add, in case I wasn't being clear, which I probably 
wasn't).


David
--
"It's overkill of course, but you can never have too much overkill."

Re: CPAN Testers results

[Graham Barr]

On Wed, November 2, 2005 11:48 am, Christopher H. Laco wrote:
> Ovid wrote:
>> Hi all,
>>
>> I've noticed that http://search.cpan.org/~ovid/HOP-Parser-0.01/,
>> amongst other modules, has no CPAN test results appearing even though
>> CPAN tester reports are coming in.  I've seen this for other modules,
>> too.
>>
>> Is there an announced reason for this I missed or is something down?
>>
> I've often wondered this myself. It seems like it builds up some sort of
> delta or count of reports, then does a build; as to avoid rebuilding
> stats for every report email that comes in.

testers.cpan.org provides an SQLite database of the result.
search.cpan.org checks this file for changes once an hour and if it has
changed it downloads it and used the new data.

I do not know how ofter testers.db is updated though.

Graham.

Re: Proposed Kwalitee tests: has_license and/or has_meta_yml_license

[Randy W. Sims]

David Landgren wrote:
I am not going to use Module::Build. I've tried it but I prefer EU::MM, 
at least for the time being. I'm all for the concept, but I wanted to do 
something really basic with it for a new module a while ago. I forget 
the details, but after futzing around for a while I just found it easier 
to go back to EU::MM.


FWIW, bug reports and missing feature reports are always welcome. There 
is an active mailing list at:


 

Regards,
Randy.

Re: $_ defaulting for mutating ops

[John Williams]

On Wed, 2 Nov 2005, Michele Dondi wrote:
> On Fri, 28 Oct 2005, John Williams wrote:
> > But IMHO the reduction in typing for this relatively minor issue is not
> > really worth the surprise to newbies at seeing operandless operators.
>
> I don't buy that argument as newbies are already exposed to all sorts of
> surprises including operandless operators. Including mutating operandless
> operators. What is s/// after all? Or is there a good reason for an
> asymmetry between different classes of operators?

Well, s/// is a term, for one thing.

It is not so much an operator, as it is a subroutine with really strange
syntax, and the side-effect of changing the $_ variable.  You need to use
an operator to get it to affect a different variable.

It looks funny no matter how much you squint your eyes.  Not that that is
a bad thing of course, but I don't think it should be used as an example
for operators to follow.

~ John Williams

Re: Proposed Kwalitee tests: has_license and/or has_meta_yml_license

[Chris Dolan]

On Nov 2, 2005, at 12:13 PM, David Landgren wrote:
No. I'm complaining that there's no need for two different Kwalitee  
points for this, that's all. I think one is sufficient (and a very  
worthy one I should add, in case I wasn't being clear, which I  
probably wasn't).


Ahh, that was unclear from your message.  I thought you were  
protesting the addition of a new Kwalitee test in general, hence my  
annoyance.  Apologies for the misunderstanding.


I originally advocated for one of the two methods of determining the  
license, not necessarily for both.


Chris

P.S.  On a marginally-related note, I released  
Module::License::Report yesterday.  Unfortunately, it's not  
immediately useful for Kwalitee because it eval()s code from  
Makefile.PL and/or Build.PL, and makes use of  
Module::Depends::Intrusive which does more of the same.


--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703

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: Test Suite Slowing Down My Development

[Tels]

-BEGIN PGP SIGNED MESSAGE-

Moin Marcello,

On Wednesday 02 November 2005 18:36, Marcello wrote:
> Tels ha scritto:
> > -BEGIN PGP SIGNED MESSAGE-
> >
> > Moin,
> >
> > On Wednesday 02 November 2005 18:02, Marcello wrote:
> >>Tels ha scritto:
[snip]
> >>>Might be, but I am not generting XML, but HTML...
> >>
> >>Valid XHTML is also valid XML.
> >
> > But valid XHTML doesn't work well in the praxis. (It offers nothing
> > what HTML can't do, but creates more problems)
> >
> > And it still doesn't solve the problem, because a:
> >
> > * div with 1px border
> > * table cell with 1px border
> >
> > look exactly in the browser, but have much different (X)HTML source.
>
> Testing 'visual equivalency' of two ([x]html|svg|whatever) documents is
> unfeasible IMHO. We need a compromise, like deciding to use a div or a
> table to produce some visual effect.
>
> This is required anyway, because while it's true that there are a dozen
> ways to generate the same page, they will differ wildly on some
> relevant aspects (e.g. browser compatibility, table- or css- based
> layout, etc.), so you have to make a decision at some point and choose
> one.

Well, yes I did. :) The problem arose when I switched from "one table cell 
per node" to "3x3 table cells per node", and again when I switched theway 
CSS classes were used and again when I changed them again etc. Each time 
the source changed, but the basic output remained the same - and yet I 
had to adapt dozends of test.

That was the original problem, and so far I haven't found  a way to really 
avoid it. But the discussion has been interesting :)

best wishes,

Tels

- -- 
 Signed on Wed Nov  2 20:07:47 2005 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "To be beautiful is enough! If a woman can do that well who should
 demand more from her? You don't want a rose to sing." -- Thackeray

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQ2kPEHcLPEOTuEwVAQH4Mwf+J8zZ/e7IEOVl0qwRRPCWhQT0UA+NgH4Y
P0+WY8cowWbQx23+p6/HAZTuMFOygH8aAfeCioXlbV7OskeI0vD+Zevp0iPhT1uk
xVf7McV2yu1qOVDko9zgLr+LrrkMgqUeINPiyqBUCemobKjhyr7c3jX6AfXvz5l5
0UukfGc89y9sSsuxlgVMAMr1RgbekQmcA3sctPiDYVkpHLbvM/I/Gzpi2+hEuDCa
JDASjcKKxYHO8NMD25ba4Wxttu/0C8Gh+h15XY+zgNFAP/p5pRFeF62qXz1m5jcg
thYUO+QjBLd5hmuusoH6SNNGhX7rv6ltZD2wtomuY5GGbO0VVrW/XQ==
=JwwY
-END PGP SIGNATURE-

Segfault with structs and CSTR

[Joshua Isom]

I'm trying to use libc to be able to do a directory listing, and and if 
I used the DATATYPE_CSTR I get a segfault, and if I use 
DATATYPE_STRING, I get a "returning unhandled string type in struct".  
I don't know if I'm doing the calls wrong or what since the 
documentation is vague in places.  pdb crashes on launch, seg fault.  I 
tried running parrot under gdb and gdb seg faulted.  I'm not too 
familiar with gdb, though, but with the dump file I was able to get 
this.


Program received signal SIGSEGV, Segmentation fault.
0x283ce659 in strlen () from /lib/libc.so.5

Here's a backtrace...

#0  0x283ce659 in strlen () from /lib/libc.so.5
#1  0x081bda43 in ret_string (interpreter=0x827e000, p=0x84e0008 ".", 
type=-69)

at unmanagedstruct.pmc:305
#2  0x081be35f in Parrot_UnManagedStruct_get_string_keyed (
interpreter=0x827e000, pmc=0x84a2050, key=0x8476ee0)
at unmanagedstruct.pmc:832
#3  0x080ee5f0 in Parrot_set_s_p_kc (cur_opcode=0x84c3e24,
interpreter=0x827e000) at set.ops:511
#4  0x081549ac in runops_slow_core (interpreter=0x827e000, pc=0x84c3e24)
at src/runops_cores.c:153
#5  0x081510d8 in runops_int (interpreter=0x827e000, offset=0)
at src/interpreter.c:750
#6  0x081538c5 in runops (interpreter=0x827e000, offs=0) at 
src/inter_run.c:81

#7  0x080c0143 in Parrot_runcode (interpreter=0x827e000, argc=1,
argv=0xbfbfec2c) at src/embed.c:869
#8  0x080bff9c in Parrot_runcode (interpreter=0x827e000, argc=1,
argv=0xbfbfec2c) at src/embed.c:808
#9  0x0808308c in main (argc=1, argv=0xbfbfec2c) at imcc/main.c:647

Anyway, here's my pir file.

#!/opt/parrot/bin/parrot

.sub _main @MAIN
.local pmc libc
.local pmc opendir
.local pmc readdir
.local pmc closedir
loadlib libc, "/usr/lib/libc.so"
dlfunc opendir, libc, 'opendir', 'pt'
dlfunc readdir, libc, 'readdir', 'pp'
dlfunc closedir, libc, 'closedir', 'ip'
store_global 'libc::opendir', opendir
store_global 'libc::readdir', readdir
store_global 'libc::closedir', closedir
.local pmc curdir
curdir = libc::opendir(".")
.local OrderedHash entry
entry = libc::readdir(curdir)

.include "/opt/parrot/runtime/parrot/include/datatypes.pasm"
new $P2, .OrderedHash
set $P2["d_fileno"], .DATATYPE_INT
push $P2, 0
push $P2, 0
set $P2["d_reclen"], .DATATYPE_SHORT
push $P2, 0
push $P2, 0
set $P2["d_type"], .DATATYPE_CHAR
push $P2, 0
push $P2, 0
set $P2["d_name"], .DATATYPE_CSTR
#set $P2["d_name"], .DATATYPE_STRING
push $P2, 0
push $P2, 0
assign entry, $P2

$S0 = entry["d_name"]
print $S0
.end

a note WRT bsr

[Leopold Toetsch]

Due to the variable-sized register frames, the usage of bsr/ret has 
some more limitations: you can't bsr into a different .sub anymore.


TODO the PASM/PIR assembler should catch this abuse of bsr.

.sub main
   bsr foo
.end

.sub foo
  # a lot of registers used
  # bang
  ret
.end

bsr is only safe inside one .sub:

.sub main
   bsr foo
   ...
foo:
   ...
   ret
.end

leo

[perl #37590] [TODO] Catch illegal use of bsr at compile time.

[via RT]

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




Begin forwarded message:

> From: Leopold Toetsch <[EMAIL PROTECTED]>
> Date: November 2, 2005 3:53:31 PM EST
> To: Perl 6 Internals 
> Subject: a note WRT bsr
>
> Due to the variable-sized register frames, the usage of bsr/ret has  
> some more limitations: you can't bsr into a different .sub anymore.
>
> TODO the PASM/PIR assembler should catch this abuse of bsr.
>
> .sub main
>bsr foo
> .end
>
> .sub foo
>   # a lot of registers used
>   # bang
>   ret
> .end
>
> bsr is only safe inside one .sub:
>
> .sub main
>bsr foo
>...
> foo:
>...
>ret
> .end
>
> leo
>
>

Re: $_ defaulting for mutating ops

[Sam Vilain]

On Wed, 2005-11-02 at 11:46 -0700, John Williams wrote:
> It is not so much an operator, as it is a subroutine with really strange
> syntax, and the side-effect of changing the $_ variable.  You need to use
> an operator to get it to affect a different variable.

operators _are_ subroutines.  There is no difference.

 multi sub *infix:<*> (Set $one, Set $two) returns Set {
 $one.intersection($two);
 }

Sam.

Re: $_ defaulting for mutating ops

[Sam Vilain]

On Wed, 2005-11-02 at 09:03 -0500, Rob Kinyon wrote:
> I think the difference comes from the Principle of Least Surprise. The
> various operators being discussed in this thread are all operators
> which are in languages that have common use - C, C++, Java, the .Net
> stack, etc. Regexen and the various built-ins are generally considered
> to be Perl-specific, so if they're weird, this is just a Perl-ism. The
> PoLS doesn't apply.
> 
> Yes, from a consistency point of view, ALL operators should default to
> $_ or some other sensible item ($*STDIN for <>, etc). However, the
> PoLS does need to guide our decisions.

I think the PoLS should be applied firstmost and foremost to a person
who is learning the language without any preconceptions of how previous
languages work.  The logical building blocks of how the language works
should build on each other; the fewer exceptions relative to *those
foundations* the better.

Specifically, catering for the preconceptions of how the language
behaves as a whole to those trained in lower order languages like you
mention (though is .net a language?) should probably be avoided.

That being said, there are probably other more pressing reasons that ops
should not accept $_ as default; I would guess, for a start, it makes
determining semantics very difficult.  Does  ++; mean &postfix:<++> or
&prefix:<++> ?

Sam.

automated web testing with selenium

[Luke Closs]

Hey there.

I was just interviewed by qapodcast.com about Selenium, a cool new
automated web testing tool.  It's really great, and super easy to use.

Also, yesterday Test::WWW::Selenium was uploaded to CPAN, so Selenium
can now be driven by perl!

Anyways, check out the podcast at http://qapodcast.com

Cheers,
Luke

-- 
Luke Closs
PureMessage Developer 
There is always time to juggle in the Sophos Zone.

Re: Proposed Kwalitee tests: has_license and/or has_meta_yml_license

[H.Merijn Brand]

On Wed, 02 Nov 2005 17:19:07 +0100, David Landgren <[EMAIL PROTECTED]> wrote:

> Chris Dolan wrote:
> > In the last year as a Fink maintainer (Mac OS X debian-like package  
> > manager), I've come across a couple CPAN modules that have no license  
> > information at all.  It's very frustrating.  I've submitted RT bugs,  
> > but one of them has been fixed (thanks Ken Williams).
> > 
> > To encourage authors to correct this oversight, I propose a new pair  of 
> > Kwalitee tests.  Both would be nice, but if either of them were  
> > implemented, I'd be thrilled.  I'd prefer that someone else implement  
> > the test (lack of tuits), but if there is approval for the idea  without 
> > a motivated implementer I will take a hack at it.
> > 
> >  1) has_license -- check for the presence of a file named something  
> > like LICENSE or COPYING or COPYLEFT or GPL or ... (each test case  
> > insensitive, with or without .txt extensions).  Alternatively, the  test 
> > can be more liberal by looking for the string "copyright" in  README, 
> > *pm and *.pod.
> > 
> >  2) has_meta_yml_license -- check for a META.yml field named  
> > "license".  Module::Build supports this.
> 
> That would suck, you may as well propose a Kwalitee bit for modules that 
> use Module::Build.

You surely mean *not* using Module::Build

using M::B inflicts a huge compatibility problem on using
the module on older perls

Now for my real opinion, I think a module shall not be judged/qualiteed on
the used build system.

> I know that the current alpha of ExtUtils::MakeMaker supports this, but 
> until it is released as stable *and* module authors have the time to 
> upgrade EU::MM *and* release a new version of their module(s), those 
> authors will be penalised through no fault of their own.
> 
> David
> 
> > These tests should not care which license is claimed, just that there  
> > is a license present.


-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2  on HP-UX 10.20, 11.00 & 11.11,
 AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
 reports  to: [EMAIL PROTECTED],perl-qa@perl.org

Re: $_ defaulting for mutating ops

[Juerd]

Sam Vilain skribis 2005-11-03 11:01 (+1300):
> Does  ++; mean &postfix:<++> or &prefix:<++> ?

I no longer think $_ defaulting for mutating ops is a good idea, but to
answer your question, read the original post: all these would imply the
LHS, so that makes ++ postfix.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

[perl #37592] [TODO] tests for examples/streams

[via RT]

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


The examples in 'examples/streams' should also be tested.
See t/examples/pir.t

Re: Role Method Conflicts and Disambiguation

[Jonathan Scott Duff]

On Tue, Nov 01, 2005 at 04:02:04PM -0800, Jonathan Lang wrote:
> True enough; but it needn't be true that d have the same tools
> available to resolve the conflicts that c has.
> 
> There are three ways that a role can deal with a conflict:
> 
> 1. choose one of a set of available methods to call its own.
> 2. create a version of its own.
> 3. pass the buck.
> 
> In the first case, the question is how we define the set of available
> methods: do we make the full hierarchy of ancestors available to the
> role, or do we say that only the immediate parents are available? 

People keep using the word "hierarchy" when talking about roles and I
keep thinking that it is the one word that definitely does NOT apply.
Heirarchies are for classes and inheritance relationships, not roles
and composition.

In my world view, a role that is composed of two other roles has full
view of the methods/attributes defined in the roles that compose it
because the landscape is quite flat. There are no hills and valleys.
When it finally comes down to composing into a class, the class sees
all of the methods/attributes provided by each and every role even the
role inside a role inside a roles.

> Another way to put this would be: should the "DOESA" list be treated
> as public or private?  (My preference: the "DOESA" list should be
> private.  You don't lose any capabilities by doing so, other than the
> capability to access stuff not explicitly declared - a capability that
> roles don't need, and probably shouldn't have.)  If "DOESA" is
> private, then d won't have access to anything from a or b without
> explicitly including them in its own DOESA list.  This seems to be
> restrictive, and it is - but only in the same way that making an
> attribute private is restrictive.

When you say:

role A { ... }
role B { ... }
role C does A does B { ... }
role D does C { ... }

roles A and B are composed into C at compile time.  If both A and B
define a method foo(), then there is a conflict (immediately, at
compile time) unless you've somehow told perl that it should defer
composition until it's actually composing classes.

What's really at question I think is whether the _default_ is to compose
immediately or to postpone composition until there's a class to compose
into. If you have roles that are never composed into classes, then it
won't matter if there's a conflict as you can't instantiate a role (not
without first turning it into a class). So, on one hand it does make
sense to defer composition until there's a class to compose into. But
it also makes sense to deal with composition conflicts incrementally
too (as roles are composed into other roles).

> The second case is pretty straightforward.

And isomorphic to the first case as it is the resolution to the first
case.

> In the third case, I'd be inclined to say that passing the buck is
> equivalent to creating an undefined version of your own - that is, not
> addressing a conflict involving method x is equivalent to saying
> "method x ($arg) { ... }".  IOW, a class that does a role that passed
> the buck is faced with an "undefined method" complaint if it doesn't
> do something about it, not an "unresolved conflict" complaint.

Nah, the third case is ye olde standard conflict, just perhaps occurring
at a different space+time than had the roles been composed immediately.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Role Method Conflicts and Disambiguation

[Yuval Kogman]

On Wed, Nov 02, 2005 at 16:37:29 -0600, Jonathan Scott Duff wrote:
> On Tue, Nov 01, 2005 at 04:02:04PM -0800, Jonathan Lang wrote:
> > True enough; but it needn't be true that d have the same tools
> > available to resolve the conflicts that c has.
> > 
> > There are three ways that a role can deal with a conflict:
> > 
> > 1. choose one of a set of available methods to call its own.
> > 2. create a version of its own.
> > 3. pass the buck.
> > 
> > In the first case, the question is how we define the set of available
> > methods: do we make the full hierarchy of ancestors available to the
> > role, or do we say that only the immediate parents are available? 
> 
> People keep using the word "hierarchy" when talking about roles and I
> keep thinking that it is the one word that definitely does NOT apply.
> Heirarchies are for classes and inheritance relationships, not roles
> and composition.

Uh, roles are composed wrt to the hierarchy of who does who.

> In my world view, a role that is composed of two other roles has full
> view of the methods/attributes defined in the roles that compose it
> because the landscape is quite flat. There are no hills and valleys.
> When it finally comes down to composing into a class, the class sees
> all of the methods/attributes provided by each and every role even the
> role inside a role inside a roles.

The composition is basically mixin with some exceptions, but there's
still a hierarchy

> roles A and B are composed into C at compile time.  If both A and B
> define a method foo(), then there is a conflict (immediately, at
> compile time) unless you've somehow told perl that it should defer
> composition until it's actually composing classes.

Class composition also happens at compile time... There's no reason
to make the error occur too early for usefulness to be around. As
long as it's not too late ;-)

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



pgpJsS5MicP4a.pgp
Description: PGP signature

Re: Role Method Conflicts and Disambiguation

[Jonathan Lang]

Jonathan Scott Duff wrote:
> People keep using the word "hierarchy" when talking about roles and I
> keep thinking that it is the one word that definitely does NOT apply.
> Heirarchies are for classes and inheritance relationships, not roles
> and composition.
>
> In my world view, a role that is composed of two other roles has full
> view of the methods/attributes defined in the roles that compose it
> because the landscape is quite flat. There are no hills and valleys.
> When it finally comes down to composing into a class, the class sees
> all of the methods/attributes provided by each and every role even the
> role inside a role inside a roles.

-snip-

> When you say:
>
> role A { ... }
> role B { ... }
> role C does A does B { ... }
> role D does C { ... }
>
> roles A and B are composed into C at compile time.  If both A and B
> define a method foo(), then there is a conflict (immediately, at
> compile time) unless you've somehow told perl that it should defer
> composition until it's actually composing classes.

Let's say you have this:

  role A {method foo() { code1; } }
  role B {method foo() { code2; } }
  role C does A does B {
method foo() { A::foo(); }
method bar() { B::foo(); }
  }

Should the following be valid?

  role D does C { method foo() { B::foo(); } }

IMHO, it shouldn't, because D doesn't do B.

--
Jonathan "Dataweaver" Lang

Re: PGE problem with non-greedy quantifiers

[Allison Randal]

On Nov 1, 2005, at 10:45, Patrick R. Michaud wrote:


Oops, I left out a "goto" -- now fixed in r9687.


Awesome! It works beautifully, and here's the result:

  http://use.perl.org/~Allison/journal/27427

Allison

Re: Role Method Conflicts and Disambiguation

[Luke Palmer]

On 11/2/05, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> Let's say you have this:
>
>   role A {method foo() { code1; } }
>   role B {method foo() { code2; } }
>   role C does A does B {
> method foo() { A::foo(); }
> method bar() { B::foo(); }
>   }
>
> Should the following be valid?
>
>   role D does C { method foo() { B::foo(); } }
>
> IMHO, it shouldn't, because D doesn't do B.

Of course it should.  To me, "role D does C" says, not "anything that
does D must do C", but "anything that does D does C".

It makes sense if you think of them as interfaces.  Say you have a
role Complexifiable (that is, this thing can behave like a complex
number).  Then you have:

role Numifiable does Complexifiable {
...
}

Complexifiable is just an abstraction that is used rarely; most things
will implement Numifiable.  But if you can behave like a real number,
certainly you can behave like a complex number.  But you don't want
people to have to say:

class Foo {
does Complexifiable;  # wtf?  what does that mean
does Numifiable;
...
}

Haskell makes a distinction between the two cases we're talking about here:

-- You need to be Complexifiable before you can be Numifiable
class (Complexifiable a) => Numifiable a where
...

-- Anything that is Numifiable is also Complexifiable
--  (by these rules):
instance Numifiable a => Complexifiable a where
...

To me, "does" is much more like the latter.  Maybe we have constraints
on roles that can do the former[1]:

role Numifiable {
where Complexifiable;
...
}

Or maybe we don't, and if you need them to implement Complexifiable
first, you just leave some methods undefined that they have to define
themselves, thus completing the interface.  I was always annoyed at
Haskell because I had to define an instance of Eq before I could
define an instance of Ord, even though Ord's algebra implies that I
can compare things for equality (and especially, since Ord defines a
total order, that a <= b and b <= a implies a = b, so it could have
implemented that for me).

It kind of seems like a Perlish thing to do to blur the two behaviors
together.

Luke

[1] Which is just this theory, without any extensions:

theory Numifiable{^T} <= Complexifiable{^T} {
...
}

So it would just be sugar in any case.

reconfiguring configure

[Joshua Hoblitt]

Hi Folks,

I don't think it's worth reviewing everything that's untidy about the
current configure systems; it should be pretty obvious from looking at
the code that it needs refactoring.  This isn't a criticism of the
original authors, just that the system has out grown it's roots as
'throw away' code.  Since then 'the plan' has been clarified and we
definitely will need some sort of configure system to run on top of
miniparrot.  There's no reason that configure system can't be written in
p5 (but shipped as compiled PIR).

In addition to cleaning up the code for maintenance some features need to
be added:

- probes need to be able to cleanly bail out if they can't find a
  requirement
- there needs to be some way of passing parameters into a probe.
  For example, telling the gcc probe which version of gcc are
  acceptable

I propose the following changes:

- The Configure::Data class gets lifted out of config/init/data.pl
  and put into Parrot::Configure::Data.

- Parrot::Configure::Step is renamed to Parrot::Configure::Util (or
  something).

- Parrot::Configure::Step becomes a very minimal base class for
  other steps.

- Steps stay in the same file they are in now but have their
  packages renamed to Parrot::Configure::Step::${type}::${name}.

(like: grep -lR 'package Configure::Step' config | grep -v .svn | xargs
perl -MFile::Basename -pi -e '$foo = basename($ARGV); $foo =~ s/\.pl$//;
$bar = basename dirname $ARGV; $_ =~
s/(?new;
# Options are held as class data in the Parrot::Configure::Options
# namespace
$conf->options(%args);
# Setup a step to run and pass any extra parameters to that steps
# runstep
# method.  Steps are (to begin with) run in the order they are
# specified.  It # is a fatal error at this point if the step/plugin is
# registered.
$conf->step('cc', ...);
# The step method can be chained.
$conf->step('lex')->step('yacc');
# Steps can only be run once.  Fatal error.
$conf->step('cc');
# Run all specified steps.  Returns a Parrot::Configure::Data object.
$conf->run;

# Something that might be nice
# return a hash of step options => descriptions
$conf->step_options('cc');
--

As a long term goal I'd like to see Steps declare their dependencies on
other steps.  So that you only have to declare which steps should be run
and not having to worry about ordering them to handle dependencies on
the results of previous steps. 

Comments/Thoughts?

Cheers,

-J

--


pgpRvSfrbCrer.pgp
Description: PGP signature

Re: Test Suite Slowing Down My Development

[Marcello]

Tels ha scritto:

-BEGIN PGP SIGNED MESSAGE-

Moin Marcello,

On Wednesday 02 November 2005 18:36, Marcello wrote:


Tels ha scritto:


-BEGIN PGP SIGNED MESSAGE-

Moin,

On Wednesday 02 November 2005 18:02, Marcello wrote:


Tels ha scritto:


[snip]


Might be, but I am not generting XML, but HTML...


Valid XHTML is also valid XML.


But valid XHTML doesn't work well in the praxis. (It offers nothing
what HTML can't do, but creates more problems)

And it still doesn't solve the problem, because a:

* div with 1px border
* table cell with 1px border

look exactly in the browser, but have much different (X)HTML source.


Testing 'visual equivalency' of two ([x]html|svg|whatever) documents is
unfeasible IMHO. We need a compromise, like deciding to use a div or a
table to produce some visual effect.

This is required anyway, because while it's true that there are a dozen
ways to generate the same page, they will differ wildly on some
relevant aspects (e.g. browser compatibility, table- or css- based
layout, etc.), so you have to make a decision at some point and choose
one.



Well, yes I did. :) The problem arose when I switched from "one table cell 
per node" to "3x3 table cells per node", and again when I switched theway 
CSS classes were used and again when I changed them again etc. Each time 
the source changed, but the basic output remained the same - and yet I 
had to adapt dozends of test.


Ehm... did I say "make a choice" ? ;-)



That was the original problem, and so far I haven't found  a way to really 
avoid it. But the discussion has been interesting :)


It's been interesting for me too.
Thanks. :-)



best wishes,

Tels

- -- 
 Signed on Wed Nov  2 20:07:47 2005 with key 0x93B84C15.

 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "To be beautiful is enough! If a woman can do that well who should
 demand more from her? You don't want a rose to sing." -- Thackeray

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQ2kPEHcLPEOTuEwVAQH4Mwf+J8zZ/e7IEOVl0qwRRPCWhQT0UA+NgH4Y
P0+WY8cowWbQx23+p6/HAZTuMFOygH8aAfeCioXlbV7OskeI0vD+Zevp0iPhT1uk
xVf7McV2yu1qOVDko9zgLr+LrrkMgqUeINPiyqBUCemobKjhyr7c3jX6AfXvz5l5
0UukfGc89y9sSsuxlgVMAMr1RgbekQmcA3sctPiDYVkpHLbvM/I/Gzpi2+hEuDCa
JDASjcKKxYHO8NMD25ba4Wxttu/0C8Gh+h15XY+zgNFAP/p5pRFeF62qXz1m5jcg
thYUO+QjBLd5hmuusoH6SNNGhX7rv6ltZD2wtomuY5GGbO0VVrW/XQ==
=JwwY
-END PGP SIGNATURE-




--
Marcello Romani
Developer
Spin s.r.l.
Reggio Emilia
http://www.spinsoft.it