[ANN] AllInOneRuby

[Erik Veenstra]

I'm pleased to announce the birth of AllInOneRuby.

As you know, Ruby has to be installed, either by unzipping a
ZIP-file, or by running an installer. Only then, you can run a
script. Well, not anymore!

AllInOneRuby creates an executable that includes both the Ruby
interpreter and the runtime libraries. Why? Because it's
sometimes not easy, or possible, or desirable, or allowed to do
a complete Ruby installation. That's where AllInOneRuby comes
in. I always have a USB-memory stick with AllInOneRuby in my
pocket.

A "just-in-time and temporary installation of Ruby"...

Because of the gathering of files from your own Ruby
installation, AllInOneRuby can only run on Windows (yet). And
when I say Windows, I mean both Windows (RubyInstaller, MinGW
and MSWin32) and Cygwin. But the generated exe under Cygwin is
very, very big, because its exe's are very big (static?) and it
includes cygwin1.dll, so it can run on machines without Cygwin.

More information and download on
http://www.erikveen.dds.nl/allinoneruby/ .

gegroet,
Erik V.

 

[Lothar Scholz]

Hello Erik,

EV> I'm pleased to announce the birth of AllInOneRuby.

EV> As you know, Ruby has to be installed, either by unzipping a
EV> ZIP-file, or by running an installer. Only then, you can run a
EV> script. Well, not anymore!

What's the difference to "rubyscript" or "exerb" ?
Both seem to do the same thing and both run (only) on windows ?

 

[Erik Veenstra]

What's the difference to "rubyscript" or "exerb" ? Both seem
to do the same thing and both run (only) on windows ?

RubyScript2Exe includes an application (your script) and only
parts of the rubylib tree (it's stripped specifically for that
application).

AllInOneRuby contains a complete Ruby installation: it includes
no application, but it does include the complete rubylib tree.
You can use it like the ruby that's already installed on your
system to run any script.

In other words: the executable, generated with RubyScript2Exe,
is an application; the one generated with AllInOneRuby "is"
Ruby.

gegroet,
Erik V.

 

[James Britt]

AllInOneRuby contains a complete Ruby installation: it includes
no application, but it does include the complete rubylib tree.
You can use it like the ruby that's already installed on your
system to run any script.

In other words: the executable, generated with RubyScript2Exe,
is an application; the one generated with AllInOneRuby "is"
Ruby.

So, if I install AIOR, I can then associate Ruby programs with AIOR, and
then run them the same way as I would with a conventional Ruby installation?

Or bundle AIOR with some Ruby GUI app, and kick the whole thing off with
a .bat file that launches AIOR, passing in my Ruby application?


James

 

[Lothar Scholz]

Hello Erik,


EV> In other words: the executable, generated with RubyScript2Exe,
EV> is an application; the one generated with AllInOneRuby "is"
EV> Ruby.

How long is the startup time for a simple FOX application or a hello
world ? Seems like a huge overhead to the already slow starting
process. Did you measure this ?

And a technical questions: Do you support the Win32 API of named jobs
to kill the process tree (on Win2K/WinXP) or the started ruby script
and do the cleanup ?

 

[Erik Veenstra]

So, if I install AIOR, I can then associate Ruby programs
with AIOR, and then run them the same way as I would with a
conventional Ruby installation?

I did...

Or bundle AIOR with some Ruby GUI app, and kick the whole
thing off with a .bat file that launches AIOR, passing in my
Ruby application?

Don't mix the term "Ruby" and the term "Ruby with all the other
stuff" (like Fox libraries, TCL/TK libraries, etc). I'm talking
about "Ruby".

I'm working on a couple of things, for both RubyScript2Exe and
AllInOneRuby, to handle additions as well. Right now, I can
handle the bin/*.dll, if they are part of lib/**/*.so . For
example, tcltklib.so needs tcl83.dll and tk83.dll .

But that's still in the pipeline, not yet released...

gegroet,
Erik V.

 

[Erik Veenstra]

How long is the startup time for a simple FOX application or
a hello world ? Seems like a huge overhead to the already
slow starting process. Did you measure this ?

At the office (XP, 512MB, >2000MHz), the overhead is a little
bit over 1 second for the "Hello World!" thing. Not that bad
when starting a GUI application...

