PrePAN

Sign in to PrePAN

PrePAN provides a place
to discuss your modules.

CLOSE

Requests for Reviews Feed

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 2 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

Config::Apple::Profile Object-oriented interface for creating and maintaining Apple configuration profiles

(Should I call this XML::AppleConfigProfile or XML::Apple::ConfigProfile ? I'm starting to lean to XML::Apple::ConfigProfile)

Apple provides users with a way to configure Apple devices (running iOS or Mac OS X) using ready-made configuration files, which Apple calls Configuration Profiles. This suite of Perl modules is intended to aid people who would like to generate their own configuration profiles, without having to mess around with the XML themselves.

Configuration profiles can be used by iOS and Mac OS X to set a number of general and user-specific items. Examples include:

  • Configuring an LDAP server, for directory search in Mail and Contacts.
  • Specifying password requirements to match company policy (and common sense).
  • Configuring an email account, with or without a user's credentials.
  • Adding new certificate authorities.

Configuration profiles can be pre-made static files, or they can be dynamically-generated with configurations (such as usernames and passwords) that are specific to a user. Configuration profiles may be encrypted (so they may only be read on a specific device) and signed (to verify that they have not been modified by anyone other than the profile's creator).

The Configuration Profile Reference is publicly available here: https://developer.apple.com/library/ios/featuredarticles/iphoneconfigurationprofileref/iPhoneConfigurationProfileRef.pdf

My ultimate goal is to have a suite of modules that will be able to create, export, and import all of the configuration profile payload types defined in the reference above, with the ability to sign and encrypt. However, in order to get the software out sooner, here are the milestones I'm trying to meet, with releases happening as each milestone is met.

  1. Finalize the class hierarchy, so new classes immediately have a place to live. Create all of the common payload-related code, so that adding new payloads will be easier. Implement some of the payload types. Profiles can be created and exported at this point, as long as their classes have been written.
  2. Continue adding support for additional payload types, eventually supporting all payload types.
  3. Add support for importing existing un-encrypted un-signed .mobileconfig files.
  4. Add support for signing, using OpenSSL's smime command (OpenSSL 0.9.8+).
  5. Add support for encryption, using OpenSSL's cms command (OpenSSL 1+).

Unit tests will be created as code is written. Travis-CI and Coveralls.io are used to keep track of test success and code coverage.

akkornel@github 3 comments

Dancer-Plugin-DetectRobots Dancer plugin which provides a keyword to test if the current client is a robot

A plugin for Dancer applications providing a keyword, is_robot, which tests request->user_agent and returns 1 if the user_agent appears to be a robot.

To use, simply call is_robot whenever/wherever you would like to know if the user is a bot or a human. For example, if you would like to skip logging for bots

if( ! is_robot ) {
    log_message("your log message");
}

The plugin has been written to be as efficient as possible. The list of Robot UserAgent strings is only matched against request->user_agent once per session.

Based upon Plack::Middleware::DetectRobots by Heiko Jansen

dbusarow@github 0 comments

Catalyst::Plugin::File::RotateLogs Catalyst Plugin for File::RotateLogs

This module allows you to initialize File::RotateLogs within the application's configuration. File::RotateLogs is utility for file logger and very simple logfile rotation. I wanted easier catalyst log rotation.

masakyst@github 0 comments

POE::Component::GPIO Hook up GPIO pins to POE

The synapsis is pretty self-explanatory, using POE::XS::Loop::EPoll, or similar, provide state changes and pin control on GPIO pins to POE.

Essentially integrate GPIO pin operations as easily as possible into your project, simple as that. In an ideal world.

torbjorn@github 0 comments

Plack-Middleware-Return-MultiLevel put Return::MultiLevel in $psgi_env

so there's Plack::Middleware::HTTPException that lets you abort out of the current point in code and return a PSGI response. Although we added this middleware to Catalyst there's a lot of feeling that using exceptions like this for flow control is not a great practice. Return::MultiLevel is another way to jump out of the call stack and return a PSGI response. The current version 'works for me' in that it could replace most or all of how catalyst is using exceptions for flow control. However there might be other use cases that I am not properly thinking of. Take a look and let me know if there's something cool about this you want to do, but can't because of the current approach. thanks

jjn1056@github 0 comments

Tk::DBI::LoginDialog DBI login dialog class for Perl/Tk.

DESCRIPTION "Tk::DBI::LoginDialog" is a dialog widget which interacts with the DBI interface specifically to attempt a connection to a database, and thus returning a database handle.

   This widget allows the user to enter username and password details into
   the dialog, and also to select driver, and other driver-specific
   details where necessary.

tmcmeeki@github 1 comment

Hash::Squash Remove numbered keys from a nested object

This package provides B and B subroutines to simplify hash/array structures.

ernix@github 5 comments

Text::Composer Handy Text Builder with Parameters and Logics

DESCRIPTION

I couldn't find nice modules which can handle parameterized text. Please let me know if you know similar modules.

SYNOPSIS

use Text::Composer;
my $composer = Text::Composer->new(
    start_symbol => '{{',
    end_symbol => '}}',
    recursive => 1,
);

say $composer->compose('My name is {{ name }}', +{ name => 'i110' });
# 'My name is i110'

say $composer->compose('My name is {{ name }}', +{
    name => '{{prefix}} i110',
    prefix => 'Mr.',
});
# 'My name is Mr. i110'

say $composer->compose('\{\{ escaped \}\} key will not be expanded', +{
    escaped => 'gununu',
});
# '{{ escaped }} key will not be expanded'

say $composer->compose('{{ with_complicated_logic }}', +{
    with_complicated_logic => sub {
        my ($self, $key) = @_;
        "This text was composed $key by {{ twitter_id }}";
    },
    twitter_id => sub {
        '@{{ user_name }}';
    },
    user_name => 'i110',
});
# 'This text was composed with_complicated_logic by @i110'

use Text::Composer qw(compose_text);
compose_text('{{without_oo_interface}}', +{ without_oo_interface => 'hakadoru' });
# 'hakadoru'

METHODS

  • new ( %args )

    • $recursive

      Expand parameters recursively. Default is true.

    • $start_symbol

    • $end_symbol

      Delimiters for parameters. Defaults are '{{' and '}}', respectively.

  • compose ( $template, $params )

    Compose rext using a template and parameters.

    • $template

      Parameterized text. Required.

    • $params

      Parameters which will be rendered in the template. This must be a hashref or coderef, otherwise it will throw an exception. And also, hash's values must be a scalar or coderef, otherwise it will throw an exception. Both of these coderefs take the same two arguments, Text::Composer instance itself and the accessing key, and should return a scalar or coderef. If the return value is a coderef, it will be called again (and repeat this process until you get a scalar value).

i110@github 3 comments