Posts Tagged ‘ruby’

Familiar: Clojure plus Ruby

October 9th, 2011 2 comments

Last week I had three separate conversations with people about using Clojure’s data structures and concurrency primitives from a language that’s not Clojure. Something about parens or insisting on using a less capable language :)

So, this weekend I played around with using Clojure from Ruby, in particular JRuby. I haven’t done much Ruby in about a year, so I spent most of my time remembering that. Anyway, I ended up with a proof of concept: Familiar. See the readme there. Here’s an example:

That’s it. This gives full access to the clojure.core API including lazy seqs, STM, and all those goodies. Good idea? Idiotic? I don’t know, but it was a fun exercise.

Categories: clojure, ruby Tags: , ,

Scripting JSoar

August 30th, 2010 No comments

In simpler times (say 2001) Soar was just Tcl. That is to say, Soar was a module, dynamically loaded into a Tcl interpreter at run-time. When loaded, Soar added a bunch of useful commands to the interpreter. Like run, matches, preferences, and probably most importantly, the sp command. When you “sourced” a Soar file, the Tcl interpreter just executed commands, loading rules, setting watch levels, etc.

The main drawback to this whole situation was that Tcl didn’t always lend itself to friendly embedding in other programs. It had funny rules about threads and, if Tk was involved, demanded to have its message queue pumped. And, of course, very few people get to know Tcl enough to like it :)

On the other hand, you could create macros for repetitive Soar structures, define new RHS functions, manipulate I/O. In short, you had the power of a full programming language mixed in with your Soar code.

With Soar 8.6 Soar’s tight integration with Tcl was broken, replaced by SML and a stricter command interpreter. It still looked like Tcl commands, but there were no Tcl control structures, variables, etc. Way it goes. When I initially started work on JSoar, I needed to quickly bootstrap a command interpreter so I could load existing code into the kernel. I turned to Tcl, in the form of Jacl, a Java implementation of Tcl. It saved a lot of time and, since Soar’s syntax was still basically Tcl, no one would really notice.

Of course, as I mentioned, no one wants Tcl, so over the last couple weeks, I’ve added a new scripting layer to JSoar. This time, I’m taking advantage of the Java Scripting API, JSR-223. This allows any scripting language with a JSR-223 implementation to be pretty seamlessly accessed from Java (and vice versa). With this new capability, it’s now possible to automate Soar agents, implement simple agent environments, and extend SoarUnit testing to include I/O, all from within a Soar source file. All with a variety of languages including Ruby, JavaScript, Python, Clojure, Groovy, etc.

A scripting engine (a language implementation) is invoked with the script command:

script javascript {
   soar.onInput(function(e) {
      soar.wmes.add("my-input", "hello");
   soar.onOutputCommand("say", function(e) {
      soar.print("The agent says: " + e.greeting);

This little bit of code sets up an input phase callback and creates a WME on the agen’ts input-link. It also handles an output command called “say”. The equivalent Java code would be … more ceremonious. Not to mention setting up a new project, compiling, etc, etc is a major hassle.

As an example, I’ve implemented a simple waterjugs environment in JavaScript, Ruby, and Python. Here are some things you can do:

  • Generate input
  • Handle output commands
  • Auto-convert hashes (JavaScript objects, Python dicts, or Ruby hashes) to input structures
  • Install new RHS functions
  • Add new commands
  • and on and on

Also, with maybe a little more work, I might have a pretty good story for dealing with I/O in SoarUnit tests. Stay tuned.

More detailed info on JSoar scripting support can be found on the JSoar wiki.

99 Prolog Problems in Ruby

April 12th, 2009 No comments

I spent the weekend on the shores of Lake Huron. During the kids’ naps, I worked through the first 28 problems of P-99: Ninety-Nine Prolog Problems in Ruby. Many have done it before me (in many languages and variations). Many will do it after.

So far P27 gave me the most trouble because I refused to use my brain. Figured it out on a nice long walk with the family. P28 was a pain because I was figuring out how Ruby blocks/procs work. Here’s the code.

p.s. an immutable list, like in Scala (or Lisp, etc, etc), with pattern matching of course, would be handy in Ruby. I wonder if one exists…

Categories: ruby Tags: ,

The Ruby Way: Chapter 1 … bipolar

January 27th, 2009 2 comments

I just finished chapter 1 of “The Ruby Way” by Hal Fulton.  I feel a little torn because it is simultaneously one of the worst chapters I have read, and also one of my favorites.  I’ll start with the bad.

The editing is pretty bad. I came across a number of typos which make me wonder if anyone actually read it before going to print. On top of that, this is some seriously sloppy technical writing (kind of like this blog). New or alternative terms are introduced without note, examples are only explained by cryptic, embedded comments, and seemingly complex concepts are given no examples at all.

The one statement that stuck out for me was on page 5 where the author describes the is-a relationship:

The relationship between a class and its superclass is interesting and important; it is usually described as the is-a relationship, because a Square “is a” Rectangle, and a Rectangle “is a” Polygon, and so on.

Ummm, please tell me that your first example of a class hierarchy isn’t one that if not just wrong is at least highly controversial.  You couldn’t have started with Person and Employee?

Hal Fulton calls this chapter “our review of object-oriented programming and our whirlwind tour of the Ruby language” so besides the typos and sloppiness, I’ll give him a break. That’s really a lot to jam into one chapter of a book whose intended audience is assumed to basically know all that stuff.

It’s like a man page. It all makes perfect sense if you already know it.

So as my hesitation grew, I reached section 1.5, “Training Your Intuition: Things to Remember”. This is where, in my opinion, the author turns everything around. This is one of my favorite sections of a technical book I’ve read in a long time. It’s basically a somewhat random laundry list of Ruby idioms, gotchas, and nuggets of general wisdom. It reminds me of the best stuff you find in a FAQ when learning a new language. It reminds me of the lists I write for colleagues when I have to bring them up to speed on a new technology. It reminds me of how I felt the first time I read Effective C++ when I was too young and foolish to recognize that for the oxymoron it was.  It’s all the stuff that you wish that a language manual would come out and tell you right away, but is completely missing or at least hidden between simplistic examples.

Great stuff. Anyway, at least he ended on a high note. Flipping through the rest of the recipe-style chapters of the book, I’m pretty confident I’ll find it invaluable specifically because it continues that laundry list style that for some reason appeals to me so much.

p.s. my “learning scala” project was a simple rules engine. For Ruby, I’m planning on a tcl interpreter. Hopefully, I can do it in less than 550 lines. Combining the speed of Ruby with the speed and expressiveness of Tcl … good times.

Categories: ruby Tags: