thread-safe ANSI-C ruby needed to replace lua

J

jeff_alexander_44

My software development generally consists of:

C++ : high-performance code -- rendering, physics, complex
computations,
system API calls (e.g. Direct3D)

lua : in-application scripting

ruby : outside-application scripting -- building, generating C++ code,
generating lua code, running tests, running benchmarks,
everything else

The only reasons for using lua are sheer technical ones: effortless
portability (100% ANSI C -- especially needed for embedded platforms),
thread-safety, and speed.

What is absolutely needed in the game software industry is a better
lua. My preference would be an ANSI C version of ruby. Many things
would become easier if I could replace lua with ruby --- I would get
some synergy between my in-application code and outside-application
code, for example. (I could of course use lua instead of ruby, but
that turns out to be more inefficient; besides, lua is generally
frustrating compared to ruby.)

So, what is standing in the way of an ANSI-C ruby? How much of ruby
or ruby2 would need to be redesigned or changed in order to get a
streamlined, minimal ANSI-C-only version?
 
J

Jim Bob

I looked at doing the same thing a while ago, heard there was such a
thing as minruby and that was about it :) Looked at the ruby-core
source, looked a bit errrr messy shall we say...and gave up
 
E

evanwebb

So, what is standing in the way of an ANSI-C ruby? How much of ruby
or ruby2 would need to be redesigned or changed in order to get a
streamlined, minimal ANSI-C-only version?

Not to pimp my own project, but....

rubinius is a new ruby VM that is thread-safe from the ground up. It
uses some C99 features which could be eliminated if need be. rubinius
is also writen as a minimal VM with the vast majority of the ruby core
library (All the methods of String, Array, etc) implemented directly
in ruby.

As for retrofitting the 1.8 code base, I attempted this with my sydney
project, which effectively made the interpreter thread-safe. There
were a lot more features I was looking to add, so I've since stopped
work on that project in favor of working on rubinius.

As for timeline, rubinius 1.0 will be out in november and be 1.8.5
compliant.

We're always looking for fresh blood to help on the project as well!

- Evan Phoenix
 
J

Jeremy Henty

The only reasons for using lua are sheer technical ones: ... What is
absolutely needed in the game software industry is a better lua.

I'm surprised to hear this, can you say more? I looked at Lua
recently and I was very impressed: a clean, simple language, proper
lexical closure and garbage collection, and the metatables feature is
very powerful. What's wrong with Lua that the game software industry
needs something better?

Regards,

Jeremy Henty
 
J

James Edward Gray II

I'm surprised to hear this, can you say more? I looked at Lua
recently and I was very impressed: a clean, simple language, proper
lexical closure and garbage collection, and the metatables feature is
very powerful. What's wrong with Lua that the game software industry
needs something better?

The one time I really needed Lua, the lack of bit manipulation
operators being built into the language was a major minus. It just
ends up being a little too minimalist for me at times.

James Edward Gray II
 
B

Bira

I'm surprised to hear this, can you say more? I looked at Lua
recently and I was very impressed: a clean, simple language, proper
lexical closure and garbage collection, and the metatables feature is
very powerful. What's wrong with Lua that the game software industry
needs something better?

I think it's a matter of custom. Maybe the original poster is more
used to Ruby than to Lua, and so the "Ruby way" feels more natural and
efficient to him. It's the same reason people who are more used to
Java, for example, complain about certain "missing features" of Ruby.

I recently joined a Lua mailing list, and it seems to me that
modifying the interpreter itself to fit your project's needs better is
an accepted practice over there. Not something developers are expected
to do every time, but not completely contrary to the language's design
philosophy.

I still don't have much experience with Lua, but it's something I want
to look into in the future. So everything I said here can be, and
probably is, wrong :).
 
M

M. Edward (Ed) Borasky

Bira said:
I think it's a matter of custom. Maybe the original poster is more
used to Ruby than to Lua, and so the "Ruby way" feels more natural and
efficient to him. It's the same reason people who are more used to
Java, for example, complain about certain "missing features" of Ruby.

I recently joined a Lua mailing list, and it seems to me that
modifying the interpreter itself to fit your project's needs better is
an accepted practice over there. Not something developers are expected
to do every time, but not completely contrary to the language's design
philosophy.

I still don't have much experience with Lua, but it's something I want
to look into in the future. So everything I said here can be, and
probably is, wrong :).
Well ... I don't know anything about Lua, but if you really need
ultimate compactness and performance and "bare-metal" access, I really
think your choices are C or Forth, and Forth is much better at building
"domain-specific languages" than C. :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,479
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top