[aardvark179]

We are getting there, lots of things work right out of the box just fine. C extensions are still being actively worked on as they often need some amount of patching because of assumptions they make about types and so forth. I think we can reduce that, but I doubt it can will disappear entirely, but in the end I hope extension authors will test on TruffleRuby themselves and patch the code themselves.

[holydude]

I know that you are using Rails as a reference point so is there any ETA when will be most of the features usable ? (openssl,activerecord,nokogiri..etc) ?

[aardvark179]

OpenSSL and nokogiri already work pretty well. ActiveRecord works providing you have a database driver and I’ve got a rough set of patches for pg that I’m working on right now.

I’m working on Discourse at the moment and can run the dB create and migrate tasks and I’m working on the asset compilation pipeline, but it’s all pretty rough and won’t be our final solution.

[holydude]

That sounds promising. I think it's important to keep community in loop and make sure people are aware of limitations and what's already possible and supported.

[ksec]

Just wondering if any Discourse or Rails Core people involved to get it working?

[aardvark179]

Not at the moment. I'm mostly doing some ugly hacks to get stuff working and generating a list of bugs for things we need to fix properly. Looking at my branch I think there's one small change that we will want to do PR for in the end, and some dependencies that we may want to make platform dependent (though they recently did change a couple for JRuby, which also helps us). Pretty much everything else I hope to back out when we've fixed a few of the root causes.

[cutler]

Does that mean languages like Python and Ruby, which rely heavily on C extensions, will be waiting a long time to be fully compatible?

[aardvark179]

It depends on their C API. Ruby doesn't really have one, it just has the exposed internals of the vm, and assumptions that can be made about those which are normally true. That includes type assumptions like VALUE being an integer that you can switch on, and _some_ values such as Qfalse and Qnil being constants that can be used in such switch statements, but it also includes things like being able to have a custom GC mark function for a C data structure.

It's very hard to produce another Ruby implementation without breaking some of those assumptions, but we can hopefully get it down to a small set so the changes needed are minimal.

There are other things like throwing Ruby exceptions across C library boundaries which may work in MRI, but whose behaviour may not be intentional and could already have subtle problems, and I don't think we should be aiming for compatibility in those areas at all. Finding and fixing things like that is normally a good thing to do anyway.

[xfalcox]

How can I convert my ruby script into a native executable for linux?