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?
on 2007-05-15 19:11
on 2007-05-15 19:19
Hello, Have you tried this? http://metaeditor.sourceforge.net/embed/ (it for C++, I know) -- Pau Garcia i Quiles http://www.elpauer.org (Due to the amount of work, I usually need 10 days to answer) Quoting firstname.lastname@example.org:
on 2007-05-15 19:27
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
on 2007-05-15 22:00
On May 15, 10:07 am, jeff_alexander...@yahoo.com wrote: > > 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
on 2007-05-17 11:31
On 2007-05-15, email@example.com <firstname.lastname@example.org> wrote: > 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
on 2007-05-17 14:02
On May 17, 2007, at 4:30 AM, Jeremy Henty wrote: > 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
on 2007-05-17 16:08
On 5/17/07, Jeremy Henty <email@example.com> wrote: > 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 :).
on 2007-05-18 21:38
Bira wrote: > Java, for example, complain about certain "missing features" of Ruby. > 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. :)