[#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:85080] [Ruby trunk Feature#14392] Pipe operator
From:
danieldasilvaferreira@...
Date:
2018-01-24 21:41:07 UTC
List:
ruby-core #85080
Issue #14392 has been updated by dsferreira (Daniel Ferreira).
shevegen (Robert A. Heiler) wrote:
> No |> though.
Hi Robert, many thanks for the extensive comment.
The idea of using `"|>"` as the proposed pipe operator came from my analysis of https://bugs.ruby-lang.org/issues/13581 issue coupled with long time syntax thoughts.
I proposed a syntax sugar for `13581` as `"|>"` or `"<|"`. You can read the logic there.
It makes sense in my head.
Resembles the way bash instructions work in multiple directions.
Ruby also has a lot of sh/bash logic in its core.
Using `"|"` coupled with `"<"` and `">"` seems to me an easy and intuitive way to overcome the syntax problem of having the three operators already with their own meanings in isolation.
> But I also very rarely use private in ruby in the first place
People don't really care about it but I do care a lot.
I like to work in top of a very well defined API.
The library API should be reduced to its minimum as much as possible.
And I want total freedom to do whatever inside the library.
So I use extensively `public`, `protected` and `private`.
I have some feature requests still open that I'm planning to implement in the near future and submit a patch.
One of them is https://bugs.ruby-lang.org/issues/9992 which is about the introduction of an `internal` access modifier which would define an `internal` interface just visible to the library namespace.
So you can see that this matters are very important to me and impact my daily work.
I love ruby but I'm not being able to express myself in the language like I would like to.
We don't live in an ideal world I know but I believe that my way of seeing the design of a library/gem or module/class brings a new insight into the ecosystem that may be good to consider by the community.
It is not easy to present the full picture of what I have in my mind so I'm starting to do it bit by bit.
With time people will understand better what is my vision and what am I proposing.
> That is also why I do not completely agree with the rubocop style guide
I'm with you 100% on this.
But you know, when you work in a big company and if you are the only one speaking in one direction you better end your talk.
Rubocop is now the default in the enterprise ruby.
Luckily I'm now in a position where my voice is heard.
But what I can't do is to tell about features that just exist in my head.
So here I am trying to make my dream a reality.
> I think elixir is cool but ruby is not elixir
This proposal it is not about Elixir.
I have never coded a single line in Elixir and I'm not planning to do it in the near future.
I mentioned Elixir just as a reference nothing else.
It seems people like language references when discussing this matters.
If that is not the case please say so and I will stop using those references.
----------------------------------------
Feature #14392: Pipe operator
https://bugs.ruby-lang.org/issues/14392#change-69797
* 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>