We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexDiscussionGeneral Discussion,  Status › Ruby-Processing
Pages: 1 2 
Ruby-Processing (Read 7735 times)
Ruby-Processing
Mar 20th, 2008, 5:18pm
 
Hey Processing crew —

Ruby-Processing 0.6 is out, which brings things to some reasonable stage of maturity. If you have any interest in beautiful code, metaprogramming, live coding, or domain-specific languages, do yourself a favor and check it out.

Proof of concept:
http://fiercefrontiers.com/applets/jwishy/

Get it here:
http://the-shoebox.org/apps/44/

fry, REAS, if there's any interest in adding it as a "contributed library", let's talk.

Re: Ruby-Processing
Reply #1 - Mar 21st, 2008, 6:48am
 
This looks beautiful. To be clear, what would it mean in relation to a contributed library?

Casey
Re: Ruby-Processing
Reply #2 - Mar 21st, 2008, 2:48pm
 
You know, Casey, I'm not sure, because it's more of a wrapper that goes around Processing than a library that plugs into it. But it think that it could be valuable to beginners who'd like to get into Processing — not having to worry about types, using more natural iteration, having flexible classes for simpler OOP code — and also for advanced folks, who can make domain-specific languages to sketch with.

As an example of that: here's a little sketch that uses a context-free drawing DSL.

http://fiercefrontiers.com/applets/contextual_tree/

It's not quite ready for prime time, and so sometimes borks out on you, but it uses a mini-language modeled after that program "Context Free."

So yeah, I don't know where it would fit in — but maybe you guys would want to make a "Language" section under the contributed libraries — I know that there have been experiments with Processing in Scala as well.
Re: Ruby-Processing
Reply #3 - Mar 21st, 2008, 10:07pm
 
I agree entirely that Java syntax is not always ideal for the type of work that Processing is used for. Back in 2001, it was a choice between Java and Python and we selected Java for the Web benefits. The world of 2008 is different.

I don't think I've seen the Scala-Processing test? Could you point me to that and a list of the other related projects that you know of? I agree it would be good to make a list on the site. I'm thinking the homepage -- to make a new list in the lower-left corner.
Re: Ruby-Processing
Reply #4 - Mar 21st, 2008, 10:40pm
 
Right. I remember reading a quote from one of you guys to that effect — and it was certainly a good choice from an "spreading through the web" point of view — I'd credit that with much of it's enduring popularity. But 2008 is 2008.

So the Scala experiment is at:
http://hipstersinc.com/blog/2008/1/23/scala_and_processing/
And you can get in touch with Mark at Hipsters Inc. about it. But I imagine that any of those new hybrid languages running at the JVM would be good targets for Processing expansions.
Re: Ruby-Processing
Reply #5 - Mar 31st, 2008, 1:09am
 
This is a great topic. In the last months I've been teaching at a Master on interaction, with quite a large focus on coding, where most students had no previous experience on that. And I totally agree that Java holds a extra difficulties for people getting started with code. Specially when teaching to students coming from arts, that pretty much stopped studying math since high school. Starting to use programming and getting to understand its logic can be a very slow process of assimilation for many of these students. And things like the difference between int and float, which shouldn't matter at all at this level of programming, are just a burden that are making that assimilation slower. It doesn't seem like much, but it can be quite hard for some people, and all these things add up. Types, declaration, syntax... Some people students even feel overwhelmed and intimidated, and abandon the ship.

In the case of Ruby-Processing, this:

Code:

int x = 0;

void setup (){
}

void draw () {
background(255);
x += 1;
if (x > width) {
x = 0;
}
line(x,0,x,width);
}


could become this:

Code:


def setup
@x = 0
end

def draw
background 255
@x += 1
if @x > width
@x = 0
end
line @x, 0, @x, width
end


