[#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-04 14:22:19 UTC
List: ruby-core #14764
On Jan 4, 2008, at 12:11 AM, Martin Duerst wrote:

> I think the two changes have to be looked at separately.

Sounds good to me.  I posted them here with the hope of inspiring  
discussion around them.  Perhaps if enough of us reach agreement, Matz  
will take pity on us zip() fans.  :)

> At 07:05 08/01/04, James Gray wrote:
>> The community has been building a Ruby 1.9 compatibility tip list on
>> my blog.  While most of the changes are good, a pattern is emerging:
>> Enumerable#zip was damaged in the translation.  The short story is:
>>
>> * Making Enumerable#zip() return and Enumerable::Enumerator when
>> called without a block hid a very useful return value that was  
>> already
>> in place.  Now we typically need `enum.zip(...).to_a` to get the
>> expected results.
>
> My recollection may be faulty, and I may not be the typical case,
> but I usually have been using zip immediately followed by some
> additional operation, which should still work in 1.9, rather
> than to produce an explicit array.

Well, Array is a superset of Enumerable, right?  So the operations you  
can follow up with are increased by an Array return value and you  
don't lose access to any of the iterators.

>> * Beyond being less attractive, Enumerable::Enumerator is quite a bit
>> slower.  It looks like `enum.zip(...).to_a` in 1.9 is about 12 times
>> slower than a straight `enum.zip(...)` in Ruby 1.8.
>
> That looks bad. But have you looked at how much slower or
> faster things get when zip is used not just to create an array?

I hadn't before, no.  Let's check though:

$ ruby -v speed_test.rb
ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin9.1.0]
Rehearsal -------------------------------------------------
zip().to_a():   8.040000   0.020000   8.060000 (  8.066183)
zip() { }:      8.770000   0.020000   8.790000 (  8.789457)
--------------------------------------- total: 16.850000sec

                     user     system      total        real
zip().to_a():   8.100000   0.010000   8.110000 (  8.112016)
zip() { }:      8.820000   0.010000   8.830000 (  8.852391)
$ ruby_dev -v speed_test.rb
ruby 1.9.0 (2007-12-25 revision 14709) [i686-darwin9.1.0]
Rehearsal -------------------------------------------------
zip().to_a(): 100.870000   9.620000 110.490000 (110.607631)
zip() { }:     82.510000   9.410000  91.920000 ( 92.208807)
-------------------------------------- total: 202.410000sec

                     user     system      total        real
zip().to_a():  99.890000   9.940000 109.830000 (109.915261)
zip() { }:     81.550000   9.470000  91.020000 ( 90.950279)
$ cat speed_test.rb
#!/usr/bin/env ruby -wKU

require "benchmark"

DATA = Array.new(25) { rand }

TESTS = 1_000_000
Benchmark.bmbm do |results|
   results.report("zip().to_a():") { TESTS.times  
{ DATA.zip(DATA).to_a } }
   results.report("zip() { }:")    { TESTS.times { DATA.zip(DATA)  
{ } } }
end

__END__

Good call.  It seems that zip() performance on the whole has tanked.

James Edward Gray II


In This Thread