January 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:111749] [Ruby master Feature#19328] Please bring back the use of Hash objects for keyword arguments
by randallcoding (Randall Coding) 09 Jan '23

09 Jan '23

Issue #19328 has been reported by randallcoding (Randall Coding). ---------------------------------------- Feature #19328: Please bring back the use of Hash objects for keyword arguments https://bugs.ruby-lang.org/issues/19328 * Author: randallcoding (Randall Coding) * Status: Open * Priority: Normal ---------------------------------------- The change in 3.0 (linked here https://www.ruby-lang.org/en/news/2019/12/12/separation-of-positional-and-k…) no longer automatically converts Hash objects into keyword arguments. This takes Ruby away from what it has always been about: being as intuitive and developer friendly as possible. The solution given to make a hash into keywords is to perform a double splat (**) on the hash object. This is confusing and esoteric, not to mention will require a lot of old code to be re-written. For example I have code that was written like this ``` ruby def Foo(a:, b:) puts a + b end ``` which I can call by simply using ``` ruby myhash = {a:3, b:5} Foo(myhash) ``` Look at the clarity, simplicity and elegance. The interpreter takes care of the messy and unnecessary bits and our code is easily understandable by other humans. But now for the same function we need to write ``` ruby Foo(**myhash) ``` We have to add superficial extra strokes (from the human perspective) to achieve what our intelligent interpreter once knew we wanted with less hassle. Let's not become like those other language! Please keep Ruby intuitive and developer friendly and make this feature what is was before. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:111752] [Ruby master Bug#19329] "gem install" installs logs and other "noisy", non-reproducible files
by apteryx (Maxim C.) 09 Jan '23

09 Jan '23

Issue #19329 has been reported by apteryx (Maxim C.). ---------------------------------------- Bug #19329: "gem install" installs logs and other "noisy", non-reproducible files https://bugs.ruby-lang.org/issues/19329 * Author: apteryx (Maxim C.) * Status: Open * Priority: Normal * ruby -v: 2.7.4 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hello, Ruby! When building/installing C extensions via `gem install`, log files produced during the build get installed to the `GEM_VENDOR` location. This is undesirable because these files are not functional and they contain non-reproducible information such as temporary compilation file names or similar. Would it be possible to *not* have any log file installed, or have an option to turn it off? Reproducer, using nokogiri as an example: ``` $ GEM_VENDOR=output gem install nokogiri-1.13.10.gem --verbose --local --ignore-dependencies --vendor --bindir output/bin ``` $ find output/extensions/ output/extensions/ output/extensions/x86_64-linux output/extensions/x86_64-linux/2.7.0 output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10 output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/mkmf.log output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/nokogiri.so output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2 output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlversion.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/SAX.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/entities.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/encoding.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/parser.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/parserInternals.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlerror.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/HTMLparser.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/HTMLtree.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/debugXML.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/tree.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/list.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/hash.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xpath.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xpathInternals.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xpointer.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xinclude.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlIO.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlmemory.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/nanohttp.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/nanoftp.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/uri.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/valid.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xlink.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/catalog.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/threads.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/globals.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/c14n.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlautomata.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlregexp.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlmodule.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlschemas.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/schemasInternals.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlschemastypes.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlstring.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlunicode.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlreader.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/relaxng.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/dict.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/SAX2.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlexports.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlwriter.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/chvalid.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/pattern.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/xmlsave.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxml2/libxml/schematron.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/xsltconfig.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/xslt.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/xsltutils.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/pattern.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/templates.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/variables.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/keys.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/numbersInternals.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/extensions.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/extra.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/functions.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/namespaces.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/imports.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/attributes.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/documents.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/preproc.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/transform.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/security.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/xsltInternals.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/xsltexports.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libxslt/xsltlocale.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libexslt output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libexslt/exslt.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libexslt/exsltexports.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/nokogiri/include/libexslt/exsltconfig.h output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/gem_make.out output/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/gem.build_complete ``` The mkmf.log file contains non-deterministic temporary file names, as shown in the following diffoscope: ``` Installing nokogiri captures a build time mkmf.log file that contains a non-deterministic file name. See the following diffoscope diff across two builds: $ diffoscope /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10{,-check} --- /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10 +++ /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10-check │ --- /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10/lib ├── +++ /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10-check/lib │ │ --- /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10/lib/ruby │ ├── +++ /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10-check/lib/ruby │ │ │ --- /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10/lib/ruby/vendor_ruby │ │ ├── +++ /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10-check/lib/ruby/vendor_ruby │ │ │ │ --- /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10/lib/ruby/vendor_ruby/extensions │ │ │ ├── +++ /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10-check/lib/ruby/vendor_ruby/extensions │ │ │ │ │ --- /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10/lib/ruby/vendor_ruby/extensions/x86_64-linux │ │ │ │ ├── +++ /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10-check/lib/ruby/vendor_ruby/extensions/x86_64-linux │ │ │ │ │ │ --- /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10/lib/ruby/vendor_ruby/extensions/x86_64-linux/2.7.0 │ │ │ │ │ ├── +++ /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10-check/lib/ruby/vendor_ruby/extensions/x86_64-linux/2.7.0 │ │ │ │ │ │ │ --- /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10/lib/ruby/vendor_ruby/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10 │ │ │ │ │ │ ├── +++ /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10-check/lib/ruby/vendor_ruby/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10 │ │ │ │ │ │ │ │ --- /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10/lib/ruby/vendor_ruby/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/mkmf.log │ │ │ │ │ │ │ ├── +++ /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10-check/lib/ruby/vendor_ruby/extensions/x86_64-linux/2.7.0/nokogiri-1.13.10/mkmf.log │ │ │ │ │ │ │ │ @@ -607,15 +607,15 @@ │ │ │ │ │ │ │ │ 11: │ │ │ │ │ │ │ │ 12: return !!argv[argc]; │ │ │ │ │ │ │ │ 13: } │ │ │ │ │ │ │ │ 14: int t(void) { void ((*volatile p)()); p = (void ((*)()))rb_category_warning; return !p; } │ │ │ │ │ │ │ │ /* end */ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ "gcc -o conftest -I/gnu/store/j4z07lyi1ykk8bc68h1p4bpj1il9dn3f-ruby-2.7.4/include/ruby-2.7.0/x86_64-linux -I/gnu/store/j4z07lyi1ykk8bc68h1p4bpj1il9dn3f-ruby-2.7.4/include/ruby-2.7.0/ruby/backward -I/gnu/store/j4z07lyi1ykk8bc68h1p4bpj1il9dn3f-ruby-2.7.4/include/ruby-2.7.0 -I. -I/gnu/store/g3y6ifhm0751vgsxv90yipfw6mk189kj-libxml2-2.9.12/include/libxml2 -I/gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10/lib/ruby/vendor_ruby/gems/nokogiri-1.13.10/ext/nokogiri/ports/x86_64-linux/libgumbo/1.0.0-nokogiri/include -g -O2 -fPIC -std=c99 -Wno-declaration-after-statement -g -Winline -Wmissing-noreturn conftest.c -L. -L/gnu/store/j4z07lyi1ykk8bc68h1p4bpj1il9dn3f-ruby-2.7.4/lib -Wl,-rpath,/gnu/store/j4z07lyi1ykk8bc68h1p4bpj1il9dn3f-ruby-2.7.4/lib -L/gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10/lib/ruby/vendor_ruby/gems/nokogiri-1.13.10/ext/nokogiri/ports/x86_64-linux/libgumbo/1.0.0-nokogiri/lib -Wl,-rpath,/gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10/lib/ruby/vendor_ruby/gems/nokogiri-1.13.10/ext/nokogiri/ports/x86_64-linux/libgumbo/1.0.0-nokogiri/lib -L. -fstack-protector-strong -rdynamic -Wl,-export-dynamic -lexslt -lxslt -lxml2 -lz /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10/lib/ruby/vendor_ruby/gems/nokogiri-1.13.10/ext/nokogiri/ports/x86_64-linux/libgumbo/1.0.0-nokogiri/lib/libgumbo.a -Wl,-rpath,/gnu/store/j4z07lyi1ykk8bc68h1p4bpj1il9dn3f-ruby-2.7.4/lib -L/gnu/store/j4z07lyi1ykk8bc68h1p4bpj1il9dn3f-ruby-2.7.4/lib -lruby -lexslt -lxslt -lxml2 -lz /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10/lib/ruby/vendor_ruby/gems/nokogiri-1.13.10/ext/nokogiri/ports/x86_64-linux/libgumbo/1.0.0-nokogiri/lib/libgumbo.a -lm -lc" │ │ │ │ │ │ │ │ +ld: /tmp/guix-build-ruby-nokogiri-1.13.10.drv-0/cc6zUuPL.o: in function `t': │ │ │ │ │ │ │ │ -ld: /tmp/guix-build-ruby-nokogiri-1.13.10.drv-0/ccaC0A0J.o: in function `t': │ │ │ │ │ │ │ │ /gnu/store/9aba01y3kfdcpxjqg5wx2sbvz4mss5hq-ruby-nokogiri-1.13.10/lib/ruby/vendor_ruby/gems/nokogiri-1.13.10/ext/nokogiri/conftest.c:15: undefined reference to `rb_category_warning' │ │ │ │ │ │ │ │ collect2: error: ld returned 1 exit status │ │ │ │ │ │ │ │ checked program was: │ │ │ │ │ │ │ │ /* begin */ │ │ │ │ │ │ │ │ 1: #include "ruby.h" │ │ │ │ │ │ │ │ 2: │ │ │ │ │ │ │ │ 3: /*top*/ ``` The original issue was reported here: https://github.com/sparklemotion/nokogiri/issues/2755 Thank you! -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111696] [Ruby master Feature#19317] Unicode ICU Full case mapping
by noraj (Alexandre ZANNI) 08 Jan '23

08 Jan '23

Issue #19317 has been reported by noraj (Alexandre ZANNI). ---------------------------------------- Feature #19317: Unicode ICU Full case mapping https://bugs.ruby-lang.org/issues/19317 * Author: noraj (Alexandre ZANNI) * Status: Open * Priority: Normal ---------------------------------------- As announced in [Case Mapping](https://docs.ruby-lang.org/en/master/case_mapping_rdoc.html#label-…, Ruby support for Unicode case mapping is not complete yet. Unicode supports in Ruby is pretty awesome, it works by default nearly everywhere, things are implemented the right way and works as expected by the UTRs. But some features are still missing. To reach [ICU Full Case Mapping support](https://unicode-org.github.io/icu/userguide/transforms/casemappings.html#full-language-specific-case-mapping), a few points need to be enhanced. ### context-sensitive case mapping * [ ] cf. [Table 3-17 (Context Specification for Casing) of the Unicode standard](https://www.unicode.org/versions/Unicode15.0.0/ch03.pdf) and [ucd/SpecialCasing.txt](https://www.unicode.org/Public/UCD/latest/ucd/Specia…. ```ruby "ΣΣ".downcase # returns σσ instead of σς ``` Output examples in EMCAScript: ``` Σ ➡️ σ Σa ➡️ σa aΣ ➡️ aς aΣa ➡️ aσa ΣA ➡️ σa aΣ a ➡️ aς a Σ1 ➡️ σ1 aΣ1 ➡️ aς1 ΣΣ ➡️ σς ``` ## language-sensitive case mapping * [ ] Lithuanian rules * [x] Turkish and Azeri ```ruby "I".downcase # => "i" "I".downcase(:turkic) # => "ı" "I\u0307".upcase # => "İ" "I\u0307".upcase(:lithuanian) # => "İ" instead of "I" ``` * [ ] using some standard locale / language codes Also, it's true that for now there are only a few language-sensitive rules (for Lithuanian, Turkish and Azeri) but why: - adding a `:turkic` symbol and not a `:azeri`? - using full english arbitrary (why `turkic` and not `turkish`?) language name rather than some [ICU locale IDs](https://unicode-org.github.io/icu/userguide/locale/)? - Language code ISO-639 standard - Script code Unicode ISO 15924 Registry - country code ISO-3166 standard So I would rather see something like that ```ruby "placeholder".upcase(locale: :tr_TR) "placeholder".upcase(lang: :tr) ``` -- https://bugs.ruby-lang.org/

4 6

[ruby-core:111579] [Ruby master Feature#19300] Move public objects from Kernel to Object
by zverok (Victor Shepelev) 08 Jan '23

08 Jan '23

Issue #19300 has been reported by zverok (Victor Shepelev). ---------------------------------------- Feature #19300: Move public objects from Kernel to Object https://bugs.ruby-lang.org/issues/19300 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- In my understanding, `Kernel` is a container for methods that are perceived as "global", and are available inside every objects as its private methods, like `puts` ```ruby class A def foo = puts "foo" end a = A.new a.foo # prints "foo" a.puts 'bar' # private method `puts' called for #<A:0x00007f39a683db28> (NoMethodError) ``` There are, though, exactly three (if I am not missing something) methods that, **according to documentation**, break this intuition and belong to [Kernel](https://docs.ruby-lang.org/en/master/Kernel.html): * `clone` * `tap` * `then` All those methods are public method for a receiver, and they mostly make sense with an explicit receiver. The most confusing of them is `#clone`, which is close cousin of `#dup`, but it is [Kernel#clone](https://docs.ruby-lang.org/en/master/Kernel.html#method-i-clo… and [Object#dup](https://docs.ruby-lang.org/en/master/Object.html#method-i-dup). This state of things is mostly harmless in practical code, but very inconvenient for teaching, reasoning about the meaning of modules and objects, and lookup for documentation. **But**, in the description above, **according to documentation** is important statement. Because according to introspection, method definitions are spread differently: ```ruby puts "Public" Object.new .then { |o| o.methods.group_by { o.method(_1).owner } } .each { puts "#{_1}: #{_2.sort.join(', ')}" } puts puts "Private:" Object.new .then { |o| o.private_methods.group_by { o.method(_1).owner } } .each { puts "#{_1}: #{_2.sort.join(', ')}" } ``` Output: ``` Public Kernel: !~, <=>, ===, class, clone, define_singleton_method, display, dup, enum_for, eql?, extend, freeze, frozen?, hash, inspect, instance_of?, instance_variable_defined?, instance_variable_get, instance_variable_set, instance_variables, is_a?, itself, kind_of?, method, methods, nil?, object_id, private_methods, protected_methods, public_method, public_methods, public_send, remove_instance_variable, respond_to?, send, singleton_class, singleton_method, singleton_methods, tap, then, to_enum, to_s, yield_self BasicObject: !, !=, ==, __id__, __send__, equal?, instance_eval, instance_exec Private: Kernel: Array, Complex, Float, Hash, Integer, Rational, String, __callee__, __dir__, __method__, `, abort, at_exit, autoload, autoload?, binding, block_given?, caller, caller_locations, catch, eval, exec, exit, exit!, fail, fork, format, gem, gem_original_require, gets, global_variables, initialize_clone, initialize_copy, initialize_dup, iterator?, lambda, load, local_variables, loop, open, p, pp, print, printf, proc, putc, puts, raise, rand, readline, readlines, require, require_relative, respond_to_missing?, select, set_trace_func, sleep, spawn, sprintf, srand, syscall, system, test, throw, trace_var, trap, untrace_var, warn BasicObject: initialize, method_missing, singleton_method_added, singleton_method_removed, singleton_method_undefined ``` E.g., internally, `Object` doesn't have _any_ method defined, and is just a `BasicObject` with `Kernel` included. So, there are three questions/proposals: 1. Does this disposition has some internal sense, or it is more of a historical thing? 2. Can it be changed so that public methods belonged to `Object` instead of `Kernel`? 3. If the answer to (2) is "no", can at least docs for `clone`, `tap` and `then` be adjusted to follow other public methods in pretending they are `Object`'s features? -- https://bugs.ruby-lang.org/

5 14

[ruby-core:111732] [Ruby master Bug#19005] Ruby interpreter compiled XCode 14 cannot build some native gems on macOS
by nobu (Nobuyoshi Nakada) 08 Jan '23

08 Jan '23

Issue #19005 has been updated by nobu (Nobuyoshi Nakada). Adding `-no_fixup_chains -undefined dynamic_lookup` together will break old compilers. `-no_fixup_chains` should be checked solely **before** `-undefined dynamic_lookup`, at least. ---------------------------------------- Bug #19005: Ruby interpreter compiled XCode 14 cannot build some native gems on macOS https://bugs.ruby-lang.org/issues/19005#change-101137 * Author: stanhu (Stan Hu) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.6p219 (2022-04-12 revision 44c8bfa984) [arm64-darwin21] * Backport: 2.7: DONE, 3.0: DONE, 3.1: DONE ---------------------------------------- This seems related to https://bugs.ruby-lang.org/issues/18912 and https://bugs.ruby-lang.org/issues/18981 . Steps to reproduce: 1. Upgrade to XCode 14. 2. Compile a new Ruby interpreter. I used the version provided in https://github.com/ruby/ruby/pull/6297 with `./configure --prefix=/tmp/ruby --with-openssl-dir=$(brew --prefix openssl(a)1.1) --with-readline-dir=$(brew --prefix readline) --enable-shared`. 3. Confirm that `-Wl,-undefined,dynamic_lookup` is no longer available: ``` irb(main):001:0> RbConfig::CONFIG['DLDFLAGS'] => "-Wl,-multiply_defined,suppress" ``` 4. Ran `gem install pg_query` (`gem install ffi-yajl` will also fail). Error: ``` linking shared-object pg_query/pg_query.bundle Undefined symbols for architecture arm64: "Init_pg_query", referenced from: -exported_symbol[s_list] command line option (maybe you meant: _Init_pg_query) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` I can workaround the problem by doing: ``` gem install pg_query -- --with-ldflags="-Wl,-undefined,dynamic_lookup" ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111730] [Ruby master Bug#19005] Ruby interpreter compiled XCode 14 cannot build some native gems on macOS
by stanhu (Stan Hu) 07 Jan '23

07 Jan '23

Issue #19005 has been updated by stanhu (Stan Hu). Submitted https://github.com/ruby/ruby/pull/7086. ---------------------------------------- Bug #19005: Ruby interpreter compiled XCode 14 cannot build some native gems on macOS https://bugs.ruby-lang.org/issues/19005#change-101133 * Author: stanhu (Stan Hu) * Status: Discussion * Priority: Normal * ruby -v: ruby 2.7.6p219 (2022-04-12 revision 44c8bfa984) [arm64-darwin21] * Backport: 2.7: DONE, 3.0: DONE, 3.1: DONE ---------------------------------------- This seems related to https://bugs.ruby-lang.org/issues/18912 and https://bugs.ruby-lang.org/issues/18981 . Steps to reproduce: 1. Upgrade to XCode 14. 2. Compile a new Ruby interpreter. I used the version provided in https://github.com/ruby/ruby/pull/6297 with `./configure --prefix=/tmp/ruby --with-openssl-dir=$(brew --prefix openssl(a)1.1) --with-readline-dir=$(brew --prefix readline) --enable-shared`. 3. Confirm that `-Wl,-undefined,dynamic_lookup` is no longer available: ``` irb(main):001:0> RbConfig::CONFIG['DLDFLAGS'] => "-Wl,-multiply_defined,suppress" ``` 4. Ran `gem install pg_query` (`gem install ffi-yajl` will also fail). Error: ``` linking shared-object pg_query/pg_query.bundle Undefined symbols for architecture arm64: "Init_pg_query", referenced from: -exported_symbol[s_list] command line option (maybe you meant: _Init_pg_query) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` I can workaround the problem by doing: ``` gem install pg_query -- --with-ldflags="-Wl,-undefined,dynamic_lookup" ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111729] [Ruby master Bug#19005] Ruby interpreter compiled XCode 14 cannot build some native gems on macOS
by stanhu (Stan Hu) 07 Jan '23

07 Jan '23

Issue #19005 has been updated by stanhu (Stan Hu). A possible fix is to squelch this warning via `-no_fixup_chains`: ```diff diff --git a/configure.ac b/configure.ac index a2a0c1e387..d653a13bb8 100644 --- a/configure.ac +++ b/configure.ac @@ -3104,7 +3104,7 @@ AS_IF([test "$rb_cv_dlopen" = yes], [ AC_SUBST(ADDITIONAL_DLDFLAGS, "") for flag in \ "-multiply_defined suppress" \ - "-undefined dynamic_lookup" \ + "-no_fixup_chains -undefined dynamic_lookup" \ ; do test "x${linker_flag}" = x || flag="${linker_flag}`echo ${flag} | tr ' ' ,`" RUBY_TRY_LDFLAGS([$flag], [], [flag=]) ``` I should note that bazel dropped `-undefined dynamic_lookup` entirely in https://github.com/bazelbuild/bazel/issues/16413, but that will break some gems that are not ready for this. ---------------------------------------- Bug #19005: Ruby interpreter compiled XCode 14 cannot build some native gems on macOS https://bugs.ruby-lang.org/issues/19005#change-101132 * Author: stanhu (Stan Hu) * Status: Discussion * Priority: Normal * ruby -v: ruby 2.7.6p219 (2022-04-12 revision 44c8bfa984) [arm64-darwin21] * Backport: 2.7: DONE, 3.0: DONE, 3.1: DONE ---------------------------------------- This seems related to https://bugs.ruby-lang.org/issues/18912 and https://bugs.ruby-lang.org/issues/18981 . Steps to reproduce: 1. Upgrade to XCode 14. 2. Compile a new Ruby interpreter. I used the version provided in https://github.com/ruby/ruby/pull/6297 with `./configure --prefix=/tmp/ruby --with-openssl-dir=$(brew --prefix openssl(a)1.1) --with-readline-dir=$(brew --prefix readline) --enable-shared`. 3. Confirm that `-Wl,-undefined,dynamic_lookup` is no longer available: ``` irb(main):001:0> RbConfig::CONFIG['DLDFLAGS'] => "-Wl,-multiply_defined,suppress" ``` 4. Ran `gem install pg_query` (`gem install ffi-yajl` will also fail). Error: ``` linking shared-object pg_query/pg_query.bundle Undefined symbols for architecture arm64: "Init_pg_query", referenced from: -exported_symbol[s_list] command line option (maybe you meant: _Init_pg_query) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` I can workaround the problem by doing: ``` gem install pg_query -- --with-ldflags="-Wl,-undefined,dynamic_lookup" ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111708] [Ruby master Bug#19321] BigDecimal multiplication giving different result since Ruby 3.1
by alexandruanca (Alexandru Anca) 07 Jan '23

07 Jan '23

Issue #19321 has been reported by alexandruanca (Alexandru Anca). ---------------------------------------- Bug #19321: BigDecimal multiplication giving different result since Ruby 3.1 https://bugs.ruby-lang.org/issues/19321 * Author: alexandruanca (Alexandru Anca) * Status: Open * Priority: Normal * ruby -v: 3.1.3 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I have this math operation 120.to_d * 0.07 and I noticed that since upgrading to Ruby 3.1 I get different results. I would expect to get the same result as in previous versions. ``` rbenv local 3.0.3 ➜ irb require 'bigdecimal/util.rb' (120.to_d * 0.07).to_s('F') => "8.4000000000000012" ``` ``` rbenv local 3.1.3 ✗ irb require 'bigdecimal/util.rb' (120.to_d * 0.07).to_s('F') => "8.4" ``` It looks like the change has been introduced in Ruby 3.1. I tested Ruby 2.7.0 and I get the same result as in 3.0 ("8.4000000000000012") I saw in the release notes that there were changes to bigdecimal so I am not sure if this is expected or it's a bug -- https://bugs.ruby-lang.org/

3 4

[ruby-core:111727] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by Eregon (Benoit Daloze) 07 Jan '23

07 Jan '23

Issue #18285 has been updated by Eregon (Benoit Daloze). It might be interesting to limit the depth or maximum number of fields shown for inspect via some argument/fiber locals (so it'd work to some extent with custom `#inspect`)/etc. But that should be a separate new proposal then. ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-101129 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal ---------------------------------------- Hello there! I'm working at Datadog on the ddtrace gem -- https://github.com/DataDog/dd-trace-rb and we ran into this issue on one of our internal testing applications. I also blogged about this issue in <https://ivoanjo.me/blog/2021/11/01/nomethoderror-ruby-cost/>. ### Background While testing an application that threw a lot of `NoMethodError`s in a Rails controller (this was used for validation), we discovered that service performance was very much impacted when we were logging these exceptions. While investigating with a profiler, the performance impact was caused by calls to `NoMethodError#message`, because this Rails controller had a quite complex `#inspect` method, that was getting called every time we tried to get the `#message` from the exception. ### How to reproduce ```ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'benchmark-ips' end puts RUBY_DESCRIPTION class GemInformation # ... def get_no_method_error method_does_not_exist rescue => e e end def get_runtime_error raise 'Another Error' rescue => e e end def inspect # <-- expensive method gets called when calling NoMethodError#message Gem::Specification._all.inspect end end NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error Benchmark.ips do |x| x.config(:time => 5, :warmup => 2) x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message } x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message } x.compare! end ``` ### Expectation and result Getting the `#message` from a `NoMethodError` should be no costly than getting it from any other exception. In reality: ``` ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] no method error message cost 115.390 (± 1.7%) i/s - 580.000 in 5.027822s runtime error message cost 6.938M (± 0.5%) i/s - 35.334M in 5.092617s Comparison: runtime error message cost: 6938381.6 i/s no method error message cost: 115.4 i/s - 60130.02x (± 0.00) slower ``` ### Suggested solutions 1. Do not call `#inspect` on the object on which the method was not found (see <https://github.com/ruby/ruby/blob/e0915ba67964d843832148aeca29a1f8244ca7b1/…>) 2. Cache result of calling `#message` after the first call. Ideally this should be done together with suggestion 1. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111726] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by Eregon (Benoit Daloze) 07 Jan '23

07 Jan '23

Issue #18285 has been updated by Eregon (Benoit Daloze). zverok (Victor Shepelev) wrote in #note-26: > Honestly, I would much rather prefer users to be advised "make sure your `#inspect` is efficient" than make everybody suffer. That's not reasonable to ask. `#inspect` was never meant to be efficient but to provide maximum debugging information. It's simply too expensive to call for a large object graph for an exception message (even with no one redefining `inspect`). If the receiver is known/the inspect method is known to be reasonably fast (e.g. for a String or some "leaf" object) it's fine, but in general it's not fine to include arbitrary `obj.inspect` in error messages, it's too expensive and too slow. ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-101128 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal ---------------------------------------- Hello there! I'm working at Datadog on the ddtrace gem -- https://github.com/DataDog/dd-trace-rb and we ran into this issue on one of our internal testing applications. I also blogged about this issue in <https://ivoanjo.me/blog/2021/11/01/nomethoderror-ruby-cost/>. ### Background While testing an application that threw a lot of `NoMethodError`s in a Rails controller (this was used for validation), we discovered that service performance was very much impacted when we were logging these exceptions. While investigating with a profiler, the performance impact was caused by calls to `NoMethodError#message`, because this Rails controller had a quite complex `#inspect` method, that was getting called every time we tried to get the `#message` from the exception. ### How to reproduce ```ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'benchmark-ips' end puts RUBY_DESCRIPTION class GemInformation # ... def get_no_method_error method_does_not_exist rescue => e e end def get_runtime_error raise 'Another Error' rescue => e e end def inspect # <-- expensive method gets called when calling NoMethodError#message Gem::Specification._all.inspect end end NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error Benchmark.ips do |x| x.config(:time => 5, :warmup => 2) x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message } x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message } x.compare! end ``` ### Expectation and result Getting the `#message` from a `NoMethodError` should be no costly than getting it from any other exception. In reality: ``` ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] no method error message cost 115.390 (± 1.7%) i/s - 580.000 in 5.027822s runtime error message cost 6.938M (± 0.5%) i/s - 35.334M in 5.092617s Comparison: runtime error message cost: 6938381.6 i/s no method error message cost: 115.4 i/s - 60130.02x (± 0.00) slower ``` ### Suggested solutions 1. Do not call `#inspect` on the object on which the method was not found (see <https://github.com/ruby/ruby/blob/e0915ba67964d843832148aeca29a1f8244ca7b1/…>) 2. Cache result of calling `#message` after the first call. Ideally this should be done together with suggestion 1. -- https://bugs.ruby-lang.org/

1 0