Hi I was looking into Ruby to actionscript 3 bytecode compilers and found a mention of a project called Red Sun but can find very little information on it.
So my Question is ... what tools are available to convert Ruby source into AS3 bytecode
I am the lead developer on the Red Sun project. There is very little information because it is really not ready to be used yet. I worked on the original prototype and presented it to a handful of people at 360|Flex San Jose. This generated further interest and encouraged me to propose it for RubyConf, for which an introductory talk on Red Sun was accepted.
Since then, I have had the time to flesh out the framework and really see what was possible. I'll be outlining all of this publicly soon, but I decided to diverge from the idea of generating ActionScript 3 bytecode becuase of the limitations of it. Ruby and ActionScript are somewhat similar, but Ruby has some significant differences in its method dispatch semantics that require any implementation in ActionScript to use a custom method lookup solution. It could perhaps be done in JavaScript, however ActionScript 3 does not allow re-assigning the prototype field to point at a different object, and Ruby relies on modifying the inheritance hierarchy at runtime.
The presentation at RubyConf will be on Saturday, Nov 8th. You can track Red Sun's development on http://github.com here http://github.com/jonathanbranam/redsun and I will be posting information on my website at http://jonathanbranam.net. I am planning to launch a site just for information about Red Sun, but that is not completed yet to share a link.
Red Sun does not include a Ruby parser or compiler, so it relies on Ruby 1.9 bytecode being generated by a true Ruby 1.9 implementation. It is currently based on 1.9.0-4 and may need changes if there is deviation from this version. As far as capabilities, as of right now (10/27/2008) it supports basic method dispatch, classes and modules. That's really about it. The standard library has not been ported and I hope to depend on Rubinius for a good portion of this.
I don't know of any Ruby->AS3 converters but in the future, Iron Monkey may make it possible to run Ruby on Tamarin (AS3 virtual machine).
As an aside, I'm pretty sure there are things you can do in Ruby that you can't do in AS3, so any converter would probably only be able to convert a subset of Ruby code.
Related
Current status of truffleruby says:
TruffleRuby is progressing fast but is currently probably not ready for you to try running your full Ruby application on. Support for critical C extensions such as OpenSSL and Nokogiri is missing.
Why does truffleruby need C extensions? It's built on GraalVM which is built on top of the JVM, it is in fact a fork of JRuby:
TruffleRuby is a fork of JRuby, combining it with code from the Rubinius project, and also containing code from the standard implementation of Ruby, MRI.
Can't they use JRuby world gems instead of depending on their C variants?
EDIT link to the issue on github
Running C extensions is hard because the C extension API is just the entire internals of MRI exposed as a header file. You aren't programming against a clean API - you're programming against all the implementation details and internal design decisions of MRI.
JRuby's Java extensions have exactly the same problem! The JRuby Java extension API is just the entire internals of JRuby, and you aren't programming against an API, instead you're programming against all the implementations details and design decisions of JRuby.
We plan to eventually tackle both problems in the same way - which is to add another level of abstraction over the C or Java code using an interpreter which we can intercept and redirect when required, so that it believes it is running against MRI or JRuby internals, but really we redirect these to our internals.
We think C extensions are more important, so we're tackling those first. We haven't really started on Java extensions yet, but we have started the underlying interpreter for Java that we'll use.
This video explains all
https://youtu.be/YLtjkP9bD_U?t=1562
You have already gotten a good answer by the project lead himself, but I want to offer a different point of view:
Why does truffleruby need C extensions?
It doesn't need them. But they do exist and there is code out there which uses them, and it would sure be nice to be able to run that code.
I use Ruby from a user level and really don't deal with the internals. I have know Rubinius as 'Ruby in Ruby' which I assumed was a generalization. Recently, I got an error with Rubinius in the RubySL (no, I don't have error msg).
I started looking at RubySL and was a little surprised to see Rubinius everywhere. I really like Ruby and was just curious why Rubinius is in most of the RubySL? It seems to be used with things like locks / unlocks (such as https://github.com/rubysl/rubysl-thread/blob/2.0/lib/rubysl/thread/thread.rb ). Definitely not questioning it, just curious.
RubySL is short for Ruby Standard Library. It is a basic part of the shipped code bundle which forms what is generally known as Ruby. The standards library provides rather basic stuff you often need but which doesn't need to be part of the core language.
For example, the implementation of the Hash or Array, the language keywords, how assignment works, ... are part of the core language. These are often implemented in a language other than Ruby. MRI (the common C-Ruby) implements this mostly in C, JRuby implements this in Java. Rubinius implements this patly in C++ but mostly in Ruby itself. It can do this by bootstrapping itself from a very simple base VM and gradually adding more stuff with Ruby.
The standards library however is mostly implemented in Ruby in all implementations (with some exceptions mostly for performance reasons). Now, all Ruby implementations right now have their own implementation of the Ruby standards library which can thus differ in minor details.
Rubinius' approach to implementing a standards library was to implement it as separate gems. The idea was to one day provide a common standards library which could be used by other implementations (including MRI). This is in line with the efforts of esp. the Rubinius community to drive the RubySpec project in order to provide a common language specification and test suite for all Ruby implementations.
The RubySpec project was eventually abandoned and right now, it doesn't seem as if other Ruby implementations seem to be moving to the RubySL gems for implementing their standards library.
Thus, (and this is the TL;DR), the RubySL gems implement the Ruby Standard Library for the Rubinius project. Thus, it is expected to see the Rubinius project all over the place there: it is their code which is generally not used by other Ruby implementations.
So I see that unity has the support for c#, JS and Boo.
I could learn one of these but I would like to make a 'compiler' or something similar that would let me write ruby code and either output JS code or make a layer that could be read by the Unity compiler.
Is this even a possibility. Im willing to invest many hours in this and have a fair bit of experience.
If your question is actually "how do I compile Ruby to JavaScript" then that's easier to answer:
Opal: Ruby to JavaScript compiler
However, you're going to be mucher better off learning one of the supported languages. It's very hard to debug "your" code when what's running is a paraphrasing of the code in another language.
I'm not that familiar with C# but if it's anything like C, it's quite possible you could create bindings from Ruby to Unity and just use it directly. Likely you could even get some kind of community going. This would be much preferable to trying to auto-refactor languages.
I recommend the "play my code" site.
It is possible to "conpiles Ruby to JavaScript", to operate the Ruby Game in a browser, just as JS.
http://www.playmycode.com/build/edit/6172
Unity 3d doesn't use Javascript, i think unity corporation call it as javascript just for marketing purposes, Unity uses UnityScript which is Boo based implementation, you can see the source here https://github.com/bamboo/unityscript
So, even if you got some compilers ruby to javascript such as Opal, you'll still compile it to JavaScript and not UnityScript, there's a big diferences between them:
Javascript is a prototype based language, and UnityScript is an class based.
UnityScript is more JScript.NET than Javascript.
See more at http://wiki.unity3d.com/index.php?title=UnityScript_versus_JavaScript
I think the easily way to integrate ruby language rather to write a full compiler is integrate IronRuby, which is a Ruby implementation written in C#, which will generate bytecodes for CLR that Unity can read.
I did a similar project with python, which uses IronPython (https://github.com/cesardeazevedo/Unity3D-Python-Editor), it's still very limited, such you still have to call python code from C#, but it works and there's a interpreter that can help you in your development, if you want to create thousands of game objects with simple python commands.
SAP announced Blue Ruby, a version of Ruby that runs inside the ABAP Virtual Machine.
This seems to lend additional credibility to the Ruby language but, except for SAP developers, does this have any applicability to the rest of the Ruby community?
I'm just wondering what other significance this may have. Additional job opportunities, perhaps, for Ruby developers to be hired to work on SAP projects?
Any other potential benefits for Ruby programmers?
Also, something I'm not clear about: Besides MRI and JRuby, how many different implementations are there and why do I, as a Ruby programmer, need any implementation except the MRI? I understand I might need JRuby if I want to integrate with Java libraries. Are there any other times I might need to look into an implementation besides the MRI or JRuby?
I notice that Blue Ruby is compiled. Is that a big benefit and would this be the first compiled version of Ruby?
Sorry - maybe too many questions but this is being discussed as a big deal except I'm not sure why/if it really is. Would be grateful to get some feedback from people who understand Ruby (and I.T.) better than I do.
There are actually quite a few alternative implementations. The reason for so many versions is partly because while Ruby itself has a lot of fans, MRI is often considered to be not quite as nice as the language it hosts.
This is a list of all the other Ruby implementations I know of:
MRI
JRuby for Java. Its speed advantage isn't as great now that Ruby 1.9 is out, but it's still a big player for its integration with Java.
IronRuby (still in development) for .NET
MacRuby for making native Mac OS X applications. It's currently based on Ruby 1.9, but they're going to release a new LLVM-based virtual machine for the next version, which looks to offer a major speed boost and will hopefully be portable to other LLVM target platforms.
MagLev (still very much in development) for high-capacity Web apps. It will probably be a commercial product.
Rubinius is a ground-up reimplementation meant as an alternative to MRI with a much cleaner foundation.
I doubt Blue Ruby will have much of an impact on the general software development landscape. It will probably be nice for SAP programmers and allow them to cast a wider net for potential hires since Ruby is somewhat more popular than ABAP.
All of the current Ruby implementations are compiled to bytecode. Contrary to SAP's claims, as of Ruby 1.9, MRI itself includes a bytecode compiler, though the ability to save the compiled bytecode to disk disappeared somewhere in the process of merging the YARV virtual machine. JRuby is compiled into Java .class files. I don't have a lot of details on MagLev, but it seems safe to say it will take that road as well.
Each implementation has its own use cases. JRuby is useful for much the same reasons Jython is. IronRuby will be useful in a .NET environment, when it exists in a usable state.
Things like this make Ruby more acceptable on the Enterprise level, and hasten the spread of Good Programming Languages.
Of course, Blue Ruby is intended for SAP related people. I don't think is going to have much more of an impact on the Ruby community because most Ruby developers are not related to ABAP development.
The main purpose of Blue Ruby is to bring a powerful Scripting Language into the ABAP world, providing more tools for ABAP developers.
You can read my blog on Blue Ruby providing an SE16 (Data table explorer) emulator.
https://weblogs.sdn.sap.com/pub/wlg/14222
Greetings,
Alvaro "Blag" Tejada Galindo.
Senior ABAP Consultant - SAP Mentor.
There are multiple Ruby implementations in the works right now. Which are you looking forward to and why? Do you actively use a non-MRI implementation in production?
Some of the options include:
Ruby MRI (original 1.8 branch)
YARV (official 1.9)
JRuby
Rubinius
IronRuby - Ironruby.net
MagLev (Thanks Julian) Github link
MacRuby (Thanks Damien Pollet)
Maglev. It will have the speed benefit of all the optimization that has gone into a major Smalltalk VM over many, many year. Plus it will automatically persist all your data pretty much automatically so there is no more need to monkey around with Object-Relational mapping layers and so on.
Ruby 1.9 (YARV) gives us a good idea as to where ruby is headed, but I wouldn't recommend using it for production use. While it's certainly much faster than 1.8, even some parts of the syntax keep changing, so I don't think you could call it stable. It does have some interesting new features and syntax which will surely find their way into all the other implementations over time.
JRuby and IronRuby are useful in that they give ruby access to a whole range of new libraries and environments where ruby couldn't be used otherwise. I've not found much use for them myself yet, but think it's great that they exist. They may allow ruby to infiltrate corporate environments where it wouldn't otherwise be permitted. That can only be a good thing.
Rubinius and Maglev are probably the most interesting projects, but also those where their benefit to the community is likely to be furthest into the future. Rubinius may well develop into a cutting edge 'pure' VM for the ruby language, allowing ruby code to run much faster than it can now. Maglev too seems extremely promising, backed as it is by 20+ years of VM experience. It will also provide features over and beyond a standard VM, but of course these will come at the cost of code portability.
Overall though, what I'm most excited about is the competition between these implementations. Having competing projects all working to make ruby better can only make the ruby ecosystem stronger. From what I've seen too, while the competition exists it is friendly; each project giving and taking ideas from each other. The work done by the JRuby and Rubinius teams in creating a ruby spec is probably the most important outcome so far, as it will help ensure that all implementations remain compatible.
jRuby is stable and reliable today. Maglev is very promising.
No one mentioned MacRuby yet? I guess it's a bit Mac-specific now, but it could probably be made to compile to the GNU or Étoilé objective-c runtimes too.
Also, I'm waiting for Maglev :)
What about Enterprise Ruby? This has been out there for a while.
https://www.phusionpassenger.com/enterprise