uricolor is a trivial script to colorize URIs with ANSI colors (underlined blue), based on URI::Find and Term::ANSIColor. It simply reads from STDIN and writes to STDOUT.

Useful in combination with urifind (provided by URI::Find).

• For a live demonstration of above example: http://q37.info/s/zmzcxvm9
• for other live demonstrations: http://q37.info/s/sssznrb4

The Atlas toolkit (http://atlastk.org/) purpose is to provide a fast and easy way to add a graphical interface to programs. This toolkit is available for Java, Node.js, PHP, Python, Ruby, and, now, also for Perl. It's lightweight, does not need other Perl modules, and requires only basic knowledge of widespread and easy-to-learn web technologies (no JavaScript required).

It can be easily used in programs that were not originally designed to have a GUI, so the user can choose which interface s/he wants to use. The Atlas toolkit also facilitates the development of prototypes, and can also easily be used by beginners.

This is a trivial Template::Toolkit plugin filter to allow any template writer to embed PlantUML Diagram Syntax in Templates and have them encoded and processed via any PlantUML Server in any supported formats.

It uses WWW:PlantUML remote client under the hood.

The author got his inspiration from XSAWYERX's Template::Plugin::xkcd

• Plantuml is a library for generating UML diagrams from a simple text markup language.

• This is a simple Perl remote client interface to a plantuml server using the same custom encoding used by most other plantuml clients. Perl was missing from the list.

• There are other plantuml Perl libraries, like PlantUML::ClassDiagram::Parse, which provide only parsing capabilities for Class Diagrams. In contrast WWW::PlantUML module provides accessing any UML Diagram Type in various formats supported by any PlantUML server via HTTP/S Protocol.

• This client defaults to the public plantuml server, but can be used against any server.

• Read more: http://plantuml.com/de/server

• See also: UML::PlantUML::Encoder

• Plantuml is a library for generating UML diagrams from a simple text markup language.

• PlantUML defines a standardized way to encode diagram text description to a simple string of characters that contains only digits, letters, underscore and minus character.

• The goal of such an encoding is to facilitate communication of diagrams through URL (see http://plantuml.com/de/server).

• This encoding includes compression to keep encoded strings as short as possible.

• Compression is done using Deflate algorithm.

• Code in PHP, Javascript, Python were readily available on various sources. Perl 5 was missing from the list.

• Read more: PlantUML Text Encoding

This was formerly posted as "AstroScript". Following the recommendations of djerius@github, I separated the astronomical code into an independent library, named after one of the authors of algorithms, Oliver Montenbruck, and placed it into Astro:: namespace.

The main purpose is to calculate positions of the Sun, the Moon, and the planets with precision that is approximately the same as that found in astronomical yearbooks. Other modules contain time-related routines, coordinates conversions, calculation of the ecliptic obliquity and nutation, etc. Over time, the range of utility functions will grow.

Partially it overlaps some code which already exists in CPAN and elsewhere. For instance, there is a Perl wrapper for Swiss Ephemeris. Swiss Ephemeris is fast and precise C library. Unfortunately, it lacks portability and convenient license.

The present library is an attempt to find a middle-ground between precision on the one hand and compact, well organized code on the other. I tried to follow the best practices of modern Perl programming.

There are many astronomical libraries available in the public domain. While giving accurate results, they often suffer from lack of convenient API, documentation and maintainability. Most of the source code is written in C, C++ or Java, and not dynamic languages. So, it is not easy for a layman to customize them for her custom application, be it an online lunar calendar, horoscope or tool for amateur sky observations. This library is an attempt to find a middle-ground between precision on the one hand and compact, well organized code on the other.

Most of the calculations are based on "Astronomy On The Personal Computer" by O.Montenbruck, T.Phleger, Fourth Edition, Springer-Verlag, 2000.

The library includes:

AstroScript::MathUtils — Core mathematical routines. AstroScript::Time — Time-related routines. AstroScript::Ephemeris — Positions of celestial bodies. AstroScript::Angles — Some abstract points related to diurnal rotation of the Celestial Sphera: Ascendant, Midheaven, Vertex, East Point. AstroScript::CoCo — Coordinates conversions. AstroScript::Houses — Astrological houses, by the most used systems. AstroScript::Nutation — Nutation and obliquity of ecliptic.

Hey Perlers!

I've come up with my own module for lookuping data structures in one single line without autovivification.

Comprehensive examples could be found in test.t in the repository.

Here, I found some alternatives:

• Data::DRef.
• Data::Reach.
• Data::Diver.

But I find my module more 'lightweight' and neat.

What do you think? Is it worth publishing?

This module is a logger with adjustable verbosity for commandline programs. Different verbosity levels can have different colors and styles applied and specific functions or methods can get extra verbosity. Message colors and styles are fully user-definable.

Additional functions are provided for displaying summaries of all warnings or errors encountered. Stack traces can been shown on demand or whenever there are warnings or errors.

This is a strictly functional module (no use of objects or methods). Tests have yet to be written.
Full documentation is available here and usage examples can be found in the examples/ directory.

Comments?

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!