PrePAN

Sign in to PrePAN

PrePAN provides a place
to discuss your modules.

CLOSE

Requests for Reviews Feed

Mojo::IOLoop::Signal Mojo::IOLoop based, non-blocking signal handler

Mojo::IOLoop::Signal is a Mojo::IOLoop based, non-blocking signal handler.

Questions:

  • Why does not Mojo::IOLoop officially support signals?
  • Do you think this module useful?
  • Any feedback is welcome.

Thanks.

skaji@github 0 comments

Alien::Boost Alien package to make the Boost libraries available to other modules at C level

To make available some C++ libraries from Perl, sometimes you need the boost libraries in order to compile the C++ bindings. In linux you can rely on the distro package system, but in windows there isn't package system.

Also the Boost libraries are very useful, for example:

Some modules include boost as part of the distribution: Boost::Geometry::Utils, Boost::Graph but I think it's better to manage Boost as another module dependency

This module aim to make easier to module authors to manage the boost library dependency.

pablrod@github 0 comments

Bio::SeqFeature::Generic::PrimerMap extends Bio::SeqFeature::Generic class to generate a PrimerMap

This module extends the Bio::SeqFeature::Generic module (part of the BioPerl core) to build a graphical map of primer sequences aligned along a base input DNA sequence (represented as a number line). The input should list the starting and ending coordinates (as base pairs) of a list of primers (see sample code above). It is a very straight forward module and I'm hoping to get feedback on code, naming conventions, and structure before submitting to CPAN.

dohalloran@github 2 comments

CCP::Xero Perl module to access Public and Private Xero Accounting Application API

We use this module for our internal integration with Xero accounting API and I am working to generalise it to release on CPAN.

Some good initial feedback from http://www.perlmonks.org/?node_id=1176469 and other reading have given me some ideas about what needs to change in this module next.

The top level CCP was chosen because the main application this code was taken from uses it. There are other modules that I had envisaged releasing through CPAN covering diverse functionality however I am currently inclined to change my top level for this module to either WebService or Finance.

There is an existing Net::Xero module in CPAN and I have been unable to open a dialog with the author. This is the module that informed the initial code but it's not feature-rich enough I believe to be included in the Xero suggested SDKs at developer.xero.com so I'd like to see a good Perl option in there.

pscott-au@github 0 comments

PerlSwagger Create RESTful webservices from OpenAPI (fka Swagger) 2.0 specification

Description (from README)

PerlSwagger is a simple to use web framework for RESTful webservices described with an OpenAPI 2.0 (formerly known as Swagger 2.0) specification.

The framework parses the specification on startup and creates a PSGI compatible app from it, which can be used with plackup.

Before calling any route handler, it checks the given parameters and only gives valid ones to the handler. Simple handlers don't have to know they are running as a webservice, as they just get a HashRef containing all the parameters and may return a HashRef as response body.

Handlers for routes are specified with the "x-handler" key in specification, which is something like this "My::Api::Code->handler_sub".

State

This module is work in progress. There are a lot of thing not yet working, like complete input validation or output validation (I think it would be good to HTTP 500 when invalid data is sent for output). The code may also need some refactoring.

PerlSwagger is developed as part of a bigger project, so features will be added as needed by me. If anyone else will be using it, I will also actively maintain PerlSwagger for use in other projects by the public.

LittleFox94@github 1 comment

Webservice::Freesound Perl wrapper around Freesound OAuth2 API

This module provides a Perl wrapper around the http://Freesound.org RESTful API.

Freesound is a collaborative database of Creative Commons Licensed sounds. It allows you to browse, download and share sounds. This Perl wrapper at present allows you 'read-only' access to Freesound, ie browse and download. Upcoming versions could provide upload, describe and edit your own sounds (though I expect it might just be easier to use their website for this).

The complete Freesound API is documented at https://www.freesound.org/docs/api/index.html

