Ruby-dev summary 25741-25780

Hi all,

This is a summary of ruby-dev ML in these days.

[ruby-dev:25755] I/O operation differs signal handler

  Minero Aoki reported that ruby does not execute pure ruby signal
  handlers while reading from a stream. e.g.

    Signal.trap(:TERM) { puts 'TERM'; exit }
    while true
      p $stdin.gets
    end

  This program does not exit until $stdin.gets returns.
  Pure ruby signal handlers are not executed, because calling ruby
  code from signal handler is dangerous. So we must take following
  steps:

    1. exit signal handler,
    2. interrupt/finish system call,
    3. update ruby's I/O buffer correctly,
    4. then call pure ruby signal handler.

  But difficulties are still lying here:

    * read(2) will never be interrupted by signals because ruby set
      SA_RESTART option (see also sigaction(2)).
    * The return value of read(2) is required to update I/O buffer.
      So we cannot update I/O buffer until system call is finished.

  We need a safe and portable solution for this problem.

[ruby-dev:25780] Proc generation without `proc'

  Nobuyoshi Nakada posted a patch to allow generating Proc object
  without `proc' or `lambda' shortly. e.g.

    x = {|a| p a } # == proc {|a| p a }
    x.call

    x = (do |a| p a end) # == proc do |a| p a end
    x.call

  This experimental patch was incorporated in to CVS HEAD.

-- Minero Aoki
ruby-dev summary index: http://i.loveruby.net/en/ruby-dev-summary.html

Hi --

···

On Sun, 6 Mar 2005, Minero Aoki wrote:

[ruby-dev:25780] Proc generation without `proc'

Nobuyoshi Nakada posted a patch to allow generating Proc object
without `proc' or `lambda' shortly. e.g.

   x = {|a| p a } # == proc {|a| p a }
   x.call

   x = (do |a| p a end) # == proc do |a| p a end
   x.call

This experimental patch was incorporated in to CVS HEAD.

Wouldn't this require empty || for blocks that don't take arguments?
For example:

    x = {|| puts "hello" }

David

--
David A. Black
dblack@wobblini.net

Minero Aoki <aamine@loveruby.net> writes:

[ruby-dev:25780] Proc generation without `proc'

  Nobuyoshi Nakada posted a patch to allow generating Proc object
  without `proc' or `lambda' shortly. e.g.

    x = {|a| p a } # == proc {|a| p a }
    x.call

    x = (do |a| p a end) # == proc do |a| p a end
    x.call

  This experimental patch was incorporated in to CVS HEAD.

Does this mean that foo { |a| ... }, { |b| ... } will work?

···

-- Minero Aoki

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

Hi,

···

In message "Re: ruby-dev summary 25741-25780" on Sun, 6 Mar 2005 20:15:03 +0900, "David A. Black" <dblack@wobblini.net> writes:

Wouldn't this require empty || for blocks that don't take arguments?
For example:

   x = {|| puts "hello" }

Yes.

              matz.

Hi,

···

In message "Re: ruby-dev summary 25741-25780" on Sun, 6 Mar 2005 20:56:08 +0900, Christian Neukirchen <chneukirchen@gmail.com> writes:

Does this mean that foo { |a| ... }, { |b| ... } will work?

No. foo {|a| ...} itself works as a method invocation with a block,
so that above code will be a syntax error. But

  foo({ |a| ... }, { |b| ... })

will do.

              matz.

Hi --

···

On Sun, 6 Mar 2005, Yukihiro Matsumoto wrote:

Hi,

In message "Re: ruby-dev summary 25741-25780" > on Sun, 6 Mar 2005 20:15:03 +0900, "David A. Black" <dblack@wobblini.net> writes:

>Wouldn't this require empty || for blocks that don't take arguments?
>For example:
>
> x = {|| puts "hello" }

Yes.

OK, second question :slight_smile:

Isn't that a little bit awkward-looking? Or am I just being too
sensitive about new forms of significant punctuation in the language?

David

--
David A. Black
dblack@wobblini.net

I like that!

regards,

Brian

···

On Sun, 6 Mar 2005 22:45:55 +0900, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Hi,

In message "Re: ruby-dev summary 25741-25780" > on Sun, 6 Mar 2005 20:56:08 +0900, Christian Neukirchen <chneukirchen@gmail.com> writes:

>Does this mean that foo { |a| ... }, { |b| ... } will work?

No. foo {|a| ...} itself works as a method invocation with a block,
so that above code will be a syntax error. But

  foo({ |a| ... }, { |b| ... })

will do.

                                                        matz.

--
Brian Schröder
http://ruby.brian-schroeder.de/

Hi,

···

On Sun, 6 Mar 2005 22:45:55 +0900, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Hi,

In message "Re: ruby-dev summary 25741-25780" > on Sun, 6 Mar 2005 20:56:08 +0900, Christian Neukirchen <chneukirchen@gmail.com> writes:

>Does this mean that foo { |a| ... }, { |b| ... } will work?

No. foo {|a| ...} itself works as a method invocation with a block,
so that above code will be a syntax error. But

  foo({ |a| ... }, { |b| ... })

will do.

Cool. Ruby won't lose its closures king position to Perl 6 anymore... hehe. :slight_smile:

Nice.

Cheers,
Joao

Hi,

···

In message "Re: ruby-dev summary 25741-25780" on Sun, 6 Mar 2005 20:59:34 +0900, "David A. Black" <dblack@wobblini.net> writes:

Isn't that a little bit awkward-looking? Or am I just being too
sensitive about new forms of significant punctuation in the language?

Maybe, maybe not. It's very subjective matter.

              matz.

Brian Schröder <ruby.brian@gmail.com> writes:

Hi,

>Does this mean that foo { |a| ... }, { |b| ... } will work?

No. foo {|a| ...} itself works as a method invocation with a block,
so that above code will be a syntax error. But

  foo({ |a| ... }, { |b| ... })

will do.

I like that!

It's fine with me.

What about foo { |a| ... } { |b| ... } ? }:slight_smile:

···

On Sun, 6 Mar 2005 22:45:55 +0900, Yukihiro Matsumoto > <matz@ruby-lang.org> wrote:

In message "Re: ruby-dev summary 25741-25780" >> on Sun, 6 Mar 2005 20:56:08 +0900, Christian Neukirchen <chneukirchen@gmail.com> writes:

regards,

Brian

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

* Yukihiro Matsumoto (Mar 06, 2005 14:50):

> Isn't that a little bit awkward-looking? Or am I just being too
> sensitive about new forms of significant punctuation in the
> language?

Maybe, maybe not. It's very subjective matter.

Definitely. I'd write it as

  x = lambda { ... }

if there weren't any arguments. It'd make it much more clear that it
was a thunk and nothing else.

(If there were arguments I'd consider skipping the proc/lamda:

  x = { |a| ... }
),
  nikolai

···

--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Christian Neukirchen wrote:

What about foo { |a| ... } { |b| ... } ? }:slight_smile:

In my opinion, foo{|a|...}{|b|...} had better be semantically equivalent to foo(){|a|...}(){|b|...}
at this time. What do you think? For example, we can write the following code.

myif = {|&cond|
   if( cond() )
     {|&then_block| {|&else_block| then_block()}}
   else
     {|&then_block| {|&else_block| else_block()}}
   end
}

I hope we are able to invoke the above Proc object as follows.

   myif{ true }{"then"}{"else"}
   myif(){ true }(){"then"}(){"else"}

The second form is not accepted from incorrect syntax so far, despite the
following accepted code.

   f = myif(){ false }
   g = f(){"then"}
   h = g(){"else"}

···

--
Takaaki Tateishi <ttate@ttsky.net>

Hi --

* Yukihiro Matsumoto (Mar 06, 2005 14:50):

Isn't that a little bit awkward-looking? Or am I just being too
sensitive about new forms of significant punctuation in the
language?

Maybe, maybe not. It's very subjective matter.

Definitely. I'd write it as

  x = lambda { ... }

if there weren't any arguments. It'd make it much more clear that it
was a thunk and nothing else.

(If there were arguments I'd consider skipping the proc/lamda:

  x = { |a| ... }
),

