Re: TAP Namespace Nonproliferation Treaty

[Smylers]

Ian Langworth writes:

> Ovid: TAP::Parser::Pedantic
> 
> Schwern: TAP::Parser::Heuristic

That's the best idea: nobody claiming that his particular parser is
_the_ TAP::Parser (or even _the_ TAPx::Parser), but giving them parallel
names with adjectives that hint at ways in which they differ.  Even if
the hints are obscure it's better than just having arbitrary different
names.

At least, nobody claim that namespace _yet_.  A few years down the line
we might've collectively learnt enough that we bless one particular
parser as canonical, or perhaps we'll make TAP::Parser be a front end
multiplexer for picking which parser to load.

> I've always feared /^[A-Z]+x::/ namespaces because I never understood
> them.

They make sense in some circumstances, where there is a well defined
project or system which itself is spread across several modules, and
other folk wish to contribute modules which are not part of that system
but are extensions to it.

But ... I don't think that applies here; it isn't that there's a "core"
Tap system and a clear distinction between that and extensions to it,
and I think it would just get confusing trying to remember which are
TAP:: and which are TAPx:: modules.

Smylers

Re: TAP diagnostic syntax proposal

[A. Pagaltzis]

* Adam Kennedy <[EMAIL PROTECTED]> [2006-07-12 06:10]:
> 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.

+1

Did you guys consider the problem of newlines in content?

Regards,
-- 
Aristotle Pagaltzis // 

fetching module version from the command line

[Gabor Szabo]

While checking if the versions of all the modules are as
required in our installation I am using the following one liner to
fetch the version numbers.

perl -MModule -e'print $Module::VERSION'

Some of the modules print extra error messages and some print
only error messages.
I have sent e-mail to the respective module authors reporting this
issue but I wonder if it would this a good practice in the genric case.

Is there a Test module that test just the above?
Is the a CPANST score one can get if all the modules in a distro
provide the correct version information and if they don't print anything
else to STDOUT or STDERR.

Gabor

Re: fetching module version from the command line

[Adriano Ferreira]

On 7/12/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:

While checking if the versions of all the modules are as
required in our installation I am using the following one liner to
fetch the version numbers.



perl -MModule -e'print $Module::VERSION'


This one-liner doesn't work all the time in modules with deep magic
(filters and modules which do strange/heavy things in BEGIN blocks,
POD-only modules and the like). A (text-based) alternative is the
ExtUtils::MakeMaker approach, which goes as follows:

perl -MExtUtils::MakeMaker -e 'print MM->parse_version(shift)'
/usr/lib/perl5/site_perl/5.8/Module.pm

Unfortunately, it depends on knowing where the .pm file is. But that
can be arranged.


Some of the modules print extra error messages and some print
only error messages.
I have sent e-mail to the respective module authors reporting this
issue but I wonder if it would this a good practice in the genric case.


I think that having version numbers is a good practice. Although to
demand they may be retrieved with "perl -MModule -e 'print
$Module::VERSION'" may be too much - don't forget that it means the
module should compile and certain modules may demand a bunch of
environment settings to do it (the right libraries, some bit of
configuration, etc.)


Is there a Test module that test just the above?
Is the a CPANST score one can get if all the modules in a distro
provide the correct version information and if they don't print anything
else to STDOUT or STDERR.


I think a test to check version numbers are provided is enough.
Another issue is that use_ok() (or some variant) works too (in a
silent fashion). As a matter of fact, the absence of version numbers
is very common for modules which are not the ones that provide the
version number for a CPAN distribution - you may see this at many
places: core modules and many others. For example, trying the YAML::*
modules installed in a Cygwin machine with which_pm (from Module-Which
distribution) gives me (module name, version, location):

