Re: Module name hierarchy...

[BC]

Thanks to Dan for that superlative example and Domi who asked:


... provided your Class::Fault is relatively generic. I.e. can it be
used by an unrelated module ?


The module will indeed be generic.  It will be yet another way to
solve the common problem of error handling and reporting.  So since
there is no requirement for each step in the path to be an existing
module, I will go with

   Class::Fault::Foobar

where 'Foobar' will be some sort of descriptive name that attempts to
succinctly identify the strategy or approach being used for handling
faults.

Many thanks to all who took time to reply.

...BC

Re: Module name hierarchy...

[Dominique Dumont]

On Wednesday, 30 September 2020 07:55:40 CEST BC wrote:
> I can avoid the whole problem by
> just picking a different but similar name:
> 
> Class::Fault
> 
> which is currently not used.  For my purposes that name works well.
> The only thing I don't like is that it feels like I am squatting on
> something fairly generic near the top of the name space.  

Which would fine fine provided your Class::Fault is relatively generic. I.e. 
can 
it be used by an unrelated module ?

> If I were to
> push my one and only module down a level as:
> 
> Class::Fault::Foobar
> 
> would it be a faux pas if there is no Class/Fault.pm or anything else
> at that second level?

If your Fault module is coupled to Foobar, why not create a Foobar::Error (or 
Foobar::Fault) module ?

For the record, I've chosen the latter approach with Config::Model::Exception.

HTH

Re: Module name hierarchy...

[Dan Book]

On Wed, Sep 30, 2020 at 1:56 AM BC  wrote:

> The only thing I don't like is that it feels like I am squatting on
> something fairly generic near the top of the name space.  If I were to
> push my one and only module down a level as:
>
> Class::Fault::Foobar
>
> would it be a faux pas if there is no Class/Fault.pm or anything else
> at that second level?
>

There is no requirement or reason that each step of the module hierarchy
needs to exist as a separate module. (Just imagine if that was needed for
https://metacpan.org/pod/Acme::Working::Out::Dependencies::From::META::files::Will::Be::Wrong::At::Some::Point::Like::This::Module::For::Instance
)

-Dan

Re: Module name hierarchy...

[BC]

Thanks to John, David, and Dan for their thoughts on my module naming
question.  So to avoid potentially tromping on another author's name
space doing something like:

   Class::Error::Foobar

where `Class::Error` already exists, I can avoid the whole problem by
just picking a different but similar name:

   Class::Fault

which is currently not used.  For my purposes that name works well.
The only thing I don't like is that it feels like I am squatting on
something fairly generic near the top of the name space.  If I were to
push my one and only module down a level as:

   Class::Fault::Foobar

would it be a faux pas if there is no Class/Fault.pm or anything else
at that second level?

...BC

Re: Module name hierarchy...

[John M. Gamble]

On Fri, September 25, 2020 4:12 pm, David Cantrell wrote:
> On 25/09/2020 19:59, Dan Book wrote:
>> On Fri, Sep 25, 2020 at 2:20 PM BC > > wrote:
>>
>> Let's say I wanted to submit a module named:
>>
>>       Class::Error::Foobar
>>
>> Would this be considered bad form if my "Foobar" module is not
>> related
>> to the existing Class::Error module in any way?  In other words,
>> Foobar does not depend on, extend, nor reference the Class::Error
>> module other than perhaps a courtesy "See Also" mention.
>>
>> It is not necessarily bad form, but if there is an existing
>> "Class::Error" ecosystem you might consider asking the author first in
>> case they wanted to use that sub-namespace. That does not really seem to
>> be the case here.
>
> I'd say that you should ask no matter what, and should also consider
> using something like Foobar::Error instead. Partly to avoid trampling on
> someone else's namespace, but also because using C::E::Foobar might give
> your users some incorrect expectations if they are already using
> Class::Error elsewhere.
>
> --
> David Cantrell
>
>

I'm of two minds. If the top and second level is large enough then it's
possible that the "ecosystem" has escaped the menagerie and it not really
under the top-and-second namespace author's control. Likewise, if the
author is clearly limiting their module to one purpose, then I don't
believe this is an issue.

But that's making assumptions that I don't know are true about your case.
If neither one is true, then yes, contact the author.

Disclosure of bias on my part: I am the author of Math::Polynomial::Solve,
and the then-author of Math::Polynomial was clearly an example of the
second case.

 --john

Re: Module name hierarchy...

[David Cantrell]

On 25/09/2020 19:59, Dan Book wrote:
On Fri, Sep 25, 2020 at 2:20 PM BC > wrote:


Let's say I wanted to submit a module named:

      Class::Error::Foobar

Would this be considered bad form if my "Foobar" module is not related
to the existing Class::Error module in any way?  In other words,
Foobar does not depend on, extend, nor reference the Class::Error
module other than perhaps a courtesy "See Also" mention.

It is not necessarily bad form, but if there is an existing 
"Class::Error" ecosystem you might consider asking the author first in 
case they wanted to use that sub-namespace. That does not really seem to 
be the case here.


I'd say that you should ask no matter what, and should also consider 
using something like Foobar::Error instead. Partly to avoid trampling on 
someone else's namespace, but also because using C::E::Foobar might give 
your users some incorrect expectations if they are already using 
Class::Error elsewhere.


--
David Cantrell

Re: Module name hierarchy...

[Dan Book]

On Fri, Sep 25, 2020 at 2:20 PM BC  wrote:

> Let's say I wanted to submit a module named:
>
>  Class::Error::Foobar
>
> Would this be considered bad form if my "Foobar" module is not related
> to the existing Class::Error module in any way?  In other words,
> Foobar does not depend on, extend, nor reference the Class::Error
> module other than perhaps a courtesy "See Also" mention.
>

It is not necessarily bad form, but if there is an existing "Class::Error"
ecosystem you might consider asking the author first in case they wanted to
use that sub-namespace. That does not really seem to be the case here.

-Dan

Re: Module name advice

[Diab Jerius]

On Thu, Sep 18, 2014 at 12:28 PM, David Cantrell da...@cantrell.org.uk wrote:
 On Thu, Sep 18, 2014 at 10:55:19AM -0400, Diab Jerius wrote:
 I've written a module which subclasses Text::Template and provides
 local encapsulation of template variable environments
 (https://bitbucket.org/djerius/text-template-localize).

 I like the name Text::Template::Localize, as in making things local,
 like the Perl 'local' command, but the name sounds a bit too much like
 its doing something with language locales.
 Text::Template::Encapsulate sounds too hermetic to me for some reason.

 Would anyone have an alternate suggestion?

 Blah::Scoped?

That sounds better (despite it's being reminiscent of an unpleasant
medical procedure).

Re: Module name advice

[Diab Jerius]

On Thu, Sep 18, 2014 at 3:40 PM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
 * Ben Deutsch b...@bendeutsch.de [2014-09-18 20:20]:
 Text::Template::LocalVars


I like that one.

Thanks much for the help.

Diab

Re: Module name advice

[David Cantrell]

On Thu, Sep 18, 2014 at 10:55:19AM -0400, Diab Jerius wrote:
 I've written a module which subclasses Text::Template and provides
 local encapsulation of template variable environments
 (https://bitbucket.org/djerius/text-template-localize).
 
 I like the name Text::Template::Localize, as in making things local,
 like the Perl 'local' command, but the name sounds a bit too much like
 its doing something with language locales.
 Text::Template::Encapsulate sounds too hermetic to me for some reason.
 
 Would anyone have an alternate suggestion?

Blah::Scoped?

-- 
David Cantrell | London Perl Mongers Deputy Chief Heretic

People from my sort of background needed grammar schools to
compete with children from privileged homes like ... Tony Benn
 -- Margaret Thatcher

Re: Module name advice

[Ben Deutsch]

Hello!


I've written a module which subclasses Text::Template and provides
local encapsulation of template variable environments
(https://bitbucket.org/djerius/text-template-localize).

I like the name Text::Template::Localize, as in making things local,
like the Perl 'local' command, but the name sounds a bit too much like
its doing something with language locales.


For what it's worth, I don't think that's too bad. For something really 
locale-based, I'd expect a name like Text::Template::Localization, 
Text::Template::Locales or even Text::Template::L10N. So ::Localize is 
not as fixed as it seems ;-)



Would anyone have an alternate suggestion?


You may want to focus on the variable environment aspect:

Text::Template::LocalVars
Text::Template::LocalScope

or similar. This way, noone will think it's trying to add l10n 
functionality.


Regards,
  Ben Deutsch

Re: Module name advice

[Aristotle Pagaltzis]

* Ben Deutsch b...@bendeutsch.de [2014-09-18 20:20]:
 Text::Template::LocalVars

FWIW, that was going to be my suggestion too.

-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Module name advice?

[Chris Marshall]

Hi Paul-

This is very intriguing work.  PDL as a module is
focused on efficiently calculating for numerical computation.
Ability to compute with more general PDF objects would
be very interesting to the PDL community.

Specifically, the coming PDL3 refactoring to a more general,
flexible, and extended type system would have a natural fit
for the types of objects this work could generate.  Another
goal for PDL3 is JIT compile support for computation which
might be exactly the place where this PDF language work
could tie in with computation.

The PDL home page is at http://pdl.perl.org and I invite you
to join the perldl mailing list which is the best way to ask
questions and get help or discuss things PDL related.
You can sign up here: http://mailman.jach.hawaii.edu/mailman/listinfo/perldl

To get back on topic, it looks like there is a fair amount of
other related work in this area that may be relevant in choosing
a module name.  Has some of this been implemented for R or
in a Python package.  That might give some other data points.

--Chris

On Fri, Jul 25, 2014 at 10:49 AM, Paul Bennett paul.w.benn...@gmail.com wrote:
 Hi, Maggie and John,

 On Fri, Jul 25, 2014 at 10:39 AM, John M Gamble jgam...@ripco.com wrote:
 On 7/25/2014 8:48 AM, Maggie X wrote:

 Thanks for looping me in, David! I don''t see Paul's email here though :)

 Looks like a nice contribution. Is it going to involve PDL?

 I don't plan for it to involve PDL at this time, but then I only have
 the vaguest idea of what PDL even is.

 The parsing is going to be done using JKGEL's excellent Marpa::R2
 module, and the math is probably going to be bluntly smacked at with
 plenty of brute force.

 I suspect PDL might be a better form of brute force than my current
 plan, which involves some pretty hare-brained shenanigans. I'm a
 simple man, with just enough undergrad math under my belt to pass an
 Electrical Engineering bachelors. Everything since then has been
 entirely self-taught, and it's been no easy road. I've found you can
 do most things by watching a few youtube videos and smashing violently
 at the keyboard, though.

 I forget whether I linked the (work in progress) grammar I'll be
 using, but it's at https://gist.github.com/PWBENNETT/8435996 if
 anyone's curious.

 I have emailed the authors of the original paper, though two of their
 four addresses came back as no such user, so ... yeah.

 I suspect the next steps are going to involve my learning PDL, and
 brushing up on the requisite math itself. I can glark a lot of it from
 context, but context can only take you so far.



 Thanks for your interest,


 --
 P/PW/PWBENNETT

Re: Module name advice?

[John M Gamble]

On 7/25/2014 8:48 AM, Maggie X wrote:

Thanks for looping me in, David! I don''t see Paul's email here though :)

Looks like a nice contribution. Is it going to involve PDL?


Best,
Maggie


Addresses (including mailing list) added to the mail.

 -john






On Thu, Jul 24, 2014 at 9:14 AM, David Mertens 
dcmertens.p...@gmail.com mailto:dcmertens.p...@gmail.com wrote:


Hey Paul,

Maggie Xiong, the author of PDL::Stats
http://sourceforge.net/projects/pdl-stats/, may have an interest
in this work, and may also have a recommendation for a name. I've
CC'd her to help with any ensuing conversation. :-)

David


On Wed, Jul 23, 2014 at 3:12 PM, John M Gamble jgam...@ripco.com
mailto:jgam...@ripco.com wrote:

On 7/22/2014 11:55 PM, Paul Bennett wrote:

I'm in the process of writing a Perl module that provides
a practical
implementation of the statistics language described at
http://ashishagarwal.org/2011/10/04/pdf-type-theory/ which
would
compile programs in that language to Perl objects that provide
-pdf($n), -cdf($n), and -rand() methods (providing the
probability
density at $n, the cumulative probability for $n, and a
random number
generated by a given script in that language, respectively).

Right now, I'm pondering the name
Statistics::Language::BAVC (the
initials of the authors of the paper).

If anyone's got any better ideas, now's your chance to
speak up.


I've just skimmed the paper. Even though they don't have a
name for their own technique, it seems risky to just name it
out of the blue.

Have you tried contacting the authors and asking if they've
come up with a term?

I agree that Statistics::Language is probably the prefix to
use for your module.

 -john




-- 
 Debugging is twice as hard as writing the code in the first place.

  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan

Re: Module name advice?

[Paul Bennett]

Hi, Maggie and John,

On Fri, Jul 25, 2014 at 10:39 AM, John M Gamble jgam...@ripco.com wrote:
 On 7/25/2014 8:48 AM, Maggie X wrote:

 Thanks for looping me in, David! I don''t see Paul's email here though :)

 Looks like a nice contribution. Is it going to involve PDL?

I don't plan for it to involve PDL at this time, but then I only have
the vaguest idea of what PDL even is.

The parsing is going to be done using JKGEL's excellent Marpa::R2
module, and the math is probably going to be bluntly smacked at with
plenty of brute force.

I suspect PDL might be a better form of brute force than my current
plan, which involves some pretty hare-brained shenanigans. I'm a
simple man, with just enough undergrad math under my belt to pass an
Electrical Engineering bachelors. Everything since then has been
entirely self-taught, and it's been no easy road. I've found you can
do most things by watching a few youtube videos and smashing violently
at the keyboard, though.

I forget whether I linked the (work in progress) grammar I'll be
using, but it's at https://gist.github.com/PWBENNETT/8435996 if
anyone's curious.

I have emailed the authors of the original paper, though two of their
four addresses came back as no such user, so ... yeah.

I suspect the next steps are going to involve my learning PDL, and
brushing up on the requisite math itself. I can glark a lot of it from
context, but context can only take you so far.



Thanks for your interest,


--
P/PW/PWBENNETT

Re: Module name advice?

[David Mertens]

Hey Paul,

Maggie Xiong, the author of PDL::Stats
http://sourceforge.net/projects/pdl-stats/, may have an interest in this
work, and may also have a recommendation for a name. I've CC'd her to help
with any ensuing conversation. :-)

David


On Wed, Jul 23, 2014 at 3:12 PM, John M Gamble jgam...@ripco.com wrote:

 On 7/22/2014 11:55 PM, Paul Bennett wrote:

 I'm in the process of writing a Perl module that provides a practical
 implementation of the statistics language described at
 http://ashishagarwal.org/2011/10/04/pdf-type-theory/ which would
 compile programs in that language to Perl objects that provide
 -pdf($n), -cdf($n), and -rand() methods (providing the probability
 density at $n, the cumulative probability for $n, and a random number
 generated by a given script in that language, respectively).

 Right now, I'm pondering the name Statistics::Language::BAVC (the
 initials of the authors of the paper).

 If anyone's got any better ideas, now's your chance to speak up.


 I've just skimmed the paper. Even though they don't have a name for their
 own technique, it seems risky to just name it out of the blue.

 Have you tried contacting the authors and asking if they've come up with a
 term?

 I agree that Statistics::Language is probably the prefix to use for your
 module.

  -john




