[#15348] Expanding arrays in method calls - why the restriction? — mathew <meta@...>
I can do
[#15359] Timeout::Error — Jeremy Thurgood <jerith@...>
Good day,
On Feb 5, 2008, at 06:20 AM, Jeremy Thurgood wrote:
Eric Hodel wrote:
Hi,
Nobuyoshi Nakada wrote:
Hi,
Nobuyoshi Nakada wrote:
Hi,
Nobuyoshi Nakada wrote:
Joel VanderWerf wrote:
Jeremy Thurgood wrote:
Joel VanderWerf wrote:
Jeremy Thurgood wrote:
Hi,
Jeremy Thurgood wrote:
Jim Hranicky wrote:
Jeremy Thurgood wrote:
Charles Oliver Nutter wrote:
On Thu, 7 Feb 2008 09:37:57 +0900, Kurt Stephens <ks@kurtstephens.com> wrote:
[#15360] reopen: can't change access mode from "w+" to "w"? — Sam Ruby <rubys@...>
I ran 'rake test' on test/spec [1], using
Hi,
In article <20080206043831.7F10DE067F@mail.bc9.jp>,
Hi,
Yukihiro Matsumoto wrote:
In article <47AAE922.5020804@intertwingly.net>,
[#15375] weird behavior of belongs_to referencing a model with set_table_name : a bug? — "Yuri Leikind" <yuri.leikind@...>
Hello all,
[#15381] gem versioning patch doesn't seem to have been applied to HEAD — Dave Thomas <dave@...>
A while back, I believe that Rich Kilmer created a patch to gems in
[#15383] Have the rules for source file encoding changed? — Dave Thomas <dave@...>
Does the -E command line option no longer set source file encoding?
Ni,
[#15389] STDIN encoding differs from default source file encoding — Dave Thomas <dave@...>
This seems strange:
Dave Thomas wrote:
NARUSE, Yui wrote:
Hi,
Hi,
Hi,
Hi,
Hi,
[#15399] Non-blocking SSL handshake — "Tony Arcieri" <tony@...>
Hello. I'm attempting to use SSL within my Fiber-based Actor framework (
[#15400] string[0..-1] no longer uses copy on write — Daniel DeLorme <dan-ml@...42.com>
As the subject states, in 1.8 string[0..-1] used copy on write but in
[#15429] rdoc/irb incompatibilities? — "Chad Woolley" <thewoolleyman@...>
Hello,
On Feb 8, 2008, at 03:50 AM, Chad Woolley wrote:
[#15445] IRHG -- Dumping T-Nodes — Charles Thornton <ceo@...>
OK - Here is the problem
[#15464] Possibly a timeout related problem — Dave Thomas <dave@...>
Setting up a sleep seems to interfere with signal handlers. The
[#15465] Synced IO seems not to be thread-safe — Dave Thomas <dave@...>
Take the following code:
[#15475] where's a complete list of assignment shortcuts? += &= %= etc. — Phlip <phlip2005@...>
Ruby Core:
[#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
Hi,
On Feb 11, 2008 11:51 AM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
[#15496] Build failures - Revision 15428 — Sam Ruby <rubys@...>
This change caused many build failures for me.
[#15528] Test::Unit maintainer — Kouhei Sutou <kou@...>
Hi Nathaniel, Ryan,
<snip>
Hi Ryan,
Kouhei Sutou wrote:
[#15534] An Masgn of 1 — "Yehuda Katz" <wycats@...>
There's a weird case in Ruby that produces an masgn of a single argument,
[#15539] IRHG - Slow Child Working? — Charles Thornton <ceo@...>
For the life of me ,
[#15551] Proc#curry — ts <decoux@...>
ts wrote:
Hi,
Hi,
Yukihiro Matsumoto wrote:
[#15585] Ruby M17N meeting summary — Martin Duerst <duerst@...>
This is a rough translation of the Japanese meeting summary
On Feb 18, 2008, at 4:33 AM, Martin Duerst wrote:
Martin Duerst wrote:
On 19/02/2008, Gonzalo Garramu単o <ggarra@advancedsl.com.ar> wrote:
[#15589] Different stacktraces in 1.8 and 1.9 — "Vladimir Sizikov" <vsizikov@...>
Hi,
[#15596] possible bug in regexp lexing — Ryan Davis <ryand-ruby@...>
current:
In article <96106826-DFF4-4BFC-9938-3CB54F28F9F1@zenspider.com>,
In article <87wsp177pg.fsf@fsij.org>,
Hi,
In article <20080220125943.78CB3E0297@mail.bc9.jp>,
[#15610] — "David A. Black" <dblack@...>
Hi --
[#15630] embedding ruby | marking and sweeping wrapped structs — Matthew Metnetsky <met@...>
All,
[#15637] Options for String#encode — Martin Duerst <duerst@...>
I just commited a very first implementation of using a hash for
[#15656] defining a method with attached data — Paul Brannan <pbrannan@...>
For various reasons, I need to be able to attached some piece of data to
Attached is a patch to add this feature directly into YARV without a
On Tue, Feb 26, 2008 at 12:54:13AM +0900, Paul Brannan wrote:
[#15667] Gems running aground on multibyte char — "David A. Black" <dblack@...>
Hi --
Hi,
On Wed, Feb 27, 2008 at 1:03 AM, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
Hi,
On Feb 27, 2008, at 18:27 PM, Nobuyoshi Nakada wrote:
[#15672] File.flock in ruby 1.9.0 — llin <cheempz@...>
Hello,
>>>>> "l" == llin <cheempz@gmail.com> writes:
[#15675] Ruby does not support mkfifo — Hongli Lai <hongli@...99.net>
Today I needed to call mkfifo() and found out that Ruby does not support
[#15678] Re: [ANN] MacRuby — "Rick DeNatale" <rick.denatale@...>
On 2/27/08, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:
On Thu, Feb 28, 2008 at 6:33 AM, Rick DeNatale <rick.denatale@gmail.com> wrote:
Hi,
On Thu, Feb 28, 2008 at 1:51 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
Re: An Masgn of 1
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