Asp Forum - Re: [ANN] ruby-opengl

Bill Kelly

7/7/2006 4:36:00 PM

From: "John Gabriele" <jmg3000@gmail.com>
>
> I've tinkered a bit with Yoshi's original ruby-opengl. My changes are
> available here:
> http://www.simisen.com/cgi-bin/jmg/ruby...
>
> The point of the changes started out mostly as an interest in getting
> some tutorial content together, but soon spiraled out of control
> resulting in me putting that little site up along with the modified
> ruby-opengl files (plus some docs).

Hi,

I think it's great that ruby-opengl has an active maintainer
now, and your website looks very nice.

If you're interested in linking to additional related libraries,
Ilmari Heikkinen and I have FTGL bindings for Ruby here:
http://rubyforge.org/projects/...
(True-type fonts in OpenGL).

One thing, from your home page:

I decided I really didn't like the way the GL calls looked
(they used to always be prefixed with the module name
(unless you did an include) and they started with a capital
letter -- which is against the usual Ruby convention).
So that's been changed ...

You don't mention whether you've left the original API
intact for backward compatibility. It sounds like you're
saying you went ahead and broke compatibility with all the
ruby OpenGL code that we've all written in the past half
decade!

I can't begin to describe how ill-advised I think it would
be to break compatibility with 100% of the existing codebase
just for relatively minor aesthetic reasons.

Regards,

Bill

14 Answers

jmg3000

7/7/2006 5:08:00 PM

On 7/7/06, Bill Kelly <billk@cts.com> wrote:
> From: "John Gabriele" <jmg3000@gmail.com>
> >
> > I've tinkered a bit with Yoshi's original ruby-opengl. My changes are
> > available here:
> > http://www.simisen.com/cgi-bin/jmg/ruby...
> >
> > The point of the changes started out mostly as an interest in getting
> > some tutorial content together, but soon spiraled out of control
> > resulting in me putting that little site up along with the modified
> > ruby-opengl files (plus some docs).
>
> Hi,
>
> I think it's great that ruby-opengl has an active maintainer
> now,

Hm.

> and your website looks very nice.

Thanks.

> If you're interested in linking to additional related libraries,
> Ilmari Heikkinen and I have FTGL bindings for Ruby here:
> http://rubyforge.org/projects/...
> (True-type fonts in OpenGL).

Will take a look. Thanks.

> One thing, from your home page:
>
> I decided I really didn't like the way the GL calls looked
> (they used to always be prefixed with the module name
> (unless you did an include) and they started with a capital
> letter -- which is against the usual Ruby convention).
> So that's been changed ...
>
> You don't mention whether you've left the original API
> intact for backward compatibility.

It's not intact in my version.

> It sounds like you're
> saying you went ahead and broke compatibility with all the
> ruby OpenGL code that we've all written in the past half
> decade!

Yes. Perhaps I need to rename it then.

I'm not trying to be the new maintainer of ruby-opengl per se. I just
wanted to use more normal lookin gl calls in my little hobby-type gl
apps, and so modified ruby-opengl to make it so.

> I can't begin to describe how ill-advised I think it would
> be to break compatibility with 100% of the existing codebase
> just for relatively minor aesthetic reasons.

Thanks for the note Bill. Looks like I made an error, and should
probably rename the project to something else.

(new "ruby-opengl" page temporarily taken down)

---John

anne001

7/7/2006 5:43:00 PM

It would be great to have people to keep opengl going, people who
understand install issues, and could bring some vitality to examples,
discussions etc...

Just with install issues, having an opengl maintainer willing to figure
out how to install on all systems would be great. But then if you could
do that, you could help with yoshi's package as well as with your
modification.

I wonder if there is a softer way of keeping yoshi's code as the
mainstay, but have your version run as well. As Bill is suggesting, to
add to the code rather than alter it in an uncompatible way.
Down the road, people could choose.

Bill Kelly

7/7/2006 5:47:00 PM

From: "John Gabriele" <jmg3000@gmail.com>
>
> I'm not trying to be the new maintainer of ruby-opengl per se.

Rats. Because I really liked the web site. :)

> I just
> wanted to use more normal lookin gl calls in my little hobby-type gl
> apps, and so modified ruby-opengl to make it so.

Incidentally, I'd wager the reason the C-style GL calls all
use function name prefixes, is because that's standard practice
in 'C', since there's no namespace or module-like mechanism.

I doubt whether we'd prefix all our functions like that in
'C' if we had an alternative.

That's why Yoshi's placing the GL calls into modules never
bothered me, for the ruby bindings. It seemed a reasonable
fit for a language that _does_ have namespaces. (Why preserve
a 'C' language convention that exists only to work around
that language's lack of namespaces?)

In any case - welcome to Ruby!

Regards,

Bill

jmg3000

7/7/2006 6:25:00 PM

On 7/7/06, Bill Kelly <billk@cts.com> wrote:
> From: "John Gabriele" <jmg3000@gmail.com>
> >
> > I'm not trying to be the new maintainer of ruby-opengl per se.
>
> Rats. Because I really liked the web site. :)

