Archive for the ‘Perl’ Category

REST::Neo4p – A Perl “OGM”

Monday, October 22nd, 2012

REST::Neo4p – A Perl “OGM”

From the post:

This is a guest post by Mark A. Jensen, a DC area bioinformatics scientist. Thanks a lot Mark for writing the impressive Neo4j Perl library and taking the time to documenting it thoroughly.

You might call REST::Neo4p an “Object-Graph Mapping”. It uses the Neo4j REST API at its foundation to interact with Neo4j, but what makes REST::Neo4p “Perly” is the object oriented approach. Creating node, relationship, or index objects is equivalent to looking them up in the graph database and, for nodes and relationships, creating them if they are not present. Updating the objects by setting properties or relationships results in the same actions in the database, and returns errors when these actions are proscribed by Neo4j. At the same time, object creation attempts to be as lazy as possible, so that only the portion of the database you are working with is represented in memory.

The idea is that working with the database is accomplished by using Perl5 objects in a Perl person’s favorite way. Despite the modules’ “REST” namespace, the developer should almost never need to deal with the actual REST calls or the building of URLs herself. The design uses the amazingly complete and consistent self-describing information in the Neo4j REST API responses to keep URLs under the hood.

A start on a Perl interface to Neo4j.

I am sure comments, testing and suggestions are welcome.

Machine Learning in All Languages: Introduction

Wednesday, September 5th, 2012

Machine Learning in All Languages: Introduction by Burak Kanber.

From the post:

I love machine learning algorithms. I’ve taught classes and seminars and given talks on ML. The subject is fascinating to me, but like all skills fascination simply isn’t enough. To get good at something, you need to practice!

I also happen to be a PHP and Javascript developer. I’ve taught classes on both of these as well — but like any decent software engineer I have experience with Ruby, Python, Perl, and C. I just prefer PHP and JS. Before you flame PHP, I’ll just say that while it has its problems, I like it because it gets stuff done.

Whenever I say that Tidal Labs’ ML algorithms are in PHP, they look at me funny and ask me how it’s possible. Simple: it’s possible to write ML algorithms in just about any language. Most people just don’t care the learn the fundamentals strongly enough that they can write an algorithm from scratch. Instead, they rely on Python libraries to do the work for them, and end up not truly grasping what’s happening inside the black box.

Through this series of articles, I’ll teach you the fundamental machine learning algorithms in a variety of languages, including:

• PHP
• Javascript
• Perl
• C
• Ruby

Just started so too soon to comment but thought it might be of interest.

Neo4j [Perl client for Neo4j]

Sunday, June 17th, 2012

Neo4j [Perl client for Neo4j]

One of my daily searches turned up:

Neo4j – A client for the Neo4j graph database

Perl client for Neo4j. A very early version, Neo4j-0.01_01.

Neo4j is increases in popularity by leaps and bounds. So are the number of clients in a variety of languages.

If the string “Neo4j” is reserved for the graph software from the Neo4j project and some other string for software to use with it, searching for both additional software and the core package will be enhanced.

Imagine the confusion if dozens of clients are all called “Neo4j” and you are searching for email or newsgroup reports on some issue.

Semantic confusion is going to happen. I don’t mean to imply otherwise.

But let’s not help it along if we can avoid it.

Lucy (not in the sky with diamonds)

Tuesday, November 15th, 2011

Lucy (not in the sky with diamonds)

From the overview:

Apache Lucy is full-text search engine library written in C and targeted at dynamic languages. It is a “loose C” port of Apache Lucene™, a search engine library for Java.

From the FAQ:

Are Lucy and Lucene compatible?

No. Lucy is a “loose” port of Lucene designed to take full advantage of C’s unique feature set, rather than a line-by-line translation from Java. The two libraries are not compatible in terms of either file format or API, and there are no plans to establish such compatibility.

Is Lucy faster than Lucene? It’s written in C, after all.

That depends. As of this writing, Lucy launches faster than Lucene thanks to tighter integration with the system IO cache, but Lucene is faster in terms of raw indexing and search throughput once it gets going. These differences reflect the distinct priorities of the most active developers within the Lucy and Lucene communities more than anything else.

Does Lucy provide a search server like Solr?

Lucy is a low-level library, like Lucene. We’d like to provide a search server eventually, but it will likely be a thin wrapper rather than a comprehensive application like Solr. The low-level capabilities are our core mission.

Why don’t you use Swig?

A major design goal of Lucy is to present bindings which are as idiomatic as possible so that our users feel as though they are programming in their native language and not in C. Swig is a great tool, but it does not offer support for many of the features which make Lucy so user friendly: subclassing, named parameters, default argument values, etc.

I poked around in the former KinoSearch archives, does “dynamic languages” = Perl? Just curious.

ack

Tuesday, October 18th, 2011

ack

From the webpage:

ack is a tool like grep, designed for programmers with large trees of heterogeneous source code.

ack is written purely in Perl, and takes advantage of the power of Perl’s regular expressions.

It is said to be “pure Perl” so Robert shouldn’t have any problems running it on Windows.

Seriously, the more I think about something Lars Marius said to me years ago, about it all being about string matching, the more that rings true.

Granting that we attach semantics to the results of that string matching but insofar as our machines are concerned, it’s just strings. We may have defined complex processing for strings, but they remain, so long as they are not viewed by us, simply strings.

(What I remember of conversations, remarks is always subject to correction by others who were present. I am sure their memories are better than mine.)