In order to use this Perl module you will need get an account at Freesound (http://www.freesound.org/home/register/) and then to register your application with them at http://www.freesound.org/apiv2/apply. Your application will then be given a client ID and a client secret which you will need to use to get OAuth2 authorisation.

The OAuth2 Dance is described at Freesound, https://www.freesound.org/docs/api/authentication.html and officially at RFC6749. It is a three step process as suggested above.

This module should look after the authorisation once done, ie when the expiry time arrives it can automatically refresh the tokens. The auth tokens are therefore kept as a file specified by "session_file", which should be read-only by you/www-data only.

When downloading a sound sample from Freesound a progress meter is available in "counter_file" which is useful in web contexts as a progress bar. Format of the file is : :: # for example "10943051:12578220:87", ie 87% of 12578220 bytes written. This is optional.

Also the download will download the sample file as its name and type suffix (some Freesound names have suffixes, some don't), so something like "/var/www/myapp/downloads/Pretty tune on piano.wav", ".../violin tremolo G5.aif" etc.

The query method allows you to put any text string into its parameter so that you have the full capabilities of Freesound search, filter, sort etc, as described here : https://www.freesound.org/docs/api/resources_apiv2.html

If used as part of a web app, then the process could be :

  • Check for session_file. If none then put up an iframe with the src set to output of $freesound-get_authorization_url();>
  • User clicks Authorise with a callback run (set in Freesound API credentials : http://www.freesound.org/apiv2/apply (ie http://localhost/cgi-bin/mayapp/do_auth.cgi) which calls $freesound-get_oauth_tokens ($code))> - the code will be a parameter in the CGI (ie $q-param ('code')>).
  • Text search box on main webpage can then be used as inputs to $freesound-query> - the output formatted into HTML (from XML or json) as you wish. With Freesound you get a picture of the waveform and a low quality sound preview so you can engineer your website to show the waveform and have start/stop/pause buttons. Best not to replicate the entire Freesound website, as this might contravene their terms and conditions.
  • A Freesound sample will have an id. This can be used in $freesound-download ($id, $dir, $counter_file)>.
  • Show download progress bar by continually polling the contents of counter_file (with an Ajax call) and drawing a CSS bar. Actually downloads to your server, not the web-browser users Downloads directory.

CaesuraMedia@github 1 comment

Sort::Naturally::XS Perl extension for human-friendly ("natural") sort order

Description

Natural sort order is an ordering of mixed (consists of characters and digits) strings in alphabetical order, except that digits parts are ordered as a numbers.

For example, standard machine-oriented alphabetical sort for list:

test21 test20 test10 test11 test2 test1

result to:

test1 test10 test11 test2 test20 test21

It isn't human-friendly, because test10 and test11 comes before test2. Natural sort order suggests the following:

test1 test2 test10 test11 test20 test21

Advantages

  • Written in C and XS, so it's really fast
  • Support already exists Sort::Naturally module API
  • Fix some Sort::Naturally deviation from normal sort behavior, like "foobar" comes before "foo13'

Benchmark

See synopsis section

the_serval@twitter 3 comments

Log-Dispatch-Email-Async Log4perl appender for emailing in separate, multiple threads.

Log-Dispatch-Email-Async

VERSION 0.01 - Initial version

This module is a Log::Log4perl appender. The module allows asyncronous emailing via a user-defined number of threads. It requires an operating network connection and will die otherwise.

Tests require intervension to seti the email parameters. All tests are skipped if email parameters are not set in the test file. This enables automated installs.

guharaja@github 0 comments

HTML::Template::Nest Nest HTML::Template's according to a structure provided in a hashref

HTML::Template is great because it is simple, and doesn't violate MVC in the uncomfortable way Mason does. However if you want components you can manipulate easily and nest arbitrarily, then the raw interface can be labour intensive to work with. For example, to recreate the example in the synopsis using plain HTML::Template, you would need to do something like:

# first create and populate the inner templates
my $box1 = HTML::Template->new( filename => 'box.html' ); 
$box1->param( title => 'First nested box' );
my $box2 = HTML::Template->new( filename => 'box.html' );
$box2->param( title => 'Second nested box' );

# feed the output to the contents of the parent
my $page = HTML::Template->new( filename => 'page.html' );
$page->param( contents => $box1->output.$box2->output );

print $page->output;

It's easy to see how this quickly becomes inconvenient as the size of the component structure increases. It would be better if a routine could create and fill in the params recursively - and this is where HTML::Template::Nest comes in.

Nest uses HTML::Template to create whatever nested structure of templates you give it. Nest

  • accepts the input structure as a hashref
  • with each (sub)component as a hashref,
  • and each list of components as an arrayref

ie. the components are represented in terms of the most obvious basic perl datatypes, which means you are free to form your structure in any of the many ways you can manipulate normal hashes/arrays. This ends up being a surprisingly powerful templating system with some great advantages - the most obvious being true separation of controller from view. E.g. lets say you wanted to create a 2 row 2 column table using the following templates:

table.html:

<table> <!-- TMPL_VAR NAME=rows --> </table>

row.html:

<tr> <!-- TMPL_VAR NAME=columns --> </tr>

column.html

<td> <!-- TMPL_VAR NAME=value --> </td>

If you were feeling masochistic, you could do this:

my $table = {
    NAME => 'table',
    rows => [{
        NAME => 'table_row',
        columns => [{
            NAME => 'table_column',
            value => 'Row 1 Col 1'
        },{
            NAME => 'table_column',
            value => 'Row 1 Col 2'
        }]
    },{
        NAME => 'table_row',
        columns => [{
            NAME => 'table_column',
            value => 'Row 2 Col 1'
        },{
            NAME => 'table_column',
            value => 'Row 2 Col 2'
        }]
    }]
 };

 print $nest->to_html( $table );

Note how each hashref gets a 'NAME' - this indicates the filename of the template (concat template_ext to get the filename). So 'NAME' is a special indicator. The rest of the variables in the hash are interpreted as fill-in parameters. If the fill in params point to text, then these are filled in directly. However if a fill in param is a hashref, then this is understood as a subcomponent, and turned into html before filling in. If a fill in param points to an arrayref, each element in the list is interpreted first (as a component, sublist or plain text) before the generated html is strung end to end in list order.

You can mix and match text fill-ins vs. sub component fill-ins to your hearts content. For example:

article.html: <div class='article'> <div class='columns'> <!-- TMPL_VAR NAME=columns --> </div> </div>

article_column.html: <div class='article-column'> <!-- TMPL_VAR NAME=contents --> </div>

my $article = {
    NAME => 'article',
    columns => [
        'Blah blah bla my column 1 is just a lump of text',
        { 
            NAME => 'article_column',
            contents => 'but col 2 is a subcomponent'

        }
   ]
};

(Obviously it's your job to make sure you create a structure that generates desirable html!)

Of course, you don't have to specify your structure with a single declaration - and why would you with the full flexibility of perl behind you? For example it makes sense to create a repeating structure like a table using a loop:

my $rows = [];
for my $i (1..2){

    my $cols = [];

    for my $j (1..2){
         push @$cols,{ 
            NAME => 'column',
            value => 'Row $i Col $j'
        };
    }

    push @$rows,{
        NAME => 'row',
        columns => $cols
    };
}

my $table = { 
    NAME => 'table',
    rows => $rows
};


print $nest->to_html( $table );

This is a good moment to explain that HTML::Template::Nest only uses the TMPL_VAR declaration from HTML::Template.

ie if you want to use TMPL_LOOP, TMPL_INCLUDE, TMPL_IF etc. then HTML::Template::Nest is not for you.

Why does HTML::Template::Nest not use these? Because the aim is to create a templating system with all of the processing in the perl, and no processing (other than filling in the template variables) in the template. After all if you are looping in the template, then your view and controller are not separate. (And with HTML::Template::Nest it's so very easy to create repetitive structures, so why would you want this anyway?)

whatnext@github 0 comments