[#14696] Inconsistency in rescuability of "return" — Charles Oliver Nutter <charles.nutter@...>

Why can you not rescue return, break, etc when they are within

21 messages 2008/01/02
[#14699] Re: Inconsistency in rescuability of "return" — Gary Wright <gwtmp01@...> 2008/01/02

[#14738] Enumerable#zip Needs Love — James Gray <james@...>

The community has been building a Ruby 1.9 compatibility tip list on

15 messages 2008/01/03
[#14755] Re: Enumerable#zip Needs Love — Martin Duerst <duerst@...> 2008/01/04

Hello James,

[#14772] Manual Memory Management — Pramukta Kumar <prak@...>

I was thinking it would be nice to be able to free large objects at

36 messages 2008/01/04
[#14788] Re: Manual Memory Management — Marcin Raczkowski <mailing.mr@...> 2008/01/05

I would only like to add that RMgick for example provides free method to

[#14824] Re: Manual Memory Management — MenTaLguY <mental@...> 2008/01/07

On Sat, 5 Jan 2008 15:49:30 +0900, Marcin Raczkowski <mailing.mr@gmail.com> wrote:

[#14825] Re: Manual Memory Management — "Evan Weaver" <evan@...> 2008/01/07

Python supports 'del reference', which decrements the reference

[#14838] Re: Manual Memory Management — Marcin Raczkowski <mailing.mr@...> 2008/01/08

Evan Weaver wrote:

[#14911] Draft of some pages about encoding in Ruby 1.9 — Dave Thomas <dave@...>

Folks:

24 messages 2008/01/10

[#14976] nil encoding as synonym for binary encoding — David Flanagan <david@...>

The following just appeared in the ChangeLog

37 messages 2008/01/11
[#14977] Re: nil encoding as synonym for binary encoding — Yukihiro Matsumoto <matz@...> 2008/01/11

Hi,

[#14978] Re: nil encoding as synonym for binary encoding — Dave Thomas <dave@...> 2008/01/11

[#14979] Re: nil encoding as synonym for binary encoding — David Flanagan <david@...> 2008/01/11

Dave Thomas wrote:

[#14993] Re: nil encoding as synonym for binary encoding — Dave Thomas <dave@...> 2008/01/11

[#14980] Re: nil encoding as synonym for binary encoding — Gary Wright <gwtmp01@...> 2008/01/11

[#14981] Re: nil encoding as synonym for binary encoding — Yukihiro Matsumoto <matz@...> 2008/01/11

Hi,

[#14995] Re: nil encoding as synonym for binary encoding — David Flanagan <david@...> 2008/01/11

Yukihiro Matsumoto writes:

[#15050] how to "borrow" the RDoc::RubyParser and HTMLGenerator — Phlip <phlip2005@...>

Core Rubies:

17 messages 2008/01/13
[#15060] Re: how to "borrow" the RDoc::RubyParser and HTMLGenerator — Eric Hodel <drbrain@...7.net> 2008/01/14

On Jan 13, 2008, at 08:54 AM, Phlip wrote:

[#15062] Re: how to "borrow" the RDoc::RubyParser and HTMLGenerator — Phlip <phlip2005@...> 2008/01/14

Eric Hodel wrote:

[#15073] Re: how to "borrow" the RDoc::RubyParser and HTMLGenerator — Eric Hodel <drbrain@...7.net> 2008/01/14

On Jan 13, 2008, at 20:35 PM, Phlip wrote:

[#15185] Friendlier methods to compare two Time objects — "Jim Cropcho" <jim.cropcho@...>

Hello,

10 messages 2008/01/22

[#15194] Can large scale projects be successful implemented around a dynamic programming language? — Jordi <mumismo@...>

A good article I have found (may have been linked by slashdot, don't know)

8 messages 2008/01/24

[#15248] Symbol#empty? ? — "David A. Black" <dblack@...>

Hi --

24 messages 2008/01/28
[#15250] Re: Symbol#empty? ? — Yukihiro Matsumoto <matz@...> 2008/01/28

Hi,

Re: Manual Memory Management

From: Kurt Stephens <ks@...>
Date: 2008-01-04 19:27:48 UTC
List: ruby-core #14775
James Tucker wrote:
> 
> On 4 Jan 2008, at 14:41, Rick DeNatale wrote:
> 
>> On Jan 4, 2008 1:25 PM, Pramukta Kumar <prak@fortiusone.com> wrote:
>>> I was thinking it would be nice to be able to free large objects at
>>> will without making ruby go through the full garbage collection
>>> process each time.  Basically to have the ability to optionally manage
>>> your own memory (kindof).  I tried adding this singleton method to the
>>> GC module as a test:
>>>
>>> in gc.c:
>>> static VALUE rb_obj_free(VALUE self, VALUE obj) {
>>>        obj_free(obj);
>>>        rb_gc_force_recycle(obj);
>>>        return Qnil;
>>> }
>>>
>>> and exposing it as GC.free(obj) in the init function
>>>
>>> It seems to actually work (except when you try and free a nil
>>> object).  I'm no expert on ruby internals though so I'm worried that
>>> i'm actually creating a severe problem by doing this.  Does anyone
>>> here know?  If this (or something similar) does work it seems like a
>>> really cool feature to add.  I've attached a patchfile.
>>
>> On the surface, this seems like a horrible idea.
>>
>> You're basically yanking the object out from under any references to
>> it that there might be, creating, in effect dangling pointers.
>>
>> The whole point of a GC, it seems to me, is to avoid this situation by
>> ensuring that objects are not recycled as long as they can be
>> referenced.
> 
> Whilst it might be somewhat an anti-pattern to Garbage Collection and
> automatic memory management in general, assigning all references to NIL
> (not nil)...
> 
> Also, aren't we about diversity, not generality of specifics? Or is it
> simply too dangerous to allow people to do this?
> 
> In a very very large object space, there might be some limited sense to
> this, no?
> 
> Of course, it will always always leave at least one dangling reference -
> that is, the one that called it.
> 
> There are also strong arguments that say it's never faster to do this,
> but speed is a separate issue to latency and long running operation
> start and stop times...
> 
>> -- 
>> Rick DeNatale
>>
>> My blog on Ruby
>> http://talklikeaduck.denhaven2.com/
>>
> 
> 

It's likely that the address of explicitly freed objects will be reused,
which could be confusing, if not fatal (SEGFAULT), to referrer to the
old object at the address.  Might be better to spend time on making
Ruby's collector generational.

Kurt Stephens
http://kurtstephens.com


In This Thread