$ which_pm YAML:: --p5p
YAML::Syck   0.45   at ${installsitearch}/
YAML::Loader::Syck   undef  at ${installsitearch}/
YAML::Dumper::Syck   undef  at ${installsitearch}/
YAML::Transfer   undef  at ${installsitelib}/
YAML::Family undef  at ${installsitelib}/
YAML::Node   undef  at ${installsitelib}/
YAML::Marshall   undef  at ${installsitelib}/
YAML::Tagundef  at ${installsitelib}/
YAML::Base   undef  at ${installsitelib}/
YAML::Types  undef  at ${installsitelib}/
YAML::Loader undef  at ${installsitelib}/
YAML::Error  undef  at ${installsitelib}/
YAML::Dumper undef  at ${installsitelib}/
YAML::Tiny   0.05   at ${installsitelib}/
YAML::Loader::Base   undef  at ${installsitelib}/
YAML::Dumper::Base   undef  at ${installsitelib}/

from Config:
   installsitearch: /usr/lib/perl5/site_perl/5.8/cygwin
   installsitelib: /usr/lib/perl5/site_perl/5.8

Adriano.

Re: fetching module version from the command line

[H.Merijn Brand]

On Wed, 12 Jul 2006 13:41:16 +0300, "Gabor Szabo" <[EMAIL PROTECTED]> wrote:

> While checking if the versions of all the modules are as
> required in our installation I am using the following one liner to
> fetch the version numbers.
> 
> perl -MModule -e'print $Module::VERSION'

Not really reliable :) But the more reliable ways take some post-processing

pc09:/home/merijn 108 > perl -le'require V;print V::get_version("DBI")'
1.51
pc09:/home/merijn 109 > perl -MExtUtils::Installed -le'print 
ExtUtils::Installed->new->version("DBI")'
1.51
pc09:/home/merijn 110 > perl -MV=DBI
DBI
/pro/lib/perl5/site_perl/5.8.7/i686-linux-64int/DBI.pm: 1.51
pc09:/home/merijn 111 > perl -le'require V;print V::get_version("DBI")' 
1.51
pc09:/home/merijn 112 > perl -MDBI=99
DBI version 99 required--this is only version 1.51 at 
/pro/lib/perl5/5.8.7/Exporter/Heavy.pm line 121.
BEGIN failed--compilation aborted.
Exit 9
pc09:/home/merijn 113 >

V is not (yet) on CPAN: http://www.test-smoke.org/otherperl.html

> Some of the modules print extra error messages and some print
> only error messages.
> I have sent e-mail to the respective module authors reporting this
> issue but I wonder if it would this a good practice in the genric case.
> 
> Is there a Test module that test just the above?
> Is the a CPANST score one can get if all the modules in a distro
> provide the correct version information and if they don't print anything
> else to STDOUT or STDERR.


-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x  on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0, AIX 4.3 & 5.2, and Cygwin.   http://qa.perl.org
http://mirrors.develooper.com/hpux/   http://www.test-smoke.org
   http://www.goldmark.org/jeff/stupid-disclaimers/

Re: fetching module version from the command line

[Rafael Garcia-Suarez]

"Gabor Szabo" wrote in perl.qa :
> While checking if the versions of all the modules are as
> required in our installation I am using the following one liner to
> fetch the version numbers.
>
> perl -MModule -e'print $Module::VERSION'

You should probably use -mModule to avoid calling Module::import().
(also, in some pathological cases, one can imagine that
UNIVERSAL::VERSION() has been overidden)

Side note:
Abe Timmerman has a module, V, useful to get versions
of installed modules:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-03/msg01038.html

Re: TAP diagnostic syntax proposal

[Ian Langworth]

On 7/11/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:


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.


Bingo.

--
Ian Langworth

Re: fetching module version from the command line

[H.Merijn Brand]

On 12 Jul 2006 11:52:07 -, Rafael Garcia-Suarez
<[EMAIL PROTECTED]> wrote:

> "Gabor Szabo" wrote in perl.qa :
> > While checking if the versions of all the modules are as
> > required in our installation I am using the following one liner to
> > fetch the version numbers.
> >
> > perl -MModule -e'print $Module::VERSION'
> 
> You should probably use -mModule to avoid calling Module::import().
> (also, in some pathological cases, one can imagine that
> UNIVERSAL::VERSION() has been overidden)
> 
> Side note:
> Abe Timmerman has a module, V, useful to get versions
> of installed modules:
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-03/msg01038.html

