gmane.comp.lang.perl.modules.authors

Re: Idea for a module: Test::Prereq::MiniCPAN

Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 — 2012-05-21T15:52:46

Similar to Dist::Zilla::Plugin::CheckPrereqsIndexed, therefore I suggest
Test::Prereq::Indexed.

Idea for a module: Test::Prereq::MiniCPAN

Robert Rothenberg — 2012-05-18T14:41:49

This module would be based on Test::Prereq, but instead of looking in a
Makefile.PL, it would look in a Mini-CPAN (based on the CPAN, CPANPLUS
configuration) and see if the module was specified in the 02packages list.

Re: RFC: Arduino::Pseudo

Aldo Calpini — 2012-05-04T15:00:16

there's no such thing as an Emulation namespace currently :-)

furthermore, I'm afraid people will incorrectly think the module 
emulates the actual Arduino hardware (eg. the ATMega chip), like for 
example those more "serious" programs:

http://emulare.sourceforge.net/
http://www.virtualbreadboard.net/

I believe the accent here should be on *Pseudo*. I would personally 
avoid mentioning emulation.

cheers,
Aldo

Re: RFC: Arduino::Pseudo

Shlomi Fish — 2012-05-04T14:10:48

Hi Aldo,

On Fri, 04 May 2012 15:28:39 +0200
Aldo Calpini <dada< at >perl.it> wrote:


I think it is worth a CPAN upload. I'm not toying with the Arduino myself, but
other people may find it useful.


Shouldn't it be under an Emulation namespace? ("Emu::" etc.) Or have I
misunderstood the purpose of this module? 

Regards,

Shlomi Fish

RFC: Arduino::Pseudo

Aldo Calpini — 2012-05-04T13:28:39

hello CPAN fellows,

I'm toying with Arduino lately, and I wrote myself a sort of Arduino 
pseudocode simulator. in Perl :-)

basically, it's just a Wx::App which tries to mimic the working of an 
Arduino, with visible widgets for physical components like pushbuttons, 
leds and potentiometers.

it's still very rude and the GUI is not visually pleasant, but I found 
it moderately useful so far.

I have setup a quick page which shows some synopsis code and explains a 
little bit better what the module does:

http://dada.perl.it/Arduino-Pseudo/

the questions:

a) do you think it's worth a CPAN upload, or better keep it in the crazy 
ideas drawer? :-)

b) do you think the name Arduino::Pseudo fits?

I know there is the Device::Arduino namespace already, but since this 
has really nothing to do with the actual physical device, I don't think 
it should be in Device::.

on the other hand, it would be a new top-level namespace, which maybe 
someone won't like. I'm open to suggestions.

cheers,
Aldo

Re: removal request - Sys::UniqueID

Ryan Voots — 2012-05-03T14:28:10

This is the route that was taken with the old and broken Net::IRC module
I believe.

Re: removal request - Sys::UniqueID

Daniel Lukasiak — 2012-05-02T14:06:33

Thanks for the feedback, I'll follow this path.

Daniel

Re: removal request - Sys::UniqueID

Bill Ward — 2012-05-02T14:01:43


Taking it over only to deprecate it might be a solution.

Re: removal request - Sys::UniqueID

Daniel Lukasiak — 2012-05-02T13:25:51

I'd be more than happy to contribute but only if that would provide any 
value.
In this case I think there's more value in removing this broken module, 
there are much better alternatives.
I understand this is a problem with CPAN's nature, but there must be a 
line somewhere.

Re: RFC: a universal tidier

Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 — 2012-05-02T07:54:35

<https://pause.perl.org/pause/query?ACTION=pause_namingmodules#Avoid_the_too_general_nouns_like_Dev>

I suggest top-level `Code` instead, it is already in use:

    cpan[1]> d /[/]Code/
    Distribution    ALFIE/Code-Dumper-0.01.tar.gz
    Distribution    ANDREWF/CodeBase-0.86.tar.gz
    Distribution    CODECHILD/XML-Bare-0.07.tar.gz
    Distribution    CODECHILD/XML-Bare-SAX-Parser-0.01.tar.gz
    Distribution    CODEHELP/XML-QOFQSF-0.05.tar.gz
    Distribution    FDALY/Code-Perl-0.03.tar.gz
    Distribution    FRANCISCO/CodeManager-0.02.tar.gz
    Distribution    KITOMER/Code-Class-C-0.08.tar.gz
    Distribution    MITHALDU/Code-Statistics-1.112980.tar.gz
    Distribution    NAZRI/Code-Generator-Perl-0.03.tar.gz
    Distribution    SWALTERS/Code-Splice-0.01.tar.gz
    Distribution    SZABGAB/Code-Explain-0.02.tar.gz
    12 items found

