Re: Module submission Module::Signature
On Tue, Aug 13, 2002 at 04:44:23PM +0200, Perl Authors Upload Server wrote: > The following module was proposed for inclusion in the Module List: > modid: Module::Signature > DSLIP: cdpfp > description: Module signature file manipulation > userid: AUTRIJUS (Autrijus Tang) > chapterid:2 (Perl_Core_Modules) I chose the Module:: namespace instead of ExtUtils::, because of the similarity of this and existing Module::* modules (::Dependency, ::Info, ::MetaInfo) seems to be greater than the ExtUtils:: bunch. > rationale: > Module::Signature adds cryptographic authentications to CPAN > distribution files, via the special SIGNATURE file. And the ::Signature portion directly correspond to the SIGNATURE file; in earlier discussion it was MAKEFILE.digest, but that name does not reflect its nature well, looks slightly worse on 8.3 (MAKEFILE.dig vs. SIGNATUR), and does not have a standard extension filename. A SIGNATURE files looks like below: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 SHA1 82795f8f0e77ec3d85a6770395652fa382695930 Changes SHA1 7a7d8d78157f0a02e8db2f8f0ca4c4a87cd0cb6e MANIFEST SHA1 1f886c22be243d3e41b56270c30ca26591bc37e5 Makefile.PL SHA1 96619d20efb174d4ec51a1d4f6facaa68c35daa9 README SHA1 d6f45aa0677174c90b1049bc0108c30b9fbd5a8a Signature.pm SHA1 39d5b47a33a3e502d8423169f4dec2ab37e07f29 TODO SHA1 9ade089dd3bc5bf67be2292aee2fb9435a00ca17 bin/cpansign SHA1 b173929a459fdfd058502ca736906b5d6db5e529 t/1-basic.t -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9WRIPtLPdNzw1AaARAo2RAJ9IOm7uTxlddoEfgxZBicsYbQHI3QCffwad yHiYAbGeKICuHlGoNZkJs3Q= =0QdN -END PGP SIGNATURE- The 'cpansign' utility that comes with the distribution may be used to sign a distribution, as well as verifying it before running Makefile.PL. Comments welcome. Thanks, /Autrijus/ msg12000/pgp0.pgp Description: PGP signature
Re: Module submission Encode::HanExtra
On Thu, Aug 01, 2002 at 03:59:20AM +0200, Perl Authors Upload Server wrote: > The following module was proposed for inclusion in the Module List: > modid: Encode::HanExtra > rationale: > Perl 5.7.3 and later ships with an adequate set of Chinese > encodings. However, the numbers of Chinese encodings are staggering, > and a complete coverage will easily increase the size of perl > distribution by several megabytes; hence, this CPAN module tries to > provide the rest of them. This module was submitted for modlist a while ago, along with Acme::ComeFrom, Encode::HanConvert, ExtUtils::AutoInstall, HTML::FromANSI, Lingua::Sinica::PerlYuYan, Locale::Maketext::Lexicon and Locale::Maketext::Fuzzy. Is there any extra information I'd need to supply for them to be included in the module list? :-) Thanks, /Autrijus/ msg12001/pgp0.pgp Description: PGP signature
Re: This is getting ridiculous. . .
On Mon, Mar 24, 2003 at 10:36:25PM -0800, Robert Spier wrote: > The idea comes up periodically, and I mention it to someone about > every six months, but it is always shot down, usually with some > comment having to do with inertia. At OpenFoundry (http://upload.openfoundry.org/) here, we are beginning to implement exactly the same thing, namely changing the apply_mod URL to point to a specific RT queue, where the application form will be turned into a ticket. That queue has a special OnResolve magic which will add the namespace into the modlist, as well as creating associated PAUSE, MT, CVS, Sympa, RT queues and permissions for that module, by POSTing back to those services' admin interface, and exports a REST interface from RT for ACL checks. I'll be happy to submit the changes back to the PAUSE svn (after ANDK's review, of course) once we finished the unit test cycle here. (FWIW, OpenFoundry is a Taiwan Government-funded initiative launched this month; it will provide sf.net-like services to Chinese free software projects. My company has been selected as the contractor for implementing the underlying loosely-coupled, PAM-based services, codenamed "CPAN-in-a-box".) > We would be doubleplushappy to host this on the perl.org RT instance. I would be glad to contribute my RT scrips and modules toward that direction. Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission POE::Component::Win32::Daemon
On Tue, Mar 25, 2003 at 07:38:45PM +0100, Perl Authors Upload Server wrote: > modid: POE::Component::Win32::Daemon (Cc'ing the POE people at [EMAIL PROTECTED]). I was under the impression that POE::Component::* modules are categorized by functionality, not by platform; so, maybe POE::Component::Daemon::Win32 is a better choice here, so there can be POE::Component::Daemon::Unix in the future. What do you think? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Language::Chef
On Tue, Mar 25, 2003 at 10:49:33PM +0100, Perl Authors Upload Server wrote: > The module is an interpreter (and kind of a chef2perl compiler) for > the Chef programming language. Hence the Language:: namespace. Currently the Language:: section in modlist says: Language:: ::BasicadpO? Implementation of BASIC ::ML cdpf? Implementation of ML ::PGForth i ? Peter Gallasch's Forth implementation ::Prolog anpO? An implementation of Prolog JACKS ::StylecdcOa Interpreter/Compiler for the Style Language ::VBParser adp?g Visual Basic 6 source parser and your DESCRIPTION says: I needn't mention that using it in production environment, heck, using it for anything but entertainment ought to result in bugs and chaos in reverse order. Hence it is my opinion that Acme:: may fit your module's spirit more; would you consider putting it into the Acme:: namespace, joining the rank of Acme::Ook, Acme::Brainfuck, and Acme::Turing? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Simulation::Particle
On Tue, Mar 25, 2003 at 10:40:21PM +0100, Perl Authors Upload Server wrote: > The following module was proposed for inclusion in the Module List: > > modid: Simulation::Particle > DSLIP: RdpOp > description: Simulate particle dynamics > userid: SMUELLER (Steffen M?ller) > chapterid: 23 (Miscellaneous_Modules) As we just got the Physics:: toplevel, do you think that Physics::Particle (or Physics::Particles) will fit your module's idea as well? To me that name helps to clarify the module's purpose, since one can arguably simulate morphing of grammatical 'Particles' (preposition, conjunction, interjection) as well. :) Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Tie::TkListbox
On Tue, Mar 25, 2003 at 10:23:44PM +0100, Perl Authors Upload Server wrote: > Working with Tk::Listbox today, it bothered me that I could not > access the listbox items more easily. Hence I created a tied wrapper > to access the data in a Tk::Listbox widget. Nice idea. > It is possible to tie arrays to Tk::Scrolled widgets (and others) > as well. This statements suggests that, rather than creating any number of Tie::TkFoo modules, maybe we should organized them into the Tie::Tk namespace: Tie::Tk::Listbox Tie::Tk::Scrolled ... This way it is clear that Tie::Tk::* corresponds to the Tk::* namespace, so we can list them under the UI chapter without introducing much confusion. Does that sound reasonable to you? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Simulation::Particle
On Wed, Mar 26, 2003 at 11:59:27AM +0100, Steffen Mueller wrote: > >As we just got the Physics:: toplevel, do you think that > >Physics::Particle (or Physics::Particles) will fit your module's idea as > >well? > > Just as well, yes. There is, however, a Simulation:: namespace, too, so > I was not proposing a new namespace. It may be in CPAN but it's not included in the official module list. :-) > >To me that name helps to clarify the module's purpose, since one can > >arguably simulate morphing of grammatical 'Particles' (preposition, > >conjunction, interjection) as well. :) > > That's something I did not think of. I will gladly follow your > suggestion and modify the module's namespace, reupload under the new > name, remove the old distribution from CPAN, and then reregister. Most excellent. I'll go ahead and approve that namespace. Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Simulation::Particle
On Wed, Mar 26, 2003 at 10:58:22PM +0800, Autrijus Tang wrote: > > Just as well, yes. There is, however, a Simulation:: namespace, too, so > > I was not proposing a new namespace. > > It may be in CPAN but it's not included in the official module list. :-) Gawd, this is embarrasing. I made comments based on an outdated module list from www.cpan.org: % HEAD http://www.cpan.org/modules/00modlist.long.html |grep Modified Last-Modified: Tue, 27 Aug 2002 23:40:25 GMT I see now that Simulation::Automate and Language::Ook are indeed included now. However I'm glad that you agreed on my suggestions. Sorry and thanks! > > That's something I did not think of. I will gladly follow your > > suggestion and modify the module's namespace, reupload under the new > > name, remove the old distribution from CPAN, and then reregister. > > Most excellent. I'll go ahead and approve that namespace. Even more embarrasingly, I see now that Arthur already did that. Oh well. :-) Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission OODoc
On Wed, Mar 26, 2003 at 06:13:24PM +0100, Arthur Bergman wrote: > >Last week I tried to get response from this modules list, but there > >was none. I know you are all very busy, but I can't wait too much > >longer. Therefore, I now ask for the name space officially. > > I am not so sure I like the namespace, it feels kind of vague, can't it > fit under a descriptive existing top level namespace? > (OTOH I am not sure why I think it's vague) I think Pod::OO or Pod::OODoc is less vague and more helpful for what this module does. As MARKOV states: POD is a visual markup language, and therefore information is lost about what is being documented. My syntax adds keywords like "=method", "=function", and "=overload" to what POD has. It helps a lot with doumenting named parameters. and it seems to me that this implies that OODoc is an extension that inherits the POD syntax, instead of something entirely different. I note that MARKOV has these comments on the Pod::OO namespace: * POD::OO, but it is not really POD although it has some simularities. So: it is not an Object Oriented POD at all. But as it conforms to the POD specification's syntax, one can argue that it is still POD, only enhanced. From L: Pod content is contained in Pod blocks. A Pod block starts with a line that matches , and continues up to the next line that matches "m/\A=cut/" -- or up to the end of the file, if there is no "m/\A=cut/" line. ... A Pod parser may allow a way for particular applications to add to the above list of known commands, and to stipulate, for each additional command, whether formatting codes should be processed. Personally, the name 'Pod::OO' sounds much more encouraging for other module authors to try on (since it implies that it is compatible with the POD syntax). Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Simulation::Particle
On Wed, Mar 26, 2003 at 05:21:11PM +0100, Arthur Bergman wrote: > >I see now that Simulation::Automate and Language::Ook are indeed > >included now. However I'm glad that you agreed on my suggestions. > >Sorry and thanks! > > Should we try and get Language::Ook to move? I feel rather bad about revoking existing namespaces -- it feels too much like censoring stuff. :-) Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Tk::autobind
On Thu, Mar 27, 2003 at 03:27:02AM +0100, Perl Authors Upload Server wrote: > > modid: Tk::autobind > > Looks at the -text and -underline options for a Tk widget and > produces a binding with the indicated character and the ALT > modifier. This is especially useful under MSWindows. Is there a specific reason to use the lower-case 'autobind'? Normally, CPAN modules are upper-cased, because lower case letters are reserved for pragma-like modules. So, will Tk::AutoBind or Tk::Autobind work as well for your module? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission OODoc
On Thu, Mar 27, 2003 at 08:11:04AM +0100, Mark Overmeer wrote: > > Personally, the name 'Pod::OO' sounds much more encouraging for other > > module authors to try on (since it implies that it is compatible with > > the POD syntax). > > That's one good point for POD::OO. That's probably the reason that C++ > is named that way: to hide the huge step they where actually making away > from C. It may work better from a sales point of view, in the beginning, > but outsiders always ask: "you are a C programmer, can you debug my C++ > program?". Ah, but by now, the huge impact implied by the name "::OO" should be quite well understood by anybody not living in caves for the past decade. And, I'd like to know, can a POD author debug an OODoc document? :) Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission OODoc
On Thu, Mar 27, 2003 at 05:56:38PM +0100, Johan Vromans wrote: > Hmm. Slightly simplified, perl ignores everything between (and > including) a line that starts with '=', and a line that reads '=cut'. > POD is one application that makes use of this to allow embedded > documentation in perl programs. This imho is an oversimplification. POD is formally defined in the perlpodspec document, and implemented by a myriad of parsers. > One can argue whether the actual format of POD is part of the perl > language. It may have started this way, but not anymore -- extensions of POD has been put to use on writing books, slides, etc, which has nothing to do with the perl interpreter. > Mark's document system uses the same technique to embed > documentation-oriented information in perl programs. I see no reason > why this should be called POD::OO or something alike, unless it is a > clear extension of POD. Which is, if I understand Mark correctly, not > the case. Is there anything in POD explicitly forbidden or incompatible with OODoc? If such conflicts necessarily exist, I'd be happy to rescind my disagreement. Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission POE::Component::Win32::Daemon
On Thu, Mar 27, 2003 at 02:22:43PM -0800, Peter Guzis wrote: > I don't have a preference one way or another. My original thought was > to keep it consistent with the naming of the base module > (Win32::Daemon) and Win32::* modules in general. I'm open to > suggestions. If so, can you submit another request on POD::Component::Daemon::Win32 on PAUSE? :-) Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission OODoc
On Fri, Mar 28, 2003 at 08:16:29AM +0100, Mark Overmeer wrote: > I don't think that the POD parser can handle this > > =docbook > > > > > > > =cut Well in fact, sure: =for docbook =cut For example, pod2html already recognizes "=for html" blocks. The =begin, =end and =for chunks in POD are designed to implement the phase 1) and 3) -- all it doesn't do is inheritance solving, which is what the OO part does. > There is no parser for that in my suite eirther, but it can easily be > added to phase 1, and then phase 2 and 3 stay the same. Different > packages within a module can even use different parsers! Exactly the same as =for/=begin/=end, unless I'm mistaken, and I'd be willing to be corrected. Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission OODoc
On Fri, Mar 28, 2003 at 11:15:00AM +0100, Johan Vromans wrote:
> Technically, this is true. But is this POD? Would you call this C:
>
>int foo(int bar) {
> _asm("...");
> _asm("...");
> _asm("...");
> _asm("...");
>}
Why, of course yes. There are plenty of perl programs nowadays
containing nothimg more than a couple declarations and Inline::C blocks,
and they are still perl.
> The 'danger zone' for Mark's idea is to use POD-like stuctures, which
> may people trick into thinking they're dealing with POD while in fact
> they're not. If running OODF through a POD processor produces anything
> useful, people will think it _is_ POD.
Correct. If that is the design goal, then I still think Pod::OO is the
better name for it.
> Along the same lines, the embedded directives like B<>, I<> are wrong
> (or at least dangerous) and should be replaced with more descriptive
> directives.
Depends on Mark's objective. Again, if he allows these PODesque
mark-ups (especially L<>) in OODoc, many people will apply the "if it
looks like POD, and it smells like POD..." argument.
> If I were Mark, I would leave POD completely and go for something new.
>
> @FILE Java Call In Implementation |
> @IN_MODULE FF
> @LOCAL
> @FUNC |
> @COPYRIGHT
> @OWNER
> @HISTORY
> @PR 0 | 981001 | e03371 | 7.2.04 | wwo | Initial version taken from the
> prototype
> @COMMENTS
> @XREF
If Mark goes with this route, then OODF or OODOC or MarkDoc are equally
applicable, since it's something that has no relation with Pod, and
(to borrow Mark's C => C++ metaphor) warrants a completely different
name like "Java" did. So the question is... What does Mark wishes to
achieve: syntactical compatibility, or radical departure?
Thanks,
/Autrijus/
pgp0.pgp
Description: PGP signature
Re: Module submission OODoc
On Fri, Mar 28, 2003 at 12:08:22PM +0100, Mark Overmeer wrote: > I think were are getting into a syntax debate for one of the > documentation parsers which is implemented for OODoc. Debates > about syntax are about as subjective as those about coding styles. I did not know that you plan to implement drastically different document parsers other than POD, so now I see that OODoc is indeed better suited to the large-scaled templating framework you have in mind. Since it would support inclusion, inheritance and pluggable parsers and preprocessors, let's call it... Template Toolkit! :-) (But seriously, did you look into using TT2 to implement the backend of your parser and processing engine?) > To come back to remarks so far: the name POD::OO is not honest to what > the module does, but might be easier to "sell" to new users. I have no > objections to a different name than OODoc, as long as it contains the > real power of the module. After your remarks that raised your module to the 'software framework' level required by a top-level CPAN name, I see that OODoc is an adequate name and am willing to approve it, if no better suggestions comes up in a couple days. Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: I'm taking over XML::TokeParser, mmkay ;)
On Fri, Mar 28, 2003 at 03:36:45AM -0800, DH wrote: > I tried contacting you before but you didn't write back > (and a few of the messages bounced). [snip] > If anyone has any objections, speak up. Can you give an account of how many times you tried reaching its author about this matter, and the date of those attempts? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission POE::Component::Win32::Daemon
On Fri, Mar 28, 2003 at 12:30:28PM +0800, Autrijus Tang wrote: > If so, can you submit another request on POD::Component::Daemon::Win32 > on PAUSE? :-) Err, I meant POE::Component::Daemon::Win32, of course... :) Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: naming advice: module for filtering scripting out of HTML
On Fri, Mar 28, 2003 at 05:53:08PM +, Nick Cleaton wrote: > I'm working on a module for filtering scripting constructs out of > HTML, leaving as much non-scripting markup in place as possible. Cool idea. :-) > I'm thinking HTML::XSSFilter, as it's an HTML filter primarily > aimed at fighting Cross Site Scripting (XSS). HTML::DeCSS, then? ;) Just kidding. I think the current name is pretty good, but maybe HTML::StripScripts is more descriptive for somebody unfamiliar with the XSS abbreviation. Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission POE::Component::Win32::Daemon
On Tue, Mar 25, 2003 at 07:38:45PM +0100, Perl Authors Upload Server wrote: > modid: POE::Component::Win32::Daemon (Oops, really cc'ing the POE people at [EMAIL PROTECTED]). I was under the impression that POE::Component::* modules are categorized by functionality, not by platform; so, maybe POE::Component::Daemon::Win32 is a better choice here, so there can be POE::Component::Daemon::Unix in the future. What do you think? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission DBIx::Perform
On Sat, Mar 29, 2003 at 11:49:37PM +0100, Perl Authors Upload Server wrote: > I know of no other implementation of a utility like this anywhere. > Of course, I don't get out much. Some googling revealed that the Informix technology is trademarked and often spelt as PERFORM, as 'Perform' is usually associated with a common verb. What do you think about DBIx::PERFORM or DBIx::Informix::Perform to reduce ambiguous readings? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Function::ID
On Sun, Mar 30, 2003 at 05:49:19AM +0200, Perl Authors Upload Server wrote: > I suggested this module on comp.lang.perl.modules about a week ago, > and the response was positive. I did a search around CPAN and didn't > find any similar modules. I did see that a top-level Function:: name > exists Strange; I did not see that. % zgrep 'Function::' 03modlist.data.gz | wc 0 0 0 Although Schwern has a Function::Override, it's not included in the official CPAN module list. Will, say, Tie::FunctionID fit your module's spirit as well? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: RFC - reserving a namespace hierarchy
On Sat, Mar 29, 2003 at 06:58:48PM -0800, Darren Duncan wrote: > Specifically, while Perl itself does not make any implications that > "Foo" is related to "Foo::Bar" or "Foo::Bar::Baz", I would appreciate > it if the official module list recognized "Rosetta::*" as a reserved > name space hierarchy which I control. This is easily achieved by making your intention well-known on the modules@ list, as you have done now, so when future requests on Rosetta::* crops up, we can inform the submitter to get in contact with you first. > By contrast, if anyone wants to make unofficial extensions to the > hierarchy, I recommend naming the module something outside of that > namespace. For example, they could use a common prefix of > "RosettaX::*". Sure; you can clearly indicate this wish in the Rossetta documentation. > 1. Given that it is normal CPAN Module List policy that frameworks > each have their own self-named name space rather than using a generic > space like "CGI" or "Text", is it implicitely recognized already that > any modules whose names start with the module name in the form > "FrameworkName::*" are under the control of the framework author, or > is it assumed that all names are free for all for new modules by > default if the name describes the module's purpose? According to my understanding, the author that proposes the original FrameworkName::* do have a socially-accepted control over the namespace under that toplevel. However, this only regulates the official module list, and does not impede on uploading of off-list modules. > 2. If control is not implicitely recognized, what are the best and/or > most authoratative ways to make it known that I would like people to > speak with me first before uploading a module whose name is > "Rosetta::*"? The most authoratative way is to state it clearly and strongly in Rosetta's README and documentation, which I assume would've been read by anybody working on Rosetta::* extensions. > 3. Are there any plans for the future that would make registering a > framework for CPAN as easy as an individual module? For example, if > someone wanted to register a "Foo" framework, then they would only > have to upload modules like "Foo::Bar" and "Foo::Baz", which share a > prefix of the framework name, but they would not need to include an > actual module "Foo" if that module would have no purpose. You can already do this by registering the toplevel namespce first. > I think that implementing this idea would require an update to the > CPAN indexing mechanism, so that if someone clicked on a registered > module/framework name in the main directory, it would show a module > listing for the framework, or otherwise a file specified in a manifest > or something, if there is no individual module with the name of the > framework. Is this feasable, or would it be beyond what CPAN is > intended to be doing? This is already the case on search.cpan.org. For example, whilst there is no I18N.pm around, one can nevertheless click on http://search.cpan.org/modlist/Internationalization_Locale/I18N and see all modules that have the I18N prefix. Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Exporter::Tidy
On Sun, Mar 30, 2003 at 12:49:16AM +0100, Perl Authors Upload Server wrote: > Note: pause wants me to put this in chapter 2. I don't think I'll > ever fully understand pause :) Although I have approved your namespace and assigned it to chapter 3 according to your wish, I'd like to invite you to consider re-listing it under chapter two, using PAUSE's "Edit Module Metadata" interface. The reason is that there are currently four Exporter modules listed in chapter 2: http://search.cpan.org/modlist/Language_Extensions and none of which are in chapter 3: http://search.cpan.org/modlist/Development_Support Personally, I can argue both ways about where should Exporter::Tidy belong, but for users looking at module list, they will probably be surprised when they do not find your module in chapter 2. This is merely an encouragement, not a demand -- if you really wish your module to continue reside in chapter 3, then it will be so. Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Function::ID
On Sun, Mar 30, 2003 at 11:37:43AM +0200, Arthur Bergman wrote: > I think Tie::FunctionID is wrong since the fact that the variables are > tied is in this case implmentation specific and not function specific. Point. Devel::FunctionID, then? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Text::Flowchart::Lingua
On Sun, Mar 30, 2003 at 01:40:59PM +0200, Perl Authors Upload Server wrote: > modid: Text::Flowchart::Lingua "Lingua" denotes a human language on CPAN. Try: Text::Flowchart::Script Text::Flowchart::Macro or something like that. Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission again
On Sun, Mar 30, 2003 at 03:09:10PM +0200, [EMAIL PROTECTED] wrote: > Note that the module is "again.pm". "again" in the subject is not to > indicate that it is yet another submission :) Can you differentiate your module with Module::Reload, Apache::Reload, Module::Reload::Selective? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission again
On Sun, Mar 30, 2003 at 07:22:48PM +0200, [EMAIL PROTECTED] wrote: > In my opinion, again is more perlish. Especially because of its > pragma-like name (compare C, C, C). It is also confusing: use Module::Name; use again 'Module::Name'; If I know nothing about your module, I'd expect line two to reload Module::Name unconditionally. But maybe it's just me. Arthur? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission CGI::Kwiki
On Mon, Mar 31, 2003 at 01:15:11AM +0200, Perl Authors Upload Server wrote: > The following module was proposed for inclusion in the Module List: > > modid: CGI::Kwiki > DSLIP: cdpOp > description: Create an extendible Wiki in minutes How about: description: Quickie Wiki builder or something that contains the Q-word, so that users can grok the pun? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Function::ID
On Sun, Mar 30, 2003 at 02:41:06PM +0200, Arthur Bergman wrote: > >Point. Devel::FunctionID, then? > > I guess that would work. Roode, what do you think about it? :) Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission DBIx::Informix::Perform
On Mon, Mar 31, 2003 at 05:19:01PM +0100, Tim Bunce wrote:
> I believe there is no need to "clarify" trademark issues in module
> names. (In the same way that domain names that include a tradename
> don't have to include the owner of the trademark.) All that's
> needed is for the module *documentation* to clarify this (README + pod).
Indeed. To quote my original mail:
Some googling revealed that the Informix technology is trademarked and
often spelt as PERFORM, as 'Perform' is usually associated with a common
verb.
I now see that it is ambiguous -- I meant
({trademarked-as + often-spelt-as} PERFORM)
instead of
(trademarked) and (often spelt-as PERFORM)
Pardon my suboptimal English. :(
The original intent is to advice against using the common verb 'Perform',
and instead either capitalize it (as an abbreviation or proper name), or
qualify it somehow, by prefixing it with ::Informix.
It is true that DBIx::Informix will look like DBD::Informix-specific.
However I cannot easily think of a better name.
Thanks,
/Autrijus/
pgp0.pgp
Description: PGP signature
Re: Module submission DBIx::Informix::Perform
On Mon, Mar 31, 2003 at 09:09:29PM +0100, Tim Bunce wrote: > It's up to [EMAIL PROTECTED] to avoid it setting any precedents. I mistakenly looked at DBIx::OracleSequence and DBIx::MSSQLReporter in the module list and thought that it's okay for DBIx::Informix::Perform to go in; now I see that, following the same naming convention, maybe it should be called DBIx::InformixPerform or something else. I sincerely apologize for the hasty approval, and will wait longer for people to feedback in the future. Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Math::ES
On Mon, Mar 31, 2003 at 11:37:01PM +0200, Perl Authors Upload Server wrote: > The following module was proposed for inclusion in the Module List: > > modid: Math::ES > DSLIP: bdpOp > description: Evolution Strategy: genetic optimizer > > Almost everybody knows GAs, genetic algorithms, but Evolution > Strategies (ES) are rather unknown, although they have been > developped simulataneously. If it is relatively unknown, then the user probably can't figure out what ES means. Maybe Math::EvolutionStrategy or Math::Evolution? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission DBIx::Informix::Perform
On Mon, Mar 31, 2003 at 09:40:17PM -0800, Eric C. Weaver wrote: > So, what's the official word from the modules-keepers? ::Informix:: or not? The official word is: keep the DBIx::Informix::Perform namespace with our blessing, and please accept my personal apology for letting you be troubled with the post-hasty-decision discussions. Note that at no point during the discussion do Tim nor I suggest the approved namespace to be changed -- we're merely discussing how similar requests to be handled in the future. > Eric Weaver > grumpy developer thereof Again, I'm sorry. Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Config::Merge
On Tue, Apr 01, 2003 at 08:41:13AM +0200, Perl Authors Upload Server wrote:
> Config::Merge merges configuration from at most three sources.
Is the maximum number of three an arbitary decision, or required by
your design?
> application may allow users to define configuration in a file, but
> you also have set predefined (default) configuration. At the end you
> want single configuration by merging them with a certain precedence.
> This module will do just that.
What format of config does it take?
> Additionally, Config::Merge provides internal parser for convenient
> and historical reason, but allows users to provide external parser
> via CODE reference to suit their need.
Can you differentiate your module from this?
use Config::General;
my %merged = (
ParseConfig('file1.cfg'),
ParseConfig('file2.cfg'),
ParseConfig('file3.cfg'),
);
Thanks,
/Autrijus/
pgp0.pgp
Description: PGP signature
Re: Module submission DBD::google
On Tue, Apr 01, 2003 at 06:14:35PM +0200, Perl Authors Upload Server wrote: > modid: DBD::google Why the lowercase? Most DBD:: drivers are properly cased, with the sole exception of 'mysql'. Wouldn't DBD::Google make more sense? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission DBD::google
On Tue, Apr 01, 2003 at 12:38:55PM -0500, darren chamberlain wrote: > I'm getting ready to upload a new version soon(ish), though, so I > suppose I could rename it DBD::Google from this point forward. I > suppose the correct thing to do at this point would be to resubmit the > namespace registration, yes? Correct. And maybe delete the old files from the PAUSE interface. BTW, very good (and sick) idea -- although I think Tie::Google is more practical... Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: CPAN LINK?
On Tue, Apr 01, 2003 at 02:20:18PM -0500, Michael Shehan wrote: > Can you tell me why http://www.cpan.org now links to Matt's Script > Archive? In case you don't know, Matt recently teamed up with Matz (and the ruby-porters ) to take over the leadership of the Perl 5 language and modules, since the original community has largely abandoned them in favor of Parrot and Perl6. Matt's takeover has been reported at use.perl: http://use.perl.org/article.pl?sid=03/04/01/1224229&mode=nested&tid=32 The transition of module list maintainence has just been completed: http://nntp.x.perl.org/group/perl.modules/20089 Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Joke or hack?
On Tue, Apr 01, 2003 at 03:11:12PM -0500, Kurt Starsinic wrote: > The "enteredby" field makes me wonder whether I should laugh or > worry. Any clues? It's a (admittedly lame) joke. I have also sent private mail to Michael Shehan to clear up the matter. And no, there's no [EMAIL PROTECTED] Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission DBIx::Informix::Perform
On Tue, Apr 01, 2003 at 09:11:27PM +0100, Tim Bunce wrote: > > I just checked and the DBIx-Perform tarball is still there in > > /W/WE/WEAV; I've "undeleted" the files. > > > > If you want to re-index it as DBIx::Perform I'm all for it. > > Thanks :) > > I think it would be easiest all round if you just filled out the > module registration form again, then one of the [EMAIL PROTECTED] > folk can just click-a-lik to register the new module name. I'd be happy to be that somebody, and deactivate DBIx::Informix::Perform from the module list. > > Thanks for your patience with me... > > No problem. Thank you for yours! And thanks to both of you for bearing with my apprenticeship... Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission EMAIL::Newsletter
On Wed, Apr 02, 2003 at 11:09:17PM +0200, Perl Authors Upload Server wrote: > The EMAIL::Newsletter namespace makes sense, because the module is > used to send Email Newsletters. First, we don't have an EMAIL toplevel yet, and I doubt it needs to be all-capitalized since it's not an acronym of anything. Second, how is your module different from Mail::Bulkmail? (please cc [EMAIL PROTECTED] in your reply.) Thanks, /Autrijus/
Re: Module submission EMAIL::Newsletter
On Thu, Apr 03, 2003 at 09:17:38AM -0800, Anthony Ettinger wrote: > My module handles HTML & Text-embedded > multipart/alternative emails...Mail::Bulkmail does > not. How about subclassing Mail::Bulkmail and name it Mail::Bulkmail::HTML or Mail::Bulkmail::MIME? We try to encourage as much re-use and subclassing on CPAN as possble, since existing Mail::Bulkmail users can then switch to your module easily if you maintain a similar interface. Thanks, /Autrijus/
Re: Module submission WWW::SMS
On Thu, Apr 03, 2003 at 05:37:51PM +0200, Perl Authors Upload Server wrote: > similar: > NET::SMS GSM::SMS Pardon my ignorance, but can you elaborate on the difference between your module and the Net:: / GSM:: variants? Thanks, /Autrijus/
Re: Word Doc Module
On Fri, Apr 04, 2003 at 10:50:55AM -0700, Kadura Rodney-rzer10 wrote: > Can anyone tell me if there is any public source for manipulating Word > docs? I use and love the ParseExcel and WriteExcel modules. > Exececptional utilities. Is there anything similar out there for > Word? On Windows, you can simply use Win32::OLE to call Microsoft Word's public API. Otherwise you may need to manupulate the structure via OLE::Storage or using external utilities like wvHtml. Please consult http://www.perlmonks.org/ or comp.lang.perl.* for additional information. Thanks, /Autrijus/
Re: Module submission Devel::Breakpoint
On Wed, May 21, 2003 at 04:48:58PM +0200, Johan Vromans wrote: > [Quoting Jan Dubois, on May 21 2003, 07:40, in "Re: Module submissio"] > > And it is more likely that someone will stumble on the > > Devel::Breakpoint module, than learning about the implementation details > > of the Perl debugger. > > Exactly. > > > So I don't know, should I upload it? > > Why not? There are many less useful modules out there already ;-). I agree. I can certainly use this and subclass it for the upcoming debugging support for PAR-generated executables. :) Thanks, /Autrijus/
Re: Perl Modules
On Wed, Mar 26, 2003 at 10:34:42AM -0800, Billa wrote: > I want to install required modules I was able to download libnet-1.13.tar.gz, > TermReadKey-2.21.tar.gz,Time-HiRes-1.43.tar.gz from CPAN.org but I don't see > the other modules and I was able to find only perl5.005_03.tar.gz file. this > file if I am right builds perl binary but perl 5.005_03 is already there on > my system So what is the best way to install other modules like File:BaseName, > File:COPY, POSIX etc. Where do I find them? Thanks in advance. They are 'core' modules already included with Perl 5.00503, so you do not need to install them again. Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Convert::FEC
在 ?G, 2003-09-09 04:01, Perl Authors Upload Server 寫道： > The following module was proposed for inclusion in the Module List: > That's why I want to write Convert::FEC. > I am certain about most aspects, except the name. I looked through > the Crypt, Data, Convert namespaces and the closest fit was Convert. > Althoguh I am not too hapyp with that. I think Convert::FEC is good enough for people who are looking for FEC implementations. Although if I was to put it on CPAN, I'll probably use the Algorithm:: space and call it Algorithm::FEC. One can find similar modules like Algorithm::Huffman, Algorithm::LUHN and Algorithm::Bucketizer, under that namespace. BTW, I'm very excited to see that a perl-based FEC is at last available. Nice work! Thanks, /Autrijus/ signature.asc Description: =?UTF-8?Q?=E9=80=99=E6=98=AF=E6=95=B8=E4=BD=8D=E5=8A=A0=E7=B0=BD?= =?UTF-8?Q?=E7=9A=84=E9=83=B5?= =?UTF-8?Q?=E4=BB=B6?=
Re: Module submission Win32::Security
在 ?G, 2003-09-09 02:23, Perl Authors Upload Server 寫道： > At the base level is Win32::Security::Raw, which provides > minimalist wrappers around the Win32 API calls that have proved > necessary. Win32::Security::SID provides for interaction with SIDs, > conversion between string and binary forms and trustee names. It looks very reasonable indeed. > I look forward to releasing the code when it is in good shape:). Any estimated time for that, or is there already preliminary POD/tests/code available for preview? Thanks, /Autrijus/ signature.asc Description: =?UTF-8?Q?=E9=80=99=E6=98=AF=E6=95=B8=E4=BD=8D=E5=8A=A0=E7=B0=BD?= =?UTF-8?Q?=E7=9A=84=E9=83=B5?= =?UTF-8?Q?=E4=BB=B6?=
Re: Module submission Net::BeepLite
在 ?G, 2003-09-09 01:54, Perl Authors Upload Server 寫道： > The following module was proposed for inclusion in the Module List: > modid: Net::BeepLite > DSLIP: bdpOl > description: lightweight BEEP framework > userid: DBLACKA (David Blacka) > chapterid:5 (Networking_Devices_IPC) > communities: > [EMAIL PROTECTED] > This is a BEEP protocol framework (RFC 3080, 3081), and, as such, > it is a bit like other internet protocol frameworks (Net::FTP, > Net::DNS, etc.). Following the example of SOAP::Lite, wouldn't BEEP::Lite of Net::BEEP::Lite be more intuitive? :-) Thanks, /Autrijus/ signature.asc Description: =?UTF-8?Q?=E9=80=99=E6=98=AF=E6=95=B8=E4=BD=8D=E5=8A=A0=E7=B0=BD?= =?UTF-8?Q?=E7=9A=84=E9=83=B5?= =?UTF-8?Q?=E4=BB=B6?=
Re: File::Basename
在 ?T, 2003-09-10 04:44, James Page 寫道： > Sometime bewteen 5.6 and 5.8 the fileparse function was updated to croak > if it received a blank or undef as a parameter. This backwards > incompatibility is causing lots of problems in my shop. Any reason for > this change? Any likelihood of an update to make it backwards compatible? You want [EMAIL PROTECTED], not [EMAIL PROTECTED] :) /Autrijus/ signature.asc Description: =?UTF-8?Q?=E9=80=99=E6=98=AF=E6=95=B8=E4=BD=8D=E5=8A=A0=E7=B0=BD?= =?UTF-8?Q?=E7=9A=84=E9=83=B5?= =?UTF-8?Q?=E4=BB=B6?=
Re: Module submission Net::BeepLite
在 ?T, 2003-09-10 03:54, David Blacka 寫道： > Net::BEEP::Lite would be fine, however. > > Although BEEP has been defined for 2 years, this is the first non-vaporware > perl implementation of it that I'm aware of. I would hope that at some > point a more comprehensive implementation of BEEP (one that supported the > complex peer-to-peer and channel multiplexing) to be implemented at some > point. It would seem to make more sense to call that Net::BEEP rather > than BEEP for BEEP::Full or something like that. Okay. Can you re-send a submission for Net::BEEP::Lite, then? :-) /Autrijus/ signature.asc Description: =?UTF-8?Q?=E9=80=99=E6=98=AF=E6=95=B8=E4=BD=8D=E5=8A=A0=E7=B0=BD?= =?UTF-8?Q?=E7=9A=84=E9=83=B5?= =?UTF-8?Q?=E4=BB=B6?=
Re: Module submission Digest::Hashcash
在 ?@, 2003-09-08 10:30, Janek Schleicher 寫道： > What about > Digest::HashCash > ^ > what seems to be easier to read for me. I agree. The literature term for it seem to be "Hash cash tokens", which suggests it can be separated into two words, which implies that HashCash is a proper name for this module. Thanks, /Autrijus/ signature.asc Description: =?UTF-8?Q?=E9=80=99=E6=98=AF=E6=95=B8=E4=BD=8D=E5=8A=A0=E7=B0=BD?= =?UTF-8?Q?=E7=9A=84=E9=83=B5?= =?UTF-8?Q?=E4=BB=B6?=
Re: Module submission Digest::Hashcash
在 ?|, 2003-09-11 14:32, [EMAIL PROTECTED] 寫道： > Maybe the confusion arises because of "hash cash tokens" are being > referred to in a general way sometimes, but that has no relevance to the > actual hascash algorithm, or the actual hashcash tokens. I see. I stand corrected, as googling "hash cash" and "hashcash" both yields plenty of results, and it is correct that the former one describes a general technique, and the latter describes a specific implementation. > "hash cash tokens" != "hashcash tokens", and the latter is what the > module calculates and checks. A module that generically implements hash > cash tokens might rightfully be called Algorithm::HashCash or so, but a > module implementing hashcahs tokens must be called "Hashcash" as to > avoid confusion. Point well taken. If there's no other objections, I'll go ahead and apply this to the module list. Thanks, /Autrijus/ signature.asc Description: =?UTF-8?Q?=E9=80=99=E6=98=AF=E6=95=B8=E4=BD=8D=E5=8A=A0=E7=B0=BD?= =?UTF-8?Q?=E7=9A=84=E9=83=B5?= =?UTF-8?Q?=E4=BB=B6?=
Re: Module submission Lingua::FA::Number
?b 五, 2003-09-12 09:32, Perl Authors Upload Server ?g?D?G > description: Returns the Persian (Farsi) HTML/Unicode equ The description is too long. Can you shorten it a bit? > rationale: > Also, a non-empty rationale will help. :-) Thanks, /Autrijus/ signature.asc Description: =?UTF-8?Q?=E9=80=99=E6=98=AF=E6=95=B8=E4=BD=8D=E5=8A=A0=E7=B0=BD?= =?UTF-8?Q?=E7=9A=84=E9=83=B5?= =?UTF-8?Q?=E4=BB=B6?=
Re: Module submission Arary::Heap2
在 ?|, 2003-09-18 15:47, Perl Authors Upload Server 寫道： > The following module was proposed for inclusion in the Module List: > modid: Arary::Heap2 "Arary" will not do. Please fix this typo and re-submit. :-) > And here is the rationale for choosing Array::Heap2: > Well, there is no good rationale, but while registering, I found > that Array::Heap has been registered in what seems 1998 already, > however, a module hasn't been uploaded in the last 5 years. (I > didn'T see this at first because my searches were for existing > modules only :) > I've contacted the author, but haven't received a reply yet (but > it's not been a long time). Interesting. CC'ed to John Macdonald, to see whether he is willing to abdicate that namespace to you. Thanks, /Autrijus/ signature.asc Description: =?UTF-8?Q?=E9=80=99=E6=98=AF=E6=95=B8=E4=BD=8D=E5=8A=A0=E7=B0=BD?= =?UTF-8?Q?=E7=9A=84=E9=83=B5?= =?UTF-8?Q?=E4=BB=B6?=
Re: Module submission Color::Output
在 ??, 2003-09-19 00:56, Perl Authors Upload Server 寫道： > similar: > Term::ANSIColor Win32::Console Win32::Console::ANSI Note that Term::ANSIScreen has a Win32::Console emulation mode, and also works in a cross-platform fashion: use Term::ANSIScreen; my $console = Term::ANSIScreen->new; $console->Cls; # or any other Win32::Console API Can you look at it a bit, and see if that module and yours are equivalent with each other? Thanks, /Autrijus/ signature.asc Description: =?UTF-8?Q?=E9=80=99=E6=98=AF=E6=95=B8=E4=BD=8D=E5=8A=A0=E7=B0=BD?= =?UTF-8?Q?=E7=9A=84=E9=83=B5?= =?UTF-8?Q?=E4=BB=B6?=
Re: Module submission Win32::File::Ver
On Fri, Oct 17, 2003 at 09:54:25PM +, Alexey Toptygin wrote: > poke? How about Win32::File::VersionInfo? I feel a wee bit uncomfortable using nonstandard abbreviations, and IIRC "GetFileVersionInfo" is a canonical name on Win32. Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Foo with Mutt Aliases
On Tue, Oct 21, 2003 at 05:05:32AM +1000, Ricky Buchanan wrote: > Could you suggest an appropriate namespace for this file? Other > than Mutt::Aliases, which creates a new root namespace which I > understand is Generall Bad Form, I have no ideas. Config::Mutt::Aliases, maybe? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module List updates?
On Wed, Oct 22, 2003 at 09:09:45AM +0100, Steve Hay wrote: > Does somebody need to click one of the links at the bottom of the > "Module submission" mail for Win32::UTCFileTime: >http://www.xray.mpe.mpg.de/mailing-lists/modules/2003-05/msg00472.html Exactly. > If so, I'd appreciate somebody doing so. (It says the links are only > valid for module list maintainers.) As the name and description seems relatively uncontroversial, and the code seems generally useful, I took the liberty to adding it to the module list. Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Module submission Math::Gradient
On Thu, Oct 23, 2003 at 02:08:59AM +0200, Perl Authors Upload Server wrote: > The following module was proposed for inclusion in the Module List: > modid: Math::Gradient > DSLIP: Rdpfp As it is marked as "Release" quality as its first version, I wonder if I can look at the code a bit. :-) Can you upload it to CPAN first, so we get a chance to see it? The module name itself sounds well thought-out and uncontroversial. Thanks, /Autrius/ pgp0.pgp Description: PGP signature
Re: Module submission TM
On Sat, Nov 01, 2003 at 07:33:23PM +0100, Perl Authors Upload Server wrote: > The following module was proposed for inclusion in the Module List: > modid: TM > DSLIP: cdcOb > description: library for building Topic Maps applications > userid: ALGER (Jan Algermissen) > chapterid: 23 (Miscellaneous_Modules) > communities: > http://www.infoloom.com/mailman/listinfo/topicmapmail Well, when I see TM, I first think of trademarks, not topic maps. What do you think about using TopicMap:: instead? Thanks, /Autrijus/ pgp0.pgp Description: PGP signature
Re: Patch for sidekick v0.02
On Sun, Sep 16, 2001 at 06:57:41AM -0700, Vipul Ved Prakash wrote: > I have retracted the VERSION patch for the moment for two reasons: Perl > versions are real numbers, and your patch treats them like canonical > version strings. This might cause a problem in future, eg when we go from > 0.3 to 0.11; in perl 0.3 > 0.11. i see. that's quite reasonable. :) but how about sprintf()'ing so it reads 0.003 => 0.011, or just using the v0.3.11 notation? > Also, CVS insists on starting revision numbers with 1.x. I am sure there's > a way to force it to use 0.x, I just haven't figured it out yet. i'm using perforce, and have no idea about cvs. :) > A question for those reading the SDK list and [EMAIL PROTECTED]: should I > upload sidekick to CPAN? as the sidekick script utilizes plenty of CPAN.pm function, how about abstract it to a module named CPAN::SDK, and work toward an integration with Bundle / MakeMaker so i could 'make sdk' or query SDKs from cpan> prompt? just my two cents, /Autrijus/ PGP signature
PAUSE Register: AUTRIJUS
me: Autrijus Tang Email: [EMAIL PROTECTED] WWW: http://autrijus.org/ UID: AUTRIJUS Modules planned to contribute: - libOurNet v1.4 (http://ourinet.com/libOurNet-snapshot.tar.gz), These modules are interfaces to BBS-based groupware projects used in Hong Kong, China and Taiwan by est. 1 million users. Used collabo- ratively, they glue BBSes together to form a distributed service network, called 'OurNet'. OurNet RmpOInterface to BBS-based groupware platforms (including following modules): ::Query RmpOPerform scriptable queries via LWP ::Site RmpOExtract texts with via templates ::FuzzyIndex RmcOFuzzy match for double-byte charsets ::ChatBotRmpOContext-Free Interactive Q&A Engine ::BBSAgent RmpOScriptable telnet-based virtual users ::Cell ampOInterface-based RPC with Relay & Locating ::WebBuilder RmpOWeb Rendering for BBS-based services ::Template ampOTemplate Extraction and Generation ::BBSbmpOComponent Object Model for BBS systems Plus assorted back-ends under OurNet::BBS::* namespace. - Games::AIBots v1.2 (http://autrijus.org/AIBots.tgz) Games:: ::AIBots RmpOAn improved clone of A.I.Wars in Perl. - Term::ANSIScreen v1.0 Term:: ::ANSIScreen RmpOGenerating ANSI cursor-control codes References: libOurNet is under constant revision and discussions by the Elixir Movement, a Taiwan-based grassroot developer group linking several independent companies, various user groups including Taipei Perl Mongers, Taiwan BSD Mongers, The CyberVision Organization, etc. The Elixir BBS is at telnet://cvic.org/, area 5. However most of the discussions are in Chinese. Coordinated by myself, AIWars is the collaborative efforts of the Perl Class of Beizheng junior high school, Taipei, Taiwan, and resides under Elixir Movement's project space, p4://p4.elixus.org/. It is a copyright-clean clone of "A.I.Wars: The Insect Mind", a popular programming game written by the fine folks at www.TacticalNeuronics.com. Term::ANSIScreen was named Term::ANSI, intended as an extension to Term::ANSIColor which is a part of standard distribution. After consulting Term::ANSIColor's authors, its name had been changed to avoid conflicts with the original module. Sincerely yours, /Autrijus/
Request for module: Convert::GeekCode
Name: Autrijus Tang Email: [EMAIL PROTECTED] WWW: http://autrijus.org/ UID: AUTRIJUS Wishes to upload this module: - Convert::GeekCode v1.0 Convert::GeekCode converts and generates Geek Code L<http://geekcode.com/> sequences. It supports different charsets and user-customizable codesets. Convert:: ::GeekCode baph Convert and generate geek code sequences Thank you, /Autrijus/
