Ruby-processing from an interpreter.

[poqudrof]

Hello,

I just had a look at the new version, and everything looks much clearer in the code ! However, I took advantage of the spaghetti-ish versions of before and I could run this in an interpreter : 

# -*- coding: utf-8 -*-
require 'ruby-processing' 

Processing::App::SKETCH_PATH = __FILE__
Processing::App::load_library :toxiclibscore

module Papartlib
  include_package 'fr.inria.papart.procam'
end

class Sketch < Processing::App

  def setup 
    size(800, 600, OPENGL)
  end

  def draw 
    background(0, 0, 0)
  end 
end

Sketch.new unless defined? $app

It was quite nice. I usually develop Processing sketches with emacs, and also ruby-processing sketches in emacs. I just run my jruby interperter and pry trough inf-ruby .

With the more recent version I have this : 

NameError: PApplet not found in packages processing.core; last error: cannot load Java class processing.core.PApplet

So, with my low background in Ruby I figured that the core.jar file was not loaded from ruby-processing (which is nice), but there is no possiblity to load it in a clean way. So here is my code now :

# -*- coding: utf-8 -*-
require 'ruby-processing' 

runner = Processing::Runner.new
Dir["#{Processing::RP_CONFIG['PROCESSING_ROOT']}/core/library/\*.jar"].each{ |jar| require jar }

Processing::App::SKETCH_PATH = __FILE__
Processing::App::load_library :toxiclibscore

module Papartlib
  include_package 'fr.inria.papart.procam'
end

class Sketch < Processing::App

  def setup 
    size(800, 600, OPENGL)
  end

  def draw 
    background(0, 0, 0)
  end 
end

Sketch.new unless defined? $app

Finally here is my question : Do you plan to support this kind of “advanced” use with a interpreter ?  If so, we could just have a function like this : 

Processing.init_sketch  __FILE__

instead of :

Processing::Runner.new
Dir["#{Processing::RP_CONFIG['PROCESSING_ROOT']}/core/library/\*.jar"].each{ |jar| require jar }
Processing::App::SKETCH_PATH = __FILE__

Cheers, thanks for the great work ! 

[monkstone]

I'm not all sure what you mean by new version of ruby-processing ie are you referring to the latest ruby-processing release (version 2.6.12). The experimental branch JRubyArt or my latest experimental version. For guidance I'm thinking of replacing JRubyArt with latest experimental version, because I can't easily get the current JRubyArt to work with jruby-9.0.0.0-rc1 (java CLASSPATH loader issue). The new JRubyArt will likely be the future for ruby-processing (for me). I'm seriously thinking about parking jashkenas/ruby-processing with processing-2.2.1 and jruby-complete-1.7.XX, but with existing compatibility with an external jruby-9.0.0.0 (introduced with 2.6.12). So at the moment I'm concentrating on processing-3.0 compatibility so I can't really cope with anything else. Feel free to fork JRubyArt and experiment with it yourself, but do it fairly soon as I am planning to clobber it it the not too distant future.

[poqudrof]

I was referring to the latest release :  2.6.12 . For now I do not plan to support Processing 3 while it is in alpha or beta in my applications. I will have a look at the JRubyArt when possible, it might be better than my current solution.

I worked on a fork of ControlP5, to integrate it in my Augmented reality applications and extend it to have multi-touch and support for Ruby-processing and possibly for Python Processing users. I will post somewhere around here when I have something acceptable.

[monkstone]

It would be very nice to have controlP5 for ruby-processing. For toxicilibs I have created a gem distribution and with jbox2d, rather than use Shiffmans Box2D for processing, I've created my own wrapper around jbox2d. The processing-3.0 will I am fairly sure move to beta very soon, and it is looking quite good, but it will be a disruptive change especially for users of PVector (if they include chaining), but ruby-processings Vec2D and Vec3D can already do chained operations and have a much more ruby like interface. PS: The only real purpose of the 2.6.12 release was to make it jruby-9.0.0.0 compatible, so if you don't need it, then use an earlier release, if that's what broke your setup.

[monkstone]

This a bit esoteric for anyone still running ruby-processing