[#75225] [Ruby trunk Feature#12324] Support OpenSSL 1.1.0 (and drop support for 0.9.6/0.9.7) — k@...
Issue #12324 has been reported by Kazuki Yamaguchi.
6 messages
2016/04/27
[#78693] Re: [Ruby trunk Feature#12324] Support OpenSSL 1.1.0 (and drop support for 0.9.6/0.9.7)
— Eric Wong <normalperson@...>
2016/12/17
k@rhe.jp wrote:
[#78701] Re: [Ruby trunk Feature#12324] Support OpenSSL 1.1.0 (and drop support for 0.9.6/0.9.7)
— Kazuki Yamaguchi <k@...>
2016/12/17
On Sat, Dec 17, 2016 at 01:31:12AM +0000, Eric Wong wrote:
[#78702] Re: [Ruby trunk Feature#12324] Support OpenSSL 1.1.0 (and drop support for 0.9.6/0.9.7)
— Eric Wong <normalperson@...>
2016/12/17
Kazuki Yamaguchi <k@rhe.jp> wrote:
[ruby-core:75059] [Ruby trunk Feature#12306] Implement String #blank? #present? and improve #strip and family to handle unicode
From:
sam.saffron@...
Date:
2016-04-21 02:29:06 UTC
List:
ruby-core #75059
Issue #12306 has been updated by Sam Saffron.
Nobuyoshi Nakada wrote:
> I think that `String#blank?` equals to `/\P{space}/ !~ self`.
> Is it slow, especially than `strip`?
Yes, in Rails apps this blank very quickly becomes a bottleneck see: http://tmm1.net/ruby21-profiling/ for a real world example. I have seen Rails applications spend 2-5% of the time in Active Support String#blank? it is used super aggressively due to the "style" of programming used.
Recently Richard Schneems has been micro optimizing blank? due to this discovery see: https://github.com/rails/rails/pull/24658
The regex approach will never come close to a native implementation see bench here: https://github.com/SamSaffron/fast_blank
@Matz as to why this tends to happen so much in Rails world, this is a super common scenario
- Allow a textinput with User name
- Then from controller run
```
# one letter name is fine, especially for Chinese names, but blank is not
raise YouGotToAddAName if params[:name].blank?
```
In Rails programming it turns out that people are checking for "blankness" of strings in tons and tons of very very common scenario. The speed boost of having a fast native implementation would be very welcome.
I am fine with not adding present? ( unless s.blank?) fills the need just fine
Regarding timing, would a PR adding blank? and unicode support to strip be welcome for 2.4 timeframe?
Regarding non-unicode strings I think strip should just keep working the way it does now.
----------------------------------------
Feature #12306: Implement String #blank? #present? and improve #strip and family to handle unicode
https://bugs.ruby-lang.org/issues/12306#change-58180
* Author: Sam Saffron
* Status: Open
* Priority: Normal
* Assignee:
----------------------------------------
Time and again there have been rejected feature requests to Ruby core to implement `blank` and `present` protocols across all objects as ActiveSupport does. I am fine with this call and think it is fair.
However, for the narrow case of String having `#blank?` and `#present?` makes sense.
- Provides a natural extension over `#strip`, `#lstrip` and `#rstrip`. `(" ".strip.length == 0) == " ".blank?`
- Plays nicely with ActiveSupport, providing an efficient implementation in Ruby core: see: https://github.com/SamSaffron/fast_blank, implementing blank efficiently requires a c extension.
However, if this work is to be done, `#strip` and should probably start dealing with unicode blanks, eg:
```
irb(main):008:0> [0x3000].pack("U")
=> " "
irb(main):009:0> [0x3000].pack("U").strip.length
=> 1
```
So there are 2 questions / feature requests here
1. Can we add blank? and present? to String?
2. Can we amend strip and family to account for unicode per: https://github.com/SamSaffron/fast_blank/blob/master/ext/fast_blank/fast_blank.c#L43-L74
--
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>