From: Mark Stoodley Date: 2016-03-15T15:41:43-05:00 Subject: [ruby-core:74355] Ruby+OMR: how should we proceed? --===============1037927450== Content-Type: multipart/alternative; boundary="=_alternative 0071AE9A85257F77_=" --=_alternative 0071AE9A85257F77_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="US-ASCII" Hi everybody, I'm looking for your advice on how and where best to publish source code=20 for the Ruby+OMR work that was presented at Ruby Kaigi. Hopefully you'll=20 forgive my long note! I wanted to make sure everyone had enough background = for the questions at the end. I am the lead for the Eclipse OMR project which builds runtime components=20 for use in all kinds of language runtimes (like Ruby!). Many of these=20 components originally came from the IBM J9 Java Virtual Machine. We=20 recently kicked off the Eclipse OMR project at the Eclipse Foundation with = code hosted at GitHub: https://github.com/eclipse/omr Back in December, we presented at Ruby Kaigi on our experiments using=20 these components inside CRuby: * Matthew Gaudet's "Experiments in sharing Java VM technology with=20 CRuby" =20 http://www.slideshare.net/MatthewGaudet/experiments-in-sharing-java-vm-tech= nology-with-cruby * Robert Young's and Craig Lehmann's "It's dangerous to GC alone. Take = this!" =20 http://www.slideshare.net/craiglehmann/the-omr-gc-talk-ruby-kaigi-2015 Since many of the OMR components are now available as open source, we are=20 in the process of updating our Ruby+OMR Technology Preview release that we = made available in mostly binary form in December at=20 https://github.com/rubyomr-preview/rubyomr-preview to now include all the=20 source code needed to build with the open OMR components. We'll contribute = the "Ruby glue" code, which connects the language agnostic OMR components=20 into the CRuby runtime, to the OMR project initially under its license. We had the thought to put all this code on GitHub (unless you'd prefer it=20 somewhere else?), but we don't want anyone to think we're forking CRuby.=20 We are NOT forking CRuby. We will donate all the source code needed to=20 consume the OMR components to the CRuby community, if that's something=20 you're interested in. The open code will already be licensed to enable=20 your use anyway, if you choose. But we thought you might like to take a look at it first :) . That's why=20 we created the Ruby+OMR Technology Preview project in the first place.=20 Also, since not all of the OMR components are in the open yet (for=20 example, the OMR JIT compiler is not yet available in source form), we=20 still want people to be able to try those parts as used for Ruby via our=20 Docker images for Linux on x86-64, OpenPOWER, and LinuxONE. We're really keen to get your feedback! Before we do anything, we thought we'd reach out here to see how you would = prefer us to proceed. Our thinking was to create a git repository with the = baseline Ruby 2.2.3 release we used along with a single commit for the OMR = changes needed to build Ruby+OMR. Moving forward, we'll update the base Ruby code to be more current as well = as adding and augmenting the source components for the remaining OMR=20 components as they become available in source form at the Eclipse OMR=20 project.=20 What do you think? Is this of interest to the CRuby community? Would you=20 prefer that we proceed any differently than I outlined above? --mark --=_alternative 0071AE9A85257F77_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="US-ASCII" Hi everybody,

I'm looking for your advice on how and where best to publish source code for the Ruby+OMR work that was presented at Ruby Kaigi. Hopefully you'll forgive my long note! I wanted to make sure everyone had enough background for the questions at the end.
I am the lead for the Eclipse OMR p= roject which builds runtime components for use in all kinds of language runtimes (like Ruby!). Many of these components originally came from the IBM J9 Java Virtual Machine. We recently kicked off the Eclipse OMR project at the Eclipse Foundation with code hosted at GitHub:
h= ttps://github.com/eclipse/omr

Back in December, we presented at Ruby Kaigi on our experiments using these components inside CRuby:
* Matthew Gaudet's "= Experiments in sharing Java VM technology with CRuby"
= http://www.slideshare.net/M= atthewGaudet/experiments-in-sharing-java-vm-technology-with-cruby

* Robert Young's = and Craig Lehmann's "It's dangerous to GC alone. Take this!"
http://www.slideshare.net/craiglehm= ann/the-omr-gc-talk-ruby-kaigi-2015

Since many of the OMR components are now available as open source, we are in the process of updating our Ruby+OMR Technology Preview release that we made available in mostly binary form in December at https://github.co= m/rubyomr-preview/rubyomr-previewto now include all the source code needed to build with the open OMR co= mponents. We'll contribute the "Ruby glue" code, which connects the language agnostic OMR components into the CRuby runtime, to the OMR project initially under its license.

We had = the thought to put all this code on GitHub (unless you'd prefer it somewhere else?), but we don't want anyone to think we're forking CRuby. We are NOT forking CRuby. We will donate all the source code needed to consume the OMR components to the CRuby commu= nity, if that's something you're interested in. The open code will already be licensed to enable your use anyway, if you choose.

But we thought you might like to take a look at it first :) . That's why we created the Ruby+OMR Technology Previ= ew project in the first place. Also, since not all of the OMR components are in the open yet (for example, the OMR JIT compiler is not yet available in source form), we still want people to be able to try those parts as used for Ruby via our Docker images for Linux on x86-64, OpenPOWER, and LinuxONE.

We're really kee= n to get your feedback!

Be= fore we do anything, we thought we'd reach out here to see how you would prefer us to proceed. Our thinking was to create a git repository with the baseline Ruby 2.2.3 release we used along with a single commit for the OMR changes needed to build Ruby+OM= R.

Moving forward, we'll u= pdate the base Ruby code to be more current as well as adding and augmenting the source components for the remaining OMR components as they become available in source form at the Eclipse OMR project.

What do you think? Is this of interest to the CRuby community? Would you prefer that we proceed any differently than I outlined above?

--m= ark

--=_alternative 0071AE9A85257F77_=-- --===============1037927450== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Unsubscribe: --===============1037927450==--