[#53893] [ruby-trunk - Bug #8204][Open] ObjectSpace.each_object(Bignum) can generate Bignums that are to small to be Bignums — "Hanmac (Hans Mackowiak)" <hanmac@...>
[#53914] [ruby-trunk - Feature #8206][Open] Should Ruby core implement String#blank? — "sam.saffron (Sam Saffron)" <sam.saffron@...>
[#53922] [ruby-trunk - Bug #8208][Open] Raise cached exceptions for nonblocking IO to avoid allocation/stack-copying costs — "headius (Charles Nutter)" <headius@...>
"headius (Charles Nutter)" <[email protected]> wrote:
[#53950] [ruby-trunk - Bug #8211][Open] Performance regression of method calls — "dunric (David Unric)" <dunric29a@...>
[#53974] [ruby-trunk - Feature #8215][Open] Support accessing Fiber-locals and backtraces for a Fiber — "halorgium (Tim Carey-Smith)" <ruby-lang-bugs@...>
[#54023] [ruby-trunk - Feature #8223][Open] Make Matrix more omnivorous. — "boris_stitnicky (Boris Stitnicky)" <boris@...>
[#54031] Question about r39944 — Aaron Patterson <tenderlove@...>
Hi,
Even if test directory should be on the load path on test-all, you should
[#54095] [ruby-trunk - Feature #8237][Open] Logical method chaining via inferred receiver — "wardrop (Tom Wardrop)" <tom@...>
[#54175] [ruby-trunk - Bug #8254][Open] Ruby segfaults on second SystemStackError from parser — "charliesome (Charlie Somerville)" <charlie@...>
[#54185] [CommonRuby - Feature #8257][Open] Exception#cause to carry originating exception along with new one — "headius (Charles Nutter)" <headius@...>
(2013/04/12 1:40), headius (Charles Nutter) wrote:
On Sat, Apr 27, 2013 at 5:19 PM, SASADA Koichi <[email protected]> wrote:
[#54196] Encouraging use of CommonRuby — Charles Oliver Nutter <headius@...>
I think we need to do more to encourage the use of the CommonRuby
Hi,
As far as I understand, what is CommonRuby and the process over CommonRuby
On Thu, Apr 11, 2013 at 11:25 PM, NARUSE, Yui <[email protected]> wrote:
(2013/04/12 16:40), Charles Oliver Nutter wrote:
On Fri, Apr 12, 2013 at 8:08 AM, NARUSE, Yui <[email protected]> wrote:
[#54201] Has ObjectSpace changed recently? — Dave Thomas <dave@...>
I just noticed that in 2.0, I see this:
[#54207] [CommonRuby - Feature #8258][Open] Dir#escape_glob — "steveklabnik (Steve Klabnik)" <steve@...>
[#54218] [CommonRuby - Feature #8259][Open] Atomic attributes accessors — "funny_falcon (Yura Sokolov)" <funny.falcon@...>
Issue #8259 has been updated by Charles Nutter.
I'm not sure if setting the attribute on the ivar is a good way to go.
[#54333] Requesting Commit Access — Aman Gupta <[email protected]>
Hello ruby-core,
Hi,
On Apr 16, 2013, at 4:34 AM, Aman Gupta <[email protected]> wrote:
[#54415] [ruby-trunk - Bug #8286][Open] Can't decode non-MIME Base64 — "adacosta (Alan Da Costa)" <alandacosta@...>
[#54459] [CommonRuby - Feature #8291][Open] Allow retrieving the root Fiber of a Thread — "halorgium (Tim Carey-Smith)" <ruby-lang@...>
[#54473] [Backport 200 - Backport #8299][Open] Minor error in float parsing — "bobjalex (Bob Alexander)" <bobjalex@...>
[#54509] [ruby-trunk - Bug #8310][Open] resque-web crashes with segfault on Ruby 2.0.0-p0 only, Resque 1.24.1, Redis 2.6.12 — "vaharoni (Amit Aharoni)" <amit.sites@...>
[#54559] [ruby-trunk - Feature #8321][Open] Ripper: I would like coordinates for keywords — "ericp (Eric Promislow)" <eric.promislow@...>
[#54606] Plan to the first 2.0.0 patchlevel release. — Tomoyuki Chikanaga <nagachika00@...>
Hello, Rubyists.
Hi,
Could you please backport the following:
[#54621] [ruby-trunk - Feature #8339][Open] Introducing Geneartional Garbage Collection for CRuby/MRI — "ko1 (Koichi Sasada)" <redmine@...>
(2013/04/28 9:23), authorNari (Narihiro Nakamura) wrote:
2013/4/28 SASADA Koichi <[email protected]>:
(2013/05/04 12:08), Narihiro Nakamura wrote:
2013/5/4 SASADA Koichi <[email protected]>:
(2013/05/06 11:50), Tanaka Akira wrote:
2013/5/6 SASADA Koichi <[email protected]>:
On Sat, Apr 27, 2013 at 8:19 PM, ko1 (Koichi Sasada)
(2013/04/28 21:40), Magnus Holm wrote:
(2013/04/28 23:34), SASADA Koichi wrote:
On Sun, Apr 28, 2013 at 6:07 PM, SASADA Koichi <[email protected]> wrote:
(2013/04/29 1:19), Magnus Holm wrote:
On Sun, Apr 28, 2013 at 6:29 PM, SASADA Koichi <[email protected]> wrote:
"ko1 (Koichi Sasada)" <[email protected]> wrote:
[#54665] [ruby-trunk - Bug #8344][Open] Status of Psych and Syck — "Eregon (Benoit Daloze)" <redmine@...>
[ruby-core:54402] [CommonRuby - Feature #8259] Atomic attributes accessors
Issue #8259 has been updated by headius (Charles Nutter).
dbussink (Dirkjan Bussink) wrote:
> I highly doubt the neverending complaints case, since this I think people using CAS would usually know what they are doing (at least my experience with using constructs like this). The overhead is actually bigger for the numeric case where a CAS would work for example for Fixnum on MRI and Rubinius without the extra checks. That could of course be optimized in implementations for those platforms.
You may be right about complaints...I use atomics all the time but I'm unusual. Skewed viewpoint, perhaps.
I'm not sure what you mean by "the overhead is actually bigger". It's a kind_of? type check at worst...is that expensive in Rubinius?
Also, Fixnum will *not* work consistently on MRI or Rubinius without extra checks if any of the values are close to the Fixnum boundary. Optimization specific to those impls would still have to confirm the Fixnum is within a certain range. Perhaps working with Fixnums that are at the failover point into Bignum is not common, but you can't just omit those checks. And you have to know you're dealing with a Fixnum anyway...so you have to check every time.
My justification for doing it unconditionally for all numerics is largely because of the overflow into Bignum. Ruby pretends that integers are one continuum, but only part of that continuum (varying across impls and architectures) is actually idempotent. As a result, all integers would need some portion of the equality checking logic on every implementation.
> If you're worried about confusion between equality and identity, we could also have an equality based CAS be the default and have the possibility of using an identity based version if people know that is what they want.
That's not a bad option, I guess. The main problem here is that I feel like people expect numerics of equal value to essentially be identical, and that's not the case for most numerics on most implementations. If people think they're essentially identical, they might expect CAS to work properly. I don't believe people would have that expectation of non-numerics, so extending equality CAS to all types seems like overkill.
----------------------------------------
Feature #8259: Atomic attributes accessors
https://bugs.ruby-lang.org/issues/8259#change-38664
Author: funny_falcon (Yura Sokolov)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:
=begin
Motivated by this gist ((<URL:https://gist.github.com/jstorimer/5298581>)) and atomic gem
I propose Class.attr_atomic which will add methods for atomic swap and CAS:
class MyNode
attr_accessor :item
attr_atomic :successor
def initialize(item, successor)
@item = item
@successor = successor
end
end
node = MyNode.new(i, other_node)
# attr_atomic ensures at least #{attr} reader method exists. May be, it should
# be sure it does volatile access.
node.successor
# #{attr}_cas(old_value, new_value) do CAS: atomic compare and swap
if node.successor_cas(other_node, new_node)
print "there were no interleaving with other threads"
end
# #{attr}_swap atomically swaps value and returns old value.
# It ensures that no other thread interleaves getting old value and setting
# new one by cas (or other primitive if exists, like in Java 8)
node.successor_swap(new_node)
It will be very simple for MRI cause of GIL, and it will use atomic primitives for
other implementations.
Note: both (({#{attr}_swap})) and (({#{attr}_cas})) should raise an error if instance variable were not explicitly set before.
Example for nonblocking queue: ((<URL:https://gist.github.com/funny-falcon/5370416>))
Something similar should be proposed for Structs. May be override same method as (({Struct.attr_atomic}))
Open question for reader:
should (({attr_atomic :my_attr})) ensure that #my_attr reader method exists?
Should it guarantee that (({#my_attr})) provides 'volatile' access?
May be, (({attr_reader :my_attr})) already ought to provide 'volatile' semantic?
May be, semantic of (({@my_attr})) should have volatile semantic (i doubt for that)?
=end
--
http://bugs.ruby-lang.org/