[#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

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

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

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: 1.8.6 gc.c thoughts

From: "Roger Pack" <rogerpack2005@...>
Date: 2008-01-10 23:03:09 UTC
List: ruby-core #14967
It might be worth encouraging someone to implement a new Ruby GC as
part of a google summer of code project.
Cheers!
-Roger

On Oct 30, 2007 9:11 AM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> Hi,
>
> In message "Re: 1.8.6 gc.c thoughts"
>     on Wed, 31 Oct 2007 00:30:25 +0900, "Roger Pack" <rogerpack2005@gmail.com> writes:
>
> |Anyway so what happens in today's implementations is that number 1 is called
> |often (I believe) preventing number 2 from ever even springing, as it resets
> |the current count of malloc'ed bytes.  It's like garbage_collect is trying
> |to serve 2 masters.  I see this as curious as it basically disallows
> |GC_MALLOC_LIMIT from being reached, which is not what you would expect.
> |To fix (should it be considered a problem) I would suggest that if you run
> |out of heap slots available you call garbage collect AND increase the heap
> |(so that next time you won't run out).  Maybe don't increase the heap stack
> |increase size by as much as 1.8 as it now is--maybe less :)
> |
> |Thoughts?
>
> It might be true.  The GC behavior is very difficult to expect in
> vitro.  I'd like to see the benchmark from real applications.  My
> guess is that malloc_increase has little control over GC behavior.
>
> |On another point, I have a question on this line of code, run at the end of
> |garbage collection:
> |if (malloc_increase > malloc_limit) {
> |    malloc_limit += (malloc_increase - malloc_limit) * (double)live / (live
> |+ freed); // this line
> |    if (malloc_limit < GC_MALLOC_LIMIT) malloc_limit = GC_MALLOC_LIMIT;
> | }
> |
> |I haven't checked this, but it seems to me that It seems to me that
> |(malloc_increase - malloc_limit) will always be a very small number (?)
> |which may not be what was expected.  I could be wrong.  In reality I think
> |what it should best do is
> |malloc_limit = GC_MALLOC_LIMIT *
> |percent_of_recent_allocated_memory_that_was_freed // allow the malloc_limit
> |to change dynamically, maybe with a fixed maximum.  I could code it up.
>
> I have to admit that I don't remember why I have chosen the equation.
> The benchmark may show us better equation.
>
>                                                         matz.
>
>



-- 
-Roger Pack
For God hath not given us the spirit of fear; but of power, and of
love, and of a sound mind" -- 2 Timothy 1:7

In This Thread