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
