[#39810] 2.0 feature questionnaire — SASADA Koichi <ko1@...>

I made a questionnaire "What do you want to introduce in 2.0?" in my

59 messages 2011/10/01
[#39822] Re: 2.0 feature questionnaire — Jeremy Kemper <jeremy@...> 2011/10/02

2011/10/1 SASADA Koichi <ko1@atdot.net>:

[#39827] Re: 2.0 feature questionnaire — Yukihiro Matsumoto <matz@...> 2011/10/02

Hi,

[#40324] Re: 2.0 feature questionnaire — Charles Oliver Nutter <headius@...> 2011/10/25

2011/10/1 SASADA Koichi <ko1@atdot.net>:

[#39823] Discussion results — SASADA Koichi <ko1@...>

Hi,

34 messages 2011/10/02
[#39840] Re: Discussion results — Intransition <transfire@...> 2011/10/02

I did not have the fortune of attending the discussion, but I would

[#39844] Re: Discussion results — Yukihiro Matsumoto <matz@...> 2011/10/02

Hi,

[#39851] Re: Discussion results (here documents with indents) — "Martin J. Dürst" <duerst@...> 2011/10/03

Hello Matz,

[#39862] Re: Discussion results (here documents with indents) — Yusuke Endoh <mame@...> 2011/10/03

Hello,

[#39874] Re: Discussion results (here documents with indents) — Trans <transfire@...> 2011/10/03

On Mon, Oct 3, 2011 at 8:16 AM, Yusuke Endoh <mame@tsg.ne.jp> wrote:

[#39915] [Ruby 1.9 - Feature #5400][Open] Remove flip-flops in 2.0 — Magnus Holm <judofyr@...>

29 messages 2011/10/04

[#39957] [Ruby 1.9 - Bug #5407][Open] Cannot build ruby-1.9.3-rc1 with TDM-GCC 4.6.1 on Windows XP SP3 — Heesob Park <phasis@...>

11 messages 2011/10/05

[#39993] [Ruby 1.9 - Feature #2348] RBTree Should be Added to the Standard Library — David Graham <david.malcom.graham@...>

10 messages 2011/10/06

[#40037] [Ruby 1.9 - Bug #5422][Open] File.fnmatch != Dir.glob # {no,sets} — Suraj Kurapati <sunaku@...>

14 messages 2011/10/07

[#40073] [Ruby 1.9 - Feature #5427][Open] Not complex patch to improve `require` time (load.c) — Yura Sokolov <funny.falcon@...>

31 messages 2011/10/09

[#40090] [Ruby 1.9 - Bug #5433][Open] PTY.spawn Kernel panic on macos lion — Gamaliel Toro <argami@...>

14 messages 2011/10/10

[#40188] [Ruby 2.0 - Feature #5454] keyword arguments — Yukihiro Matsumoto <matz@...>

16 messages 2011/10/17
[#40189] Re: [Ruby 2.0 - Feature #5454] keyword arguments — Evan Phoenix <evan@...> 2011/10/17

This looks very interesting! Would someone be willing to translate to english? I've only got a vague idea of what is being discussed.

[#40191] Re: [Ruby 2.0 - Feature #5454] keyword arguments — Yutaka Hara <yutaka.hara@...> 2011/10/18

Hi,

[#40192] Re: [Ruby 2.0 - Feature #5454] keyword arguments — Yukihiro Matsumoto <matz@...> 2011/10/18

Hi,

[#40259] Counseling — Perry Smith <pedzsan@...>

Ruby and I are back in counseling... Its always the same thing with her. "I'm throwing an Encoding exception!!!"

21 messages 2011/10/21
[#40263] Re: Counseling — "Haase, Konstantin" <Konstantin.Haase@...> 2011/10/21

What's your $LC_CTYPE? What OS are you on?

[#40264] Re: Counseling — Gon軋lo Silva <goncalossilva@...> 2011/10/21

Hi all,

[#40266] Re: Counseling — Bill Kelly <billk@...> 2011/10/21

Gon軋lo Silva wrote:

[#40267] Re: Counseling — Perry Smith <pedzsan@...> 2011/10/22

[#40268] Re: Counseling — Eric Hodel <drbrain@...7.net> 2011/10/22

On Oct 21, 2011, at 9:43 AM, Perry Smith wrote:

[#40269] Re: Counseling — Joshua Ballanco <jballanc@...> 2011/10/22

To try and cut to the core of the issue: in Ruby 1.8 it was common practice to use the String class to represent both "proper strings" as well as a "bag-o-bytes". In Ruby 1.9, you can only properly use the String class to represent "proper strings". For a "bag-o-bytes" we're left with Array, but there are times when Array is not the right abstraction (e.g. reading data from a socket, identifying a start and stop token, and writing the bytes between to a file on disk). Also, the "BINARY" encoding is not the right abstraction, because you still have an object which will worry about encodings and, due to Ruby always trying to do "the right thing", bugs can be very difficult to track down. Consider:

[#40271] Can rubygems save us from "binary-compatibility hell"? — Yusuke Endoh <mame@...>

Hello, rubygems developers --

17 messages 2011/10/22

[#40290] [ruby-trunk - Feature #5474][Assigned] keyword argument — Yusuke Endoh <mame@...>

36 messages 2011/10/23
[#40414] Re: [ruby-trunk - Feature #5474][Assigned] keyword argument — Charles Oliver Nutter <headius@...> 2011/10/26

More refinement below. I think we're on a good path here.

[#40416] Re: [ruby-trunk - Feature #5474][Assigned] keyword argument — Yukihiro Matsumoto <matz@...> 2011/10/26

Hi,

[#40418] Re: [ruby-trunk - Feature #5474][Assigned] keyword argument — Joshua Ballanco <jballanc@...> 2011/10/26

On Wed, Oct 26, 2011 at 2:08 PM, Yukihiro Matsumoto <matz@ruby-lang.org>wrote:

[#40425] Re: [ruby-trunk - Feature #5474][Assigned] keyword argument — Yukihiro Matsumoto <matz@...> 2011/10/27

Hi,

[#40298] Re: [ruby-trunk - Feature #5474][Assigned] keyword argument — Yukihiro Matsumoto <matz@...> 2011/10/24

Hi,

[#40311] [ruby-trunk - Feature #5478][Open] import Set into core, add syntax — Konstantin Haase <Konstantin.Haase@...>

33 messages 2011/10/24

[#40312] [ruby-trunk - Feature #5479][Open] import StringIO into core, add String#to_io — Konstantin Haase <Konstantin.Haase@...>

9 messages 2011/10/24
[#40350] [ruby-trunk - Feature #5479] import StringIO into core, add String#to_io — Charles Nutter <headius@...> 2011/10/25

[#40316] [ruby-trunk - Feature #5481][Open] Gemifying Ruby standard library — Hiroshi Nakamura <nakahiro@...>

86 messages 2011/10/24
[#40334] [ruby-trunk - Feature #5481] Gemifying Ruby standard library — Lucas Nussbaum <lucas@...> 2011/10/25

[#40322] [ruby-trunk - Feature #5482][Open] Rubinius as basis for Ruby 2.0 — Thomas Sawyer <transfire@...>

19 messages 2011/10/25

[#40356] JIT development for MRI — Carter Cheng <cartercheng@...>

Hello,

25 messages 2011/10/25
[#40390] Re: JIT development for MRI — SASADA Koichi <ko1@...> 2011/10/26

Hi,

[#40394] Re: JIT development for MRI — Carter Cheng <cartercheng@...> 2011/10/26

Dear Koichi SASADA,

[#40395] Re: JIT development for MRI — Carter Cheng <cartercheng@...> 2011/10/26

I noticed that you used context threading in YARV. Do you have some analysis

[#40417] Re: JIT development for MRI — SASADA Koichi <ko1@...> 2011/10/26

Thanks for reference.

[#40423] Re: JIT development for MRI — Carter Cheng <cartercheng@...> 2011/10/26

Thanks Koichi.

[#40412] [ruby-trunk - Bug #5486][Open] rb_stat() doesn’t respect input encoding — Nikolai Weibull <now@...>

15 messages 2011/10/26

[#40462] [ruby-trunk - Bug #5492][Open] MinGW Installation with Ruby 1.9.3rc1 Broken — Charlie Savage <cfis@...>

14 messages 2011/10/27

[#40573] [ruby-trunk - Bug #5530][Open] SEEK_SET malfunctions when used with 'append' File.open mode — "Joshua J. Drake" <ruby-lang.jdrake@...>

17 messages 2011/10/31

[#40586] [ruby-trunk - Feature #5531][Open] deep_value for dealing with nested hashes — Kyle Peyton <kylepeyton@...>

19 messages 2011/10/31

[ruby-core:40474] [ruby-trunk - Feature #5494][Open] Proposal: Improved Finalizer Semantics

From: Kurt Stephens <ks.ruby@...>
Date: 2011-10-28 03:20:38 UTC
List: ruby-core #40474
Issue #5494 has been reported by Kurt  Stephens.

----------------------------------------
Feature #5494: Proposal: Improved Finalizer Semantics  
http://redmine.ruby-lang.org/issues/5494

Author: Kurt  Stephens
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 2.0


Proposal: Improved Finalizer Semantics:

ObjectSpace.define_finalizer(object, proc):
** proc should have a single parameter, the object to be finalized, not its id.

When an object with a finalizer is no longer referenced (sweepable):
* The object is reconsidered to be REFERENCED until next GC.
* It's finalizer proc(s) are called, only once, with the object as the sole argument.
* Subsequently, the finalizer procs are removed from the object.
* The object's memory will *NOT* be reclaimed yet, nor will its C free_proc be called, 
  since calling the finalizer proc effectively creates new (temporary) references to the object.
* If the finalizer did *NOT* create any additonal, long-term references to the object, 
  the object's memory and low-level C resources will be reclaimed in the next GC.

This is a simpler protocol: 

* It removes the need for _id2ref in the finalizer procs.
* Prevents other complications: such as GC being reinvoked within a finalizer.
* Finalizers are invoked with the same "urgency" as before.

The downside:

* Objects with finalizers actually live for more than one GC cycle, if they are unreferenced.
* This is probably acceptable since the resources the finalizers "clean-up"
(eg.: file descriptors in a File object) are generally more scarce than the objects holding them.






-- 
http://redmine.ruby-lang.org

In This Thread

Prev Next