[#15359] Timeout::Error — Jeremy Thurgood <jerith@...>

Good day,

41 messages 2008/02/05
[#15366] Re: Timeout::Error — Eric Hodel <drbrain@...7.net> 2008/02/06

On Feb 5, 2008, at 06:20 AM, Jeremy Thurgood wrote:

[#15370] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/06

Eric Hodel wrote:

[#15373] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/06

Hi,

[#15374] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/06

Nobuyoshi Nakada wrote:

[#15412] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/07

Hi,

[#15413] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/07

Nobuyoshi Nakada wrote:

[#15414] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/07

Hi,

[#15360] reopen: can't change access mode from "w+" to "w"? — Sam Ruby <rubys@...>

I ran 'rake test' on test/spec [1], using

16 messages 2008/02/05
[#15369] Re: reopen: can't change access mode from "w+" to "w"? — Nobuyoshi Nakada <nobu@...> 2008/02/06

Hi,

[#15389] STDIN encoding differs from default source file encoding — Dave Thomas <dave@...>

This seems strange:

21 messages 2008/02/06
[#15392] Re: STDIN encoding differs from default source file encoding — Yukihiro Matsumoto <matz@...> 2008/02/06

Hi,

[#15481] very bad character performance on ruby1.9 — "Eric Mahurin" <eric.mahurin@...>

I'd like to bring up the issue of how characters are represented in

16 messages 2008/02/10

[#15528] Test::Unit maintainer — Kouhei Sutou <kou@...>

Hi Nathaniel, Ryan,

22 messages 2008/02/13

[#15551] Proc#curry — ts <decoux@...>

21 messages 2008/02/14
[#15557] Re: [1.9] Proc#curry — David Flanagan <david@...> 2008/02/15

ts wrote:

[#15558] Re: [1.9] Proc#curry — Yukihiro Matsumoto <matz@...> 2008/02/15

Hi,

[#15560] Re: Proc#curry — Trans <transfire@...> 2008/02/15

[#15585] Ruby M17N meeting summary — Martin Duerst <duerst@...>

This is a rough translation of the Japanese meeting summary

19 messages 2008/02/18

[#15596] possible bug in regexp lexing — Ryan Davis <ryand-ruby@...>

current:

17 messages 2008/02/19

[#15678] Re: [ANN] MacRuby — "Rick DeNatale" <rick.denatale@...>

On 2/27/08, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:

18 messages 2008/02/28
[#15679] Re: [ANN] MacRuby — "Laurent Sansonetti" <laurent.sansonetti@...> 2008/02/28

On Thu, Feb 28, 2008 at 6:33 AM, Rick DeNatale <rick.denatale@gmail.com> wrote:

[#15680] Re: [ANN] MacRuby — Yukihiro Matsumoto <matz@...> 2008/02/28

Hi,

[#15683] Re: [ANN] MacRuby — "Laurent Sansonetti" <laurent.sansonetti@...> 2008/02/28

On Thu, Feb 28, 2008 at 1:51 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Re: An Masgn of 1

From: Daniel DeLorme <dan-ml@...42.com>
Date: 2008-02-14 01:27:29 UTC
List: ruby-core #15536
Yehuda Katz wrote:
> It seems like this is happening because the |x,| syntax is getting 
> errantly parsed as an masgn, and treated as such as a block, but somehow 
> treated as an lasgn in the standlone lambda case. Am I misunderstanding 
> something?

I was also confused by this behavior so I made a table of the 
differences between blocks and lambdas:

arr = []
arr << "  lambda{|x,y|x}"
arr << "  lambda{|x,| x}"
arr << "  lambda{|x|  x}"
arr << "Proc.new{|x,y|x}"
arr << "Proc.new{|x,| x}"
arr << "Proc.new{|x|  x}"
arr.each do |label|
   fn = eval(label)
   (1..2).each do |nb_args|
     args = (1..nb_args).to_a
     res = fn.call(args) rescue :err
     puts "%s.call( %-6s ) -> %s" % [label, args.inspect, res.inspect]
     res = fn.call(*args) rescue :err
     puts "%s.call(*%-6s ) -> %s" % [label, args.inspect, res.inspect]
   end
end

   lambda{|x,y|x}.call( [1]    ) -> :err
   lambda{|x,y|x}.call(*[1]    ) -> :err
   lambda{|x,y|x}.call( [1, 2] ) -> :err
   lambda{|x,y|x}.call(*[1, 2] ) -> 1
   lambda{|x,| x}.call( [1]    ) -> [1]
   lambda{|x,| x}.call(*[1]    ) -> 1
   lambda{|x,| x}.call( [1, 2] ) -> [1, 2]
   lambda{|x,| x}.call(*[1, 2] ) -> :err
   lambda{|x|  x}.call( [1]    ) -> [1]
   lambda{|x|  x}.call(*[1]    ) -> 1
   lambda{|x|  x}.call( [1, 2] ) -> [1, 2]
   lambda{|x|  x}.call(*[1, 2] ) -> [1, 2] + warning (ruby1.8)
                                 -> :err (ruby1.9)
Proc.new{|x,y|x}.call( [1]    ) -> 1
Proc.new{|x,y|x}.call(*[1]    ) -> 1
Proc.new{|x,y|x}.call( [1, 2] ) -> 1
Proc.new{|x,y|x}.call(*[1, 2] ) -> 1
Proc.new{|x,| x}.call( [1]    ) -> 1
Proc.new{|x,| x}.call(*[1]    ) -> 1
Proc.new{|x,| x}.call( [1, 2] ) -> 1
Proc.new{|x,| x}.call(*[1, 2] ) -> 1
Proc.new{|x|  x}.call( [1]    ) -> [1]
Proc.new{|x|  x}.call(*[1]    ) -> 1
Proc.new{|x|  x}.call( [1, 2] ) -> [1, 2]
Proc.new{|x|  x}.call(*[1, 2] ) -> [1, 2] + warning (ruby1.8)
                                 -> 1 (ruby1.9)

So I think it has to do with blocks using multiple-assignment semantics 
and lambdas using function-arguments semantics. Since there is no such 
thing as "def foo(x,)" then "lambda{|x,|" is considered as the 
equivalent of "def foo(x)". Do I have it wrong?

--
Daniel

In This Thread