-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan

Re: Module name advice?

[John M Gamble]

On 7/22/2014 11:55 PM, Paul Bennett wrote:

I'm in the process of writing a Perl module that provides a practical
implementation of the statistics language described at
http://ashishagarwal.org/2011/10/04/pdf-type-theory/ which would
compile programs in that language to Perl objects that provide
-pdf($n), -cdf($n), and -rand() methods (providing the probability
density at $n, the cumulative probability for $n, and a random number
generated by a given script in that language, respectively).

Right now, I'm pondering the name Statistics::Language::BAVC (the
initials of the authors of the paper).

If anyone's got any better ideas, now's your chance to speak up.


I've just skimmed the paper. Even though they don't have a name for 
their own technique, it seems risky to just name it out of the blue.


Have you tried contacting the authors and asking if they've come up with 
a term?


I agree that Statistics::Language is probably the prefix to use for your 
module.


 -john

Re: module name for a tutorial or example or sample module

[Aristotle Pagaltzis]

* bulk 88 bul...@hotmail.com [2012-06-08 03:20]:
 It only real purpose is to be copied into other XS modules and be
 studied from. What namespace should it go under?

CopyPasta::FastHash? :-)

In all seriousness, I would pick Example::XS::FasterHashes. Or maybe
just Example::FasterXSHashes.

XS:: seems the wrong place because the *main* thing about this module
seems to me to be that it is not a library, just an educational example
for XS authors.

Module:: is definitely incorrect, because this has nothing to do with
doing something with modules.

Acme:: seems incorrect because to my mind it means “this is stupid or
crazy but in any case inadvisable, yet still funny or cool, and I wanted
to put it out there for people to look at”. And your code would clearly
be out of place in such a category.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: module name for a tutorial or example or sample module

[Zbigniew Łukasiak]

On Fri, Jun 8, 2012 at 5:09 PM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
 * bulk 88 bul...@hotmail.com [2012-06-08 03:20]:
 It only real purpose is to be copied into other XS modules and be
 studied from. What namespace should it go under?

 CopyPasta::FastHash? :-)

 In all seriousness, I would pick Example::XS::FasterHashes. Or maybe
 just Example::FasterXSHashes.

 XS:: seems the wrong place because the *main* thing about this module
 seems to me to be that it is not a library, just an educational example
 for XS authors.

 Module:: is definitely incorrect, because this has nothing to do with
 doing something with modules.

 Acme:: seems incorrect because to my mind it means “this is stupid or
 crazy but in any case inadvisable, yet still funny or cool, and I wanted
 to put it out there for people to look at”. And your code would clearly
 be out of place in such a category.


I vote for Example:: - I wish there were more such modules (I would
even move many existing modules into that namespace).

Z.

Re: module name for a tutorial or example or sample module

[M. Nunberg]

It's already a common convention for module authors to have an 'eg' 
directory which contains examples.


How about making this into a top level namespace (Generally top level 
namespaces are discouraged, but in this case it might be beneficial and 
encourage other authors to place more robust and visible examples).


Eg::XS::FastHash

or

XS::Eg::FastHash

or

XS::FastHash::Eg


On 06/07/2012 06:14 PM, bulk 88 wrote:


I have a XS module I wrote as a sample, example or tutorial on how to do increase the 
performance of perl hashes on an XS level. It doesn't do anything useful on its own other 
provide 2 XSUBs which are supposed to be benchmarked against each other to show the 
traditional vs my new way of doing things. It exports nothing 
C/.so/.a/.lib/.dll or Perl wise. It's test file just does the benchmark. It doesn't link 
with anything except a stock perl and a stock c std lib. It only real purpose is to be 
copied into other XS modules and be studied from. What namespace should it go under? I 
thought its name should be FastHash or XSFasterHashes. Example::FastHash? Example:: 
already exists. Sample:: doesn't exist. XS:: exists, XS::Example doesn't, so 
XS::Example::FastHash? Module::FastHash? (I dont like that) Module::Example::FastHash? 
Acme::FastHash? Acme::Tutorial::FastHash? I dont find Acme:: offensive, its a good way to 
prove the module doesn't do anything on its own and its not int
ended to 
be use'd.

Re: Module name query: enumerate Unicode canonically equivalent strings

[Shlomi Fish]

On Thu, 23 Jun 2011 21:14:11 -0500
BobH 134ra5...@sneakemail.com wrote:

 I am implementing a module which [currently] has only the following 
 function:
 
  permute_string($s)
  Given an arbitrary string, permute_string() returns
  a reference to an unsorted array of all unique strings
  that are canonically equivalent to the argument.
 
 As an example, if given a string such as \x{1eb7}\x{0303}, the 
 function returns an array containing all the following strings:
 
 a\x{0306}\x{0303}\x{0323}
 a\x{0306}\x{0323}\x{0303}
 a\x{0323}\x{0306}\x{0303}
 \x{0103}\x{0303}\x{0323}
 \x{0103}\x{0323}\x{0303}
 \x{1ea1}\x{0306}\x{0303}
 \x{1eb5}\x{0323}
 \x{1eb7}\x{0303}
 
 This can be used, for example, to generate test data for a text 
 processing function, or to help construct or test OpenType rules for a font.
 
 I am looking for recommendations on where this function belongs:
 
 1) Does it belong in some existing module?
 
 2) Does it belong in its own module, and if so what?
 

I think #2 is.

 My preference is something like Unicode::Equivalents but according to 
 https://pause.perl.org/pause/authenquery?ACTION=pause_namingmodules 
 Unicode may be off-limit.
 
 Suggestions?
 

Maybe Text::Unicode::Equivalence or something.

Regards,

Shloimi Fish

-- 
-
Shlomi Fish   http://www.shlomifish.org/
Parody of The Fountainhead - http://shlom.in/towtf

“We’re not doing it for money… we’re doing it for a shitload of money!”
— Spaceballs, http://www.imdb.com/title/tt0094012/

Please reply to list if it's a mailing list post - http://shlom.in/reply .

Re: module name for test data?

[Jerome Quelin]

hi,

and sorry for the delay to answer...

On 09/09/30 01:13 -0700, Ovid wrote:
 - Original Message 
 
  From: David Nicol davidni...@gmail.com
 
  you could put the word corpus in there somewhere, since you're
  publishing some test data. For others to use it, who might be
  looking for test data, that's what a corpus is in test data jargon
  (i believe.)
  
  Test::Corpus::audio::mpd
  
  would set an example of publishing test data to CPAN under the
  Test::Corpus prefix.
 
 ++!
 
 You know, I never did like this idea of publishing test data to the
 CPAN, but I ever dislike even more the idea of people stretching it
 for legitimate uses.  The Test::Corpus:: namespace is lovely.  If you
 publish there and folks are reasonably happy with this, let us know
 and I'll post some stuff to my blog and Perl-QA to get others to know
 about this namespace (and potentially use it).

i followed your advices and just pushed test::corpus::audio::md.
now i need to update my other modules to use this instead of embedding
the data themselves.


 If these corpuses (corpi?) can also guarantee a stable interface, we
 may even be able to guarantee common sets of test data which different
 *developers* can use, not just modules.  To that end, how would we
 guarantee a stable interface which people could trust, or be able to
 quickly bail out or skip if there's an incompatible change?

hmm, i also provide a module that configures and launches a test mpd
automatically. so it's a bit more than just a corpus. anyway, i guess i
can even split it further with test::corpus only shipping the data, and
the logic in test::audio::mpd. but really not for today! :-)


thanks,
jérôme 
-- 
jque...@gmail.com

Re: module name for test data?

[Ovid]

- Original Message 

 From: David Nicol davidni...@gmail.com

 you could put the word corpus in there somewhere, since you're
 publishing some test data. For others to use it, who might be looking
 for test data, that's what a corpus is in test data jargon (i
 believe.)
 
 Test::Corpus::audio::mpd
 
 would set an example of publishing test data to CPAN under the
 Test::Corpus prefix.

++!

You know, I never did like this idea of publishing test data to the CPAN, but I 
ever dislike even more the idea of people stretching it for legitimate uses.  
The Test::Corpus:: namespace is lovely.  If you publish there and folks are 
reasonably happy with this, let us know and I'll post some stuff to my blog and 
Perl-QA to get others to know about this namespace (and potentially use it).

If these corpuses (corpi?) can also guarantee a stable interface, we may even 
be able to guarantee common sets of test data which different *developers* can 
use, not just modules.  To that end, how would we guarantee a stable interface 
which people could trust, or be able to quickly bail out or skip if there's an 
incompatible change?

 
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: module name for test data?

