[#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: Enumerable#zip Needs Love

From: James Gray <james@...>
Date: 2008-01-08 04:50:09 UTC
List: ruby-core #14836
On Jan 7, 2008, at 8:07 PM, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: Enumerable#zip Needs Love"
>    on Tue, 8 Jan 2008 07:15:56 +0900, James Gray <james@grayproductions.net 
> > writes:
>
> |Matz, at least this much of my proposal seems uncontested.  Can you
> |tell us the reason for the new behavior?
>
> The rationales behind the changes were:
>
>  (a) stopping at the shortest
>
>      adopting the behavior from python where I took the idea of zip
>      method.  I saw some use cases that the shortest stop may
>      helpful.  Besides that it's much simpler to implement.  But
>      there's still room for you to persuade me.

Well, I don't want to sound like a broken record here, but the way I  
see it is:

* With the 1.8 system, we easily can have it both ways.  We can find  
the bigger group and lead with that to save all data, or find the  
shorter group and lead with it to trim data.
* Under 1.9 we lose data by default and it's challenging to save it  
since all groups must be expanded to the same length.

>   (b) return value
>
>      My estimation was that zip was mostly used for iteration, and
>      there's little need to get an array from zip, so that it is more
>      convenient to keep consistency with other enumerator returning
>      methods in Enumerable.

I can see your point here and Martin seemed to agree with you, but:

* An Array is a super set of Enumerable, so we gain more options  
without losing anything.
* It seems to break a fair bit of 1.8 code.  I can name three  
libraries affected by the change off the top of my head.
* Performance seems like another good reason to do this, since you  
said it would speed things up.

I promise I'm done pleading my case now.  ;)

> But use-case is more important than theoretical rationale.  There are
> several options we can take:
>
>  (3) hardest way - (2) + honoring length of the receiver
>
>      I am not sure how to implement it yet.

I don't understand.  We had this in 1.8.  Can we not go back to that  
code?

James Edward Gray II


In This Thread