I'm trying to figure out why I don't like this (including the {||...}
form.

I think it's because it requires visual backtracking. When I see:

   x = {

I read it as a hash constructor. With the lambda possibility, I have
to read further, and *then* understand what the { meant.

   x = {| # OK, that { was *not* a hash constructor

Even though {...} can also be a block, there's never any ambiguity or
backtracking required:

   x.y { # block
   x.y({ # hash

so by the time the { is reached, it's clear what it means.

I guess I don't like having the meaning of the { be undetermined by
what is on its left. At least that's my current shot at analyzing why
this syntax change doesn't appeal to me.

David

···

On Mon, 7 Mar 2005, Nikolai Weibull wrote:

--
David A. Black
dblack@wobblini.net

Takaaki Tateishi <ttate@ttsky.net> writes:

Christian Neukirchen wrote:

What about foo { |a| ... } { |b| ... } ? }:slight_smile:

In my opinion, foo{|a|...}{|b|...} had better be semantically equivalent to foo(){|a|...}(){|b|...}
at this time. What do you think? For example, we can write the following code.

myif = {|&cond|
   if( cond() )
     {|&then_block| {|&else_block| then_block()}}
   else
     {|&then_block| {|&else_block| else_block()}}
   end
}

I hope we are able to invoke the above Proc object as follows.

   myif{ true }{"then"}{"else"}
   myif(){ true }(){"then"}(){"else"}

Convinces me, although I was thinking of foo(lambda{|a|..}){|b|...}.

···

Takaaki Tateishi <ttate@ttsky.net>

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

Hi,

Christian Neukirchen wrote:

What about foo { |a| ... } { |b| ... } ? }:slight_smile:

Syntax error.

In my opinion, foo{|a|...}{|b|...} had better be semantically equivalent to foo(){|a|...}(){|b|...}
at this time. What do you think?

I'm not sure how I can interpret foo(){|a|...}(){|b|...} as a valid
Ruby code.

              matz.

···

In message "Re: ruby-dev summary 25741-25780" on Mon, 7 Mar 2005 01:24:06 +0900, Takaaki Tateishi <ttate@ttsky.net> writes:

Yukihiro Matsumoto wrote:

>In my opinion, foo{|a|...}{|b|...} had better be semantically equivalent to foo(){|a|...}(){|b|...}
>at this time. What do you think?

I'm not sure how I can interpret foo(){|a|...}(){|b|...} as a valid
Ruby code.

Would you like to use foo{|a|...}{|b|...} instead of foo(){|a|...}(){|b|...}?
I'd like to know if you are interested in method call with multiple blocks.

···

--
Takaaki Tateishi <ttate@ttsky.net>

David A. Black wrote:

I'm trying to figure out why I don't like this (including the {||...}
form.

I think it's because it requires visual backtracking. When I see:

  x = {

I read it as a hash constructor. With the lambda possibility, I have
to read further, and *then* understand what the { meant.

I'm not sure if it's the "visual backtracking" aspect, but I agree, I have trouble with braces.

It's even more confusing that you can also define a block with 'do ... end', and that you can create anonymous methods with either "proc", "Proc.new", "lambda" and the new syntax.

If it were up to me, I'd make it so braces can *only* be used for defining hashes, and then make all the methods of defining a Proc object do exactly the same thing:

(do puts "Proc!" end) == lambda do puts "Proc!" end == proc do puts "Proc!" end == Proc.new do puts "Proc!" end

It may be a really unpopular thing to get rid of braces for Procs, but I still think it would be a good idea.

1. Confusion between hashes and blocks, especially blocks without parameters.
2. Inconsistency: all "blocks of ruby code" are terminated by 'end' except for some blocks, which are terminated by '}'
3. No clear choice: 'do ... end' blocks are exactly equivalent to '{ ... }' blocks. Because of that, people have their own rules about what they use and when they use it, and that makes for confusion when reading someone else's code.

I know this is far too radical a change for the current Ruby line, but maybe for Ruby 2.0 Matz could consider this kind of change? (Unless I'm soundly booed for even suggesting it).

Oh yeah, and while I'm fundamentally changing the language, howsabout:

x = lambda
       puts "Proc!"
     end

or
x = proc puts "Proc!" end

(note the conspicuous lack of "do")

Ben

P.S. Flame away!

Hi,

Would you like to use foo{|a|...}{|b|...} instead of foo(){|a|...}(){|b|...}?

I'm not sure what you mean by the above sentence.

I'd like to know if you are interested in method call with multiple blocks.

I'm not. Multiple blocks allows something interesting (user definable
if-else clause, for example), but makes syntax and semantics too
complex.

              matz.

···

In message "Re: ruby-dev summary 25741-25780" on Mon, 7 Mar 2005 20:03:11 +0900, Takaaki Tateishi <ttate@ttsky.net> writes:

Hello Everyone,

Iam Ramya.I'am totally new to ruby.I'am a fresher and i have just
joined work.I have installed ruby and have succesfully configured
Apache for ruby on windows platform.

I'am havin problems in installin rails.Ruby gems is not working for me
an i suppose its becos am behind a firewall.So i manually installed
rake,actionpack,actionmaile,activesupport,rails.
But i dont know how am suppose to get it working.Read a lot of stuff
on the net,and i feel totally lost.

Kindly,please lemme know to how i shoud proceed further.Expecting a
reply.Please Help.

Thanks and regards
Ramya

There are some great tutorials out there:

btw, you'll also want to install mysql, but that's covered in the tutorials.
good luck with it, and welcome to Ruby (and Rails)

···

On Tue, 8 Mar 2005 02:23:20 +0900, Ramya Ramaswamy <rumyaiyer@gmail.com> wrote:

Hello Everyone,

Iam Ramya.I'am totally new to ruby.I'am a fresher and i have just
joined work.I have installed ruby and have succesfully configured
Apache for ruby on windows platform.

I'am havin problems in installin rails.Ruby gems is not working for me
an i suppose its becos am behind a firewall.So i manually installed
rake,actionpack,actionmaile,activesupport,rails.
But i dont know how am suppose to get it working.Read a lot of stuff
on the net,and i feel totally lost.

Kindly,please lemme know to how i shoud proceed further.Expecting a
reply.Please Help.

--
Bill Guindon (aka aGorilla)