ActiveRubyScript and RubyAEOSA

I just discovered ActiveRubyScript (sometimes written as two words) by
following up on a reference here. I haven’t had a chance to play with it
yet but I’m installing a Windows emulator in the background so I can play
with it.

How important is it? How much is it like Ruby.

It doesn’t appear to be much like RubyAEOSA. Is this important?

I’m sort of a *nix newbie but thumbing through “Unix in a Nutshell” there
don’t appear to be any ‘scripting languages’ in the Visual
Basic/JavaScript/AppleScript sense or for that matter any scriptable
applications.[1] I don’t doubt that this is related to the linear nature of
many Unix apps that has been mentioned here before. But that raises the
question of will there ever be scriptable Unix apps, and if the answer is
yes, shouldn’t there be a single Ruby syntax for addressing them.

[1] Leaving MOSX out of UNIX for the sake of discussion.

···


Many individuals have, like uncut diamonds, shining qualities beneath a
rough exterior. - Juvenal, poet (c. 60-140)

I just discovered ActiveRubyScript (sometimes written as two words) by
following up on a reference here. I haven’t had a chance to play with it
yet but I’m installing a Windows emulator in the background so I can play
with it.

Isn’t it actually called ActiveScriptRuby? I’m
going from memory here…

How important is it? How much is it like Ruby.

I’d say it is Ruby – an embeddable version of the
interpreter (embeddable in the sense of Windows Script
Host, etc.). For example, using ASR, your Internet
Explorer can run Ruby scripts just as (out of the box)
it runs Javascript code.

Having said that it “is” Ruby, there may be differences
I’m not aware of.

How important? Only if 1) you’re using Windows and 2) you
want to use an embedded Ruby interpreter. And then there
might be other ways.

It doesn’t appear to be much like RubyAEOSA. Is this important?

I don’t know about that. Can you elaborate?

I’m sort of a *nix newbie but thumbing through “Unix in a Nutshell” there
don’t appear to be any ‘scripting languages’ in the Visual
Basic/JavaScript/AppleScript sense or for that matter any scriptable
applications.[1] I don’t doubt that this is related to the linear nature
of
many Unix apps that has been mentioned here before. But that raises the
question of will there ever be scriptable Unix apps, and if the answer is
yes, shouldn’t there be a single Ruby syntax for addressing them.

Interesting viewpoint. Personally I would say that
the Unix world invented the scriptable app and
perhaps the concept of a scripting language (as
opposed to the old job control languages). Flames
to /dev/null, please. :slight_smile:

But I think I see what you are saying. You want
apps to expose an interface the way Windows apps
expose a COM interface, or something, right? Or
am I misunderstanding?

Well, I have often wished for a COM equivalent in
the Unix world. It would only be useful if there
were one universal standard, I think. My knowledge
of this particular area is limited, though, so I
can’t address it much.

But please, let’s generate some discussion on this.

Hal

···

----- Original Message -----
From: “Chris Gehlker” gehlker@fastq.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, July 30, 2002 12:46 PM
Subject: ActiveRubyScript and RubyAEOSA

Having said that it “is” Ruby, there may be differences
I’m not aware of.

How important? Only if 1) you’re using Windows and 2) you
want to use an embedded Ruby interpreter. And then there
might be other ways.

You can write IIS ASP websites in ActiveScriptRuby

But I think I see what you are saying. You want
apps to expose an interface the way Windows apps
expose a COM interface, or something, right? Or
am I misunderstanding?

Well, I have often wished for a COM equivalent in
the Unix world. It would only be useful if there
were one universal standard, I think. My knowledge
of this particular area is limited, though, so I
can’t address it much.

But please, let’s generate some discussion on this.

I, too, would be interested in knowing what sort of app scripting is
available on Unix. Do KDE or Gnome provide ways to expose automation
interfaces? Can I write a Ruby app to instantiate and manipulate an
instance of OpenOffice, as I can have it so with Microsoft Word?

You can use ActiveScriptRuby to create stand-alone, browser-based GUIs using
IE. Is such a thing possible with Mozilla/Netscape/Opera?

James

···

Hal

From: “Chris Gehlker” gehlker@fastq.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, July 30, 2002 12:46 PM
Subject: ActiveRubyScript and RubyAEOSA

I just discovered ActiveRubyScript (sometimes written as two words) by
following up on a reference here. I haven’t had a chance to play with it
yet but I’m installing a Windows emulator in the background so I can play
with it.

