Geo::Index is a module for creating in-memory geographic point indices. Once indexed, fast searches can be run. The module supports search by radius, by bounding box and by proximity.

This will be my first CPAN release so I welcome any feedback you might have. The module has full documentation and test cases. Have I missed anything?

As of v0.0.4 XS is being used directly instead of via Inline::C. Can anyone comment on whether the way I wrote the XS support code is correct for use in a module?

The following was in regards to v0.0.3:

One specific thing that I'd value feedback on is my use of Inline::C. My code does have automatic fallbacks in place for when C isn't available and includes instructions for using it (the C code) in a server environment. Is there anything else I should be aware of when using it in a module?

Thanks!

This is a module that beautifies SQL code.

Sometimes we create a Perl module for our private use that we are not ready or not able to release to CPAN. The utility cpan-mirror-tiny lets us create a private CPAN repositoy on our local filesystem to store such packages we can then use in our own projects.

This plugin gives you the ability to automate this task when you run "dzil release". Use this plugin instead of UploadToCPAN.

PhotoDB is an attempt to create a database for film photography that can be used to track cameras, lenses, accessories, films, negatives and prints, to fully catalogue a collection of photographic equipment as well as the pictures that are made with them. Read the CONCEPTS document for full details on the capabilities of PhotoDB.

PhotoDB can also write EXIF tags to scanned images taken with film cameras, so they appear in your digital photo library with the correct metadata (time, date, focal length, geotag, etc). At the moment, the PhotoDB project is unfinished and the code continues to change unpredictably. Look for a tagged release in the future!

The heart of PhotoDB is the MySQL/MariaDB backend database schema. This is the most complete part of the project and describes all the data that is recorded. The application is an interactive command-line tool to make it easier to add and edit data in the database. It is not a graphical interface or web application (but someone with the right enthusiasm and skills could use the logic I've already written to make a basic graphical interface quite quickly).

PhotoDB runs only on Linux systems and there are installation instructions for Fedora and Ubuntu Linux. However it should be able to run on pretty much any Linux distribution and MacOS as the Perl dependencies are portable. Soon there will be Docker support which will simplify installation and allow PhotoDB to run anywhere, including on Windows. The application is not quite feature-complete, so for now you may also need to edit parts of the database directly in some circumstances. You can access the raw database using the MySQL command line, by using an application such as MySQL Workbench or phpMyAdmin to obtain a GUI for manipulating the tables.

Recently I discovered some smart light bulbs from Yeelight which have pretty well documented API, unfortunately there is no Perl module to control them (similar, however not compatible, module is Device::Hue).

This Perl module implements local device discovery via Yeeling specific SSDP protocol and sending commands via control protocol in the JSON format.

Deferred loading of modules with large dependency footprint may improve test script and/or command-line tools load times.

Autoload is used. No performance penalty is imposed, aside from loading the module on the first call to it.

Of course, the drawback is that compile time errors (if any) are delayed until unexpected. Better check that the modules in question actually exist and load correctly.

This module is a wrapper around the standalone Perl script "psjoin.pl" by Tom Sato. All I did was the minimal set of changes to allow Tom's script to work as a Perl subroutine.

I just realized that the synopsis and description don't explain the handful of options; I'll add those.

Text::Parser is a bare-bones text parsing class. It is ignorant of the text format, and cannot recognize any grammars, but derived classes that inherit from it can specify this. They can do this usually by overriding just one of the methods in this class.

Future versions are expected to include progress-bar support, parsing text from sockets, or a chunk of memory. All these software features are text-format independent and can be re-used in parsing any text format. Derived classes of Text::Parser will be able to take advantage of these features.

Simple wrappers for core print-like methods (print, say, printf). The goal is to avoid using "print or die" since autodie does not work with print.

The "die" action can be configured by importing use_"action". Where "action" can be croak (default), die, carp, cluck, and confess.

Every method has three wrappers (with o/e/at at the end of the names)

The "o" method writes on STDOUT, the "e" method writes to STDERR and the "at" writes to file handle. The "at" methods will require a block, which is anyways the recommended way (according to Perl Best Practices) of passing filehandles when using print-like methods.

Example:

use Print::OrDie qw(use_confess sayo saye sayat);

# It will 'confess' if there's some error.  
sayo 'FOOBAR'; # writes "FOOBAR\n" at STDOUT
saye 'FOOBAR'; # writes "FOOBAR\n" at STDERR
sayat {*STDERR} 'FOOBAR'; # same as before
sayat {$my_file_handle} 'FOOBAR'; # writes "FOOBAR\n" at given file handle

Example:

use Print::OrDie qw(use_confess sayat printfat);
use autodie;

# It will 'confess' if there's some error.  
open my $fh, '>', 'foobar.txt';
sayat {$fh} 'FOO';
close $fh;
$fh = undef;
printfat {$fh // *STDOUT} 'FOO %s', 'BAR';

Will write "FOO\n" on the 'foobar.txt' file and 'FOO BAR' on the console (STDOUT)

Example

use autodie;
use File::Temp qw( tempfile );
use Print::OrDie qw( use_confess sayat sayo );

my ( $fh, $filename ) = tempfile();
close $fh;

print {$fh} q(); # It will not fail

sayat {$fh} q(); # It will fail

sayo 'finished'; # Will never execute

When implements concurrent non-blocking I/O using select(2) or others (without AnyEvent/IO::AIO), it makes many complex procedural codes. This framework makes easy to write it by scenarios. AnyEvent and IO::AIO are great tools, but I think these are too much for this case. IMO, this case is not needed async I/O or/and event loops.