PrePAN

Sign in to PrePAN

PrePAN provides a place
to discuss your modules.

CLOSE

Requests for Reviews Feed

Test::Module::Runnable A runnable framework on Moose for running tests

A test framework based on Moose introspection to automagically call all methods matching a user-defined pattern. Supports per-test setup and tear-down routines and easy early BAIL_OUT using Test::More.

daybologic@github 1 comment

WWW::Europeana wrapper around the REST API of europeana.eu

This module is a wrapper around the REST API of Europeana (cf. ). At the moment only a basic search function is implemented.

Apart from general feedback, I am interested in ways how to mock the webservice, in order to write more meaningful tests.

Thanks in advance!

hatorikibble@github 2 comments

Games::Dice::Roll20 Simulate dice rolls with Roll20's syntax

Although there are already some dice roller on cpan, all i found only support a simple dice notation like 2d6+4. Games::Dice::Roll20 strives to support the full Roll20 dice specification under https://wiki.roll20.net/Dice_Reference. I would be very happy if someone could take a look before i release the distribution.

And i'm not sure about the name yet, should I really name it after a commercial webservice? And i wouldn't guarantee that i add my own extension to the spec in the future or change some behaviour. But all the good names seems to be taken: There are for example Games::Dice and Games::Dice::Advanced. I thought with Games::Dice::Complex but that seems rather bland and unhelpful.

Any ideas?

mdom@github 2 comments

SceneGraph A native Perl port of OpenSceneGraph 3.4 using OpenGL

I had hoped to provide a native Perl port of OpenSceneGraph 3.4 using the OpenGL module accompanied by GLUT.

I believe that, though there is a large code-base, this is a feasible venture as most of OpenSceneGraph 3.4 is an OO structure surrounding the base calls available in OpenGL.

I would use Moose for the OO structure.

I would use Imager as necessary for textures.

I would impliment as much of the OSG Core, osgUtil, osgViewer and osgDB as possible, though it would vary greatly from the C++ instance of OpenSceneGraph 3.4.

I have worked extensively with OpenSceneGraph in the past.

I have appreciated experience with OOP in Perl utilizing Moose.

I have reviewed the source and am estimating 4 - 5 fruitful sittings until several of the examples provided with the OpenSceneGraph 3.4 source are brought to the screen.

jmcveigh@github 2 comments

Date::Japanese::Era::Table::Builder Allows building a Data::Japanese::Era::Table dynamically

This module empowers Date::Japanese::Era by allowing lookups using an arbitrary table of Eras, dynamically generated or just tailored for some purpose.

The main usage, insofar as there is one, is for use of Date::Japanese::Era in the context of alternate or speculative historical fiction.

Additionally, and perhaps more usefully, it allows control of the romanisation. Where there is written 'taishou' above, 'Taisho', 'taisho' and 'Taishō' could have gone just as easily.

wito@github 1 comment

Cache::Memcache::Elasticache AWS auto-discovery wrapper for Cache::Memcached::Fast

A wrapper for Cache::Memacached::Fast with support for AWS's auto reconfiguration mechanism. It makes use of an AWS elasticache memcached cluster's configuration endpoint to discover the memcache servers in the cluster and periodically check the current server list to adapt to a changing cluster.

zebardy@github 0 comments

Types::SQL Type library for SQL types, with ability to extract column info for DBIC

I've been thinking that it would be nice when using DBIx::Class to be able to define columns using Type::Tiny-style types, e.g.

column foo => ( isa => Maybe[Varchar[12]] );

and have something that extracts the column info from the type.

Whether this should be a change to DBIC or a plugin/extension, I'm not yet sure. But the first thing is to create a type library and a utility function to extract the column_info from the type.

Part of the idea is that you can declare your own types that inherit from these types, and it should still work.

robrwo@github 0 comments

IO::Die like autodie, but more flexible and encapsulated

FGasper@github 1 comment

Text::Quote::Self Encapsulate unsafe string as object that quotes itself in the needed way

UPDATE Renamed Text::Escape::Any => Text::Quote::Self - does the latter make more sense?

I would like to present a module that can hide potentially dangerous strings behind a facade with overloaded stringification. Concrete stringification method (as-is, uri-escape, quotemeta, etc) is chosen based on a package variable. Such variable can be localized to a scope, and is honoured by all of my stringifier objects at once.

This way the part of the application that handles data does not need to know about how we're going to present the data. And the presentation part may handle all of its input values as plain strings and not care to quote them properly, as long as preferred stringification method is set.

I still have some questions, mostly on naming:

  • Is Text:: the right namespace?
  • Is Text::Escape::Any a descriptive enough name, and what would be better if not?
  • It seems reasonable to abbreviate constructor. Is safe_text() a rare enough function name to not infringe on users' functions/methods?
  • I want to keep the package switch name as close the above as possible. Is $safe_text_escaping good enough?

dallaylaen@github 0 comments