[ADD EXAMPLE] Hilbert Curve

[monkstone]

There is a JRubyArt (an implementation of processing in ruby) version based on a Lindenmayer System it should be possible to convert to run in vanilla processing. The include Processing::Proxy is only relevant to JRubyArt (it allows access similar to Processing inner classes in ruby).

[villares]

Hi @monkstone, @jeremydouglass, how do you like this?

# L-System - Hilbert Curve rules

iterations = 7
stroke_len = 600
angle_deg = 90
axiom = "L"
sentence = axiom
rules = {
    'L': '+RF-LFL-FR+',
    'R': '-LF+RFR+FL-',
}

def setup():
    size(700, 700)
    global xo, yo
    xo, yo = 50, height - 50
    strokeWeight(1)
    noFill()
    generate(iterations)

def draw():
    background(0)
    translate(xo, yo)
    plot(radians(angle_deg))

def generate(n):
    global stroke_len, sentence
    for _ in range(n):
        stroke_len *= 0.5
        next_sentence = ""
        for c in sentence:
            next_sentence += rules.get(c, c)
        sentence = next_sentence

def plot(angle):
    for c in sentence:
        if c == "F":
            stroke(255)
            line(0, 0, 0, -stroke_len)
            translate(0, -stroke_len)
            # ellipse(0, 0, 10, 10)
        elif c == "+":
            rotate(angle)
        elif c == "-":
            rotate(-angle)
        elif c == "[":
            pushMatrix()
        elif c == "]":
            popMatrix()

def keyPressed():
    global angle_deg, xo, yo, stroke_len
    if key == '-':
        angle_deg -= 5
        print(angle_deg)
    if str(key) in "=+":
        angle_deg += 5
        print(angle_deg)
    if key == 's':
        saveFrame("####.png")
    if key == 'a':
        stroke_len *= 2
    if key == 'z':
        stroke_len /= 2
    if keyCode == LEFT:
        xo -= 50
    if keyCode == RIGHT:
        xo += 50
    if keyCode == UP:
        yo -= 50
    if keyCode == DOWN:
        yo += 50

[monkstone]

@jeremydouglass @villares See some examples I just remembered I wrote a few years ago in processing.py I'm quite proud of 3D Hilbert. Also see my long forgotten blog and LSystems Library.

[jeremydouglass]

These look great. Monkstone, how would you feel about us collecting some JRubyArt examples in a separate branch of this repo? (/Java /Python /Ruby)

They won't run in PDE, but the release can be downloaded manually -- and having the collection together might be interesting to rubyists from a "rosetta" standpoint.

[monkstone]

I'm quite easy with that, I expect I may be fairly unique in being across processing in ruby/python/java. Years ago I wrote plugins for JEdit, that would run all three. Some of my commando files here http://community.jedit.org/?q=filestore/browse/20

[jeremydouglass]

Cool. I know that I've said it before, but I wish that we could get a Ruby mode application into the Processing Google Summer of Code project. I feel like deploying JRubyArt through the cross-platform app infrastructure and contribution manager would really lower the barrier to adoption.

That said, R mode has not lit the world on fire, so "if you build it" (and make easily available through PDE) alone isn't enough....

[jeremydouglass]

@monkstone -- Would an example file ideally be called:

examples/Ruby/hilbert_curve/hilbert_curve.rb

I seem to recall that Ruby has an underscores and lowercase convention. Not sure if the enclosing folder should match the entrypoint .rb as in Java mode.

[monkstone]

There is no requirement with ruby-processing for the folder to match filename, in the Ruby world it is normal to prefer snakecase over camel case for all but class and module names. The automatic sketch title feature does not work in ruby as the compiled class name (which is why I created sketch_title method to add a title to frame). With ruby I usually put many theme related sketches in a single folder and all these sketches then have access to the enclosed library and data folders.

[jeremydouglass]

Great, thank you. So we could put all the .rb sketch files in one big Ruby folder if we wanted to.

Still, given how many hundreds of tasks there are (potentially), I think we'll use one folder per task -- in case some of them need their own resources, and to keep it roughly parallel with Java and Python modes.