I can’t speak for others, but I would be interested in such a thing. But not
for having a true native machine code executable. But rather for ease of
distribution. It would be nice to be able to easily distribute small to medium
sized Ruby apps without installing the development tools on a target machine.
I played with the exerb stuff a few months ago and found it primitive, but
pretty cool nonetheless.
I agree completely. It’s probably a tad difficult, but the lack of such
a facility causes me to keep looking at Python, and it’s a serious
component of why I’m doing my current project in Java at work.
Truthfully, one of the things that I look at about Python is Pyrex, a
compiler for easily blending C and Python. I have no idea how well it
works, but the concept is so intriguing! (But I’d still need to be able
to distribute the final package.)
I can’t speak for others, but I would be interested in such a thing. But not
for having a true native machine code executable. But rather for ease of
distribution. …
Christopher J. Meisenzahl CPS, CSTE
Senior Software Testing Consultant
Spherion christopher.j.meisenzahl@citicorp.com
I’d also like to see compiler for the purpose of ease of distribution.
The Perl guys are working on Parrot. Does anyone know how exactly Parrot
works? Is it akin to Java’s JVM? I ask because, if it is, we could
compile Ruby for the Parrot bytecode instead of machine code. Then Ruby
could be “compile once, run everywhere”, a la Java.
Another thought is to compile Ruby to the .NET CLI. The Mono project is
making good progress. If it catches on in Linuxland, thisf might be an
option.
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137
I can’t speak for others, but I would be interested in such a thing. But not
for having a true native machine code executable. But rather for ease of
distribution. …
Christopher J. Meisenzahl CPS, CSTE
Senior Software Testing Consultant
Spherion christopher.j.meisenzahl@citicorp.com
I agree completely. It’s probably a tad difficult, but the lack of such
a facility causes me to keep looking at Python, and it’s a serious
component of why I’m doing my current project in Java at work.
Truthfully, one of the things that I look at about Python is Pyrex, a
compiler for easily blending C and Python. I have no idea how well it
works, but the concept is so intriguing! (But I’d still need to be able
to distribute the final package.)
Exactly the same here. The first time I became aware of Pyrex, I wanted
to go back to Python immediately. But after I thought further on the
things that made me switch from Python to Ruby in the first place, I
decided to stay in Ruby. My position now is just to wait in the hope that
some day a Ruby Pyrex will become a reality…
I can’t speak for others, but I would be interested in such a thing. But not
for having a true native machine code executable. But rather for ease of
distribution. …
I agree completely. It’s probably a tad difficult, but the lack of such
a facility causes me to keep looking at Python, and it’s a serious
component of why I’m doing my current project in Java at work.
Truthfully, one of the things that I look at about Python is Pyrex, a
compiler for easily blending C and Python. I have no idea how well it
works, but the concept is so intriguing! (But I’d still need to be able
to distribute the final package.)
What I’m curious about is that if you use a VM don’t you still have to
make sure the VM is distributed? What is the comparative size of a given
VM vs interpreter?
Now if you use Java, you have the best chance of the user already
having the correct VM on their machine. BTW, since you mention Java,
uou might be interested in the jruby project.
···
On Thu, Dec 19, 2002 at 07:59:49AM +0900, Daniel Carrera wrote:
I’d also like to see compiler for the purpose of ease of distribution.
The Perl guys are working on Parrot. Does anyone know how exactly Parrot
works? Is it akin to Java’s JVM? I ask because, if it is, we could
compile Ruby for the Parrot bytecode instead of machine code. Then Ruby
could be “compile once, run everywhere”, a la Java.
Another thought is to compile Ruby to the?.NET CLI. The Mono project is
making good progress. If it catches on in Linuxland, thisf might be an
option.
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137
My coworker keeps hassling me about how great Python is and how I should
try it. Personally, I never got past the stupid indentation bit. I’m a
perl guy, nothing like that for me. But, out of interest, could you tell
me what about ruby made you switch?
db
···
On Thu, Dec 19, 2002 at 09:12:41AM +0900, William Djaja Tjokroaminata wrote:
I can’t speak for others, but I would be interested in such a thing. But not
for having a true native machine code executable. But rather for ease of
distribution. …
I agree completely. It’s probably a tad difficult, but the lack of such
a facility causes me to keep looking at Python, and it’s a serious
component of why I’m doing my current project in Java at work.
Truthfully, one of the things that I look at about Python is Pyrex, a
compiler for easily blending C and Python. I have no idea how well it
works, but the concept is so intriguing! (But I’d still need to be able
to distribute the final package.)
Hi,
Exactly the same here. The first time I became aware of Pyrex, I wanted
to go back to Python immediately. But after I thought further on the
things that made me switch from Python to Ruby in the first place, I
decided to stay in Ruby. My position now is just to wait in the hope that
some day a Ruby Pyrex will become a reality…
Regards,
Bill
–
A.D. 1844: Samuel Morse invents Morse code. Cryptography export
restrictions prevent the telegraph’s use outside the U.S. and Canada.
What I’m curious about is that if you use a VM don’t you still have to
make sure the VM is distributed? What is the comparative size of a given
VM vs interpreter?
OCaml’s standardlib and GC engine enters at 200K for the native code
compiled version. This is small enough that each dll you create can have
it’s own VM (if you can call it VM) - this is useful for creating COM
components and similar.
The bytecode version needs only the OCamlRun.dll which is 100K in size and
the bytecode is rather small. This figure then grows with additional
extensions being used - these can be compiled into the bytecode if there is
no C code involved.
Thus the distribution is limited to a single dll, which is better (much
better) than most non VM applications you’ll find. And even C typically
requires a runtime dll for malloc etc.
It wouldn’t be a far cry to wrap the bytecode up with the runtime dll,
actually I think you can already do this by making your own runtime (there’s
a tool). However, it’s better to have the runtime separated out because the
bytecode is then platform independent.
I actually tried to deploy such a solution in a pre-release production test
environment - although only as a prototype for the final politically correct
C++ solution.
So I’d say it certainly is possible to have a VM in distribution - also
without bloated .NET and Java runtimes.
A Ruby VM would probably have to be somewhat larger than OCamls but up to
1MB would easily be acceptable. I think Ruby’s current runtime is not very
large actually - and exerb does pull a nice stunt at wrapping it up -
although I have yet to experiment with it.
For distibution purposes it doesn’t really matter if it is xor’ed sourcecode
or bytecode. Exerb is close to a real solution, but it’s windows only and it
ought to be supported directly in the Ruby core development. It should also
support creating dynamic “packages” such that you don’t have to ship, say,
FxRuby with every piece of code.
What ruby needs is the equivalent of tcl’s starkits. It meets all of
your requirements. About 1 meg, cross-platform, supported in core. There
are alternative starkits, with various libs included, and can be turned into
“starpacks”- single standalone executable apps that can be built for any
platform tcl is ported too (quite a lot, to say the least).
Jake
“Why do I always talk about tcl on comp.lang.ruby, and ruby on
comp.lang.tcl?”
Mikkel wrote
1MB would easily be acceptable. I think Ruby’s current runtime is not very
large actually - and exerb does pull a nice stunt at wrapping it up -
although I have yet to experiment with it.
For distibution purposes it doesn’t really matter if it is xor’ed
sourcecode
or bytecode. Exerb is close to a real solution, but it’s windows only and
it
ought to be supported directly in the Ruby core development. It should
also
···
support creating dynamic “packages” such that you don’t have to ship, say,
FxRuby with every piece of code.