Hey, thanks. :) I don't think it's gone for good, I just don't want to
false advertise. Thanks for pointing out the problem.

> > I just
> > wanted to use more normal lookin gl calls in my little hobby-type gl
> > apps, and so modified ruby-opengl to make it so.
>
> Incidentally, I'd wager the reason the C-style GL calls all
> use function name prefixes, is because that's standard practice
> in 'C', since there's no namespace or module-like mechanism.
>
> I doubt whether we'd prefix all our functions like that in
> 'C' if we had an alternative.

Then what would you think of GL::foo_bar instead of glFooBar? I really
don't like ruby-opengl's current GL::FooBar, since that looks like a
constant to me in Ruby.

The trouble with *that* though (using GL::foo_bar), is, if you
`include` the GL, GLU, and GLUT modules, you might then have possible
name collision issues (if you take away the prefix, the GL function
names start looking pretty common).

> That's why Yoshi's placing the GL calls into modules never
> bothered me, for the ruby bindings. It seemed a reasonable
> fit for a language that _does_ have namespaces. (Why preserve
> a 'C' language convention that exists only to work around
> that language's lack of namespaces?)

Well, the reasons that make sense to me are:

1. Lots of OpenGL C code uses those names, so it would likely make
"porting" a lot easier (not that you'd often port working C code to
Ruby, but "porting" could mean just turning pseudocode into Ruby, for
example, or maybe C snippets you find on the 'Net). Probably much more
common would be to first write your GL code in Ruby, then, if
necessary for performance reasons, you might end up recoding it in C.
Using normal GL names would make this much simpler, I think.

2. Folks are already used to the glFooBar names, which are quite well
established.

3. It makes it easier for folks new to Ruby and/or GL to follow along
with the many tutorials on the 'Net (since they mostly all are for C
and use the customary gl names).

4. If I do preserve the namespaces, then I'm stuck with function names
in Ruby that start with a capital letter, which really don't look
right for Ruby.

>
> In any case - welcome to Ruby!

Thanks. :)

jmg3000

7/9/2006 3:00:00 AM

On 7/7/06, Bill Kelly <billk@cts.com> wrote:
> From: "John Gabriele" <jmg3000@gmail.com>
> >
> > I'm not trying to be the new maintainer of ruby-opengl per se.
>
> Rats. Because I really liked the web site. :)
>

Well then, I'll have to see what I can do:
http://www.simisen.com/cgi-bin/jmg/ruby...

I reverted my changes to the method names, so it's back to being
"ruby-opengl". Please take a 2nd look.

Also, if there's any Mac OS X Ruby OpenGL users out there, note that
there seems to be one last issue with getting this to work correctly
on OS X. I've incorporated some changes by James Adam that Ilmari
pointed out to me, but there's seems to be a last hurdle on OS X to
get them working. It may build and run with no changes but with a
*current* version of Ruby on OS X. Dunno. But there's issues with it
working with whatever older version of Ruby Apple provides.

---John

Bill Kelly

7/9/2006 5:22:00 AM

From: "John Gabriele" <jmg3000@gmail.com>
> On 7/7/06, Bill Kelly <billk@cts.com> wrote:
>> From: "John Gabriele" <jmg3000@gmail.com>
>> >
>> > I'm not trying to be the new maintainer of ruby-opengl per se.
>>
>> Rats. Because I really liked the web site. :)
>>
>
> Well then, I'll have to see what I can do:
> http://www.simisen.com/cgi-bin/jmg/ruby...
>
> I reverted my changes to the method names, so it's back to being
> "ruby-opengl". Please take a 2nd look.

Awesome! Much appreciated... It's a weight off my mind to
not have to worry about the API changing.

BTW, here's one possible way to define the prefixed methods
and constants, if you prefer to work with them that way.

You could require a file that does something like the
following:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
require 'opengl'

class Object
(GL.methods - Object.methods).each do |m|
define_method("gl#{m}") {|*args| GL.send(m, *args)}
end

(GLU.methods - Object.methods).each do |m|
define_method("glu#{m}") {|*args| GLU.send(m, *args)}
end
end

GL.constants.each do |c|
Object.const_set("GL_#{c}", GL.const_get(c))
end

GLU.constants.each do |c|
Object.const_set("GLU_#{c}", GLU.const_get(c))
end
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This should import the GL and GLU methods and constants
into the global namespace, using their traditional
prefixed nomenclature.

(Note: Only lightly tested... but I think it works.. :)

Regards,

Bill

anne001

7/9/2006 12:17:00 PM

One Tiger trick
One of the tricks I found on the internet, which seemed to help me was
to make a GL directory in the opengl folder in which you are trying to
build opengl.
find the GL libraries the install is looking for on your computer and
copy them in that directory.

jmg3000

7/9/2006 4:21:00 PM