And a technical questions: Do you support the Win32 API of
named jobs to kill the process tree (on Win2K/WinXP) or the
started ruby script and do the cleanup ?

When you kill the Ruby script (or better: the Ruby
interpreter), the cleanup will be performed. When you kill
allinoneruby.exe itself, well, there's no time left for
cleaning up things... I still need to do some trapping of
interrupts in EEE. Never done it before in Pascal.

gegroet,
Erik V.

 

[James Britt]

Don't mix the term "Ruby" and the term "Ruby with all the other
stuff" (like Fox libraries, TCL/TK libraries, etc). I'm talking
about "Ruby".

I'm having a hard time, then picturing a concrete use for this.

Can you give some examples where this works better than, say, exerb?

Thanks,


James

 

[Erik Veenstra]

I'm having a hard time, then picturing a concrete use for
this.

Hmmm... I made it because I had concrete use for it. Not the
other way aroung...

An example. My boss expects me to program on his IBM mainframe.
That's where he pays me for. Nowadays, 3270-emulators are used
as terminals, instead of the good old green screens... Big Blue
gave us HLLAPI (High Level Language API), which is a way to
program the interaction with the emulator, although the
emulator still thinks it's a human-being that is in control.
Over the years, I made a lot of scripts to cope with tests,
quick downloads, ditto upload, log filtering, etc. My
colleagues are not stupid and say "That's nice! Can I have it."
So they need Ruby, but not necessarily a full blown
installation. Besides that, it's not possible to install
anything on our machines. There's not much more than a network
share and a tempdir. So I bound .rb to H:\allinoneruby.exe ...

Can you give some examples where this works better than, say,
exerb?

Did I say it was better?... At least, it's simpler...

gegroet,
Erik V.

 

[James Britt]

Hmmm... I made it because I had concrete use for it. Not the
other way aroung...

Lots of stuff happens that way.

An example. My boss expects me to program on his IBM mainframe.
That's where he pays me for. Nowadays, 3270-emulators are used
as terminals, instead of the good old green screens... Big Blue
gave us HLLAPI (High Level Language API), which is a way to
program the interaction with the emulator, although the
emulator still thinks it's a human-being that is in control.
Over the years, I made a lot of scripts to cope with tests,
quick downloads, ditto upload, log filtering, etc. My
colleagues are not stupid and say "That's nice! Can I have it."
So they need Ruby, but not necessarily a full blown
installation. Besides that, it's not possible to install
anything on our machines. There's not much more than a network
share and a tempdir. So I bound .rb to H:\allinoneruby.exe ...

H: is the network share, and H:\allinoneruby.exe works better than
H:\ruby\bin\ruby.exe ?

Did I say it was better?...

Not that I'm aware of. I would hazard a guess, though, that if you use
AllInOneRuby instead of exerb then you might think it was better, at
least for some specific tasks. So I was curious what those tasks might be.

At least, it's simpler...

That's not clear to me, but I gather at this point I should go try it
myself.

Thanks.


James

 

[Erik Veenstra]

H: is the network share, and H:\allinoneruby.exe works better
than H:\ruby\bin\ruby.exe ?

879 files take a lot more space than just one file. Especially
when it's NTFS...

I'll check it on my USB (VFAT). Just a minute... Ruby (MinGW)
consumes 22480 KB and AllInOneRuby eats 4672 MB. There you are!

Not that I'm aware of. I would hazard a guess, though, that
if you use AllInOneRuby instead of exerb then you might think
it was better, at least for some specific tasks. So I was
curious what those tasks might be.

It's better for my understanding of Ruby in general..

That's not clear to me, but I gather at this point I should
go try it myself.

I never managed to create an exe with Exerb. OK, I didn't try
very hard...

gegroet,
Erik V.

 

[Lothar Scholz]

Hello Erik,


EV> Hmmm... I made it because I had concrete use for it. Not the
EV> other way aroung...

