From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.1 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id A1BA11F461 for ; Wed, 15 May 2019 20:33:43 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id F22071209E7; Thu, 16 May 2019 05:33:37 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id F1295120966 for ; Thu, 16 May 2019 05:33:35 +0900 (JST) Received: by filter0067p3las1.sendgrid.net with SMTP id filter0067p3las1-2986-5CDC77A0-35 2019-05-15 20:33:36.649977588 +0000 UTC m=+181918.076976847 Received: from herokuapp.com (unknown [34.228.185.226]) by ismtpd0030p1iad2.sendgrid.net (SG) with ESMTP id TjxF1lkuSXSzgczpGT8lvg for ; Wed, 15 May 2019 20:33:36.224 +0000 (UTC) Date: Wed, 15 May 2019 20:33:36 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 68149 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 6590 X-Redmine-Issue-Author: headius X-Redmine-Issue-Assignee: hsbt X-Redmine-Sender: Eregon X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr2MWJJnnzCRsAK5xekQLd?= =?us-ascii?Q?lJ70fxqiztlrc6TLVRufTK+LsMiFNqJ6lPYg4et?= =?us-ascii?Q?+PfkBQHTg1LiSUnI2UuhLsMfF0byc1UZgltMPfj?= =?us-ascii?Q?ei7ZJQMmJ2MPbIZeO5j09m544fxETVjEgBXeCpx?= =?us-ascii?Q?b+iWbWk4gPBprgvoRp7IggXMbjXQUBDaDdA=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 92666 Subject: [ruby-core:92666] [Ruby trunk Feature#6590] Dealing with bigdecimal, etc gems in JRuby X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #6590 has been updated by Eregon (Benoit Daloze). @hsbt I wonder, is there a plan for addressing this? There are now many default gems as shown by https://stdgems.org/, a fair amount of them being C extensions and not pure-Ruby. Basically, there will be similar situations with TruffleRuby, where users try to install/update a default gem (there were not many user-submitted issues related to this yet, though). The difference being TruffleRuby can support C extensions, although some gems will need some work to run on TruffleRuby (e.g., currently `bigdecimal` doesn't `gem install` on TruffleRuby). For some of these gems such as `stringio` and `fiddle`, I think it might be better for TruffleRuby to keep TruffleRuby's mostly pure-Ruby implementations instead of using a C extension. This would be possible with e.g., some `RUBY_ENGINE` check in both extconf.rb and the main library file, similar to how it's done for the FFI gem: https://github.com/ffi/ffi/blob/cb3aaca588c6645b5c8186505fb42f809811055f/ext/ffi_c/extconf.rb#L3 https://github.com/ffi/ffi/blob/master/lib/ffi.rb However, that has the downside to be potentially not fully API-compatible if there are additions in the default gem compared to the latest MRI release. For the rest of the gems, it would probably be best for TruffleRuby to use the C extension, to reduce maintenance efforts and make sure to be compatible with MRI's version. However, that might require significant work for C extension compatibility, so it's trade-off if there is already a pure-Ruby implementation. To give some idea, TruffleRuby can currently run these C extension default gems: etc, json, openssl, psych and zlib. And these are untested and probably don't work yet: bigdecimal, date, *dbm, fcntl, fiddle, io-console, stringio, strscan. ---------------------------------------- Feature #6590: Dealing with bigdecimal, etc gems in JRuby https://bugs.ruby-lang.org/issues/6590#change-78030 * Author: headius (Charles Nutter) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Target version: ---------------------------------------- Hello! http://jira.codehaus.org/browse/JRUBY-6704 We have a need to make the "bigdecimal" gem work for JRuby, so that distros (like Red Hat, mentioned in the above bug) and users can have the same gemspec for JRuby with updated bigdecimal gem references. I'm not sure the best way to proceed. The bigdecimal source and gemspec all come from MRI source, and are not versioned separately. That means we can't simply share a repository for the JRuby bits. We could maintain a forked version in our forked "jruby/ruby" repository, but that wouldn't be part of the bigdecimal release cycle then. So I'm looking to you for guidance. The BigDecimal lib is here in JRuby: https://github.com/jruby/jruby/tree/master/src/org/jruby/ext/bigdecimal It might be simplest if for now there's a dummy "bigdecimal" gem pushed for JRuby that does not contain anything, since we would have other complications if we tried to remove BigDecimal from JRuby proper (it is referenced elsewhere int eh code, etc). Thoughts? - Charlie ---Files-------------------------------- noname (500 Bytes) -- https://bugs.ruby-lang.org/