[#1651] A min/max bug? — "Christoph" <chr_news@...>
Hi,
[#1690] Re: open-uri patch, added progress_proc hook — Elliott Hughes <ehughes@...>
In effect. I mean that if a method's interface is getting too complicated,
In article <AD4480A509455343AEFACCC231BA850F17C358@ukexchange>,
On Sun, Nov 16, 2003 at 07:51:42PM +0900, Tanaka Akira wrote:
[#1699] FileUtils bug and fix — Chad Fowler <chad@...>
As posted in ruby-talk:85349, I believe there is a bug in FileUtils.cp's
[#1706] gc_sweep in Ruby 1.8 — Richard Kilmer <rich@...>
I posted about this before but Matz wanted me to post more detail.
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
[#1711] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...>
Tanaka Akira:
On Sunday 23 November 2003 07:12 pm, Mathieu Bouchard wrote:
On Sunday 23 November 2003 08:26 pm, Mathieu Bouchard wrote:
On Sunday 23 November 2003 09:32 pm, Mathieu Bouchard wrote:
On Sunday 23 November 2003 11:13 pm, Mathieu Bouchard wrote:
On Mon, Nov 24, 2003 at 05:32:09AM +0900, Mathieu Bouchard wrote:
[#1716] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...>
Tanaka Akira:
[#1718] Re: open-uri patch, added progress_proc hook — Elliott Hughes <ehughes@...>
In article <AD4480A509455343AEFACCC231BA850F17C434@ukexchange>,
On Saturday 22 November 2003 04:34 pm, Tanaka Akira wrote:
In article <200311221024.05642.transami@runbox.com>,
On Sunday 23 November 2003 02:24 am, Tanaka Akira wrote:
In article <200311230325.21687.transami@runbox.com>,
On Sunday 23 November 2003 03:10 pm, Tanaka Akira wrote:
In article <200311230648.41003.transami@runbox.com>,
On Monday 24 November 2003 03:19, Tanaka Akira wrote:
Sean E Russell [mailto:ser@germane-software.com] wrote:
[#1753] gc_sweep under 1.8 ... not syck.so — Richard Kilmer <rich@...>
We still encountered a gc_sweep in our use of Ruby 1.8 on Linux (v8).
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
Yes, there are several (Ruby) threads working during this gc_sweep.
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
of course this effects 300 machines ;-)
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
The saga continues:
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
There is a discussion (found by chad fowler) on ruby-dev (22000)
[#1755] Re: Controlled block variables — Jamis Buck <jgb3@...>
On Mon, 2003-11-24 at 02:04, T. Onoma wrote:
On Monday 24 November 2003 05:22 pm, Jamis Buck wrote:
On Monday 24 November 2003 11:51, T. Onoma wrote:
On Monday 24 November 2003 06:40 pm, Sean E Russell wrote:
On Tue, 25 Nov 2003, T. Onoma wrote:
On Monday 24 November 2003 14:02, T. Onoma wrote:
On Monday 24 November 2003 09:15 pm, Sean E Russell wrote:
[#1799] Syck install on Debian Standard (Ruby 1.6.7) — "T. Onoma" <transami@...>
Hi, I'm having some trouble installing Syck on Debain (woody). I'm not
On Friday 28 November 2003 09:17 am, T. Onoma wrote:
On Fri, Nov 28, 2003 at 05:22:48PM +0900, T. Onoma wrote:
[#1819] Re: configure.in: do not override CCDLDFLAGS, LDFLAGS, XLDFLAGS — Eric Sunshine <sunshine@...>
Hello,
Re: open-uri patch, added progress_proc hook
On Sunday 23 November 2003 08:26 pm, Mathieu Bouchard wrote:
> Actually, looking at http://www.rubygarden.org/ruby?Rite, I can only see a
> change in the opposite direction, block locals, and although I can't
> justify that change either, at least it doesn't have as much of a
> compatibility issue.
>
> What confuses me most in all of this is, why the change towards a flat
> local space isn't included in Matz' list, and why an opposite idea is
> included in Matz' list. I also feel that the item in matz' list is not
> completely clear, and suspect that I don't really understand it.
>
Lets clear this up, b/c i've read that too, and became very confused for a
while. I do not believe that page has a proper explination and makes you
think that the blocks are somehow fully isolated, but they are not. So...
Here is the current behavior:
a = [1,2,3]
i = nil
a.each { |x| i = x + i.to_i }
p "#{i}" # => "6"
The i = nil is required prior to the block in order for i to "persist" in the
outer scope as it passes through the inner scope of the block. Without it the
last statement would produce:
p "#{i}" # => ""
Now the newly proposed behavior would allow us to remove the i = nil.
a = [1,2,3]
a.each { |x| i = x + i.to_i }
p "#{i}" # => "6"
So i exists at both levels.
Basically what is happening is that blocks no longer represent divisions of
scope. Those barriers are now only on def, class, module, and the TOPLEVEL.
So we are loosing a mechinism of inner scoping, albiet a limted one.
This WILL brake code. Consider:
a = [1,2,3]
a.each { |x| i = x + i.to_i }
p "#{i}" # => "6"
a = [1,2,3]
a.each { |x| i = x + i.to_i }
p "#{i}" # => "12" # => Doh! It's not 6 anymore!
If all Matz wants to do is get rid of the "silly" i=nil, so the code looks
cleaner then he should try something like:
a = [1,2,3]
a.each { i |x| i = x + i.to_i }
p "#{i}" # => "6"
See the difference? And no "back" breaking. But maybe he's after something
else. I don't know.
-t0