[#84867] [Ruby trunk Bug#14357] thread_safe tests suite segfaults — v.ondruch@...
Issue #14357 has been reported by vo.x (Vit Ondruch).
11 messages
2018/01/15
[#85364] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/03
v.ondruch@tiscali.cz wrote:
[#85368] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/03
Eric Wong wrote:
[#85442] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Eric Wong <normalperson@...>
2018/02/06
Eric Wong <normalperson@yhbt.net> wrote:
[#85451] Re: [Ruby trunk Bug#14357] thread_safe tests suite segfaults
— Vladimir Makarov <vmakarov@...>
2018/02/06
On 02/06/2018 05:00 AM, Eric Wong wrote:
[#84874] [Ruby trunk Bug#14360] Regression CSV#open method for writing from Ruby 2.4.3 to 2.5.0 — shevegen@...
Issue #14360 has been updated by shevegen (Robert A. Heiler).
3 messages
2018/01/15
[#84980] [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — hsbt@...
Issue #13618 has been updated by hsbt (Hiroshi SHIBATA).
10 messages
2018/01/23
[#85012] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/01/23
hsbt@ruby-lang.org wrote:
[#85081] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/01/24
Eric Wong <normalperson@yhbt.net> wrote:
[#85082] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/01/24
> Thinking about this even more; I don't think it's possible to
[#85088] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — danieldasilvaferreira@...
Issue #13618 has been updated by dsferreira (Daniel Ferreira).
3 messages
2018/01/25
[#85107] [Ruby trunk Misc#14222] Mutex.lock is not safe inside signal handler: what is? — eregontp@...
Issue #14222 has been updated by Eregon (Benoit Daloze).
3 messages
2018/01/25
[#85136] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — Eric Wong <normalperson@...>
samuel@oriontransfer.org wrote:
3 messages
2018/01/26
[ruby-core:85056] [Ruby trunk Feature#14392] Pipe operator
From:
zverok.offline@...
Date:
2018-01-24 15:13:31 UTC
List:
ruby-core #85056
Issue #14392 has been updated by zverok (Victor Shepelev).
Let me, then, introduce some philosphy here (I know this issue will be rejected anyways, so whatever).
When you propose new language feature, it is often useful to think a bit of it: how it plays with other features and general language intuition? Would it benefit from existing concepts, or will require the introduction of a bunch of new concepts? Will it look similar to other situations or strikingly dissimilar "special case just for the prettyness for one particular usage"?
```ruby
value |> method_name
```
...is really awful on all those accounts.
What is `method_name` here? Because in ALL other contexts, naked `method_name` means immediate call of the method. Can we have proc there? If no, why? If yes, how it will be compatible with `method_name` syntax?
Applying some "next processing" to ONE value is strikingly different from applying some to COLLECTION:
In Elixir:
```elixir
collection |> Enumerable.map(...)
one_value |> String.split(...)
```
In Ruby 2.5
```ruby
collection.map { ... }
one_value.yield_self { ... }
# with some method
collection.map(&method(:puts))
one_value.yield_self(&method(:puts))
```
Your proposal:
```ruby
collection.map { ... }
one_value |> something
```
It already looks messed up :)
I agree that `yield_self(&method(:puts))` is less-than-optimal. Two problems here are:
* `method()`, the price we pay for having `()`-less method calls; there are ongoing discussions of shorthand syntax;
* REALLY unfortunate `yield_self` name, which I'll never get tired to blame.
But otherwise, it is perfectly idiomatic and readable Ruby, playing well with all usual metaphors and intuitions.
People tend to constantly mix "syntax akin to other language" or "syntax as I imagine it in my head" with "syntax which is clear and idiomatic". ¯\\\_(ツ)_/¯
----------------------------------------
Feature #14392: Pipe operator
https://bugs.ruby-lang.org/issues/14392#change-69774
* Author: dsferreira (Daniel Ferreira)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
I would like to see implemented in ruby a pipe operator as we have in elixir.
An example of application I have in mind is this:
```ruby
class Foo
def bar(var)
puts “Hello #{var}!”
end |> private
def baz(arg)
bar(arg)
end
end
foo = Foo.new
foo.baz("Fred") # => "Hello Fred!"
```
It can also help simplify method chains:
```ruby
class Secret
def initialise(user, password)
@user = user
@password = password
end
def second_pass(encrypted_string)
encrypted_string.chain_4.chain_5.chain_6
end |> private
##
# Super encryption
def super_encryption
@password.chain_1.chain_2.chain_3
|> second_pass
end |> public
end
```
And also simplify codes like this:
```ruby
class Foo
def bar(*args)
baz = args.select { |arg| arg =~ /regex/ }.first
good?(baz)
end
public :bar
def good(arg)
arg.to_s.size > 10
end
private :good
end
```
to become:
```ruby
class Foo
##
# Bar public method.
def bar(*args)
args.select { |arg| arg =~ /regex/ }.first
|> good?
end |> public
def good(arg)
arg.to_s.size > 10
end |> private
end
```
Lots of local variables would be saved and I would expect some performance improvements with that.
--
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>