Re: CPANTS quality brainstorming
brian d foy wrote: In article [EMAIL PROTECTED], Thomas Klausner [EMAIL PROTECTED] wrote: I added a few things, most notably the new has_license metric (thanks again to Gabor Szabo for implementing it). (BTW, there was quite a drop in the CPANTS game highscore lists, as lots of dists don't come with a license (9064 to be exact) Well, you should say that those dists don't come with a license that you detected. For instance, all of my modules clearly state in the documentation that they are available under the same terms as Perl itself. They come with a license, even if its not explicity stated in META.yml. Furthermore, everything has a license, even if it is implied. Since everything on CPAN is available for free, no one has to pay any fee or enter into any agreement to use anything on CPAN. If we find a distribution that says otherwise, we (as in the PAUSE admins) remove it from CPAN. How about some other ways to measure this metric? Let's not divide the world into people who use Module::Build and those who don't. Makefile.PL still drives most distributions, and, at least for me, I've never received a complaint that dealt with a Makemaker issue. Agreed, while the META.yml key is the simplest way, it should be possible to locate the most common patterns for licensing, such at the typical COPYRIGHT POD block that often contains ... is licensed ... etc. At the same time, if that POD block mentions a LICENSE file, we should detect that the distribution actually comes with one. Adam K
Re: Comments after ending plan
- Original Message From: Michael G Schwern [EMAIL PROTECTED] Ovid wrote: Which is correct? I'm assuming that comments *are* allowed after the plan? Comments are exempt. Since the parser is not supposed to do anything with junk lines, I assume that junk after the plan is also allowed? For right now, I'll assume it's not and just add support later. ok 1 not ok 2 1..2 # this comment is acceptable ... but what about this? Cheers, Ovid
Re: Comments after ending plan
On Wednesday 13 September 2006 23:35, Ovid wrote: Since the parser is not supposed to do anything with junk lines, I assume that junk after the plan is also allowed? For right now, I'll assume it's not and just add support later. ok 1 not ok 2 1..2 # this comment is acceptable ... but what about this? Shouldn't that last line always be an error wherever it occurs? -- c
Re: Comments after ending plan
- Original Message From: chromatic [EMAIL PROTECTED] ok 1 not ok 2 1..2 # this comment is acceptable ... but what about this? Shouldn't that last line always be an error wherever it occurs? For purposes of forward compatability, it's been my understanding that the consensus is that junk lines are ignored but are not parse errors. This ensures that that if we ever get some strange TAP v2, it won't break a parser for TAP v1. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
New TAP Grammar
As it turns out, adding support to allow comments after a terminating plan was
trivial. However, the grammar was getting a bit old and needed some work. I
noticed, amongst other things, that comments had never been integrated.
If you're not familiar with reading this style of grammar, here are a few
comments:
I'm using POSIX character classes to represent digits and printable characters.
If you want to manually encode all of the Unicode characters for [:print:], be
my guest :)
The following means all printable characters except the newline.
([:print:] - \n)
The following means, a digit followed by zero or more digits.
digit {digit}
A question mark after an atom means it's optional.
I'm not particularly gifted with grammars, so corrections welcome.
The corrected TAP grammar:
digit ::= [:digit:]
character ::= ([:print:] - \n)
positiveInteger::= ( digit - '0' ) {digit}
nonNegativeInteger ::= digit {digit}
tap ::= plan tests | tests plan {comment}
plan::= '1..' nonNegativeInteger \n
lines ::= line {lines}
line::= (comment | test) \n
tests ::= test {test}
test::= status positiveInteger? description? directive?
status ::= 'not '? 'ok '
description ::= (character - (digit '#')) {character - '#'}
directive ::= '#' ( 'TODO' | 'SKIP' ) ' ' {character}
comment ::= '#' {character}
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: CPANTS quality brainstorming
Adam Kennedy wrote: Agreed, while the META.yml key is the simplest way, it should be possible to locate the most common patterns for licensing, such at the typical COPYRIGHT POD block that often contains ... is licensed ... etc. Or licenced. Please remember to take account of such a common mis-spelling. -- David Cantrell
Re: CPANTS quality brainstorming
David Cantrell wrote: Adam Kennedy wrote: Agreed, while the META.yml key is the simplest way, it should be possible to locate the most common patterns for licensing, such at the typical COPYRIGHT POD block that often contains ... is licensed ... etc. Or licenced. Please remember to take account of such a common mis-spelling. And yeah, the usual caveats about spelling etc apply as usual :) Adam K
Re: post-YAPC::Europe CPANTS news
Le mardi 12 septembre 2006 à 11:15, Chris Dolan écrivait: On Sep 12, 2006, at 9:24 AM, Salve J Nilsen wrote: Any metric that catches bad things, particularly bad technical things, is going to be just fine. Metrics that try to push good behavior are fraught with trouble, because they start pushing people in odd directions. Do you have an example on this? (Any pointer would be wonderful.) I have two: pod.t and pod_coverage.t. These are pointless to run on an end-user's machine. At best they are redundant to immutable tests already run on the author's machine and just waste processor cycles. At worst they fail and cause false negative test reports. The prevalence of those two tests in CPAN modules is almost entirely due to the influence of CPANTS. At least has_test_pod can be rewritten as no_pod_errors and achieve the same goal (check that the documentation is syntactically correct pod-wise). Since running Test::Pod on all .pm and .pod file doesn't require actually running the code itself, it sound perfectly acceptable for both parties (those who want to check that the pod is correct and those that think that multiple copies of t/pod.t shouldn't clutter CPAN). ... I just had myself motivated enough to write such a metric, when I discovered that Module::CPANTS::Analyse already has a no_pod_errors metric! That makes me wonder about the utility of has_test_pod, since no_pod_errors is even more interesting: we want to give points to people that *have* a correctly written pod, rather than to those who merely try, don't we? -- Philippe BooK Bruhat What everyone wants, nobody gets, What nobody gets, everybody wants. (Moral from Groo The Wanderer #47 (Epic))
TidyView - preview your perltidy options
Hi all, I have release a pet project on Sourceforge called TidyView, at https://sourceforge.net/projects/tidyview/ https://sourceforge.net/projects/tidyview/ Basically it is a Tk GUI to help preview the effect of the plethora of options provided by Perltidy. If you dont know what Perltidy is, its a pretty-printer for Perl-code. You can use it to have all your code consistently indented and spaced, automagically. Perltidy is recommended by TheDamian at page 34 of PBP, and he provides a sample perltidy config file. But if you wish to tweak this, it is easy to get lost in the hundreds of option choices available. You can preview the effect of your selected options on your code, and if you like them, have a nicely formatted perltidyrc file saved for you. It can also parse and present your exisiting perltidyrc files, and allow you to make incremental adjustments to tighten up your desired autoamtic code formatting Obviously it requires Tk and Perltidy, both available from CPAN. It supports some pretty old Tk versions, but requires a very recent Perltidy. Additionally, whilst this is in the early release phase, version and Log::Log4perl are required. I have been working with the author of Perltidy over the past few months, and he has been using TidyView to debug and improve Perltidy itself, which is just super. So if you wish to have a consistent code style for all your (and your dev teams) Perl-code, till you get it looking just right. Its licensed under the same terms as Perl itself, and I am very, VERY eager to receive feedback, complaints, abuse, suggestions and patches. There are a list of things I'd like to add in the TODO file, colourised diff's between what you code originally looked like and how Perltidy formatted it would be a great addition, but I haven't a clue how to do it. Note, there are some people who have expressed the concern that Perltidy can inadvertently change the parse tree of the code it reformats - that is, change the meaning of your code. However, the developer of Perltidy says no one has every reported that to him in the many years he's been developing Perltidy, though he's sure someone (TheDamian would have to be at the top of that list) could write something sufficiently freaky to do that - but they havent yet. But if there is enough demand for it, I can add in support for PPI::Signature to make sure that doesnt ever happen without TidyView noticing. I haven't done it yet as at the moment it solves a problem that doesn't exist, and it introduces another dependency. Patches to flexibly support PPI::Signature are welcome. The purpose of announcing this on PerlQA is that coding standards are often lumped into the 'QA'-bucket, so the QA mail-list seems most appropriate. I hope to announce this more widely (perl monks, CPAN maybe) in a few weeks. Thanx for your time, Leif Eriksen -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.3/447 - Release Date: 13/09/2006 ** IMPORTANT The contents of this e-mail and its attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you received this e-mail in error, please notify the HPA Postmaster, [EMAIL PROTECTED], then delete the e-mail. This footnote also confirms that this e-mail message has been swept for the presence of computer viruses by Ironport. Before opening or using any attachments, check them for viruses and defects. Our liability is limited to resupplying any affected attachments. HPA collects personal information to provide and market our services. For more information about use, disclosure and access see our Privacy Policy at www.hpa.com.au **
Updated Tidyvew URL
Of course it had to be wrong didnt it - http://sourceforge.net/projects/tidyview/ http://sourceforge.net/projects/tidyview/ if the https isnt working for you. Leif Eriksen -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.3/447 - Release Date: 13/09/2006 ** IMPORTANT The contents of this e-mail and its attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you received this e-mail in error, please notify the HPA Postmaster, [EMAIL PROTECTED], then delete the e-mail. This footnote also confirms that this e-mail message has been swept for the presence of computer viruses by Ironport. Before opening or using any attachments, check them for viruses and defects. Our liability is limited to resupplying any affected attachments. HPA collects personal information to provide and market our services. For more information about use, disclosure and access see our Privacy Policy at www.hpa.com.au **
Re: TidyView - preview your perltidy options
Please excuse the stupid question, but is there any chance this could use Wx instead of Tk, since Wx installs from CPAN cleanly everywhere now (I think) and Tk doesn't seem to install properly. But then I imagine moving to Wx would mean a HUGE amount of code to change... Adam K [EMAIL PROTECTED] wrote: Hi all, I have release a pet project on Sourceforge called TidyView, at https://sourceforge.net/projects/tidyview/ https://sourceforge.net/projects/tidyview/ Basically it is a Tk GUI to help preview the effect of the plethora of options provided by Perltidy. If you dont know what Perltidy is, its a pretty-printer for Perl-code. You can use it to have all your code consistently indented and spaced, automagically. Perltidy is recommended by TheDamian at page 34 of PBP, and he provides a sample perltidy config file. But if you wish to tweak this, it is easy to get lost in the hundreds of option choices available. You can preview the effect of your selected options on your code, and if you like them, have a nicely formatted perltidyrc file saved for you. It can also parse and present your exisiting perltidyrc files, and allow you to make incremental adjustments to tighten up your desired autoamtic code formatting Obviously it requires Tk and Perltidy, both available from CPAN. It supports some pretty old Tk versions, but requires a very recent Perltidy. Additionally, whilst this is in the early release phase, version and Log::Log4perl are required. I have been working with the author of Perltidy over the past few months, and he has been using TidyView to debug and improve Perltidy itself, which is just super. So if you wish to have a consistent code style for all your (and your dev teams) Perl-code, till you get it looking just right. Its licensed under the same terms as Perl itself, and I am very, VERY eager to receive feedback, complaints, abuse, suggestions and patches. There are a list of things I'd like to add in the TODO file, colourised diff's between what you code originally looked like and how Perltidy formatted it would be a great addition, but I haven't a clue how to do it. Note, there are some people who have expressed the concern that Perltidy can inadvertently change the parse tree of the code it reformats - that is, change the meaning of your code. However, the developer of Perltidy says no one has every reported that to him in the many years he's been developing Perltidy, though he's sure someone (TheDamian would have to be at the top of that list) could write something sufficiently freaky to do that - but they havent yet. But if there is enough demand for it, I can add in support for PPI::Signature to make sure that doesnt ever happen without TidyView noticing. I haven't done it yet as at the moment it solves a problem that doesn't exist, and it introduces another dependency. Patches to flexibly support PPI::Signature are welcome. The purpose of announcing this on PerlQA is that coding standards are often lumped into the 'QA'-bucket, so the QA mail-list seems most appropriate. I hope to announce this more widely (perl monks, CPAN maybe) in a few weeks. Thanx for your time, Leif Eriksen -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.3/447 - Release Date: 13/09/2006 ** IMPORTANT The contents of this e-mail and its attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you received this e-mail in error, please notify the HPA Postmaster, [EMAIL PROTECTED], then delete the e-mail. This footnote also confirms that this e-mail message has been swept for the presence of computer viruses by Ironport. Before opening or using any attachments, check them for viruses and defects. Our liability is limited to resupplying any affected attachments. HPA collects personal information to provide and market our services. For more information about use, disclosure and access see our Privacy Policy at www.hpa.com.au **
Re: TidyView - preview your perltidy options
And the second obvious question, while I'm thinking about it... When will we be able to install this from CPAN? :) Adam K [EMAIL PROTECTED] wrote: Hi all, I have release a pet project on Sourceforge called TidyView, at https://sourceforge.net/projects/tidyview/ https://sourceforge.net/projects/tidyview/ Basically it is a Tk GUI to help preview the effect of the plethora of options provided by Perltidy. If you dont know what Perltidy is, its a pretty-printer for Perl-code. You can use it to have all your code consistently indented and spaced, automagically. Perltidy is recommended by TheDamian at page 34 of PBP, and he provides a sample perltidy config file. But if you wish to tweak this, it is easy to get lost in the hundreds of option choices available. You can preview the effect of your selected options on your code, and if you like them, have a nicely formatted perltidyrc file saved for you. It can also parse and present your exisiting perltidyrc files, and allow you to make incremental adjustments to tighten up your desired autoamtic code formatting Obviously it requires Tk and Perltidy, both available from CPAN. It supports some pretty old Tk versions, but requires a very recent Perltidy. Additionally, whilst this is in the early release phase, version and Log::Log4perl are required. I have been working with the author of Perltidy over the past few months, and he has been using TidyView to debug and improve Perltidy itself, which is just super. So if you wish to have a consistent code style for all your (and your dev teams) Perl-code, till you get it looking just right. Its licensed under the same terms as Perl itself, and I am very, VERY eager to receive feedback, complaints, abuse, suggestions and patches. There are a list of things I'd like to add in the TODO file, colourised diff's between what you code originally looked like and how Perltidy formatted it would be a great addition, but I haven't a clue how to do it. Note, there are some people who have expressed the concern that Perltidy can inadvertently change the parse tree of the code it reformats - that is, change the meaning of your code. However, the developer of Perltidy says no one has every reported that to him in the many years he's been developing Perltidy, though he's sure someone (TheDamian would have to be at the top of that list) could write something sufficiently freaky to do that - but they havent yet. But if there is enough demand for it, I can add in support for PPI::Signature to make sure that doesnt ever happen without TidyView noticing. I haven't done it yet as at the moment it solves a problem that doesn't exist, and it introduces another dependency. Patches to flexibly support PPI::Signature are welcome. The purpose of announcing this on PerlQA is that coding standards are often lumped into the 'QA'-bucket, so the QA mail-list seems most appropriate. I hope to announce this more widely (perl monks, CPAN maybe) in a few weeks. Thanx for your time, Leif Eriksen -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.3/447 - Release Date: 13/09/2006 ** IMPORTANT The contents of this e-mail and its attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you received this e-mail in error, please notify the HPA Postmaster, [EMAIL PROTECTED], then delete the e-mail. This footnote also confirms that this e-mail message has been swept for the presence of computer viruses by Ironport. Before opening or using any attachments, check them for viruses and defects. Our liability is limited to resupplying any affected attachments. HPA collects personal information to provide and market our services. For more information about use, disclosure and access see our Privacy Policy at www.hpa.com.au **
Re: TidyView - preview your perltidy options
- Original Message From: Adam Kennedy [EMAIL PROTECTED] Please excuse the stupid question, but is there any chance this could use Wx instead of Tk, since Wx installs from CPAN cleanly everywhere now (I think) and Tk doesn't seem to install properly. I finally gave up trying to install Wx on my iBook. Tk went in without a hitch. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: CPANTS quality brainstorming
On Sep 14, 2006, at 4:36 AM, David Cantrell wrote: Adam Kennedy wrote: Agreed, while the META.yml key is the simplest way, it should be possible to locate the most common patterns for licensing, such at the typical COPYRIGHT POD block that often contains ... is licensed ... etc. Or licenced. Please remember to take account of such a common mis- spelling. Again, I plug: My Module::License::Report package looks for spelling errors like that. It does a weighted estimation of the license: meta.yml counts most, then DSLIP, then .pm POD, then .pod POD, and finally miscellaneous files like README, Build.PL, Makefile.PL. Here's an example run: % bin/license-report -a DateTime Can't find a license for Class::Singleton perl DateTime perl DateTime-Locale perl DateTime-TimeZone perl Params-Validate Of those five, DateTime-Locale and DateTime-TimeZone have META.yml license info and the others do not. Class::Singleton confuses my module by having an unusually stated license for Artistic only: COPYRIGHT Copyright (C) 1998 Canon Research Centre Europe Ltd. All Rights Reserved. This module is free software; you can redistribute it and/or modify it under the term of the Perl Artistic License. === I'm plugging module this because I think it's an important tool that needs some improvement. Before this post did any of you know that the popular DateTime module had a non-Perl-licensed dependency? I didn't. https://svn.clotho.com/clotho/Module-License-Report/ Improvements needed: * Check if it works with a local CPAN mirrror * Reduce reliance on CPANPLUS? * Better license heuristics (like detecting Artistic in the above example) * Test against more of CPAN * Better Build.PL/Makefile.PL parsing - PPI - Module::MakefilePL::Parse (but that uses eval) - fancier regexps - http://www.nntp.perl.org/group/perl.makemaker/ 2523 * Better user control over weighting (like, a --yml flag to only look at META.yml) * Think harder about weighting: - Certainty of heuristic should matter (META.yml is certain, regexps on POD prose is uncertain) - Partial success should matter (found a POD COPYRIGHT section, but couldn't parse it) - Locality to code should matter (POD more significant than DSLIP) and finally: * Advocacy to get popular modules to state their licenses more prominently * Advocacy to get modules with inconsistently stated licenses (e.g. DSLIP vs. POD) corrected Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: TidyView - preview your perltidy options
From: [EMAIL PROTECTED] colourised diff's between what you code originally looked like and how Perltidy formatted it would be a great addition, but I haven't a clue how to do it. Use Algorithm::Diff::sdiff() to calculate the differences, then parse the output to convert it into tagged text when adding it to the Tk::Text widgets. Coding this is simple. Determining what constitutes a difference and how it should be displayed is the hard part. -mjc
Re: TidyView - preview your perltidy options
Michael Carman wrote: From: [EMAIL PROTECTED] colourised diff's between what you code originally looked like and how Perltidy formatted it would be a great addition, but I haven't a clue how to do it. Use Algorithm::Diff::sdiff() to calculate the differences, then parse the output to convert it into tagged text when adding it to the Tk::Text widgets. Coding this is simple. Determining what constitutes a difference and how it should be displayed is the hard part. I'd look at meld (http://meld.sourceforge.net/). Maybe some ideas or code could be borrowed. -- Michael Peters Developer Plus Three, LP
Re: CPANTS quality brainstorming
On 9/14/06, Chris Dolan [EMAIL PROTECTED] wrote: * Advocacy to get popular modules to state their licenses more prominently * Advocacy to get modules with inconsistently stated licenses (e.g. DSLIP vs. POD) corrected I think if we can include it in the CPANTS tests so there might be several metrics: has_license_in_yaml has_license_in_source (though I am not sure if that should mean the main .pm file only or all the files or what) licenses_are_consistent that would make a nice step in advocating putting licenses on modules. Gabor
Re: Installing Tests
Adam Kennedy wrote: Hmm, that would waste a lot of disk. Maybe we could cache the tarballs somewhere. Maybe on the network or even Amazon S3. Some sort of big repository of modules. We can call it the Network of Archived Postinstall Crap, NAPC for short! This same argument applies to the tests. Sure does. :) Further, you've missed the main point here, which is that I'm suggesting saving the post-make state of the tarballs with all build assumptions and such in place, not the pristine just-unrolled version. We're already wasting disk saving the tests, why not waste a bit more and make sure we actually save enough to know the tests will work for sure. I just thought of something. The point is to test that what's *installed* is working, right? But you're talking about testing at the point of installation. This is different from what's actually installed. Consider some common ways the code you're running can fall out of sync with what was installed. * Admin A installs and archives the source properly. Admin B installs by hand and doesn't update the archive. Or the package manager installs a different version. Or any number of module shadowing and overlay scenarios like the above. * The installed module is edited in place. Either in an attempt to fix a bug, add a feature or alter a Config.pm. * Disk corruption. * The CPAN shell's recompile command is run (such as after an architecture change like when going from a PowerPC to Intel Mac like I just did). Testing the post-make source doesn't do anything for the above scenarios, and the first two are rather common. It gives you a false sense of security. To be useful and accurate you have to test against the actual code which is installed. Not what you think is installed.
Re: post-YAPC::Europe CPANTS news
Adam Kennedy wrote: I'm find with adding an additional environment variable though for the packaging state. But please lets not decide on anything right now, AUTOMATED_TESTING is already a sub-optimal name, I'd rather make sure that the EU::MM, M:B and M:I modules all agreed on a single consistent name before we go and add support for it. Whatever it is, prefix it with PERL_ to avoid conflicts.
Re: Comments after ending plan
Ovid wrote: - Original Message From: chromatic [EMAIL PROTECTED] ok 1 not ok 2 1..2 # this comment is acceptable ... but what about this? Shouldn't that last line always be an error wherever it occurs? For purposes of forward compatability, it's been my understanding that the consensus is that junk lines are ignored but are not parse errors. This ensures that that if we ever get some strange TAP v2, it won't break a parser for TAP v1. Yes, that's it. If someone wants to make a stricter interpretation they can always do it on top of the parser. And yes, unparsable crap at the end doesn't count.
Re: New TAP Grammar
Ovid wrote:
The corrected TAP grammar:
digit ::= [:digit:]
character ::= ([:print:] - \n)
positiveInteger::= ( digit - '0' ) {digit}
nonNegativeInteger ::= digit {digit}
tap ::= plan tests | tests plan {comment}
plan::= '1..' nonNegativeInteger \n
lines ::= line {lines}
line::= (comment | test) \n
tests ::= test {test}
test::= status positiveInteger? description? directive?
status ::= 'not '? 'ok '
description ::= (character - (digit '#')) {character - '#'}
directive ::= '#' ( 'TODO' | 'SKIP' ) ' ' {character}
TODO and SKIP are case insensitive
comment ::= '#' {character}
I don't see the skip all syntax in there:
# Skip all tests with no reason
1..0
# Skip all tests with a reason
1..0 # skip: reason
You might find it handy to pull all the sample test files from the
Test::Harness tests and use them to test TAPx::Parser.
http://svn.perl.org/modules/Test-Harness/trunk/t/sample-tests/
The proper behaviors can be gleaned from t/strap-analyze.t
Re: Installing Tests
Adam Kennedy wrote: I'm not suggesting we test against the post-make code, but if we keep everything, we can be fairly certain we still have any data files or other things that are needed to support the testing. Now we rerun the test suite, but without including blib. And you get a full test run against the currently installed code, but with any data files or other stuff the tests need available. How are you going to exclude blib? Since the point of hanging onto the source tree is to account for customized installers, they will have customized test harnesses.
Re: New TAP Grammar
On 9/14/06, Ovid [EMAIL PROTECTED] wrote:
I'm not particularly gifted with grammars, so corrections welcome.
The corrected TAP grammar:
digit ::= [:digit:]
character ::= ([:print:] - \n)
positiveInteger::= ( digit - '0' ) {digit}
nonNegativeInteger ::= digit {digit}
tap ::= plan tests | tests plan {comment}
plan::= '1..' nonNegativeInteger \n
lines ::= line {lines}
line::= (comment | test) \n
tests ::= test {test}
test::= status positiveInteger? description? directive?
status ::= 'not '? 'ok '
description ::= (character - (digit '#')) {character - '#'}
directive ::= '#' ( 'TODO' | 'SKIP' ) ' ' {character}
comment ::= '#' {character}
i translated this grammar to a perl 6 grammar. i know it has some bugs
in it (probably 'rule' vs. 'token' among others) but it's a good
start. from translating it, there are a few things that stick out.
first, the grammar:
grammar TAP;
token digit { \d }
token character { +print-[\n] }
token positiveInteger{ +digit-[0] digit* }
token nonNegativeInteger { digit+ }
rule tap { [ plan tests | tests plan comment? ] }
rule plan{ '1..' nonNegativeInteger \n }
rule lines { line+ }
rule line{ [ comment | test ] \n }
rule tests { test+ }
rule test{ status positiveInteger? description? directive? }
rule status { [ not \s ]? ok }
rule description { -[#]-digit -[#]* }
rule directive { '#' [ :ignorecase todo | skip ] character* }
rule comment { '#' character* }
~ i thought descriptions started with a hyphen C-, not an octothorpe C#.
~ doesn't directive belong before description ??
C# SKIP comment rather than C- comment #SKIP
~ schwern already mentioned 'skip_all'
~ missing 'Bail out!'
in any case, it looks pretty good, and i'll try to keep my parrot TAP
parser grammar in line with the TAPx::Parser grammar as it develops.
~jerry
btw, i love writing grammars in perl6. what kind of a geek does that
make me? eh, who cares. grammars rock!
Re: TidyView - preview your perltidy options
Ovid wrote: - Original Message From: Adam Kennedy [EMAIL PROTECTED] Please excuse the stupid question, but is there any chance this could use Wx instead of Tk, since Wx installs from CPAN cleanly everywhere now (I think) and Tk doesn't seem to install properly. I finally gave up trying to install Wx on my iBook. Tk went in without a hitch. I allowed Alien::wxWidgets to build wxwidgets. Then Wx installed with one hitch. When installing Wx make sure you don't have INC set or it will not see the Alien installed wxwidgets when it tries to compile Wx.c at the end. http://rt.cpan.org/Ticket/Display.html?id=21492
Re: TidyView - preview your perltidy options
I see the opposite. Alien::wxWidgets has gotten better and worse with each version, but gradually trending towards better. Tk, well there's a lot of scary errors there. I'd try Wx again every couple of Alien:: releases, and see how it goes if you let it build Wx itself. Adam K Ovid wrote: - Original Message From: Adam Kennedy [EMAIL PROTECTED] Please excuse the stupid question, but is there any chance this could use Wx instead of Tk, since Wx installs from CPAN cleanly everywhere now (I think) and Tk doesn't seem to install properly. I finally gave up trying to install Wx on my iBook. Tk went in without a hitch. Cheers, Ovid
Re: New TAP Grammar
- Original Message From: Michael G Schwern You might find it handy to pull all the sample test files from the Test::Harness tests and use them to test TAPx::Parser. http://svn.perl.org/modules/Test-Harness/trunk/t/sample-tests/ What a pain in the @$$. I'm up to 613 new tests from that. So far I've not uncovered any bugs, but I need to add support for comments and junk before the plan. The proper behaviors can be gleaned from t/strap-analyze.t What's 'bonus'? I haven't figured that out yet. Also, I never tracked the exit status of the tests. Frankly, I never used that number myself. Does anyone? If so, can anyone provide a use case? Cheers, Ovid
Re: New TAP Grammar
On Thursday 14 September 2006 13:14, Ovid wrote: What's 'bonus'? I haven't figured that out yet. That should be the number of successful TODO tests. If it's not, I have no idea. Also, I never tracked the exit status of the tests. Frankly, I never used that number myself. Does anyone? If so, can anyone provide a use case? Originally that was to indicate the number of failing tests, but using an unsigned eight-bit integer really limites the applicability. You should be able to ignore it. -- c
Too many tests
Here's we have a test where the plan is 1..3 but we've run 7 tests. TAPx-Parser $ prove -v t/sample-tests/too_many t/sample-tests/too_many...1..3 ok 1 ok 2 ok 3 ok 4 ok 5 ok 6 ok 7 dubious Test returned status 4 (wstat 1024, 0x400) DIED. FAILED tests 4-7 Failed 4/3 tests, -33.33% okay Failed Test Stat Wstat Total Fail List of Failed --- t/sample-tests/too_many4 1024 34 4-7 Failed 1/1 test scripts. -4/3 subtests failed. Files=1, Tests=3, 0 wallclock secs ( 0.01 cusr + 0.01 csys = 0.02 CPU) Failed 1/1 test programs. -4/3 subtests failed. The last three tests have passed, but Test::Harness says they've failed. My TAPx::Parser reports that they've passed and the only real way to know if there's a problem is to test the $parser-good_plan method. I've added this as a parse error, but why are the passing tests listed as failing? Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: New TAP Grammar
- Original Message From: jerry gay [EMAIL PROTECTED] thanks for the responses. i've done a second take on the TAP grammar in perl6 format, with the help of patrick michaud. i'm pretty sure it's correct now, at least as per your previous grammar. have a look: I'll update my grammar as I can and I'll send it along and I'll try to incorporate your work. It's great to see a Perl6 version. Do Perl6 grammars support semantics along with syntax? Each test number should actually be one greater than the previous test number, but a traditional EBNF can't support that. ~ there are some places i took liberties (eg. \d versus [:digit:], \N verses [:print:] (are comments, directives, and description really limited to printable characters?).) Hmm, never thought about that. I don't think there's anything really wrong with non-printable characters (are null bytes a problem?), but I'm not sure how to represent that. as an aside, patrick asked why C1..0 was valid. i explained Cno_plan, and he asked why it wasn't C1.. or the more perl6ish C1..*. i know TAP isn't perl-only, but i have to say, C1..* is really growing on me... 'one to whatever.' it looks and sounds better than 'one to zero.' anyone else have thoughts on that? '1..0' actually means 'skip all'. '1..' or '1..*' would be useful for indicating an infinite stream. 'no_plan' TAP has the plan at the end. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
RE: TidyView - preview your perltidy options
Well, I'm hoping for feedback from this maillist, and when that settles down, I'm debating whether to send it to CPAN ten announce on perlmonks et al, or to announce on perl monks whilst still on sourceforge, and after feedback from perl monks, post it to CPAN -I already have a PAUSE id etc. So I'm going for a little more feedback and stability before posting a release to CPAN - maybe I'm being too precious, I don’t know. Leif -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, 14 September 2006 10:45 PM To: Leif Eriksen Cc: perl-qa@perl.org Subject: Re: TidyView - preview your perltidy options And the second obvious question, while I'm thinking about it... When will we be able to install this from CPAN? :) Adam K [EMAIL PROTECTED] wrote: Hi all, I have release a pet project on Sourceforge called TidyView, at https://sourceforge.net/projects/tidyview/ https://sourceforge.net/projects/tidyview/ Basically it is a Tk GUI to help preview the effect of the plethora of options provided by Perltidy. If you dont know what Perltidy is, its a pretty-printer for Perl-code. You can use it to have all your code consistently indented and spaced, automagically. Perltidy is recommended by TheDamian at page 34 of PBP, and he provides a sample perltidy config file. But if you wish to tweak this, it is easy to get lost in the hundreds of option choices available. You can preview the effect of your selected options on your code, and if you like them, have a nicely formatted perltidyrc file saved for you. It can also parse and present your exisiting perltidyrc files, and allow you to make incremental adjustments to tighten up your desired autoamtic code formatting Obviously it requires Tk and Perltidy, both available from CPAN. It supports some pretty old Tk versions, but requires a very recent Perltidy. Additionally, whilst this is in the early release phase, version and Log::Log4perl are required. I have been working with the author of Perltidy over the past few months, and he has been using TidyView to debug and improve Perltidy itself, which is just super. So if you wish to have a consistent code style for all your (and your dev teams) Perl-code, till you get it looking just right. Its licensed under the same terms as Perl itself, and I am very, VERY eager to receive feedback, complaints, abuse, suggestions and patches. There are a list of things I'd like to add in the TODO file, colourised diff's between what you code originally looked like and how Perltidy formatted it would be a great addition, but I haven't a clue how to do it. Note, there are some people who have expressed the concern that Perltidy can inadvertently change the parse tree of the code it reformats - that is, change the meaning of your code. However, the developer of Perltidy says no one has every reported that to him in the many years he's been developing Perltidy, though he's sure someone (TheDamian would have to be at the top of that list) could write something sufficiently freaky to do that - but they havent yet. But if there is enough demand for it, I can add in support for PPI::Signature to make sure that doesnt ever happen without TidyView noticing. I haven't done it yet as at the moment it solves a problem that doesn't exist, and it introduces another dependency. Patches to flexibly support PPI::Signature are welcome. The purpose of announcing this on PerlQA is that coding standards are often lumped into the 'QA'-bucket, so the QA mail-list seems most appropriate. I hope to announce this more widely (perl monks, CPAN maybe) in a few weeks. Thanx for your time, Leif Eriksen -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.3/447 - Release Date: 13/09/2006 ** IMPORTANT The contents of this e-mail and its attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you received this e-mail in error, please notify the HPA Postmaster, [EMAIL PROTECTED], then delete the e-mail. This footnote also confirms that this e-mail message has been swept for the presence of computer viruses by Ironport. Before opening or using any attachments, check them for viruses and defects. Our liability is limited to resupplying any affected attachments. HPA collects personal information to provide and market our services. For more information about use, disclosure and access see our Privacy Policy at www.hpa.com.au ** -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.3/447 - Release Date: 13/09/2006
RE: TidyView - preview your perltidy options
Not a huge effort - I tried to separate the code into two main areas - dealing with Perltidy and dealing with Tk - so theoretically, it would just require poking the Tk side. That said, I've never played with Wx so the most work is in learning the Wx API. The lib/ dir is split into the two areas - lib/TidyView and lib/PerlTidy, and almost all the Tk code is in lib/TidyView. There is some in the main .pl file, setting up frames for TidyView things to go in. I've also used only standard Tk widgets, and the only non-standard Tk code is to use a single scrollbar to control two scrolled text panes - so I'd have to also work out how to do that too. Plus add some code to detect if a user had Tk or Wx installed - and we're done!! Simple!! Gimme a few weeks. L -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, 14 September 2006 10:43 PM To: Leif Eriksen Cc: perl-qa@perl.org Subject: Re: TidyView - preview your perltidy options Please excuse the stupid question, but is there any chance this could use Wx instead of Tk, since Wx installs from CPAN cleanly everywhere now (I think) and Tk doesn't seem to install properly. But then I imagine moving to Wx would mean a HUGE amount of code to change... Adam K [EMAIL PROTECTED] wrote: Hi all, I have release a pet project on Sourceforge called TidyView, at https://sourceforge.net/projects/tidyview/ https://sourceforge.net/projects/tidyview/ Basically it is a Tk GUI to help preview the effect of the plethora of options provided by Perltidy. If you dont know what Perltidy is, its a pretty-printer for Perl-code. You can use it to have all your code consistently indented and spaced, automagically. Perltidy is recommended by TheDamian at page 34 of PBP, and he provides a sample perltidy config file. But if you wish to tweak this, it is easy to get lost in the hundreds of option choices available. You can preview the effect of your selected options on your code, and if you like them, have a nicely formatted perltidyrc file saved for you. It can also parse and present your exisiting perltidyrc files, and allow you to make incremental adjustments to tighten up your desired autoamtic code formatting Obviously it requires Tk and Perltidy, both available from CPAN. It supports some pretty old Tk versions, but requires a very recent Perltidy. Additionally, whilst this is in the early release phase, version and Log::Log4perl are required. I have been working with the author of Perltidy over the past few months, and he has been using TidyView to debug and improve Perltidy itself, which is just super. So if you wish to have a consistent code style for all your (and your dev teams) Perl-code, till you get it looking just right. Its licensed under the same terms as Perl itself, and I am very, VERY eager to receive feedback, complaints, abuse, suggestions and patches. There are a list of things I'd like to add in the TODO file, colourised diff's between what you code originally looked like and how Perltidy formatted it would be a great addition, but I haven't a clue how to do it. Note, there are some people who have expressed the concern that Perltidy can inadvertently change the parse tree of the code it reformats - that is, change the meaning of your code. However, the developer of Perltidy says no one has every reported that to him in the many years he's been developing Perltidy, though he's sure someone (TheDamian would have to be at the top of that list) could write something sufficiently freaky to do that - but they havent yet. But if there is enough demand for it, I can add in support for PPI::Signature to make sure that doesnt ever happen without TidyView noticing. I haven't done it yet as at the moment it solves a problem that doesn't exist, and it introduces another dependency. Patches to flexibly support PPI::Signature are welcome. The purpose of announcing this on PerlQA is that coding standards are often lumped into the 'QA'-bucket, so the QA mail-list seems most appropriate. I hope to announce this more widely (perl monks, CPAN maybe) in a few weeks. Thanx for your time, Leif Eriksen -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.12.3/447 - Release Date: 13/09/2006 ** IMPORTANT The contents of this e-mail and its attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you received this e-mail in error, please notify the HPA Postmaster, [EMAIL PROTECTED], then delete the e-mail. This footnote also confirms that this e-mail message has been swept for the presence of computer viruses by Ironport. Before opening or using any attachments,
Re: TidyView - preview your perltidy options
On 9/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Well, I'm hoping for feedback from this maillist, and when that settles down, I'm debating whether to send it to CPAN ten announce on perlmonks et al, or to announce on perl monks whilst still on sourceforge, and after feedback from perl monks, post it to CPAN -I already have a PAUSE id etc. So I'm going for a little more feedback and stability before posting a release to CPAN - maybe I'm being too precious, I don't know. Leif -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, 14 September 2006 10:45 PM To: Leif Eriksen Cc: perl-qa@perl.org Subject: Re: TidyView - preview your perltidy options And the second obvious question, while I'm thinking about it... When will we be able to install this from CPAN? :) Adam K [EMAIL PROTECTED] wrote: Hi all, I have release a pet project on Sourceforge called TidyView, at https://sourceforge.net/projects/tidyview/ https://sourceforge.net/projects/tidyview/ Basically it is a Tk GUI to help preview the effect of the plethora of options provided by Perltidy. If you dont know what Perltidy is, its a pretty-printer for Perl-code. You can use it to have all your code consistently indented and spaced, automagically. Perltidy is recommended by TheDamian at page 34 of PBP, and he provides a sample perltidy config file. But if you wish to tweak this, it is easy to get lost in the hundreds of option choices available. You can preview the effect of your selected options on your code, and if you like them, have a nicely formatted perltidyrc file saved for you. It can also parse and present your exisiting perltidyrc files, and allow you to make incremental adjustments to tighten up your desired autoamtic code formatting Obviously it requires Tk and Perltidy, both available from CPAN. It supports some pretty old Tk versions, but requires a very recent Perltidy. Additionally, whilst this is in the early release phase, version and Log::Log4perl are required. I have been working with the author of Perltidy over the past few months, and he has been using TidyView to debug and improve Perltidy itself, which is just super. So if you wish to have a consistent code style for all your (and your dev teams) Perl-code, till you get it looking just right. Its licensed under the same terms as Perl itself, and I am very, VERY eager to receive feedback, complaints, abuse, suggestions and patches. There are a list of things I'd like to add in the TODO file, colourised diff's between what you code originally looked like and how Perltidy formatted it would be a great addition, but I haven't a clue how to do it. Note, there are some people who have expressed the concern that Perltidy can inadvertently change the parse tree of the code it reformats - that is, change the meaning of your code. However, the developer of Perltidy says no one has every reported that to him in the many years he's been developing Perltidy, though he's sure someone (TheDamian would have to be at the top of that list) could write something sufficiently freaky to do that - but they havent yet. But if there is enough demand for it, I can add in support for PPI::Signature to make sure that doesnt ever happen without TidyView noticing. I haven't done it yet as at the moment it solves a problem that doesn't exist, and it introduces another dependency. Patches to flexibly support PPI::Signature are welcome. The purpose of announcing this on PerlQA is that coding standards are often lumped into the 'QA'-bucket, so the QA mail-list seems most appropriate. I hope to announce this more widely (perl monks, CPAN maybe) in a few weeks. Uploading to CPAN and voting in a pseudo democratic state have much in common. Release early, release often. Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: Too many tests
On 9/14/06, Ovid [EMAIL PROTECTED] wrote: Here's we have a test where the plan is 1..3 but we've run 7 tests. TAPx-Parser $ prove -v t/sample-tests/too_many t/sample-tests/too_many...1..3 ok 1 ok 2 ok 3 ok 4 ok 5 ok 6 ok 7 dubious Test returned status 4 (wstat 1024, 0x400) DIED. FAILED tests 4-7 Failed 4/3 tests, -33.33% okay Failed Test Stat Wstat Total Fail List of Failed --- t/sample-tests/too_many4 1024 34 4-7 Failed 1/1 test scripts. -4/3 subtests failed. Files=1, Tests=3, 0 wallclock secs ( 0.01 cusr + 0.01 csys = 0.02 CPU) Failed 1/1 test programs. -4/3 subtests failed. The last three tests have passed, but Test::Harness says they've failed. My TAPx::Parser reports that they've passed and the only real way to know if there's a problem is to test the $parser-good_plan method. I've added this as a parse error, but why are the passing tests listed as failing? Well, I dont know that I can say it authoritatively, but treating a passing test you have specifically said wasnt going to occur as a fail seems to reasonable behaviour to me. How else are you going to deal with you've run more tests than you said you were? If you accept the results and assume the count is wrong how do you know what the program didn't silently die part way through and in fact you are dealing with a catastrophic failure in the middle of more tests than were run? But a nice message like you ran 128 tests, but you said you were going to run 123 tests, probably you should change your test count would be useful. (And if i recall is produced by Test::Harness?) Cheers, Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: Too many tests
How else are you going to deal with you've run more tests than you said you were? If you accept the results and assume the count is wrong how do you know what the program didn't silently die part way through and in fact you are dealing with a catastrophic failure in the middle of more tests than were run? Yep, too many tests is a major error, not of those test, but of the plan. You promised to run X tests, you didn't. FAIL. Over or under, it doesn't matter. That's why the plan is there. Adam K
Re: New TAP Grammar
Ovid wrote: The reason you see descriptions starting with a hyphen in Test::More style output is because people do stuff like this: ok $foo, '3rd test passed'; And you don't want to risk that leading digit confusing the parser. Actually its there because I thought it made it easier to read. :) ~ missing 'Bail out!' Phooey! Thanks. Um, that raises an interesting question: is anything allowed after Bail out? I see that in some of the sample tests, but I'll try and figure out those after I get off work. *shrug* No opinion here.
Re: New TAP Grammar
chromatic wrote: On Thursday 14 September 2006 13:14, Ovid wrote: What's 'bonus'? I haven't figured that out yet. That should be the number of successful TODO tests. If it's not, I have no idea. Also, I never tracked the exit status of the tests. Frankly, I never used that number myself. Does anyone? If so, can anyone provide a use case? Originally that was to indicate the number of failing tests, but using an unsigned eight-bit integer really limites the applicability. You should be able to ignore it. That use of the exit code is a Test::More-ism and came in rather late in the game. It was put in to allow you to determine how many tests failed without having to parse the output. I don't know of anyone who actually used it to that effect. The true purpose of the harness tracking the exit code is because of this: 1..2 ok 1 ok 2 Segmentation fault That is a failing test, you have to check for a non-zero exit code to know that. So no, you can't ignore it. Its also useful information. When you program explodes sometimes its useful to know its exit and wait status.
Re: New TAP Grammar
It might be worth running Perl::MinimumVersion over the codebase real quick. It has all the obvious stuff coded into it (like warnings and qr//) already. Adam K Michael G Schwern wrote: Ovid wrote: Also, for purposes of backwards compatability, I'm concerned about qr// and $code-(). When were those first introduced in Perl? I don't want someone using really old versions to not be able to use this code. qr// was introduced in 5.6. $code-() has been in there as long as I know. use warnings is 5.6. To give you an idea, the Test-Simple distribution has been broken on 5.5.3 for a few releases now (Test::Builder::Tester uses qr//) and I've gotten a grand total of one bug report about it.
Re: New TAP Grammar
A few minor corrections:
On Sep 14, 2006, at 3:47 PM, jerry gay wrote:
grammar TAP;
## Ovid's TAP grammar, translated, corrected, and rendered idiomatic
## NOTE: not yet extended to deal with 'Bail out!' etc.
token tap { plan lines | lines plan comment* }
token plan{ '1..' \d+ \n }
That \d+ is bad because it allows '000'. Instead:
token plan{ '1..' [ '0' | [1..9] \d* ] \n }
token lines { line+ }
token line{ test | comment }
token test{
status
[ ' ' ([1..9] \d*) ]? ## assumes a single
space, not \h+
\h* description? \h* directive? \n
}
token status { 'not '? 'ok' }
token description { after \h -[#\n]+ }
The description can't start with a number if there is a test number:
token description { after \h -[#\n\d] -[#\n]* }
token directive { after \h '# ' [:i todo | skip ] \N* }
token comment { '#' \N* \n }
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/)
