Just for posterity, it should be noted that in this particular example
(and several others from itertools), you don't even need generators;
internal iterators work just fine...
def izip(*enums)
(enums[0].length).times { | i |
elems = enums.map { | enum |
enum[i]
}
yield elems
}
end
izip([1,2,3], [4,5,6], [7,8,9]) { | elem |
p elem
}
Of course, you have to be wary about gotchas regarding the elements
being iterable and so forth; just thought it was worthy of mention
that this is possible with the built-in iteration construct, without
resorting to external iterators.
Regards,
Jordan
···
On Nov 28, 10:53 am, "Just Another Victim of the Ambient Morality" <ihates...@hotmail.com> wrote:
"MonkeeSage" <MonkeeS...@gmail.com> wrote in message
news:4f89dee4-b922-49ef-889f-e281e7ad0e8c@j44g2000hsj.googlegroups.com...
> On Nov 28, 9:19 am, MonkeeSage <MonkeeS...@gmail.com> wrote:
>> ========
>> require 'generator'
>> module Enumerable
>> def izip(*enumerables)
>> enumerables = [self] + enumerables
>> generators= enumerables.map { | enum |
>> Generator.new(enum)
>> }
>> whilegenerators[0].next?
>> result =generators.map { | gen |
>> gen.next
>> }
>> yield result
>> end
>> end
>> end
>> [1,2,3].izip([4,5,6]) { | x, y |
>> puts x, y
>> }
>> ========
>> NB. generator.rb says thatgeneratorsare slow in 1.8.
>> Regards,
>> Jordan
> Ps. The SyncEnumerator class from generator does the same thing as
> izip:
> SyncEnumerator.new([1,2,3], [4,5,6]).each { | x, y |
> puts x, y
> }
Thank you, MonkeeSage, this is exactly what I'm looking for!
It's interesting thatgeneratorsare slow enough to warn users about its
lack of speed! Do you know if it would be any faster implemented with
continuations? I'm surprised it's so slow considering Ruby employs green
threads...
"MonkeeSage" <MonkeeSage@gmail.com> wrote in message
news:d0ee96af-656e-4dd8-8a17-bcf46e4ff69a@e67g2000hsc.googlegroups.com...
···
On Nov 28, 10:53 am, "Just Another Victim of the Ambient Morality" > <ihates...@hotmail.com> wrote:
"MonkeeSage" <MonkeeS...@gmail.com> wrote in message
> Ps. The SyncEnumerator class from generator does the same thing as
> izip:
> SyncEnumerator.new([1,2,3], [4,5,6]).each { | x, y |
> puts x, y
> }
Thank you, MonkeeSage, this is exactly what I'm looking for!
It's interesting that generators are slow enough to warn users about
its
lack of speed! Do you know if it would be any faster implemented with
continuations? I'm surprised it's so slow considering Ruby employs green
threads...
Other way around. 
The continuation version is slow. The threaded
version is fast.
Ah, that's good to hear! I was confused there. It looks like, as long
as we have these green threads, we won't really need continuations.
This is starting to get off topic but, if you happen to know, if Ruby is
moving towards native threads, will we keep green threads around? They're
useful things, even with native threads available...
I downloaded the precompiled versions of 1.0.2 and 1.1b1 and both
displayed the same behavior. I'll submit a bug report.
Regards,
Jordan
···
On Nov 28, 3:22 pm, Charles Oliver Nutter <charles.nut...@sun.com> wrote:
MonkeeSage wrote:
> On Nov 28, 9:41 am, Charles Oliver Nutter <charles.nut...@sun.com> > > wrote:
>> MonkeeSage wrote:
>>> You actually need a generator, which can be implemented with
>>> continuations, but doesn't have to be (in 1.9 the generators are
>>> implemented with threads -- have a look at generator.rb in 1.8 and 1.9
>>> to see the differences). Using generators, you can implement izip (and
>>> all of itertools if you'd like, though most of it already has
>>> equivalent ruby solutions). Here is a pretty close translation of the
>>> python given in the itertools docs:
>> Ruby 1.9 also moves continuations out of core, but provides a form of
>> bounded continuations (coroutines) that's possible to implement in JRuby:
>> require 'fiber'
>> f = Fiber.new { a = 1; while true; Fiber.yield a; a += 1; end }
>> 5.times { puts f.resume }
>> $ jruby -J-Djruby.compat.version=ruby1_9 fiber_example.rb
>> 1
>> 2
>> 3
>> 4
>> 5
>> Under JRuby, it's using a native thread per live Fiber, so it's heavier
>> than in Ruby 1.9 which uses green threads. However they'll actually run
>> in parallel on JRuby, so that's a benefit. JRuby also supports a thread
>> pool in 1.1 that helps blunt the cost of spinning up native threads.
>> - Charlie
> I just tried the above izip function in jruby, but it only gave me two
> iterations...
Could be a bug in generator; could you try it on a more recent release
(like 1.0.2 or 1.1b1) and report it if it's actually a problem?
http://jira.codehaus.org/browse/JRUBY
- Charlie
Bug #1635 [ http://jira.codehaus.org/browse/JRUBY-1635 ]
···
On Nov 28, 4:35 pm, MonkeeSage <MonkeeS...@gmail.com> wrote:
On Nov 28, 3:22 pm, Charles Oliver Nutter <charles.nut...@sun.com> > wrote:
> MonkeeSage wrote:
> > On Nov 28, 9:41 am, Charles Oliver Nutter <charles.nut...@sun.com> > > > wrote:
> >> MonkeeSage wrote:
> >>> You actually need a generator, which can be implemented with
> >>> continuations, but doesn't have to be (in 1.9 the generators are
> >>> implemented with threads -- have a look at generator.rb in 1.8 and 1.9
> >>> to see the differences). Using generators, you can implement izip (and
> >>> all of itertools if you'd like, though most of it already has
> >>> equivalent ruby solutions). Here is a pretty close translation of the
> >>> python given in the itertools docs:
> >> Ruby 1.9 also moves continuations out of core, but provides a form of
> >> bounded continuations (coroutines) that's possible to implement in JRuby:
> >> require 'fiber'
> >> f = Fiber.new { a = 1; while true; Fiber.yield a; a += 1; end }
> >> 5.times { puts f.resume }
> >> $ jruby -J-Djruby.compat.version=ruby1_9 fiber_example.rb
> >> 1
> >> 2
> >> 3
> >> 4
> >> 5
> >> Under JRuby, it's using a native thread per live Fiber, so it's heavier
> >> than in Ruby 1.9 which uses green threads. However they'll actually run
> >> in parallel on JRuby, so that's a benefit. JRuby also supports a thread
> >> pool in 1.1 that helps blunt the cost of spinning up native threads.
> >> - Charlie
> > I just tried the above izip function in jruby, but it only gave me two
> > iterations...
> Could be a bug in generator; could you try it on a more recent release
> (like 1.0.2 or 1.1b1) and report it if it's actually a problem?
>http://jira.codehaus.org/browse/JRUBY
> - Charlie
I downloaded the precompiled versions of 1.0.2 and 1.1b1 and both
displayed the same behavior. I'll submit a bug report.
Regards,
Jordan
MonkeeSage wrote:
Bug #1635 [ http://jira.codehaus.org/browse/JRUBY-1635 ]
Cool, thanks. Now if you're really ambitious, maybe you can fix it 
- Charlie
Looks like somebody already beat me to it (with bells on!) [
http://jira.codehaus.org/browse/JRUBY-1635 ]; not that I'd have been
any help anyway.
Regards,
Jordan
···
On Nov 29, 1:05 am, Charles Oliver Nutter <charles.nut...@sun.com> wrote:
MonkeeSage wrote:
> Bug #1635 [http://jira.codehaus.org/browse/JRUBY-1635\]
Cool, thanks. Now if you're really ambitious, maybe you can fix it
- Charlie