testing Pugs with Perl 6 modules
Darren Duncan
I wish to help out the development of Perl 6, initially running under
Pugs, by supplying test code of sorts, written in Perl 6, that we
would attempt to run under Pugs (and eventually Parrot) to ensure
that it works correctly with the subset of Perl 6 that I use.
Yesterday I was reading the newest Pugs missive on Perl.com, and read
the Pugs Apocryphon 1; I seem to remember reading a line that said
there was a collection of Perl code already under way that was used
for such testing of but on further reading I was unable to
re-discover the reference. This collection formed a "To Do" of
sorts, illustrating code that Pugs needed to support eventually, but
didn't necessarily support yet, and provided guidance towards further
Pugs development. I didn't get the impression that this "To Do" code
was in the Pugs distro, and that the distro only contained Perl 6
code that already was working.
Question 1: So where would I find the "To Do" code collection?
Related to this, my current working set of CPAN module contributions
(those modules started on or after January of 2003) has been designed
from the start with the intent that they be moved to Perl 6 / Parrot
as soon as possible, being among the very first useful modules
available on CPAN for Perl 6 / Parrot users. These are not modules
that were created only for Perl 5 and then moved to Perl 6 as an
after-thought. My Perl 5 versions are intended to be working
prototypes for the Perl 6 versions. They make use of simulations of
features that will be native to Perl 6 but that Perl 5 doesn't
support, such as compile-time declared and typed class/object
properties, and compile-time constant values.
The modules in question are "Locale::KeyedText", "SQL::Routine[|::*]"
and "Rosetta[|::*]" which are concerned with localization and
databases.
I intend that my main contribution towards tests for Perl 6 is to
actually produce the Perl 6 versions of the aforementioned modules,
and their test suites, as soon as possible. This code would be more
comprehensive or complicated by its nature than a typical test-only
suite, and we already know what kind of output the tests should
produce because it is what the tests in the Perl 5 version produce.
I will start off by making the Perl 6 version of Locale::KeyedText,
because that module is the simplest, the most rigorously defined, and
has the most thorough test suite of the lot. Once this module is
shown to be working under Pugs, I will next port SQL::Routine (the
next most mature module) and go on from there.
Given the Pugs road map, I suppose that none of my modules will work
until at least version 6.28, since they are object oriented. At the
same time, I don't do anything particularly fancy, so I probably
don't need the features pending subsequent major releases.
Considering the Apocryphon question on a CPAN for Perl 6 modules, I
will conform by initially naming my modules into the "Perl6::lib"
namespace; they will have the same names they do now but for that
namespace prefix. For example, my first module will be named
"Perl6::lib::Locale::KeyedText" v0.01 (which corresponds to the
upcoming Locale::KeyedText v1.02).
Question 2: Should I just upload my ports in Perl 6 to CPAN the usual
way, or do you have a special repository for "To Do" Perl 6 code that
you want me to stuff it into, or should I do both?
Question 3: What's the deal with this Kwid thing? Is this an
official replacement for Pod that I missed reading about, or is it
something temporary that is used with Pugs and will have to be
rewritten again later to Pod? I plan to port my docs as well as the
code, so I should know whether to do it in Kwid or Pod.
Question 4: If Perl 6 code is to start being released to CPAN now, is
there an already planned method for those distros to say the right
things in their Makefile.PL so that the existing automated CPAN
testers network can know to run them through Pugs? Or do we just
have to skip automated tests for now?
Thanks for any feedback and directions.
-- Darren Duncan
Stevan Little
I will take a stab at your questions.
On Mar 5, 2005, at 6:25 PM, Darren Duncan wrote:
> Question 1: So where would I find the "To Do" code collection?
The TODO code which you are referring too is actually in the Pugs
distro. If you grep the .t files you will find many todo_ok() and
todo_is() tests, which have been written based upon the current
Synopsis documents, but not yet implemented in Pugs. This basically
amounts to a very informal TODO list for Autrijus and the other
more-Haskell-inclinded perl6 folks.
> I intend that my main contribution towards tests for Perl 6 is to
> actually produce the Perl 6 versions of the aforementioned modules,
> and their test suites, as soon as possible.
This would be an excellent way of contributing, but I will warn you
(since I have tried to do this myself with my own CPAN modules) that
much of what you will probably need is not only un-implemented, but
possibly not even specified by the perl 6 language folks. Keep in mind
that perl 6 as a language is still very much a moving target, and the
spec is not finished yet.
However, this should not discourage you from contributing. Example code
is also a driving force behind the development (metaperl and his work
with Junctions is a prime example of this). I view them as being
something akin to integration tests, since they typically combine a
number of features in one script. Whereas the test work tends to be
features in isolation. Any contributions you want to give in this
department would surely be appreciated, whether is be a complete port
of your module, or something smaller.
> Considering the Apocryphon question on a CPAN for Perl 6 modules, I
> will conform by initially naming my modules into the "Perl6::lib"
> namespace; they will have the same names they do now but for that
> namespace prefix. For example, my first module will be named
> "Perl6::lib::Locale::KeyedText" v0.01 (which corresponds to the
> upcoming Locale::KeyedText v1.02).
This is currently the rough plan as I understand it. I think that
Autrijus currently has the perl6 @*INC set up to start looking in
Perl6/lib/ first. We also only currently have "require", and no "use"
feature, so many things may change on this in the future.
> Question 2: Should I just upload my ports in Perl 6 to CPAN the usual
> way, or do you have a special repository for "To Do" Perl 6 code that
> you want me to stuff it into, or should I do both?
My suggestion is too put them in the examples/* directory in the Pugs
distro. When they (and Pugs) hit a certain maturity point, you can move
them over to CPAN then.
> Question 3: What's the deal with this Kwid thing? Is this an official
> replacement for Pod that I missed reading about, or is it something
> temporary that is used with Pugs and will have to be rewritten again
> later to Pod? I plan to port my docs as well as the code, so I should
> know whether to do it in Kwid or Pod.
Autrijus said recently that he intends Pugs to support both Kwid and
Pod. If you want to write it in Kwid, go ahead. If you prefer POD go
ahead. Although, this is how things were on friday afternoon (EST),
they may very well have changed since then :)
> Question 4: If Perl 6 code is to start being released to CPAN now, is
> there an already planned method for those distros to say the right
> things in their Makefile.PL so that the existing automated CPAN
> testers network can know to run them through Pugs? Or do we just have
> to skip automated tests for now?
Good question. I am not sure if we are far enough along to even start
thinking about those details, but I suppose it's never to early to
start.
Darren, I hope I have answered some of your questions. My suggestion is
to come and visit us at #perl6. The development is currently going on
almost 24 hours a day on a worldwide scale, and is actually quite a lot
of fun, and we can always use more help.
- Steve
Autrijus Tang
> I wish to help out the development of Perl 6, initially running under
> Pugs, by supplying test code of sorts, written in Perl 6, that we
> would attempt to run under Pugs (and eventually Parrot) to ensure
> that it works correctly with the subset of Perl 6 that I use.
Wonderful! :-)
As Stevan has answered your quetions quite well, I'd only take Q4:
> Question 4: If Perl 6 code is to start being released to CPAN now, is
> there an already planned method for those distros to say the right
> things in their Makefile.PL so that the existing automated CPAN
> testers network can know to run them through Pugs? Or do we just
> have to skip automated tests for now?
We at #perl6 had brainstormed on that question today; see my journal
for a writeup: http://use.perl.org/~autrijus/journal/23524
Basically, to avoid disrupting CPAN in general, and consider Pugs'
current immaturity in supporting the P6 module spec (with "long names"
and advaced versioning), it is recommended that you commit your
modules work under the Pugs tree's ext/Locale-KeyedText/ directory
for now. If that sounds okay with you, I'll send you an invitation
mail for you to become a committer.
Eventually we need to figure out a way to distribute P6 modules either
as a prefixed distname on CPAN (using Module::Install::Perl6 to
correctly run tests with pugs/perl6 and install into the correct path),
adopting either the Perl6-lib-* prefix or the shorter p6-* prefix;
another possibility is to set up a dedicated CPAN subdirectory to
host P6 modules. This all needs some discussion with CPAN workers
and Perl 6 design team, and until that is settled, committing into
the Pugs tree sounds like the safest bet.
I'll update the Apocrypha after some more discussion on #perl6 and a
better-worded consensus is reached. :)
Thanks,
/Autrijus/
Darren Duncan
and Autrijus; thanks to both of you for those. I also read parts of
the March 6 IRC log where concerns I raised in my 4th question was
discussed.
I'll start showing up on IRC soon, though I have to find a good Mac
OS X client for IRC first (I'm still used to email as a primary
communication medium).
At 1:52 AM +0800 3/7/05, Autrijus Tang wrote:
>We at #perl6 had brainstormed on that question today; see my journal
>for a writeup: http://use.perl.org/~autrijus/journal/23524
>
>Basically, to avoid disrupting CPAN in general, and consider Pugs'
>current immaturity in supporting the P6 module spec (with "long names"
>and advaced versioning), it is recommended that you commit your
>modules work under the Pugs tree's ext/Locale-KeyedText/ directory
>for now. If that sounds okay with you, I'll send you an invitation
>mail for you to become a committer.
About commit access, yes please! I still have to learn SVN, though I
don't expect that to take long. Should have something uploaded to
ext/Locale-KeyedText/ within 2 weeks. Meanwhile, I will await that
committer invitation email.
I will not upload anything Perl 6 related to CPAN, but put it in the
Pugs tree instead.
>Eventually we need to figure out a way to distribute P6 modules either
>as a prefixed distname on CPAN (using Module::Install::Perl6 to
>correctly run tests with pugs/perl6 and install into the correct path),
>adopting either the Perl6-lib-* prefix or the shorter p6-* prefix;
>another possibility is to set up a dedicated CPAN subdirectory to
>host P6 modules. This all needs some discussion with CPAN workers
>and Perl 6 design team, and until that is settled, committing into
>the Pugs tree sounds like the safest bet.
>
>I'll update the Apocrypha after some more discussion on #perl6 and a
>better-worded consensus is reached. :)
I'll give some input on this in a separate email. The issue is dear
to me, in a manner of speaking, so expect lots of input.
>This would be an excellent way of contributing, but I will warn you
>(since I have tried to do this myself with my own CPAN modules) that
>much of what you will probably need is not only un-implemented, but
>possibly not even specified by the perl 6 language folks. Keep in
>mind that perl 6 as a language is still very much a moving target,
>and the spec is not finished yet.
Yes indeed. I looked over Locale-KeyedText again and several of the
things I need include basic class support, basic regexp support, and
the ability to determine programmatically whether a class is already
loaded, and load it if not, prior to trying to use it. That and
multi-dimensional hashes and arrays. And basic try/catch. I won't
actually be throwing exceptions in Locale::KeyedText though. I do
lots of that later in SQL::Routine; and then I need to be able to
throw exceptions that are objects.
>However, this should not discourage you from contributing. Example
>code is also a driving force behind the development (metaperl and
>his work with Junctions is a prime example of this). I view them as
>being something akin to integration tests, since they typically
>combine a number of features in one script. Whereas the test work
>tends to be features in isolation. Any contributions you want to
>give in this department would surely be appreciated, whether is be a
>complete port of your module, or something smaller.
You're right. My tests are purely integration tests, not language
feature in isolation tests (though I may throw a few of those in too
if necessary).
>This is currently the rough plan as I understand it. I think that
>Autrijus currently has the perl6 @*INC set up to start looking in
>Perl6/lib/ first. We also only currently have "require", and no
>"use" feature, so many things may change on this in the future.
Whatever. I *never* used import()/Exporter anyway and consider that
to be a dirty feature. The main thing I like is to be able to
include/compile modules at run-time, as plain "require" does.
>Autrijus said recently that he intends Pugs to support both Kwid and
>Pod. If you want to write it in Kwid, go ahead. If you prefer POD go
>ahead. Although, this is how things were on friday afternoon (EST),
>they may very well have changed since then :)
Since I'm throwing my code in the Pugs distro, I'll keep things
simple and skip moving over any of my Pod for now, since it has less
need to stand on its own. I will move just the code over to Perl 6,
and include a comment to look at the Perl 5 version for the user
documentation. Documentation will be copied to the Perl 6 version
when there is good reason to do so.
I also have some input of my own concerning issues of CPAN handling
of Perl 6 modules and the best way to organize the Perl 6 module name
space. But those comments will go in a different email thread, due
on p6c within an hour or so.
Thank you. -- Darren Duncan
Yuval Kogman
> I'll start showing up on IRC soon, though I have to find a good Mac
> OS X client for IRC first (I'm still used to email as a primary
> communication medium).
I'm very happy with colloquy (http://colloquy.info). You can
probably get bitchx from fink if you like that kind of stuff. Maybe
more CLI irc clients. There's also mozilla chat, which comes as part
of mozilla or as a plugin to firefox.
See you there!
--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!!
Darren Duncan
1. I completed the committer registration with the Pugs repository.
1.1 No problems per se, but the new member agreement was written in
Chinese so I couldn't read it (the Google translate tool wasn't much
help); so I just clicked through it.
2. Downloaded and installed the Colloquay IRC client for the first
time, and it works great; I was able to get into IRC and chatted
there from 5-12pm or so last night (GMT -8).
2.1 Thanks for both of the IRC client suggestions.
3. Downloaded and installed svn for the first time, with no problems.
4. Downloaded and installed GHC for the first time, no problems.
5. Created a local working folder for Pugs and fetched the latest
version using svn, for the first time, no problems.
6. Detected problems in and fixed and committed the MAKEFILE and
MAKEFILE.SKIP files; committed r486 and r488.
6.1 Apparently "make manifest" is your friend; saves on manual updates.
6.1.1 You still update the .SKIP manually, the above respects it.
7. The standard make procedures result in "all tests passed" though
afterwards I got an error about "v6.0.0 expected, this is only
v5.8.1".
8. Had an IRC chat on names for Perl 6 modules; I'll post something
about this to the email list in a little while, following what came
out of that (suggesting the creation of a FAQ-type or standards
committee recommendation type document).
Finally, I expect to add+commit the first Locale::KeyedText for Perl
6 in a few days.
-- Darren Duncan