[#80974] [Ruby trunk Feature#13517] [PATCH] reduce rb_mutex_t size from 160 to 80 bytes on 64-bit — ko1@...
Issue #13517 has been updated by ko1 (Koichi Sasada).
4 messages
2017/05/02
[#81024] Re: [Ruby trunk Feature#13517] [PATCH] reduce rb_mutex_t size from 160 to 80 bytes on 64-bit
— SASADA Koichi <ko1@...>
2017/05/07
sorry for late response.
[#80996] [Ruby trunk Feature#13544] Allow loading an ISeqs sequence directly from a C extension without requiring buffer is in an RVALUE — sam.saffron@...
Issue #13544 has been reported by sam.saffron (Sam Saffron).
3 messages
2017/05/04
[#81016] [Ruby trunk Bug#13526] Segmentation fault at 0x0055c2e58e8920 ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux] — s.wanabe@...
Issue #13526 has been updated by wanabe (_ wanabe).
3 messages
2017/05/07
[#81048] Re: [ruby-cvs:65788] normal:r58614 (trunk): rb_execution_context_t: move stack, stack_size and cfp from rb_thread_t — SASADA Koichi <ko1@...>
It causes compile error on raspi 3.
3 messages
2017/05/09
[#81201] Re: [ruby-cvs:65935] normal:r58761 (trunk): test/test_extilibs.rb: do not check the existence of fiddle — "U.NAKAMURA" <usa@...>
Hi, Eric
4 messages
2017/05/16
[#81202] Re: [ruby-cvs:65935] normal:r58761 (trunk): test/test_extilibs.rb: do not check the existence of fiddle
— Eric Wong <normalperson@...>
2017/05/16
"U.NAKAMURA" <usa@garbagecollect.jp> wrote:
[#81427] Fwd: [ruby-changes:46809] normal:r58924 (trunk): test for IO.copy_stream CPU usage (r58534) — SASADA Koichi <ko1@...>
Hi,
6 messages
2017/05/28
[#81428] Re: Fwd: [ruby-changes:46809] normal:r58924 (trunk): test for IO.copy_stream CPU usage (r58534)
— Eric Wong <normalperson@...>
2017/05/28
SASADA Koichi <ko1@atdot.net> wrote:
[ruby-core:81447] [Ruby trunk Bug#13589] unmatched opening backtick / closing quote in NoMethodError: undefined method `name' for {}:Hash
From:
duerst@...
Date:
2017-05-29 08:13:05 UTC
List:
ruby-core #81447
Issue #13589 has been updated by duerst (Martin Dürst).
shyouhei (Shyouhei Urabe) wrote:
> domaio (Dorian M) wrote:
> > Looking at error.c in general, it seems like a rather intentional
>
> Yes. I bekieve this is how quotation marks in English works. I don't like the idea to change our error messages only because wild Markdown parsers don't interface.
Well, to be precise, English quotations use ‘…’ and “…” in high-quality typography. The use of `…' is a fallback convention on some systems. See https://en.wikipedia.org/wiki/Quotation_mark#Typewriters_and_early_computers. The number of characters in ASCII was very limited, so the "`" character had to cover both as the grave accent (used after a base character and a backspace character, or before a backspace and the base character) and as a backquote. On typewriters, the "`" was usually not available, and so simple '…' was used.
----------------------------------------
Bug #13589: unmatched opening backtick / closing quote in NoMethodError: undefined method `name' for {}:Hash
https://bugs.ruby-lang.org/issues/13589#change-65152
* Author: domaio (Dorian M)
* Status: Rejected
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin16]
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
From [`error.c`](https://github.com/ruby/ruby/blob/trunk/error.c#L1953-L1964):
~~~ c
/*
* Document-class: NoMethodError
*
* Raised when a method is called on a receiver which doesn't have it
* defined and also fails to respond with +method_missing+.
*
* "hello".to_ary
*
* <em>raises the exception:</em>
*
* NoMethodError: undefined method `to_ary' for "hello":String
*/
~~~
For instance:
~~~ ruby
>> {}.c
NoMethodError: undefined method `c' for {}:Hash
>> {}.name
NoMethodError: undefined method `name' for {}:Hash
~~~
Expected (two tildes):
~~~ ruby
NoMethodError: undefined method `c` for {}:Hash
~~~
Expected (two single quotes):
~~~ ruby
NoMethodError: undefined method 'c' for {}:Hash
~~~
P.S.: I just noticed it's the same for method names, e.g.:
~~~ ruby
`<main>'
# in
from /Users/d/.rvm/rubies/ruby-2.4.1/bin/irb:11:in `<main>'
~~~
Looking at error.c in general, it seems like a rather intentional behavior but I didn't see any explanation of it (and it doesn't look good / make it easy to copy/paste for me, even all those code examples are messed up because of it :) (but not the ones with the fixed syntax ;) ) ).
--
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>