Experiments with ruby-processing (processing-2.2.1) and JRubyArt for processing-3.0

Friday 27 December 2013

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.

Thursday 26 December 2013

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

Tuesday 24 December 2013

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.

Saturday 14 December 2013

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.

Tuesday 10 December 2013

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).

Friday 6 December 2013

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).

Followers

About Me

My photo
I have developed JRubyArt and propane new versions of ruby-processing for JRuby-9.1.5.0 and processing-3.2.2