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

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.

RFC: Arduino::Pseudo

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.

removal request - Sys::UniqueID

Contacting Tassilo von Parseval about adopting Inline::Lua

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

--

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

Staring at XSLT code for one minute has a 67% chance of making one permanently
blind.

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

RFC: Name for new modules (RandomJungle::)

New DMTF module set with proposed top-level namespace

Changing module name

I am thinking about changing Plack::Middleware::Auth::Form to
WebPrototypes::LoginForm - the idea is to provide more such 'widgets'
(there are already two published:
http://search.cpan.org/search?query=webprototypes&mode=all - still
experimental) with the same basic approach for  reusabillity of web
elements.

Is there a common procedure for such a migration?

--

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

The Marpa namespace

[ This post, from the marpa parser Google group
(https://groups.google.com/forum/?hl=en&fromgroups#!forum/marpa-parser) largely repeats what
I believe to have been the result of a previous discussion in this group.  I send it now because I know of
several Marpa-based modules being created, suspect there are others, so that I think it may be timely.  Thanks.]

The standard and traditional practice is, where a module or set of modules is associated with a top-level
namespace, to reserve that namespace for modules controlled by a single team.  The example cited most
often is Moose, which top-level namespace is reserved for modules controlled by the Moose Team.  Moose
modules not under the control of the Moose Team often go into the MooseX namespace, which is reserved for
that purpose.

I feel that I need to follow this practice for Marpa.  Modules going into the Marpa top-level namespace
should only be those completely controlled by the Marpa Team.  Among the places where other Marpa-related
modules can go is into a top-level MarpaX namespace.

I don't know the full history of the traditional practice, but there are at least two reasons why it is
necessary in the Marpa case.  The first is namespace management.  The Marpa Team, to avoid collisions, and
for its own expansion needs, requires a namespace that it controls fully.  A second reason is least
surprise when it comes to responsibility for the modules and issues with them.  A user will have a
reasonable expectation that, if there is an issue with a Marpa::X::Y::Z module, the Marpa Team are the
people to go to about it.

Under traditional practice, the Marpa Team is also entitled to control all namespaces with Marpa as a
component, for example, Acme::Marpa::Widget.  The Marpa Team will NOT exercise this traditional right. 
The Marpa Team feels that control of the top-level Marpa namespace is sufficient.  The usual PAUSE and CPAN
processes for granting namespaces, of course, still apply, and there may be cases where the Marpa Team
wants input into those processes.

In the above, I refer to the "Marpa Team".  At the moment, this is simply me.  Other projects of the size and
complexity of Marpa are managed by multi-person teams, and I hope that will become the case with Marpa.

Thanks, jeffrey kegler

Proposal for building module info

metacpan logo contest voting?

Re: Hello PAUSE