Re: removal request - Sys::UniqueID

Todd Rinaldo — 2012-05-01T23:49:46

On May 1, 2012, at 1:09 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote:


You could take it over and fix it…

Re: removal request - Sys::UniqueID

Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 — 2012-05-01T18:09:25

You can write a review to let people know what's wrong with it and
about better alternatives. Ratings are prominently aggregated/linked to
on search.cpan.org and MetaCPAN.

<http://cpanratings.perl.org/rate/?distribution=Sys-UniqueID>

Re: RFC: a universal tidier

Jonathan Swartz — 2012-04-30T18:36:36

Yeah, Any::Tidy seemed to suggest to me "use the best of available tidiers".

I'm leaning now towards Devel::TidyAll, with tidyall being the name of the script.

On Apr 30, 2012, at 11:17 AM, David Nicol wrote:

Re: RFC: a universal tidier

David Nicol — 2012-04-30T18:17:20


I like the Any:: name space for things that offer single interfaces to
multiple back-ends. One could argue that Tidying really doesn't fit
there though. And that argument could be countered with hypothetical
examples involving large projects with different styles, enforced by
different tidying engines, for different parts of it, and the desire
for the scripts called at check-in time to run the correct tidying
engine by looking up per-file metadata.

RFC: a universal tidier

Jonathan Swartz — 2012-04-29T12:56:14

I'm thinking about a module/script to unify a bunch of code tidiers and validators in a single place. With a single command, e.g.

   % tidyall

you could apply the appropriate tidiers and validators to files in your project (e.g. your git directory hierarchy). It would tidy each file as needed and throw an error result if any of the validations failed. 

Features:
* Only tidy files that haven't changed since the last time (using File::Modified and a file cache)
* A single config file with options for all the tidiers and validators, as well as which files to apply them to
* Easy to add new validators/tidiers as plugins

This would be a command that the anal-retentive among us could run on our projects before each commit.

Tidiers and vaildators for Perl include Perl::Tidy, Pod::Tidy, and Perl::Critic. There are also various tidiers and validators for HTML, css and javascript out there.

Comments and suggestions for names welcome. Devel::MultiTidy?

Thanks
Jon

removal request - Sys::UniqueID

Daniel Lukasiak — 2012-04-24T17:05:23

Hi all,
while I was browsing CPAN I found Sys::UniqueID which I think should be 
removed from CPAN for several reasons:
1. It doesn't compile (hostip isn't exported by Sys::HostIP
2. It doesn't do what it says in the docs, even when I replaced hostip 
with ip it didn't work (returns empty string)
3. Author's email address is dead.||
4. No updates since 2000 (not a problem by itself, but see 1 and 2)

Given there's Data::UUID which is a better alternative (even to working 
Sys::UniqueID) I think it's reasonable to remove Sys::UniqueID from CPAN.

If removal isn't possible is there any other mechanism (forced 
depreciation?) that can be used?

Daniel

Re: Contacting Tassilo von Parseval about adopting Inline::Lua

Steffen Mueller — 2012-04-24T05:37:02

Hi all,

I found another email address of Tassilo's (see CC).

On 04/23/2012 11:11 AM, Shlomi Fish wrote:

Tassilo, would you mind if I transfer maintenance for Inline::Lua to Rob?

On a related note, it would be great if you could log in to PAUSE to 
update your contact info. If, on the other hand, you don't want people 
to contact you about such matters, then I'd be both sad and glad to 
accept a blanket permission to hand off your modules to new homes as 
users speak up and try to get in touch.

Man, it's been a long time since we've exchanged email. That must've 
been in the early 2000s via clpm?

Best regards,
Steffen
(for the PAUSE admins)

Contacting Tassilo von Parseval about adopting Inline::Lua

Shlomi Fish — 2012-04-23T09:11:39

Hi all,

Rob Hoelz has written this blogs.perl.org post about his willingness to
contribute to Inline::Lua by contacting the original author :

http://blogs.perl.org/users/hoelzro/2012/04/still-alive-inlinelua.html

Quoting from it:

[QUOTE] 

I was reading about the Inline module the other day, so naturally I looked to see if there was a binding for one of my other favorite languages, Lua. Sure enough, Inline::Lua exists; however, it has not seen a new release in nearly five years, and it doesn't even build on perls newer than 5.10. I like this idea enough that I'd like to put some time into it and cut a new release; however, I haven't been able to reach the author. So, in accordance with the guidelines I read in the CPAN FAQ, I'm making a post asking if the original author, Tassilo von Parseval, is still in the Perl community and interested in updating this module.

[/QUOTE]

There's also a useful comment by Joel Berger with some leads.

Regards,

Shlomi Fish

RFC: Name for new modules (RandomJungle::)

Robert Freimuth — 2012-04-15T02:27:33

<resending from a gmail account after failed attempts from a yahoo account
- apologies for duplicate postings if the first ones eventually come
through)

Hi,

I developed a series of modules that provide users with the ability to
post-process and manipulate the output of the Random Jungle program (
http://randomjungle.sourceforge.net/).  The proposed name of each module,
as well as a brief synopsis, is included below.  Please let me know if more
information is desired.

I would appreciate input on the selection of names.  At last check, there
was nothing on CPAN related to Random Jungle.

Thanks,
Bob

There are 7 modules in this distribution, 4 of which provide low-level
access to files and 3 of which are intended to be used by client programs.

Modules to access RJ data files:

RandomJungle::File::XML - Low level access to the data in the RandomJungle
XML output file

RandomJungle::File::RAW - Low level access to the data in the RandomJungle
RAW input file

RandomJungle::File::OOB - Low level access to the data in the RandomJungle
OOB output file

RandomJungle::File::DB - Low level access to the data in the RandomJungle
DB file (used to consolidate data from the XML, RAW, and OOB files and
provides query methods)

Modules to provide a user-centric interface to RJ data:

RandomJungle::Jungle - Consolidated interface for Random Jungle input and
output data (from the perspective of the entire jungle)

RandomJungle::Tree - A Random Jungle classification tree (trees make up the
jungle)

RandomJungle::Tree::Node - A simple representation of a node in a
RandomJungle::Tree

New DMTF module set with proposed top-level namespace

Stephen Hurd — 2012-04-10T18:45:27

I'm working on a set of modules which implement various DMTF standards.  Mostly they are alphabet soup, but my proposal for the module names is:

DMTF::CIM - Working with a DSP0004 CIM (Common Information Model) object model
DMTF::WSMan -The WS-Management protocol (DSP0226)
DMTF::CIM::MOF -MOF (Managed Object Format) parser (format defined in DSP0004)
DMTF::CIM::WSMan - Maps WSMan traffic to CIM data (DSP0227 and DSP0230)
DMTF::SMME -SM ME (DSP0215) UFiP expansion

Most of these modules are currently fairly light, but have room for growth and are interrelated and interdependent.  I initially considered a more abstract top-level namespace such as "Management" but that would make the association between the WSMan and CIM modules unobvious and already existing things such as SNMP:* and Net::SNMP are already in separate namespaces.  These module names are a bit of an alphabet soup, but most pass the "Google Test" and are obvious to people who would want to make use of the standards.

Future modules which are but a glint in my eye:
DMTF::ASF - Module for working with ASF (Alert Standard Format) traffic (DSP0114)
DMTF::ASF::RMCP -RMCP (Remote Management and Control Protocol) protocol (defined in DSP0114)
DMTF::ASF:: PET - PET (Platform Event Trap) protocol (per DSP0114, defined by Intel)
DMTF::CIMXML - The CIM-XML protocol (Defined in DSP0200)
DMTF::CIM::CIMXML - Maps CIM-XML traffic to CIM data (DSP0201)

The module naming doc makes it relatively clear that grabbing a top-level namespace without discussion is frowned upon, so I want to get this discussion rolling.

Stephen Hurd
Senior Staff Engineer - Software Development
Broadcom Corporation
949-926-8039
shurd< at >broadcom.com<mailto:shurd< at >broadcom.com>

Re: Changing module name

Bill Ward — 2012-04-09T16:47:59

I think the easiest solution is to create a new module with the new name,
and refactor the old one to use it... so Plack::Middleware::Auth::Form
would still exist as a consumer of the new module, and perhaps there are
some Plack-specific things that it might add to the inherited object,
especially if what you're creating is truly a webprototype, and the
existing module is truly middleware...

2012/4/9 Zbigniew Łukasiak <zzbbyy< at >gmail.com>