Isn’t it actually called ActiveScriptRuby? I’m
going from memory here…

ActiveScriptRuby is more common. I was just copying the translation from the
last page I googled up.

How important is it? How much is it like Ruby.

I’d say it is Ruby – an embeddable version of the
interpreter (embeddable in the sense of Windows Script
Host, etc.). For example, using ASR, your Internet
Explorer can run Ruby scripts just as (out of the box)
it runs Javascript code.

Having said that it “is” Ruby, there may be differences
I’m not aware of.

How important? Only if 1) you’re using Windows and 2) you
want to use an embedded Ruby interpreter. And then there
might be other ways.

It doesn’t appear to be much like RubyAEOSA. Is this important?

I don’t know about that. Can you elaborate?

I was trying to get a sense of whether the community was happy with the way
that the Mac and Windows versions of Ruby as a ‘scripting language’ was
evolving separately. Personally I’m not because it seems to me that a
program that, for example, tells MS Word to grab some data from a named
range in Excel and insert it in a document should not have to know what OS
the apps are running on. But I don’t want to speak too strongly about other
peoples projects.

I’m sort of a *nix newbie but thumbing through “Unix in a Nutshell” there
don’t appear to be any ‘scripting languages’ in the Visual
Basic/JavaScript/AppleScript sense or for that matter any scriptable
applications.[1] I don’t doubt that this is related to the linear nature
of
many Unix apps that has been mentioned here before. But that raises the
question of will there ever be scriptable Unix apps, and if the answer is
yes, shouldn’t there be a single Ruby syntax for addressing them.

Interesting viewpoint. Personally I would say that
the Unix world invented the scriptable app and
perhaps the concept of a scripting language (as
opposed to the old job control languages). Flames
to /dev/null, please. :slight_smile:

But I think I see what you are saying. You want
apps to expose an interface the way Windows apps
expose a COM interface, or something, right? Or
am I misunderstanding?

Exactly! I wasn’t trying to start a flame war but ‘scripting language’ means
very different things in different contexts. I think of Ruby as a ‘scripting
language’ and Visual Basic for Applications as a ‘macro’ language. I think
of Excel as a ‘scriptable app’ and emacs as a ‘programmable app’. I think
the distinction is clear enough to anyone who has used both. Languages like
Ruby and Perl are concerned more with data manipulation. The other group
strive to be more of a JCL. There competitors are bash, tcsh, etc more than
Ruby.

Having said that, the JavaScript folks were on to something. There is no
reason for the user to have to learn more than one syntax.

Well, I have often wished for a COM equivalent in
the Unix world. It would only be useful if there
were one universal standard, I think. My knowledge
of this particular area is limited, though, so I
can’t address it much.

The Mac OS X one is just XML. They have a DTD for an application to use to
describe the objects it knows about, the gettable instances, the
gettable/settable instances and the methods and their parameters and return
messages. The DTD associates more or less arbitrary 32 bit codes with all of
these human readable strings. It’s up to the language implementer to parse
the XML and present the user with a human readable ‘dictionary’ and to turn
the dictionary words back into the codes. Alternatively, if you build the
language as a plug-in to ScriptEditor.app, you get the parsing and
translation ‘for free’. The actual messaging infrastructure is just BSD IAC.

There are advantages to this approach. It’s easy to understand, very easy
to localize, and it’s not too hard to make tools that automate some of the
XML generation. It’s portable to any OS that has some method of piping
messages between applications.

Of course it means the apps have to have an additional UI in addition to the
command line or GUI or whatever.

But please, let’s generate some discussion on this.

What fuels my enthusiasm is seeing (non-Geek) graphic artists at my wife’s
office doing useful work with AppleScript, the COBOL of scripting languages.

The language itself has some disfeatures but they find it easy to work with
because it presents an object hierarchy that’s already familiar to them.
WorkBooks contain sheets contain ranges contain cells… They don’t have to
create the objects, they already understand them from messing around with
spreadsheets. So if they get assigned to get some numbers from a corporate
database and manipulate them in Excel and present the results in a Word
document, they will do it by hand three of for times and then just script
the whole process.

Think about how much easier that would be with Ruby.

···

On 7/30/02 10:59 AM, “Hal E. Fulton” hal9000@hypermetrics.com wrote:

----- Original Message -----

