Setting and initializing instance variables on RubyClasses

Ruby IronRuby
#1

Hello,

How can I go about setting an instance variable on a RubyClass?

Here’s some code for context:

[RubyClass("Graphics")]
public class Graphics
{
    [RubyMethod("frame_rate", RubyMethodAttributes.PublicSingleton)]
    public static int GetFrameRate(RubyClass self)
    {
        // What goes here?
        // I could use self.TryGetClassVariable, but that's a

class
variable, correct?
// I want to achieve the same thing as “return @frame_rate”,
// not “return @@frame_rate”
}

    [RubyMethod("frame_rate=",

RubyMethodAttributes.PublicSingleton)]
public static void SetFrameRate(RubyClass self, int frameRate)
{
// Same thing here. I could do this:
// self.SetClassVariable(“frame_rate”, frameRate);
// but I want to achieve the same as this:
// @frame_rate = frame_rate
}
}

Another option just dawned on me; how about these two:
self.Context.SetInstanceVariable(self, “frame_rate”, frameRate);
self.Context.TryGetInstanceVariable(self, “frame_rate”, out frameRate);

Is that what I’m looking for?

One more question: is there a way to get the library initializer to
invoke
a callback so that I may perform some initialization for the RubyClass
itself? In the case above, I’d like to initialize the frame_rate when
the
RubyClass is created. As an example:

class Graphics
attr_accessor :frame_rate
frame_rate = 40
end
…
Graphics.frame_rate = something_else

I’d like that “frame_rate = 40” to happen when the assembly is loaded by
the
IronRuby runtime, if possible. I’m sure I could type that into my
auto-generated LibraryInitializer, but I’d rather do this declaratively,
perhaps using Attributes (like RubyMethod and RubyClass, etc).

Thanks,
-Charles

#2

What is your overall goal? Are you implementing a Ruby native library?

Tomas

#3

Wow, that was quick! Thanks Tomas.

If by Ruby native you mean mostly implemented in Ruby, then no.

I mentioned the Ruby snippets just for clarification. If I understand
correctly, SetClassVariable has the same semantics as declaring what
Ruby
would call a class variable, as in @@some_var. @@some_var would be
visible
to the whole class hierarchy, so FancyGraphics < Graphics; end would
share
the same @@some_var instance - which is not what I’d like.

Just curious how that might work using the IR APIs.

I assume the second question made sense. If not, let me know.

Cheers,

Charles

#4

By native Ruby library/extension I meant an implementation in C.

Although possible it’s not easy to simulate Ruby classes definition in
C# in a declarative way. I would suggest writing your implementation in
Ruby and calling .NET when you need so using IronRuby’s .NET interop.
If you absolutely need to implement your Ruby classes in C# (I would be
interested to understand why) you can use C# instance fields instead of
Ruby’s instance variables. They won’t be exposed as instance variables
to Ruby but they would be faster to work with. The fact they are not
exposed shouldn’t matter since instance variables should be a private
implementation detail of the class anyways.

It is more complicated with per-class data. You shouldn’t use static
fields since the value should be bound to Ruby runtime. To allocate data
bound to a runtime we provide GetOrCreateLibraryData method on
RubyContext. You’ll find a few places where it’s used in
IronRuby.Library. But before you dig into that consider writing your
code in Ruby and perhaps parts of it that are perf critical in pure C#
(w/o Ruby specific attributes). Our C# interop is strong so there
shouldn’t be generally a need for writing Ruby code in C#.

Tomas

#5

By native Ruby library/extension I meant an implementation in C.

D’oh! I realized that’s what you’d meant after I replied. Woops :).

If you absolutely need to implement your Ruby classes in C# (I would be

interested to understand why)

I probably don’t need to for the most part, but I do have some
motivation
for doing so. Performance is a must. Also, I’m doing a lot of
WritableBitmap manipulations, using (among other things) the
WritableBitmapEx on CodePlex, which feels a lot more natural in C#.
I’ve
already completed my little project using pure [Iron]Ruby and WinForms,
but
I figured I’d try out the IronRuby API & C# now that I’m porting it to
Silverlight. The interop with plain vanilla C# libs is great, but I
can’t
picture pulling off stuff like #_dump and ._load without going the API
route. Also, I think it’ll be good practice using the IronRuby API from
C#,
as I’d like to contribute back to libraries (ruby-debug-ide and ffi are
at
the top of my list).

To allocate data bound to a runtime we provide GetOrCreateLibraryData
method

on RubyContext.

I’ll have to check that out. For now, using the following pattern seems
to
work well enough:

// from the Graphics class
self.TryGetClassVariable(“renderables”, out renderables) // where
self is
the RubyClass

// from another class:
var graphicsClass = context.GetClass(typeof(Graphics));
graphicsClass.TryGetClassVariable(“renderables”, out renderables)

I also (think) I saw some code throughout IronRuby that used
CallSiteStorage
to interact with ruby objects. Would that yield better performance?

Cheers,

-Charles

On Wed, Jul 7, 2010 at 11:15 AM, Tomas M. <

#6

So you’re building a graphics library based on WritableBitmap?
You can certainly try to build Ruby classes in C# however it might be
much easier and more flexible to build basic data structures and
algorithms that need to be highly optimized in regular C# (no Ruby
specific stuff) and then wrap them into a Ruby class in Ruby code. Your
C#.dll might define a regular C# class Graphics:

namespace MyNamespace {
public class Graphics {
public void DoStuff() { }
}
}

And then you’ll write a Ruby wrapper:

require ‘graphics.dll’
class MyNamespace::Graphics
def ruby_facade
do something ruby-ish
do_stuff
end
end

Maybe if you gave concrete examples of the APIs you’re designing it
might help me understand why this wouldn’t be sufficient. The goal of
IronRuby is to allow you to use interop with regular C# code easily and
efficiently without a need to specialize it for Ruby. For calling back
to Ruby you can use C#'s dynamic features. If there is anything that
prevents you from doing so let us know. The additional advantage of
this approach is that your C# code can easily be used from other
languages as well.

Re: CallSiteStorage: any time you need to dynamically call a method
using Ruby semantics you should use it to do so. Three are plenty of use
cases throughout the library that you can see for examples (search for
Storage).

We don’t have any optimizations in place for class variable access. So
TryGetClassVariable always looks up a dictionary.

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Charles
Strahan
Sent: Sunday, July 25, 2010 3:02 AM
To: [email protected]
Subject: Re: [Ironruby-core] Setting and initializing instance variables
on RubyClasses

By native Ruby library/extension I meant an implementation in C.

D’oh! I realized that’s what you’d meant after I replied. Woops :).

If you absolutely need to implement your Ruby classes in C# (I would be
interested to understand why)

I probably don’t need to for the most part, but I do have some
motivation for doing so. Performance is a must. Also, I’m doing a lot
of WritableBitmap manipulations, using (among other things) the
WritableBitmapEx on CodePlex, which feels a lot more natural in C#.
I’ve already completed my little project using pure [Iron]Ruby and
WinForms, but I figured I’d try out the IronRuby API & C# now that I’m
porting it to Silverlight. The interop with plain vanilla C# libs is
great, but I can’t picture pulling off stuff like #_dump and ._load
without going the API route. Also, I think it’ll be good practice using
the IronRuby API from C#, as I’d like to contribute back to libraries
(ruby-debug-ide and ffi are at the top of my list).

To allocate data bound to a runtime we provide GetOrCreateLibraryData
method on RubyContext.

I’ll have to check that out. For now, using the following pattern seems
to work well enough:

// from the Graphics class
self.TryGetClassVariable(“renderables”, out renderables) // where
self is the RubyClass

// from another class:
var graphicsClass = context.GetClass(typeof(Graphics));
graphicsClass.TryGetClassVariable(“renderables”, out renderables)

I also (think) I saw some code throughout IronRuby that used
CallSiteStorage to interact with ruby objects. Would that yield better
performance?

Cheers,

-Charles

On Wed, Jul 7, 2010 at 11:15 AM, Tomas M.
<[email protected]mailto:[email protected]>
wrote:
By native Ruby library/extension I meant an implementation in C.

Although possible it’s not easy to simulate Ruby classes definition in
C# in a declarative way. I would suggest writing your implementation in
Ruby and calling .NET when you need so using IronRuby’s .NET interop.
If you absolutely need to implement your Ruby classes in C# (I would be
interested to understand why) you can use C# instance fields instead of
Ruby’s instance variables. They won’t be exposed as instance variables
to Ruby but they would be faster to work with. The fact they are not
exposed shouldn’t matter since instance variables should be a private
implementation detail of the class anyways.

It is more complicated with per-class data. You shouldn’t use static
fields since the value should be bound to Ruby runtime. To allocate data
bound to a runtime we provide GetOrCreateLibraryData method on
RubyContext. You’ll find a few places where it’s used in
IronRuby.Library. But before you dig into that consider writing your
code in Ruby and perhaps parts of it that are perf critical in pure C#
(w/o Ruby specific attributes). Our C# interop is strong so there
shouldn’t be generally a need for writing Ruby code in C#.

