I want to convert a series of VB DLLs to ruby. Is it possible to write
activex controls and DLLs in ruby? There might be a snag in that the
controls need to send events to the calling program.
Also is it possible to write windows servers in ruby or have ruby
itself run as a windows service?
Cheers.
Tim Uckun wrote:
I want to convert a series of VB DLLs to ruby. Is it possible to write
activex controls and DLLs in ruby? There might be a snag in that the
controls need to send events to the calling program.
The short answer is no, you can't compile Ruby code into a binary DLL.
You can call DLLs from Ruby.
The slightly longer answer involves Ruby2C, which converts a subset of
Ruby to C, but I don't suppose this is what you want.
Also is it possible to write windows servers in ruby or have ruby
itself run as a windows service?
Yes, you can do these. Check out win32-service on the RAA.
Cheers,
Dave
Thanks. I am a bit disapointed that I can't write activex controls or
DLLs in ruby, I know it's possible to do that in python.
I will take a look at the windows service though, that might provide a
workaround for some of the stuff I want to do.
On 5/12/06, Dave Burt <dave@burt.id.au> wrote:
Tim Uckun wrote:
> I want to convert a series of VB DLLs to ruby. Is it possible to write
> activex controls and DLLs in ruby? There might be a snag in that the
> controls need to send events to the calling program.The short answer is no, you can't compile Ruby code into a binary DLL.
You can call DLLs from Ruby.The slightly longer answer involves Ruby2C, which converts a subset of
Ruby to C, but I don't suppose this is what you want.> Also is it possible to write windows servers in ruby or have ruby
> itself run as a windows service?Yes, you can do these. Check out win32-service on the RAA.
Cheers,
Dave
Well a more complete answer would be that you cannot write a DLL in
just Ruby. It is pretty easy to embed Ruby into a C program (or DLL)
and then have it wrap either an embedded or external Ruby program. Do
be careful that the Ruby interpreter is not thread safe and if you
need to support threads you should mutex the whole thing.
Good luck
pth
On 5/12/06, Tim Uckun <timuckun@gmail.com> wrote:
Thanks. I am a bit disapointed that I can't write activex controls or
DLLs in ruby, I know it's possible to do that in python.I will take a look at the windows service though, that might provide a
workaround for some of the stuff I want to do.On 5/12/06, Dave Burt <dave@burt.id.au> wrote:
> Tim Uckun wrote:
> > I want to convert a series of VB DLLs to ruby. Is it possible to write
> > activex controls and DLLs in ruby? There might be a snag in that the
> > controls need to send events to the calling program.
>
> The short answer is no, you can't compile Ruby code into a binary DLL.
> You can call DLLs from Ruby.
>
> The slightly longer answer involves Ruby2C, which converts a subset of
> Ruby to C, but I don't suppose this is what you want.
>
> > Also is it possible to write windows servers in ruby or have ruby
> > itself run as a windows service?
>
> Yes, you can do these. Check out win32-service on the RAA.
>
> Cheers,
>
> Dave
>
Tim Uckun wrote:
Thanks. I am a bit disapointed that I can't write activex controls or
DLLs in ruby, I know it's possible to do that in python.
Really? Can you tell me more? I imagine it's less straightforward than
you make it sound.
See also Pat's answer.
I will take a look at the windows service though, that might provide a
workaround for some of the stuff I want to do.
Depending on what you want to do, using rubyw.exe to launch Ruby without
an attached console might be an easier way.
Cheers,
Dave
Dave Burt wrote:
Tim Uckun wrote:
Thanks. I am a bit disapointed that I can't write activex controls or
DLLs in ruby, I know it's possible to do that in python.Really? Can you tell me more? I imagine it's less straightforward than
you make it sound.
Win32 COM servers can be created in Python:
<http://mail.python.org/pipermail/python-list/2002-November/129951.html>
...and 'compiled' to a DLL and/or EXE using py2exe:
Mully
--
Posted via http://www.ruby-forum.com/\.
Yes, it's trivial really. It's a nice feature of python. I found this
http://www.geocities.com/masonralph/ruby.html which is really
interesting because it doesn't actually generate a DLL but still lets
you instantiate your ruby objects as COM objects as long as they are
in the library path.
Quite interesting. Supposedly still beta and hasn't been touched in a
while apparently.
In principle, this isn't hard to make happen. I could imagine a
universal delegator approach where you cruft up a generic
implementation of IDispatch and use Ruby's reflection capabilities to
find methods to call. The only wierd stuff that you might have to
worry about is mapping named parameters and marshaling SAFEARRAYS.
The tougher thing is dealing with threading / apartment model
compatibility. You could probably only make the STA threading model
work for the generic case of a single STA in a process due to Ruby not
being thread safe.
In RubyCLR I have to worry about the case where multiple STA threads
attempt to call into Ruby - my proxies have to disallow the method
call and raise a CLR exception.
It would be really, really nice once the Ruby interpreter is thread safe 
-John
http://www.iunknown.com
It would be really, really nice once the Ruby interpreter is thread safe
Just by way of clarification, are you referring to the fact that Ruby
doesn't share synchronization primitives with the native platform? I've
given that some thought recently and it may be possible to accomplish with a
patch to Ruby's thread.rb. What's the point of it, however? Are you trying
to make it so a container can spin multiple COM threads and each thread can
access Ruby objects without any cooperation from Ruby's interpreter?
More broadly (and I'm asking this out of curiosity, not tendentiously):
what's the point of being able to write a DLL in Ruby? Are people looking
for the ability to write CLR programs that include components written in a
variety of different languages? And is there some reason to do this apart
from retaining compatibility with already-written stuff? If you did this,
how much of Ruby's metaprogramming would you have to give up, in order to
get a statically-enforceably contract that could be expressed as a COM
interface? I can imagine a more loosely-coupled way of achieving the same
thing.
Sorry I'm not really contributing anything but more questions with this
post, but I'm trying to understand the questions that have already been
posed.
On 5/14/06, John Lam <drjflam@gmail.com> wrote:
In principle, this isn't hard to make happen. I could imagine a
universal delegator approach where you cruft up a generic
implementation of IDispatch and use Ruby's reflection capabilities to
find methods to call. The only wierd stuff that you might have to
worry about is mapping named parameters and marshaling SAFEARRAYS.The tougher thing is dealing with threading / apartment model
compatibility. You could probably only make the STA threading model
work for the generic case of a single STA in a process due to Ruby not
being thread safe.In RubyCLR I have to worry about the case where multiple STA threads
attempt to call into Ruby - my proxies have to disallow the method
call and raise a CLR exception.It would be really, really nice once the Ruby interpreter is thread safe
-John
http://www.iunknown.com
My main goal in writing a COM object in Ruby is to be able call ruby
code from VB and to replace VB COM objects with ruby COM objects. Ruby
is a much more capably language then VB so I would like to use it
instead.
On 5/15/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
>>>It would be really, really nice once the Ruby interpreter is thread safe
Just by way of clarification, are you referring to the fact that Ruby
doesn't share synchronization primitives with the native platform? I've
given that some thought recently and it may be possible to accomplish with a
patch to Ruby's thread.rb. What's the point of it, however? Are you trying
to make it so a container can spin multiple COM threads and each thread can
access Ruby objects without any cooperation from Ruby's interpreter?More broadly (and I'm asking this out of curiosity, not tendentiously):
what's the point of being able to write a DLL in Ruby? Are people looking
for the ability to write CLR programs that include components written in a
variety of different languages? And is there some reason to do this apart
from retaining compatibility with already-written stuff? If you did this,
how much of Ruby's metaprogramming would you have to give up, in order to
get a statically-enforceably contract that could be expressed as a COM
interface? I can imagine a more loosely-coupled way of achieving the same
thing.Sorry I'm not really contributing anything but more questions with this
post, but I'm trying to understand the questions that have already been
posed.On 5/14/06, John Lam <drjflam@gmail.com> wrote:
>
> In principle, this isn't hard to make happen. I could imagine a
> universal delegator approach where you cruft up a generic
> implementation of IDispatch and use Ruby's reflection capabilities to
> find methods to call. The only wierd stuff that you might have to
> worry about is mapping named parameters and marshaling SAFEARRAYS.
>
> The tougher thing is dealing with threading / apartment model
> compatibility. You could probably only make the STA threading model
> work for the generic case of a single STA in a process due to Ruby not
> being thread safe.
>
> In RubyCLR I have to worry about the case where multiple STA threads
> attempt to call into Ruby - my proxies have to disallow the method
> call and raise a CLR exception.
>
> It would be really, really nice once the Ruby interpreter is thread safe
>
>
> -John
> http://www.iunknown.com
>
In my case I have an existing infrastructure where a "master" server
instantiates a series of activeX dlls and communicates with them via
events. The DLLs are now written in VB and I was thinking it would be
nice to rewrite them in Ruby.
On 5/15/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
>>>It would be really, really nice once the Ruby interpreter is thread safe
Just by way of clarification, are you referring to the fact that Ruby
doesn't share synchronization primitives with the native platform? I've
given that some thought recently and it may be possible to accomplish with a
patch to Ruby's thread.rb. What's the point of it, however? Are you trying
to make it so a container can spin multiple COM threads and each thread can
access Ruby objects without any cooperation from Ruby's interpreter?More broadly (and I'm asking this out of curiosity, not tendentiously):
what's the point of being able to write a DLL in Ruby? Are people looking
for the ability to write CLR programs that include components written in a
variety of different languages? And is there some reason to do this apart
from retaining compatibility with already-written stuff? If you did this,
how much of Ruby's metaprogramming would you have to give up, in order to
get a statically-enforceably contract that could be expressed as a COM
interface? I can imagine a more loosely-coupled way of achieving the same
thing.Sorry I'm not really contributing anything but more questions with this
post, but I'm trying to understand the questions that have already been
posed.On 5/14/06, John Lam <drjflam@gmail.com> wrote:
>
> In principle, this isn't hard to make happen. I could imagine a
> universal delegator approach where you cruft up a generic
> implementation of IDispatch and use Ruby's reflection capabilities to
> find methods to call. The only wierd stuff that you might have to
> worry about is mapping named parameters and marshaling SAFEARRAYS.
>
> The tougher thing is dealing with threading / apartment model
> compatibility. You could probably only make the STA threading model
> work for the generic case of a single STA in a process due to Ruby not
> being thread safe.
>
> In RubyCLR I have to worry about the case where multiple STA threads
> attempt to call into Ruby - my proxies have to disallow the method
> call and raise a CLR exception.
>
> It would be really, really nice once the Ruby interpreter is thread safe
>
>
> -John
> http://www.iunknown.com
>
I wonder if you could write a utility that would parse a Ruby class and turn
it into C code that you could compile down to a COM object. (Not the actual
Ruby code, just the methods and arguments, giving you the IDL and the COM
interface.) But then you'd need to shoehorn a Ruby interpreter into your COM
container to run the objects. Hmmm.....
Might be better off with a SOA approach, depending on what you're trying to
do
On 5/14/06, Tim Uckun <timuckun@gmail.com> wrote:
My main goal in writing a COM object in Ruby is to be able call ruby
code from VB and to replace VB COM objects with ruby COM objects. Ruby
is a much more capably language then VB so I would like to use it
instead.On 5/15/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
> >>>It would be really, really nice once the Ruby interpreter is thread
safe
>
> Just by way of clarification, are you referring to the fact that Ruby
> doesn't share synchronization primitives with the native platform? I've
> given that some thought recently and it may be possible to accomplish
with a
> patch to Ruby's thread.rb. What's the point of it, however? Are you
trying
> to make it so a container can spin multiple COM threads and each thread
can
> access Ruby objects without any cooperation from Ruby's interpreter?
>
> More broadly (and I'm asking this out of curiosity, not tendentiously):
> what's the point of being able to write a DLL in Ruby? Are people
looking
> for the ability to write CLR programs that include components written in
a
> variety of different languages? And is there some reason to do this
apart
> from retaining compatibility with already-written stuff? If you did
this,
> how much of Ruby's metaprogramming would you have to give up, in order
to
> get a statically-enforceably contract that could be expressed as a COM
> interface? I can imagine a more loosely-coupled way of achieving the
same
> thing.
>
> Sorry I'm not really contributing anything but more questions with this
> post, but I'm trying to understand the questions that have already been
> posed.
>
> On 5/14/06, John Lam <drjflam@gmail.com> wrote:
> >
> > In principle, this isn't hard to make happen. I could imagine a
> > universal delegator approach where you cruft up a generic
> > implementation of IDispatch and use Ruby's reflection capabilities to
> > find methods to call. The only wierd stuff that you might have to
> > worry about is mapping named parameters and marshaling SAFEARRAYS.
> >
> > The tougher thing is dealing with threading / apartment model
> > compatibility. You could probably only make the STA threading model
> > work for the generic case of a single STA in a process due to Ruby not
> > being thread safe.
> >
> > In RubyCLR I have to worry about the case where multiple STA threads
> > attempt to call into Ruby - my proxies have to disallow the method
> > call and raise a CLR exception.
> >
> > It would be really, really nice once the Ruby interpreter is thread
safe
> >
> >
> > -John
> > http://www.iunknown.com
> >
>