We are all born originals - why is it so many of us die copies? -Edward
Young, poet (1683-1765)

Interesting viewpoint. Personally I would say that
the Unix world invented the scriptable app and
perhaps the concept of a scripting language (as
opposed to the old job control languages). Flames
to /dev/null, please. :slight_smile:

But I think I see what you are saying. You want
apps to expose an interface the way Windows apps
expose a COM interface, or something, right? Or
am I misunderstanding?

Exactly! I wasn’t trying to start a flame war but ‘scripting
language’ means
very different things in different contexts. I think of Ruby as a
’scripting
language’ and Visual Basic for Applications as a ‘macro’ language. I think
of Excel as a ‘scriptable app’ and emacs as a ‘programmable app’. I think
the distinction is clear enough to anyone who has used both.

What is the distinction for people who have not (sufficiently) used both?

(And, at the risk of starting a language flame war, I don’t think there all
that many functional difference between VBA and VB.)

I don’t know about emacs, but with Excel you can have an application create
an instance of Excel, and manipulate it, or you have Excel load a script and
execute it internally. Or both.

Languages like
Ruby and Perl are concerned more with data manipulation. The other group
strive to be more of a JCL. There competitors are bash, tcsh, etc
more than
Ruby.

Well, I’m inclined to say that Ruby (and maybe Perl) is concerned with
object manipulation. Sometimes the object need be defined in Ruby. Other
times the object can be an external thing with a suitable API.

What fuels my enthusiasm is seeing (non-Geek) graphic artists at my wife’s
office doing useful work with AppleScript, the COBOL of scripting
languages.

The language itself has some disfeatures but they find it easy to
work with
because it presents an object hierarchy that’s already familiar to them.
WorkBooks contain sheets contain ranges contain cells… They
don’t have to
create the objects, they already understand them from messing around with
spreadsheets. So if they get assigned to get some numbers from a corporate
database and manipulate them in Excel and present the results in a Word
document, they will do it by hand three of for times and then just script
the whole process.

Think about how much easier that would be with Ruby.

I’ve written a fair amount of VBA code for Word, and would love to be able
to use Ruby instead of a Visual Basic variant.

James

I was trying to get a sense of whether the community was happy with the
way
that the Mac and Windows versions of Ruby as a ‘scripting language’ was
evolving separately. Personally I’m not because it seems to me that a
program that, for example, tells MS Word to grab some data from a named
range in Excel and insert it in a document should not have to know what OS
the apps are running on. But I don’t want to speak too strongly about
other
peoples projects.

Offhand I’d say that it’s different because each app
takes advantage of its OS features. As I see it, COM
is a Windoze thing, not an Apple thing; so even though
you have Windows apps on a Mac, they will expose
different kinds of interfaces because the OSes are
different (and Micro$oft simply hasn’t created COM for
the Mac, which might well be difficult to impossible
even if they wanted to). Is this assessment accurate?

But I think I see what you are saying. You want
apps to expose an interface the way Windows apps
expose a COM interface, or something, right? Or
am I misunderstanding?

Exactly! I wasn’t trying to start a flame war but ‘scripting language’
means
very different things in different contexts. I think of Ruby as a
’scripting
language’ and Visual Basic for Applications as a ‘macro’ language. I think
of Excel as a ‘scriptable app’ and emacs as a ‘programmable app’. I think
the distinction is clear enough to anyone who has used both. Languages
like
Ruby and Perl are concerned more with data manipulation. The other group
strive to be more of a JCL. There competitors are bash, tcsh, etc more
than
Ruby.

Having said that, the JavaScript folks were on to something. There is no
reason for the user to have to learn more than one syntax.

I’m not sure I follow all your reasoning, but we’ll
let it go. I know little about COM and VBA, and nothing
about the Mac.

The Mac OS X one is just XML. They have a DTD for an application to use to
describe the objects it knows about, the gettable instances, the
gettable/settable instances and the methods and their parameters and
return
messages. The DTD associates more or less arbitrary 32 bit codes with all
of
these human readable strings. It’s up to the language implementer to parse
the XML and present the user with a human readable ‘dictionary’ and to
turn
the dictionary words back into the codes. Alternatively, if you build the
language as a plug-in to ScriptEditor.app, you get the parsing and
translation ‘for free’. The actual messaging infrastructure is just BSD
IAC.