Tomas

#7

It’s actually an entire game engine port :).

http://www.rpgmakerweb.com/product.html?prod=xp

However, I don’t believe “port” is the correct word - perhaps
“reimplementation” would be more accurate. I don’t have access to RPG
Maker’s source code, so I’ve written the entire game engine from the
documented APIs, and by injecting little bits of Ruby into RPG Maker’s
Ruby
runtime to fill in any of the blanks. Finally, I ran several games
through
my “port” and fixed any little bugs I came across. It was no small
feat, I
assure you :).

So, as you can probably imagine, the rendering is highly coupled to the
rest
of the engine. As a result, I have no expectations to use it anywhere
else. Sure, I could abstract away stuff like drawing rectangles and
circles
to bitmaps, but anything more than that (sprites, windows, etc.)
wouldn’t
make any sense outside of this particular game engine. I’m sure I could
do
it all in Ruby (and have, when I wrote the WinForms impl) - but I don’t
find
IronRuby as easy to debug as C# (yet). So, if I’m going to write any C#
code, that C# code will need to directly interop with the rest of the
Ruby
modules and classes (in most cases). I’m sure the IronRuby APIs will
change
from version to version, but that’s not a big deal in my case. I’m fine
updating my code to match the latest release, or just tying my code to a
specific version. My current goal is to make my port run on Silverlight
and, consequently, Windows Phone 7 so that people can redistribute their
games on the market place or on the web; in both cases, targeting a
specific
version of IronRuby is easy. If, on the otherhand, I wanted to
distribute a
platform agnostic implementation, then I would run into problems as
there’s
no telling what version of IronRuby is installed on each computer.

In case you’re curious about the legality of my project, I assure you
that
it’s quite fine. The only thing I plan to redistribute is some code
that
will run existing games. No copyright protected materials such as
images,
audio, video etc will be redistributed - nor do I have any interest in
developing the part of the RPG Maker software that actually let’s you
makegames, which means that my project won’t impact Enterbrain’s
profits in any
way (their EULA allows the customer to redistribute their games however
the
customer sees fit, so they only make money when someone purchases RPG
Maker
to develop games).

If you’re still interested in taking a peek at my code, I plan on
distributing the source on GitHub some time soon.

-Charles

On Sun, Jul 25, 2010 at 1:50 PM, Tomas M. <

#8

Cool! :slight_smile:

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Charles
Strahan
Sent: Monday, July 26, 2010 5:24 AM
To: [email protected]
Subject: Re: [Ironruby-core] Setting and initializing instance variables
on RubyClasses

It’s actually an entire game engine port :).

http://www.rpgmakerweb.com/product.html?prod=xp

However, I don’t believe “port” is the correct word - perhaps
“reimplementation” would be more accurate. I don’t have access to RPG
Maker’s source code, so I’ve written the entire game engine from the
documented APIs, and by injecting little bits of Ruby into RPG Maker’s
Ruby runtime to fill in any of the blanks. Finally, I ran several games
through my “port” and fixed any little bugs I came across. It was no
small feat, I assure you :).

So, as you can probably imagine, the rendering is highly coupled to the
rest of the engine. As a result, I have no expectations to use it
anywhere else. Sure, I could abstract away stuff like drawing
rectangles and circles to bitmaps, but anything more than that (sprites,
windows, etc.) wouldn’t make any sense outside of this particular game
engine. I’m sure I could do it all in Ruby (and have, when I wrote the
WinForms impl) - but I don’t find IronRuby as easy to debug as C# (yet).
So, if I’m going to write any C# code, that C# code will need to
directly interop with the rest of the Ruby modules and classes (in most
cases). I’m sure the IronRuby APIs will change from version to version,
but that’s not a big deal in my case. I’m fine updating my code to
match the latest release, or just tying my code to a specific version.
My current goal is to make my port run on Silverlight and, consequently,
Windows Phone 7 so that people can redistribute their games on the
market place or on the web; in both cases, targeting a specific version
of IronRuby is easy. If, on the otherhand, I wanted to distribute a
platform agnostic implementation, then I would run into problems as
there’s no telling what version of IronRuby is installed on each
computer.

In case you’re curious about the legality of my project, I assure you
that it’s quite fine. The only thing I plan to redistribute is some
code that will run existing games. No copyright protected materials
such as images, audio, video etc will be redistributed - nor do I have
any interest in developing the part of the RPG Maker software that
actually let’s you make games, which means that my project won’t impact
Enterbrain’s profits in any way (their EULA allows the customer to
redistribute their games however the customer sees fit, so they only
make money when someone purchases RPG Maker to develop games).

