[#87467] [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError — mofezilla@...
Issue #14841 has been reported by hirura (Hiroyuki URANISHI).
3 messages
2018/06/10
[#87515] [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError — hirura@...
Issue #14841 has been updated by hirura (Hiroyuki URANISHI).
7 messages
2018/06/19
[#87516] Re: [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError
— Eric Wong <normalperson@...>
2018/06/19
hirura@gmail.com wrote:
[#87517] Re: [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError
— Eric Wong <normalperson@...>
2018/06/19
Sorry, I left this out: If you can reproduce it again, can you
[#87519] Re: [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError
— hirura <hirura@...>
2018/06/19
Hi Eric,
[#87521] Re: [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError
— Eric Wong <normalperson@...>
2018/06/19
hirura <hirura@gmail.com> wrote:
[#87541] [Ruby trunk Feature#14859] [PATCH] implement Timeout in VM — normalperson@...
Issue #14859 has been reported by normalperson (Eric Wong).
4 messages
2018/06/21
[#87605] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — takashikkbn@...
Issue #14867 has been reported by k0kubun (Takashi Kokubun).
3 messages
2018/06/23
[#87614] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — normalperson@...
Issue #14867 has been updated by normalperson (Eric Wong).
4 messages
2018/06/23
[#87631] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — takashikkbn@...
Issue #14867 has been updated by k0kubun (Takashi Kokubun).
5 messages
2018/06/25
[#87635] Re: [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process
— Eric Wong <normalperson@...>
2018/06/25
takashikkbn@gmail.com wrote:
[#87665] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — eregontp@...
Issue #14867 has been updated by Eregon (Benoit Daloze).
4 messages
2018/06/28
[#87710] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — Greg.mpls@...
Issue #14867 has been updated by MSP-Greg (Greg L).
3 messages
2018/06/30
[ruby-core:87422] [Ruby trunk Bug#8316] Can't pass hash to first positional argument; hash interpreted as keyword arguments
From:
tyler@...
Date:
2018-06-06 01:49:17 UTC
List:
ruby-core #87422
Issue #8316 has been updated by TylerRick (Tyler Rick).
ozydingo (Andrew Schwartz) wrote:
> This is unfortunately still an issue with default values in positional arguments:
>
> 2.2.2 > def foo(hash={}, opt: true); p hash; p opt; end
> => :foo
> 2.2.2 > foo({a: 1})
> ArgumentError: unknown keyword: a
>
> Expected behavior is that foo can be called with a hash argument in the first position without needing to specify the optional keyword args.
Ay! Just ran into this today.
Looks like this case is tracked in #12717 and #11967 but won't be fixed until Ruby 3 (#14183).
I wish there were a good workaround. Best I was able to come up with was:
```
def foo(hash={}, options = {opt: true})
opt = options[:opt]
[hash, opt]
end
> foo({a: 1})
=> [{:a=>1}, true]
> foo({a: 1}, opt: false)
=> [{:a=>1}, false]
```
----------------------------------------
Bug #8316: Can't pass hash to first positional argument; hash interpreted as keyword arguments
https://bugs.ruby-lang.org/issues/8316#change-72410
* Author: TylerRick (Tyler Rick)
* Status: Closed
* Priority: Normal
* Assignee: mame (Yusuke Endoh)
* Target version:
* ruby -v: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-darwin13]
* Backport:
----------------------------------------
I'm able to pass any other type of object to my first argument:
def foo(hash, opt: true)
puts "hash: #{hash}, opt: #{opt.inspect}"
end
foo 'a' # => hash: a, opt: true
foo [{a:1}] # => hash: [{:a=>1}], opt: true
foo [{a:1}], opt: false # => hash: [{:a=>1}], opt: false
But when I try to pass a hash, it raises an ArgumentError:
foo({a:1}) # Raises ArgumentError: unknown keyword: a
# Expected behavior: hash: {:a=>1}, opt: true
I tried to work around the "unknown keyword" error by using ** but ended up getting a "wrong number of arguments (0 for 1)" error instead.
def foo_with_extra(hash, **extra)
puts "hash: #{hash}, extra: #{extra.inspect}"
end
foo_with_extra 'a' # hash: a, extra: {}
foo_with_extra [{a:1}] # hash: [{:a=>1}], extra: {}
foo_with_extra [{a:1}], opt: false # hash: [{:a=>1}], extra: {:opt=>false}
foo_with_extra({a:1}) # Raises ArgumentError: wrong number of arguments (0 for 1)
# Expected behavior: hash: {:a=>1}, extra: {}
This behavior is surprising and I haven't seen it mentioned anywhere before. Is it really intentional?
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>