T
t3chn0n3rd
right now I am running ruby on red hat 8. Is there a compiler for
windows vista?
windows vista?
T
Thomas Wieczorek
There are interpreters for all Windows plattform, yes. Some WinAPI
libraries might not work though
T
Tim Hunter
t3chn0n3rd said:
If by "compiler" you mean "interpreter," then yes. Google
"ruby+windows". If by "compiler" you mean "a thing that turns Ruby code
into object code," then no. There are no Ruby compilers. If you mean
something else, please clarify.
J
James Tucker
Except the one in jruby. oh and rubinius (is that working yet?). Oh
and 1.9.
F
Fred Talpiot
t3chn0n3rd said:
I have several ruby-on-rails projects that run on Windows XP 32-bit and
run the same on Linux 64-bit. So yes, they're compatible.
Uh, they run 'the same' with the exception that the faster hardware runs
it faster, of course.
T
Tim Hunter
James said:Except the one in jruby. oh and rubinius (is that working yet?). Oh
and 1.9.
I knew somebody would quibble. That's why I specified "a thing that
turns Ruby code into object code." Neither JRuby nor YARV is turns Ruby
code into object code. VM instructions, yes. Object code, no.
J
James Tucker
I don't really want to argue, but I do feel it's important to point
this out. Most code that you will ever write (including C or any form
of assembler to run under an operating system (any of the 6 most
common OSes), runs inside a virtual machine). Whilst some or even most
of the instructions may run directly on the processor, there are many
layers of indirection providing a genuine virtual machine experience.
That is, memory management, scheduling, memory access security, and so
on and so forth. Many C heads (of which I am actually not one) will
tell you that "most C code is written for a virtual machine on any
modern OS".
Now if you want to get 1 step closer to the processor, and this is
your definition (of object code), that's fine, but there are often no
genuine benefits to doing so, by comparison to what becomes available
expanding the size (or more specifically capability) of the VM you run
on. Start up time aside, it's relatively well known that Java is
starting to push these boundaries.
The real gain that businesses see to 'object code' is that it is very
hard to 'steal implementation code' from 'object code'. This is partly
a product of optimization and of the effective (co-incidental)
obfuscation of the code. According to some of the Jruby folks, it's
very hard indeed, to get 'implementation code' from jruby compiled
classes.
Moreover, I'm not sure it's practical, or even entirely possible, to
implement ruby without at least some 'VM' style code running in the
background, even under an attempt to make that all static, stateless
code. I'd like to be proven wrong, though.
As I say, I don't want to argue on the definition of object code. We
probably share different opinions. This is just mine, and I'm happy to
discuss it, but not to argue.
F
Fred Talpiot
C and assembler run directly on the hardware. Sometimes in user mode,
sometimes in kernel mode. Sometimes with an extensive run time library,
sometimes without.
I suppose you could call virtual memory a 'VM', but few do. And neither
C nor assembler require virtual memory underneath.
sometimes in kernel mode. Sometimes with an extensive run time library,
sometimes without.
I suppose you could call virtual memory a 'VM', but few do. And neither
C nor assembler require virtual memory underneath.