If you’re still interested in taking a peek at my code, I plan on
distributing the source on GitHub some time soon.

-Charles

On Sun, Jul 25, 2010 at 1:50 PM, Tomas M.
<[email protected]mailto:[email protected]>
wrote:
So you’re building a graphics library based on WritableBitmap?
You can certainly try to build Ruby classes in C# however it might be
much easier and more flexible to build basic data structures and
algorithms that need to be highly optimized in regular C# (no Ruby
specific stuff) and then wrap them into a Ruby class in Ruby code. Your
C#.dll might define a regular C# class Graphics:

namespace MyNamespace {
public class Graphics {
public void DoStuff() { }
}
}

And then you’ll write a Ruby wrapper:

require ‘graphics.dll’
class MyNamespace::Graphics
def ruby_facade
do something ruby-ish
do_stuff
end
end

Maybe if you gave concrete examples of the APIs you’re designing it
might help me understand why this wouldn’t be sufficient. The goal of
IronRuby is to allow you to use interop with regular C# code easily and
efficiently without a need to specialize it for Ruby. For calling back
to Ruby you can use C#'s dynamic features. If there is anything that
prevents you from doing so let us know. The additional advantage of
this approach is that your C# code can easily be used from other
languages as well.

Re: CallSiteStorage: any time you need to dynamically call a method
using Ruby semantics you should use it to do so. Three are plenty of use
cases throughout the library that you can see for examples (search for
Storage).

We don’t have any optimizations in place for class variable access. So
TryGetClassVariable always looks up a dictionary.

Tomas

From:
[email protected]mailto:[email protected]
[mailto:[email protected]mailto:[email protected]]
On Behalf Of Charles S.
Sent: Sunday, July 25, 2010 3:02 AM

To: [email protected]mailto:[email protected]
Subject: Re: [Ironruby-core] Setting and initializing instance variables
on RubyClasses

By native Ruby library/extension I meant an implementation in C.

D’oh! I realized that’s what you’d meant after I replied. Woops :).
If you absolutely need to implement your Ruby classes in C# (I would be
interested to understand why)

I probably don’t need to for the most part, but I do have some
motivation for doing so. Performance is a must. Also, I’m doing a lot
of WritableBitmap manipulations, using (among other things) the
WritableBitmapEx on CodePlex, which feels a lot more natural in C#.
I’ve already completed my little project using pure [Iron]Ruby and
WinForms, but I figured I’d try out the IronRuby API & C# now that I’m
porting it to Silverlight. The interop with plain vanilla C# libs is
great, but I can’t picture pulling off stuff like #_dump and ._load
without going the API route. Also, I think it’ll be good practice using
the IronRuby API from C#, as I’d like to contribute back to libraries
(ruby-debug-ide and ffi are at the top of my list).
To allocate data bound to a runtime we provide GetOrCreateLibraryData
method on RubyContext.

I’ll have to check that out. For now, using the following pattern seems
to work well enough:

// from the Graphics class
self.TryGetClassVariable(“renderables”, out renderables) // where
self is the RubyClass

// from another class:
var graphicsClass = context.GetClass(typeof(Graphics));
graphicsClass.TryGetClassVariable(“renderables”, out renderables)

I also (think) I saw some code throughout IronRuby that used
CallSiteStorage to interact with ruby objects. Would that yield better
performance?

Cheers,

-Charles
On Wed, Jul 7, 2010 at 11:15 AM, Tomas M.
<[email protected]mailto:[email protected]>
wrote:
By native Ruby library/extension I meant an implementation in C.

Although possible it’s not easy to simulate Ruby classes definition in
C# in a declarative way. I would suggest writing your implementation in
Ruby and calling .NET when you need so using IronRuby’s .NET interop.
If you absolutely need to implement your Ruby classes in C# (I would be
interested to understand why) you can use C# instance fields instead of
Ruby’s instance variables. They won’t be exposed as instance variables
to Ruby but they would be faster to work with. The fact they are not
exposed shouldn’t matter since instance variables should be a private
implementation detail of the class anyways.

It is more complicated with per-class data. You shouldn’t use static
fields since the value should be bound to Ruby runtime. To allocate data
bound to a runtime we provide GetOrCreateLibraryData method on
RubyContext. You’ll find a few places where it’s used in
IronRuby.Library. But before you dig into that consider writing your
code in Ruby and perhaps parts of it that are perf critical in pure C#
(w/o Ruby specific attributes). Our C# interop is strong so there
shouldn’t be generally a need for writing Ruby code in C#.

Tomas