For Ruby libraries such as sockets, openssl etc (ie not built-in classes
or modules), I assume we will implement/port them using say C# to
produce a managed dll (eg socket.dll). Client programs will then require
‘socket’, and IronRuby will load socket.dll rather than socket.so
I note IronRuby already has the ability to load managed dlls such as
mscorlib - but that appears to simply load the assembly and then
presumably uses .NET reflection to expose the .NET classes as Ruby
classes. But for managed dll such as socket.dll that has been
specifically engineered as an IronRuby extension dll, I image the
loading process would be a little different? CRuby, for example exposes
an Init_Foo function which explicitly calls define_class, define_method
etc to explicitly register each of the Ruby classes implemented by that
library (equivalent to what IronRuby does in
LibrariesInitializer.LoadModules).
Will there be a similar convention used by IronRuby? Possibly in static
class constructors?
I believe the library side of this mechanism is already in-place.
Take a look at the
\trunk\src\IronRuby.Libraries\Initializer.Generated.cs
file which is automatically generated by the
\trunk\src\IronRuby.Libraries\GenerateInitializers.cmd. The cmd file
reflects on the compiled library file, reading the RubyClass,
RubyMethod,
etc. attributes and generates the initialize code you describe below.
You
can see this in action inside \trunk\src\ironruby\Runtime\Loader.cs :
Ruby.Runtime.Loader.LoadStandardRubyLibraries().
What appears to be missing is the hosting side of things when you
“require”
one of these assemblies. There doesn’t seem to be any point in the
assembly
loading process that checks for a LibraryInitializer class and runs the
LoadModules method.
For Ruby libraries such as sockets, openssl etc (ie not built-in classes
or
modules), I assume we will implement/port them using say C# to produce a
managed dll (eg socket.dll). Client programs will then require ‘socket’,
and
IronRuby will load socket.dll rather than socket.so
I note IronRuby already has the ability to load managed dlls such as
mscorlib - but that appears to simply load the assembly and then
presumably
uses .NET reflection to expose the .NET classes as Ruby classes. But for
managed dll such as socket.dll that has been specifically engineered as
an
IronRuby extension dll, I image the loading process would be a little
different? CRuby, for example exposes an Init_Foo function which
explicitly
calls define_class, define_method etc to explicitly register each of the
Ruby classes implemented by that library (equivalent to what IronRuby
does
in LibrariesInitializer.LoadModules).
Will there be a similar convention used by IronRuby? Possibly in static
class constructors?
What do you see would be the advantage of something like this as
opposed to the current method of loading .NET assemblies? I mean you
could use something like OpenSSL.NET
(http://openssl-net.sourceforge.net/) today to implement ssl in
IronRuby for example
The main reason for implementing the libraries in C# would be for better
performance. But if it’s just a thin wrapper on top of some .NET piece,
there’s no reason you couldn’t implement it in Ruby code instead of C#
I believe the library side of this mechanism is already in-place.
Take a look at the
\trunk\src\IronRuby.Libraries\Initializer.Generated.cs file which is
automatically generated by the
\trunk\src\IronRuby.Libraries\GenerateInitializers.cmd. The cmd file
reflects on the compiled library file, reading the RubyClass,
RubyMethod, etc. attributes and generates the initialize code you
describe below. You can see this in action inside
\trunk\src\ironruby\Runtime\Loader.cs :
Ruby.Runtime.Loader.LoadStandardRubyLibraries().
What appears to be missing is the hosting side of things when you
“require” one of these assemblies. There doesn’t seem to be any point
in the assembly loading process that checks for a LibraryInitializer
class and runs the LoadModules method.
Yes, my only point is that the way it works today a .NET class becomes
a Ruby class and a .NET method becomes a Ruby method. Nothing is
stopping one from writing a .NET assembly so that it “feels” like Ruby
when it’s compiled.
That said, I can see the advantage of being able to use the RubyClass
and RubyMethod attributes outside of that…
Is the performance between this and utilizing an Initializer that great?
It’s not just about getting access to some implementation of OpenSSL, it
about providing a set of Ruby classes and methods that exactly match
those exposed by existing Ruby extension libraries used by CRuby. By
explicitly calling define_class, define_method etc, you have better
control over how your C# code is presented to the Ruby world. You can,
for example, specify a Ruby base class that may not exist as a static
.NET class. I’m not sure if this is actually an issue in practice. But
then if there’s no need to call define_class and define_method
explicitly for external libraries, then why do it for the built-in
classes? Why not simply load an RubyExternalLibrary.dll? Is it for
performance, for preciseness of interface or both?
What do you see would be the advantage of something like this as
opposed to the current method of loading .NET assemblies? I mean you
could use something like OpenSSL.NET
(http://openssl-net.sourceforge.net/) today to implement ssl in
IronRuby for example
I believe a future goal is to actually support loading unmanaged
extensions (this is based strictly on comments in the code, noone’s
actually said this as far as I know).
Sorry, I misunderstood. I thought you were suggesting writing the
library as a .rb file & using .NET interop features to call into the
.NET code.
Yeah, you couldn’t just write it in C# because we need the initializer
to give proper Ruby method names &
public/protected/private/instance/singleton metadata. It’s also a
performance win because we don’t need to use reflection to pull out the
metadata at runtime.