hi, what is the best way to distribute ruby apps without having the end
user need to download ruby?
i have looked into:
tar2ruby
exerb
and Xruby
however they seem difficult to use, after trying and failing. are there
other solutions? or any guides? for such an amazing language, ruby is
very difficult to compile to a standalone.
--
Posted via http://www.ruby-forum.com/.
i forgot to mention im usign debian linux and can anyone tell me what
init.rb referres to?
--
Posted via http://www.ruby-forum.com/.
Pavel Pvl wrote:
hi, what is the best way to distribute ruby apps without having the end
user need to download ruby?
rubyscript2exe is nice.
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
This is more to the 'gods of ruby' than a reply. Tcl/Tk has a nice way to do stuff like this called Starpacks. This is possible using the Tcl/Tk virtual file system hooks. Starpacks are executables that consist of the intepreter, necessary compiled packages, and a virtual
file system appended to the back end of the executable that contains the script, scripted packages and loadable binaries.
A similar sort of thing for Ruby might be a _good_ thing. The seminal paper on starpacks and the related starkit (the virtual filesystem unbundled from the run-time) is at:
http://www.equi4.com/papers/skpaper1.html
if any of the ruby gods are interested.
Please don't read this as a Tcl/Tk plug... just a comment that other scripted languages had to face this and here's one solution that another scripting language came up with that may apply here.
Ron.
Pavel Pvl wrote:
hi, what is the best way to distribute ruby apps without having the end
user need to download ruby?i have looked into:
tar2ruby
exerb
and Xrubyhowever they seem difficult to use, after trying and failing. are there
other solutions? or any guides? for such an amazing language, ruby is
very difficult to compile to a standalone.
I asked almost the same question not too long ago. I think the
consensus was that JRuby was the best way to go. I don't really like
this solution, but seems like the only way to go at the moment.
Joe
On Dec 19, 2007 4:19 PM, Pavel Pvl <pavel989@gmail.com> wrote:
i forgot to mention im usign debian linux and can anyone tell me what
init.rb referres to?--
Posted via http://www.ruby-forum.com/\.
Isn't this exactly what rubyscript2exe does?
http://www.erikveen.dds.nl/rubyscript2exe/
On 12/20/07, Ron Fox <fox@nscl.msu.edu> wrote:
Starpacks are executables that
consist of the intepreter, necessary compiled packages, and a virtual
file system appended to the back end of the executable that contains the
script, scripted packages and loadable binaries.A similar sort of thing for Ruby might be a _good_ thing. The
seminal paper on starpacks and the related starkit (the virtual
filesystem unbundled from the run-time) is at:
well it seems as tho i can;t really figure out how to use
rubyscript2exe, but i emailed the creator. im still trying to get jruby
to work. But seriously for such a language, it's hard to believe that
there isn't any 'standard' compiler.
--
Posted via http://www.ruby-forum.com/.
Sounds like it to me, although I don't know starpacks at all.
I've had very good luck with rubyscript2exe. Even used it with C
extensions (like rb-gsl) and it worked on different distributions than
what I "compiled" it on.
Pavel, it's really straight-forward to use. What are you having
problems with?
Cameron
On Dec 20, 2007 1:45 PM, Adam Shelly <adam.shelly@gmail.com> wrote:
On 12/20/07, Ron Fox <fox@nscl.msu.edu> wrote:
> Starpacks are executables that
> consist of the intepreter, necessary compiled packages, and a virtual
> file system appended to the back end of the executable that contains the
> script, scripted packages and loadable binaries.
>
> A similar sort of thing for Ruby might be a _good_ thing. The
> seminal paper on starpacks and the related starkit (the virtual
> filesystem unbundled from the run-time) is at:
>Isn't this exactly what rubyscript2exe does?
http://www.erikveen.dds.nl/rubyscript2exe/
Some differentiations:
1. starpack/starkit technology also supports a separation of the run-time (tclkit in Tcl/Tk land), and the application stuff (the stuff in the VFS). This allows you to split the installer into a system dependent piece (the tclkit) and the application (starkit). These can
be combined to a starpack which is system dependent.
2. Because the starkit part of the system is a full featured filesystem from the Tcl/Tk point of view it's possible to do a few neat things including automatic updating of the contents of the starkit. The application, as it starts up can ask the world if there are newer versions and, if desired, confirmed by the user..all the application specific caveats you care to apply, can update itself in place.
3. Because the VFS that constitutes starkits is actually a metakit database, updates described above can be done as a transaction which either entirely succeed or entirely fail, but not leave the application in some funky state.
4. Again, because the VFS is a file system, the application can:
- store data (e.g. ordinary help files) and access them as files.
- keep e.g. configuration data allowing for a portable computing env.
(e.g. a web-browser starpack could keep your book marks in its
VFS so you could run around with your browser on a memory stick).
5. Because the starkit is a virtual file system to Tcl/Tk, there's no need to unpack the application into a temp directory for purely scripted apps.. or for apps whose extensions are built into the tclkit. Only compiled loadable extensions need to be copied out into the host's filesystem so that they host system's dynamic loader can find them. For large apps this can improve the startup time significantly.
Ron.
Adam Shelly wrote:
On 12/20/07, Ron Fox <fox@nscl.msu.edu> wrote:
Starpacks are executables that
consist of the intepreter, necessary compiled packages, and a virtual
file system appended to the back end of the executable that contains the
script, scripted packages and loadable binaries.A similar sort of thing for Ruby might be a _good_ thing. The
seminal paper on starpacks and the related starkit (the virtual
filesystem unbundled from the run-time) is at:Isn't this exactly what rubyscript2exe does?
http://www.erikveen.dds.nl/rubyscript2exe/
I found this hard to believe too.
I was hoping for at least a cross platform packaging format, similar
to jar for Java but specific to Ruby.
On Dec 19, 2007 7:54 PM, Pavel Pvl <pavel989@gmail.com> wrote:
well it seems as tho i can;t really figure out how to use
rubyscript2exe, but i emailed the creator. im still trying to get jruby
to work. But seriously for such a language, it's hard to believe that
there isn't any 'standard' compiler.
--Posted via http://www.ruby-forum.com/\.
Is there any working example of a macosx application (even some
"hello world") which is build with rubyscript2exe?
-- Maurice
On Dec 20, 9:59 pm, Cameron McBride <cameron.mcbr...@gmail.com> wrote:
On Dec 20, 2007 1:45 PM, Adam Shelly <adam.she...@gmai
> Isn't this exactly what rubyscript2exe does?
>http://www.erikveen.dds.nl/rubyscript2exe/Sounds like it to me, although I don't know starpacks at all.
I've had very good luck with rubyscript2exe. Even used it with C
extensions (like rb-gsl) and it worked on different distributions than
what I "compiled" it on.Pavel, it's really straight-forward to use. What are you having
problems with?
How does this handle interacting with the filesystem outside the VFS?
So let's say you have files in the same directory as the starkit How
would you access them? Does it automatically assume you're accessing
something outside of the starkit unless you specifically say you want
something in the starkit? (IIRC that's how jars work in Java)
Joe
On Dec 20, 2007 4:39 PM, Ron Fox <fox@nscl.msu.edu> wrote:
Some differentiations:
1. starpack/starkit technology also supports a separation of the
run-time (tclkit in Tcl/Tk land), and the application stuff (the stuff
in the VFS). This allows you to split the installer into a system
dependent piece (the tclkit) and the application (starkit). These can
be combined to a starpack which is system dependent.2. Because the starkit part of the system is a full featured filesystem
from the Tcl/Tk point of view it's possible to do a few neat things
including automatic updating of the contents of the starkit. The
application, as it starts up can ask the world if there are newer
versions and, if desired, confirmed by the user..all the application
specific caveats you care to apply, can update itself in place.3. Because the VFS that constitutes starkits is actually a metakit
database, updates described above can be done as a transaction which
either entirely succeed or entirely fail, but not leave the application
in some funky state.4. Again, because the VFS is a file system, the application can:
- store data (e.g. ordinary help files) and access them as files.
- keep e.g. configuration data allowing for a portable computing env.
(e.g. a web-browser starpack could keep your book marks in its
VFS so you could run around with your browser on a memory stick).5. Because the starkit is a virtual file system to Tcl/Tk, there's no
need to unpack the application into a temp directory for purely scripted
apps.. or for apps whose extensions are built into the tclkit. Only
compiled loadable extensions need to be copied out into the host's
filesystem so that they host system's dynamic loader can find them. For
large apps this can improve the startup time significantly.Ron.
Adam Shelly wrote:
> On 12/20/07, Ron Fox <fox@nscl.msu.edu> wrote:
>> Starpacks are executables that
>> consist of the intepreter, necessary compiled packages, and a virtual
>> file system appended to the back end of the executable that contains the
>> script, scripted packages and loadable binaries.
>>
>> A similar sort of thing for Ruby might be a _good_ thing. The
>> seminal paper on starpacks and the related starkit (the virtual
>> filesystem unbundled from the run-time) is at:
>>
>
> Isn't this exactly what rubyscript2exe does?
> http://www.erikveen.dds.nl/rubyscript2exe/
>
Hi Cameron,
No, starkits and starpacks are actually much more powerful and
versatile. The Tcl world had the equivalent of rubyscript2exe for years
and years, but when starkits and starpacks came out it everyone found it
a huge step forward when it came to deployment.
Among the advantages:
* ship a single file platform-specific executable (as per *2exe)
* ship a single file platform-neutral application, which can then be
run with a (single file) platform-specific but application-neutral
binary; in other words, your entire language runtime can be in a single
file you can just download, and use for many applications
* no changing your code... because starkits are based on a virtual
file system, you refer to files "in" the starkit exactly the same as you
would normal files on disk, using standard I/O commands. so that is
both scripts, data files, etc.
* starkits can be used as a way to distribute source, again all in
one file; people can grab the starkit, unpack it, make some changes,
pack it up again
* source can be optionally protected (i.e. you can't get the original
scripts back) using a compiler, which is actually a separate and
complementary tool
Mark
Cameron McBride <cameron.mcbride@gmail.com> wrote:
> Isn't this exactly what rubyscript2exe does?
> http://www.erikveen.dds.nl/rubyscript2exe/Sounds like it to me, although I don't know starpacks at all.
Cameron McBride wrote:
Isn't this exactly what rubyscript2exe does?
http://www.erikveen.dds.nl/rubyscript2exe/Sounds like it to me, although I don't know starpacks at all.
I've had very good luck with rubyscript2exe. Even used it with C
extensions (like rb-gsl) and it worked on different distributions than
what I "compiled" it on.Pavel, it's really straight-forward to use. What are you having
problems with?Cameron
well, ive been experimenting some more with it. ran into some problems
with the ftools library. but i somehow fixed it. now im just trying to
figure out how this system works. i have a script compiled, but it only
lets me load it through a terminal. so ill just need to paly with it a
bit more, but it seems to be working.
otherwise, for things like jruby and so forth. idunno y, but it seems as
tho my ubuntu isn't "built" for them. i guess its a problem with my
java, but they wont work. although i would like to try them
On Dec 20, 2007 1:45 PM, Adam Shelly <adam.shelly@gmail.com> wrote:
--
Posted via http://www.ruby-forum.com/\.
Joe wrote:
I was hoping for at least a cross platform packaging format, similar
to jar for Java but specific to Ruby.
If you want to package a set of pure ruby files (no extensions, no interpreter) into a single script file, you can try darb:
http://raa.ruby-lang.org/project/darb/
http://redshift.sourceforge.net/darb/
Not as fancy as jar, and limited, but useful in some cases.
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Ruby is an interpreted language at this point, so you have no choice
but to pair it with an interpreter of some kind, whether it be MRI
Ruby, Rubinius, JRuby, or whatever.
You could always just package a no-install version of Ruby with your
application, stripping out any libraries you don't use. You could
also look into somehow using miniruby:
http://article.gmane.org/gmane.comp.lang.ruby.general/68084
--Jeremy
On Dec 19, 2007 11:08 PM, Joe <qbproger@gmail.com> wrote:
I found this hard to believe too.
I was hoping for at least a cross platform packaging format, similar
to jar for Java but specific to Ruby.On Dec 19, 2007 7:54 PM, Pavel Pvl <pavel989@gmail.com> wrote:
> well it seems as tho i can;t really figure out how to use
> rubyscript2exe, but i emailed the creator. im still trying to get jruby
> to work. But seriously for such a language, it's hard to believe that
> there isn't any 'standard' compiler.
> --
>
> Posted via http://www.ruby-forum.com/\.
>
>
--
http://www.jeremymcanally.com/
My books:
Ruby in Practice
My free Ruby e-book
My blogs:
The VFS appears mounted in a specific point on the actual filesystem.
There's no problem accessing files outside or inside the VFS.
I have a starkit, for example that implements a launcher for X11 clients
to windows X11 servers. That starkit is able to, and perfectly well does, store session configurations in a file in the 'normal windows
locations $AppData\xlauncer'.
The application can find the top-level of the starkit vfs via the
variable starkit::topdir
See e.g. Writing to Your Starkit
for more information and sample code.
Ron.
Joe wrote:
How does this handle interacting with the filesystem outside the VFS?
So let's say you have files in the same directory as the starkit How
would you access them? Does it automatically assume you're accessing
something outside of the starkit unless you specifically say you want
something in the starkit? (IIRC that's how jars work in Java)Joe
On Dec 20, 2007 4:39 PM, Ron Fox <fox@nscl.msu.edu> wrote:
Some differentiations:
1. starpack/starkit technology also supports a separation of the
run-time (tclkit in Tcl/Tk land), and the application stuff (the stuff
in the VFS). This allows you to split the installer into a system
dependent piece (the tclkit) and the application (starkit). These can
be combined to a starpack which is system dependent.2. Because the starkit part of the system is a full featured filesystem
from the Tcl/Tk point of view it's possible to do a few neat things
including automatic updating of the contents of the starkit. The
application, as it starts up can ask the world if there are newer
versions and, if desired, confirmed by the user..all the application
specific caveats you care to apply, can update itself in place.3. Because the VFS that constitutes starkits is actually a metakit
database, updates described above can be done as a transaction which
either entirely succeed or entirely fail, but not leave the application
in some funky state.4. Again, because the VFS is a file system, the application can:
- store data (e.g. ordinary help files) and access them as files.
- keep e.g. configuration data allowing for a portable computing env.
(e.g. a web-browser starpack could keep your book marks in its
VFS so you could run around with your browser on a memory stick).5. Because the starkit is a virtual file system to Tcl/Tk, there's no
need to unpack the application into a temp directory for purely scripted
apps.. or for apps whose extensions are built into the tclkit. Only
compiled loadable extensions need to be copied out into the host's
filesystem so that they host system's dynamic loader can find them. For
large apps this can improve the startup time significantly.Ron.
Adam Shelly wrote:
On 12/20/07, Ron Fox <fox@nscl.msu.edu> wrote:
Starpacks are executables that
consist of the intepreter, necessary compiled packages, and a virtual
file system appended to the back end of the executable that contains the
script, scripted packages and loadable binaries.A similar sort of thing for Ruby might be a _good_ thing. The
seminal paper on starpacks and the related starkit (the virtual
filesystem unbundled from the run-time) is at:Isn't this exactly what rubyscript2exe does?
http://www.erikveen.dds.nl/rubyscript2exe/
Joe, the virtual file system hooks work comparably to 'real' file
systems in that you can 'mount' a new file system at a particular point
in the directory tree.
Let's say you've downloaded your starkit to /home/foo/my.kit. When you
run the starkit, the file system inside it essentially gets mounted at
that location in the directory tree. So if you try to access
/home/foo/my.kit/bar/data.txt, that will look inside the starkit. If
you try to access /home/foo/other.dat, it will look in the regular file
system, because the starkit isn't mounted there.
So the nice thing is that it's all transparent. You just use the
regular commands you'd used to operate on any old file, and the internal
I/O system will figure out what 'filesystem' you're working on based
upon the path names.
Like any virtual file system based thing, the same approach is used for
other filesystems... e.g. one that maps an http server to a file system.
Mark
Joe <qbproger@gmail.com> wrote:
How does this handle interacting with the filesystem outside the VFS?
So let's say you have files in the same directory as the starkit How
would you access them? Does it automatically assume you're accessing
something outside of the starkit unless you specifically say you want
something in the starkit? (IIRC that's how jars work in Java)Joe
On Dec 20, 2007 4:39 PM, Ron Fox <fox@nscl.msu.edu> wrote:
> Some differentiations:
> 1. starpack/starkit technology also supports a separation of the
> run-time (tclkit in Tcl/Tk land), and the application stuff (the stuff
> in the VFS). This allows you to split the installer into a system
> dependent piece (the tclkit) and the application (starkit). These can
> be combined to a starpack which is system dependent.
>
> 2. Because the starkit part of the system is a full featured filesystem
> from the Tcl/Tk point of view it's possible to do a few neat things
> including automatic updating of the contents of the starkit. The
> application, as it starts up can ask the world if there are newer
> versions and, if desired, confirmed by the user..all the application
> specific caveats you care to apply, can update itself in place.
>
> 3. Because the VFS that constitutes starkits is actually a metakit
> database, updates described above can be done as a transaction which
> either entirely succeed or entirely fail, but not leave the application
> in some funky state.
>
> 4. Again, because the VFS is a file system, the application can:
> - store data (e.g. ordinary help files) and access them as files.
> - keep e.g. configuration data allowing for a portable computing env.
> (e.g. a web-browser starpack could keep your book marks in its
> VFS so you could run around with your browser on a memory stick).
>
> 5. Because the starkit is a virtual file system to Tcl/Tk, there's no
> need to unpack the application into a temp directory for purely scripted
> apps.. or for apps whose extensions are built into the tclkit. Only
> compiled loadable extensions need to be copied out into the host's
> filesystem so that they host system's dynamic loader can find them. For
> large apps this can improve the startup time significantly.
>
> Ron.
>
>
>
> Adam Shelly wrote:
> > On 12/20/07, Ron Fox <fox@nscl.msu.edu> wrote:
> >> Starpacks are executables that
> >> consist of the intepreter, necessary compiled packages, and a virtual
> >> file system appended to the back end of the executable that contains the
> >> script, scripted packages and loadable binaries.
> >>
> >> A similar sort of thing for Ruby might be a _good_ thing. The
> >> seminal paper on starpacks and the related starkit (the virtual
> >> filesystem unbundled from the run-time) is at:
> >>
> >
> > Isn't this exactly what rubyscript2exe does?
> > http://www.erikveen.dds.nl/rubyscript2exe/
> >
>
>
Jeremy McAnally wrote:
Ruby is an interpreted language at this point, so you have no choice
but to pair it with an interpreter of some kind, whether it be MRI
Ruby, Rubinius, JRuby, or whatever.You could always just package a no-install version of Ruby with your
application, stripping out any libraries you don't use. You could
also look into somehow using miniruby:
http://article.gmane.org/gmane.comp.lang.ruby.general/68084
Ruby 1.9, XRuby, IronRuby, Ruby.NET, and Rubinius run Ruby as compiled bytecodes all the time (ok, you could say a bytecode interpreter, but it's still a big step beyond walking an AST). JRuby includes a mixed interpred/compiled mode for execution by default along with "all interpreted" and "all compiled" modes. In fact, as far as I know, Ruby 1.8 is the only version that's "only" interpreted at this point...all other versions have compiled execution.
- Charlie
I should once more say the intent is not to suggest that Tcl is better than Ruby... but that the idea of using virtual file systems to package
software is a good one that gives you a lot of traction, and one that
perhaps us ruby-ites could learn from, rather than struggling in the wilderness for a few years before it occurs to us.
Looking at ruby2exe about the only thing it seems to be missing to get there is the idea that it's internal tarball is really a virtual filesystem, and could be accessed directly if ruby libraries had virtual file system support.
The idea of virtual filesystems also provides much more than just starpack/starkit technologies.
Ron.
Ron Fox wrote:
The VFS appears mounted in a specific point on the actual filesystem.
There's no problem accessing files outside or inside the VFS.
I have a starkit, for example that implements a launcher for X11 clients
to windows X11 servers. That starkit is able to, and perfectly well does, store session configurations in a file in the 'normal windows
locations $AppData\xlauncer'.The application can find the top-level of the starkit vfs via the
variable starkit::topdirSee e.g. Writing to Your Starkit
for more information and sample code.
Ron.
Joe wrote:
How does this handle interacting with the filesystem outside the VFS?
So let's say you have files in the same directory as the starkit How
would you access them? Does it automatically assume you're accessing
something outside of the starkit unless you specifically say you want
something in the starkit? (IIRC that's how jars work in Java)Joe
On Dec 20, 2007 4:39 PM, Ron Fox <fox@nscl.msu.edu> wrote:
Some differentiations:
1. starpack/starkit technology also supports a separation of the
run-time (tclkit in Tcl/Tk land), and the application stuff (the stuff
in the VFS). This allows you to split the installer into a system
dependent piece (the tclkit) and the application (starkit). These can
be combined to a starpack which is system dependent.2. Because the starkit part of the system is a full featured filesystem
from the Tcl/Tk point of view it's possible to do a few neat things
including automatic updating of the contents of the starkit. The
application, as it starts up can ask the world if there are newer
versions and, if desired, confirmed by the user..all the application
specific caveats you care to apply, can update itself in place.3. Because the VFS that constitutes starkits is actually a metakit
database, updates described above can be done as a transaction which
either entirely succeed or entirely fail, but not leave the application
in some funky state.4. Again, because the VFS is a file system, the application can:
- store data (e.g. ordinary help files) and access them as files.
- keep e.g. configuration data allowing for a portable computing env.
(e.g. a web-browser starpack could keep your book marks in its
VFS so you could run around with your browser on a memory stick).5. Because the starkit is a virtual file system to Tcl/Tk, there's no
need to unpack the application into a temp directory for purely scripted
apps.. or for apps whose extensions are built into the tclkit. Only
compiled loadable extensions need to be copied out into the host's
filesystem so that they host system's dynamic loader can find them. For
large apps this can improve the startup time significantly.Ron.
Adam Shelly wrote:
On 12/20/07, Ron Fox <fox@nscl.msu.edu> wrote:
Starpacks are executables that
consist of the intepreter, necessary compiled packages, and a virtual
file system appended to the back end of the executable that contains the
script, scripted packages and loadable binaries.A similar sort of thing for Ruby might be a _good_ thing. The
seminal paper on starpacks and the related starkit (the virtual
filesystem unbundled from the run-time) is at:Isn't this exactly what rubyscript2exe does?
http://www.erikveen.dds.nl/rubyscript2exe/