[Ovid]

--- On Wed, 30/9/09, Ovid publiustemp-moduleautho...@yahoo.com wrote:

 From: Ovid publiustemp-moduleautho...@yahoo.com

 You know, I never did like this idea of publishing test
 data to the CPAN, but I ever dislike even more the idea of
 people stretching it for legitimate uses..

What a load of crap.  Let me try that again :)

You know, I never did like this idea of publishing test data to the CPAN, but 
I dislike even more the idea of telling people they can't stretch the CPAN for 
legitimate uses.

jeers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: module name for test data?

[Smylers]

Ovid writes:

 If these corpuses (corpi?)

Corpora (similar to opus - opera).

Smylers

Re: module name for test data?

[Shlomi Fish]

On Wednesday 30 Sep 2009 11:35:05 Smylers wrote:
 Ovid writes:
  If these corpuses (corpi?)
 
 Corpora (similar to opus - opera).
 

For more information see:

http://en.wiktionary.org/wiki/corpus

Regards,

Shlomi Fish

-- 
-
Shlomi Fish   http://www.shlomifish.org/
The Human Hacking Field Guide - http://shlom.in/hhfg

Chuck Norris read the entire English Wikipedia in 24 hours. Twice.

Re: module name for test data?

[Smylers]

Jerome Quelin writes:

 On 09/09/28 20:08 +0100, Paul LeoNerd Evans wrote:

  ... I'd make sure to include the word Test (capitalised) ...
 
 yes, i never capitalize when i'm writing (except code, of course). so
 the proposed module names would be capitalized correctly, of course.

That's what I guessed; apologies if it came across as overly pedantic.
But in some ways module names _are_ code, and I've previously
encountered users on case-insensitive file-systems writing code with
module names all lower-case -- which runs for them, but not elsewhere --
so I thought it worth checking.

Smylers

Re: module name for test data?

[nadim khemir]

Hi,

On Monday 28 September 2009 18.37.17 Smylers wrote:
 Jerome Quelin writes:
  - audio::mpd::common? (even if i don't think that's the best)
  - audio::mpd::test? this one is already used by a module in audio::mpd,
but that's not a problem (i plan to move audio::mpd::test somewhere in
t/lib/, so namespace would be free)
  - audio::mpd::testdata?
  - audio::mpd::common::test?
  - data::audio::mpd?
  - data::audio::mpd::test?
  - test::audio::mpd?

 I'd go for the latter (well, with some capital letters!) cos people are
 used to the idea that Test:: modules are used for testing rather than
 being part of the 'main function' of your program.

 But none of those names sound bad -- they're all pretty self-
 explanatory, so any of them would do.

 Smylers

I'd desagree with Smylers. Test:: is for testing modules while your data is, 
well data, and very much special to Audio::Mpd.

My vote would go to Audio::Mpd::Test::Data::+ whatever you want this would 
also allow you to keep your current test module where it is.

I also believe that minimizing the need to upload the test data (even if it's 
not too much data) is a great idea. Now you could also delete the test data 
after the tests.

Cheers, Nadim.

Re: module name for test data?

[Jonathan Leto]

Howdy,

 - audio::mpd::testdata?
 - audio::mpd::common::test?
 - data::audio::mpd?
 - data::audio::mpd::test?
 - test::audio::mpd?
 - is there a namespace for bulk data? test data?

If your module is useful to others for testing mpd audio in general,
then I would put it in the Test::Audio::MPD namespace. If you just
want to silo your module-specific test data, then it should go in
Audio::MPD::TestData or similar.

Cheers,


-- 

Jonathan Leto
jonat...@leto.net
http://leto.net

Re: module name for test data?

[David Nicol]

you could put the word corpus in there somewhere, since you're
publishing some test data. For others to use it, who might be looking
for test data, that's what a corpus is in test data jargon (i
believe.)

Test::Corpus::audio::mpd

would set an example of publishing test data to CPAN under the
Test::Corpus prefix.

Re: module name for test data?

[Smylers]

Jerome Quelin writes:

 - audio::mpd::common? (even if i don't think that's the best)
 - audio::mpd::test? this one is already used by a module in audio::mpd,
   but that's not a problem (i plan to move audio::mpd::test somewhere in
   t/lib/, so namespace would be free)
 - audio::mpd::testdata?
 - audio::mpd::common::test?
 - data::audio::mpd?
 - data::audio::mpd::test?
 - test::audio::mpd?

I'd go for the latter (well, with some capital letters!) cos people are
used to the idea that Test:: modules are used for testing rather than
being part of the 'main function' of your program.

But none of those names sound bad -- they're all pretty self-
explanatory, so any of them would do.

Smylers

Re: module name for test data?

[Paul LeoNerd Evans]

On Mon, Sep 28, 2009 at 05:37:17PM +0100, Smylers wrote:
 Jerome Quelin writes:
 
  - audio::mpd::common? (even if i don't think that's the best)
  - audio::mpd::test? this one is already used by a module in audio::mpd,
but that's not a problem (i plan to move audio::mpd::test somewhere in
t/lib/, so namespace would be free)
  - audio::mpd::testdata?
  - audio::mpd::common::test?
  - data::audio::mpd?
  - data::audio::mpd::test?
  - test::audio::mpd?
 
 I'd go for the latter (well, with some capital letters!) cos people are
 used to the idea that Test:: modules are used for testing rather than
 being part of the 'main function' of your program.
 
 But none of those names sound bad -- they're all pretty self-
 explanatory, so any of them would do.

If the module is for use purely during testing, and serves no other
useful purpose, I'd make sure to include the word Test (capitalised)
somewhere in its distribution name. The variations on common without
test would imply it's some sort of shared useful code to use in
production use.

-- 
Paul LeoNerd Evans

leon...@leonerd.org.uk
ICQ# 4135350   |  Registered Linux# 179460
http://www.leonerd.org.uk/


signature.asc
Description: Digital signature

Re: module name for test data?

[Jerome Quelin]

On 09/09/28 20:08 +0100, Paul LeoNerd Evans wrote:
 If the module is for use purely during testing, and serves no other
 useful purpose, I'd make sure to include the word Test (capitalised)
 somewhere in its distribution name. The variations on common without
 test would imply it's some sort of shared useful code to use in
 production use.

yes, i never capitalize when i'm writing (except code, of course). so
the proposed module names would be capitalized correctly, of course.

currently, it seems that test::audio::mpd gtes the most votes...

jérôme 
-- 
jque...@gmail.com

Re: Module name suggestions? - automatic per-OS subclass

[Paul LeoNerd Evans]

On Wed, Mar 25, 2009 at 04:09:12PM +, David Cantrell wrote:
 On Wed, Mar 25, 2009 at 11:25:15AM -0400, Jonathan Yu wrote:
 
  So, I guess this is just my long-winded way of saying that you should
  include a method of mapping operating systems to class names, but in a
  portable manner
 
 Devel::CheckOS is your friend.  It knows that, for example, Solaris,
 Irix and AIX are all Unix.

Having looked at it, it's not sufficient. When run on, say, Solaris, I
want to try in order:

  Foo::Bar::Solaris
  Foo::Bar::Unix
  Foo::Bar

Devel::CheckOS can't apply this ordering. I could get a list of all
possible supported names, then filter that by what this machine is.

I'm sure I recall in some code somewhere, the use of a list of possible
OS family names, from most to least specific, keyed by $^O. I'm thinking
something more like that would be best.

-- 
Paul LeoNerd Evans

leon...@leonerd.org.uk |CPAN ID: PEVANS
srand($,= );print sort{rand0.5}grep{0.8rand}qw(another Just hacker of Perl)


signature.asc
Description: Digital signature

Re: Module name suggestions? - automatic per-OS subclass

[Hans Dieter Pearcey]

On Thu, Mar 26, 2009 at 10:02:24AM -0700, Bill Ward wrote:
 I thought Devel was only for use in the development context, not in the 
 field
 in a deployed module.

I'm not sure what you mean by only -- whether you think that Dave should
rename his module, or that your expectations for the namespace don't match
other people's, or what -- but there are plenty of Devel modules that are used
in deployed modules (Declare, Symdump, GlobalDestruction, StackTrace, and
InnerPackage are all installed on my machine, for example).

hdp.

Re: Module name suggestions? - automatic per-OS subclass

[Paul LeoNerd Evans]

On Wed, Mar 25, 2009 at 05:57:45PM -0700, Bill Ward wrote:
 I'm not really liking any of the names that have been proposed so I'm going
 back to the original message to give my thoughts.
 
 The English name of $^O is $OSNAME, so there's precedent for OS.  I think
 it should use OS and not something like System.

That doesn't really narrow it down ;)

  ByOS
  PerOS
  ForOS
  OSSpecific
  OSMagic
  MagicOS
  ...

 As for where to put it, the way this would be useful to me would not be as
 any sort of object (which rules out Class::) but as a sort of assertion or
 query about the operating system.  You wouldn't need to instantiate any
 objects of this class, it would just be for asking what OS am I running
 on? so OO is really not needed except maybe for some @ISA magic.

This isn't about yes/no assertions. This is about always providing _an_
implementation of some code, but possibly providing a better one on some
OS if it can be done.

An actual example: Linux has pselect() and ppoll(), which allow safe
mixed IO-and-signal handling. Portably these don't exist. A Linux
implementation of IO::Async::Loop could use these to mix file IO and
signals safely; a portable base can't, so would have to make do with
something less.

 use OS has_symlinks;  # would fail under Windows
 use OS::linux;  # would fail under any non-Linux OS

That's not at all where I'm aiming here...

 What specific OS-related questions do you want this for?  Obviously not
 filesystem naming rules...

IT's the magic used to allow another class to provide per-OS
customisations. E.g. see my IO::Async example above :)

-- 
Paul LeoNerd Evans

leon...@leonerd.org.uk |CPAN ID: PEVANS


signature.asc
Description: Digital signature

Re: Module name suggestions? - automatic per-OS subclass

[Jonathan Yu]

Hi Paul:

This sounds like a great idea. However, I would recommend that when
you do write your module, you include some way of determining which
version is currently in use.

For example, it's difficult to detect which version of File::Spec is
in use, because it's set up so that it does @ISA =
('File::Spec::Unix'); Other classes, including the Win32 one, subclass
the Unix class to get its basic functionality too, so doing:
File::Spec-isa('File::Spec::Unix') doesn't work properly.

For reasons related to module naming, I wouldn't simply do:
File::Spec::$^O. Consider the case where Linux and OS/2 both use the
same class, Unix (as happens with File::Spec). Then simply appending
$^O will mean you need to copy the class for both 'linux' and 'OS2'.

File::Spec handles it internally by using a hash mapping to the
different modules where appropriate. But this might not work in
general (as your class is designed for), since the behaviours of
different operating systems are different. File::Spec does it because
filehandling on OS2 and Linux are similar, but other behaviours may be
different.

So, I guess this is just my long-winded way of saying that you should
include a method of mapping operating systems to class names, but in a
portable manner, so that you can later determine which one is
currently in use. I ran into this problem with one of my modules that
used File::Spec under Win32, where my program was expecting Unix-style
path names. So I needed a way to detect if File::Spec was running
under Unix. If not, then the module was to convert the path stuff to
Unix-like, which obviously isn't necessary if we're already running
under Unix. (This might not be possible under my current understanding
of how your module is supposed to work, since it appears to be as
zero-configuration as possible. Hopefully there is a way to pass
parameters before the call to your module's subclass-finding magic to
tell it about such aliases, since there are lots of $^O strings, that
might not be strictly necessary)

But, getting to what your module should be named, no good ideas really
come to mind. But if you're going to leave out the Magic class names
(personally I don't see anything wrong with it, and think
Class::OSMagic might be appropriate)... Then my next choice would be
Class::ForSystem, since it's not too long and conveys what the module
is designed to do.

Doing stuff like this can get pretty complicated, so I'm glad somebody
is working on something for it :-). Good work

Cheers,

Jonathan
(PAUSE: FREQUENCY)