(In Ruby parentheses are optional, so they could be added for clarity, or not. And there's a syntactic sugar version of IF, but this one is closer to talking.)

Goodbye types, goodbye void (try to explain void to a newbie), bye declarations outside of functions, and bye bye parentheses, brackets, semicolons.. This lifts a huge weight out of their shoulder. It allows them to focus only on the stuff that matter the most: variables and methods.

But at this point, I still prefer holding these other burdens instead of asking them to use an editor, getting acquainted with a command line, and everything that comes with that. The Processing IDE is damn practical. Just install it, in any platform, and it comes packed with all the features needed, plus it has a nice big play/stop button.

What would be a big step forward is some kind of integration with the IDE itself.


By the way, as far as I know, Ruby is actually a damn nice possibility for this kind of bridge. It's a flexible language, with its meta programming and other tricks. And JRuby is by itself an impressive implementation of Ruby in Java. I saw a few benchmarks where it was way faster than Ruby 1.8. (1.9 is currently in beta). Plus its community is growing very fast. Gartner has just speculated that by 2013 there would be 4 million Ruby on Rails developers. On the other hand, so is Python, which has a great art driven community, quite the opposite of Ruby. But Ruby's syntax is cleaner and a few nice tricks python doesn't have (check this and see what I mean http://tryruby.hobix.com ). Anyway this is the ongoing python/ruby debate. And I'm biased, I use Ruby for web development, and so far it's mostly used for commercial applications, I'd love to see it growing in the arts fields.
Re: Ruby-Processing
Reply #6 - Mar 31st, 2008, 7:59pm
 
Steph —

You're absolutely right that integration with an IDE would be a great next step . . . The question is just, which IDE, and how? The Processing app ain't gonna fly because it's totally Java-focused. Many Ruby programmers use Textmate, but that's expensive and Mac-only. I really don't feel comfortable thinking about a plug-in for Eclipse, because the sheer weight and cluttered madness of it runs counter to everything that Processing (presumably) could be said to stand for. Plus, the entire Ruby community (for better or for worse) is oriented towards text editors and the command line in a way that the Java community, for instance, is not. So, I don't see a compelling way to couple it with an IDE at this moment.

Really, if you're looking for a learning environment that couples graphics coding and Ruby, you should take a look at _why's Hackety Hack: http://hacketyhack.net/ (Although you're probably already familiar with that effort.) Ruby-Processing actually grew out of some frustrations with Shoes (the soul of Hackety Hack), and has adapted some shoes-isms into its repertoire.

Casey said earlier that we might be able to get some props on the Processing homepage, so hopefully there'll be interest in mixing up some integration. "Run in Ruby-Processing" bundles for Textmate at a minimum!
Re: Ruby-Processing
Reply #7 - Mar 31st, 2008, 9:51pm
 
Cheers for telling me about this in my thread, I've got a question for you;

Would it be possible to make these scripts into files that you can import into an existing processing sketch?

I'm not sure how to phrase what I mean, but I guess I'm asking, could you use Ruby-Processing to make plugins for a processing application?

Maybe just having the code to draw something to the screen, but no setup/draw parts?
Re: Ruby-Processing
Reply #8 - Mar 31st, 2008, 10:06pm
 
Really, Manic, all of Ruby-Processing is a paper-thin convenience between JRuby (which is Ruby implemented in Java), and Processing. If you wanted to use Ruby to write plugins for your sketch, you would have to load in the JRuby jar, and then cause it to execute your plugin. This is close to how Ruby-Processing applets work. So theoretically, yeah sure.

But I think it would be easier to answer your question if you tell us a little more about what you have in mind...
Re: Ruby-Processing
Reply #9 - Mar 31st, 2008, 10:19pm
 
Jashkenas,

thanks for pointing at hackety hack. Haven't tried it yet, but looks like a nice tool for self-teaching. But Processing will still be our environment of choice to teach, because of its capabilities. Shoes is not an option right now. Java is not the best to start understanding code concepts, but at this point with Processing it's the best if we think in the long term for these students.

And you're absolutely right, for teaching, nothing beats the feature-packed cross-platform PDE. But it shouldn't be unfeasible to make a version of it for JRuby, like Arduino did for their language. It may even be easier, since "JRuby is tightly integrated with Java to allow the embedding of the interpreter into any Java application with full two-way access between the Java and the Ruby code." (wikipedia) Correct me if I'm wrong.

Re: Ruby-Processing
Reply #10 - Apr 1st, 2008, 5:29am
 
Steph —

Yep, it would probably be possible to fork the PDE, like Arduino, and bundle in the jruby executable, or the jar'd version. You'd have to hack the way that the app treats its pages, to run them as Ruby, including syntax highlighting and all that, and you'd have to either disable or rewrite many of the features, like code auto-formatting and exporting to applications. Doable, certainly. Easy, not so much. I'm not the right person to spearhead that effort, because I don't do much Java. But I'd certainly love to help if anyone, reading this, feels like taking it on.
Re: Ruby-Processing
Reply #11 - Apr 14th, 2008, 11:13pm
 
Progress continues. Version 0.7 is out, with OpenGL applet exporting capabilities, a pure-Ruby library example, and more.

The source is also now available on GitHub, and can be branched and worked with there.

http://github.com/jashkenas/ruby-processing/tree/master

But perhaps more importantly, a fairly thorough wiki is up and running, which should have everything you need to get started with Ruby-Processing.

http://github.com/jashkenas/ruby-processing/wikis

REAS — any news on being added to Processing.org as a "Sister Language" under "Related Initiatives", or something along those lines ... ?
Re: Ruby-Processing
Reply #12 - Apr 15th, 2008, 3:05pm
 
*very* cool!
Re: Ruby-Processing
Reply #13 - Apr 19th, 2008, 11:18pm
 
And roll out the red carpet for Ruby-Processing 0.8

It can now export your sketches as Mac Applications, just a simple "script/application my_sketch.rb", and off you go. If you happen to have a .icns icon file in your data folder, that will become the icon for the app.

The Boids library is now about 40% faster.

Sketches now have a library_loaded? method, so that you can check if a library has been started successfully, and conditionally enable things. (Good for OpenGL.)

The wiki (http://github.com/jashkenas/ruby-processing/wikis) now has a gallery, to which you should feel free to post links to your sketches, if you've got any, because we're all in this together, y'know?
Re: Ruby-Processing
Reply #14 - Apr 20th, 2008, 11:19am
 
The applets don't work for me.. Java version 1.6.0_05-b13..
in some cases when i close the window after waiting for it to load, they cause firefox to crash.
Pages: 1 2