bk clone bk://ftp.rubyx.org/rubyx
cd rubyx
bk co

 
mkdir /my/rubyx/dir  (or something like)
./rubyx --root /my/rubyx/dir --download base net disk (for the basics)
./rubyx --root /my/rubyx/dir --download all (for everything)

Homepage: battery.rubyforge.org/

Download: rubyforge.org/frs/?group_id=268&release_id=531

 The Ruby Production Archive (RPA) will provide packages of Ruby
 libraries and programs in a form that allows production use, engineered
 through a stringent process resembling FreeBSD's or Debian's.

 rpa-base is a port/package manager designed to support RPA. Its scope and
 purposes are different to those of other systems like RubyGems.

 rpa-base 0.1.0 is now available on http://rpa-base.rubyforge.org .
 Please keep in mind that this is *not* a RPA release (that is, a release
 of the repository) but just a release of the rpa-base tool itself. We
 have provided several sample ports/packages for testing purposes, but
 they don't formally belong to RPA. Read below for information on the
 libs/apps packaged so far.

 rpa-base requires Ruby 1.8.1 (certainly 1.8 at least, it might work on
 1.8.0); it has been tested on several Linux distributions, FreeBSD and
 win32. We would appreciate feedback (both positive and negative) under
 those or any other architecture.

 It takes but a couple minutes to install and will allow you to do

 rpa install instiki ruvi

 ;-)
 (NOTE: ruvi, the cool pure-Ruby vim clone, won't work on win32)

 Features
 ========

 rpa-base is a port/package manager designed to support RPA's client-side
 package management. You can think of it as RPA's apt-get + dpkg. It
 features the following (working right now):

  * sane dependency management: rpa-base installs dependencies as needed,
    keeps track of reverse dependencies on uninstall, and will remove no
    longer needed dependencies
  * atomic (de)installs: operations on the local RPA installation are atomic
    transactions; the system has been designed to survive ruby crashes (OS
    crashes too on POSIX systems)
  * modular, extensible design: the 2-phase install is similar to FreeBSD and
    Debian's package creation; rpa-base packages need not be restricted
    to installing everything under a single directory ("1 package, 1 dir"
    paradigm)
  * rdoc integration: RDoc documentation for libraries is generated at install
    time (currently disabled on win32)
  * ri integration: ri data files are generated for all the libraries managed
    by RPA; you can access this information with ri-rpa (currently disabled on
    win32)
  * handling C extensions: if you have the required C toolchain, rpa-base can
    compile extensions as needed
  * unit testing: when a library is installed, its unit tests are run; the
    installation is canceled if they don't pass

 > PPS:
 > I remember working for a company, where it took the make utility3/4 of
 > an hour to figure out *what* to compile, and the compilers a day to
 > compile- it was a C++ project b.t.w. which was canceled and replaced by
 > a Smalltalk program after they spent 50man-years on a non-working
 > program - so much for non-toy languages !

Yeah and I just spent 3 days in an inhouse J2EE workshop held by one of our chief architects. We spent most of our time fighting with the tools. Changed setting over and over. The goal of the workshop was to demonstrate how to insert a row into an oracle table. At the end of the 2 days the table was still empty. Another non-toy language.

I have written two small apps (apx 5000 LOC) one in squak and one in stx. It was a dream. Got up in the morning and fixed two or three bugs before breakfast. You can only do this with a real cool environment.

German English

It’s probably because in order to post in the Java ng he has to be 10x as verbose as in the Smalltalk ng.

He probably has to declare himself, cast himself, wrap himself in a try catch block, bubble up any exceptions, use some external iterators, implement some interfaces, and wrap up his primitives in real objects. Maybe after auto-boxing and generics are supported, he’ll only have to post 7 or 8x as often.

Don’t worry James, we appreciate and understand your terseness over here. ;-)

I’m still waiting for some more, so check back periodically to see updates.

 GM> Are there any accepted or already practiced ways for
 GM> companies to prevent Ruby source code from being read by potential
 GM> competitors? I can vaguely imagine redefining Ruby's
 GM> "require"-type methods so they can include zipped and passworded
 GM> ".rbz" files, say. Or using exerb (except for UNIX and without the
 GM> potential license issues).

 GM> I want to use Ruby at work but this is one of those "steps to
 GM> convincing your boss to use Ruby" I need to go through.

Just look at the "eval.c" file, i think the require is defined there and then write your hook. Or write a dll/so and add embedd your rb files as large c strings there (using maybe the "wrap" tool from the Fox Toolkit) and then do rb_eval_string("my c file"). After this protect the dll with something like "armadillo" (use google to find the URL). This works perfectly for me.