I never use -m. I should :)

# perl -mV -le'print V::get_version("DBI")'
1.51

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x  on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0, AIX 4.3 & 5.2, and Cygwin.   http://qa.perl.org
http://mirrors.develooper.com/hpux/   http://www.test-smoke.org
   http://www.goldmark.org/jeff/stupid-disclaimers/

Re: TAP diagnostic syntax proposal

[David Landgren]

Jonathan T. Rockway wrote:
I agree that "got" is generally a good word to avoid in formal writing, 
but in a testing protocol I think that it's an acceptable abbreviation 


No! Do not accept inferior substitutes, strive for perfection.

for "the actual result".  Especially since "received" doesn't quite 
convey the right meaning here.  Maybe "expected data" and "actual data" 


Expected and actual has a long tradition in scientific endeavour, and is 
what I put forward last year, the last time this subject came up.


(or "expected" and "actually") are better?  Or maybe "got" is fine; HTTP 
still works even though "Referer" is misspelled.


So we should use Recieved? :)

Has got/expected ever caused any confusion to anyone (including 
non-speakers of English)?  If so, why?


Yes me, and I am a native speaker (well, Australian... so... whatever...)

I ranted about this on -qa some time back, and Schwern said that it was 
too late to do anything about it now. But this new format allows me to 
roll out my rant again!


My confusion regarding "got" is that I never know whether it's what I 
got initially, and then I want to see what the test brings back, or 
whether I have something, and it's what I got back from the test. On a 
number of occasions I have stared at a failing test, wondering why when 
I run it manually or stick in printf statements I appear to be getting 
the right thing. Or the wrong thing, whatever. It gets me confused.


Compounded by the fact that, as others point out elsewhere in this 
thread, the order of appearance is backwards.


A primary school teacher taught me that "got" was a word of the weak, 
that can nearly always be replaced by something better. This is the only 
lesson that still stands out vivdly for me from that time.


Here, let me dig up that rant:

  http://www.mail-archive.com/perl-qa@perl.org/msg03999.html

Thanks,
David
--
Much of the propaganda that passes for news in our own society is given 
to immobilising and pacifying people and diverting them from the idea 
that they can confront power. -- John Pilger

Re: TAP diagnostic syntax proposal

[Jonathan Rockway]

Did you guys consider the problem of newlines in content?
  


This is a good question.  Implementing your own file format means you 
have a big-bag-o-quoting problems.  How do you print a verbatim 
newline?  What about a verbatim single quote?  What about Unicode?  What 
about a new line then "not ok - ++$counter"? :)


http://cr.yp.to/qmail/guarantee.html says:


When another programmer wants to talk to a user interface, he has to 
/quote/: convert his structured data into an unstructured sequence of 
commands that the parser will, he hopes, convert back into the 
original structured data.


This situation is a recipe for disaster. The parser often has bugs: it 
fails to handle some inputs according to the documented interface. The 
quoter often has bugs: it produces outputs that do not have the right 
meaning. Only on rare joyous occasions does it happen that the parser 
and the quoter both misinterpret the interface in the same way.




Things to think about :)

Regards,
Jonathan Rockway

Re: fetching module version from the command line

[David Wheeler]

On Jul 12, 2006, at 03:41, Gabor Szabo wrote:


perl -MModule -e'print $Module::VERSION'


I have this alias set up:

  function pv () { perl -M$1 -le "print $1->VERSION"; }

I think that calling ->VERSION is more correct.

Best,

David

Re: TAP diagnostic syntax proposal

[A. Pagaltzis]

* Jonathan Rockway <[EMAIL PROTECTED]> [2006-07-12 17:50]:
> Things to think about :)

