August 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:118858] [Ruby master Bug#20678] Doxygen document doesn't print Ruby C APIs properly
by jaruga (Jun Aruga) 15 Aug '24

15 Aug '24

Issue #20678 has been reported by jaruga (Jun Aruga). ---------------------------------------- Bug #20678: Doxygen document doesn't print Ruby C APIs properly https://bugs.ruby-lang.org/issues/20678 * Author: jaruga (Jun Aruga) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I am looking for how to see a list of Ruby C API descriptions written in the comment area by a command. For example, in the case of the `rb_scan_args`, the description is below. https://github.com/ruby/ruby/blob/908305a2977856264a932cad02437c30f08c365b/… The `ri` command only shows a very simple text rather than the above description. ``` $ ri rb_scan_args = .rb_scan_args (from ruby core) === Implementation from C ------------------------------------------------------------------------ rb_scan_args(method_body) ------------------------------------------------------------------------ Extracts parameters from the method_body and returns a method parameter string. Follows 1.9.3dev's scan-arg-spec, see README.EXT ``` @nobu gave me a clue to print the list of such descriptions by using `doxygen`. Below are the steps I tested at the latest ruby/ruby master branch 2a933609e75aa87f27cf1c892a54389d3efed928 on my Fedora Linux 39. Installed Doxygen. ``` $ sudo dnf install doxygen $ which doxygen /bin/doxygen ``` Generated the Doxygen document. Then the `doc/capi` directory was created. ``` $ ./autogen.sh $ ./configure ...<snip>... ... checking for doxygen... doxygen ... $ make capi ``` Opened the Main page. ``` $ firefox doc/capi/html/index.html & ``` Then I cannot find the document about `rb_scan_args` on the Main Page (`ruby_doxygen_main_page.png`) and Namespace List (`ruby_doxygen_namespace_list.png`) page. Do you know what's the reason and what's wrong? I don't think all the Ruby APIs are listed on the page. I assume there may be a bug in the process of generating the doxygen document. ---Files-------------------------------- ruby_doxygen_main_page.png (55.8 KB) ruby_doxygen_namespace_list.png (164 KB) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118856] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by Dan0042 (Daniel DeLorme) 14 Aug '24

14 Aug '24

Issue #6648 has been updated by Dan0042 (Daniel DeLorme). byroot (Jean Boussier) wrote in #note-36: > As for the API, my two cents is that it would make the most sense in `Process`. e.g. `Process.argv`, such as: I don't mind using "Process", but the "argv" name is really ambiguous. For the command `ruby --yjit script.rb --arg` we'd have: main(char **argv) => ["ruby", "--yjit", "script.rb", "--arg"] Process.argv => ["--yjit", "script.rb", "--arg"] ARGV => ["--arg"] Process.argv0 => "script.rb" (not element 0 of any of the 3 arrays above) The name "argv" already has 3 different conflicting meanings, so adding a 4th one is a bit too much imho. byroot (Jean Boussier) wrote in #note-38: > Needs a bit of polish (e.g. doc and spec), but that's essentially what I think we should do: https://github.com/ruby/ruby/pull/11370 This works great for re-executing the current process, but not for the original problem described in OP to "launch subprocess Ruby instances with the same settings". It's definitely a bit more complicated to extract just ["--yjit"] from the example above, and requires to change `proc_options` in ruby.c ...I'll try to see if I can whip up something. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-109424 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118844] [Ruby master Feature#20676] Pathnames aren't Comparable
by gmcgibbon (Gannon McGibbon) 14 Aug '24

14 Aug '24

Issue #20676 has been reported by gmcgibbon (Gannon McGibbon). ---------------------------------------- Feature #20676: Pathnames aren't Comparable https://bugs.ruby-lang.org/issues/20676 * Author: gmcgibbon (Gannon McGibbon) * Status: Open ---------------------------------------- 👋 I was working with Pathnames recently and noticed that I could do: ```rb Pathname("/a/b").to_s <= Pathname("/a/b/c").to_s ``` but could not do: ```rb Pathname("/a/b") <= Pathname("/a/b/c") ``` to check if pathnames are subdirectories of each other. Pathname implements [`<=>`](https://docs.ruby-lang.org/en/master/Pathname.html#method-i-3C-3D-3E) with case insensitive matching for use-cases like this, but does not include Comparable. I think Pathname should include Comparable. I've opened a [PR here](https://github.com/ruby/pathname/pull/40) for your consideration. Thanks! -- https://bugs.ruby-lang.org/

6 7

[ruby-core:118777] [Ruby master Misc#20661] Stop retrying tests in `make test-all` command by default
by ono-max (Naoto Ono) 14 Aug '24

14 Aug '24

Issue #20661 has been reported by ono-max (Naoto Ono). ---------------------------------------- Misc #20661: Stop retrying tests in `make test-all` command by default https://bugs.ruby-lang.org/issues/20661 * Author: ono-max (Naoto Ono) * Status: Open * Assignee: ono-max (Naoto Ono) ---------------------------------------- ## Summary Currently, tests are retried once if they fail when tests are executed as parallel tests in the `make test-all` command by default. This is to prevent test failures caused by parallel testing. That's why failed tests are executed serially, not in parallel. Source code: https://github.com/ruby/ruby/blob/master/tool/lib/test/unit.rb#L728-L751 However, there is a problem, which might hide a real issue like https://bugs.ruby-lang.org/issues/20314. To prevent missing this "real" problem, stopping the retry of tests in the `make test-all` command by default would be better. ## Concerns when stopping the retry of tests in the `make test-all` command Here are some concerns about stopping the retry mechanism in `make test-all` command. #### 1. There are some flaky tests in the test suite. Are we okay with that? Yes, [all flaky tests are tracked by Launchable](https://app.launchableinc.com/organizations/ruby/workspaces/rub…, and they're mainly monitored by @mame. Thus, they'll be fixed in the future. #### 2. When a test that is not related to my change fails, what should we do? Just click the "Re-run jobs" button via the GitHub UI. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:118846] >>> Your account is hacked. Your data is stolen. Learn how to regain access.
by ruby-core＠ruby-lang.org 14 Aug '24

14 Aug '24

> Hi, > > I am a hacker, and I have successfully gained access to your operating system. > I also have full access to your account. > > I've been watching you for a few months now. > > The fact is that your computer has been infected with malware through an adult site that you visited. > If you are not familiar with this, I will explain. > Trojan Virus gives me full access and control over a computer or other device. > This means that I can see everything on your screen, turn on the camera and microphone, but you do not know about it. > I also have access to all your contacts and all your correspondence. > > Why did your antivirus not detect malware? > Answer: The malware I used is driver-based, I update its signatures every 4 hours. Hence your antivirus is unable to detect its presence. > I made a video showing how you satisfy yourself in the left half of the screen, and the right half shows the video you were watching at the time. > > With one mouse click, I can send this video to all your emails and contacts on your social networks. > I can also make public all your e-mail correspondence and chat history on the messengers that you use. > > If you don't want this to happen, transfer $880 in Bitcoin equivalent to my Bitcoin address (if you do not know how to do this, just search "buy bitcoin" on Google). > > My Bitcoin address (BTC Wallet) is: 1D9NgNsdmYXMYbw2z4oxEJvTwx1ut3F7o3 > > After confirming your payment, I will delete the video immediately, and that's it. You will never hear from me again. > I will give you 50 hours (more than 2 days) to pay. I will get a notice, when you open this email, and the timer will start. > Filing a complaint somewhere does not make sense because this email cannot be tracked like my Bitcoin address. > > I never make any mistakes. > If I find that you have shared this message with someone else, the video will be immediately distributed. > > Best regards!

1 0

[ruby-core:118842] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by byroot (Jean Boussier) 13 Aug '24

13 Aug '24

Issue #6648 has been updated by byroot (Jean Boussier). Needs a bit of polish (e.g. doc and spec), but that's essentially what I think we should do: https://github.com/ruby/ruby/pull/11370 ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-109409 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118841] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by kddnewton (Kevin Newton) 13 Aug '24

13 Aug '24

Issue #6648 has been updated by kddnewton (Kevin Newton). It might make sense to split this ticket into two requests: one for `Process.argv` or similar and one for re-executing the current process with the same or additional flags (`Process.reexec`??). These seems like slightly different requests, and `Process.argv` seems like it might be slightly more difficult to implement. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-109408 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118840] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by byroot (Jean Boussier) 13 Aug '24

13 Aug '24

Issue #6648 has been updated by byroot (Jean Boussier). As for the API, my two cents is that it would make the most sense in `Process`. e.g. `Process.argv`, such as: ```bash $ ruby --yjit -e "p Process.argv" ["--yjit", "-e", "p Process.argv"] ``` So a self re-exec would be: ```ruby Process.exec(RbConfig.ruby, *Process.argv) ``` ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-109407 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118839] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by byroot (Jean Boussier) 13 Aug '24

13 Aug '24

Issue #6648 has been updated by byroot (Jean Boussier). This need came up again in https://github.com/rubygems/rubygems/pull/7933. AFAICT there is currently no good way for a program to re-exec itself with all the same arguments. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-109406 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118833] [Ruby master Bug#20674] Time zone conversion issue Time.at
by moustafasallam (Moustafa Sallam Mahmoud) 13 Aug '24

13 Aug '24

Issue #20674 has been reported by moustafasallam (Moustafa Sallam Mahmoud). ---------------------------------------- Bug #20674: Time zone conversion issue Time.at https://bugs.ruby-lang.org/issues/20674 * Author: moustafasallam (Moustafa Sallam Mahmoud) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- # Time.at converts the epoch time to the local time zone But there seems a weird case with Central Time (US & Canada) # where it convert it one hour earlier for example # take this timestamp 1728018000 when converted it to Central Time (US & Canada) with Time.at # => Time.zone = "Central Time (US & Canada)" # => "Central Time (US & Canada)" # => Time.at(1728018000) # => 2024-10-04 01:00:00 -0400 # While using ActiveSupport::TimeZone # ActiveSupport::TimeZone['Central Time (US & Canada)'].at(1728018000) # => Fri, 04 Oct 2024 00:00:00.000000000 CDT -05:00 # so Time.at convert it to -4 while ActiveSupport::TimeZone convert it to -5 -- https://bugs.ruby-lang.org/

2 2