ruby-dev summary 25741-25780
Minero Aoki
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
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
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
dbl...@wobblini.net
Yukihiro Matsumoto
In message "Re: ruby-dev summary 25741-25780"
on Sun, 6 Mar 2005 20:15:03 +0900, "David A. Black" <dbl...@wobblini.net> writes:
|Wouldn't this require empty || for blocks that don't take arguments?
|For example:
|
| x = {|| puts "hello" }
Yes.
matz.
Christian Neukirchen
> [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 <chneuk...@gmail.com> http://chneukirchen.org
David A. Black
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?
Yukihiro Matsumoto
In message "Re: ruby-dev summary 25741-25780"
on Sun, 6 Mar 2005 20:56:08 +0900, Christian Neukirchen <chneuk...@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.
Yukihiro Matsumoto
In message "Re: ruby-dev summary 25741-25780"
on Sun, 6 Mar 2005 20:59:34 +0900, "David A. Black" <dbl...@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
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
> > 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
> On Sun, 6 Mar 2005 22:45:55 +0900, Yukihiro Matsumoto
> <ma...@ruby-lang.org> wrote:
>> Hi,
>>
>> In message "Re: ruby-dev summary 25741-25780"
>> on Sun, 6 Mar 2005 20:56:08 +0900, Christian Neukirchen <chneuk...@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.
>>
>
> I like that!
It's fine with me.
What about foo { |a| ... } { |b| ... } ? }:-)
> regards,
>
> Brian
Takaaki Tateishi
> What about foo { |a| ... } { |b| ... } ? }:-)
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 <tt...@ttsky.net>
David A. Black
On Mon, 7 Mar 2005, Nikolai Weibull wrote:
> * 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.
Joao Pedrosa
On Sun, 6 Mar 2005 22:45:55 +0900, Yukihiro Matsumoto
<ma...@ruby-lang.org> wrote:
Cool. Ruby won't lose its closures king position to Perl 6 anymore... hehe. :-)
Nice.
Cheers,
Joao
Christian Neukirchen
> Christian Neukirchen wrote:
>> What about foo { |a| ... } { |b| ... } ? }:-)
>
> 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 <tt...@ttsky.net>
Yukihiro Matsumoto
In message "Re: ruby-dev summary 25741-25780"
on Mon, 7 Mar 2005 01:24:06 +0900, Takaaki Tateishi <tt...@ttsky.net> writes:
|Christian Neukirchen wrote:
|> What about foo { |a| ... } { |b| ... } ? }:-)
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.
Florian Gross
> |Christian Neukirchen wrote:
> |> What about foo { |a| ... } { |b| ... } ? }:-)
>
> Syntax error.
Any way to add that as well? I think the biggest plus of having
lambda-less objectified blocks is being able to pass multiple of them to
functions in a way that is very similar to passing a single one.
But then again perhaps keyword lambdaless blocks should be prefered?
Csaba Henk
> Yukihiro Matsumoto wrote:
>
>> |Christian Neukirchen wrote:
>> |> What about foo { |a| ... } { |b| ... } ? }:-)
>>
>> Syntax error.
>
> Any way to add that as well? I think the biggest plus of having
> lambda-less objectified blocks is being able to pass multiple of them to
> functions in a way that is very similar to passing a single one.
Hm. I'm not sure it would do any good. The block argument *is*
semantically different from proc arguments, may those appear as
"proc{|..| ... foo ... }" or just "{|..| ... foo ... }".
I'm for this sugaring crusade which is happening now, but
"foo { |a| ... } { |b| ... }" is too much ambiguous for me.
It supposed to mean "foo({ |a| ... }) { |b| ... }", but it just at one
character distance from "foo { |a| ... }, { |b| ... }", which is
something else. Uh, wait a minute! This latter is not valid as of
current cvs!
Anyway, now we have
foo({ |a| ... }) { |b| ... }
and
"foo({ |a| ... },{ |b| ... })"
and both just as terse as they should be.
Csaba
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
Takaaki Tateishi
> |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 <tt...@ttsky.net>
Martin DeMello
If blocks are allowed to take blocks, it raises the problem of
(foo {|a| }){|b| }
versus
foo {|a| } {|b| }
martin
Daniel Berger
Martin DeMello wrote:
> Daniel Berger <djbe...@hotmail.com> wrote:
> >
> > 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?
None.
Dan
Yukihiro Matsumoto
In message "Re: ruby-dev summary 25741-25780"
on Mon, 7 Mar 2005 20:03:11 +0900, Takaaki Tateishi <tt...@ttsky.net> writes:
|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.
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
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
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)
--
Bill Guindon (aka aGorilla)
Marcelo Paniagua
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.
--
Este correo esta libre de virus!
Austin Ziegler
<pani...@pcmxl.com.mx> wrote:
> 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
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
Belorion
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
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
On Tue, 8 Mar 2005 04:34:02 +0900, Marcelo Paniagua
<pani...@pcmxl.com.mx> wrote:
--
Don Owens
rege...@gmail.com
Trans
either
x = {|a| p a }
or
x = (do |a| p a end)
use
x = (|a| p a)
T.
Trans
use square brackets too.
[ :a => 1, :b => 2 ]
Is this really so hard to differentiate from an array?
T.
George Ogata
Very, when it's empty.
But, yeah, it's unfortunate that curlies are overloaded. I don't
really find the "visual backtracking" that David talked about a
problem. but it does seem icky that there's this "exception to the
rule" in that you can't create empty procs this way. I guess empty
procs aren't that common, though.
Trans
True. But
[=>]
though a bit odd looking, would work fine. With 1.9 and the new
notation for symbol keys,
[:]
could work too and it looks fairly nice, to me at least.
T.
Matt Mower
I created a patch for Tomita's client (which is included as a part of
Rails ActiveRecord) to handle the 4.1 authentication protocol. There
are, I think, a few issues still with mixed access (i.e. access a 4.1
and pre-4.1 server in the same session) but otherwise it seems robust.
The only way to obtain it at the moment is to install the activerecord
gem (or use svn).
Regards,
Matt
--
Matt Mower :: http://matt.blogs.it/
Marcelo Paniagua
mysql411.rb or mysql.rb?
Thanks
----- Original Message -----
From: "Matt Mower" <matt....@gmail.com>
To: "ruby-talk ML" <ruby...@ruby-lang.org>
Sent: Friday, March 11, 2005 10:37 AM
Subject: Re: Problems connecting MySQL with Ruby
> I created a patch for Tomita's client (which is included as a part of
> Rails ActiveRecord) to handle the 4.1 authentication protocol. There
> are, I think, a few issues still with mixed access (i.e. access a 4.1
> and pre-4.1 server in the same session) but otherwise it seems robust.
>
> The only way to obtain it at the moment is to install the activerecord
> gem (or use svn).
>
> Regards,
>
> Matt
>
> --
> Matt Mower :: http://matt.blogs.it/
>
>
Matt Mower
On Tue, 15 Mar 2005 07:20:42 +0900, Marcelo Paniagua
<pani...@pcmxl.com.mx> wrote:
> While using this unit, what would be the correct unit to require?
> mysql411.rb or mysql.rb?
>
First mysql, then mysql411. The latter redefines a few methods from
the former to handle 4.1+ authentication and working out which route
to take.
James Britt
>
> I created a patch for Tomita's client (which is included as a part of
> Rails ActiveRecord) to handle the 4.1 authentication protocol. There
> are, I think, a few issues still with mixed access (i.e. access a 4.1
> and pre-4.1 server in the same session) but otherwise it seems robust.
>
> The only way to obtain it at the moment is to install the activerecord
> gem (or use svn).
Has this patch been offered to Tomita so it can be rolled into the
stand-alone ruby-mysql lib?
Thanks,
James
--
http://www.ruby-doc.org
http://www.rubyxml.com
http://catapult.rubyforge.com
http://orbjson.rubyforge.com
http://ooo4r.rubyforge.com
http://www.jamesbritt.com
Matt Mower
> Matt Mower wrote:
> >
> > I created a patch for Tomita's client (which is included as a part of
> > Rails ActiveRecord) to handle the 4.1 authentication protocol. There
> > are, I think, a few issues still with mixed access (i.e. access a 4.1
> > and pre-4.1 server in the same session) but otherwise it seems robust.
> >
> > The only way to obtain it at the moment is to install the activerecord
> > gem (or use svn).
>
> Has this patch been offered to Tomita so it can be rolled into the
> stand-alone ruby-mysql lib?
>
Not at this point but it certainly was my intention. I should take
another look at this.
M