This is the time in our program where we stop to consider what it
means that DJB, who wrote that advice/rant, also wrote an RFC2822
parser.

Regards,
-- 
Aristotle Pagaltzis // 

Re: CPANDB - was: Module::Dependency 1.84

[Tels]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Moin,

On Wednesday 12 July 2006 03:13, David Golden wrote:
> 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.

Quoted:

>B provides object-oriented access to the CPAN index,
>using a collection of relatively common modules, and automates
>entire process of fetching and accessing the index.

Uhm, no the DB should maybe be able to have a front-end that fills it from 
the CPAN index, but you should also be able to build a DB from a local 
file, if you so wish.

>The index is stored in a L database file, with an object
>model implemented around it using L. To update the index,
>the L class implements the logic to flush and reset
>the database, fetch the index files, parse them, and repopulate the
>database.

The DB backend shouldn't matter at all, it should be transparent and be 
switchable without any noticable change at the front. Plus, I planned to 
use YAML because it creates a _much_ less heavy overhead and dependency 
chain. Using SQLite or similiar is what really creates the problems with 
CPANTS - you cant just access the raw database without the front-end. 
WithYAML, at least you could get at the data by other means. Of course for 
performance reasons it might not be good, but since premature optimization 
is the root of all evil, I'd say use YAML now, change when nec.

Otherwise, the projects seem similiar in scope, except that I focus on the 
DB and let things like "download stuff" be done outside.

Whether that works out, uh I don't know. In any event I have quite a few 
ideas I'd like to try out and this proves to be fun to me. I hope it 
doesn't end upI have to implement other people ideas - thats too much work 
like :D

Best wishes,

Tels

- -- 
 Signed on Wed Jul 12 18:54:01 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "When it's done in 2001." - 2000 Christmas card about Duke Nukem Forever
 (http://tinyurl.com/6m8nh)

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

iQEVAwUBRLUqL3cLPEOTuEwVAQK3DAf/VEIV3fCdHTMinHZqL9N3JTxAHBIVZSlw
4grWxod0u3/8DiAhHkSjNu4y0XjE2WV1LrI6JWFD+4/qoElUhvMFydLYXP8cG31X
CnXGuAFvq6TVKXCQbHWWucSlcHrILc648i5sCkmi+OTJYUP1AP0/IWdyEbgevWp3
7daHed1UvCetKYyWwTNwgxerTwHAyziFd8kCR2pWzsXUve3zcHhEudm+KF6q6mOI
K069eG99V0R5Ix5nisYAdJdei1+TQ8SSXmNZ30VKju8YFTRKcWQNMmWcdxqErydB
19E5C8HDpXAiafUizpmvG8/tChioFjOS+bbsV/AInid6BcQDBDXONg==
=2qra
-END PGP SIGNATURE-

Re: TAP diagnostic syntax proposal

[Fergal Daly]

If only we had some kind of standard language for marking things up
that was extensible... and wasn't met with universal disapproval,


F

On 12/07/06, Jonathan Rockway <[EMAIL PROTECTED]> wrote:


> Did you guys consider the problem of newlines in content?
>

This is a good question.  Implementing your own file format means you
have a big-bag-o-quoting problems.  How do you print a verbatim
newline?  What about a verbatim single quote?  What about Unicode?  What
about a new line then "not ok - ++$counter"? :)

http://cr.yp.to/qmail/guarantee.html says:
>
> When another programmer wants to talk to a user interface, he has to
> /quote/: convert his structured data into an unstructured sequence of
> commands that the parser will, he hopes, convert back into the
> original structured data.
>
> This situation is a recipe for disaster. The parser often has bugs: it
> fails to handle some inputs according to the documented interface. The
> quoter often has bugs: it produces outputs that do not have the right
> meaning. Only on rare joyous occasions does it happen that the parser
> and the quoter both misinterpret the interface in the same way.
>

Things to think about :)

Regards,
Jonathan Rockway

Re: CPANDB - was: Module::Dependency 1.84

[Tim Bunce]

