Re: TAP diagnostic syntax proposal
Whoa whoa whoa slow down there folks... Some people seemed to have misrecognised those keys as YAML. It was NEVER meant to be YAML. The idea was to use something more like MIME headers. We all agreed that we DIDN'T want the format to be too heavy, and going with MIME or MIME-alike seemed the sweet spot in terms of ease of parsing and standardization vs extensibility. Having YAML in the TAP spec would complicate things greatly, especially as the YAML spec includes things like multi-line strings. And it would mean that we'd have to deal with YAML error events, JSON-style parsing and a bunch of other things that are problematic. It's NOT ease to parse at all, not compared to the current relative simplicity of TAP at the moment. Adam K Jonathan T. Rockway wrote: not ok 2 - omg t3h sooper test!!1! --- TAP diagnostics file:foo.t Why aren't we commenting the YAML block so that it's compatible with current TAP parsers? I'm thinking something like this: not ok 2 - ensure that foo is equal to bar # --- !!tap/diagnostics # file: foo.t # line: 42 # got: # - !!perl/foobar # key: value # expected: # - !!perl/foobar # key: ~ # etc: (and so on) The commented section is raw YAML goodness, AND this format is compatible with current TAP parsers. I'm liking this a lot, especially since I can use it Right Now (tm) by doing diag(Dump($data)). Any reason this shouldn't be the standard? It's easy to parse, it's easy to read. Would it be acecptable if I patched Test::More to start outputing it's expected/got messages in YAML instead of a plain text format? Regards, Jonathan Rockway
Re: TAP diagnostic syntax proposal
I can see why we wouldn't want to include YAML, and won't cry for *too long* if it doesn't go in ;), but here are some reasons why I'd like for full YAML to be a part of the spec: - marshaling data structures between the application being tested and the test harness (strings are nice, but full Perl/!!YAML objects are nicer) - infinite extensibility (then again, it was a little bit too easy for people to add to HTML, and look at what that got us) I just think having all of YAML at our disposal would let test authors and test harness authors do pretty much anything they want. YAML is pretty hard to parse, but fortunately the Hard Work has been done for us. YAML::Syck supports all the YAML we need and it has bindings for pretty much every language. I wouldn't call it lightweight, but the 300k of additional memory it uses is worth the potential benefits. I dunno, maybe I *am* overthinking this. It's just TAP. I guess what I really want is for the perl interpreter to be able to serialize itself so I can debug failing tests more easily. That's not really a TAP issue,though :) Regards, Jonathan Rockway Adam Kennedy wrote: > Whoa whoa whoa slow down there folks... > > Some people seemed to have misrecognised those keys as YAML. > > It was NEVER meant to be YAML. > > The idea was to use something more like MIME headers. > > We all agreed that we DIDN'T want the format to be too heavy, and going > with MIME or MIME-alike seemed the sweet spot in terms of ease of > parsing and standardization vs extensibility. > > Having YAML in the TAP spec would complicate things greatly, especially > as the YAML spec includes things like multi-line strings. And it would > mean that we'd have to deal with YAML error events, JSON-style parsing > and a bunch of other things that are problematic. > > It's NOT ease to parse at all, not compared to the current relative > simplicity of TAP at the moment. > > Adam K > > Jonathan T. Rockway wrote: >>> not ok 2 - omg t3h sooper test!!1! >>> --- TAP diagnostics >>> file:foo.t >> >> >> Why aren't we commenting the YAML block so that it's compatible with >> current TAP parsers? I'm thinking something like this: >> >> not ok 2 - ensure that foo is equal to bar >> # --- !!tap/diagnostics >> # file: foo.t >> # line: 42 >> # got: >> # - !!perl/foobar >> # key: value >> # expected: >> # - !!perl/foobar >> # key: ~ >> # etc: (and so on) >> >> The commented section is raw YAML goodness, AND this format is >> compatible with current TAP parsers. I'm liking this a lot, >> especially since I can use it Right Now (tm) by doing diag(Dump($data)). >> >> Any reason this shouldn't be the standard? It's easy to parse, it's >> easy to read. >> >> Would it be acecptable if I patched Test::More to start outputing it's >> expected/got messages in YAML instead of a plain text format? >> >> Regards, >> Jonathan Rockway > signature.asc Description: OpenPGP digital signature
Re: TAP diagnostic syntax proposal
- Original Message
From: Adam Kennedy
> Whoa whoa whoa slow down there folks...
>
> Some people seemed to have misrecognised those keys as YAML.
>
> It was NEVER meant to be YAML.
>
> The idea was to use something more like MIME headers.
Well, regardless of what those lines are, we might have to come up with a
language agnostic implementation if we really care about what we're going to do
with that data other than spit it out the whole chunk of it. If all that's
intended is to show a pop-up of the failure after clicking on a "See Details"
button, then parsing it isn't necessary and I, for one, am not keen on writing
one parser for TAP and having a separate parser for the details.
My vote:
not ok 2 - omg t3h sooper test!!1!
> { any:
> junk,
> you:
> want.
>TADA! }
I don't care *what* is on the right side of the "> " (greater than, space).
Any TAP parser shouldn't care, either. It merely knows that this is failure
information associated with the previous test. If someone wants to write a
custom handler which handles their language's flavor of got/expected (I agree
that "got" is terrible), then let them parse that for their little "See
Details" GUI pop-up box.
So in the parser:
while ( my $chunk = $tap_stream->() ) {
$parser->parse_stream( $chunk );
}
$parser->finalize;
foreach my $result ( $parser->results ) {
if ( $result->is_test && $result->failed ) {
my_parser( $result->diagnostics ); # whee! We don't care what it does
}
else { ... }
}
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/
WWW::Mechanize 1.18 passing value of submit field
On a form the submit button looks like this:
when this form is submitted using
$w->submit_form (
fields => {
fname => 'Foo',
});
the field submit and its value Update does not seem to be sent
to web server. If I add
submit => 'Update',
to the list of the fields, it silently ignores this field.
In my case this causes the application to fail as it derives some state
information from the value of the submit field.
Using Firefox the submit=Update is sent to the server.
How can I fix this?
Gabor
Re: WWW::Mechanize 1.18 passing value of submit field
On Tue, Jul 11, 2006 at 01:47:26PM +0300, Gabor Szabo wrote:
> On a form the submit button looks like this:
>
>
>
> when this form is submitted using
>
> $w->submit_form (
>fields => {
>fname => 'Foo',
>});
>
> the field submit and its value Update does not seem to be sent
> to web server. If I add
>
>submit => 'Update',
>
> to the list of the fields, it silently ignores this field.
> In my case this causes the application to fail as it derives some state
> information from the value of the submit field.
>
> Using Firefox the submit=Update is sent to the server.
>
> How can I fix this?
WWW::Mechanize(3pm)
$mech->submit_form( ... )
This method lets you select a form from the previously fetched page,
fill in its fields, and submit it. It combines the form_number/form_name,
set_fields and click methods into one higher level call. Its arguments
are a list of key/value pairs, all of which are optional.
[stripped]
* button => button
Clicks on button button (calls "click()")
J
--
Jody Belka
knew (at) pimb (dot) org
Re: WWW::Mechanize 1.18 passing value of submit field
the field submit and its value Update does not seem to be sent to web server. If I add submit => 'Update', That's right. It's possible to submit a form without specifying a submit button. If you want the submit button clicked, then you have to explicitly specify it. Also, this is better asked on libwww list. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: WWW::Mechanize 1.18 passing value of submit field
On 7/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > How can I fix this? WWW::Mechanize(3pm) $mech->submit_form( ... ) This method lets you select a form from the previously fetched page, fill in its fields, and submit it. It combines the form_number/form_name, set_fields and click methods into one higher level call. Its arguments are a list of key/value pairs, all of which are optional. [stripped] * button => button Clicks on button button (calls "click()") Thanks this indeed works. From the documentation it is not clear (to me) why is the value of the submit button sent only if I specify button => button The doc only sais this: If button is not passed, then the "submit()" method is used instead. regards Gabor
Re: WWW::Mechanize 1.18 passing value of submit field
On Jul 11, 2006, at 9:07 AM, Gabor Szabo wrote: If button is not passed, then the "submit()" method is used instead. Perhaps it could be clearer then: submit() does not pass any button unless you specify it. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: WWW::Mechanize 1.18 passing value of submit field
On 7/11/06, Andy Lester <[EMAIL PROTECTED]> wrote:
On Jul 11, 2006, at 9:07 AM, Gabor Szabo wrote:
> If button is not passed, then the "submit()" method is used
> instead.
Perhaps it could be clearer then: submit() does not pass any button
unless you specify it.
Yes maybe that, in addition to the current sentence.
Also I think if the button is not specified but someone adds a
fields => {
buttonname => 'some value'
}
this should generate at least a warning (and not silently ignored as
it seems to be today). After all the coder seems to desperately want
to send the value of the
submit button.
Gabor
Re: TAP diagnostic syntax proposal
I mentioned YAML with a pretense I failed to mention -- that we
wouldn't parse the YAML. That's already been done, and there are
plenty of parsers.
YAML has clear designations of where it starts and ends. A TAP parser
wouldn't have to look at the diagnostics and guess what it is.
If the data structure is limited to MIME-like key/value pairs, many
people will do their own marshalling anyway. Why not give them that
power from the start?
Maybe we don't care. Maybe we can simply add a callback for some
diagnostic_block_analyzer() and, in my own little happy world,
$parser->diagnostic_block_analyzer( sub {
my ($block) = @_;
if ($block =~ m{ \A --- }xs) {
do something with YAML::Load($block);
}
else {
do something else
}
});
On 7/11/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
Whoa whoa whoa slow down there folks...
Some people seemed to have misrecognised those keys as YAML.
It was NEVER meant to be YAML.
The idea was to use something more like MIME headers.
We all agreed that we DIDN'T want the format to be too heavy, and going
with MIME or MIME-alike seemed the sweet spot in terms of ease of
parsing and standardization vs extensibility.
Having YAML in the TAP spec would complicate things greatly, especially
as the YAML spec includes things like multi-line strings. And it would
mean that we'd have to deal with YAML error events, JSON-style parsing
and a bunch of other things that are problematic.
It's NOT ease to parse at all, not compared to the current relative
simplicity of TAP at the moment.
Adam K
Jonathan T. Rockway wrote:
>> not ok 2 - omg t3h sooper test!!1!
>> --- TAP diagnostics
>> file:foo.t
>
>
> Why aren't we commenting the YAML block so that it's compatible with
> current TAP parsers? I'm thinking something like this:
>
> not ok 2 - ensure that foo is equal to bar
> # --- !!tap/diagnostics
> # file: foo.t
> # line: 42
> # got:
> # - !!perl/foobar
> # key: value
> # expected:
> # - !!perl/foobar
> # key: ~
> # etc: (and so on)
>
> The commented section is raw YAML goodness, AND this format is
> compatible with current TAP parsers. I'm liking this a lot, especially
> since I can use it Right Now (tm) by doing diag(Dump($data)).
>
> Any reason this shouldn't be the standard? It's easy to parse, it's easy
> to read.
>
> Would it be acecptable if I patched Test::More to start outputing it's
> expected/got messages in YAML instead of a plain text format?
>
> Regards,
> Jonathan Rockway
--
Ian Langworth
Re: TAP diagnostic syntax proposal
On Jul 11, 2006, at 7:34 AM, Ian Langworth wrote:
Maybe we don't care. Maybe we can simply add a callback for some
diagnostic_block_analyzer() and, in my own little happy world,
$parser->diagnostic_block_analyzer( sub {
my ($block) = @_;
if ($block =~ m{ \A --- }xs) {
do something with YAML::Load($block);
}
else {
do something else
}
});
If you merge this together with Ovid's proposal, I like it fine. We
have some arbitrary associated chunk of data - format user-defined -
that follows the ok/not ok; if there's a callback supplied to do
something with it, fine; otherwise it's opaque to TAP and we don't
care. Delimiting it visually somehow is probably a good idea.
This is, I think, a place where "stupid is better" wins, The TAP
parser is less complex, which makes it more reasonable to assume that
other languages/platforms will implement it, and the diagnostic info
becomes extremely flexible as to what it contains because it's
essentially unparsed arbitrary data. In an extreme case, it's'
arbitrary binary data: this is the PNG that the program generated. If
you *want* YAML, or MIME headers, or whatever, they're permissible,
as long as the data follows the basic "this is diag data" standard..
A data generator/parser plugin plugs in to the TAP parser: the
generator side encodes diagnostic data in the manner the parser side
will understand. This becomes testable as a separate unitm and allows
anyone to extend TAP in whatever direction they like.
We could go REALLY stupid: the plugin gets a lookin first at each
"item" in the TAP data stream and decides if the TAP parser should
see it at all; then you have no limit whatsoever on the data format,
as long as the plugin can parse it.
--- Joe M.
Re: TAP diagnostic syntax proposal
Ian Langworth wrote: I mentioned YAML with a pretense I failed to mention -- that we wouldn't parse the YAML. That's already been done, and there are plenty of parsers. I agree with this. YAML has been done and done again, in every language. It works, it's tested. I don't think we need EVERY feature of YAML; Syck is enough for my everyday use, anyway. How about this? Let's make "comments" and "data" separate parts of TAP. Comments are the usual # Testing Foo::Bar 0.42 on perl 6.0.0 (r69342 20091225) We already have and use these, so no further explanantion is necessary :) In addition to comments, we could have some "data" that follows a test. A data section begins with "--- " and ends with "...", and can contain anything. This is an "approved" way of getting data from the app to the harness if necessary. If the harness doesn't understand whatever's in that section, it can safely ignore it. If the harness DOES understand the data, well then, it can act on it. This seems like the best way to make everyone happy :) However, if you wanted to make *me* happy ;), why not make the whole darn thing a YAML stream like this: --- plan: 10 testname: foo --- diagnostic: Testing Foo::Bar version 42 interperter: perl 6.0.0 (20091225) operating_system: OpenBSD other: information --- test: Test whether foo + bar = baz result: ok sequence: 1 --- test: Test whether foo - bar = bar result: not ok sequence: 2 have: !!perl:hash/Foo::Bar hello: world value: 32 want: !!perl:hash/Foo::Bar hello: world value: 38 filename: t/foo.t line: 8 --- etc. The harness can then print out: foo.0/10 foo.1/10 foo.2/10 FAILED TEST 2: have: [whatever Foo::Bar stringifies to] want: [whatever the other Foo::Bar stringifies to] as per usual. IO::YAML will handle these streams properly, BTW. This might be a Perl-only solution, though. Regards, Jonathan Rockway
Re: WWW::Mechanize 1.18 passing value of submit field
On Tue, Jul 11, 2006 at 05:07:02PM +0300, Gabor Szabo wrote:
> From the documentation it is not clear (to me) why is the value of the
> submit
> button sent only if I specify button => button
> The doc only sais this:
>
> If button is not passed, then the "submit()" method is used instead.
And if you look at the documentation for "submit()", which is just above, then
you see this:
$mech->submit()
Submits the page, without specifying a button to click. Actually, no
button is clicked at all.
This used to be a synonym for "$mech->click("submit")", but is no longer
so.
J
--
Jody Belka
knew (at) pimb (dot) org
Re: TAP diagnostic syntax proposal
On 7/11/06, Jonathan T. Rockway <[EMAIL PROTECTED]> wrote: Ian Langworth wrote: > I mentioned YAML with a pretense I failed to mention -- that we > wouldn't parse the YAML. That's already been done, and there are > plenty of parsers. I agree with this. YAML has been done and done again, in every language. It works, it's tested. I don't think we need EVERY feature of YAML; Syck is enough for my everyday use, anyway. if i recall correctly, syck doesn't handle utf-8/16. does/will tap care about that? oh, and while i'm thinking about it, i think it would be wise to include a tap version in the tap header, so as this protocol changes, parsers will have a chance to handle different tap versions gracefully. ~jerry
Re: TAP diagnostic syntax proposal
- Original Message From: Jonathan T. Rockway <[EMAIL PROTECTED]> > However, if you wanted to make *me* happy ;), why not make the whole > darn thing a YAML stream like this: > --- > test: Test whether foo + bar = baz > result: ok > sequence: 1 > --- Aside from the fact that many languages are already using the TAP protocol and we'd create something they *don't* use, what happens when my 4,000 test lines all of a sudden become 16,000 test lines because the format has been changed? *falls over dead* Hugs, Ovid
Re: TAP diagnostic syntax proposal
if i recall correctly, syck doesn't handle utf-8/16. does/will tap care about that? That's true -- I think Audrey patched the perl version to work properly, but I forgot that other languages are without that functionality. Ruby doesn't properly support Unicode either, so Unicode support probably doesn't matter to them. (I think Syck is originally a Ruby project, and Ruby has some moral qualm with Unicode, so that's why Syck doesn't work with Unicode.) As for Python, dunno. I do actually do test UTF-8 data structures in some of my tests, so this is actually a relevant concern. I think things will work fine if you're just outputting UTF8 data to your UTF8 terminal, but if you're doing colation or charset conversion (maybe your terminal is EUC_JP for example), then you'll run into problems. This is something to look into, if we want YAML TAP to work for languages other than Perl. What else is TAP targeted to? C / C++ / Java? oh, and while i'm thinking about it, i think it would be wise to include a tap version in the tap header, so as this protocol changes, parsers will have a chance to handle different tap versions gracefully. Good idea.
Re: TAP diagnostic syntax proposal
- Original Message From: Jonathan Rockway <[EMAIL PROTECTED]> > What else is TAP targeted to? C / C++ / Java? Java programmers typically use jUnit. C programmers have libtap available. PHP tests often use TAP (don't know the name) and Javascript has Test.Simple, though it parses the test results directly and then outputs TAP (if I recall correctly). 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: TAP diagnostic syntax proposal
Ovid wrote: > - Original Message From: Jonathan Rockway <[EMAIL PROTECTED]> > >> What else is TAP targeted to? C / C++ / Java? > > > PHP tests often use TAP (don't know the name) almost all of the php test frameworks now offer TAP support - see http://search.cpan.org/dist/Test-Harness/lib/Test/Harness/TAP.pod#PHP there's also a decent list of other languages as well. --Geoff
Re: TAP diagnostic syntax proposal
Aside from the fact that many languages are already using the TAP protocol and we'd create something they *don't* use, what happens when my 4,000 test lines all of a sudden become 16,000 test lines because the format has been changed? Do you pay for CPU time on a per-newline basis? :) Good point, though. If we put YAML in comments then we remain compatible with all past parsers and emitters. However, most perl tests don't care about TAP, they use Test::More and Test::Harness and happen to exchange data via TAP. If Test::More and Test::Harness decied to use "YAP" (YAML Anything Protocol? :), then most applications would probably never notice. However, emitting a raw YAML stream means that the application can never emit any other output, otherwise the YAML will become invalid. If we use comments and --- ..., then non-TAP output should still be acceptable. OK, you've convinced me. All-YAML TAP isn't a good idea. I might play with it a little more though, just for fun. Regards, Jonathan Rockway
Re: TAP diagnostic syntax proposal
> However, most perl tests don't care about TAP, they use Test::More and > Test::Harness and happen to exchange data via TAP. If Test::More and > Test::Harness decied to use "YAP" (YAML Anything Protocol? :), then most > applications would probably never notice. most _perl_ applications would never notice. IMHO however this overhaul ends up playing out, TAPs current marvel is that it's wonderfully simple and very forgiving - if the new version isn't completely back compatible y'all should call it something else, lest you risk alienating all the non-perl folks who embraced the protocol because of it's simplicity. in other words, call it TAP but break current non-perl TAP implementations and I think you'll wipe out the userbase that some of us spent a lot of effort trying to win over (and succeeding :) --Geoff
Re: TAP diagnostic syntax proposal
On Jul 11, 2006, at 09:21, Ovid wrote: Java programmers typically use jUnit. C programmers have libtap available. PHP tests often use TAP (don't know the name) and Javascript has Test.Simple, though it parses the test results directly and then outputs TAP (if I recall correctly). It both outputs TAP (for parsers to harvest) *and* keeps an internal data structure for its own harnessing (I wasn't keen on writing a parser in JS). Best, David
Module::Dependency 1.84
I needed some code to trawl through a directory tree parsing perl
modules and scripts to determine their dependencies.
The closest existing CPAN code was Module::Dependency but it fell short
of what I needed. The original author (P Kent) has passed over
maintenance to me. My latest release is:
file: $CPAN/authors/id/T/TI/TIMB/Module-Dependency-1.84.tar.gz
size: 52161 bytes
md5: 90a83b2aee39f5d25060ebdb6cc3105d
With the changes I've made I've pretty much 'scratched my own itch'
for the time being. (Most recently with a completely new query
script - docs appended below.) But the core code is still basically as
it was when I came to it.
I'm posting this here to see if anyone would like to contribute to it.
The code is in subversion on perl.org and I'll happily give write
access to anyone interested.
Some random things I'd like to see done:
- make items be real objects with methods etc
- use overloading to stringify to $obj->{key}
- move some pmd_dump.pl subs into object methods
- abstract the modules and give them proper APIs
- move to using Sqlite with a proper schema
for example to handle multiple packages per file,
not to mention supporting arbitrary queries
- Look at using Graph::Easy to rewrite/replace Module::Dependency::Grapher.
Tim.
=head1 NAME
pmd_dump.pl - Query and print Module::Dependency info
=head1 SYNOPSIS
pmd_dump.pl [options] object-patterns
object-patterns can be:
f=S- Select objects where field f equals string S
f=~R - Select objects where field f matches regex R
S$ - Same as filename=~S$ to match by file suffix
S - Same as key=S
For example:
package=Foo::Bar - that specific package
package=~^Foo:: - all packages that start with Foo::
filename=~sub/dir/path - everything with that path in the filename
filename=~'\.pm$'- all modules
restart.pl$ - all files with names ending in restart.pl
foo - same as key=foo
Fields available are:
filename - "dir/subdir/foo.pl"
package - "strict"
key - same as package for packages, or filename for other files
filerootdir - "/abs/path"
depends_on - "Carp strict Foo::Bar"
depended_upon_by - "Other::Module dir/subdir/foo.pl dir2/bar.pl
Another:Module"
Selected objects can be augmented using:
-P=N Also pre-select N levels of parent objects
-C=N Also pre-select N levels of child objects
Then filtered:
-F=P Filter OUT objects matching the object-pattern P
-S=P Only SELECT objects matching the object-pattern P
Then merged:
-M Merge data for selected objects into a single pseudo-object.
Removes internally resolved dependencies.
Handy to see all external dependencies of a group of files.
The -P and -C flags are typically only useful with -M.
Then modified:
-D Delete dependencies on modules which weren't indexed but can
be found in @INC
Then dumped:
-f=f1,f2,... - only dump these fields (otherwise all)
And for each one dumped:
-p=N Recurse to show N levels of indented parent objects first
-c=N Recurse to show N levels of indented child objects after
-i=S Use S as the indent string (default is a tab)
-u Unique - only show a child or parent once
-k Don't show key in header, just the fieldname
-h Don't show header (like grep -h), used with -f=fieldname
-s sort by name
-r=P Show the relationship between the item and those matching P
Other options:
-help Displays this help
-t Displays tracing messages
-o the location of the datafile (default is /var/tmp/dependence/unified.dat)
-r State the relationship, if any, between item1 and item2 - both may be
scripts or modules.
=head1 EXAMPLE
pmd_dump.pl -o ./unified.dat Module::Dependency::Info
Select and merge everything in the database (which removes internally resolved
dependencies) and list the names of all unresolved packages:
pmd_dump.pl -f=depends_on -h -M ''
Do the same but feed the results back into pmd_dump.pl to get details of what
depends on those unresolved items:
pmd_dump.pl -f=depended_upon_by `pmd_dump.pl -f=depends_on -h -M ''` | less
-S
=cut
Fw: TAP diagnostic syntax proposal
Aargh! It gets annoying that the reply goes directly to the author rather than the list. -- 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/ - Forwarded Message From: Ovid <[EMAIL PROTECTED]> To: Jonathan Rockway <[EMAIL PROTECTED]>; perl-qa@perl.org Sent: Tuesday, July 11, 2006 5:21:33 PM Subject: Re: TAP diagnostic syntax proposal - Original Message From: Jonathan Rockway <[EMAIL PROTECTED]> > What else is TAP targeted to? C / C++ / Java? Java programmers typically use jUnit. C programmers have libtap available. PHP tests often use TAP (don't know the name) and Javascript has Test.Simple, though it parses the test results directly and then outputs TAP (if I recall correctly). 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/
CPANDB - was: Module::Dependency 1.84
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Moin Tim,
On Tuesday 11 July 2006 18:34, Tim Bunce wrote:
> I needed some code to trawl through a directory tree parsing perl
> modules and scripts to determine their dependencies.
>
> The closest existing CPAN code was Module::Dependency but it fell short
> of what I needed. The original author (P Kent) has passed over
> maintenance to me. My latest release is:
>
> file: $CPAN/authors/id/T/TI/TIMB/Module-Dependency-1.84.tar.gz
> size: 52161 bytes
>md5: 90a83b2aee39f5d25060ebdb6cc3105d
Thats sort of cool, although I havent looked at it yet :-D
My real-grand-plan was always to have a CPANDB module that does exactly the
following:
maintains a database with:
* every CPAN author with all details (ID, email, name)
* every package with all details (author id, version, name etc etc)
You would get current packages and old, for performance reasons in tow Dbs
but this would be transparent for the user. There would be two interfaces:
# cpandb --query Math::BigInt
name: Math::Bigint
author: TELS
version: v1.77
latest: v1.77
# cpandb --update Math-BigInt-1.78.tar.gz
package Math::Bigint updated.
New entry:
name: Math::Bigint
author: TELS
version: v1.78
latest: v1.78
# cpandb --query Math-BigInt-1.77
name: Math::Bigint
author: TELS
version: v1.77
latest: v1.78
and so on. This script would also update, add etc to the DB, much like RPM.
(it only maintains the DB, no code no install etc).
The other interface is Perl OO like so:
use CPANDB;
my $db = CPANDB->open();# default location
print $db->author('TELS');
my $m = $db->latest_package'(Math::BigInt');
print $m->depends_on();
etc.
The Db would be empty, but with a suitale wrapper around cpandb could be
filled, or you could download a pre-made one. Pause could even maintain on
on their own, because then it would be always update.
This database could then be used by all the following modules:
Module::Dependency
Graph::Dependency
CPANPLUS
CPANTS
CPAN
Module::Author
and a few others I forgot. Basically by every module out there that
re-invents the wheel over and over again just to be able to query stuff
about CPAN modules. (some of them do really horrible stuff like accessing
search.cpan.org - I know I wrote one of them :D
And up until today it is still not possible to get easily the answer "what
modules do I need install for Foo::Bar 1.23 when using Perl 5.8.x".
(Why not use CPANTs database? Easy, because the interface module is as far
as I know broken since a few years, the database changed formats a few
times (breaking any interfacing module again), its undocumented (that is
not the documentation you are looking for) and has a few other small
problems, like no command line interface etc. And it is tightly integrated
into CPANTS and it has a lot of dependency like sql or postgres or
whatever. All the other solutions out there have some of the same problems
or other problems of the same kind.
The most common theme seems to be that everyone wants what the DB does, plus
something more (website generator, graph generator, installator and a shell
etc). And since no real DB exists yet, everyone invents their own DB
backend again :)
My idea was to build _only_ the database, and do it right, simple and easy
to use and then get everyone else to just use the DB instead of fiddling
with their own. (simple by having the database being superior to every
other hack thats in existance now :-)
I even got so far as to do a mockup v0.02 - but then went back to playing
Guildwars.
Is this a project that would be of general interest?
best wishes,
Tels
PS: Sorry for the rambling on, its 3:00 am local time and I should be asleep
since 3 or 4 hours. And this email should have been written like 2 months
ago. I hope someone understand what I wanted to say :-D
- --
Signed on Wed Jul 12 02:58:38 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
I am looking for a Perl-related job (no, Python is not Perl-related :-).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iQEVAwUBRLRKWncLPEOTuEwVAQI9TQf+I9xoOMGGEj6V5poS4VUX9fVN8FcPyYlP
jdT6PGCfurG7kGs2zuhyPYBM+W6rlk5wvrfI30KoDtxzDuCyCdogNIWekpjtnWB+
Ei72dZdVtiWEADxLopGG2gAMjhE4OPKo7qkmiox3sZQj/9jpU87nHCDpVHxrC1as
QlVJUaA3MGl75mYepiMoyoBcGfjyWsVzd59rouymwp4/NVpSfU+z4/cZU4KRFNb+
RuKmYXQKSfSsQe4Jn1o69ZCkzPOlZ2NC0HfVN6ZXCZ/iz5/CZTq3nT6iM/JBOIOE
HOAqwJzz3fkdS1z/AlKaoDbKNv+tBaH+6+wyX15dzr5f3UKR/2pb2g==
=lDv9
-END PGP SIGNATURE-
Re: CPANDB - was: Module::Dependency 1.84
Tels wrote: My idea was to build _only_ the database, and do it right, simple and easy to use and then get everyone else to just use the DB instead of fiddling with their own. (simple by having the database being superior to every other hack thats in existance now :-) I even got so far as to do a mockup v0.02 - but then went back to playing Guildwars. Is this a project that would be of general interest? At YAPC::NA, Adam Kennedy mention that he wanted to try to make some headway on CPAN::Index, which sounds very similar in intent. While it's not released, you can see the formative project at his public repository: http://tinyurl.com/g888h Perhaps you can join forces with him and help push some collective project towards a release. Regards, David Golden
Re: TAP diagnostic syntax proposal
Geoffrey Young wrote: However, most perl tests don't care about TAP, they use Test::More and Test::Harness and happen to exchange data via TAP. If Test::More and Test::Harness decied to use "YAP" (YAML Anything Protocol? :), then most applications would probably never notice. most _perl_ applications would never notice. IMHO however this overhaul ends up playing out, TAPs current marvel is that it's wonderfully simple and very forgiving - if the new version isn't completely back compatible y'all should call it something else, lest you risk alienating all the non-perl folks who embraced the protocol because of it's simplicity. in other words, call it TAP but break current non-perl TAP implementations and I think you'll wipe out the userbase that some of us spent a lot of effort trying to win over (and succeeding :) Indeed, I think we were pretty much clear that under no circumstances whatsoever would we break full back-compatibility. The idea of the extra mime-like things was to be able to provide some relatively simple and cross-language enhancements, so that, for example, if running tests with a higher verbosity, there could be some feedback to, say, an editor or a tool about the location of the errors. This is part of why I dislike YAML for this. Regardless of what the marketing says, it isn't cross-language for anything more than trivial use cases, for example objects or !!perl-specific things. As others have mentioned, the beauty of TAP is it's simplicity and accessibility. It Just Works across languages with almost no effort at all, can be done in pure-$your_language easily, and is generally quite forgiving. In introducing some form of semi-standard enhancements (such as the failure diagnostics) I really don't want to lose this. In using YAML, we're already adding a lot of extra weight, adding dependencies on C libraries, and tempting people into using the more ehnanced, non-platform-neutral features. Lets at least let the YAML spec stop morphing and the language implementations become stable before we start thinking of making TAP inherit any baggage from other protocols by adding them as dependencies. Fair enough a "Layer 1" TAP parser might not care, but why not make it as equally easy to implement a "Layer 2" parser as well. Adam K
