RE: [Rubydotnet-developer] [ANN] Ruby/.NET bridge release 4 now available

[Thomas S. <th...@th...>]

> I'd like to announce release 4 of our Ruby/.NET bridge.  It includes
> 
> 	- Offline documentation
> 	- An Evaluator Transcript window
> 	- New syntax for creating .NET delegates
> 	- A Samples Browser with a few lessons and samples

Great! Things are moving along nicely. It's a tell tale sign that you
are getting quite feature complete now that you can devote time to
documentation.

> Hope everything is well with all of you - if you have any questions or

> ideas, please post them!

I have a couple of ideas. I think both our bridges are getting
reasonably feature complete. I think there are two significant things
that could contribute to both our projects and the ultimate goal the
best possible integration with .net from ruby:

1) A dogfood project - as in eating our own. A large or largish
application written in ruby using the .net facilities. Unit tests are
great but it would be interesting to flush out the bugs you only find
with use and get a feel for the runtime performance etc.

2) Contributing to ruby itself to improve it's threading on Windows. I
have run some experiments using ruby (no .net) on Windows and linux with
ruby threads. On linux things appear to work sanely. Take for instance
this small script:

t = Thread.new { loop { sleep 1; puts "hello world" } }
loop { puts gets }
t.join

On linux it happily prints out "hello world" once a second no matter
what else you do. On Windows (the pragproc VC build of ruby, I'm using
at least) the entire process is blocked in the call to gets().

We need to fix this to make ruby threading tolerable on windows!


These are things worthwhile doing. Currently I'm also working on a small
project for embedding ruby in a .net project. It is mostly independent
on the bridge implementation, it is merely an interface for creating a
ruby interpreter instance and setting it to work. 

I am also thinking about a Mono port using the mono hosting API. The
managed C++ extension wont work on non-windows platforms and I think the
cross platform aspect is important to the ruby community. Unix support
in itself certainly is important to the community.

I have also been lobbying around the Python, Tcl and Lua camps to hear
if they have similar projects as ours and suggested that we collaborate
on the bits that are similar across projects. I have been sending them
the following lines:

There is a range of things you want to do when you bind a dynamic
language like ruby to .net using a dual-runtime approach, that is not
ruby specific, but specific to the dynamic nature of the language. I
have been building ScriptingExtensions for .net as I needed things for
rubydotnet. Currently it has the following classes/services:

1) ScriptingExtensions.ScriptEngine/Evaluator - for dynamically
evaluating C#, VB, and JScript from the script side. Primarily to allow
the script writer to express performance critical sections in .net
rather than in the scripting language, without having to create e.g. a
C# project and compile it to .net. This uses
Microsoft.CSharp(/VisualBasic/JScript) to compile code at runtime.

2) ScriptingExtensions.TypeFinder - simple class for looking up types
and namespaces. (Type.GetType doesn't look in dynamically loaded
assemblies, and there is no built-in mechanism for looking up a
namespace, as far as I can
tell)

3) ScriptingExtensions.TypedDelegateFactory.getDelegate(Type
delegateType, IProc proc) - creates typed delegates that invoke
IProc.invoke(object[] args). ScriptingExtensions.Binder implements a
binder that can be used with Type.InvokeMember to allow automatic
conversion of IProc's to the relevant delegate type.

4) ScriptingExtensions.DynamicClassFactory.getType(Type baseType, Type[]
interfaces) - automatically create wrapper type objects with base
baseType that implements interfaces. This is necessary if you want
script objects to implement  .net interfaces. This is based on
implementing all members of the interfaces in terms of
IObject.send(string msg, object[] args). baseType must implement
IObject.

I don't see why language bindings for Python, Perl, TCL, PHP, Lua etc
wouldn't need the same services.

Cheers,

Thomas