On Wed, Jul 12, 2006 at 03:03:14AM +0200, Tels wrote:
> -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)

> 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

A key point about those modules (other than Module::Dependency) is that they
don't work for private modules (the so called "Dark CPAN") nor for scripts.

Module::Dependency handles both (details changed to protect the guilty):

$ pmd_dump.pl adnetwork/www/cron/cv.pl
adnetwork/www/cron/cv.pl depended_upon_by: 
adnetwork/www/cron/cv.pl depends_on: strict File::Basename lib Env wConfig 
vConfig Churl::Log Churl::MyDBI Churl::Util

$ pmd_dump.pl Churl::MyDBI 
Churl::MyDBI depended_upon_by: www/cron/cv.pl www/cron/pub_login.pl
Churl::MyDBI depends_on: Exporter strict warnings Carp DBIx::DWIW 
File::Basename Sys::Syslog vars
Churl::MyDBI filename: clcyt/Churl/lib/Churl/MyDBI.pm


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

Or what module may be affected if I upgrade Foo::Bar.

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

Yes! But widen your horizon, and schema, beyond just CPAN.
I'd be interested in helping out and, if it works out, perhaps migrate
Module::Dependency to use it.

Tim.

Re: CPANDB - was: Module::Dependency 1.84

[Adam Kennedy]

Tels wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Moin,

On Wednesday 12 July 2006 03:13, David Golden wrote:

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.


Quoted:


B provides object-oriented access to the CPAN index,
using a collection of relatively common modules, and automates
entire process of fetching and accessing the index.


Uhm, no the DB should maybe be able to have a front-end that fills it from 
the CPAN index, but you should also be able to build a DB from a local 
file, if you so wish.


Well of course, and that's what it does.

If has a database structure with a DBIx::Class layer to the schema for a 
CPAN index, and it handily comes by default with modules to download the 
main CPAN index and stream it into the database.


If we wanted to add a different mechanism to populate the same database, 
that would be just fine. In fact, part of what I want is to create an 
equivalent of CPAN::Inject, to be able to build out a custom "modified 
CPAN" that also includes commercial modules.



The index is stored in a L database file, with an object
model implemented around it using L. To update the index,
the L class implements the logic to flush and reset
the database, fetch the index files, parse them, and repopulate the
database.


The DB backend shouldn't matter at all, it should be transparent and be 
switchable without any noticable change at the front.


Yep, right with you. Hence DBIx::Class.

Plus, I planned to
use YAML because it creates a _much_ less heavy overhead and dependency 
chain. Using SQLite or similiar is what really creates the problems with 
CPANTS - you cant just access the raw database without the front-end.


Erm, I'm not sure I get you here. The main problem with all the things 
that loads the index currently is that they tend to consume 50-100 meg 
of ram, and that's just the active index. Add in extra stuff and you're 
up into stupid amounts of ram quite quickly.


WithYAML, at least you could get at the data by other means. Of course for 
performance reasons it might not be good, but since premature optimization 
is the root of all evil, I'd say use YAML now, change when nec.


It's already necesary, based on the memory load. That's not to say you 
have to use SQLite to DISTRIBUTE or publish the data, just that when you 
access and manipulate it computationally, you do it via SQLite.


This method has worked spectacularly well in the JSAN code, which 
implements something very similar to what I'm heading towards. To do 
dependencies and so on, it just links an Algorithm::Dependency object 
into the DBIx::Class code, and there you have your full range of 
graph-math things, like dep chains (up and downstream) weights, etc.


Otherwise, the projects seem similiar in scope, except that I focus on the 
DB and let things like "download stuff" be done outside.


Whether that works out, uh I don't know. In any event I have quite a few 
ideas I'd like to try out and this proves to be fun to me. I hope it 
doesn't end upI have to implement other people ideas - thats too much work 
like :D


Have a look at just the database parts, which I've finished already from 
memory.


The bit that isn't finished is the complete "grab your CPAN.pm config 
and stream down all the files and populate the database".


Adam K