For the next version of ruby-processing examples will not be included in the gem.

You will still be able to install using "rp5 setup unpack_samples" which will just download and install the sketches for you:-

Example-Sketches

Many of the vanilla processing example sketches have been translated to ruby-processing, and they are mainly written as 'bare' sketches (ie not class wrapped) in keeping with the original processing. At runtime these sketches the get wrapped into a Sketch class. Should you prefer you can still write class wrapped sketches, these will work equally well with ruby processing. Certain sketches must be run with JRuby-Complete (load_image and shader sketches), this is some java permissions thing with jruby. You should also checkout the Nature of Code Examples in ruby and for the beginner Learning Processing with Ruby.

Partial Catalogue (for the lazy)

1. Basic

   1. structure
   2. objects
   3. arrays
   4. input
   5. shape
   6. image
   7. control

2. Topics

   1. shaders
   2. lsystems

3. Libraries

   1. fastmath
   2. vecmath
   3. control-panel

Understanding the ruby-processing examples (since processing-2.0 and ruby 1.9)

I've been pushing out a lot of ruby-processing samples, and suddenly realized that I should flesh out the reasons why some of the code looks the way it does:

1. First of all, and this is very important for anyone looking at the older ruby-processing examples, all ruby-processing sketches should now be "bare sketches" (ie similar to what you might do in the processing ide the user does not explicitly wrap the code in class). However as with regular processing the code does get wrapped in a class at run time, with regular processing the class name is taken from the folder name, with ruby-processing it becomes the sketch class. I see this a good move, because it can be done, but also you might find that an explicitly wrapped sketch may not run, you have been warned.
2. As with regular processing the default renderer is JAVA2D, but a change for ruby-processing since processing-2.0 the renderer SHOULD be defined as the third argument in "size", and preferably this is the first line in the "setup" block as with regular processing.
3. When loading libraries, it is not usually sufficient to "load_library" or load_libraries" this should be followed by either import or include. If you want to include a java package I have preferred "include_package" over "java_import" (this is kosher since the Processing::App is a module). It is sometimes sensible to create your own module to facilitate the import of packages (outside of sketch file) the module will then act as "namespace" you can use to your advantage.
   

   module JavaUtil
     include_package "java.util"
   end
   
   JavaUtil::Date.new
   

4. Since processing-2.0, I have found it necessary to explicitly "setVisible" the control_panel, which otherwise seems to work as expected (can't say I'm a big fan of the processing.event introduced in processing-2.0, and I had anticipated conflicts, but I've seen none so far), and certainly the use of reflection in "registerMethod" is just plain EVIL.