There are advantages to this approach. It’s easy to understand, very easy
to localize, and it’s not too hard to make tools that automate some of the
XML generation. It’s portable to any OS that has some method of piping
messages between applications.

Of course it means the apps have to have an additional UI in addition to
the
command line or GUI or whatever.

“Another UI” is no biggie. The benefits outweigh the hardship
of coding, I think.

I find it hard to understand the XML concept, given that it’s
hard to represent control structures and such in XML. Do they
use tags to mark the parts of a loop and the branches of an
if-then and that kind of thing?

But if it works, and it’s semi-elegant, I’m impressed.

But please, let’s generate some discussion on this.

What fuels my enthusiasm is seeing (non-Geek) graphic artists at my wife’s
office doing useful work with AppleScript, the COBOL of scripting
languages.

Really? AppleScript is that bad? I’m not a Macoid.

The language itself has some disfeatures but they find it easy to work
with
because it presents an object hierarchy that’s already familiar to them.
WorkBooks contain sheets contain ranges contain cells… They don’t have
to
create the objects, they already understand them from messing around with
spreadsheets. So if they get assigned to get some numbers from a corporate
database and manipulate them in Excel and present the results in a Word
document, they will do it by hand three of for times and then just script
the whole process.

Think about how much easier that would be with Ruby.

Yes, definitely! My dream for many months now has been to
control a bunch of Linux (or Unix) apps with Ruby.

Of course, I was thinking of DRb (Distributed Ruby) for
that purpose. It would be easier if the app itself were
written in Ruby – but I daresay the average C/C++ app
could be given an embedded Ruby interpreter that could
run a DRb server.

Either way, that would require an investment in the
application writer’s time. But learning Ruby is time
well spent.

Hal

···

----- Original Message -----
From: “Chris Gehlker” gehlker@fastq.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, July 30, 2002 4:31 PM
Subject: Re: ActiveRubyScript and RubyAEOSA

Well, there’s Win32OLE:

http://homepage1.nifty.com/markey/ruby/win32ole/index_e.html

It looks like a translated version of the Perl module with a similar
name.

The example given there is an Excel one:

require ‘win32ole’

application = WIN32OLE.new(‘Excel.Application’)

application.visible = TRUE
workbook = application.Workbooks.Add();
worksheet = workbook.Worksheets(1);
worksheet.Range(‘A1:D1’).value = [‘North’,‘South’,‘East’,‘West’];

···

On Tuesday 30 July 2002 03:22 pm, JamesBritt wrote:

I’ve written a fair amount of VBA code for Word, and would love to
be able to use Ruby instead of a Visual Basic variant.


Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

Hal E. Fulton:

Offhand I’d say that it’s different because each app
takes advantage of its OS features. As I see it, COM
is a Windoze thing, not an Apple thing; so even though
you have Windows apps on a Mac, they will expose
different kinds of interfaces because the OSes are
different (and Micro$oft simply hasn’t created COM for
the Mac, which might well be difficult to impossible
even if they wanted to). Is this assessment accurate?

Microsoft implemented COM on MacOS and for a while even encouraged
developers to use it. I think they have given up on publicising it but its
likely its still used internally in Office and IE to allow code sharing with
Windows.

Here is an historical link about COM/ActiveX MacOS. The referenced SDK
link is now dead.
http://www.mactech.com/articles/mactech/Vol.13/13.06/ActiveXControlsforMac/

Neil

From: “Chris Gehlker” gehlker@fastq.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, July 30, 2002 4:31 PM
Subject: Re: ActiveRubyScript and RubyAEOSA

[Question about COM on MacOS]

Offhand I’d say that it’s different because each app
takes advantage of its OS features. As I see it, COM
is a Windoze thing, not an Apple thing; so even though
you have Windows apps on a Mac, they will expose
different kinds of interfaces because the OSes are
different (and Micro$oft simply hasn’t created COM for
the Mac, which might well be difficult to impossible
even if they wanted to). Is this assessment accurate?

There actually was a MacCOM in OS < X that Microsoft tried to license and
they had a few takers. There is a limited implementation in OSX that is
sufficient to make the VBA scripts in Office portable as long as they don’t
make system calls. Motorola also uses some OSX COM and it probably shows up
a few other places.

If memory serves, a programmer from MS’s Mac Business Unit said that in OSX,
COM is built on top of the Apple Event model. Certainly in Office you can
use both models, COM or the Apple Event Model.

