December 2022 - ruby-core - ml.ruby-lang.org

[ruby-core:111510] [Ruby master Bug#19284] Integer overflow when using RUBY_GC_HEAP_INIT_SLOTS environment variable
by zeke (Zeke Gabrielse) 21 Mar '23

21 Mar '23

Issue #19284 has been reported by zeke (Zeke Gabrielse). ---------------------------------------- Bug #19284: Integer overflow when using RUBY_GC_HEAP_INIT_SLOTS environment variable https://bugs.ruby-lang.org/issues/19284 * Author: zeke (Zeke Gabrielse) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-darwin19] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- If you set the environment variable `RUBY_GC_HEAP_INIT_SLOTS` to anything other than `0`, an integer overflow runtime error occurs: ```ruby RUBY_GC_HEAP_INIT_SLOTS=2 ruby -e 'puts "hello, world!"' # => integer overflow: 3689348814741910508 * 8 > 18446744073709551615 (RuntimeError) ``` At this time, I'm not sure if this is platform-specific. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:111557] [Ruby master Bug#19292] Time object's wday, yday, and isdst returns broken value (and so does to_a) when kwarg in: 'UTC' was given
by matsuda (Akira Matsuda) 21 Mar '23

21 Mar '23

Issue #19292 has been reported by matsuda (Akira Matsuda). ---------------------------------------- Bug #19292: Time object's wday, yday, and isdst returns broken value (and so does to_a) when kwarg in: 'UTC' was given https://bugs.ruby-lang.org/issues/19292 * Author: matsuda (Akira Matsuda) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2022-12-30T15:31:50Z master 0bb07e5ba4) +YJIT [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- $ ruby -e "p Time.new(2023, 1, 1, 0, 0, 0, in: 'UTC').wday" 7 $ ruby -e "p Time.new(2023, 1, 1, 0, 0, 0, in: 'UTC').yday" 0 $ ruby -e "p Time.new(2023, 1, 1, 0, 0, 0, in: 'UTC').isdst" -e:1:in `isdst': isdst is not set yet (RuntimeError) from -e:1:in `<main>' $ ruby -e "p Time.new(2023, 1, 1, 0, 0, 0, in: 'UTC').to_a" [0, 0, 0, 1, 1, 2023, 7, 0, true, "UTC"] where the expected `to_a` value should be: [0, 0, 0, 1, 1, 2023, 0, 1, false, "UTC"] This bug seems to be happening on the following conditions: - On any given date and time, regardless of past or future - Either on `Time.new(Integer, Integer, ...)` style or `Time.new(String)` style - Only when `in: 'UTC'` kwarg was given. Other formats like `in: '+0000'` or `in: 0` seems to be OK - On all Ruby versions that accept kwarg `in:` (3.1, 3.2, and 3.3) -- https://bugs.ruby-lang.org/

4 4

[ruby-core:111480] [Ruby master Misc#19276] It is not possible to reply to emails from rubymine
by graywolf (Gray Wolf) 28 Feb '23

28 Feb '23

Issue #19276 has been reported by graywolf (Gray Wolf). ---------------------------------------- Misc #19276: It is not possible to reply to emails from rubymine https://bugs.ruby-lang.org/issues/19276 * Author: graywolf (Gray Wolf) * Status: Open * Priority: Normal ---------------------------------------- It is no possible to reply to email from about issue update in order to add further comments to the tickets. Is that something that could be turned on? I think it would be user friendly to be able to react directly from mail client, without having to switch to the browser and navigate to the issue and comment there. -- https://bugs.ruby-lang.org/

4 7

[ruby-core:111225] [Ruby master Bug#19189] Ruby 3.1.3/3.2.x can no longer find pkg-config if not present at buildtime
by mistydemeo (Misty De Meo) 23 Feb '23

23 Feb '23

Issue #19189 has been reported by mistydemeo (Misty De Meo). ---------------------------------------- Bug #19189: Ruby 3.1.3/3.2.x can no longer find pkg-config if not present at buildtime https://bugs.ruby-lang.org/issues/19189 * Author: mistydemeo (Misty De Meo) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Starting with Ruby 3.1.3, mkmf.rb calls to `pkg-config` will fail if `pkg-config` wasn't present on the system at the time it was built. Prior to that version, even if Ruby itself wasn't configured with `pkg-config`, mkmf.rb would be able to correctly pick it up from the `PATH`. This was introduced by https://github.com/ruby/ruby/commit/7f1ca666424849134990d022266bcd4d6636465f and its Ruby 3.1.3 equivalent, https://github.com/ruby/ruby/commit/3914581213e3aea138b02941b41e62c15461af27. I've confirmed that reverting this specific change fixes the problem. This broke a Ruby deployment which is built in a minimal Docker environment with no `pkg-config`, but which is later copied into a system with `pkg-config` present. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:111053] [Ruby master Bug#19158] Ruby 3.1.3 installs wrong gemspec for debug gem
by deivid 23 Feb '23

23 Feb '23

Issue #19158 has been reported by deivid (David Rodríguez). ---------------------------------------- Bug #19158: Ruby 3.1.3 installs wrong gemspec for debug gem https://bugs.ruby-lang.org/issues/19158 * Author: deivid (David Rodríguez) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [arm64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- A pristine installation of Ruby 3.1.3 shows an installed `debug-1.6.3.gemspec` file that claims that debug-1.6.3 has no dependencies. This is incorrect, and causes issues for Bundler as reported at https://github.com/rubygems/rubygems/issues/6082. An issue workaround is to manually reinstall the gem with `gem install debug:1.6.3`. That will reinstall the gem, including a correct gemspec file. This is the file diff before and after reinstalling the gem ```diff --- old.gemspec 2022-11-29 13:54:36 +++ /Users/deivid/.asdf/installs/ruby/3.1.3/lib/ruby/gems/3.1.0/specifications/debug-1.6.3.gemspec 2022-11-29 13:55:25 @@ -24,4 +24,16 @@ s.summary = "Debugging functionality for Ruby".freeze s.installed_by_version = "3.3.26" if s.respond_to? :installed_by_version + + if s.respond_to? :specification_version then + s.specification_version = 4 + end + + if s.respond_to? :add_runtime_dependency then + s.add_runtime_dependency(%q<irb>.freeze, [">= 1.3.6"]) + s.add_runtime_dependency(%q<reline>.freeze, [">= 0.3.1"]) + else + s.add_dependency(%q<irb>.freeze, [">= 1.3.6"]) + s.add_dependency(%q<reline>.freeze, [">= 0.3.1"]) + end end ``` In general, the files installed by ruby-core for bundled gems should be identical to the ones installed by explicit `gem install`. This issue is also present in master and I'm guessing it was introduced by https://github.com/ruby/ruby/commit/a2c66f52f402cb58372e271226f3341065561e53 (backported at https://github.com/ruby/ruby/commit/2d26e45135af8b427d9ccc6d47082c21be8b9c74) -- https://bugs.ruby-lang.org/

3 9

[ruby-core:111022] [Ruby master Bug#19153] Since 2.7.7 CGI::Cookie raises ArgumentError when cookie domains is prefixed with a dot
by cpinto (Celso Pinto) 23 Feb '23

23 Feb '23

Issue #19153 has been reported by cpinto (Celso Pinto). ---------------------------------------- Bug #19153: Since 2.7.7 CGI::Cookie raises ArgumentError when cookie domains is prefixed with a dot https://bugs.ruby-lang.org/issues/19153 * Author: cpinto (Celso Pinto) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.7p221 (2022-11-24 revision 168ec2b1e5) [arm64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The rspec tests of our Rails app started failing with an ArgumentError after upgrading to 2.7.7. On inspection, the issue seems to be caused by CGI::Cookie.domain=: ``` def domain=(str) if str and ((str = str.b).bytesize > 255 or !DOMAIN_VALUE_RE.match?(str)) raise ArgumentError, "invalid domain: #{str.dump}" end @domain = str end ``` Setting a breakpoint: 0> str => ".example.com" 0> DOMAIN_VALUE_RE => /\A(?<label>(?!-)[-A-Za-z0-9]+(?<!-))(?:\.\g<label>)*\z/ 0> DOMAIN_VALUE_RE.match?(str) => false 0> DOMAIN_VALUE_RE.match?('example.com') => true -- https://bugs.ruby-lang.org/

4 5

[ruby-core:111194] [Ruby master Feature#19179] Support parsing SCM_CRED(ENTIALS) messages from ancillary messages
by kjtsanaktsidis (KJ Tsanaktsidis) 13 Feb '23

13 Feb '23

Issue #19179 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Feature #19179: Support parsing SCM_CRED(ENTIALS) messages from ancillary messages https://bugs.ruby-lang.org/issues/19179 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal ---------------------------------------- ## Background Linux and FreeBSD support processes at either end of a unix socket identifying themselves to the other party by passing an ancillary message of type `SCM_CREDENTIALS` (Linux) or `SCM_CREDS` (FreeBSD). The socket library contains code to parse these ancillary messages, but the only way this is exposed into Ruby code is by the `Socket::AncillaryData#inspect` method - e.g. ``` # On Linux irb(main):002:0> s1, s2 = UNIXSocket.pair => [#<UNIXSocket:fd 5>, #<UNIXSocket:fd 6>] irb(main):004:0> s2.setsockopt Socket::SOL_SOCKET, Socket::SO_PASSCRED, 1 => 0 # struct ucred on Linux is (32-bit signed) pid_t, followed by (32-bit unsigned) uid_t, followed by # (32-bit unsigned) gid_t irb(main):008:0> ancdata = [Process.pid, Process.uid, Process.gid].pack("lLL") => "\x1ET\x05\x00\xE8\x03\x00\x00\xE8\x03\x00\x00" # Socket::AncillaryData knows how to unmarshal the data into struct ucred irb(main):010:0> ancmsg = Socket::AncillaryData.new(Socket::AF_UNIX, Socket::SOL_SOCKET, Socket::SCM_CRE DENTIALS, ancdata) => #<Socket::AncillaryData: UNIX SOCKET CREDENTIALS pid=349214 uid=1000 gid=1000 (ucred)> irb(main):011:0> s1.sendmsg "hi", 0, nil, ancmsg => 2 # ancillary message can be passed through irb(main):012:0> _, _, _, recvanc = s2.recvmsg; recvanc => #<Socket::AncillaryData: UNIX SOCKET CREDENTIALS pid=349214 uid=1000 gid=1000 (ucred)> ``` On Linux, at least, a suitably privileged process can send any value through for the pid, uid, or gid, but the kernel will reject attempts by unprivileged processes to forge credentials in this way. So SCM_CREDENTIALS messages can be useful for certain systems programming tasks. A somewhat wider array of operating systems support querying the identity of the other side of a socket using a socket option, variously `SO_PEERCRED` (Linux, OpenBSD) or `LOCAL_PEERCRED` (FreeBSD, MacOS). Again, the socket library is able to unmarshal the socket data into the correct structure on these various systems, but it's only exposed to Ruby code via `#inspect` - e.g. ``` irb(main):002:0> s1, s2 = UNIXSocket.pair => [#<UNIXSocket:fd 5>, #<UNIXSocket:fd 6>] irb(main):014:0> s1.getsockopt Socket::SOL_SOCKET, Socket::SO_PEERCRED => #<Socket::Option: UNIX SOCKET PEERCRED pid=349214 euid=1000 egid=1000 (ucred)> ``` Ruby _does_ however support e.g. `BasicSocket#getpeereid`, which could use `SO_PEERCRED` etc under the hood - so getting the uid/gid data is not totally impossible. I believe getting the pid is though. ``` irb(main):016:0> s1.getpeereid => [1000, 1000] ``` ## My proposal I believe we should implement the following: * `Socket::Credentials` - this would be a struct which can contain all the various platform-specific pieces of credential info that can be transferred over a socket, such as uid, gid, pid, euid, egid, and group list. * `Socket::AncillaryData#credentials` - this would parse an `SCM_CREDS` or `SCM_CREDENTIALS` ancillary data message into the appropriate platform-specific struct, and return a `Socket::Credentials` instance containing that data. This would be analogous to `Socket::AncillaryData#int`; a method for interpreting the ancillary data in a certain form. * `Socket::Option#credentials` - This would parse a `SO_PEERCRED` or `LOCAL_PEERCRED` socket option response into the appropriate platform-specific struct, and return a `Socket::Credentials` instance containing that data. Again, this would be analogous to `Socket::Option#int`. The existing `struct ucred`/`struct xucred`/`struct sockpeercred`/`struct cmsgcred` parsing code (used only for `#inspect` output) would be moved into `Socket::Credentials`, and `Socket::AncillaryData#inspect`/`Socket::Option#inspect` would be implemented in terms of `Socket::Credentials`. This would nicely wrap a lot of parsing work that Ruby is already doing, into an API which allows Ruby code to take advantage of it. ## Use-cases My motivation for designing this feature came about whilst I was experimenting with some ideas for Ruby profilers. I wanted to allow a CLI tool to ask a Ruby process to start profiling itself by sending a message on a unix socket. Alongside the message, it would send a file descriptor which was the result of calling `perf_event_open(2)` in the CLI tool. In order to call `perf_event_open(2)`, the CLI tool would need to be privileged. I also wanted the Ruby process to authenticate the request and make sure it came from the same UID that it was running as. Calling `BasicSocket#getpeereuid` would reveal the remote process to be running as UID 0, (or perhaps even some other UID, with sufficient ambient capabilities to call `perf_event_open`). Instead, I decided to make the CLI tool send a `SCM_CREDENTIALS` message containing the uid of the process to be profiled; that way, the kernel does all the policy checking on whether or not this is actually allowed, and the Ruby process receiving the message just needs to check if `uid == Process.getuid`. I think, on Linux at least, that this feature will be useful for any kind of communication/authentication scheme between privileged & unprivileged processes over unix sockets. ## My implementation I have an implementation of roughly this in this pull request: https://github.com/ruby/ruby/pull/6822 Thanks! -- https://bugs.ruby-lang.org/

3 4

[ruby-core:111501] [Ruby master Bug#19283] Regex error on ruby 3.2
by Sho (Shohei Nakano) 09 Feb '23

09 Feb '23

Issue #19283 has been reported by Sho (Shohei Nakano). ---------------------------------------- Bug #19283: Regex error on ruby 3.2 https://bugs.ruby-lang.org/issues/19283 * Author: Sho (Shohei Nakano) * Status: Open * Priority: Normal * ruby -v: 3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- There is an regex error pattern on ruby 3.2.0. This pattern is success on ruby 3.1.3. Is this a bug? Or, is ruby 3.2.0 correct? - ruby 3.2.0 ``` # ruby -v ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] (byebug) MAX_CHAR_LENGTH = 8 8 (byebug) WHITE_SPACE_STR = '[[:space:]]　\uFEFF\u00A0\u200B\u180E' "[[:space:]]　\\uFEFF\\u00A0\\u200B\\u180E" (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,8}x)|(.{,8}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,8}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') #<MatchData "a b" 1:"a b" 2:nil 3:"a b"> (byebug) MAX_CHAR_LENGTH = 9 9 (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,9}x)|(.{,9}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,9}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') nil ``` - ruby 3.1.3 ``` # ruby -v ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] (byebug) MAX_CHAR_LENGTH = 8 8 (byebug) WHITE_SPACE_STR = '[[:space:]]　\uFEFF\u00A0\u200B\u180E' "[[:space:]]　\\uFEFF\\u00A0\\u200B\\u180E" (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,8}x)|(.{,8}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,8}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') #<MatchData "a b" 1:"a b" 2:nil 3:"a b"> (byebug) MAX_CHAR_LENGTH = 9 9 (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,9}x)|(.{,9}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,9}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') #<MatchData "a b" 1:"a b" 2:nil 3:"a b"> ``` -- https://bugs.ruby-lang.org/

1 2

[ruby-core:111461] [Ruby master Feature#19272] Hash#merge: smarter protocol depending on passed block arity
by zverok (Victor Shepelev) 09 Feb '23

09 Feb '23

Issue #19272 has been reported by zverok (Victor Shepelev). ---------------------------------------- Feature #19272: Hash#merge: smarter protocol depending on passed block arity https://bugs.ruby-lang.org/issues/19272 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- Usage of `Hash#merge` with a "conflict resolution block" is almost always clumsy: due to the fact that the block accepts `|key, old_val, new_val|` arguments, and many trivial usages just somehow sum up old and new keys, the thing that should be "intuitively trivial" becomes longer than it should be: ```ruby # I just want a sum! {apples: 1, oranges: 2}.merge(apples: 3, bananas: 5) { |_, o, n| o + n } # I just want a group! {words: %w[I just]}.merge(words: %w[want a group]) { |_, o, n| [*o, *n] } # I just want to unify flags! {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE) { |_, o, n| o | n } # ...or, vice versa: {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE, 'file2' => File::WRITABLE) { |_, o, n| o & n } ``` It is especially noticeable in the last two examples, but the _usual_ problem is there are too many "unnecessary" punctuation, where the essential might be lost. There are proposals like #19148, which struggle to define _another_ method (what would be the name? isn't it just merging?) But I've been thinking, can't the implementation be chosen based on the arity of the passed block?.. Prototype: ```ruby class Hash alias old_merge merge def merge(other, &block) return old_merge(other) unless block if block.arity.abs != 2 old_merge(other, &block) else old_merge(other) { |_, o, n| block.call(o, n) } end end end {apples: 1, oranges: 2}.merge(apples: 3, bananas: 5, &:+) #=> {:apples=>4, :oranges=>2, :bananas=>5} {words: %w[I just]}.merge(words: %w[want a group], &:concat) => {:words=>["I", "just", "want", "a", "group"]} {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE, &:|) # => {"file1"=>5, "file2"=>5} {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE, 'file2' => File::WRITABLE, &:&) # => {"file1"=>0, "file2"=>4} # If necessary, old protocol still works: {apples: 1, oranges: 2}.merge(apples: 3, bananas: 5) { |k, o, n| k == :apples ? 0 : o + n } # => {:apples=>0, :oranges=>2, :bananas=>5} ``` As far as I can remember, Ruby core doesn't have methods like this (that change implementation depending on arity of passed callable), but I think I saw this approach in other languages. Can't remember particular examples, but always found this idea appealing. -- https://bugs.ruby-lang.org/

5 8

[ruby-core:111146] [Ruby master Bug#19172] `ruby_thread_has_gvl_p` is innacurate sometimes -- document or change?
by ivoanjo (Ivo Anjo) 02 Feb '23

02 Feb '23

Issue #19172 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #19172: `ruby_thread_has_gvl_p` is innacurate sometimes -- document or change? https://bugs.ruby-lang.org/issues/19172 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal * ruby -v: (All Ruby versions) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Howdy 👋! I work for Datadog [on the ddtrace gem](https://github.com/DataDog/dd-trace-rb) and I found a... sharp edge on the internal `ruby_thread_has_gvl_p` API. I am aware that `ruby_thread_has_gvl_p` is documented an experimental API that is exported as a symbol but not present on the VM include files. ### Background In the ddtrace profiling component, we setup a signal handler and then periodically send SIGPROF signals to try to interrupt the running Ruby thread (e.g. the thread that is holding the global VM lock or equivalent). In the signal handler, we need to perform some API calls which are not safe to do without the GVL. So we need to check if the signal handler got called in the thread that has the GVL. ### The issue ```ruby int ruby_thread_has_gvl_p(void) { rb_thread_t *th = ruby_thread_from_native(); if (th && th->blocking_region_buffer == 0) { return 1; } else { return 0; } } ``` In its current implementation, `ruby_thread_has_gvl_p` only checks if the thread has a `blocking_region_buffer` or not. Unfortunately, this means that when called from a thread that lost the GVL but not due to blocking (e.g. via `rb_thread_schedule()`), it can still claim that a thread is holding the GVL when that is not the case. I ran into this issue in https://github.com/DataDog/dd-trace-rb/pull/2415, and needed to find a workaround. ### Next steps Since this is an internal VM API, I'm not sure you'd want to change the current behavior, so I was thinking of perhaps two options: * Is it worth changing `ruby_thread_has_gvl_p` to be accurate in the case I've listed? * If not, would you accept a PR to document its current limitations, so that others don't run into the same issue I did? -- https://bugs.ruby-lang.org/

2 2