Re: Namespace advice for Git-related package
On 10/27/2016 11:25 AM, Smylers wrote: James E Keenan writes: Alternatively, Devel::Git::MultiBisect would indicate that this is a tool for Perl development use. And that's what I ultimately went with! This is indeed a developer's tool. http://search.cpan.org/dist/Devel-Git-MultiBisect-0.01/ Thank you very much. Jim Keenan
Re: Namespace advice for Git-related package
James E Keenan writes: > I am in the process of developing a CPAN library which I am > considering calling Git-Multisect-Perl. ... > > 'Multisect::' is chosen to contrast with 'bisect'. That hadn't occurred to me. I read it as a contraction of ‘multiple sections’ or similar. > When we speak of bisection in the context of, say, Perl 5 core > development and use of Porting/bisect.pl, we're usually looking for a > single answer to a question, e.g., at which specific commit did this > test file start to experience failures. Recently, however, we have a > case where a file failed in different ways over many months. That's > the actual use case which led me to develop this library. However, ‘bisect’ is a well known word for this activity. Sometimes with naming things it's clearer to be familiar-but-approximate rather than accurate-but-obscure. Once the name has got somebody's attention, the docs can explain nuances. I think Git::MultiBisect or Git::Bisect::Multiple get the idea across more obviously. > The '::Perl' in the namespace is intended to say, "This is a way to > apply the concept of multisection to typical needs in Perl development Unfortunately I don't think it does that. A suffix of ::Perl usually indicates that it's implemented in Perl — either because there's also an ::XS variant, or it's a port of a library that originated in Java or some other language. I'm not sure there is anything which indicates ‘typical for Perl development’. I'd omit that aspect from the name. > we don't want to foreclose the possibility of future libraries which > use git to perform multisection in other problem spaces." Let any hypothetical future rival Git-multi-bisect distribution — and there may not be one — come up with an adjective that distinguishes itself from yours. Alternatively, Devel::Git::MultiBisect would indicate that this is a tool for Perl development use. Good luck! Smylers -- http://twitter.com/Smylers2
book namespace advice
I'm writing a free perl book in Chinese http://github.com/fayland/chinese-perl-book/tree/master and I'm wondering if it's OK to upload it to CPAN since it's popular and easy to share with others. if it's OK, which namespace is suit for the book? Book::? Acme::Book::? or POD::Book::? Thanks. -- Fayland Lam // http://www.fayland.org/ Foorum based on Catalyst // http://www.foorumbbs.com/
Re: book namespace advice
Hi!
Here are my thoughts about the matter.
On Thursday 06 August 2009 10:16:24 Fayland Lam wrote:
I'm writing a free perl book in Chinese
http://github.com/fayland/chinese-perl-book/tree/master
Well, first of all - thanks for your effort. We could always use more online
books about Perl. Just a note - Catalyst.pod reads:
{{{
=head1 COPYRIGHT LICENSE
This program is free software; you can redistribute it and/or modify it
under the same terms as Perl itself.
}}}
Are you sure you want to use these licensing terms?
See:
* http://perlbuzz.com/2009/07/help-end-licensing-under-same-terms-as-perl-
itself.html
(Short URL: http://xrl.us/be8pep )
I should also note that for a book with code samples, then a permissive open-
source license such as http://en.wikipedia.org/wiki/MIT_License or
http://en.wikipedia.org/wiki/ISC_license (or maybe even dual licensed with
http://wiki.creativecommons.org/CC0_FAQ ) would be more suitable, because one
can expect people to copy-and-paste code into their programs.
and I'm wondering if it's OK to upload it to CPAN since it's popular and
easy to share with others.
I saw some texts on CPAN:
* http://search.cpan.org/dist/Object-PerlDesignPatterns/
* http://search.cpan.org/dist/Catalyst-Manual/
* http://search.cpan.org/dist/Religion-Islam-Quran/
If you have many L links to modules, etc. then putting it there may be a
good idea. How big do you expect the book to get?
You may also opt to host it on http://perl-begin.org/ or wherever. Contact me
if you're interested.
if it's OK, which namespace is suit for the book? Book::? Acme::Book::?
or POD::Book::?
Acme::Book is not suitable because this is not a joke module. POD::Book may
imply that it has something to do with POD processing, which it doesn't as it
is only written in POD. Maybe Book:: or Perl::Book.
Regards,
Shlomi Fish
--
-
Shlomi Fish http://www.shlomifish.org/
Parody on The Fountainhead - http://xrl.us/bjria
God gave us two eyes and ten fingers so we will type five times as much as we
read.
Re: book namespace advice
Shlomi Fish wrote:
Hi!
Here are my thoughts about the matter.
On Thursday 06 August 2009 10:16:24 Fayland Lam wrote:
I'm writing a free perl book in Chinese
http://github.com/fayland/chinese-perl-book/tree/master
Well, first of all - thanks for your effort. We could always use more online
books about Perl. Just a note - Catalyst.pod reads:
{{{
=head1 COPYRIGHT LICENSE
This program is free software; you can redistribute it and/or modify it
under the same terms as Perl itself.
}}}
Are you sure you want to use these licensing terms?
See:
* http://perlbuzz.com/2009/07/help-end-licensing-under-same-terms-as-perl-
itself.html
(Short URL: http://xrl.us/be8pep )
I should also note that for a book with code samples, then a permissive open-
source license such as http://en.wikipedia.org/wiki/MIT_License or
http://en.wikipedia.org/wiki/ISC_license (or maybe even dual licensed with
http://wiki.creativecommons.org/CC0_FAQ ) would be more suitable, because one
can expect people to copy-and-paste code into their programs.
well, I really don't have much idea on the license. maybe I'll just pick
MIT since you mentioned it. :)
and I'm wondering if it's OK to upload it to CPAN since it's popular and
easy to share with others.
I saw some texts on CPAN:
* http://search.cpan.org/dist/Object-PerlDesignPatterns/
* http://search.cpan.org/dist/Catalyst-Manual/
* http://search.cpan.org/dist/Religion-Islam-Quran/
If you have many L links to modules, etc. then putting it there may be a
good idea. How big do you expect the book to get?
I'm not sure, depends on my energy and the feedback of the book. :)
You may also opt to host it on http://perl-begin.org/ or wherever. Contact me
if you're interested.
Thanks for that. but it's not finished yet and I would change it
frequently, so not now. :)
if it's OK, which namespace is suit for the book? Book::? Acme::Book::?
or POD::Book::?
Acme::Book is not suitable because this is not a joke module. POD::Book may
imply that it has something to do with POD processing, which it doesn't as it
is only written in POD. Maybe Book:: or Perl::Book.
OK, then I'll name it as Book::Chinese (maybe
Book::Chinese::MasterPerlToday or something else) if nobody is against it.
Thanks for your reply again.
Regards,
Shlomi Fish
--
Fayland Lam // http://www.fayland.org/
Foorum based on Catalyst // http://www.foorumbbs.com/
Speaking of namespace advice...
I've got a module that... well, the idea is that it's the
Module::CoreList for Strawberry.
What should I call it? Module::List::Strawberry and
Strawberry::ModuleList both come to mind.
Here's the hashes so far:
%release = (
'5.008009002' = {
'C:' = {
'uname' = 'Win32 strawberryperl 5.8.9.2 #1 Wed Jul 29 18:54:19
2009 i386',
'reldate' = 'Wed Jul 29 18:54:19 2009',
'version' = '5.8.9.2',
},
...
%version = (
'5.008009002' = {
'AnyDBM_File' = '1.00',
'App::Prove'= '3.17',
'App::Prove::State' = '3.17',
'App::Prove::State::Result'= '3.17',
'App::Prove::State::Result::Test'= '3.17',
'Archive::Tar' = '1.52',
'Archive::Tar::Constant'= '0.02',
'Archive::Tar::File'= '0.02',
'Archive::Zip' = '1.30',
...
--Curtis
--
Curtis Jewell
swords...@csjewell.fastmail.us
%DCL-E-MEM-BAD, bad memory
-VMS-F-PDGERS, pudding between the ears
[I use PC-Alpine, which deliberately does not display colors and pictures in
HTML mail]
Re: Speaking of namespace advice...
Curtis Jewell wrote: I've got a module that... well, the idea is that it's the Module::CoreList for Strawberry. What should I call it? Module::List::Strawberry and Strawberry::ModuleList both come to mind. what's wrong with just Module::CoreList::Strawberry? cheers, Aldo
Re: Speaking of namespace advice...
Curtis Jewell wrote in perl.module-authors : I've got a module that... well, the idea is that it's the Module::CoreList for Strawberry. What should I call it? Module::List::Strawberry and Strawberry::ModuleList both come to mind. Module::CoreList::Strawberry ? Here's the hashes so far: By the way, did you notice that perl comes with a script that helps generating the Module::CoreList data ? http://perl5.git.perl.org/perl.git/blob_plain/HEAD:/Porting/corelist.pl It can be helpful, I suppose. -- Is it any wonder the world's gone insane, with information come to be the only real medium of exchange ? -- Thomas Pynchon, Gravity's Rainbow
Re: Speaking of namespace advice...
On Thu, 06 Aug 2009 10:51 +, Rafael Garcia-Suarez rgarciasua...@gmail.com wrote: Curtis Jewell wrote in perl.module-authors : I've got a module that... well, the idea is that it's the Module::CoreList for Strawberry. What should I call it? Module::List::Strawberry and Strawberry::ModuleList both come to mind. Module::CoreList::Strawberry ? Since you're the third person that's said that, I think that's what I'll go with. Here's the hashes so far: By the way, did you notice that perl comes with a script that helps generating the Module::CoreList data ? http://perl5.git.perl.org/perl.git/blob_plain/HEAD:/Porting/corelist.pl It can be helpful, I suppose. Yes, I did. I altered it to do the collection. Would have taken lots of hours otherwise. :) Don't have the updated script as complete as I'd like, but it did the trick. --Curtis -- Curtis Jewell swords...@csjewell.fastmail.us %DCL-E-MEM-BAD, bad memory -VMS-F-PDGERS, pudding between the ears [I use PC-Alpine, which deliberately does not display colors and pictures in HTML mail]
Re: Namespace Advice
Hello Chris, Chris Dolan wrote: On Apr 6, 2005, at 11:06 AM, Reinhard Pagitsch wrote: I would suggest now to name the module Win32::Storage::ReadSummaryInfo. I like this better than before, but why not Win32::Document::SummaryInfo? Because not only MS documents can be read? There is also the possibility to read the summary informations from text and and other files, if there is a summary information available. Reinhard
Re: Namespace Advice
Hello Chris, Chris Dolan wrote: On Apr 7, 2005, at 8:28 AM, Reinhard Pagitsch wrote: Hello Chris, Chris Dolan wrote: On Apr 6, 2005, at 11:06 AM, Reinhard Pagitsch wrote: I would suggest now to name the module Win32::Storage::ReadSummaryInfo. I like this better than before, but why not Win32::Document::SummaryInfo? Because not only MS documents can be read? There is also the possibility to read the summary informations from text and and other files, if there is a summary information available. Reinhard Hmm, I think it must be my Mac experience showing through. I'll defer in this case, but permit me to further detail my thoughts anyway... When I think Document I mentally include any non-active file, including MS Office files, text files, PDF files, etc. but excluding executables. To me Win32::Storage and Win32::File suggest the manifestation of the file in the filesystem, not the the contents of that file. The summary information of a Win32 (NT/2000/XP/2003) are not part of the content of the file. MS tells about Structured Storage it the following: [quotation] Structured Storage provides file and data persistence in COM by treating a single file as a structured collection of objects known as storages and streams. The purpose of Structured Storage is to reduce the performance penalties and overhead associated with storing separate objects in a single file. Structured Storage provides a solution by defining how to treat a single file entity as a structured collection of two types of objectsstorages and streamsthrough a standard implementation called Compound Files. This lets the user interact with and manage a compound file as if it were a single file rather than a nested hierarchy of separate objects. And also: Traditional file systems face challenges when they try to store efficiently multiple kinds of objects in one document. COM provides a solution: a file system within a file. COM structured storage defines how to treat a single file entity as a structured collection of two types of objects storages and streams that act like directories and files. This scheme is called /structured storage/. The purpose of structured storage is to reduce the performance penalties and overhead associated with storing separate objects in a flat file. [end quotation] So these informations can be stored for any file, including executables and dll's, as I understand this, or I am wrong? Ok, in these two explanations they only speak about compund files, but as I know you can also use it for executables and dll's. Reinhard
Re: Namespace Advice
On Apr 6, 2005, at 11:06 AM, Reinhard Pagitsch wrote: I would suggest now to name the module Win32::Storage::ReadSummaryInfo. I like this better than before, but why not Win32::Document::SummaryInfo? Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) PGP.sig Description: This is a digitally signed message part
Re: Namespace Advice
On Apr 7, 2005, at 8:28 AM, Reinhard Pagitsch wrote: Hello Chris, Chris Dolan wrote: On Apr 6, 2005, at 11:06 AM, Reinhard Pagitsch wrote: I would suggest now to name the module Win32::Storage::ReadSummaryInfo. I like this better than before, but why not Win32::Document::SummaryInfo? Because not only MS documents can be read? There is also the possibility to read the summary informations from text and and other files, if there is a summary information available. Reinhard Hmm, I think it must be my Mac experience showing through. I'll defer in this case, but permit me to further detail my thoughts anyway... When I think Document I mentally include any non-active file, including MS Office files, text files, PDF files, etc. but excluding executables. To me Win32::Storage and Win32::File suggest the manifestation of the file in the filesystem, not the the contents of that file. But perhaps my vocabulary of simply off base. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) PGP.sig Description: This is a digitally signed message part
Re: Namespace Advice
Hello Chris, Chris Dolan wrote: On Apr 5, 2005, at 2:44 AM, Reinhard Pagitsch wrote: Win32::File::Prop - Perl extension read property informations from MS compound files and normal files, if the properties are set. Question: Is this really Win32 specific? Are you using Windows-only functionality, or would this module work fine on non-Windows computers (like the Excel and OLE modules do)? Yes the module is really Win32 specific because it uses the functions for the Structured Storage, and I do not belive these functions are available on Linux/Unix systems or cygwin. As I made tests also with OpenOffice documents and saw that there the informations stored in a different way so I have to check the OOo SDK to get the informations I need. I think Document may be better than File in this case. My first impression was that Win32::File::Prop is would interact with Windows filesystem properties, like permissions, hidden flags, ownership, etc. Or maybe Win32::Storage::PropertySet? Reinhard Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Namespace Advice
Le mercredi 06 avril 2005 à 12:11, Smylers écrivait: Reinhard Pagitsch writes: Chris Dolan wrote: I think Document may be better than File in this case. My first impression was that Win32::File::Prop is would interact with Windows filesystem properties, like permissions, hidden flags, ownership, etc. Or maybe Win32::Storage::PropertySet? I would expect something with storage in its name to be quite low-level; it wouldn't occur to me that it would deal with document-specific properties. Also PropertySet makes it sounds that it _sets_ properties, whereas you said your module reads them. It all depends if you hear set as a noun or as a verb, doesn't it? -- Philippe BooK Bruhat The shortest distance between two points is not always the safest. (Moral from Groo The Wanderer #69 (Epic))
Re: Namespace Advice
Philippe 'BooK' Bruhat writes: Le mercredi 06 avril 2005 à 12:11, Smylers écrivait: Also PropertySet makes it sounds that it _sets_ properties, whereas you said your module reads them. It all depends if you hear set as a noun or as a verb, doesn't it? Yes, but it's quite common for modules to be Noun::Verb, such as Email::Send for instance. My point was that it's ambiguous, and therefore less preferable than a similar name that couldn't cause such confusion. Smylers
Re: Namespace Advice
Hello Smylers, Smylers wrote: Reinhard Pagitsch writes: Chris Dolan wrote: I think Document may be better than File in this case. My first impression was that Win32::File::Prop is would interact with Windows filesystem properties, like permissions, hidden flags, ownership, etc. Or maybe Win32::Storage::PropertySet? I would expect something with storage in its name to be quite low-level; it wouldn't occur to me that it would deal with document-specific properties. The module gets the informations which would be displayed in the Summary information dialog if you right click on a MS document (Word, Excel, ...) chooseing Properties in the popup menu. But it can also read none MS documents like text files, if there are extra informations stored. (I just tested it with MS documents and normal text files.) Also PropertySet makes it sounds that it _sets_ properties, whereas you said your module reads them. Hmm, you shall read it as a Set of Properties not setting properties. I would suggest now to name the module Win32::Storage::ReadSummaryInfo. Reinhard Smylers
Namespace Advice
Hello, I finished my module Win32::File::Prop Here is an extract from the POD: Win32::File::Prop - Perl extension read property informations from MS compound files and normal files, if the properties are set. TODO: Adding support for OpenOffice and StarOffice documents. I thought I can name it Win32::File::Prop or would it better to name it Win32::File::PropertySet? Your thoughts are appreciated. Thank you, Reinhard
Re: Namespace Advice
On Apr 5, 2005, at 2:44 AM, Reinhard Pagitsch wrote: Win32::File::Prop - Perl extension read property informations from MS compound files and normal files, if the properties are set. Question: Is this really Win32 specific? Are you using Windows-only functionality, or would this module work fine on non-Windows computers (like the Excel and OLE modules do)? I think Document may be better than File in this case. My first impression was that Win32::File::Prop is would interact with Windows filesystem properties, like permissions, hidden flags, ownership, etc. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) PGP.sig Description: This is a digitally signed message part
Seeking Namespace Advice (MVS OS/390 Mainframe Util.)
I'm just about to finish up a module that someone might find useful. It emulates two utilities found on IBM Mainframes, IEBUPDTE and IEBPTPCH. For a general discussion, lets just say that these two utilities are similar to tar/untar. I wrote them so that I can bundle local files to upload, and so that I can un-bundle files downloaded from the mainframe. If I were to start fresh, I'd like OS390::IEBUtils. A bit of history: IBM's OS has gone through many names, the three most recent are 'MVS', 'OS/390', and 'z/OS', so it's a little tricky using the OS name as an identifier. The two most closely related existing modules are MVS::VBFile and Convert::OS390. What's a little bit unusual is that this code would only be of interest to a mainframer, but it's designed to run on a PC. Your thoughts are appreciated. I've got a good bit of work in the modules, and don't want to gum up the works with an ineffective or misleading name. -- Paul Boin http://www.intertechconsulting.net (717) 382-9711
Re: Seeking Namespace Advice (MVS OS/390 Mainframe Util.)
On Thu, Mar 24, 2005 at 04:52:51PM -0500, Paul Boin wrote: I'm just about to finish up a module that someone might find useful. It emulates two utilities found on IBM Mainframes, IEBUPDTE and IEBPTPCH. For a general discussion, lets just say that these two utilities are similar to tar/untar. I wrote them so that I can bundle local files to upload, and so that I can un-bundle files downloaded from the mainframe. If I were to start fresh, I'd like OS390::IEBUtils. A bit of history: IBM's OS has gone through many names, the three most recent are 'MVS', 'OS/390', and 'z/OS', so it's a little tricky using the OS name as an identifier. The two most closely related existing modules are MVS::VBFile and Convert::OS390. What's a little bit unusual is that this code would only be of interest to a mainframer, but it's designed to run on a PC. Your thoughts are appreciated. I've got a good bit of work in the modules, and don't want to gum up the works with an ineffective or misleading name. If the utilities are archivers, would it work to put them in the Archive:: top level namespace, alongside Archive::Tar and Archive::Zip ? Nicholas Clark