On Tue, Mar 24, 2009 at 6:30 AM, Paul LeoNerd Evans
leon...@leonerd.org.uk wrote:
 I find a number of times, that I've wanted to make some code that
 certain OSes would have better implementations of than others, or just
 plain implement in a different way.

 There's some existing examples of code that does this; File::Spec comes
 to mind. It chooses a specific subclass at runtime, based on the OS
 choice ($^O), or falling back on a list of decreasing specificness if
 that isn't found. Another example here would be a Linux-specific
 subclass of File::Tail that can use Inotify rather than polling for
 stat(). I've had further thoughts on things like /proc-scraping, network
 interface information, etc...

 What all these have in common is that $^O is used as a key to build a
 list of possible module names, and the code then tries to load and use
 the first one in the list it finds. Perhaps in cases like File::Tail
 where the OS-specific class is simply more optimal, this could be an
 optional installation later on.

 I'd like to write a small module for automatically doing this sort of
 magic; I'm just in short of a name for it. I feel it ought to be
 Class-y; something like

   Class::OSMagic
   Class::OSSpecific
   Class::MagicOS
   Class::SystemSpecific
   Class::ForSystem

 As a brief example of code, consider the following hack on File::Tail.

 Two-line change to File/Tail.pm:

  use Class::OSMagic;

  # Rename constructor
  sub __new
  {
     ...
  }

 The 'use' line would automatically import a 'sub new' into the caller,
 which just does something like

  sub new
  {
     Class::OSMagic::find_best_subclass( shift )-__new( @_ );
  }

 The user of File::Tail need not know the difference; the normal

  my $tailer = File::Tail-new( $path );

 constructor is unaffected.

 If one day someone writes an Inotify-aware Linux extension, all they
 have to do is provide

  sub File::Tail::linux;  # note lowercase, to match $^O

  use Linux::Inotify;

  sub __new
  {
     ...
  }

 Now, any code that tries to use File::Tail objects on a Linux machine
 will automatically find this subclass if it is installed.


 There's a suggestion that the word 'magic' should be avoided - other
 ideas on the name?

 --
 Paul LeoNerd Evans

 leon...@leonerd.org.uk     |    CPAN ID: PEVANS

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

 iD8DBQFJyLYsvLS2TC8cBo0RAig4AJ9AvIGIeEi9KQPUMMZ2hiBxKJJjCwCfXl3O
 

Re: Module name

[Aristotle Pagaltzis]

* Miguel Pignatelli [EMAIL PROTECTED] [2008-01-03 10:20]:
 Maybe Tie::File::Formats or Tie::File::DataFormat could be
 a better choice.

The key idea is that you get a more complex data structure from a
line than just a string.

Tie::File::Record
Tie::File::Parsed

 Also, Tie::File::AnyData::CSV is a module that subclasses
 Tie::File::AnyData. It allows to group multiple CSV lines
 into 1 record based on a given field. I am looking for a proper
 name for this module too, maybe
 Tie::File::Formats::MultilineCSV.

Tie::File::Record::CSV::Grouped

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Module Name Proposal - Text::Report

[Johan Vromans]

D. Huggins [EMAIL PROTECTED] writes:

 I have created a module that will allow you to create neatly
 formatted, text based reports that contain any number of tables of
 various dimensions replete with configurable  optional titles, column
 headings, decorations, sorting, column alignment and more.

 Output can be a formatted report suitable for formal presentation
 and/or you can produce comma delimited data either by individual
 tables or the entire report.

Looks pretty much like Data::Report on steroids.

When I made Data::Report (and not Text::Report) I choose for that name
since it can (in theory) handle arbitrary data, not just text.

Would it be possible to merge these two? I that case I can hand you the
name Data::Report.

-- Johan

Re: Module Name Proposal - Text::Report

[D. Huggins]

On Fri, 29 Jun 2007 04:38:57 -0400, Johan Vromans [EMAIL PROTECTED] wrote:
 Looks pretty much like Data::Report on steroids.

 When I made Data::Report (and not Text::Report) I choose for that name
 since it can (in theory) handle arbitrary data, not just text.


I do like the idea of Data:: as opposed to Text:: It does seem to fit
better.

When I look specifically at, say Text::Format or Text::SimpleTemplate,
I see more text manipulation processes while I see Report.pm (yours 
mine) as more of a data transformation process.


 Would it be possible to merge these two? In that case I can hand you
 the name Data::Report.

I like the framework of your Data::Report. I have considered adding
capabilities for html  xml output. A base class/plugin model would
fit the bill for these additions. At this moment my vision of *how*
the two products would merge is vague. Suggestions (from anyone) would
be welcome.

The only hesitation that I would have regarding a merge would be the
development time. I know that it might seem a little silly, but I have
been diligently working on soliciting some new customers for contract
coding projects and would really like to add at least one CPAN credit
to my CV sooner rather than later and none of my other libraries are
quite ready for PAUSE yet.

Just thinking out loud...




Sincerely,
-David

  

David J. Huggins
Chief Design Engineer
Full-Duplex Communications Corporation
www.full-duplex.com
www.in-brandon.com

Re: Module Name Proposal - Text::Report

[Bill Ward]

Interesting module.  I think the name may be a little too generic but
I can't think of a better one.

As for paginating, you could always feed the output of your module
through format/write and let it handle the paginating :-)

Oh, I'm not thrilled about the namingConvention you use for arguments
to new().  I much prefer a naming_convention that is more consistent
with subroutine_names.  And I know log() is a reserved function name
so that's why you used Log, but maybe you could use something else,
like log_filehandle maybe, instead to get around that?

Love the bit about things that bark and meow and calling up relatives...

On 6/28/07, D. Huggins [EMAIL PROTECTED] wrote:

Wednesday, 27 June, 2007 10:34
Module Name Proposal - Text::Report


I have created a module that will allow you to create neatly
formatted, text based reports that contain any number of tables of
various dimensions replete with configurable  optional titles, column
headings, decorations, sorting, column alignment and more.

Output can be a formatted report suitable for formal presentation
and/or you can produce comma delimited data either by individual
tables or the entire report.



I've tried to keep the interface simple and flexible. There are three
components to configure.

The 'report' component includes the width of the report itself, the
way that the 'blocks' of data are ordered within the report (either
automatically or by explicit indexing) and the way that table titles
are printed for each 'block' or data set.

The 'block' component is manipulated by its name and can contain
either free-form string data, a decorative separator, or columnar data
as a table or footer. Columns in each block created can be
automatically sized or the size (width) and alignment can be defined
by the user either globally or per column.

An example of a block definition:
$rpt-defblock(name = 'data',
  title = 'Resultant Amalgamum Firnunciation Per Anum',
  useColHeaders = 1,
  columnAlign = 'right',
  cols = 6,
  pad = {top = 2, bottom = 2},);



The 'column' component is manipulated by the block name that contains
it and the column position in the table. Columns can be addressed
individually to tweak the alignment, width and the column header.

For example:
$rpt-setcol($blockname, $colnum, align = 'left', width = 7)



Building the report is easy. Once all of the report blocks are
defined, you apply the 3-dimensional data to the named block of choice
in the form of:

$obj-fill_block($blockname, @AoA)

Where:
@AoA = (
['data', 'data', 'data', 'data'],
['data', 'data', 'data', 'data'],
...);


Coughing up a report or csv data is even easier using

@report = $obj-report(['get' | 'print' | 'csv'])

There are numerous other features that I won't waste time detailing
here. Some are documented in the pod and others I will create examples
for.


I've also incorporated a feature that allows you to save the defined
report as a template (using Storable store()  retrieve()) and reuse
it. (This feature may not be documented in the pod yet)


I think the module is ready for prime time and I would appreciate a
blessing on the name and the module's desirability. And certainly any
feedback if anyone would like to take it for a spin.


The POD is here:
http://www.full-duplex.com/~pan/Text-Report-1.002.html

The Source can be found here:
http://www.full-duplex.com/~perl/lib/Text/Report.pm


This is my first contribution and seasoned advice is welcomed.

Thank you,

-David



David J. Huggins
Chief Design Engineer
Full-Duplex Communications Corporation
www.full-duplex.com
www.in-brandon.com






--
Help bring back the San Jose Earthquakes - http://www.soccersiliconvalley.com/

Re: Module name advice: Mobile::P2kMoto

[Bill Ward]

Why not Mobile::Moto4Lin to match the library?

On 6/24/07, Mattia Barbon [EMAIL PROTECTED] wrote:

  Hi,
I am making the wrappers for the p2kmoto library
(http://moto4lin.sf.net); despite the name, the library
should work on Win32 and Mac too.

  Looking on search.cpan.org, it seems that Phone is not a TLN,
while Mobile is already used, so I'd go for Mobile::P2kMoto,
but of course advice on the name is welcome :-)

Mobile::P2kMoto::openPhone( 3000 );
Mobile::P2kMoto::FS::searchRequest( '/a/*' );
Mobile::P2kMoto::FS::fileList( sub { print $_[0]-name, \n } );

Thanks in advance,
Mattia




--
Help bring back the San Jose Earthquakes - http://www.soccersiliconvalley.com/

Re: Module name advice: Mobile::P2kMoto

[Mattia Barbon]

On Sun, 24 Jun 2007 08:17:31 -0700
Bill Ward [EMAIL PROTECTED] wrote:

 Why not Mobile::Moto4Lin to match the library?

  Because the library is called p2kmoto :-) moto4lin
is a GUI program.  They are maintained as part of the same
project.  Also Lin recalls Linux, while the library is
supposed to be cross platform (I have seen code to that effect
in the sources).

Regards,
Mattia

Re: Module name - smoke testing automation

[Ovid]

--- A. Pagaltzis [EMAIL PROTECTED] wrote:

 makes no effective difference. I’d attack this directly by
 cleaning up $ENV{PATH}:
 
 use Config;
 use File::Spec::Functions;
 use File::stat;
 use Fcntl qw( :mode );
 
 $ENV{PATH} = do {
 my $sep = $Config{path_sep};
 
 join $sep, (
 map  { /(.*)/ }
 grep { ! stat($_)-mode  S_IWOTH }
 grep { file_name_is_absolute( $_ ) }
 split( /\Q$sep/, $ENV{PATH}, -1 ),
 );
 };

Turns out this solves an issue I have at work.  There were two issues I
uncovered.

1.  The server I tested this on had one entry in the PATH which didn't
exist on the server, so I first check to see if stat($_) returns a true
value.
2.  There was a precedence problem.  The not (!) binds tighter than the
bitwise and (), so parentheses were needed.

$ENV{PATH} = do {
my $sep = $Config{path_sep};

join $sep, (
map { /(.*)/ }
  grep { stat($_)  !( stat($_)-mode  S_IWOTH ) }
  grep { file_name_is_absolute($_) }
  split( /\Q$sep/, $ENV{PATH} ),
);
};

Cheers,
Ovid

--

Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/

Re: Module name - smoke testing automation

[Ovid]

--- Ovid [EMAIL PROTECTED] wrote:

 $ENV{PATH} = do {
 my $sep = $Config{path_sep};
 
 join $sep, (
 map { /(.*)/ }
   grep { stat($_)  !( stat($_)-mode  S_IWOTH ) }
   grep { file_name_is_absolute($_) }
   split( /\Q$sep/, $ENV{PATH} ),
 );
 };

Ugh.  I hated my double call to stat().

$ENV{PATH} = do {
my $sep = $Config{path_sep};

join $sep, ( 
map { /(.*)/ }
grep {
  local $_ = stat $_;
  defined  !( $_-mode  S_IWOTH )
}
grep { file_name_is_absolute($_) }
split( /\Q$sep/, $ENV{PATH}, -1 ),
);
};

Cheers,
Ovid

--

Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/

RE: Module name - smoke testing automation

[Pearce, Martyn]

Functionally, stat(_) avoids actually doing a second stat.
Of course, your gripe may be aesthetic, which this won't help. 

