PrePAN

Sign in to PrePAN

PrePAN provides a place
to discuss your modules.

CLOSE

Requests for Reviews Feed

Scalar::IfDefined Apply block to scalar depending on whether the scalar is defined.

ifdef

Takes a block and a scalar value.

If the scalar value is undef, the block is ignored and undef is returned straight away.

If the scalar value is defined, then the block is evaluated with $_ as the value passed in, and the result of the block is returned.

nmbooker@github 1 comment

Games::Dukedom Display agnostic implementation of the big iron game of Dukedom

See POD

boftx@github 1 comment

WWW::BetfairNG Object-oriented Perl interface to the Betfair JSON API

Betfair is an online betting exchange which allows registered users to interact with it using a JSON-based API. This module provides an interface to that service which handles the JSON exchange, taking and returning perl data structures (usually hashrefs). Although some checking of the existence of required parameter fields is done, and a listing of the BETFAIR DATA TYPES is provided below, it requires a level of understanding of the Betfair API which is best gained from their own documentation, available from https://developer.betfair.com/

To use this library, you will need a funded Betfair account and an application key. To use the non-interactive log in, you will also need an SSL certificate and key (in seperate files, rather than a single .pem file). Details of how to create or obtain these, and how to register your certificate with Betfair are also available on the above website. The interactive login does not require an SSL certificate or key and is therefore easier to set up, but Betfair strongly recommend that unattended bots use the non-interactive version.

MyrddinWyllt@github 0 comments

Carp::Proxy Diagnostic delegation

Error messages in Perl are commonly coded with idioms like:

die 'explanation'
    if not $assertion;

The idiom is attractive when the explanation is simple. If an explanation grows to more than a few words, or if it requires calculation, then the surrounding flow becomes disrupted. The solution, of course, is to offload failing assertions to a subroutine.

Subroutines that perform diagnosis, compose error messages and throw exceptions tend to have repeated code at the beginning and end, with unique content somewhere in the middle. Carp::Proxy proposes a wrapper subroutine, called a Proxy, to factor out the repeated sections.

fatal 'user_subroutine'
    if not $assertion;

Proxys, like fatal(), serve as elaborate, customizable replacements for warn(), die() and members of the Carp:: family like confess(). If we look at warn(), die(), confess() and the like, we notice that they are all just different variations on two themes:

  • Add locational context to a user-supplied message.
  • Throw some kind of exception.

Carp::Proxy parameterizes the two themes into attributes of an exception object that is created whenever a Proxy is called. The Proxy passes the object to a user-defined "Handler" subroutine which is responsible for constructing the diagnostic message. When the Handler returns, the Proxy optionally adds "Context" (a stacktrace) to the message and performs "Disposition", typically by calling die().

When the object is constructed it captures the state of Perl's error variables, for later examination by the Handler. The object provides methods that aid in message composition. Attributes control message formatting, stacktrace generation and how Disposition will be handled.

The object overloads Perl's stringification operator with a message rendering method, causing uncaught exceptions to be nicely formatted. Exceptions that are caught can be modified and re-thrown.

thairman@github 1 comment

Bio::ViennaNGS Perl extension for Next-Generation Sequencing analysis

Bio::ViennaNGS is a collection of utilities and subroutines often used for Next-Generation Sequencing (NGS) data analysis. It comes with a set of utility programs for accomplishing routine tasks often required in NGS data processing. The utilities serve as reference implementation of the routines implemented in the library.

mtw@github 2 comments

App::DBBRowser New insert feature

Hello, I added the possibility to insert data into database tables to the latest developer releases.

There are 4 ways for the user to add the values for the "INSERT INTO":

Enter each time a column
Enter each time a row
Enter multiple rows
Read from a file

Id would be nice if I could get some feedback regarding these 4 input methods.

kuerbis@github 0 comments

Net::SNTP SNTP client and Server Module

This a single Client Server script that is based on RFC2030 (SNTP Protocol). It runs on while loop based on the interval defined by the server. It basically calculates 2 parameters (the roundtrip delay d and local clock offset t). This is my first attempt to wright a module so please take this in consideration upon reviewing my code.

thanos1983@github 0 comments

Mesos Perl bindings for Apache Mesos

Design

Instead of implementing pure perl drivers, which would require a lot of knowledge of Mesos' internals(and is more likely to break in future versions), I decided to steal certain patterns from Mesos' python bindings. Like in the python bindings, the perl drivers contain instances of C++ drivers, which register C++ proxy schedulers/executors with the C++ drivers. In python, these C++ proxy classes were essentially wrappers around the registered Python classes, which just obtained the GIL, decoded protobuf messages, and called the desired python code. To avoid using perl threads, I decided to create a C++ channel between the C++ proxy classes, and the perl drivers. The C++ proxy classes would send the command name, and encoded args into the channel, and perl drivers would decode the args and invoke the correct method on the perl classes. In perl, the channel was implemented as a tied filehandle so that it could be passed directly to IO::Select or AnyEvent, and used in an IO loop.

I must admit that I am new to XS and perl guts, so I would greatly appreciate a look from someone with XS experience. I also had a small number of other, general concerns.

Concerns

  • Namespace
    • would this be more appropriate under a different namespace(Net::Mesos, AnyEvent::Mesos)?
  • Architecture
    • does the use of a pipe/channel between the C++ threads and an AnyEvent IO watcher seem sane?
    • does using a tied filehandle, for the perl interface to the channel, seem sane?
    • any suggestions for how to better handle protobuf messages(is using Google::ProtocolBuffers simple enough)?
  • XS
    • are there any XS anti-patterns?
    • is there too much code in the typemaps(and should be moved into XS or perl)?
    • is there too much code in XS(and should be moved into perl)?
    • does using of an XS include file(include/XS/MesosUtils.hpp) seem sane?

mark-5@github 3 comments

Lock::Socket application lock/mutex module based on sockets

Lock::Socket provides cooperative inter-process locking for applications that need to ensure that only one process is running at a time. This module works by binding an INET socket to a port on a loopback (127.0.0.0/8) address which the operating system conveniently restricts to a single process.

The "lock_socket()" and "try_lock_socket()" functions both take a mandatory port number and an optional IP address as arguments, and return a Lock::Socket object on success. "lock_socket()" will raise an exception if the lock cannot be taken whereas "try_lock_socket()" will return "undef".

Objects are instantiated manually as follows:

Lock::Socket->new(
    port => $PORT, # required
    addr => $ADDR, # defaults to 127.X.Y.1
);

On most systems the $PORT number needs to be greater than 1024 unless you are running as root.

If $ADDR is not provided then it is calculated as follows:

Octet   Value
------  ------------------------------
1       127
2       First byte of user ID
3       Second byte of user ID
4       1

This scheme provides something of an automatic per-user lock for a given $PORT, provided there is no user ID greater than 65536. The calculated address can be read back via the "addr()" method.

As soon as the Lock::Socket object goes out of scope the port is closed and the lock can be obtained by someone else.

If you want to keep holding onto a lock socket after a call to "exec" (perhaps after forking) read about the $^F variable in perlvar, as you have to set it before creating a lock socket to ensure the it will not be closed on exec. See the example/solo file in the distribution for a demonstration:

usage: solo PORT COMMAND...

# terminal 1
example/solo 1414 sleep 10  # Have lock on 127.3.232.1:1414

# terminal 2
example/solo 1414 sleep 10  # bind error

mlawren@github 0 comments