- ruby-core - ml.ruby-lang.org

[ruby-core:111064] [Ruby master Feature#19000] Data: Add "Copy with changes method" [Follow-on to #16122 Data: simple immutable value object]

by p8 (Petrik de Heus)

Issue #19000 has been updated by p8 (Petrik de Heus). If `dup` is chosen would it make sense to always allow `dup` methods to take arguments for consistency? For example, it would allow the following code in Rails ```ruby firm = Firm.first.dup firm.account = Account.first assert_queries(2) { firm.save! } ``` (https://github.com/rails/rails/blob/8e34831f97acd7448fd68a6ac130694079aea95…) to be written as: ```ruby firm = Firm.first.dup(account: Account.first) assert_queries(2) { firm.save! } ``` ---------------------------------------- Feature #19000: Data: Add "Copy with changes method" [Follow-on to #16122 Data: simple immutable value object] https://bugs.ruby-lang.org/issues/19000#change-100324 * Author: RubyBugs (A Nonymous) * Status: Open * Priority: Normal ---------------------------------------- *As requested: extracted a follow-up to #16122 Data: simple immutable value object from [this comment](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/109815)* # Proposal: Add a "Copy with changes" method to Data Assume the proposed `Data.define` exists. Seeing examples from the [[Values gem]](https://github.com/ms-ati/Values): ```ruby # A new class Point = Data.def(:x, :y) # An immutable instance Origin = Point.with(x: 0, y: 0) # Q: How do we make copies that change 1 or more values? right = Origin.with(x: 1.0) up = Origin.with(y: 1.0) up_and_right = right.with(y: up.y) # In loops movements = [ { x: +0.5 }, { x: +0.5 }, { y: -1.0 }, { x: +0.5 }, ] # position = Point(x: 1.5, y: -1.0) position = movements.inject(Origin) { |p, move| p.with(**move) } ``` ## Proposed detail: Call this method: `#with` ```ruby Money = Data.define(:amount, :currency) account = Money.new(amount: 100, currency: 'USD') transactions = [+10, -5, +15] account = transactions.inject(account) { |a, t| a.with(amount: a.amount + t) } #=> Money(amount: 120, currency: "USD") ``` ## Why add this "Copy with changes" method to the Data simple immutable value class? Called on an instance, it returns a new instance with only the provided parameters changed. This API affordance is now **widely adopted across many languages** for its usefulness. Why is it so useful? Because copying immutable value object instances, with 1 or more discrete changes to specific fields, is the proper and ubiquitous pattern that takes the place of mutation when working with immutable value objects. **Other languages** C# Records: “immutable record structs — Non-destructive mutation” — is called `with { ... }` https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-t… Scala Case Classes — is called `#copy` https://docs.scala-lang.org/tour/case-classes.html Java 14+ Records — Brian Goetz at Oracle is working on adding a with copy constructor inspired by C# above as we speak, likely to be called `#with` https://mail.openjdk.org/pipermail/amber-spec-experts/2022-June/003461.html Rust “Struct Update Syntax” via `..` syntax in constructor https://doc.rust-lang.org/book/ch05-01-defining-structs.html#creating-insta… ## Alternatives Without a copy-with-changes method, one must construct entirely new instances using the constructor. This can either be (a) fully spelled out as boilerplate code, or (b) use a symmetrical `#to_h` to feed the keyword-args constructor. **(a) Boilerplate using constructor** ```ruby Point = Data.define(:x, :y, :z) Origin = Point.new(x: 0.0, y: 0.0, z: 0.0) change = { z: -1.5 } # Have to use full constructor -- does this even work? point = Point.new(x: Origin.x, y: Origin.y, **change) ``` **(b) Using a separately proposed `#to_h` method and constructor symmetry** ```ruby Point = Data.define(:x, :y, :z) Origin = Point.new(x: 0.0, y: 0.0, z: 0.0) change = { z: -1.5 } # Have to use full constructor -- does this even work? point = Point.new(**(Origin.to_h.merge(change))) ``` Notice that the above are not ergonomic -- leading so many of our peer language communities to adopt the `#with` method to copy an instance with discrete changes. -- https://bugs.ruby-lang.org/

1 year, 5 months

1
0
0 0

[ruby-core:111055] [Ruby master Feature#19099] Support `private_constant` for an undefined constant

by okuramasafumi (Masafumi OKURA)

Issue #19099 has been updated by okuramasafumi (Masafumi OKURA). I wonder if the code below is acceptable: ```ruby class C private_constant { X = ... } end ``` Here, `private_constant` takes a block and every constant defined there are private. This is especially useful when defining multiple private constants at once. ---------------------------------------- Feature #19099: Support `private_constant` for an undefined constant https://bugs.ruby-lang.org/issues/19099#change-100315 * Author: ujihisa (Tatsuhiro Ujihisa) * Status: Open * Priority: Normal ---------------------------------------- All the following discussion applies to `public_constant` too. Maybe `deprecate_constant` as well. ## Problem ```ruby class C X = ... private_constant :X end ``` The above idiom usually works fine, but when `...` part is long, like a 30-line Ruby Hash, it's very easy to miss the following `private_constant :X` part. ## Impossible solution ```ruby class C private_constant X = ... end ``` Like `private`, if the above notation could work, it would be awesome, but it breaks so many backward compatibility. The constant assignment returns its value but not the name of the constant, and we should keep the current behaviour. ## Proposed solution Allow the following new notation for `private_constant` by making constant private by name without actually resolving itself and raises an error. ``` ruby class C private_constant :X X = ... end ``` The current behaviour is to raise NameError. ``` /tmp/v8svpb4/95:2:in `private_constant': constant C::X1 not defined (NameError) private_constant :X1 ^^^^^^^^^^^^^^^^ from /tmp/v8svpb4/95:2:in `<class:C>' from /tmp/v8svpb4/95:1:in `<main>' ``` This proposal breaks this backward compatibility. Also I'm concerned about potential typos. It may be hard to find typos. ```ruby class C private_constant :BEHAVIOUR BEHAVIOR = 123 # Remains public unintentionally end ``` Maybe we need some sort of foolproof somewhere in this way. -- https://bugs.ruby-lang.org/

1 year, 5 months

1
0
0 0

[ruby-core:111050] [Ruby master Feature#12848] Crazy idea: Allow regex definition for methods (Do not take it seriously please)

by byroot (Jean Boussier)

Issue #12848 has been updated by byroot (Jean Boussier). Status changed from Open to Rejected Given the feature request I think we can just close it. ---------------------------------------- Feature #12848: Crazy idea: Allow regex definition for methods (Do not take it seriously please) https://bugs.ruby-lang.org/issues/12848#change-100312 * Author: shevegen (Robert A. Heiler) * Status: Rejected * Priority: Normal ---------------------------------------- Me again, sorry - only crazy ideas coming about as of late here. ### Crazy idea: Allow regex definition for methods I should wait until first april. :) But anyway. Consider this: ```ruby def foo_bar puts 'hi there!' end; alias foobar foo_bar ``` Ok now we can call this either as: ```ruby foo_bar() foobar() foo_bar foobar ``` All things work! Here I was wondering ... what if I can omit the alias part? Tada! Enter regex-defined methods as idea! ```ruby def foo_?bar puts 'hi there!' end ``` Now the above works too, without any alias. Yay! I assume that this may not be possible perhaps syntax-wise - and perhaps if it WOULD be possible, it should not be done anyway. # It actually makes things harder to read, so I am also against this idea, too. But! It had to be published. :) I think I remember once a collection of evil code in a file called evil.rb. If I remember correctly, it may have been championed by flori ... something. I even forgot the name. But it was pretty fun. I don't remember if we could have shapechanging object but I like the idea in itself (if we had that? I think you could someone change the parent class ... somehow. Actually, this may not be totally useless, I still think it may be a nice idea to have things like a generic Button.new interface that gets translated properly into the different GUI toolsets and also for www code ... unify all the things!) Things like that with evil.rb are sorta fun - experiment with evil ideas that you should not use. There could be a whole type system added in it as well! Mandatory type system - things that make you unhappy when you use them. Since it is MANDATORY haha! :D And then, on top of that, a ruby-to-crystal compiler just for the fun of it (well, you write in ruby... and then just let it compile into some binary via crystal ... without having to write crystal on your own ... then you'd have the best of both worlds. Crystal feels heavier on my brain than ruby but if it gives me faster binaries OR if I can distribute code as a drop-out-exe for friends to use, this would be good! My friends tend to be noobs so making things as simple as possible is good. Also, I am much more a crystal noob than a ruby noob though I am also a ruby noob too. So the crystal idea, well, actually - would be nice if ruby itself would have that too. Like scripting languages that can be compiled! And run like on something like JVM just not needing java haha.) It's Caturday sorta, don't mind me. So actually, I think my second idea would be to have something like evil.rb again, in stdlib/core or so. We have some `GOTO` stuff too somewhere (I don't remember where ... it is probably too evil to google for it... but I did ... the variable `SUPPORT_JOKE`. We could also `SUPPORT_EVIL` yes! Or perhaps `SUPPORT_FUN` or something like that.) I don't remember if evil.rb was really used a lot by anyone else, but perhaps it would be fun to toy with crazy evil features - and you can not rely on them being made available either, they may disappear or re-appear! Anyway, don't take any of this too seriously please. -- https://bugs.ruby-lang.org/

1 year, 5 months

1
0
0 0

[ruby-core:111049] [Ruby master Feature#6047] read_all: Grow buffer exponentially in generic case

by byroot (Jean Boussier)

Issue #6047 has been updated by byroot (Jean Boussier). I just tried my hand at this one: https://github.com/ruby/ruby/pull/6829 I think such a change would make sense. Not that `IO#read` without a size if common, but might as well do something sensible. ---------------------------------------- Feature #6047: read_all: Grow buffer exponentially in generic case https://bugs.ruby-lang.org/issues/6047#change-100311 * Author: MartinBosslet (Martin Bosslet) * Status: Open * Priority: Normal ---------------------------------------- In the general case, read_all grows its buffer linearly by just the amount that is currently read from the underlying source. This results in a linear number of reallocs, It might turn out beneficial if the buffer were grown exponentially by multiplying with a constant factor (e.g. 1.5 or 2), thus resulting in only a logarithmic numver of reallocs. I will provide a patch and benchmarks, but I'm already opening this issue so I won't forget. See also https://bugs.ruby-lang.org/issues/5353 for more details. -- https://bugs.ruby-lang.org/

1 year, 5 months

1
0
0 0

[ruby-core:111047] [Ruby master Bug#19003] TracePoint behavior inconsistency in 3.2.0-preview2

by hurricup (Alexandr Evstigneev)

Issue #19003 has been updated by hurricup (Alexandr Evstigneev). This stays the same in the `preview3`. Are there any chances this will change until release? Current behavior reduces usefulness and complicates usage of local tracepoints, because I can't just set smarter TP, but also I need to think about what fires when and in which cases we have chained events handling. This is really frustrating. ---------------------------------------- Bug #19003: TracePoint behavior inconsistency in 3.2.0-preview2 https://bugs.ruby-lang.org/issues/19003#change-100308 * Author: hurricup (Alexandr Evstigneev) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0preview2 (2022-09-09 master 35cfc9a3bb) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- This is kind of continuation of my previous report about global/local TP processing (#18730). Sample script: ```rb def foo return 1 end puts RubyVM::InstructionSequence.of(method :foo).disasm def step_over TracePoint.new(:line, :return, :b_return) do |tp| puts "Step over hits by #{tp.event} at #{tp.lineno}" step_over tp.disable end.enable(target: RubyVM::InstructionSequence.of(method :foo), target_thread: Thread.current) end TracePoint.new(:line, :return, :b_return) do |tp| if tp.lineno == 2 puts "Step into hits by #{tp.event} at #{tp.lineno}" step_over tp.disable end end.enable(target_thread: Thread.current) a = foo ``` In ruby 3.1.2 we have expected behavior. Output: ``` == disasm: #<ISeq:foo@/home/hurricup/Projects/ruby-debugger/jb-debase-30/test_sample.rb:1 (1,0)-(3,3)> (catch: FALSE) 0000 putobject_INT2FIX_1_ ( 2)[LiCa] 0001 leave ( 3)[Re] Step into hits by line at 2 Step over hits by return at 3 ``` In ruby 3.2.0-preview2 - not so much. Output: ``` == disasm: #<ISeq:foo@/home/hurricup/Projects/ruby-debugger/jb-debase-30/test_sample.rb:1 (1,0)-(3,3)> (catch: false) 0000 putobject_INT2FIX_1_ ( 2)[LiCa] 0001 leave ( 3)[Re] Step into hits by line at 2 Step over hits by line at 2 Step over hits by return at 3 ``` -- https://bugs.ruby-lang.org/

1 year, 5 months

1
0
0 0

[ruby-core:111046] [Ruby master Feature#19000] Data: Add "Copy with changes method" [Follow-on to #16122 Data: simple immutable value object]

by mame (Yusuke Endoh)

Issue #19000 has been updated by mame (Yusuke Endoh). @RubyBugs Please check my comment https://bugs.ruby-lang.org/issues/19000#note-13 . A wrong motivation example raises the suspicion that this API is actually confusing to users. ---------------------------------------- Feature #19000: Data: Add "Copy with changes method" [Follow-on to #16122 Data: simple immutable value object] https://bugs.ruby-lang.org/issues/19000#change-100307 * Author: RubyBugs (A Nonymous) * Status: Open * Priority: Normal ---------------------------------------- *As requested: extracted a follow-up to #16122 Data: simple immutable value object from [this comment](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/109815)* # Proposal: Add a "Copy with changes" method to Data Assume the proposed `Data.define` exists. Seeing examples from the [[Values gem]](https://github.com/ms-ati/Values): ```ruby # A new class Point = Data.def(:x, :y) # An immutable instance Origin = Point.with(x: 0, y: 0) # Q: How do we make copies that change 1 or more values? right = Origin.with(x: 1.0) up = Origin.with(y: 1.0) up_and_right = right.with(y: up.y) # In loops movements = [ { x: +0.5 }, { x: +0.5 }, { y: -1.0 }, { x: +0.5 }, ] # position = Point(x: 1.5, y: -1.0) position = movements.inject(Origin) { |p, move| p.with(**move) } ``` ## Proposed detail: Call this method: `#with` ```ruby Money = Data.define(:amount, :currency) account = Money.new(amount: 100, currency: 'USD') transactions = [+10, -5, +15] account = transactions.inject(account) { |a, t| a.with(amount: a.amount + t) } #=> Money(amount: 120, currency: "USD") ``` ## Why add this "Copy with changes" method to the Data simple immutable value class? Called on an instance, it returns a new instance with only the provided parameters changed. This API affordance is now **widely adopted across many languages** for its usefulness. Why is it so useful? Because copying immutable value object instances, with 1 or more discrete changes to specific fields, is the proper and ubiquitous pattern that takes the place of mutation when working with immutable value objects. **Other languages** C# Records: “immutable record structs — Non-destructive mutation” — is called `with { ... }` https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-t… Scala Case Classes — is called `#copy` https://docs.scala-lang.org/tour/case-classes.html Java 14+ Records — Brian Goetz at Oracle is working on adding a with copy constructor inspired by C# above as we speak, likely to be called `#with` https://mail.openjdk.org/pipermail/amber-spec-experts/2022-June/003461.html Rust “Struct Update Syntax” via `..` syntax in constructor https://doc.rust-lang.org/book/ch05-01-defining-structs.html#creating-insta… ## Alternatives Without a copy-with-changes method, one must construct entirely new instances using the constructor. This can either be (a) fully spelled out as boilerplate code, or (b) use a symmetrical `#to_h` to feed the keyword-args constructor. **(a) Boilerplate using constructor** ```ruby Point = Data.define(:x, :y, :z) Origin = Point.new(x: 0.0, y: 0.0, z: 0.0) change = { z: -1.5 } # Have to use full constructor -- does this even work? point = Point.new(x: Origin.x, y: Origin.y, **change) ``` **(b) Using a separately proposed `#to_h` method and constructor symmetry** ```ruby Point = Data.define(:x, :y, :z) Origin = Point.new(x: 0.0, y: 0.0, z: 0.0) change = { z: -1.5 } # Have to use full constructor -- does this even work? point = Point.new(**(Origin.to_h.merge(change))) ``` Notice that the above are not ergonomic -- leading so many of our peer language communities to adopt the `#with` method to copy an instance with discrete changes. -- https://bugs.ruby-lang.org/

1 year, 5 months

1
0
0 0

[ruby-core:111045] [Ruby master Feature#13847] Gem activated problem for default gems

by hsbt (Hiroshi SHIBATA)

Issue #13847 has been updated by hsbt (Hiroshi SHIBATA). Assignee set to hsbt (Hiroshi SHIBATA) ---------------------------------------- Feature #13847: Gem activated problem for default gems https://bugs.ruby-lang.org/issues/13847#change-100299 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- If you try to use some default gems with a fixed version using Bundler, there are cases where the current RubyGems/Bundler/Ruby specification can not be used with the version specified by the user. For example ``` $ ruby -v ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin17] $ gem list | grep openssl openssl (2.0.5, 2.0.4, default: 2.0.3) ``` In the environment such as ```require 'openssl'```, the version that is activated when openssl is searched with openssl is the version found first, ie 2.0.5. ``` $ ruby -ropenssl -e 'p OpenSSL::VERSION' "2.0.5" ``` At this time, for example, suppose the user really wants to use openssl 2.0.4 and wrote the following Gemfile. ``` > cat Gemfile # frozen_string_literal: true source "https://rubygems.org" gem 'openssl', '2.0.4' ``` Unfortunately, since rubygems has required openssl before the bundler runs it will result in an activated error like this: ``` > bundle exec ruby -ropenssl -e 'p OpenSSL::VERSION' /path/to/2.4.1/lib/ruby/gems/2.4.0/gems/bundler-1.15.4/lib/bundler/runtime.rb:317:in `check_for_activated_spec!': You have already activated openssl 2.0.5, but your Gemfile requires openssl 2.0.4. Prepending `bundle exec` to your command may solve this. (Gem::LoadError) ``` This problem can be avoided by bundling it as a vendoring library under bundler's repository if it is a default gem implemented with pure ruby. Https://github.com/bundler/bundler/blob/master/lib/bundler/vendor/fileutils… In the case of bundler, by separating the namespace as `Bundler::FileUtils`, even the version specified by the user is made available without conflict at the time of activate. However, this method can not be used with C extension library. Since we want to use json/psych from the bundler team with rubygems/bundler to serialize data, we need about whether we can implement a way to avoid some kind of C extension on Ruby itself. I discussed with @indirect who is maintainer of RubyGems/Bundler. We can resolve this problem like following feature of ruby. ``` require_for_bundler 'json', '2.0.2' ``` When we declared above `require_for_bundler`, We put a json-2.0.2 to placed in a namespace like `Bundler::JSON`. There were similar issues in the past as well. https://bugs.ruby-lang.org/issues/10320 I think that the way of writing ```require 'json', version: '2.0.2', into: :Bundler``` which extended the method like this issue seems like that. Also, in this use case, it seems to be enough to use ```require 'json', version: :default, into: :Bundler``` which forces the use of default gem. Matz, How do you think about this feature? -- https://bugs.ruby-lang.org/

1 year, 5 months

1
0
0 0

[ruby-core:111044] [Ruby master Bug#18133] LTO: TestGCCompact#test_ast_compacts segfaults on i686

by hsbt (Hiroshi SHIBATA)

Issue #18133 has been updated by hsbt (Hiroshi SHIBATA). Assignee set to peterzhu2118 (Peter Zhu) ---------------------------------------- Bug #18133: LTO: TestGCCompact#test_ast_compacts segfaults on i686 https://bugs.ruby-lang.org/issues/18133#change-100297 * Author: vo.x (Vit Ondruch) * Status: Assigned * Priority: Normal * Assignee: peterzhu2118 (Peter Zhu) * ruby -v: ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [i386-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- I observe following segfault running the test suite on i686 on RHEL9: ~~~ $ gdb --args ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems ./test/runner.rb --excludes-dir=./test/excludes -v ... snip ... (gdb) handle SIGPIPE noprint nostop pass Signal Stop Print Pass to program Description SIGPIPE No No Yes Broken pipe (gdb) r ... snip ... [ 8347/20497] TestGBK#test_mbc_enc_len = 0.00 s [ 8348/20497] TestGBK#test_mbc_to_code = 0.00 s [ 8349/20497] TestGCCompact#test_ast_compacts--Type <RET> for more, q to quit, c to continue without paging-- Thread 1 "ruby" received signal SIGSEGV, Segmentation fault. 0xf7e33fe6 in rb_class_remove_from_super_subclasses (klass=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/class.c:96 96 RCLASS_EXT(entry->next->klass)->parent_subclasses = RCLASS_EXT(klass)->parent_subclasses; (gdb) bt #0 0xf7e33fe6 in rb_class_remove_from_super_subclasses (klass=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/class.c:96 #1 obj_free (obj=<optimized out>, objspace=0x5655ac30) at /builddir/build/BUILD/ruby-3.0.2/gc.c:3019 #2 gc_page_sweep (sweep_page=0x5a40e1f0, heap=0x5655ac48, objspace=0x5655ac30) at /builddir/build/BUILD/ruby-3.0.2/gc.c:4914 #3 gc_sweep_step.isra.0 (objspace=<optimized out>, heap=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/gc.c:5134 #4 0xf7ca3f09 in gc_sweep_rest (objspace=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/gc.c:5190 #5 gc_sweep (objspace=0x5655ac30) at /builddir/build/BUILD/ruby-3.0.2/gc.c:5313 #6 0xf7ca8250 in gc_marks (full_mark=<optimized out>, objspace=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/gc.c:7504 #7 gc_start (objspace=<optimized out>, reason=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/gc.c:8322 #8 0xf7ca8530 in garbage_collect (objspace=objspace@entry=0x5655ac30, reason=reason@entry=238592) at /builddir/build/BUILD/ruby-3.0.2/gc.c:8210 #9 0xf7caa723 in gc_start_internal (compact=2, immediate_sweep=2, immediate_mark=2, full_mark=2, self=1448715280, ec=0x5655afac) at /builddir/build/BUILD/ruby-3.0.2/gc.c:8553 #10 gc_compact (ec=0x5655afac, self=1448715280) at /builddir/build/BUILD/ruby-3.0.2/gc.c:9468 #11 0xf7dfae3c in invoke_bf (argv=0x0, bf=<optimized out>, reg_cfp=<optimized out>, ec=0x5655afac) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:5583 #12 vm_invoke_builtin_delegate (ec=0x5655afac, cfp=<optimized out>, bf=<optimized out>, start_index=0) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:5607 #13 0xf7e0664c in vm_exec_core (ec=0x0, initial=1448732852) at /builddir/build/BUILD/ruby-3.0.2/insns.def:1482 #14 0xf7e1d0d5 in rb_vm_exec (ec=<optimized out>, mjit_enable_p=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/vm.c:2172 #15 0xf7e0c3c9 in invoke_block (captured=<optimized out>, captured=<optimized out>, opt_pc=<optimized out>, type=<optimized out>, cref=0x0, self=1450588460, iseq=0x5669174c, ec=0x5655afac) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:399 #16 invoke_iseq_block_from_c (me=0x0, is_lambda=<optimized out>, cref=0x0, passed_block_handler=0, kw_splat=0, argv=0xffffbf00, argc=1, self=1450588460, captured=<optimized out>, ec=0x5655afac) at /builddir/build/BUILD/ruby-3.0.2/vm.c:1335 #17 invoke_block_from_c_bh (force_blockarg=<optimized out>, is_lambda=<optimized out>, cref=<optimized out>, passed_block_handler=<optimized out>, kw_splat=<optimized out>, argv=<optimized out>, argc=<optimized out>, block_handler=<optimized out>, ec=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/vm.c:1353 #18 vm_yield (kw_splat=0, argv=0xffffbf00, argc=1, ec=0x5655afac) at /builddir/build/BUILD/ruby-3.0.2/vm.c:1398 #19 rb_yield_0 (argv=0xffffbf00, argc=1) at /builddir/build/BUILD/ruby-3.0.2/vm_eval.c:1333 #20 rb_yield (val=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/vm_eval.c:1349 #21 0xf7c2ae74 in rb_ary_collect (ary=1503666180) at /builddir/build/BUILD/ruby-3.0.2/array.c:3635 #22 0xf7dfc835 in vm_call_cfunc_with_frame (ec=0x5655afac, reg_cfp=0xf77f6d70, calling=0xffffc004) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:2929 #23 0xf7dfdd31 in vm_sendish (ec=0x5655afac, reg_cfp=0xf77f6d70, cd=0x566c8f00, block_handler=4152323453, method_explorer=mexp_search_method) at /builddir/build/BUILD/ruby-3.0.2/vm_callinfo.h:336 #24 0xf7e0590a in vm_exec_core (ec=0x0, initial=1448732852) at /builddir/build/BUILD/ruby-3.0.2/insns.def:770 #25 0xf7e1d0d5 in rb_vm_exec (ec=<optimized out>, mjit_enable_p=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/vm.c:2172 #26 0xf7e0c3c9 in invoke_block (captured=<optimized out>, captured=<optimized out>, opt_pc=<optimized out>, type=<optimized out>, cref=0x0, self=1450588460, iseq=0x56691850, ec=0x5655afac) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:399 #27 invoke_iseq_block_from_c (me=0x0, is_lambda=<optimized out>, cref=0x0, passed_block_handler=0, kw_splat=0, argv=0xffffc2b0, argc=1, self=1450588460, captured=<optimized out>, ec=0x5655afac) at /builddir/build/BUILD/ruby-3.0.2/vm.c:1335 #28 invoke_block_from_c_bh (force_blockarg=<optimized out>, is_lambda=<optimized out>, cref=<optimized out>, passed_block_handler=<optimized out>, kw_splat=<optimized out>, argv=<optimized out>, argc=<optimized out>, block_handler=<optimized out>, ec=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/vm.c:1353 #29 vm_yield (kw_splat=0, argv=0xffffc2b0, argc=1, ec=0x5655afac) at /builddir/build/BUILD/ruby-3.0.2/vm.c:1398 #30 rb_yield_0 (argv=0xffffc2b0, argc=1) at /builddir/build/BUILD/ruby-3.0.2/vm_eval.c:1333 #31 rb_yield (val=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/vm_eval.c:1349 #32 0xf7c2ac4a in rb_ary_each (ary=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/array.c:2523 #33 rb_ary_each (ary=1501058480) at /builddir/build/BUILD/ruby-3.0.2/array.c:2517 #34 0xf7dfc835 in vm_call_cfunc_with_frame (ec=0x5655afac, reg_cfp=0xf77f6dfc, calling=0xffffc474) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:2929 #35 0xf7e00602 in vm_call_method_each_type (ec=0x5655afac, cfp=0xf77f6dfc, calling=0xffffc474) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:3419 #36 0xf7e00a46 in vm_call_refined (calling=<optimized out>, cfp=0xf77f6dfc, ec=0x5655afac) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:3398 #37 vm_call_method_each_type (ec=0x5655afac, cfp=0xf77f6dfc, calling=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:3476 #38 0xf7dfdd31 in vm_sendish (ec=0x5655afac, reg_cfp=0xf77f6dfc, cd=0x5669f510, block_handler=4152323593, method_explorer=mexp_search_method) at /builddir/build/BUILD/ruby-3.0.2/vm_callinfo.h:336 #39 0xf7e0590a in vm_exec_core (ec=0x0, initial=1448732852) at /builddir/build/BUILD/ruby-3.0.2/insns.def:770 #40 0xf7e1d0d5 in rb_vm_exec (ec=<optimized out>, mjit_enable_p=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/vm.c:2172 #41 0xf7e0c3c9 in invoke_block (captured=<optimized out>, captured=<optimized out>, opt_pc=<optimized out>, type=<optimized out>, cref=0x0, self=1450588460, iseq=0x566900cc, ec=0x5655afac) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:399 #42 invoke_iseq_block_from_c (me=0x0, is_lambda=<optimized out>, cref=0x0, passed_block_handler=0, kw_splat=0, argv=0xffffc720, argc=1, self=1450588460, captured=<optimized out>, ec=0x5655afac) at /builddir/build/BUILD/ruby-3.0.2/vm.c:1335 #43 invoke_block_from_c_bh (force_blockarg=<optimized out>, is_lambda=<optimized out>, cref=<optimized out>, passed_block_handler=<optimized out>, kw_splat=<optimized out>, argv=<optimized out>, argc=<optimized out>, block_handler=<optimized out>, ec=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/vm.c:1353 #44 vm_yield (kw_splat=0, argv=0xffffc720, argc=1, ec=0x5655afac) at /builddir/build/BUILD/ruby-3.0.2/vm.c:1398 #45 rb_yield_0 (argv=0xffffc720, argc=1) at /builddir/build/BUILD/ruby-3.0.2/vm_eval.c:1333 #46 rb_yield (val=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/vm_eval.c:1349 #47 0xf7c2ac4a in rb_ary_each (ary=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/array.c:2523 --Type <RET> for more, q to quit, c to continue without paging-- #48 rb_ary_each (ary=1501058920) at /builddir/build/BUILD/ruby-3.0.2/array.c:2517 #49 0xf7dfc835 in vm_call_cfunc_with_frame (ec=0x5655afac, reg_cfp=0xf77f6ec0, calling=0xffffc8e4) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:2929 #50 0xf7e00602 in vm_call_method_each_type (ec=0x5655afac, cfp=0xf77f6ec0, calling=0xffffc8e4) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:3419 #51 0xf7e00a46 in vm_call_refined (calling=<optimized out>, cfp=0xf77f6ec0, ec=0x5655afac) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:3398 #52 vm_call_method_each_type (ec=0x5655afac, cfp=0xf77f6ec0, calling=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:3476 #53 0xf7dfdd31 in vm_sendish (ec=0x5655afac, reg_cfp=0xf77f6ec0, cd=0x566cbca0, block_handler=4152323789, method_explorer=mexp_search_method) at /builddir/build/BUILD/ruby-3.0.2/vm_callinfo.h:336 #54 0xf7e0590a in vm_exec_core (ec=0x0, initial=1448732852) at /builddir/build/BUILD/ruby-3.0.2/insns.def:770 #55 0xf7e1d0d5 in rb_vm_exec (ec=<optimized out>, mjit_enable_p=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/vm.c:2172 #56 0xf7e1da4e in rb_iseq_eval (iseq=0x5657ad18) at /builddir/build/BUILD/ruby-3.0.2/vm.c:2409 #57 0xf7cdb23e in load_iseq_eval (ec=0x5655afac, fname=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/load.c:594 #58 0xf7ce0ef8 in require_internal (ec=<optimized out>, fname=<optimized out>, exception=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/load.c:1065 #59 0xf7ce10ce in rb_require_string (fname=1448587920) at /builddir/build/BUILD/ruby-3.0.2/load.c:1142 #60 0xf7ce117c in rb_f_require_relative (obj=1448845900, fname=1448588380) at /builddir/build/BUILD/ruby-3.0.2/load.c:857 #61 0xf7dfc835 in vm_call_cfunc_with_frame (ec=0x5655afac, reg_cfp=0xf77f6fd8, calling=0xffffce04) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:2929 #62 0xf7e00602 in vm_call_method_each_type (ec=0x5655afac, cfp=0xf77f6fd8, calling=0xffffce04) at /builddir/build/BUILD/ruby-3.0.2/vm_insnhelper.c:3419 #63 0xf7dfdd31 in vm_sendish (ec=0x5655afac, reg_cfp=0xf77f6fd8, cd=0x56616828, block_handler=0, method_explorer=mexp_search_method) at /builddir/build/BUILD/ruby-3.0.2/vm_callinfo.h:336 #64 0xf7e04d92 in vm_exec_core (ec=0x0, initial=1448732852) at /builddir/build/BUILD/ruby-3.0.2/insns.def:789 #65 0xf7e1d0d5 in rb_vm_exec (ec=<optimized out>, mjit_enable_p=<optimized out>) at /builddir/build/BUILD/ruby-3.0.2/vm.c:2172 #66 0xf7e1db19 in rb_iseq_eval_main (iseq=0x5657b63c) at /builddir/build/BUILD/ruby-3.0.2/vm.c:2420 #67 0xf7c91b99 in rb_ec_exec_node (ec=ec@entry=0x5655afac, n=n@entry=0x5657b63c) at /builddir/build/BUILD/ruby-3.0.2/eval.c:317 #68 0xf7c964fa in ruby_run_node (n=0x5657b63c) at /builddir/build/BUILD/ruby-3.0.2/eval.c:375 #69 0x56556143 in main (argc=<optimized out>, argv=<optimized out>) at ./main.c:50 ~~~ Unfortunately: 1) I don' have better reproducer then to run the whole test suite and even then it is not triggered always. I was not successful to hit the issue running just the single test case or the test file. 2) I have failed to reproduce this on CentOS Stream 9, which is surprising. Luckily, I can reproduce it on my system. This is seems to be related to LTO, because I have never faced such issue with LTO disabled. ---Files-------------------------------- mmap.patch (9.45 KB) mmap.patch (11.1 KB) -- https://bugs.ruby-lang.org/

1 year, 5 months

1
0
0 0

[ruby-core:111043] [Ruby master Feature#9830] Support for GOST private/public keys

by hsbt (Hiroshi SHIBATA)

Issue #9830 has been updated by hsbt (Hiroshi SHIBATA). Assignee set to rhenium (Kazuki Yamaguchi) ---------------------------------------- Feature #9830: Support for GOST private/public keys https://bugs.ruby-lang.org/issues/9830#change-100296 * Author: Envek (Andrey Novikov) * Status: Assigned * Priority: Normal * Assignee: rhenium (Kazuki Yamaguchi) ---------------------------------------- Hello everyone. We're required to use GOST encryption algorithms for signing requests, interacting with HTTPS services with client certificate authentication and so on. OpenSSL 1.0.0 is bundled with GOST engine, and, if correctly configured, can handle all of these tasks from command line. Also see #9822. **Issue** Ruby can't read GOST private and public keys: ~~~ ruby> privkey = OpenSSL::PKey.read(File.read('gost_r_34_10_2001_private_key.pem')) OpenSSL::PKey::PKeyError: unsupported key type ruby> # Same for public keys ruby> crt = OpenSSL::X509::Certificate.new(File.read('gost_r_34_10_2001_certificate.pem')) ruby> crt.public_key OpenSSL::PKey::PKeyError: unsupported key type ~~~ The problem is there is no "Generic PKey" class in Ruby's OpenSSL. In source in `ext/openssl/openssl_pkey.c` at line 76 in method `ossl_pkey_new` there is examination of key type and creating appropriate Ruby classes. But GOST R 34.10-2001 key type have type `NID_id_GostR3410_2001` (811), and Ruby fails. **Possible solution** GOST keys are EC keys in fact (at least for GOST R 34.10-2001). And, if I add `case NID_id_GostR3410_2001:` right before `case EVP_PKEY_EC:` and remove checks about key type in `ext/openssl/openssl_pkey_ec.c` – everything will work. To illustrate this, I've attached required patches (one from issue #9822), self-signed GOST R 34.10-2001 certificate with private key and two test scripts. **NOTE**: You will need OpenSSL version 1.0.0 or newer with correct configuration, see links below! **Question** How should GOST keys support implemented in Ruby? Should it even use `OpenSSL::PKey::EC`, or, may be, subclass from it? I'm not experienced neither in C programming nor in cryptography, but I would be glad to help with the implementation of this. **Further information** * **README.gost**: Instructions for setting up OpenSSL and usage: https://github.com/openssl/openssl/blob/master/engines/ccgost/README.gost * **OpenSSL GOST engine source**: https://github.com/openssl/openssl/tree/master/engines/ccgost * **RFC 5830**: GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms: http://tools.ietf.org/html/rfc5830 * **RFC 5831**: GOST R 34.11-94: Hash Function Algorithm: http://tools.ietf.org/html/rfc5831 * **RFC 5832**: GOST R 34.10-2001: Digital Signature Algorithm: http://tools.ietf.org/html/rfc5832 * **RFC 4491**: Using the GOST Algorithms with the Internet X.509 Public Key Infrastructure: http://tools.ietf.org/html/rfc4491 * **RFC 4490**: Using the GOST Algorithms with Cryptographic Message Syntax (CMS): http://tools.ietf.org/html/rfc4490 * **RFC 4357**: Additional Cryptographic Algorithms for Use with GOST Algorithms * Some stackoverflow.com related questions: http://stackoverflow.com/questions/12868384/openssl-gost-parameter-set and http://stackoverflow.com/questions/14580340/generate-gost-34-10-2001-keypai… ---Files-------------------------------- gost_keys_support_draft.patch (1.92 KB) gost_r_34_10_2001_certificate.pem (826 Bytes) gost_r_34_10_2001_private_key.pem (152 Bytes) gost_sigining.rb (541 Bytes) gost_ssl_example_with_certs.rb (742 Bytes) respect_system_openssl_settings.patch (430 Bytes) -- https://bugs.ruby-lang.org/

1 year, 5 months

1
0
0 0

[ruby-core:111042] [Ruby master Bug#18657] IRB raises exception when stdout is a pipe

by hsbt (Hiroshi SHIBATA)

Issue #18657 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Closed This patch has been merged at https://github.com/ruby/irb/pull/353 ---------------------------------------- Bug #18657: IRB raises exception when stdout is a pipe https://bugs.ruby-lang.org/issues/18657#change-100295 * Author: pjones (Peter Jones) * Status: Closed * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-03-24T16:14:55Z master 33b13bd9f1) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- When piping stdout to another process IRB fails: ``` lib/ruby/3.0.0/irb/input-method.rb:42:in `winsize': Inappropriate ioctl for device (Errno::ENOTTY) ``` For example: ``` echo n=1 | irb | cat ``` This bug was introduced in e468d9f49ca34f713c030c623f655a40370e186d and triggered by 8f9b1902f48b413bd161666630c878ad58418c04 and 555ea8334451c5ccd881e68b8b7ddc15745e66e3. The attached patch fixes the bug and includes a test to demonstrate the issue. ---Files-------------------------------- ruby-irb.patch (1.26 KB) -- https://bugs.ruby-lang.org/

1 year, 5 months

1
0
0 0

2024

2023

2022

ruby-core

2024

2023

2022

ruby-core ----- 2024 ----- May 2024 April 2024 March 2024 February 2024 January 2024 ----- 2023 ----- December 2023 November 2023 October 2023 September 2023 August 2023 July 2023 June 2023 May 2023 April 2023 March 2023 February 2023 January 2023 ----- 2022 ----- December 2022 November 2022

ruby-core