Ironruby core - Feb 2008 - Initializing external Ruby libraries

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?

Cheers, Wayne.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/ironruby-core/attachments/20080214/6ee8eaaf/attachment.html

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.

 

Is that what you meant?
Pete

 

From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly
Sent: Wednesday,13 February 13, 2008 23:59
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Initializing external Ruby libraries

 

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?

 

Cheers, Wayne.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/ironruby-core/attachments/20080214/690b6f5c/attachment.html

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).

On Feb 13, 2008 6:58 PM, Wayne Kelly <w.kelly at qut.edu.au>
wrote:
>
>
> 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?
>
> Cheers, Wayne.
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
Michael Letterle
[Polymath Programmer]
http://michaeldotnet.blogspot.com

Michael Letterle:
> 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#

- John

________________________________
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Peter Bacon Darwin
Sent: Thursday, 14 February 2008 11:01 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Initializing external Ruby libraries

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.

Is that what you meant?
Yes, exactly.

Cheers, Wayne.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/ironruby-core/attachments/20080214/f087d712/attachment.html

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?

On Feb 13, 2008 8:13 PM, John Messerly <jomes at microsoft.com>
wrote:
> Michael Letterle:
>
> > 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#
>
> - John
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>


-- 
Michael Letterle
[Polymath Programmer]
http://michaeldotnet.blogspot.com

> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org
> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of
> Michael Letterle
> Sent: Thursday, 14 February 2008 11:03 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Initializing external Ruby libraries
>
> 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
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?

Cheers, Wayne.

Michael Letterle:
> 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?
>
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.

- John

I assume then we will be using the RubyLibrary, RubyClass, RubyMethod
attributes, et al to implement that then?

On Feb 13, 2008 9:00 PM, John Messerly <jomes at microsoft.com>
wrote:
> Michael Letterle:
>
> > 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?
> >
>
> 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.
>
>
> - John
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>


-- 
Michael Letterle
[Polymath Programmer]
http://michaeldotnet.blogspot.com