-Original Message-
From: Ovid [mailto:[EMAIL PROTECTED] 
Sent: Monday, April 16, 2007 11:52 AM
To: module-authors@perl.org
Subject: Re: Module name - smoke testing automation

--- Ovid [EMAIL PROTECTED] wrote:

 $ENV{PATH} = do {
 my $sep = $Config{path_sep};
 
 join $sep, (
 map { /(.*)/ }
   grep { stat($_)  !( stat($_)-mode  S_IWOTH ) }
   grep { file_name_is_absolute($_) }
   split( /\Q$sep/, $ENV{PATH} ),
 );
 };

Ugh.  I hated my double call to stat().

$ENV{PATH} = do {
my $sep = $Config{path_sep};

join $sep, ( 
map { /(.*)/ }
grep {
  local $_ = stat $_;
  defined  !( $_-mode  S_IWOTH )
}
grep { file_name_is_absolute($_) }
split( /\Q$sep/, $ENV{PATH}, -1 ),
);
};

Cheers,
Ovid

--

Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/

Re: Module name - smoke testing automation

[A. Pagaltzis]

Hi Ovid,

* Ovid [EMAIL PROTECTED] [2007-04-16 12:45]:
 1. The server I tested this on had one entry in the PATH which
 didn't exist on the server, so I first check to see if stat($_)
 returns a true value.

But you do it with a double stat, hmm.

 2. There was a precedence problem.  The not (!) binds tighter
 than the bitwise and (), so parentheses were needed.

Oh yeah. I wrote this with only a single grep doing both the
absolute check and the mode check at first, then decided to pull
them apart for readability. Generally I prefer the low-precedence
set of boolean ops so I don’t have good instincts for composition
with the other set. I should have stuck with `not`… oh, and
*tested* the code after rewriting it.

use Config;
use File::Spec::Functions;
use File::stat;
use Fcntl qw( :mode );

$ENV{PATH} = do {
my $sep = $Config{path_sep};

join $sep, (
map  { /(.*)/ }
grep { my $s = stat($_); $s and not $s-mode  S_IWOTH }
grep { file_name_is_absolute($_) }
split( /\Q$sep/, $ENV{PATH} ),
);
};

(And this time it’s tested.)

-- 
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1}
Just-another-Perl-hack;
#Aristotle

Re: Module name - smoke testing automation

[A. Pagaltzis]

* Ovid [EMAIL PROTECTED] [2007-04-16 12:55]:
 Ugh.  I hated my double call to stat().
 
 $ENV{PATH} = do {
 my $sep = $Config{path_sep};
 
 join $sep, ( 
 map { /(.*)/ }
 grep {
   local $_ = stat $_;
   defined  !( $_-mode  S_IWOTH )
 }
 grep { file_name_is_absolute($_) }
 split( /\Q$sep/, $ENV{PATH}, -1 ),
 );
 };

Note that `local $_` has issues when tieing or other magic are
involved. If you want to topicalise something, use `for` instead.
That’s not viable in this case, though, since `for` doesn’t
return a well-defined value and you need that for `grep`. Better
just use a lexical variable.

Also note that if `stat` succeeds it will return an object, which
can never be false. Testing definedness is therefore unnecessary,
you can just test truth.

Finally, if you switch to the low-precedence boolops you can get
rid of those parens. At that point you have the version I posted.

What I learned from this excercise is that Perl has no good API
to encapsulate stat(2). What I *wanted* to write is this:

$s and $s-perm( 'o-w' )

where the `o-w` is a string that follows symbolic chmod mode
syntax. (So `o-w` means “others may not write”, `o+w` means
“others may write”, and `o=w` means “others may write, but not
read or execute,” and you can equally use variations on the theme
like `ug+rx,o=x`.)

That is much easier to decipher than all that C-ish bitfiddle.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Module name - smoke testing automation

[Ovid]

--- A. Pagaltzis [EMAIL PROTECTED] wrote:

 Note that `local $_` has issues when tieing or other magic are
 involved. If you want to topicalise something, use `for` instead.
 That’s not viable in this case, though, since `for` doesn’t
 return a well-defined value and you need that for `grep`. Better
 just use a lexical variable.

Thanks for this and the other comments.  Great points. 
 
Cheers,
Ovid

--

Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/

Re: Module name - smoke testing automation

[Ovid]

--- Dave Rolsky [EMAIL PROTECTED] wrote:

 Well, it's a little more programmatic than that. The svn up part is 
 dirt-simple, but doing something like running svn info $uri against
 the repo uri to get the last changed date requires some code and
 regular expressions and whatnot.

Out of curiosity, what's your cross-platform way of figuring out the
full path to the svn executable?  Just doing system('svn', 'info',
$uri) can get you an Insecure $ENV{PATH} (or something like that)
when running in taint mode.

Cheers,
Ovid

--

Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/

Re: Module name - smoke testing automation

[Dave Rolsky]

On Sun, 15 Apr 2007, Ovid wrote:


--- Dave Rolsky [EMAIL PROTECTED] wrote:


Well, it's a little more programmatic than that. The svn up part is
dirt-simple, but doing something like running svn info $uri against
the repo uri to get the last changed date requires some code and
regular expressions and whatnot.


Out of curiosity, what's your cross-platform way of figuring out the
full path to the svn executable?  Just doing system('svn', 'info',
$uri) can get you an Insecure $ENV{PATH} (or something like that)
when running in taint mode.


I was going to use File::Which. I don't know if that will work under taint 
mode, but I never use taint mode anyway ;)



-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/

Re: Module name - smoke testing automation

[A. Pagaltzis]

* Dave Rolsky [EMAIL PROTECTED] [2007-04-15 16:35]:
 On Sun, 15 Apr 2007, Ovid wrote:
 Just doing system('svn', 'info', $uri) can get you an
 Insecure $ENV{PATH} (or something like that) when running in
 taint mode.
 
 I was going to use File::Which.

What’s the point? File::Which examines the PATH to locate
executables, so whether you do  

my $svn = which( 'svn' );
system( $svn, 'status' );

or

system( 'svn', 'status' );

makes no effective difference. I’d attack this directly by
cleaning up $ENV{PATH}:

use Config;
use File::Spec::Functions;
use File::stat;
use Fcntl qw( :mode );

$ENV{PATH} = do {
my $sep = $Config{path_sep};

join $sep, (
map  { /(.*)/ }
grep { ! stat($_)-mode  S_IWOTH }
grep { file_name_is_absolute( $_ ) }
split( /\Q$sep/, $ENV{PATH}, -1 ),
);
};

This splits the PATH on its platform-specific separators, weeds
out relative entries, weeds out world-writable directories, and
finally rubberstamps them all as sane, before joining them all
back on the platform’s PATH separator.

Maybe this deserves to go in some module. It took an arguably
unreasonable amount of time to gather and arrange all the cogs,
as the train of modules I ended up pulling in illustrates – and
that’s not even the full list of modules whose docs and source(!)
I referred to.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Module name - smoke testing automation

[Darren Chamberlain]

On 4/15/07, A. Pagaltzis [EMAIL PROTECTED] wrote:

Maybe this deserves to go in some module.


Yeah, File::Which.

--
(darren)

Re: Module name - smoke testing automation

[Andy Lester]

On Apr 13, 2007, at 11:58 AM, Dave Rolsky wrote:

The core idea is that there are multiple test sets, which is  
really any directory that contains a t/ subdirectory with .t files.  
The app will be a script you can call from cron to run a test set,  
and the order is determined by how out of date a test set is,  
whether it's been marked as prioritized, etc.


Also it needs to be able to run on multiple configurations, so you  
can have Makefile.PL or configure with multiple sets of arguments.


xoa

--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance

Re: Module name - smoke testing automation

[Eric Wilhelm]

# from Dave Rolsky
# on Friday 13 April 2007 09:58 am:

I'm working on a module/app that will be used to automate testing
 multiple branches of a code base.
...
Internally so far I've been calling it Test::SmokeRunner, which seems
 like a reasonable name, but I'm open to suggestions.

I would say it's not really a Test:: module if it doesn't get use()d by 
tests.  Of course, Test::Harness and other harnesses have already 
invaded, so I suppose history wins again.  Is it too late to dub 
Tester:: or TestDriver:: or RunTests:: or AutoTest:: (or 
something) as the home for things that run tests?

I would like to see multi or sets in the name.  Provided that the 
svn stuff is not inherent to what you're building, maybe 
Tester::RunMulti or Tester::RunSets?

--Eric
-- 
Turns out the optimal technique is to put it in reverse and gun it.
--Steven Squyres (on challenges in interplanetary robot navigation)
---
http://scratchcomputing.com
---

Re: Module name - smoke testing automation

[Dave Rolsky]

On Fri, 13 Apr 2007, Eric Wilhelm wrote:


If your 'svn up' support and other aspects were configured as pre_smoke
directives in a config, that might make it more easily adaptable than
if the code has to be subclassed to do something different.


Well, it's a little more programmatic than that. The svn up part is 
dirt-simple, but doing something like running svn info $uri against the 
repo uri to get the last changed date requires some code and regular 
expressions and whatnot.



-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/

Re: Freedesktop::Trash (was Re: Module name - File::Trash::FreeDesktop)

[A. Pagaltzis]

* Robert Rothenberg (CPAN) [EMAIL PROTECTED] [2006-03-03 21:15]:
Does anyone have anything against starting a new top-level hierarchy?

In this instance, I don’t.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Module name - File::Trash::FreeDesktop

[Eric Wilhelm]

# from Robert Rothenberg (CPAN)
# on Monday 27 February 2006 09:36 am:

Freedesktop::Trash seems to be the obvious name, but there's nothing
 in the Freedesktop top-level namespace.

How about Freedesktop::File::Trash ?  With FD aiming to be a standard, I 
would rather see all of the modules which implement it under a single 
tlns (even in a tree which mirrors the generic modules which are 
already there -- e.g. FreeDesktop::Image::Thumbnail for the thumbnails 
standard, etc.)

X11::FreeDesktop:DesktopEntry is the only precedent and I'm inclined to 
think it should have been in the FD tlns as FreeDesktop::DesktopEntry.

IMO, File::Trash::FreeDesktop sounds too much like it aims to trash my 
fd-related files :-)

--Eric
-- 
...the bourgeoisie were hated from both ends: by the proles, because
they had all the money, and by the intelligentsia, because of their
tendency to spend it on lawn ornaments.
--Neal Stephenson
---
http://scratchcomputing.com
---

Re: Module name advice

[José Castro]

* David Golden ([EMAIL PROTECTED]) wrote:
 Mattia Barbon [EMAIL PROTECTED] wrote:
   Having discarded a top-level namespace, I am now
 inclined to use WWW::Selenium for the Selenium driver
 and Test::Selenium for the TAP-emitting module
 to be used in test scripts. 
 
   Does anybody have suggestions?
 
 For consistency with WWW::Mechanize and Test::WWW::Mechanize (and other 
 Test::WWW tools), I'd suggest going with WWW::Selenium and 
 Test::WWW::Selenium.

I second that (I was actually going to say the same thing).

Cheers,

jac

--
Jose Alves de Castro [EMAIL PROTECTED]
  http://jose-castro.org/

Re: Module name advice

[David Golden]

Mattia Barbon [EMAIL PROTECTED] wrote:

  Having discarded a top-level namespace, I am now
inclined to use WWW::Selenium for the Selenium driver
and Test::Selenium for the TAP-emitting module
to be used in test scripts. 


  Does anybody have suggestions?


For consistency with WWW::Mechanize and Test::WWW::Mechanize (and other 
Test::WWW tools), I'd suggest going with WWW::Selenium and Test::WWW::Selenium.


Regards,
David Golden

Re: Module Name: Net::Lite::FTP

[David Nicol]

On Sat, 8 Jan 2005 04:26:29 +0100, A. Pagaltzis [EMAIL PROTECTED] wrote:
 But ::Lite is misleading anyway. It's not the module's goal to be
 a light implementation of FTP, rather it intends to support
 things Net::FTP doesn't.


So call it something else -- to load it -- but internally, keep the
Net::FTP package
name do it can be droppped in to provide those extra things ---

 # use Net::FTP; but I wantTLS!
 use Net::FTP::NotByGBARR;
 my $ftp = new Net::FTP ...



-- 
David L Nicol
You're striving for harmony, and, if you try to take
 too much, you'll come to grief.  -- Michael Redmond

Re: Module Name: Net::Lite::FTP

[A. Pagaltzis]

* Dariush Pietrzak [EMAIL PROTECTED] [2005-01-08 01:24]:
  Bad name. That should be Net::FTP::Lite.
 My code has nothing to do with Net::FTP, it's not a subclass or
 anything, I believe Graham Barr could get offended if someone
 was to associate my code with his masterpiece.

Sure it has something to do with Net::FTP -- it does a very
similar thing. It has as much to do with Net::FTP as
Net::CIDR::Lite has to do with Net::CIDR.

The name is bad. It's not an FTP doodad for an implementation of
Lite which is a network thing. It's a Lite version of an
implementation of the FTP protocol, which is a network thing. So
the name is Net::FTP::Lite, if anything.

But ::Lite is misleading anyway. It's not the module's goal to be
a light implementation of FTP, rather it intends to support
things Net::FTP doesn't.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1}
Just-another-Perl-hacker;

Re: Module Name: Net::Lite::FTP

[A. Pagaltzis]

* Dariush Pietrzak [EMAIL PROTECTED] [2005-01-05 11:59]:
 This module is very simple, but provides access to TLS-enabled
 servers, and is going to be a testbed for few relatively new
 extensions to ftp
 
  Intented usage:
   my $tlsftp=Net::Lite::FTP-new();

Bad name. That should be Net::FTP::Lite.

I don't really like the ::Lite part though.

I would suggest something with TLS in the name but you said that
it's a testbed for new FTP features, so that wouldn't be its sole
focus.

Something like ::More might be better suited to convey what the
module is supposed to do (ie support more FTP extensions than
Net::FTP at the cost of reliability).

Then put a mention in the POD that this module is awaiting
obsoletion by Net::FTP when it gains TLS support, that people
should patch Net::FTP instead of this module, and work with
Graham to get Net::FTP where you want it. If nothing else,
putting the code out there might inspire someone else to port the
features to Net::FTP in your stead.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1}
Just-another-Perl-hacker;

Re: Module Name: Net::Lite::FTP

[David Nicol]

call it Net::FTP2 with the same caveats and reccommenddations

and include blat and slurp methods! I don't want to have
to create and release Net::FTP2::blat when I want to work
with remote data over secure FTP.


my two rusty bottlecaps,

david nicol

Re: Module Name: Net::Lite::FTP

[Dariush Pietrzak]

On Wed, 5 Jan 2005, Austin Schutz wrote:
   Why not just add the functionality to Net::FTP? Or you could
 subclass Net::FTP and call it something clever like Net::FTP::TLS.
 Because Net::FTP is written in a way that makes it extremely hard to make
needed modifications. 
 It is a very well-thought, large and organized object hierarchy.
I tried adding TLS support to it almost 2years ago, contacted it's author,
heard that there is large redesign coming, which will allow changes needed
for encryption, however there is still no TLS in Net::FTP, and I'm sitting
here on encryption-enabled client for the past two years.
 Do you think that I should keep it to myself for the next few years?

Additionally Net::FTP works with very large range of ftpservers, which
fills code with lots and lots of special cases, this (and elaborate object
hierarchy) makes it very hard for someone to come and extend it, and after
trying to do that, I can only conclude that I'm too stupid to be playing
with its internals.
-- 
Key fingerprint = 40D0 9FFB 9939 7320 8294  05E0 BCC7 02C4 75CC 50D9
We're giving you a new chance in life, and an opportunity
 to screw it up in a new, original way.

Re: Module Name: Net::Lite::FTP

[David Landgren]

Dariush Pietrzak wrote:
On Wed, 5 Jan 2005, Austin Schutz wrote:
Why not just add the functionality to Net::FTP? Or you could
subclass Net::FTP and call it something clever like Net::FTP::TLS.
 Because Net::FTP is written in a way that makes it extremely hard to make
needed modifications. 
 It is a very well-thought, large and organized object hierarchy.
Net::FTP?
I tried adding TLS support to it almost 2years ago, contacted it's author,
heard that there is large redesign coming, which will allow changes needed
for encryption, however there is still no TLS in Net::FTP, and I'm sitting
here on encryption-enabled client for the past two years.
 Do you think that I should keep it to myself for the next few years?
No, you should release it ASAP.
Additionally Net::FTP works with very large range of ftpservers, which
fills code with lots and lots of special cases, this (and elaborate object
hierarchy) makes it very hard for someone to come and extend it, and after
trying to do that, I can only conclude that I'm too stupid to be playing
with its internals.
Well that doesn't jibe with well-thought and organized, but I guess 
that means I'm stupid too. I've been using Net::FTP for 8 years or so, 
and I never even knew there was a hierarchy. Or are you referring to 
Net::Cmd?

I'd still favour going with the name Net::FTP::TLS, even if it isn't 
subclassed from Net::FTP. If the redesign ever comes down the pipe, you 
could reimplement by subclassing and keep the interface the same? I 
think that people will look for Net::FTP and drill down, not go up from 
Net::FTP and do a breadth-first search in the CPAN namespace.

Or do you foresee that it might also be possible to write 
Net::TLS::SMTP, Net::TLS::LDAP, Net::TLS::Foomatic?

David

Re: Module Name: Net::Lite::FTP

[Jrme Fenal]

David Landgren wrote:
Dariush Pietrzak wrote:
On Wed, 5 Jan 2005, Austin Schutz wrote:
Why not just add the functionality to Net::FTP? Or you could 
subclass Net::FTP and call it something clever like 
Net::FTP::TLS.
...
I'd still favour going with the name Net::FTP::TLS, even if it isn't
 subclassed from Net::FTP. If the redesign ever comes down the pipe,
 you could reimplement by subclassing and keep the interface the
same? I think that people will look for Net::FTP and drill down, not
go up from Net::FTP and do a breadth-first search in the CPAN
namespace.
Net::FTP::TLS++.
And later just add a start_tls when Net::FTP is redesigned.
Or do you foresee that it might also be possible to write 
Net::TLS::SMTP, Net::TLS::LDAP, Net::TLS::Foomatic?
No, as you can put any protocol in a TLS/SSL tunnel, you should keep
Net::FTP::TLS.
SSL is just a transport as TCP or SSH.
TLS is an extension for protocols as a mean to switch to
encrypted mode (SSL) on the same TCP connection as the non encrypted
one. TLS extensions are not always available for all protocols.
Oh, and there's already a Net::LDAPS module (in perl-ldap), and
Net::LDAP objects also have a start_tls method which works differently
than Net::LDAPS ones.
Regards,
J.
--
$A+=3%2?1:0
Jrme Fenal
jfenalml at free point fr
http://fenal.org/

Re: Module Name: Net::Lite::FTP

[Dana Hudes]

Reinventing the wheel is a bad idea.
FTP looks simple but you have to consider all manner of issues
such as buffer overflows and so forth.
I'd much rather see you work with the existing Net::FTP
and enhance it either by patching or by subclassing.

Net::FTP is widely used therefore bugs and other oddities
are spotted and fixed more rapidly.



On Wed, 5 Jan 2005, Dariush Pietrzak wrote:

 Hi,
  I'm going to release on CPAN simple FTP client implementation.
 This module is very simple, but provides access to TLS-enabled servers, and
 is going to be a testbed for few relatively new extensions to ftp, like
 statefull-firewall-piercing-while-encrypting-both-data-and-control-channel;).
 
  Intented usage:
   my $tlsftp=Net::Lite::FTP-new();
   $tlsftp-open(ftp.tls.pl,21);
   $tlsftp-user(user);
   $tlsftp-pass(password);
   $tlsftp-command( PBSZ 0);#Required at the momemnt
   $tlsftp-command(PROT P);#Required at the momemnt
   $tlsftp-cwd(pub);
   my @files=$tlsftp-nlist(*.exe);
   foreach $f (@files) {
   $tlsftp-get($f);
   };
 
 
 -- 
 Key fingerprint = 40D0 9FFB 9939 7320 8294  05E0 BCC7 02C4 75CC 50D9
 We're giving you a new chance in life, and an opportunity
  to screw it up in a new, original way.
 

Re: Module Name: Net::Lite::FTP

[Ovid]

--- Dana Hudes [EMAIL PROTECTED] wrote:
 Reinventing the wheel is a bad idea.

Reinventing the wheel is *often* a bad idea.  Never say never :)

 I'd much rather see you work with the existing Net::FTP
 and enhance it either by patching or by subclassing.

If I understood the original author correctly, he could not patch
Net::FTP because those working on Net::FTP were changing things and
not accepting new features.  This has been going on for a couple of
years.  How many more years should we wait for this to be finished?

Also, sometimes subclassing things is more trouble than it's worth. 
Perl is not exactly a great language for subclassing.  Further, if the
Net::FTP code is as bad as those on this list imply, subclassing could
be virtually impossible.  Just try subclassing CGI.pm, for example. 
I've done it, but it turned out to be more difficult than one would
think and most would get it wrong.  In fact, I got it wrong until
Lincoln Stein pointed out my error :)

Cheers,
Ovid

=
Silence is Evil
http://users.easystreet.com/ovid/philosophy/decency.html
Ovid   http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl  http://users.easystreet.com/ovid/cgi_course/

RE: Module Name: Net::Lite::FTP

[Orton, Yves]

Title: RE: Module Name: Net::Lite::FTP





On 05 January 2005 18:16 Ovid wrote:
  I'd much rather see you work with the existing Net::FTP
  and enhance it either by patching or by subclassing.
 
 If I understood the original author correctly, he could not patch
 Net::FTP because those working on Net::FTP were changing things and
 not accepting new features. This has been going on for a couple of
 years. How many more years should we wait for this to be finished?


IMO the only person who can speak to this particular point is Graham Barr. 


Until Graham says its not worth waiting for IMO the best thing is to work towards putting the TLS functionality in that module. 

If the OP has difficulty doing so then perhaps he could or should ask for help to do so. 


Im sure the folks on Perlmonks for one would be happy to help.


Yves

Re: Module Name: Net::Lite::FTP

[Austin Schutz]

On Wed, Jan 05, 2005 at 02:19:31PM +0100, Dariush Pietrzak wrote:
 On Wed, 5 Jan 2005, Austin Schutz wrote:
  Why not just add the functionality to Net::FTP? Or you could
  subclass Net::FTP and call it something clever like Net::FTP::TLS.
  Because Net::FTP is written in a way that makes it extremely hard to make
 needed modifications. 
  It is a very well-thought, large and organized object hierarchy.
 I tried adding TLS support to it almost 2years ago, contacted it's author,
 heard that there is large redesign coming, which will allow changes needed
 for encryption, however there is still no TLS in Net::FTP, and I'm sitting
 here on encryption-enabled client for the past two years.
  Do you think that I should keep it to myself for the next few years?
 

No.

 Additionally Net::FTP works with very large range of ftpservers, which
 fills code with lots and lots of special cases, this (and elaborate object
 hierarchy) makes it very hard for someone to come and extend it, and after
 trying to do that, I can only conclude that I'm too stupid to be playing
 with its internals.
 -- 

I hear you, really. But as you say, it works with a large range
of ftp servers, with workarounds for the buggy ones, etc.
If you submit your work to Graham and have no luck getting it
incorporated, then never mind. But it would be a shame to have really
large amounts of duplicated effort, especially when people are submitting
reports to you for the same bugs he fixed in Net::FTP years ago.
Additionally I agree with the suggestion of trying to get some
assistance via perlmonks. It may be easier to use Net::FTP as a base class
than you think.. or maybe delegate to a Net::FTP object where useful.

All that said, if you're really just not interested in pursuing that,
then go ahead and release it. Someone else could incorporate it into
Net::FTP at some later date if there's interest. If you go that route
please don't call it Net::FTP::TLS. :-)

Austin

Re: Module Name

[Darren Chamberlain]

