Experimenting with pry and JRubyArt

If we replace ruby-processings 'live.rb' with the following version, we can easily use pry with ruby-processing (but I am not sure what for, because I don't use pry).

# An PRY shell for live coding. 
# This flavor will either load up empty JRubyArt sketch, 
# or will start with your sketch.

require "#{File.dirname(__FILE__)}/base.rb"
Processing.load_and_run_sketch

ARGV.clear # So that IRB doesn't try to load them as files.

require 'pry'

binding.pry

You still need to access sketch using $app, eg $app.background 0 sets background to 0 (but I expect that could be changed?). Ideally you will also install pry with rgem, and use the --gem flag to be sure that jruby can use the pry gem. Actually turn out this is still somewhat flakey, certainly on linux.

Rakefile to run JRubyArt sketches in a directory from netbeans (tested with samples/contributed)

NB need to adjust path to "k9" executable...., since we are running with development version in netbeans (not an externally installed version)

# Simple demo Rakefile to autorun samples in current directory
# from netbeans, adjust path to k9 executable as required

SAMPLES_DIR="./"

desc 'run demo'
task :default => [:demo]

desc 'demo'
task :demo do
  samples_list.shuffle.each{|sample| run_sample sample}
end

def samples_list
  files = []
  Dir.chdir(SAMPLES_DIR)
  Dir.glob("*.rb").each do |file|
    files << File.join(SAMPLES_DIR, file)
  end
  return files
end

def run_sample(sample_name)
  puts "Running #{sample_name}...quit to run next sample"
  open("|../../bin/k9 run #{sample_name}", "r") do |io|
    while l = io.gets
      puts(l.chop)
    end
  end
end

Experimental handler for overloaded "background" in JRubyArt

Previously for ruby-processing, we allowed jruby to make sensible choices for methods with overloaded signatures (but to encourage more efficient operation, jruby is being very noisy about it) and we told you how you can use specific method signatures using java_alias to shut up jruby (and be more efficient). However background it could be argued (because of its ubiquity in sketches and the unique method signatures) might warrant special treatment. Here is an experiment to add such features via the helper_methods module.

# The vanilla processing background method is highly overloaded, a single
# argument could be an instance of PImage, int or float (multiple arguments are
# usually taken to be floats).
# @param *args arguments for background as an Array
#

def background *args
  if (args.length == 1)
    if args[0].kind_of? Integer
      self.java_send :background, [Java::int], args[0]
    elsif args[0].kind_of? Float
      self.java_send :background, [Java::float], args[0]
    elsif args[0].kind_of? Java::ProcessingCore::PImage
      self.java_send :background, [Java::ProcessingCore::PImage], args[0]
    end
  elsif (args.length == 3)
    self.java_send :background, [Java::float, Java::float, Java::float], args[0], args[1], args[2]
  elsif (args.length == 2)  # greyscale with transparency
    self.java_send :background, [Java::float, Java::float], args[0], args[1]
  elsif (args.length == 4) # color with transparency
    self.java_send :background, [Java::float, Java::float, Java::float, Java::float], args[0], args[1], args[2], args[3]
  end
end

JRubyArt is the development branch of ruby-processing.

Developing JRubyArt with Netbeans

Thanks largely to Thomas Enebo, I expect to be doing future development of JRubyArt all under Netbeans see screenshot click on image to see full size:-

Screenshot of me developing JRubyArt  with Netbeans

It is just bloody brilliant, brings all the code together, sensible refactoring hints, easy renaming etc.etc.

Time to give up on the Mac

I have started a new development fork of ruby-processing, I am calling it JRubyArt, there will be no support for the Mac (in the foreseeable future, possibly never, depends on active co-operation Mac users). Calling it JRubyArt may not be so daft because the end point need not only be a processing sketch (PovRAY or Sunflow).
It is an absolute requirement of the development branch to be using at least java-7 (this is requirement for processing-2.1+, but I am really targeting java-8). The idea is that JRubyArt keeps step with jruby-9000 development (which will likely require at least java-7, but likely to work best with java-8). On this basis, there is absolutely no point in supporting the Mac, which post Maverick seems to be designed not to work with java (having said that many jruby users have Macs go figure).

Revised advice for Mac users of ruby-processing

Update 7 December 2012

It appears that vanilla processing-2.1.0 may not be working on Mavericks, however processing-2.0.3 does work, especially using Apple jvm (but this is unsustainable in longer term, and I am sure you should be working towards using the latest Oracle jvm). It seems that you should really install the Oracle JDK rather than just the runtime (to get links updated etc) but if you have previously installed the Apple jvm make sure you do a thorough job of uninstalling it first.
I have just updated the main branch of ruby-processing (version 2.4.0) to make use of an installed version of vanilla processing. Until Ben Fry endorses processing-2.1+ on Mavericks, I recommend installing processing-2.0.3 on the Mac (and processing 2.1+ on linux and Microsoft windows).

Ruby-processing on MacOSX, Apple or Oracle JVM

UPDATED 1 February 2014 ruby-processing-2.4.2 (is now available as a rubygem)

Now this is entirely theoretical as I've exceptionally limited experience with a MAC (I once loaded some photos on my Artist friends MAC). However, from what I understand if you update to Mavericks, you won't have java installed.  The ideal solution from my point of view, is that this forces you to install Oracle jdk1.7.0_51 (64 bit). However apparently if you are conservative, or otherwise need it, apparently you can get Apple jvm here.


For OSX users incapable of using google, for some reason following link may be helpful stackoverflow it may even encourage you to do the sensible thing and install the Oracle jvm?

But what does this mean for ruby-processing on MacOSX:

Use processing-2.0.3 especially if you are sticking with Apple jvm (Mavericks or otherwise)

Step by step instruction to install of the latest version of ruby-processing:-

1. Install jruby (at least version 1.7.3 but preferably 1.7.10)
2. Install processing-2.0.3, or if not on Mavericks you could try processing-2.1.1 & jdk7
3. Run the processing sketch here to set the path to the processing root
4. gem install ruby-processing
5. install_jruby_complete
6. cd your work directory
7. rp5 unpack samples
8. cd samples/contributed
9. rp5 run grapher.rb (or jwishy.rb or whatever)

Please report how you get on since if I can establish that this is working OK we will be able to return to ruby-gems distribution. If you don't have a system installed jruby, all sketches you would need to use the --nojruby flag to use the vendored jruby-complete eg

rp5 --nojruby run grapher.rb

Here is another link that might be useful re installing jdk7.