Much of the discussion concerning Ruby focuses on the language itself
and on how enjoyable it is to program in.  I'm still a Ruby novice but
I agree with these sentiments.  However, I have not heard much
discussion about the quality of the Ruby VM implementation.  How
good/mature/production ready is it?  So far I've used it for simple
development tasks/utilities but not in production.

I was wondering why noone responded (besides the fact that I mistakenly
asked about the quality of the Ruby VM when its actually an
interpreter)?   I considered the question an earnest one and did not
intend to be trolling.

Interestingly, Avi Bryant has a post on his blog
(http://smallthought.com/avi/?p=8) suggesting that Cincom make it
possible to run Ruby in their Smalltalk VM.

Gary Blomquist

GJB wrote:
> I was wondering why noone responded (besides the fact that I mistakenly
> asked about the quality of the Ruby VM when its actually an
> interpreter)?   I considered the question an earnest one and did not
> intend to be trolling.

Timing?  Most posts, (even trolls :) )  get a prompt response on this 
list, but every so often a message just gets lost in a swirl of threads 
and off-list activity.

Offhand, I'd say that after 13 years of development the Ruby interpreter 
is pretty robust.


James
-- 

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools

From: "GJB" <gjblomquist@hotmail.com>
>
>I was wondering why noone responded (besides the fact that I mistakenly
> asked about the quality of the Ruby VM when its actually an
> interpreter)?   I considered the question an earnest one and did not
> intend to be trolling.

Not sure what particular measure of quality you were asking
about - but for what it's worth, I run some multi-user quake
server admin software written in Ruby that consistently operates
for hundreds of days of uptime, until I eventually reboot the
server or quit the application intentionally.

It uses TCP and UDP networking, and keeps a fairly large dynamic
in-memory data structure (100 megs or so)... I also dynamically
reload code modules without quitting the application on a periodic
basis, when adding simple new features or making bug fixes.

I've been pleased with Ruby's stability so far, if that helps.


Regards,

Bill

On Dec 1, 2005, at 7:23 PM, Bill Kelly wrote:

> It uses TCP and UDP networking, and keeps a fairly large dynamic
> in-memory data structure (100 megs or so)... I also dynamically
> reload code modules without quitting the application on a periodic
> basis, when adding simple new features or making bug fixes.

Hi Bill,

Just wondering if you're able to share more about your application?   
It sounds interesting.

Thanks,
Steve

Hi Stephen,

From: "Stephen Waits" <steve@waits.net>
> 
>> It uses TCP and UDP networking, and keeps a fairly large dynamic
>> in-memory data structure (100 megs or so)... I also dynamically
>> reload code modules without quitting the application on a periodic
>> basis, when adding simple new features or making bug fixes.
> 
> Just wondering if you're able to share more about your application?   
> It sounds interesting.

Thanks - well, technically there's a rubyforge project:
http://rubyforge.org/projects/dorkbuster/
But the documentation is very meager / nonexistent.

Also, I've learned a bit about Ruby since I first wrote it,
so I wouldn't recommend some parts as shining examples of
good idiomatic ruby code; especially the parts using threads
and mutexes.  (Some modules could be simplified quite a bit.)

I'd design some parts of it rather differently if I were to
do it over. . . . Etc.

Pragmatically speaking, though, it works.  :)  Multiple admins
are logged into it at any given time to monitor server activity
and watch out for cheaters.  We've been using it for about three
years now.

A brief overview of what it is/isn't:

  - Allows multiple admins to log in over telnet and monitor
    quake 2 servers, and issue bot scans and rcon commands
    without admins knowing the actual server rcon password.

  - Provides an optional "windowed" interface using ANSI
    telnet scrolling regions, and supports line editing and
    command history.  (No tab-completion, yet.)
    Windows show admin chat, live server status, and raw
    server log data.

  - Keeps a database linking player names to player IP's,
    and shows a sorted list of most recently/frequently
    used names for each player connected.
    The database is currently stored in-memory (checkpointed
    to disk on a periodic basis), and can get quite large.
    I've intended to switch over to a traditional database
    engine (sqlite/mysql/postgresql).

  - Provides hooks for "droids" (like IRC bots) to connect
    to the admin system and provide additional functionality,
    such as bot scans or running player-driven map rotations.
    (The map rotation droid is provided with the project.
    The bot scanners are private, as it's difficult to stay
    ahead of the cheaters.)

  - Currently, no *automatic* cheat-detection scans are 
    performed.  (We use a third-party module on our servers,
    q2admin, to provide some level of cheat auto-detection.)
    Strange as it may sound, the lack of automated scans in
    dorkbuster is somewhat by design.  I think the key reason
    dorkbuster is actually effective is the presence of
    multiple human admins monitoring the servers pretty
    much around the clock.  So db's design has been focused
    on providing a collaborative environment for live admins.
    Some automated scans might be nice - but not if the result
    were to reduce the level of human participation.  So we'll
    proceed carefully. . . .

  - As yet, no way to monitor multiple servers from a single
    telnet window.  This is at the top of the to-do list.


Thanks for your interest.  I'm happy to answer questions either
on or off-list, as appropriate.


Regards,

Bill

GJB wrote:

>I was wondering why noone responded (besides the fact that I mistakenly
>asked about the quality of the Ruby VM when its actually an
>interpreter)?   I considered the question an earnest one and did not
>intend to be trolling.
>
>Interestingly, Avi Bryant has a post on his blog
>(http://smallthought.com/avi/?p=8) suggesting that Cincom make it
>possible to run Ruby in their Smalltalk VM.
>
>Gary Blomquist
>  
>

The problem with your question is that we have no idea why you think 
that Ruby is not suitable for production. How is the quality of the VM 
lacking?

Ruby is used in production, there are big, well used systems written in 
Ruby. Which all goes to make you sound like a troll and would account 
for people ignoring you.

On Dec 1, 2005, at 10:23 PM, Bill Kelly wrote:

> Thanks for your interest.  I'm happy to answer questions either
> on or off-list, as appropriate.

Sounds cool Bill, thanks for sharing.

--Steve