[snip]

I find it hard to understand the XML concept, given that it’s
hard to represent control structures and such in XML. Do they
use tags to mark the parts of a loop and the branches of an
if-then and that kind of thing?

But if it works, and it’s semi-elegant, I’m impressed.

You’re making it too sophisticated. The XML just presents a static
representation of the objects that the target application understands
together with a mapping to codes used to communicate with it. Control
structures and iteraters are in the scripting language, whether that be
Basic, AppleScript or what have you. Then the third place where there is
some intelligence is in the editor. It has to take object oriented code and
turn it into a bunch of result = send_msg(0x56988569, 0x43852391,
0x89658723,…) type calls by referring to the XML.

Really? AppleScript is that bad? I’m not a Macoid.

It’s semantics are rather nice - clearly in the Smalltalk/Ruby/ObjC family.
But it’s syntax is from the natural language school. It actually uses the
possessive form ('s) to refer to instance variables as in:

Set the text of thePage’s third paragraph to "This is some weird language"
Set the textface of thePage’s third paragraph to bold.

It also suffers from the TIMTOWTDI syndrome but worse than perl. Because I
can write an AppleScript app and save it to disk and what gets saved
contains a bunch of those send_msg() calls. Then I open it again and the
editor loads the XML and tries to recreate my code. But the editor has to
guess. So my:

Page1Count = count of words on page 1 of theDocument

becomes:

Set Page1Count to count of theDocument’s first page’s words.
Or something like that. It’s disconcerting.

Yes, definitely! My dream for many months now has been to
control a bunch of Linux (or Unix) apps with Ruby.

Of course, I was thinking of DRb (Distributed Ruby) for
that purpose. It would be easier if the app itself were
written in Ruby – but I daresay the average C/C++ app
could be given an embedded Ruby interpreter that could
run a DRb server.

Either way, that would require an investment in the
application writer’s time. But learning Ruby is time
well spent.

This is not a bad way to go at all. The only advantage of the XML method is
it works where the app writer is so benighted that she doesn’t prefer Ruby.

Seriously, it’s just a question of how the work gets divided up between the
app writer, the language implementer and the person writing the editor.

For MacOSX most important apps already have either the XML file or the old
MacOS < X format file. And FUJIMOTO Hisakuni already wrote the Ruby library.
So all I need to do is finish the smart editor and I really can control a
bunch of apps with Ruby.

But it would be nice if I could send Ruby messages to apps running on any
platform.

···

On 7/30/02 3:47 PM, “Hal E. Fulton” hal9000@hypermetrics.com wrote:

----- Original Message -----

C++: The power, elegance and simplicity of a hand grenade.

Interesting viewpoint. Personally I would say that
the Unix world invented the scriptable app and
perhaps the concept of a scripting language (as
opposed to the old job control languages). Flames
to /dev/null, please. :slight_smile:

But I think I see what you are saying. You want
apps to expose an interface the way Windows apps
expose a COM interface, or something, right? Or
am I misunderstanding?

Exactly! I wasn’t trying to start a flame war but ‘scripting
language’ means
very different things in different contexts. I think of Ruby as a
’scripting
language’ and Visual Basic for Applications as a ‘macro’ language. I think
of Excel as a ‘scriptable app’ and emacs as a ‘programmable app’. I think
the distinction is clear enough to anyone who has used both.

What is the distinction for people who have not (sufficiently) used both?
Hmm. Maybe it’s a continuum by now. So let me make up an example comparing a
couple of implementations at the extremes, AppleScript and perl on FreeBSD.
Let say I have a bunch of digital photos in jpeg format and I want to touch
them up to make me look handsome. The perl way would be to look on CPAN for
a jpeg library use it to program the code that beautifies me. It would
probably just step though every file in a given directory. The program would
know a lot about jpegs and, with the addition of the library, would actually
embody a model of a jpeg.

Now look at the same project in AppleScript. I’d just write some glue to
tell iPhoto to pass every picture on the current roll to Canvas and to tell
Canvas to clean up my visage. AppleScript doesn’t have any model of a jpeg
but that doesn’t matter because iPhoto and Canvas do. It doesn’t matter that
iPhoto’s model is very different from Canvas’s either.

Of course one could actually build a model of a jpeg in AppleScript because
its Turing Complete but it would be very hard.

I don’t know about emacs, but with Excel you can have an application create
an instance of Excel, and manipulate it, or you have Excel load a script and
execute it internally. Or both.

Yep.

Languages like
Ruby and Perl are concerned more with data manipulation. The other group
strive to be more of a JCL. There competitors are bash, tcsh, etc
more than
Ruby.

Well, I’m inclined to say that Ruby (and maybe Perl) is concerned with
object manipulation. Sometimes the object need be defined in Ruby. Other
times the object can be an external thing with a suitable API.

I buy this on Windows and Mac. On general *nix there isn’t a good method for
discovering the APIs of external objects, AFAICT.

What fuels my enthusiasm is seeing (non-Geek) graphic artists at my wife’s
office doing useful work with AppleScript, the COBOL of scripting
languages.

The language itself has some disfeatures but they find it easy to
work with
because it presents an object hierarchy that’s already familiar to them.
WorkBooks contain sheets contain ranges contain cells… They
don’t have to
create the objects, they already understand them from messing around with
spreadsheets. So if they get assigned to get some numbers from a corporate
database and manipulate them in Excel and present the results in a Word
document, they will do it by hand three of for times and then just script
the whole process.

Think about how much easier that would be with Ruby.

I’ve written a fair amount of VBA code for Word, and would love to be able
to use Ruby instead of a Visual Basic variant.

You actually can do this now in Mac Word.

···

On 7/30/02 3:22 PM, “JamesBritt” james@jamesbritt.com wrote:

Those who write clearly have readers, those who write obscurely have
commentators. -Albert Camus, writer and philosopher (1913-1960)

[snip]

What you say is true, Ned. But if I am not
mistaken, what he wants to do is the “inside
out” version of that – i.e., he wants to
write code that runs within Word, not code
that runs externally and manipulates Word.

This other case can be handled (I think) by
ActiveScriptRuby.

By analogy, you can write a Ruby program that
will manipulate IE, (by browsing to a specific
page, for instance). But to get IE to understand
Ruby (as it understands Javascript), it takes
ASR.

But if I’m mistaken in what he means: Then
Win32OLE should be fine (or even RubyCOM by
Ralph Mason, which I’ve used before).

Hal

···

----- Original Message -----
From: “Ned Konz” ned@bike-nomad.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, July 30, 2002 5:49 PM
Subject: Re: ActiveRubyScript and RubyAEOSA

On Tuesday 30 July 2002 03:22 pm, JamesBritt wrote:

I’ve written a fair amount of VBA code for Word, and would love to
be able to use Ruby instead of a Visual Basic variant.

Well, there’s Win32OLE:

http://homepage1.nifty.com/markey/ruby/win32ole/index_e.html

It looks like a translated version of the Perl module with a similar
name.

The example given there is an Excel one:

require ‘win32ole’

True, but I want to open up the VBA IDE in Word and enter Ruby code, not
VBA, though I don’t see that happening anytime soon.

James

···

On Tuesday 30 July 2002 03:22 pm, JamesBritt wrote:

I’ve written a fair amount of VBA code for Word, and would love to
be able to use Ruby instead of a Visual Basic variant.

Well, there’s Win32OLE:

http://homepage1.nifty.com/markey/ruby/win32ole/index_e.html

You all might want to look at this as well…more along the lines of
what Chris was first talking about:

Ralph Mason is its author…don’t know his current status.

-rich

From: JamesBritt [mailto:james@jamesbritt.com]
Sent: Tuesday, July 30, 2002 7:06 PM
To: ruby-talk ML
Subject: RE: ActiveRubyScript and RubyAEOSA

I’ve written a fair amount of VBA code for Word, and would love to
be able to use Ruby instead of a Visual Basic variant.

Well, there’s Win32OLE:

http://homepage1.nifty.com/markey/ruby/win32ole/index_e.html

True, but I want to open up the VBA IDE in Word and enter Ruby code,
not

···

-----Original Message-----

On Tuesday 30 July 2002 03:22 pm, JamesBritt wrote:
VBA, though I don’t see that happening anytime soon.

James

You all might want to look at this as well…more along the lines of
what Chris was first talking about:

http://www.geocities.com/masonralph/rubycomdoc.html

Ralph Mason is its author…don’t know his current status.

Oh, thank you! I had been looking for this a while back. I remembered
seeing it discussed in ruby-talk, but didn’t recall enough detail to search
and find it.

James

···

-rich