[#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: block locals & Ruby2 [was Re: open-uri patch, added progress_proc hook]
On Mon, Nov 24, 2003 at 06:34:49AM +0900, T. Onoma wrote:
> On Sunday 23 November 2003 10:04 pm, Mauricio Fern疣dez wrote:
> > On Mon, Nov 24, 2003 at 05:32:09AM +0900, Mathieu Bouchard wrote:
> > > I think the actual problem would be more with code that does things like
> > > this:
> > >
> > > def foo(n)
> > > (0...n).map {
> > > proc {a=0; proc{a+=1;a}}[]
> > > }
> > > end
> >
> > This would work with the new rules (and the current ones), I believe:
> >
> > def foo(n)
> > (0...n).map { proc {|a| proc{ a += 1; a } }[0] }
> > end
> >
> actually using
>
> foo(3).each { |q| p q.call }
>
> they both produce
>
> 1
> 1
> 1
This is the behavior matju wanted (n independent counters). It works in
1.x because the block argument is local unless it was already in use in
the outer scope, and will in 2.0 because block args will *always* be
local.
> but in both, if you add a=0:
>
> def foo(n)
> a = 0
> (0...n).map { proc {|a| proc{ a += 1; a } }[0] }
> end
>
> then
>
> 1
> 2
> 3
a exists in the method scope, so it's not block local in this case (for
1.x)
> So you tell me how it changes in new system, cause I don't know. i'm
> guessing the first won't be 1 1 1 anymore. but who am i to say? i find the
> examples confusing enough in themselves :).
In 2.0, you'd get 1 1 1 in the second case, and a warning ("shadowing is evil" or such :-),
if I understood correctly matz's latest statements on the matter.
Note that this could also be written as
def foo(n); (0..n).map{ local{|a| a = 0; proc{ a+= 1; a} } }
with
def local
yield
end
I'd really like to try :=,
def foo(n); (0..n).map{ a:= 0; proc{ a+=1; a } }
but it seems that matz has definitely abandoned the idea :-(
--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
<miguel> any new sendmail hole I have to fix before going on vacations?
-- Seen on #Linux