Ruby for jMax


(Mathieu Bouchard) #1

Just a note that I wrote a jMax object using the Ruby language.

It works.

This functionality will be included in GridFlow 0.6.0.

···

Mathieu Bouchard http://hostname.2y.net/~matju


(david casal) #2

Can you say more about this? Does it mean you embedded an Ruby interpreter
within JMax, so one can write objects for jMax in a similar way to
Python/Scheme for PD?

dc

david casal --0+

···

On Tue, 11 Jun 2002, Mathieu Bouchard wrote:

Just a note that I wrote a jMax object using the Ruby language.

It works.

This functionality will be included in GridFlow 0.6.0.

    ---
d.casal@uea.ac.uk --9+
    ---
www.ariada.uea.ac.uk/~dcasal --)+


(Vincent Touquet) #3

Mathieu Bouchard wrote:

Just a note that I wrote a jMax object using the Ruby language.
It works.
This functionality will be included in GridFlow 0.6.0.

Just stumbled on this post :slight_smile:

Its great ! :slight_smile:

Hope your url stays fixed for some time,
so I can check back for updates…

I love the description of Gridflow.
I’m not able to test it now,
but I sure will.

I’m looking into audio-video-graphics
synergy (hope this doesn’t sound too arty farty)

thanks and respect
Vincent


(Mathieu Bouchard) #4

this is my emulation of the "for" object:

# this is the demo and test for Ruby->jMax bridge
# FObject is a flow-object as found in jMax
# _0_bang means bang message on inlet 0
# FObject#send_thru sends a message through an outlet
class RubyFor < GridFlow::FObject
  attr_accessor :start, :stop, :step
  def initialize(start,stop,step)
    raise ArgumentError, "@start not integer" unless Integer===start
    raise ArgumentError, "@stop not integer" unless Integer===stop
    raise ArgumentError, "@step not integer" unless Integer===step
    @start,@stop,@step = start,stop,step
  end
  def _0_bang
    x = start
    if step > 0
      (send_thru 0, x; x += step) while x < stop
    elsif step < 0
      (send_thru 0, x; x += step) while x > stop
    end
  end
  def _0_int(x)
    self.start = x
    _0_bang
  end
  alias :_1_int :stop=
  alias :_2_int :step=

  # FObject.install(name, inlets, outlets)
  # no support for metaclasses yet
  install "rubyfor", 3, 1
end

···

On Wed, 12 Jun 2002, david casal wrote:

On Tue, 11 Jun 2002, Mathieu Bouchard wrote:
> Just a note that I wrote a jMax object using the Ruby language.
> It works.
> This functionality will be included in GridFlow 0.6.0.
Can you say more about this? Does it mean you embedded an Ruby interpreter
within JMax, so one can write objects for jMax in a similar way to
Python/Scheme for PD?

________________________________________________________________
Mathieu Bouchard http://hostname.2y.net/~matju


(ccos) #5

hey there,

I’m looking into audio-video-graphics
synergy (hope this doesn’t sound too arty farty)

not at all.
i’m looking for a solution to the same problem.
i currently use supercollider for audio
which is a smalltalk, just made open source:
www.audiosynth.com
…but, i’m looking for a way of programmatically spawning and
manipulating 3/2d ‘objects’ in the visual domain in real time,
preferably using opengl.

i’ve really just started with ruby, but it is so similar to supercollider
that i feel right at home with it. i’m just learning unix though
so installing things is a bit of a problem because
i’m on os x and nothing seems to fit. i couldn’t get the opengl
stuff from ruby.org to install for instance, it’s very frustrating.
anyway, my dream is to talk to ruby and the sc-server via open sound
control with the
supercollider interpreter to have the server do audio, and ruby do
opengl.

i posted a little while back about osx/ruby/opengl.
does anybody know if it’ll work and which libraries to use?
has anyone done it in rubycocoa, is that possible?
has anybody tried to build an osc server in ruby?
does jmax (or a jmax extension) do opengl, out of curiosity?
is there a better way of doing real time oo scripting of
opengl on os x than with ruby, am i barking up the wrong tree?

best,
c


(Mathieu Bouchard) #6

oh, and for specifics of installation: you need libruby.so, and it will be
loaded by libgridflow.so which is a jMax plugin. My code translates jMax
atoms to Ruby objects and back, and ties GridFlow::FObject to a
fts_object_t. It scans for inlet-methods by name and exports them to jMax.

however, i could not make any kind of Ruby threading to work with jMax,
which is why I couldn't get Ruby/Tk to not crash. note that jMax has its
own event-loop, and afaik, Tk's event-loop can not be subordinated to
jMax's, so I'd have to use threads.

···

On Wed, 12 Jun 2002, Mathieu Bouchard wrote:

On Wed, 12 Jun 2002, david casal wrote:

> On Tue, 11 Jun 2002, Mathieu Bouchard wrote:
> > Just a note that I wrote a jMax object using the Ruby language.
> > It works.
> > This functionality will be included in GridFlow 0.6.0.
> Can you say more about this? Does it mean you embedded an Ruby interpreter
> within JMax, so one can write objects for jMax in a similar way to
> Python/Scheme for PD?

this is my emulation of the "for" object:

________________________________________________________________
Mathieu Bouchard http://hostname.2y.net/~matju


(François Déchelle) #7

Mathieu Bouchard wrote:

···

On Wed, 12 Jun 2002, david casal wrote:

On Tue, 11 Jun 2002, Mathieu Bouchard wrote:

Just a note that I wrote a jMax object using the Ruby language.
It works.
This functionality will be included in GridFlow 0.6.0.

Can you say more about this? Does it mean you embedded an Ruby interpreter
within JMax, so one can write objects for jMax in a similar way to
Python/Scheme for PD?

this is my emulation of the "for" object:

# this is the demo and test for Ruby->jMax bridge
# FObject is a flow-object as found in jMax
# _0_bang means bang message on inlet 0
# FObject#send_thru sends a message through an outlet
class RubyFor < GridFlow::FObject
  attr_accessor :start, :stop, :step
  def initialize(start,stop,step)
    raise ArgumentError, "@start not integer" unless Integer===start
    raise ArgumentError, "@stop not integer" unless Integer===stop
    raise ArgumentError, "@step not integer" unless Integer===step
    @start,@stop,@step = start,stop,step
  end
  def _0_bang
    x = start
    if step > 0
      (send_thru 0, x; x += step) while x < stop
    elsif step < 0
      (send_thru 0, x; x += step) while x > stop
    end
  end
  def _0_int(x)
    self.start = x
    _0_bang
  end
  alias :_1_int :stop=
  alias :_2_int :step=

  # FObject.install(name, inlets, outlets)
  # no support for metaclasses yet
  install "rubyfor", 3, 1
end

________________________________________________________________
Mathieu Bouchard http://hostname.2y.net/~matju

This looks good. How big is the Ruby interpreter ? Does it have its
own garbage collector ?

Another point: it looks like metaclass do not fit into standard object
oriented languages. May be an indication that it is not the right
concept.

François


(Kyle Rawlins) #8

I’m curious what you mean by this; could you elaborate? I guess I’m having
trouble thinking of such a language (maybe c++, but I don’t know it very well,
and it’s really only standard in terms of usage). I don’t really know all
that many languages but I know people here at umass who are using metaclasses
to transparently implement a distributed object system in java - that’s not to
say that it’s easy, but it’s doable. Smalltalk has metaclasses (and I think
was the first language to have them), and CLOS does too. These represent just
a few ‘standard’ OO languages/systems, but fairly important ones. I don’t know
about Eiffel.

Perhaps I misunderstood? Possibly it just worries me because I rather like
metaclasses and think that they’re a good abstraction for certain aspects of OO
languages.

-kyle

···

On Thu, Jun 13, 2002 at 11:09:10PM +0900, François Déchelle wrote:

Another point: it looks like metaclass do not fit into standard object
oriented languages. May be an indication that it is not the right
concept.


http://mas.cs.umass.edu/~rawlins

God is god.


(Mathieu Bouchard) #9

Mathieu Bouchard wrote:

This looks good. How big is the Ruby interpreter ?

the raw meat is:

size /opt/lib/libruby.so.1.6.7
   text data bss dec hex filename
615869 7576 56788 680233 a6129 /opt/lib/libruby.so.1.6.7

with all the fat (debugging info) it's doubled:

ls -l /opt/lib/libruby.so.1.6.7
           1471217 jun 15 13:28 /opt/lib/libruby.so.1.6.7*

the interpreter has many loadable .so and .rb files; there are 8.6 megs of
it right now on my system, but i suspect half of that is debugging
symbols, and anyway i installed many plugins myself.

Does it have its own garbage collector ?

Ruby has had mark-and-sweep garbage collector for many years now; in
comparison, Perl and Python still only use reference-counts. In a
real-time system there might be an advantage to using reference-counts,
but that advantage is meagre as long as the object-count is low, as it
would be for something like FTS/GridFlow. (if you have to many objects at
once, upgrading to Ruby 1.7 makes things smoother, but Ruby 1.7 is still
marked experimental)

Another point: it looks like metaclass do not fit into standard object
oriented languages. May be an indication that it is not the right
concept.

jMax/FTS's idea of metaclass is different from SmallTalk's and Ruby's idea
of metaclass.

In SmallTalk, the split between classes and metaclasses is done so that
the functionality of classes is reused at a second level. "class methods"
and such are defined in metaclasses, just like "object methods" are
defined in classes. So there are two parallel hierarchies, one rooted in
the Object class, and the other rooted in the Class class.

In Ruby it is similar, though there is the added concept of singleton
classes for adding methods to specific objects, and that's what
metaclasses are implemented with.

The biggest mismatches I see between jMax and others are: peculiarness of
metaclasses, lack of inheritance, lack of method_missing (the wildcard
method), and of course, a dataflow model of operation.

Note that emulating jMax's metaclasses is not a problem in Ruby. It can be
done mostly within a page of code, by creating anonymous subclasses at
runtime and storing them in a Hashtable. I've done very similar things in
the past in other Ruby projects. The main difficulty will be writing the C
part for connecting with jMax, but that's because when programming for
jMax I've always limited myself to ordinary classes.

···

On Thu, 13 Jun 2002, François Déchelle wrote:

________________________________________________________________
Mathieu Bouchard http://hostname.2y.net/~matju


(Ned Konz) #10

Another point: it looks like metaclass do not fit into standard
object oriented languages. May be an indication that it is not
the right concept.

I’m not sure what you mean by “standard object oriented languages”. I
didn’t know there was such a thing. There are “popular” OO languages
(by usage, by interest in the academic community, by marketing
dollars spent, by magazine space, etc.).

[snip]

Perhaps I misunderstood? Possibly it just worries me because I
rather like metaclasses and think that they’re a good abstraction
for certain aspects of OO languages.

There has been ongoing discussion about metaclasses over on
comp.lang.smalltalk. And on the Squeak list, Alan Kay has expressed
doubts about whether metaclasses were a good idea, given the
difficulty of supporting them in the environment.

At least in Smalltalk, metaclasses do a few things:

  • provide a namespace for otherwise global “loose” methods (especially
    constructors)
  • provide a namespace for otherwise global variables
  • hold class metadata (shape of instance variables, organization for
    browsers…)
  • hold compiled methods
  • hold selectors and their mapping to compiled methods
  • hold a reference to the superclass
    (am I missing anything?)

All of these could be (and have been) done by separate reflection and
namespace mechanisms without requiring metaclasses.

For instance, one could use prototypes for constructor behavior. And
separate “mirror” objects for reflection. These two are what the Self
language did; Self did away with classes altogether.

After all, classes are not essential for object-oriented programming.
Though they’ve been a comfortable concept in many languages, all you
really need for OO is objects. Inheritance, classes as objects, etc.
aren’t required.

···

On Thursday 13 June 2002 08:50 am, Kyle Rawlins wrote:

On Thu, Jun 13, 2002 at 11:09:10PM +0900, François Déchelle wrote:


Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE


(James) #11

I’m not sure what you mean by “standard object oriented languages”. I
didn’t know there was such a thing.

But Sun’s been telling us for years that Java is a standard.

:slight_smile:

James


(Kyle Rawlins) #12

After all, classes are not essential for object-oriented programming.

Well, I certainly agree with that. However, it seems to me that if you’re
using a language which does have classes, especially one where everything is an
object, the most consistent way to abstract what a class is is have some object
that represents a class. Consistency would then further cause you to have some
class that describes that object. There are other ways to do it in languages
which have classes, but to me it’s a matter of consistency. But perhaps I
should stop here since I’m not really experienced enough to judge one way or
the other about metaclasses in the long run, I just think they’re neat.

Though they’ve been a comfortable concept in many languages, all you
really need for OO is objects. Inheritance, classes as objects, etc.
aren’t required.

I actually think quite a few people would disagree with this statement. The
thing that has differentiated what has been called object oriented programming
from simple data abstraction/ADTs (which has been used in non-OO languages for
ages) is having some kind of relationship between the objects. If you simply
take the name ‘object oriented programming’ and analyse it, yes, it seems that
all you need are objects. But the things that have been called OO at least
that I know of, have all gone beyond data abstraction to have relationships.
This doesn’t necessarily have to be expressed as classes and inheritance, but
the common thread does seem to be some approximation of the subtype relation.
Also, to me, the presence of these relationships is one of the things which
makes the languages interesting.

-kyle

···

On Fri, Jun 14, 2002 at 01:19:47AM +0900, Ned Konz wrote:


http://mas.cs.umass.edu/~rawlins

Beware of free morphemes!