On 7/9/06, anne001 <anne@wjh.harvard.edu> wrote:
> One Tiger trick
> One of the tricks I found on the internet, which seemed to help me was
> to make a GL directory in the opengl folder in which you are trying to
> build opengl.
> find the GL libraries the install is looking for on your computer and
> copy them in that directory.

OS X seems a bit complicated when it comes to libraries. I think
there's .dylib's, .so's, .bundle's, some are in "frameworks"... If
someone knows of an extension module that builds on OS X, please let
me know so I can take a look at its extconf.rb.

jmg3000

7/11/2006 5:56:00 AM

On 7/9/06, Bill Kelly <billk@cts.com> wrote:
> From: "John Gabriele" <jmg3000@gmail.com>
> > On 7/7/06, Bill Kelly <billk@cts.com> wrote:
> > > From: "John Gabriele" <jmg3000@gmail.com>
> > >[snip]
> >
> > I reverted my changes to the method names, so it's back to being
> > "ruby-opengl". Please take a 2nd look.
>
> Awesome! Much appreciated... It's a weight off my mind to
> not have to worry about the API changing.
>
>
> BTW, here's one possible way to define the prefixed methods
> and constants, if you prefer to work with them that way.
>
> You could require a file that does something like the
> following:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> require 'opengl'
>
> class Object
> (GL.methods - Object.methods).each do |m|
> define_method("gl#{m}") {|*args| GL.send(m, *args)}
> end
>
> (GLU.methods - Object.methods).each do |m|
> define_method("glu#{m}") {|*args| GLU.send(m, *args)}
> end
> end
>
> GL.constants.each do |c|
> Object.const_set("GL_#{c}", GL.const_get(c))
> end
>
> GLU.constants.each do |c|
> Object.const_set("GLU_#{c}", GLU.const_get(c))
> end
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> This should import the GL and GLU methods and constants
> into the global namespace, using their traditional
> prefixed nomenclature.
>
> (Note: Only lightly tested... but I think it works.. :)

It seems to work! Thanks! I just added it (Ilmari had also offered a
solution, which I appreciate very much, but I ended up using yours).
Have a look:

http://www.simisen.com/cgi-bin/jmg/ruby...

I've only tried it so far with samples/smooth.rb. It's late and I
*really* have to get to bed. :)

Thank you again. This is really shaping up nicely, IMO. The current
release is labeled 0.34pre because I'd like to hear from someone
running Mac OS X 10.4 if it builds and runs there out-of-the-box. I'd
also like to "port" more of the samples over (I figure I'll try to
provide at least a good number of samples written in *both* styles).
If anyone wants to help with that, be my guest. :)

Anne, you're on 10.4 ("Tiger" I suppose -- I don't know the Apple
cat-names for them), right? Does this latest release work for you
without any tweaking?

Thanks,
---John

jmg3000

7/11/2006 2:59:00 PM

On 7/11/06, Ilmari Heikkinen <ilmari.heikkinen@gmail.com> wrote:
> Hi,
>
> On 7/9/06, Bill Kelly <billk@cts.com> wrote:
> > require 'opengl'
> >
> > class Object
> > (GL.methods - Object.methods).each do |m|
> > define_method("gl#{m}") {|*args| GL.send(m, *args)}
> > end
> >
> > (GLU.methods - Object.methods).each do |m|
> > define_method("glu#{m}") {|*args| GLU.send(m, *args)}
> > end
> > end
>
> #define_method makes somewhat slower methods than alias_method.
> If an app is making lots of GL calls, it might cause some slowdown.
>
> I doubt it makes much change in real applications, but here's a silly
> micro-benchmark anyhow:
>
> $ ruby bench_alias_define.rb
> user system total real
> Foo 0.200000 0.030000 0.230000 ( 0.224021)
> FooAlias 0.190000 0.030000 0.220000 ( 0.222571)
> FooDelegate 0.810000 0.100000 0.910000 ( 0.909526)

I get about the same results on my system too. Nearly the same with
bmbm instead of bm too.

Thanks for your patience in helping me understand this Ilmari. The ri
docs on `extend` don't cover it the way you're using it, and I don't
understand the brief explanation in the PickAxe v2 (bottom of p.385).
It *looks* to me like putting `extend self` inside a module turns all
its instance methods into module methods. All of them -- ones you've
already defined, and the ones you're going to define -- *aliases
included*. I guess aliases are just like methods in this case (?).

Also, it seems that you can use strings in place of Symbols in the
args to `alias_method` and `public`. For some reason, that reminds me
of a symbolic reference (a la Perl).

Anyhow, I see I have more to learn here, and your stategy seems quite
a bit faster, so I'll probably go ahead and switch to it unless anyone
can point out a reason not to. What do you think Bill?

Thanks. Me thinks me need coffee now.

---John

comp.lang.ruby

Re: [ANN] ruby-opengl

Bill Kelly

jmg3000

anne001

Bill Kelly

jmg3000

jmg3000

Bill Kelly

anne001

jmg3000

jmg3000

jmg3000

x Login to ForumsZone