EV> An example. My boss expects me to program on his IBM mainframe.
EV> That's where he pays me for. Nowadays, 3270-emulators are used
EV> as terminals, instead of the good old green screens... Big Blue
EV> gave us HLLAPI (High Level Language API), which is a way to
EV> program the interaction with the emulator, although the
EV> emulator still thinks it's a human-being that is in control.
EV> Over the years, I made a lot of scripts to cope with tests,
EV> quick downloads, ditto upload, log filtering, etc. My
EV> colleagues are not stupid and say "That's nice! Can I have it."
EV> So they need Ruby, but not necessarily a full blown
EV> installation. Besides that, it's not possible to install
EV> anything on our machines. There's not much more than a network
EV> share and a tempdir. So I bound .rb to H:\allinoneruby.exe ...

EV> Did I say it was better?... At least, it's simpler...

Simpler ? I don't think so. Not for the creation side because you
still have to specify the files you want. And also not for the user
side where more things can happen (out of disk space, wrong env
variables, no access rights).

But it has one real advantage. In systems where you need to start a
few scripts maybe with 'popen("ruby.exe")' from the the main script,
the disk overhead will be much much less.

But to be honest, in such cases i prefer an "setup.exe" file. In fact
i don't think that the 'my friends want only one exe file' argument is
is really important. The difference between a generated *.exe and a
setup.exe is not so big.

 

[James Britt]

EV> [... ] At least, it's simpler...

Simpler ? I don't think so. Not for the creation side because you
still have to specify the files you want. And also not for the user
side where more things can happen (out of disk space, wrong env
variables, no access rights).

But it has one real advantage. In systems where you need to start a
few scripts maybe with 'popen("ruby.exe")' from the the main script,
the disk overhead will be much much less.

But to be honest, in such cases i prefer an "setup.exe" file. In fact
i don't think that the 'my friends want only one exe file' argument is
is really important. The difference between a generated *.exe and a
setup.exe is not so big.

I can see certain advantages to the AIOR approach. One is
psychological. Sys admins or IT mangers may be less hostile to a single
(albeit relatively large) application file than to a cluster of
directories and files. Aside from taking less disk space, it "looks"
smaller. Hey, it's just one file.


Anyways, thanks Erik for helping me understand this better, and for
making it available.

I've only played a bit with exerb, so I don't know that I could make a
meaningful comparison. But AIOR looks quite interesting.


james

 

[Xiangrong Fang]

Hi,

Just by browsing the AIOR home page... I think it is NOT simpler OR more
complicate than EXERB. They are 2 different application. AIOR as said,
is only "Ruby", i.e., it makes the *COMPLETE* Ruby environment in one
file, but your script is NOT included in this file. On the contrary,
EXERB makes your application a single EXE, but it is NOT a complete ruby
installation.

--
Xiangrong Fang <[email protected]>

EV> [... ] At least, it's simpler...

Simpler ? I don't think so. Not for the creation side because you
still have to specify the files you want. And also not for the user
side where more things can happen (out of disk space, wrong env
variables, no access rights).

But it has one real advantage. In systems where you need to start a
few scripts maybe with 'popen("ruby.exe")' from the the main script,
the disk overhead will be much much less.

But to be honest, in such cases i prefer an "setup.exe" file. In fact
i don't think that the 'my friends want only one exe file' argument is
is really important. The difference between a generated *.exe and a
setup.exe is not so big.

I can see certain advantages to the AIOR approach. One is
psychological. Sys admins or IT mangers may be less hostile to a single
(albeit relatively large) application file than to a cluster of
directories and files. Aside from taking less disk space, it "looks"
smaller. Hey, it's just one file.


Anyways, thanks Erik for helping me understand this better, and for
making it available.

I've only played a bit with exerb, so I don't know that I could make a
meaningful comparison. But AIOR looks quite interesting.


james

 

[Erik Veenstra]

Just by browsing the AIOR home page... I think it is NOT
simpler OR more complicate than EXERB. They are 2 different
application. AIOR as said, is only "Ruby", i.e., it makes the
*COMPLETE* Ruby environment in one file, but your script is
NOT included in this file. On the contrary, EXERB makes your
application a single EXE, but it is NOT a complete ruby
installation.

I made both RubyScript2Exe and AllInOneRuby, because they are
not the same. Exerb is more like RubyScript2Exe, AllInOneRuby
is different.

gegroet,
Erik V.