Hello Scott,
Lothar,
I would
use ExErb, except for one thing. I'm a Linux user. I have 4 computers
and the target development board at my disposal. All of them run Linux.
I wont lecture you on the usual Linux vs. Windows stuff, that's a
waste of your time and mine. But yeah, exerb really wont help me in
this case.
Okay then we need to port the stuff to Linux, it's not so difficult to
generate a ELF header and store the node tree of preparsed source
code. Why not dropping a line to the maintainer.
Of course the real pain with deployment on Linux is the library isssue that
is the some for C programs as for interpreters (which are C programs).
Until the major distributions still kill the ideas of the file
hierarchy standard by adding version tags to libc there will be no
good solution - other then using MacOS X.
But of course this will not help you very much for reducing the
startup time. But here some other clever techniques may help - like a
"require" on demand instead putting all of them on the top of a
source file.
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
Sean Russell wrote:
David Ross <drossruby@yahoo.com> wrote in message
news:<20040719161148.44048.qmail@web21529.mail.yahoo.com>...
> I do not know if I can look at the source to make a
> specification, then start working on a compiler that
> is under a BSD license. Most of the code is copyright
> by Matz and the companies that hired him. I do not
> want any legal complications. --David
Hey David,
I just wanted to let you know that I'm all for you exploring this
(Ruby-to-native compiler). I'm a little distressed that the first
responses that you got to your posting were "it can't be done," "it
will be harder than you think," "you won't get the performance gain
you expect," etc., etc.. I think a native Ruby compiler *is*
possible, although some aspects will be difficult, and I'd *love* to
see a good one.
I'd love to see one two!
What might be even better would a Ruby compiler for the .NET CLR -- now that
Mono has reached 1.0 that would immediately make it viable on Windows and
Linux.
Curt
Hello Bill,
Hi,
From: "Lothar Scholz" <mailinglists@scriptolutions.com>
> it possible to distribute the application without distributing the
> source code to it. That isn't so important for us, but it may be for
> others.
Use ExErb, in version 3.2 it stores the node trees.
I read this with much interest (!) ... However I just
tried out exerb-3.2.0 and searched through the binary
and was able to see my source code there. I was hoping
that if it stores the node trees, my source code would
no longer be in ASCII form. Did I misunderstand?
I must say i didn't look at it exactly but in the source code of
exerb-3.2.0 there is a subdirectory "bruby-0.0.7" which contains the
code to read/write the binary node tree.
So i thought that there is some way to use it. But a short grep shows
that no file includes anything from "bruby". So i can't say if this is
a coming or a going feature.
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
Ara.T.Howard wrote:
how about a simple 'ruby-interpreter' server written as a drb object. the
server could simply start ruby via a fork'd process or via a pipe, and run the
code in question; something similar in spirit to mod_ruby. you would
eliminate the start up costs only with this method, but your post seem to
suggest this might be o.k./sufficient
Cool idea. It's been in the back of my mind to do something like that. The ruby daemon doesn't even have to use DRb--it could just listen on a socket for the name of a .rb file to load. A ruby daemon would make it more efficient to use ruby programs as "commands" in shell scripts (not that its really inefficient now). Also, it would reduce memory usage if you've got a lot of scripts running at the same time.
One way to use this would be to send the server a .rb file that loads up a bunch of libs and then daemonizes goes into the server code again, creating a specialized ruby daemon that has already loaded the stuff that takes some time. I use a similar approach for development already by having a "puts; gets; fork" loop after each major stage in loading libs and data. But the daemon approach would make it easier to start separate forked apps from different command lines.
IIRC Robert Feldt's student should end his 'ruby on the clr' project
in this days 
···
il Wed, 21 Jul 2004 02:24:13 +0900, "Curt Hibbs" <curt@hibbs.com> ha scritto::
I'd love to see one two!
What might be even better would a Ruby compiler for the .NET CLR -- now that
Mono has reached 1.0 that would immediately make it viable on Windows and
Linux.
This chunk (from 'src/mod_bruby/mod_bruby.cpp' in the exerb-3.2.0
distribution) would seem suggestive:
static VALUE
mod_bruby_load_code(const char *code, const DWORD size, const char *filename)
{
::rb_raise(rb_eLoadError, "not implemented");
return Qnil;
}
So I think that the bruby hooks may indeed be unfinished.
In general, while I've used Exerb on a number of projects and found it
to be very convenient for simple distributions of Ruby apps, it lacks
a number of features that an ideal packaging tool would have for my
uses.
What *I* really want is just a quick way to statically link a set of
extensions into a custom Ruby interpreter. Ideally, it would also
include an arbitrary chunk of Ruby code (either as a node tree, or
just a constant C string) to be evaluated at startup. I don't need
obfuscation, just convenient packaging.
If I had the time to work on it right now, I'd probably be hacking
something up to do just that; as it is, though, all I can do is
complain and hope someone else will do it first.
Lennon
Joel VanderWerf wrote:
Ara.T.Howard wrote:
how about a simple 'ruby-interpreter' server written as a drb object. the
server could simply start ruby via a fork'd process or via a pipe, and run the
code in question; something similar in spirit to mod_ruby. you would
eliminate the start up costs only with this method, but your post seem to
suggest this might be o.k./sufficient
Cool idea. It's been in the back of my mind to do something like that. The ruby daemon doesn't even have to use DRb--it could just listen on a socket for the name of a .rb file to load. A ruby daemon would make it more efficient to use ruby programs as "commands" in shell scripts (not that its really inefficient now). Also, it would reduce memory usage if you've got a lot of scripts running at the same time.
One way to use this would be to send the server a .rb file that loads up a bunch of libs and then daemonizes goes into the server code again, creating a specialized ruby daemon that has already loaded the stuff that takes some time. I use a similar approach for development already by having a "puts; gets; fork" loop after each major stage in loading libs and data. But the daemon approach would make it easier to start separate forked apps from different command lines.
While this is a good idea, and actually may prove useful for me in the future, it will not help me in this situation. Since all the ruby programs will start when the system boots and they never restart. The time saved when starting the ruby programs would be spent starting the daemon so it would even out, and possible even take longer. It's not a big deal really. The normal speed is adequate for the application. It would just be nice to make it a little faster.
-Scott
Lennon Day-Reynolds wrote:
What *I* really want is just a quick way to statically link a set of
extensions into a custom Ruby interpreter. Ideally, it would also
include an arbitrary chunk of Ruby code (either as a node tree, or
just a constant C string) to be evaluated at startup. I don't need
obfuscation, just convenient packaging.
Don't know whether this qualifies as quick, but why not just put your extension in ext/ and build it statically? You have to edit ext/Setup to refer to your extension, so that the build process knows you want to build it statically. For details, grep for Setup in README.EXT.
For QNX, I've ended up doing this for all extensions I use, both stdlib and otherwise, because ruby on QNX seems to have trouble loading dynamically.
But in any case, it has the effect of creating a custom ruby interpreter with your libraries (well, the .so part anyway) built in. You still have to load lib/ stuff separately, of course, so this may not help you.
I guess you could write a C extension that contains a huge string, which has all your ruby code, and just evals that string at startup.
Joel,
That's precisely what I was looking into; however, it would be nice to
have a somewhat more automatic way of doing all that housekeeping.
Basically, I want to just define the modules I'm using, and have a
driver script handle the source tree setup, building, and linking.
Lennon
···
On Thu, 29 Jul 2004 07:14:26 +0900, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:
Lennon Day-Reynolds wrote:
> What *I* really want is just a quick way to statically link a set of
> extensions into a custom Ruby interpreter. Ideally, it would also
> include an arbitrary chunk of Ruby code (either as a node tree, or
> just a constant C string) to be evaluated at startup. I don't need
> obfuscation, just convenient packaging.
Don't know whether this qualifies as quick, but why not just put your
extension in ext/ and build it statically? You have to edit ext/Setup to
refer to your extension, so that the build process knows you want to
build it statically. For details, grep for Setup in README.EXT.
For QNX, I've ended up doing this for all extensions I use, both stdlib
and otherwise, because ruby on QNX seems to have trouble loading
dynamically.
But in any case, it has the effect of creating a custom ruby interpreter
with your libraries (well, the .so part anyway) built in. You still have
to load lib/ stuff separately, of course, so this may not help you.
I guess you could write a C extension that contains a huge string, which
has all your ruby code, and just evals that string at startup.