ruby-dev summary 25741-25780

[Minero Aoki]

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.trapTERM) { 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

 

[Daniel Berger]

[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.

This feels like we're getting too clever for our own good. The second
form looks like some bastardized form of Lisp. Folks, we're not in a
contest to see how terse we can make Ruby.

I vote NAY.

Dan

 

[David A. Black]

Hi --

[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

 

[Yukihiro Matsumoto]

Hi,

In message "Re: ruby-dev summary 25741-25780"

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

Yes.

matz.

 

[David A. Black]

Hi --

Hi,

In message "Re: ruby-dev summary 25741-25780"

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

Yes.

OK, second question

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

 

[Yukihiro Matsumoto]

Hi,

In message "Re: ruby-dev summary 25741-25780"

|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.

 

[Steven Shaw]

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

x = {|| puts "hello" }

Wouldn't

x = (do puts "hello" end)

be ok/unambiguous?

 

[Nikolai Weibull]

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

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

 

[David A. Black]

Hi --

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



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

 

[Martin DeMello]

This feels like we're getting too clever for our own good. The second
form looks like some bastardized form of Lisp. Folks, we're not in a
contest to see how terse we can make Ruby.

I vote NAY.

How many times have you had to pass an inline lambda as an argument to a
method? How many of those times have you winced at how ugly it was? IMHO
this change will encourage the use of lambdas as arguments, which is a
good thing.

martin

 

[Daniel Berger]

How many times have you had to pass an inline lambda as an argument to a
method?

None.

Dan

 

[Ben Giddings]

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!

 

[Ramya Ramaswamy]

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

 

[Bill Guindon]

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.

There are some great tutorials out there:
http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html?page=1
http://www.onlamp.com/pub/a/onlamp/2005/03/03/rails.html
http://rails.homelinux.org/

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)

 

[Marcelo Paniagua]

Hello there!

I'm using Tomita Masahiro MySQL-Ruby 2.5 Library and MySQL 4.1. When I
try to connect, I receive the following message:

Client does not support authentication protocol

Any idea how to correct this? It seems the library works well when it
connects via an anonymous account.

Thanks!

Marcelo Paniagua L.

 

[Austin Ziegler]

Hello there!

I'm using Tomita Masahiro MySQL-Ruby 2.5 Library and MySQL 4.1. When I
try to connect, I receive the following message:

Client does not support authentication protocol

Any idea how to correct this? It seems the library works well when it
connects via an anonymous account.

I believe that this has to do with MySQL changing its authentication protocol.

-austin

 

[Belorion]

I believe that this has to do with MySQL changing its authentication protocol.

Yes, if I recall correctly, Tomita Masahiro's MySQL-Ruby 2.5 library
only works with MySQL < 4.1 (we use 4.0.20 at work just fine).

 

[Don Owens]

The password style has changed in MySQL 4.1. I have seen this error
message when trying to access a MySQL 4.1 server with a MySQL 4.0
client. The problem was fixed with the OLD_PASSWORD() function
mentioned here:

http://dev.mysql.com/doc/mysql/en/old-client.html

Don

 

[Trans]

Consider droping the { and } all together and use parens? Instead of
either

x = {|a| p a }

or

x = (do |a| p a end)

use

x = (|a| p a)

T.

 

[Trans]

Or better yet (though I know no one is going to agree) change hashes to
use square brackets too.

[ :a => 1, :b => 2 ]

Is this really so hard to differentiate from an array?

T.