General

Profile

Shugo Maeda

  • Registered on: 05/08/2008
  • Last connection: 01/18/2017

Issues

Projects

Activity

01/20/2017

12:26 PM Ruby trunk Feature #13110: Byte-based operations for String
> The "buffer gap" technique is very well known, I'm familiar with it since the early 90ies. I was thinking about it,...

01/19/2017

08:13 AM Ruby trunk Bug #13135 (Closed): Regexp.last_match returns nil with s.rindex(//)
Applied in changeset r57374.
----------
string.c: rindex(//) should set $~.
This seems a bug introduced by r520 (1....
08:13 AM Ruby trunk Revision 57374: string.c: rindex(//) should set $~.
This seems a bug introduced by r520 (1.4.0). [ruby-core:79110] [Bug #13135]

01/18/2017

05:57 AM Ruby trunk Bug #13135: Regexp.last_match returns nil with s.rindex(//)
Shugo Maeda wrote:
> Regexp.last_match returns nil, if // is given to String#rindex:
The following patch seems to...
02:53 AM Ruby trunk Bug #13135 (Closed): Regexp.last_match returns nil with s.rindex(//)
Regexp.last_match returns nil, if // is given to String#rindex:
```
lexington:ruby$ ruby -ve 'p "foo".rindex(//);...

01/12/2017

02:20 AM Ruby trunk Bug #13018: end of file reached (EOFError) from SMTP
Shugo Maeda wrote:
> Can we close this issue by fixing backtrace information?
Closed by r57311, but feel free to...
02:19 AM Ruby trunk Bug #13018 (Closed): end of file reached (EOFError) from SMTP
Applied in changeset r57311.
----------
lib/net/protocol.rb: preserve backtrace information
BufferedIO#rbuf_fill sh...
02:19 AM Ruby trunk Revision 57311: lib/net/protocol.rb: preserve backtrace information
BufferedIO#rbuf_fill should preserve backtrace information when raising
EOFError. Otherwise, users get confused when...
01:32 AM Ruby trunk Bug #13018: end of file reached (EOFError) from SMTP
Toby Murray wrote:
> Someone has commented on the Rails issue here: https://github.com/rails/rails/issues/27298#is...

01/09/2017

10:50 PM Ruby trunk Feature #13110: Byte-based operations for String
Benoit Daloze wrote:
> Shugo Maeda wrote:
> > Martin Dürst wrote:
> > > What about using UTF-32? It will use some ...

Also available in: Atom