Re: Array/list transformations.
On Tue, Dec 27, 2005 at 12:10:45AM -0500, Rob Kinyon wrote: : Creating an array whose positions are aliases for positions in another : array can be useful. How about : : my @s := @a[0,2,4] is alias; : : @a[2] = 3; # @s[1] == 3 : @s[1] = 4; # @a[2] == 4 : : The default slicing behavior would default to "is copy", to preserve : the current semantics. Does that sound reasonable? Hmm. Assignment is already adequate for copying semantics. And binding the individual elements can presumably be done by: my [EMAIL PROTECTED] := @a[0,2,4]; Larry
Re: Array/list transformations.
On 12/22/05, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote: > On Thu, Dec 22, 2005 at 04:47:21PM +0100, Michele Dondi wrote: > > Also I wonder if one will be able to push(), pop(), etc. array slices as > > well whole arrays. A' la > > > > my @a=qw/aa bb cc dd ee/; > > my $s=pop @a[0..2]; # or [0,2] or just [0] for that matters! > > # $s='cc'; > > # @a=qw/aa bb dd ee/; => same as what I can do with slice() > > > > Not terribly necessary, but indeed consistent IMHO. > > Not quite sure why you'd want this, but if we have something like this: > > my @a = qw/aa bb cc dd ee/; > my @slice := @a[0..2]; > my $s = pop @slice; > > (where @slice is a "reference" to part of @a) > > You get what you want and more. To echo Scott's point, @a[0..2] === @a.splice(0,3). Now, a more interesting problem is @a[0,2,4], which doesn't map to a single splice() call. Ruby's syntax for this is problematic, which points to a problem with how the solutionspaces are mapping to the problemspaces. Creating an array whose positions are aliases for positions in another array can be useful. How about my @s := @a[0,2,4] is alias; @a[2] = 3; # @s[1] == 3 @s[1] = 4; # @a[2] == 4 The default slicing behavior would default to "is copy", to preserve the current semantics. Does that sound reasonable? Rob
Re: Match objects
On 12/26/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > > I argue that by the structure of that rule, you should be able to tell > > which xs go with which y. > > ... > > Is there a counterargument that I'm not seeing? > > I'd say that if you want a structured rule, it should be written > that way, as in > > ( (x)* y )* > > or > > ( (x)* (y) )* I wouldn't really call that a counterargument. What I'm after is not "how can I see the correspondence between the inner matches" so much as "how is 'dumb flattening'" useful? It's quite possible that neither of the semantics in my original message are correct. "Deep nesting" seemed much more natural[1] from the implementation side of things, which is why I brought it up. I suppose you could consider dumb flattening to be useful with the following pattern matching two-column text: / [ $:=(<-[|]>) \| $:=(<-[|]>) \n ]* / Where @ and @ would then hold the lines in each of the columns. But that is the only case I can think of, and it doesn't generalize to an arbitrary number of columns (that is, not hardcoded into the regex), which makes me think that it's not an important case.[2] On the other hand, I can't see many cases where deep nesting buys you much where using capturing parens doesn't. It basically spits out the transpose of the same structure. The thing that makes it feel more correct to me is that: (1) it has the same amount of asymptotic memory overhead, and (2) it keeps more information. It may be convenient to work with flattened arrays, but needlessly throwing away information is not usually a wise move. We can provide a "deep flatten" function that makes the flat structure only one function call away; you can't say the same thing going the other direction. But still, the thing that's going to make the decision clear is examples. Luke [1] By which I do *not* mean "easier". In fact, it was a good deal harder. It's hard to say exactly what I mean... [2] If it did generalize, then I would consider it much more important.
Re: How to use Devel::Cover?
Hi James and Randy, Thank you so much for your replies! Yes, the modules that we are testing are not for standard distribution. They are created by other folks in my organization to support and to be part of our current automated integration system. They are our internal use. There already are many unit tests, which created by other folks in my organization, to load (use) those modules and exercise the functions in them. I am trying to figure out how to get the code coverage metrics of these existing units tests on those modules and to figure out where we should add more tests to cover. Yes, because history reason and because product other particular reason, we need use our in house built test harness to execute those tests one by one, and the mechanism in our test harness are different from how standard Test::Harness-based approach work. Our test scripts use APIs that our test harness provides which are not exact same but similar to Test::Simple or Test::More provide. I understand and appreciate James' points. Our purpose, our different situation and the effort our people had put in make me have to find a way looks like different from standard way that James mentioned. Randys comment makes me concerning if there is an existing way or tool out there which may help me out to collect code coverage data for our tests. Thanks again and please continue advice if you can. I will continue my research basing on all your feedbacks. Thanks, Scoot --- "Randy W. Sims" <[EMAIL PROTECTED]> wrote: > James E Keenan wrote: > > Scott Wang wrote: > >> Hi Chris, > >> > >> I am still confus. > >> > >> For example, > >> > >> On my Linux box, I have a module > >> "/tmp/experiment/lib/module_to_test.pm" to be > tested, and I have two > >> Perl unit test scripts > "/tmp/experiment/tests/test1.pl" and > >> '"/tmp/experiment/tests/test2.pl" to load the > module_to_test.pm module > >> and execute the subroutines in it. Then, what are > exact "perl > >> -MDevel::Cover" commands I could use to get the > module_to_test.pm > >> module code coverage data from running test1.pl > and test2.pl unit test > >> scripts? I am new in Perl, appreciate your detail > information. > >> > >> > > > > Scott: > > > > With all due respect, I think your confusion is > self-inflicted. You > > acknowledge that you are new to Perl and to > Devel::Cover in particular, > > but you are trying to do things in a way (a) that > would take an > > experienced Perl programmer a lot of time to hack > up; and (b) that an > > experienced Perl programmer would not even bother > with. Why not? > > Because experienced Perl programmers know that the > Perl community > > worldwide has expended considerable effort > developing certain standard > > practices which work right out of the box. > > > > In particular, experienced Perl programmers, when > developing and testing > > a module, structure the module's distribution in a > particular way. Using > > your directory names: > > I've only been half-reading this thread (with > holidays and fighting off > a cold), but my impression is that Scott has > *installed* modules that he > wishes to test rather than a distribution to test. > Wanting to test > installed modules seems a reasonable thing to do for > internal/private > use modules that don't need to be created as > distributions. However, I > don't know of any current way to do this or of any > infrastructure that > would assist here. > > Randy. > > __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Re: How to use Devel::Cover?
James E Keenan wrote: Scott Wang wrote: Hi Chris, I am still confus. For example, On my Linux box, I have a module "/tmp/experiment/lib/module_to_test.pm" to be tested, and I have two Perl unit test scripts "/tmp/experiment/tests/test1.pl" and '"/tmp/experiment/tests/test2.pl" to load the module_to_test.pm module and execute the subroutines in it. Then, what are exact "perl -MDevel::Cover" commands I could use to get the module_to_test.pm module code coverage data from running test1.pl and test2.pl unit test scripts? I am new in Perl, appreciate your detail information. Scott: With all due respect, I think your confusion is self-inflicted. You acknowledge that you are new to Perl and to Devel::Cover in particular, but you are trying to do things in a way (a) that would take an experienced Perl programmer a lot of time to hack up; and (b) that an experienced Perl programmer would not even bother with. Why not? Because experienced Perl programmers know that the Perl community worldwide has expended considerable effort developing certain standard practices which work right out of the box. In particular, experienced Perl programmers, when developing and testing a module, structure the module's distribution in a particular way. Using your directory names: I've only been half-reading this thread (with holidays and fighting off a cold), but my impression is that Scott has *installed* modules that he wishes to test rather than a distribution to test. Wanting to test installed modules seems a reasonable thing to do for internal/private use modules that don't need to be created as distributions. However, I don't know of any current way to do this or of any infrastructure that would assist here. Randy.
Re: How to use Devel::Cover?
Scott Wang wrote: Hi Chris, I am still confus. For example, On my Linux box, I have a module "/tmp/experiment/lib/module_to_test.pm" to be tested, and I have two Perl unit test scripts "/tmp/experiment/tests/test1.pl" and '"/tmp/experiment/tests/test2.pl" to load the module_to_test.pm module and execute the subroutines in it. Then, what are exact "perl -MDevel::Cover" commands I could use to get the module_to_test.pm module code coverage data from running test1.pl and test2.pl unit test scripts? I am new in Perl, appreciate your detail information. Scott: With all due respect, I think your confusion is self-inflicted. You acknowledge that you are new to Perl and to Devel::Cover in particular, but you are trying to do things in a way (a) that would take an experienced Perl programmer a lot of time to hack up; and (b) that an experienced Perl programmer would not even bother with. Why not? Because experienced Perl programmers know that the Perl community worldwide has expended considerable effort developing certain standard practices which work right out of the box. In particular, experienced Perl programmers, when developing and testing a module, structure the module's distribution in a particular way. Using your directory names: /tmp/experiment/ README MANIFEST Makefile.PL # or Build.PL if using Module::Build rather than # ExtUtils::MakeMaker lib/ Module_to_test.pm t/ test1.pl test2.pl You can achieve this directory and file structure a number of ways: the h2xs utility that ships with CPAN; CPAN module ExtUtils::ModuleMaker (which I maintain); or CPAN module Module::Starter (maintained by Ricardo Signes). Whichever you choose, note that the directory in which the test files sit is called 't/' -- not 'tests/'. If you use this structure, and if in your test*.pl files you use the functionality provided by Test::Simple or Test::More, then you are already set up to do coverage analysis with Devel::Cover. Why? Because Devel::Cover is set up to work on top of ExtUtils::MakeMaker's 'make test' or Module::Build's equivalent command. And they in turn are set up to activate Perl's Test::Harness, which in turn is set up to play nicely with Test::Simple and Test::More. You are frustrating this demonstrably successful approach in two ways: (1) You are calling the directory in which your test scripts reside 'tests/' rather than 't/'. An experienced Perl hacker could go into Test::Harness and MakeMaker and make this substitution work -- but a Perl beginner cannot. And, as mentioned above, the experienced Perl hacker wouldn't bother with this, because she knows that the standard approach does what she wants. (2) You imply that your company requires you to use its own testing harness rather than Perl's standard Test::Harness-based approach. Why? More to the point, even if your company requires you to use its own harness at some point in the development cycle, why does this prevent you from using Perl's standard approach at the point with which you're concerned: coverage analysis? If you use the directory structure described above and use Test::Simple or Test::More (or anything else built on Test::Builder), then getting coverage stats is a snap (cf my original posting in this thread for details). Jim Keenan
[perl #38023] [TODO] build - support pkgconfig
# New Ticket Created by Joshua Hoblitt # Please include the string: [perl #38023] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38023 > Parrot should support pkgconfig by installing a pc data file. It should probably be named parrot.pc. -J -- pgp5jxwL3wlQm.pgp Description: PGP signature
Re: Cygwin versun plain XP (for working with Pugs+Parrot together)
On 12/23/05, Peter Schwenn <[EMAIL PROTECTED]> wrote: > Dear 6Compilers, > questions about the internals of parrot (including build/config trouble) are best directed instead to the perl6 internals list, so i've copied them on my response. > Cygwin isn't entirely happy with Parrot (don't know about Pugs). Is the > best approach on "plain" windows for setting up perl5+pugs+parrot to: > > 1. set up a gcc environment > 2. get the tar.gz sources involved > 3. use gcc's make tomake, make test, make install each of > perl (587? or 592?), pugs and parrot > (4. CPANPLUS, ...) > cygwin *should* compile parrot just fine. the last report i see on http://smoke.parrotcode.org/smoke/ for i386-cygwin-gcc is from r10487, which is a few weeks old, though. can any other cygwin users confirm peter's report? there have been some significant changes to the config system lately, these may have broken your platform. i don't understand what you mean by "plain" windows. i use windows with msvc 6 & 7.1. others use msys with mingw. we consider cygwin a different platform, so it's not really "windows" at all. > OR > > is there an advantageous alternative involving PXPerl or ... or some > Cygwin alternative or ...? > i mentioned msys with mingw, which is an alternative. also, there are free microsoft compiler tools, which have been tested in the past, however the only recent reports i know of these are from a ppc-osx emulating i386-windows running them, where the build failed. that's a rather hard setup to debug, though. there should be a good bit of useful information in README.win32, in the parrot root directory. > OR > > work to make Cygwin work (e.g. to Configure.pl Parrot's Makefile) > if it's failing in cygwin, this is the best fix. > PeterS > thanks for reporting. if you can provide the specifics of the config failure and your platform information, this would be much appreciated. ~jerry
(Array) introspection
Hi all, do we have any specifications for array introspection, or introspection of data structures (including subroutines) in general? Say I have this array: my @array (1..9 --> Int); I think I get the first bit with .shape; what about the Int? Since arrays are glorified subroutines, perhaps .signature or something like that would be logical, although I don't know how /natural/ that is. Thanks, -- wolverian <[EMAIL PROTECTED]>
"*** Cannot find a runnable 'ghc' from path" from Pugs Makefile.PL under Cygwin
Perl6'ers
Under Cygwin (bash), while building PUGS, Pugs' Makefile.PL (one of its
henchmen) needs an environment setting to say where a runnable 'ghc' can
be found. I have GHC installed (in its .msi incarnation as required) in
c:/cygwin/home/me/ghc
I tried:
setenv GHC=/home/me/ghc/bin (where the full ghc.exe is)
Could someone give me an example of the ghc environment variable setting
for pugs building that they have used under Cygwin (or minGW or bare GCC.)?
Thanks much, PeterS
p.s. I also tried every variation I could think of, of quoting, \/, and
/home/ghc/bin, C:\cygwin\home\me\ghc\bin, /cygdrive/c/home/me/ghc/bin,
${HOME}/ghc/bin, and truncating ...ghc/bin to ...ghc without any luck.
I also built GHC as a linux app under Cygwin instead of via .msi. Nothing.
GHC Environment for Pugs compilation
In order to Makefile.PL Pugs, what is the environment variable that points to GHC?
Re: How to use Devel::Cover?
On Dec 25, 2005, at 3:46 PM, Scott Wang wrote: I am new to use Devel::Cover. We have lots of product Perl modules in our product "lib" folder and we have lots of Perl test scripts to cover those modules, right now, we are trying to get the code coverage metrics for our tests on those modules. I find we might get help by using Devel::Cover, would you please give me some idea on how I should use the Devel::Cover to generate our tests coverage metrics on our Perl modules? Thanks in advance, Scott If you use Module::Build, then simply type "./Build testcover" and then open cover_db/coverage.html in your browser. If you are using a version of M::B older than 0.27_02, you may wish to manually delete the whole cover_db directory between runs. Later M::B versions auto- detect when cover_db files are out of date. 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/)
Cygwin versun plain XP (for working with Pugs+Parrot together)
Dear 6Compilers, Cygwin isn't entirely happy with Parrot (don't know about Pugs). Is the best approach on "plain" windows for setting up perl5+pugs+parrot to: 1. set up a gcc environment 2. get the tar.gz sources involved 3. use gcc's make tomake, make test, make install each of perl (587? or 592?), pugs and parrot (4. CPANPLUS, ...) OR is there an advantageous alternative involving PXPerl or ... or some Cygwin alternative or ...? OR work to make Cygwin work (e.g. to Configure.pl Parrot's Makefile) PeterS
Re: "*** Cannot find a runnable 'ghc' from path" from Pugs Makefile.PL under Cygwin
On Mon, Dec 26, 2005 at 12:00:11AM -0500, Peter Schwenn wrote: > I've since discovered the prior discussion of Pugs under Cygwin so I > know there's probably not yet a simple answer but enough of a work > around to go forward (building and using Pugs+Parrot+... under Cygwin.) We'll be very happy for contributions on this front. Why don't you join us on IRC and get commit access?[1] Alternatively, I'm using coLinux happily.[2] [1] #perl6 on irc.freenode.org [2] http://www.colinux.org/ -- Gaal Yahas <[EMAIL PROTECTED]> http://gaal.livejournal.com/
Re: External Parrot as opposed to embedded
On Fri, Dec 23, 2005 at 11:24:54PM -0500, Peter Schwenn wrote: > How does Pugs use Parrot "external" as opposed to "embedded"? Have the parrot executable in your path. Don't have "parrot" in the PUGS_EMBED environment variable. (TODO: move over PUGS_EMBED to the config.yml file.) -- Gaal Yahas <[EMAIL PROTECTED]> http://gaal.livejournal.com/
Re: GHC Environment for Pugs compilation
On Fri, Dec 23, 2005 at 02:47:08PM -0500, Peter Schwenn wrote: > In order to Makefile.PL Pugs, what is the environment variable that > points to GHC? It just needs to be in your PATH. Make sure you have version 6.4.1 or a recent development snapshot. -- Gaal Yahas <[EMAIL PROTECTED]> http://gaal.livejournal.com/
Re: "*** Cannot find a runnable 'ghc' from path" from Pugs Makefile.PL under Cygwin
Dear self,
I've since discovered the prior discussion of Pugs under Cygwin so I
know there's probably not yet a simple answer but enough of a work
around to go forward (building and using Pugs+Parrot+... under Cygwin.)
Peter Schwenn
Peter Schwenn wrote:
Perl6'ers
Under Cygwin (bash), while building PUGS, Pugs' Makefile.PL (one of
its henchmen) needs an environment setting to say where a runnable
'ghc' can be found. I have GHC installed (in its .msi incarnation as
required) in c:/cygwin/home/me/ghc
I tried:
setenv GHC=/home/me/ghc/bin (where the full ghc.exe is)
Could someone give me an example of the ghc environment variable
setting for pugs building that they have used under Cygwin (or minGW
or bare GCC.)?
Thanks much, PeterS
p.s. I also tried every variation I could think of, of quoting, \/,
and /home/ghc/bin, C:\cygwin\home\me\ghc\bin,
/cygdrive/c/home/me/ghc/bin, ${HOME}/ghc/bin, and truncating
...ghc/bin to ...ghc without any luck. I also built GHC as a linux app
under Cygwin instead of via .msi. Nothing.
[perl #38028] Some more tests to ops in pir
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #38028] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38028 > Most are trivial, few are important. Cheers Alberto -- Alberto Simões - Departamento de Informática - Universidade do Minho Campus de Gualtar - 4710-057 Braga - Portugal Index: t/compilers/imcc/syn/op.t === --- t/compilers/imcc/syn/op.t (revision 10641) +++ t/compilers/imcc/syn/op.t (working copy) @@ -12,10 +12,15 @@ $I0 += 20 print $I0 print "\n" + +$I0 += -20 +print $I0 +print "\n" end .end CODE 30 +10 OUT ## @@ -25,10 +30,15 @@ $I0 -= 20 print $I0 print "\n" + +$I0 -= -20 +print $I0 +print "\n" end .end CODE -10 +10 OUT pir_output_is(<<'CODE', <<'OUT', "*="); @@ -37,10 +47,15 @@ $I0 *= 20 print $I0 print "\n" + +$I0 *= -2 +print $I0 +print "\n" end .end CODE 200 +-400 OUT pir_output_is(<<'CODE', <<'OUT', "/="); @@ -49,10 +64,18 @@ $I0 /= 2 print $I0 print "\n" + +$N0 = 20 +$N0 /= .5 +$I0 = $N0 +print $I0 +print "\n" + end .end CODE 10 +40 OUT pir_output_is(<<'CODE', <<'OUT', "%="); @@ -61,10 +84,16 @@ $I0 %= 7 print $I0 print "\n" + +$I0 = 200 +$I0 %= 2 +print $I0 +print "\n" end .end CODE 6 +0 OUT pir_output_is(<<'CODE', <<'OUT', ".="); @@ -73,21 +102,32 @@ $S0 .= "cd" print $S0 print "\n" + +$S0 .= "" +print $S0 +print "\n" end .end CODE abcd +abcd OUT + pir_output_is(<<'CODE', <<'OUT', "&="); .sub test :main $I0 = 0b1011 $I0 &= 0b1000 print $I0 print "\n" + +$I0 &= 0b +print $I0 +print "\n" end .end CODE 8 +0 OUT pir_output_is(<<'CODE', <<'OUT', "|="); @@ -96,10 +136,15 @@ $I0 |= 0b1000 print $I0 print "\n" + +$I0 |= 0b0100 +print $I0 +print "\n" end .end CODE 11 +15 OUT pir_output_is(<<'CODE', <<'OUT', "~="); @@ -108,10 +153,15 @@ $I0 ~= 0b1000 print $I0 print "\n" + +$I0 ~= 0b0011 +print $I0 +print "\n" end .end CODE 3 +0 OUT pir_output_is(<<'CODE', <<'OUT', ">>="); @@ -190,10 +240,16 @@ $I0 = length s print $I0 print "\n" + +s = "" +$I0 = length s +print $I0 +print "\n" end .end CODE 3 +0 OUT pir_output_is(<<'CODE', <<'OUT', "x = sin"); @@ -201,7 +257,7 @@ $N0 = sin 0 print $N0 print "\n" -end +end .end CODE 0.00 @@ -213,7 +269,7 @@ $I0 = can $P0, "puts" print $I0 print "\n" -end +end .end CODE 1 @@ -225,7 +281,7 @@ $I0 = isa $P0, "scalar" print $I0 print "\n" -end +end .end CODE 1
External Parrot as opposed to embedded
How does Pugs use Parrot "external" as opposed to "embedded"? (e.g. as expressed in: CAVEATS FOR ALL USERS - Parrot is used to provide Perl6-style regular expressions. Perl5-style regular expressions (eg, rx:perl5/foo/) can be used without any parrot at all. Pugs can be built to use parrot external (the default), or embedded. External is recommended. ) PeterS
Re: Good Perl6 environment
Luke, Thank you very much - that should get me more than started. One more pointer, an elaboration, (a general one to documentation one relation of Pugs to embedded Parrot even better): if Pugs doesn't have a feature yet, like much of Rules, does it ship it off to embedded Parrot for potential help? Thanks again Luke Palmer wrote: On 12/23/05, Peter Schwenn <[EMAIL PROTECTED]> wrote: Perl6'ers Is the "best" (most complete as to Perl6 Language) current setup (for experimenting with Perl6 source code) currently a hybrid: Pugs with embedded Parrot, or is it Perl5 with a large set of Perl6'ish modules. Or something else that I've missed. Definitely pugs. Perl 5 with Perl6:: modules gives you a few nice features, but it is by no means programming in Perl 6. You have to embed Parrot if you want to experiment with rules (or use s:Perl5///). The perl 5 module Perl6::Rules doesn't... um... work. However, rules are a little sketchy just about everywhere, so be prepared to fight with it no matter what you choose. For the former case (Pugs+Parrot) where is starting point for documentation for acquiring configuring and make'ing the right Pugs and Parrot bits? Quite simple, really. Get parrot and build it as usual. Get pugs and set PARROT_PATH="/path/to/parrot/trunk", and then Makefile.PL; make as usual. That should do it. The documentation for that is, as far as I know, in Makefile.PL. It will tell you "Parrot embedding disabled" if you didn't set things up right. Luke
Re: Problem with dwimmery
> As a third possibility, could we huffman-code "do nothing" clauses by
> leaving out the appropriate argument? That is:
>
> while $x-- && some_condition($x);
That's a bit too short for my liking: it is likely to lead to the
traditional C undetectable bug when you write
while $x-- && some_condition($x);
{
some_operation($x);
}
modulo brace style, of course.
--
Stop the infinite loop, I want to get off! http://surreal.istic.org/
Paraphernalia/Never hides your broken bones,/ And I don't know why you'd
want to try:/ It's plain to see you're on your own.-- Paul Simon
The documentation that can be written is not the true documentation.
Re: How to use Devel::Cover?
Hi Chris, I am still confus. For example, On my Linux box, I have a module "/tmp/experiment/lib/module_to_test.pm" to be tested, and I have two Perl unit test scripts "/tmp/experiment/tests/test1.pl" and '"/tmp/experiment/tests/test2.pl" to load the module_to_test.pm module and execute the subroutines in it. Then, what are exact "perl -MDevel::Cover" commands I could use to get the module_to_test.pm module code coverage data from running test1.pl and test2.pl unit test scripts? I am new in Perl, appreciate your detail information. Many thanks in advance, Scott Chris Dolan <[EMAIL PROTECTED]> wrote: On Dec 25, 2005, at 3:46 PM, Scott Wang wrote: > I am new to use Devel::Cover. > > We have lots of product Perl modules in our product "lib" folder > and we have lots of Perl test scripts to cover those modules, right > now, we are trying to get the code coverage metrics for our tests > on those modules. I find we might get help by using Devel::Cover, > would you please give me some idea on how I should use the > Devel::Cover to generate our tests coverage metrics on our Perl > modules? > > Thanks in advance, > > Scott If you use Module::Build, then simply type "./Build testcover" and then open cover_db/coverage.html in your browser. If you are using a version of M::B older than 0.27_02, you may wish to manually delete the whole cover_db directory between runs. Later M::B versions auto- detect when cover_db files are out of date. 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/) - Yahoo! DSL Something to write home about. Just $16.99/mo. or less
Re: Match objects
On Mon, Dec 26, 2005 at 07:34:06PM +, Luke Palmer wrote: > On 12/26/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > > On Fri, Dec 23, 2005 at 02:09:19PM +, Luke Palmer wrote: > > > "x" ~~ / [ [ (x) ]* ]* / > > > > As I understand things, $/[0][0] would be "x". > > Hmm, that seems wrong. Consider: > > "xxxyxxyxy" ~~ / [ [ (x) ]* (y) ]* / > > I argue that by the structure of that rule, you should be able to tell > which xs go with which y. > ... > Is there a counterargument that I'm not seeing? I'd say that if you want a structured rule, it should be written that way, as in ( (x)* y )* or ( (x)* (y) )* Then it's easy to know which xs go with which y. As I play more with rules, it seems that parens are the way to build/preserve structure in captures, while square brackets are the way to flatten or ignore it. Pm
Re: Match objects
On 12/26/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Fri, Dec 23, 2005 at 02:09:19PM +, Luke Palmer wrote: > > "x" ~~ / [ [ (x) ]* ]* / > > As I understand things, $/[0][0] would be "x". Hmm, that seems wrong. Consider: "xxxyxxyxy" ~~ / [ [ (x) ]* (y) ]* / I argue that by the structure of that rule, you should be able to tell which xs go with which y. Currently, the match object comes out: [0] => [ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ], [1] => [ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ] Obscuring that information. Whereas, with "deeper" nesting semantics, you get: [0] => [ [ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ], [ [EMAIL PROTECTED], [EMAIL PROTECTED] ], [ [EMAIL PROTECTED] ] ] [1] => [ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ] Making it easy to tell which xs go with which y ($/[0][1] corresponds to $/[1][1], etc.). Is there a counterargument that I'm not seeing? Luke
Re: Threading PDD?
On Fri, Dec 23, 2005 at 09:33:42PM +0100, Klaas-Jan Stol wrote: > Hi, > > I'm wondering, is there a PDD about Thread implementation in Parrot? I > searched the list archive, and found a lot of info. Dan even mentioned > writing a PDD on the subject, but I havent' been able to find it. This question seems to arise frequently -- perhaps there should be a PDD about thread implementation, even if it only says "we haven't speced this part yet yet", "draft copy welcome", and/or "here are the relevant references"? Just a thought, Pm
Re: How to use Devel::Cover?
Thanks for all your helps. I am new in Perl world, my situation is, for example: - my modules, which I like to test, live in "tmp/experiment/lib" folder - my test scripts, which are created to load and exercise the above modules, live in "tmp/experiment/tests" folder - I call our internal test harness script, which is different from the CPAN test harness, to invoke the above tests in "tmp/experiment/tests" folder one by one to test and cover the modules in "tmp/experiment/lib" folder I installed Devel::Cover module on my Linux box and I used perl -MDevel::Cover tmp/experiment/lib/module_one.pm and I did get coverage data for module_one.pm. But I have questions: (1)My tests test1_module_one and test2_module_one are perl script to load and exercise module_one.pms subroutiones. So, what is the Devel::Cover command to call test scripts test1_module_one and test2_module_one, which load module_one.pm, to get test coverage data for module_one.pm? (2)One step further, as I mentioned, I actually need call our internal test harness script to kick off the two test scripts one by one to cover the modules_one.pm, so the scenario is that, my test harness script calls test scripts, and test scripts load module_one.pm and test it. So, what will be best strategy and commnds for me to use Devel::Cover to achieve the goal => call my test harness script and get the code coverage data on module_one.pm by running the two tests. I am new in Perl and Devel::Cover, so pleaes help and give detail info. Thanks again and looking forward to getting your further advice! Scott James E Keenan <[EMAIL PROTECTED]> wrote: Scott Wang wrote: > Hi , > > I am new to use Devel::Cover. > > We have lots of product Perl modules in our product "lib" folder and we have > lots of Perl test scripts to cover those modules, right now, we are trying to > get the code coverage metrics for our tests on those modules. I find we might > get help by using Devel::Cover, would you please give me some idea on how I > should use the Devel::Cover to generate our tests coverage metrics on our > Perl modules? > Are you asking for assistance in how to get stats for a *single* Perl module? If so, that's easy (and easily learned from the docs): perl Makefile.PL make cover -delete make test HARNESS_PERL_SWITCHES=-MDevel::Cover cover That creates a subdirectory cover_db/which holds the database created by running Devel::Cover, as well as HTML files which vividly display what's covered and what's not by statement, branch, condition, subroutine, etc. When I'm developing a Perl module I sometimes like to save text versions coverage reports in a separate subdirectory. So I'll call: cover cover_db --report=text > coverage.mymodule.myversionnumber.txt If, on the other hand, you're asking how to collate the results of running Devel::Cover on *many* modules, well, that's something I haven't had to do, though others have. Check archives of this list as well as Paul Johnson's home page. jimk - Yahoo! for Good - Make a difference this year.
Re: Match objects
On Fri, Dec 23, 2005 at 02:09:19PM +, Luke Palmer wrote: > What sort of match object should this return, supposing that it didn't > infinite loop: > > "x" ~~ / [ [ (x) ]* ]* / > > Should $/[0][0] be "x", or should $/[0][0][0] be "x"? If it's the > latter, then when do new top-level elements get added? As I understand things, $/[0][0] would be "x". FWIW, PGE currently creates top-level elements as they are encountered in the pattern match. Pm
Re: PGE infinite loop bug
On Fri, Dec 23, 2005 at 12:17:16PM +, Luke Palmer wrote: > The following causes PGE to infinite loop: > > "x" ~~ /[ [ x ]* ]*/ > Thanks -- PGE doesn't yet handle repetitions of zero-length substrings. It's on the TODO list; I worked on it a couple of weeks ago but had to stop to re-think the problem and solution a bit. Pm