David Landgren wrote:
Terrence Brannon wrote:
 I believe you can do everything that this module does using
 Parse::RecDescent.
Maybe so, but Parse::RecDescent is slow, and that in itself is reason
enough to avoid using it. You also have to write the grammar, which can
take a non-trivial amount of time to design and test.
It doesn't need to be slow, at least not after the first run, since
you can have it compile the grammar into executable Perl.
(darren)


signature.asc
Description: OpenPGP digital signature

Re: Module Name

[Xavier Noria]

On Dec 25, 2004, at 10:51 PM, Alberto Manuel Brandao Simoes wrote:
I'm designing a new module to include a little rewritting language on 
Perl. It will be based on Filter::Simple.

First, I imagined :
Text::Rewrite
Then
Inline::Rewrite
The language makes you able to define rules, and join that rules on a 
function you can call from Perl code. The rules map regular 
expressions on other regular expressions.
I don't see clearly the usage or purpose of the module from that 
description.

The module seems to be a source filter. One that allows the user to map 
regular expressions from a given definition using rules. Those rules 
can be joined into a Perl function that can be called..., I am lost.

To get the picture. Can you give some usage example? Can you describe a 
situation where the module can be useful? From that summary I would 
expect kind of a wrapper of FILTER_ONLY regex = ... but then which is 
the role of that function of joined rules? When would it be 
constructed? Which code would use it?

-- fxn

Re: Module Name

[Alberto Manuel Brandao Simoes]

Xavier, maybe I didn't explain it correctly.
THe idea:
RULES foo
aa==bb
cd==ef
ENDRULES
and it creates the function foo which receives a string, and applies the 
rules while possible, rewritting the string.

There are very interesting purposes for this module. We wrote a full 
text-to-speech system based on such rules. Now, we want to make it a 
module to put the text cleaner.

Cheers,
Alb
Xavier Noria wrote:
On Dec 25, 2004, at 10:51 PM, Alberto Manuel Brandao Simoes wrote:
I'm designing a new module to include a little rewritting language on 
Perl. It will be based on Filter::Simple.

First, I imagined :
Text::Rewrite
Then
Inline::Rewrite
The language makes you able to define rules, and join that rules on a 
function you can call from Perl code. The rules map regular 
expressions on other regular expressions.

I don't see clearly the usage or purpose of the module from that 
description.

The module seems to be a source filter. One that allows the user to map 
regular expressions from a given definition using rules. Those rules can 
be joined into a Perl function that can be called..., I am lost.

To get the picture. Can you give some usage example? Can you describe a 
situation where the module can be useful? From that summary I would 
expect kind of a wrapper of FILTER_ONLY regex = ... but then which is 
the role of that function of joined rules? When would it be constructed? 
Which code would use it?

-- fxn
--
Alberto Simões - Departamento de Informática - Universidade do Minho
,,__
   ..  ..   / o._)   .---.
  /--'/--\  \-'||...' '.
 /\_/ / |  .'  '..' '-.
   .'\  \__\  __.'.' .'  ì-._
 )\ |  )\ |  _.'
// \\ // \\
   ||_  \\|_  \\_ Perl Monger
   mrf '--' '--'' '--'www.perl-hackers.net

Re: Module Name

[Alberto Manuel Brandao Simoes]

your original post said something about regular expressions.
True. It support them
RULES foo
a(b+)c==c$1a!!length($1)5
ENDRULES
so, abbbc gets cbbba if the number of b greater than 5.
Regexp::Rules is the name I'm pointing to, at the moment.
THanks for helping me with the brainstorming.
Alberto
--
Alberto Simões - Departamento de Informática - Universidade do Minho
,,__
   ..  ..   / o._)   .---.
  /--'/--\  \-'||...' '.
 /\_/ / |  .'  '..' '-.
   .'\  \__\  __.'.' .'  ì-._
 )\ |  )\ |  _.'
// \\ // \\
   ||_  \\|_  \\_ Perl Monger
   mrf '--' '--'' '--'www.perl-hackers.net

Re: Module Name

[Xavier Noria]

On Dec 26, 2004, at 10:03 PM, Alberto Manuel Brandao Simoes wrote:
Regexp::Rules is the name I'm pointing to, at the moment.
I would go for the Text:: namespace instead, since the module is about 
transforming text by means of chained substitutions. In the Regexp:: 
namespace modules are generally about regexps themselves.

I haven't found a name that convinces me by now though.
-- fxn

Re: Module Name

[Alberto Manuel Brandao Simoes]

I have the module ready at the moment, named Text::Rewrite (the original 
name I though about)

I'll ask co-author tomorrow for a name. Maybe something like
 Text::RegExp::Rules
 Text::Rewrite::Rules (like this one)
Albie
Xavier Noria wrote:
On Dec 26, 2004, at 10:03 PM, Alberto Manuel Brandao Simoes wrote:
Regexp::Rules is the name I'm pointing to, at the moment.

I would go for the Text:: namespace instead, since the module is about 
transforming text by means of chained substitutions. In the Regexp:: 
namespace modules are generally about regexps themselves.

I haven't found a name that convinces me by now though.
-- fxn
--
Alberto Simões - Departamento de Informática - Universidade do Minho
,,__
   ..  ..   / o._)   .---.
  /--'/--\  \-'||...' '.
 /\_/ / |  .'  '..' '-.
   .'\  \__\  __.'.' .'  ì-._
 )\ |  )\ |  _.'
// \\ // \\
   ||_  \\|_  \\_ Perl Monger
   mrf '--' '--'' '--'www.perl-hackers.net

Re: Module Name

[Dylan Hardison]

On Sat, 25 Dec 2004 21:51:18 +, Alberto Manuel Brandao Simoes
[EMAIL PROTECTED] wrote:
 I'm designing a new module to include a little rewritting language on
 Perl. It will be based on Filter::Simple.
 
 First, I imagined :
 
 Text::Rewrite
 
 Then
 
 Inline::Rewrite
 
 The language makes you able to define rules, and join that rules on a
 function you can call from Perl code. The rules map regular expressions
 on other regular expressions.
 
 Thanks for any idea.
 Alberto


Perhaps Filter::Rewrite::Regexp?

-- 
Oh, you cannae shove yer granny off a bus, Oh, you cannae shove yer
granny off a bus,
you cannae shove your granny, 'cause she's yer mammy's mammy.

Re: module name for Wily (a text editor) interface client?

[Christopher Hicks]

On Tue, 3 Aug 2004, Sam Holden wrote:
I would argue that Wily is just as much a way of life as Emacs and Vi.
No doubt.
However, it certainly isn't anywhere near as popular - chances are 
you've never heard of it...
I heard of it when I went to see what the heck a module called Wily was 
all about actually.  I did this only a few days ago, but before this 
thread started.

It doesn't warrant a toplevel namespace all to itself - though of course 
my current code uses one :)
You're hardly the only CPANer guilty of this.
There are two Wily modules in existance at the moment (that I know of), 
but they do the same thing - one uses XS to link with the wily libs, 
whereas mine uses pack/unpack to decode the messages itself. But yes, 
there's much less scope for multiple modules (due to the fact that the 
intersection of wily users and perl programmers is small...)
How about TextEditor::WilyPP.  Is PP recognized as pure perl widely 
enough?  If the XS-based module owner could be convinced to switch to 
TextEditor::Wily you'd really be starting a trend.

--
/chris

Re: module name for Wily (a text editor) interface client?

[Sam Holden]

Christopher Hicks writes:
On Tue, 3 Aug 2004, Sam Holden wrote:
[snip]

 There are two Wily modules in existance at the moment (that I know of), 
 but they do the same thing - one uses XS to link with the wily libs, 
 whereas mine uses pack/unpack to decode the messages itself. But yes, 
 there's much less scope for multiple modules (due to the fact that the 
 intersection of wily users and perl programmers is small...)

How about TextEditor::WilyPP.  Is PP recognized as pure perl widely 
enough?  If the XS-based module owner could be convinced to switch to 
TextEditor::Wily you'd really be starting a trend.

I'd be more inclined to modify the existing XS module and my non-XS
module to have the same interface. Currently you could replace
my Wily::Message and Wily::RPC modules with XS modules easily enough
(since they are simply perlifications of the msg.c and rpc.c code
from Wily - well actually they are perlifications of the
pythonifications of that code - which actually made it too OO for
my perl tastes, but it was quicker to code).

That way the same Wily.pm wrapper could be used to give a nicer (of
course that term is very subjective) interface to both versions of
the code.

A little like Text::CSV_XS and Text::CSV (though I don't know if they
have the same interface, it's just one case I know of where an XS
version and a non-XS version exist). Of course in that case performance
might actually matter, I doubt it ever will when interfacing to a text
editor with a message-response interface over a unix domain socket.

I don't think the XS code is on CPAN anyway, the author is on the
wilyfans mailing list though so I'm sure something could be arranged.

Anyway TextEditor::Wily seems like a reasonable thing to try, so unless
there are any obvious problems with that I'll ask for it tomorrow.

-- 
Sam

Re: module name for Wily (a text editor) interface client?

[Christopher Hicks]

On Mon, 2 Aug 2004, Sam Holden wrote:
Namespace wise, Text::Wily was suggested on comp.lang.perl.modules, but 
the module itself has almost nothing to do with text - it interfaces to 
a text editor which I think is a very different thing.
I would think the existing examples might provide some light on this but 
the modules to interface to emacs seem to be in their own Emacs:: space 
and the vi-related modules seem to be in Vi::.  I'm not sure what the 
received wisdom is for the right way to do this would be, but the option 
based on precedents could only be Wily::.

Text:: may seem inappropriate in one sense, but in any classification 
system you're going to have things that almost fit one place, but don't 
fit anywhere else at all.  Going with the almost fit is often the right 
choice rather than trying to create perfect categories for everything. 
The worst case for not going with almost fit is that you end up with /n/ 
objects in /n/ categories eventually and there's no point in the 
categories anymore.

Speaking of categories, why do we have a Commercial Software Interfaces, 
but not a Noncommercial Software Interfaces?  Is that intentional?

--
/chris

Re: module name for Wily (a text editor) interface client?

[Smylers]

Christopher Hicks writes:

 I would think the existing examples might provide some light on this
 but the modules to interface to emacs seem to be in their own Emacs::
 space and the vi-related modules seem to be in Vi::.  I'm not sure
 what the received wisdom is for the right way to do this would be,
 but the option based on precedents could only be Wily::.

But 'Vi' and 'Emacs' are arguable more a Way of Life than a mere editor
-- also they are so widely known by many people (especially those with a
Unix background) that there isn't much chance of confusion or ambiguity
with their names.

That possibly doesn't apply to 'Wily'.  Or, more to the point, it
certainly doesn't apply to every possible application that anybody could
ever want to create a Perl interface to.

There are some 'Excel'-related modules in the Spreadsheet:: namespace.
I think creating an Editor:: namespace for 'Wily' would be reasonable.

Smylers

Re: module name for Wily (a text editor) interface client?

[Christopher Hicks]

On Mon, 2 Aug 2004, Smylers wrote:
Christopher Hicks writes:
I would think the existing examples might provide some light on this
but the modules to interface to emacs seem to be in their own Emacs::
space and the vi-related modules seem to be in Vi::.  I'm not sure
what the received wisdom is for the right way to do this would be,
but the option based on precedents could only be Wily::.
But 'Vi' and 'Emacs' are arguable more a Way of Life than a mere editor
-- also they are so widely known by many people (especially those with a
Unix background) that there isn't much chance of confusion or ambiguity
with their names.
Plus I can see that there's more of a chance for multiple Emacs and Vi 
related modules than Wily-related ones.

That possibly doesn't apply to 'Wily'.  Or, more to the point, it 
certainly doesn't apply to every possible application that anybody could 
ever want to create a Perl interface to.
Agreed.
There are some 'Excel'-related modules in the Spreadsheet:: namespace.
I think creating an Editor:: namespace for 'Wily' would be reasonable.
I'd rather see TextEdit:: or TextEditor:: than the somewhat ambiguous 
Editor::, but I'd be happy to see a new name space for these sorts of 
things.

