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

Thursday 30 July 2015

Ruby-Processing now using pry for live coding mode

The latest release of ruby-processing uses pry for live coding, and this is genuinely exciting. Here is a live mode for a class wrapped jwishy.rb sketch, which I have listed in the pry console using '$' command (NB: click on images to see full size):-

This is all the class wrapping needed

class JWishy < Processing::App
  # bare sketch code
end
Bare sketches instead get listed as the super class, but to be honest listing of the code in the pry console is not that exciting see embedded video, the exciting bit is to be able to futz with sketch code from the console and watch it affect the running console (but why not try it for yourself). In the "Wishy Worm" example we change the background of the sketch by changing the @back_color variable, and change the bluish accessor method to a custom method that returns bluish as function of the y_wiggle variable

But you can do so much more, including 'ls' available methods, and remember pry has a built in help...


live from monkstone on Vimeo.

Live coding in ruby-processing now using pry

Bounce.rb code used in video
You should also checkout the pry 'edit' function, which allows you to use your favourite editor to edit a method say 'JWishy#draw'

Sunday 26 July 2015

Yet more experiments with JRubyArt and pry

My experience of ruby-processing with pry (for live mode) has not been promising, however things change so I thought I would give it another go, since the live IRB, has not been that wonderful either:-
The live.rb code
# An pry shell for live coding.
# Will start with your sketch.

require_relative 'base'
Processing.load_and_run_sketch

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

require 'pry'
$app.pry

The sketch k9 create fred 300 300 --wrap
class Fred < Processing::App
  def setup
    sketch_title 'Fred'
  end

  def draw

  end

  def settings
    size 300, 300, FX2D
    # smooth # here
  end
end

k9 live fred.rb

Turns out it was a really lucky choice to experiment with FX2D sketch (as there might be threading or other issues with JAVA2D), another strategy that seemed to work well is to redefine the sketch draw loop from pry (still can't see a serious use case, but it is a bit of fun). IRB can handle a yield block in draw loop (with block_given? guard) but it doesn't play too well with pry.

Tuesday 14 July 2015

A more refined (ruby-2.2) interface for java classes with mixed arguments

Since ruby-2.0 it has been possible to use keywords as first class arguments, and ruby-2.1 introduced the required keyword argument (these are available to JRubyArt and potentially ruby-processing since jruby-9.0.0.0). So I thought it would be sensible to make use of them to make say the parameters of an ArcBall library more descriptive:-
# experimental ArcBall class
class ArcBall
  attr_reader :applet, :x, :y, :r
  def initialize(app:, center_x: nil, center_y: nil, radius: nil)
    @applet = app
    @x = (center_x.nil?) ? app.width * 0.5 : center_x
    @y = (center_y.nil?) ? app.height * 0.5 : center_y
    @r = (radius.nil?) ? app.width * 0.8 : radius
  end

  def to_s
    format('ArcBall.new(applet: %s, centre_x: %d, centre_y: %d, radius: %d)',
           applet, x, y, r)
  end
end

Applet = Struct.new(:width, :height) do
  def to_s
    'MyApplet'
  end
end

applet = Applet.new(800, 600)
puts ArcBall.new(app: applet).to_s
puts ArcBall.new(app: applet, center_x: 300, center_y: 200, radius: 800).to_s

Output:
ArcBall.new(applet: MyApplet, centre_x: 400, centre_y: 300, radius: 640)
ArcBall.new(applet: MyApplet, centre_x: 300, centre_y: 200, radius: 800)

Testing whether concept works in practice for JRubyArt (using a local ArcBall library in sketchbook for test purposes);-
load_library :arcball

def setup
  sketch_title 'Arcball Box'
  ArcBall.new(app: self)
  fill 180
end

def draw
  background 50
  box 300, 300, 300
end

def settings
  size 600, 600, P3D
  smooth 8
end

# experimental ArcBall class
class ArcBall
  include_package 'arcball'
  attr_reader :applet, :x, :y, :r
  def initialize(app:, center_x: nil, center_y: nil, radius: nil)
    @applet = app
    @x = (center_x.nil?) ? app.width * 0.5 : center_x
    @y = (center_y.nil?) ? app.height * 0.5 : center_y
    @r = (radius.nil?) ? app.width * 0.8 : radius
    app = JarcBall.new applet.to_java, x.to_java(:float), y.to_java(:float), r.to_java(:float)
    app.set_active true
  end

  def to_s
    format('ArcBall.new(applet: %s, centre_x: %d, centre_y: %d, radius: %d)',
           applet, x, y, r)
  end
end

And indeed it does work if you supply suitable java types to the "hidden" java ArcBall class.

Friday 3 July 2015

JRubyArt-0.3.0 vs ruby-processing-2.6.12

Previously I posted a comparison between a different version of JRubyArt and ruby-processing where both were running using processing-2.2.1 and the the same version, but they had different designs. The current JRubyArt candidate is more similar to ruby-processing, but is targetting processing-3.0 (currently 3.0a10) and jruby-9.0.0.0 (currently jruby-9.0.0.0.rc1). I see ruby-processing as sticking with processing-2.2.1, but remaining compatible with stable releases of jruby, whereas JRubyArt will only be compatible with processing-3.0a10+.

External Dependencies

  • ruby-processing requires an installed version of processing-2.2.1
  • ruby-processing requires an installed version of processing-3.0a10+

Core processing libraries (sound, video etc)

  • ruby-processing has builtin support 
  • jruby_art has the same built in support but sound, video libraries are now external (since processing-3.0)

Contributed processing libraries

  • ruby-processing has builtin support for libraries installed by processing ide 
  • jruby_art has the same builtin support for libraries installed by processing

Vec2D, Vec3D, Arcball and DEGLUT

  • ruby-processing requires load_library 
  • jruby_art these libraries automatically loaded into jruby runtime

Processing::Proxy module

  • in ruby-processing Proxy can be used to mimic processings inner classes, probably v. bad juju convenience isn't everything 
  • in jruby_art a different Proxy can also be used to mimic processings inner classes but has a simpler implementation

Thursday 2 July 2015

Experimenting with standalone app using jruby

On the jruby wiki there is an explanation of how to create standalone JRuby apps, it appears to be v. old referring to since JRuby-1.6 but I have found it still works with JRuby-9.0.0.0-SNAPSHOT (as of 2 July 2015) see steps I took:-
cp jruby/lib/jruby.jar myapp.jar         # adjust path to jruby.jar
echo "puts 'hello'" >> jar-bootstrap.rb
jar ufe myapp.jar org.jruby.JarBootstrapMain jar-bootstrap.rb
java -jar myapp.jar

output was as expected 'hello'. Perhaps I could harness this for JRubyArt app export?
Here is what my myapp.jar MANIFEST.MF looks like:-
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Built-By: tux
Created-By: Apache Maven 3.3.3
Build-Jdk: 1.8.0_45
Main-Class: org.jruby.JarBootstrapMain

Apparently you can also embed additional .rb files into the jar, and the root of the jar file will be used as an implicit LOAD_PATH entry. Warbler is another option to consider.

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