--
/chris

Re: module name for Wily (a text editor) interface client?

[Sam Holden]

Christopher Hicks writes:
On Mon, 2 Aug 2004, Smylers wrote:
 Christopher Hicks writes:
 I would think the existing examples might provide some light on this
 but the modules to interface to emacs seem to be in their own Emacs::
 space and the vi-related modules seem to be in Vi::.  I'm not sure
 what the received wisdom is for the right way to do this would be,
 but the option based on precedents could only be Wily::.

 But 'Vi' and 'Emacs' are arguable more a Way of Life than a mere editor
 -- also they are so widely known by many people (especially those with a
 Unix background) that there isn't much chance of confusion or ambiguity
 with their names.

Plus I can see that there's more of a chance for multiple Emacs and Vi 
related modules than Wily-related ones.

I would argue that Wily is just as much a way of life as Emacs and Vi. 
However, it certainly isn't anywhere near as popular - chances are
you've never heard of it... It doesn't warrant a toplevel namespace
all to itself - though of course my current code uses one :)

There are two Wily modules in existance at the moment (that I know of),
but they do the same thing - one uses XS to link with the wily libs,
whereas mine uses pack/unpack to decode the messages itself. But yes,
there's much less scope for multiple modules (due to the fact that the
intersection of wily users and perl programmers is small...)

 That possibly doesn't apply to 'Wily'.  Or, more to the point, it 
 certainly doesn't apply to every possible application that anybody could 
 ever want to create a Perl interface to.

Agreed.

 There are some 'Excel'-related modules in the Spreadsheet:: namespace.
 I think creating an Editor:: namespace for 'Wily' would be reasonable.

I'd rather see TextEdit:: or TextEditor:: than the somewhat ambiguous 
Editor::, but I'd be happy to see a new name space for these sorts of 
things.

I'm happy both of those. Is there a preference for 8 or less
character names due to some old file system restrictions? If not
then TextEditor:: seems better than TextEdit:: or Editor::.

-- 
Sam

Re: module name for Wily (a text editor) interface client?

[Randy W. Sims]

Sam Holden wrote:
I asked this in comp.lang.perl.modules and was pointed here, so
here I am.
Firstly, wily[1] is a (mostly) workalike of Acme[2] an editor
under plan9.
Wily provides only basic functionality with a very different but very
small interface (with lots of mousing, meaning many people will *hate*
it). It doesn't for example have a means of doing search-and-replace
(though everyone who uses wily will have an external program that adds
that to it in some way).
It does however, allow external programs to interface to it (and
possibly add some of the missing functionality). The module I've written
implements that interface and allows perl to communicate with wily.
Basically it allows a perl script to interact with wily the way
LISP code might interact with emacs (I think anyway, not being an
emacs user).
I can't work out a namespace for the module on CPAN. In fact I can't
even work out a category (Commercial Software Interfaces is close, but
wily isn't commercial...)
Namespace wise, Text::Wily was suggested on comp.lang.perl.modules, but
the module itself has almost nothing to do with text - it interfaces to
a text editor which I think is a very different thing.
Acme::Wily is another option, but that's subverting the meaning of the
Acme namespace and putting it somewhere that makes it harder to find.
I'd suggest something like: App::API::Wily
Randy.

Re: Design philosophy (was Re: Module name: WWW-ISBNReference)

[_brian_d_foy]

In article [EMAIL PROTECTED], Robert Rothenberg
[EMAIL PROTECTED] wrote:

 On 7/25/2004 2:26 AM brian d foy wrote:

  On Sun, 25 Jul 2004, Robert Rothenberg wrote:

  I don't think it's appropriate to merge with Business::ISBN, which 
  just deals with ISBN data.  The isbnsearch system is a distributed, 
  open-source isbn-lookup system for bibliographic data.

  Business::ISBN does much more than that.  Why not put all the ISBN stuff 
  in one place?

 Looking at the docs and source forge page, Business::ISBN seems to just deal 
 with ISBN information. Have I missed something?

 One of my pet-peeves with many CPAN modules is that they try to be everything 
 for everybody, which means they make it harder for developers to customize to 
 their needs. 

it's not the ease of developers that concern me.  the truly popular
modules have been the ones that pull things together for the users,
like DBI and LWP.

-- 
brian d foy, [EMAIL PROTECTED]

Re: Module name: WWW-ISBNReference

[brian d foy]

On Sun, 25 Jul 2004, Robert Rothenberg wrote:
I don't think it's appropriate to merge with Business::ISBN, which just deals 
with ISBN data.  The isbnsearch system is a distributed, open-source 
isbn-lookup system for bibliographic data.
Business::ISBN does much more than that.  Why not put all the ISBN stuff 
in one place?

--
brian d foy [EMAIL PROTECTED]

Re: Module name: WWW-ISBNReference

[Robert Rothenberg]

I am working on a module that can query isbnreference.org for information 
about a particular book.
have you thought about working with Ed Summers to put that into
Business::ISBN ?
I have joined the isbnsearch-devel list that maintains the software for 
isbnreference and have brought up the idea on that list.

I don't think it's appropriate to merge with Business::ISBN, which just deals 
with ISBN data.  The isbnsearch system is a distributed, open-source 
isbn-lookup system for bibliographic data.

It accomplishes the same thing as Net::Amazon only using public domain data.

Design philosophy (was Re: Module name: WWW-ISBNReference)

[Robert Rothenberg]

Looking at the docs and source forge page, Business::ISBN seems to just deal 
with ISBN information. Have I missed something?

Which I think is fine: I rather like the philosophy that a tool should do just 
one thing (or maybe a few closely-related things) really well.  It's just a 
matter of plugging in the tools one needs.

I'd not be happy if I wanted to use Business::ISBN with Net::Amazon or one of 
the WWW::Scraper::ISBN modules or something else, but had extra stuff related 
to ISBNSearch (using LWP, and maybe Net::Z3950) and MARC format processing and 
a lot of bibliographic information that has nothing to do with ISBNs, except 
that it's a key to search for this information.

One of my pet-peeves with many CPAN modules is that they try to be everything 
for everybody, which means they make it harder for developers to customize to 
their needs.  So they write yet another module to do X


On 7/25/2004 2:26 AM brian d foy wrote:
On Sun, 25 Jul 2004, Robert Rothenberg wrote:
I don't think it's appropriate to merge with Business::ISBN, which 
just deals with ISBN data.  The isbnsearch system is a distributed, 
open-source isbn-lookup system for bibliographic data.
 
Business::ISBN does much more than that.  Why not put all the ISBN stuff 
in one place?

Re: Module name: WWW-ISBNReference

[Jim Cromie]

Robert Rothenberg wrote:
I am working on a module that can query isbnreference.org for 
information about a particular book.

isbnreference.org is an open-source ISBN lookup service.
As far as I know, there is no Perl module which uses 
isbnreference.org, although there are modules to support the Library 
of Congress Net::Z3950 protocol that isbnreference.org uses.


IIRC  WebService::* emerged by consensus as the new and improved TLN for 
this kind of thing.

Dave Rolsky is the 1st, with WebService::StreetMapLink

Re: Module name: WWW-ISBNReference

[A. Pagaltzis]

* Jim Cromie [EMAIL PROTECTED] [2004-07-24 15:31]:
 Dave Rolsky is the 1st, with WebService::StreetMapLink

Uh, hardly. I get 13 hits for distributions with webservice on
search.cpan.org at the time of this writing, and all but two or
three are older than ::StreetMapLink.

Regards,
-- 
Aristotle
If you can't laugh at yourself, you don't take life seriously enough.

Re: Module name: WWW-ISBNReference

[_brian_d_foy]

In article [EMAIL PROTECTED], Robert Rothenberg
[EMAIL PROTECTED] wrote:

 I am working on a module that can query isbnreference.org for information 
 about a particular book.

have you thought about working with Ed Summers to put that into
Business::ISBN ?

-- 
brian d foy, [EMAIL PROTECTED]

Re: Module name? CPAN::Distribution::Depends

[James Keenan]

On July 15, 2004 9:52:30 PM EDT, Robert Rothenberg wrote:
 I am working on a module that when given a CPAN distribution, it will 
determine what modules that distribution depends on by scanning the 
META.yml file or if that one is not present, the Makefile.PL file.

 Is that a good name for it?

 It differs from existing modules in that it merely parses the 
Makefile.PL file rather than try to compile or run it and look for what 
modules it requests. For most modules on CPAN, it is quite adequate.


Rob:
I took a look thru the TL CPAN::* and Module* namespaces yesterday and, 
contrary to my first impression, came to the conclusion that your 
module does indeed do something that other modules don't, mainly 
because it is more narrowly focused and modest.  So I think it will be 
a useful addition to CPAN.

I think you are correct in not wanting to create a TL Distribution:** 
namespace.  However, I tend to agree with other posters that the best 
place for this will be under the Module::* namespace, not the CPAN::* 
namespace.

My reasoning:  (1) As comdog said, if this can apply to _any other_ 
form of distribution besides CPAN (and I suspect it can, or should), 
then it should not go in the CPAN namespace; and (2) the other modules 
that do things like yours are in the Module** namespace, so someone 
searching through that space will be able to make quick comparisons 
between your module and say, Module::Install, and determine which is 
better for his/her needs.

Jim Keenan

Re: Module name? CPAN::Distribution::Depends

[Randy W. Sims]

Robert Rothenberg wrote:
I am working on a module that when given a CPAN distribution, it will 
determine what modules that distribution depends on by scanning the 
META.yml file or if that one is not present, the Makefile.PL file.
A while back I started on a module to read, write,  validate the 
META.yml file according to the spec. I'm not sure if it's usefull or 
relevant, but it can be found at 
http://www.thepierianspring.org/CPAN-Metadata-0.00_02.tar.gz.

I haven't really looked in detail, but I do know that there are a lot of 
modules that do this using various approaches. Are you sure you have 
looked at them all and that none are similar enough to use or extend 
instead of creating another module? Like I said, I haven't really 
investigated myself, so I'm just asking.

Is that a good name for it?
I think some of the modules that perform this task are in the Module::* 
namespace. That's shorter and seems more appropriate.

Randy.
It differs from existing modules in that it merely parses the 
Makefile.PL file rather than try to compile or run it and look for what 
modules it requests. For most modules on CPAN, it is quite adequate.

(The parsing module is actually Module::MakefilePL::Parse--which is 
already on CPAN, although that may not be the best name...)

The purpose of this is for a larger project that checks testing results 
from CPAN Testers for a module and specific platforms.  The lack of test 
results for some platforms is sometimes because needed modules do not 
work on specific platforms.  This information would be useful to module 
authors.

Thanks,
Rob

Re: Module name? CPAN::Distribution::Depends

[_brian_d_foy]

In article [EMAIL PROTECTED], Robert Rothenberg
[EMAIL PROTECTED] wrote:

 I am working on a module that when given a CPAN distribution, it will 
 determine what modules that distribution depends on by scanning the META.yml 
 file or if that one is not present, the Makefile.PL file.

This should be able to do the same thing for non-CPAN distributions
too, and maybe even distributions that aren't modules. :)

-- 
brian d foy, [EMAIL PROTECTED]

Re: Module name? CPAN::Distribution::Depends

[Robert Rothenberg]

On 7/16/2004 5:04 AM Randy W. Sims wrote:
I haven't really looked in detail, but I do know that there are a lot of 
modules that do this using various approaches. Are you sure you have 
looked at them all and that none are similar enough to use or extend 
instead of creating another module? 
I'm pretty sure I have looked at all the modules, and tried most of them (some 
do not work on Windows).  Again, they use a different technique

I think some of the modules that perform this task are in the Module::* 
namespace. That's shorter and seems more appropriate.
Maybe Module::ParseDeps (since there is already a Module::ScanDeps).
Module::* still seems like a misnomer, since really what I'm working on are 
distributions, but there is no Dist::, Distro:: or Distribution:: namespace 
and I'm not about to create it.

Rob