Ruby-dev summary 28206-28273

Ruby
1

Hi all,

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

[ruby-dev:28211] GC.stress

TANAKA Akira proposed a new method GC.stress, which dispatches garbage
collection more eagerly. This method is useful to debug GC related
problems.

Matz agreed to him and this patch is committed in 1.9 branch.

[ruby-dev:28217] ANDCALL operator

Nobuyoshi N. suggested a new operator `&?’ (this notation is
temporary)
which evaluates left-hand-side expression, and if it is true then call
right-hand-side method. For example:

if a[1] and a[1].strip.empty?
            ||
if a[1] &? strip.empty?

h["key"] and h["key"].dispatch
            ||
h["key"] &? dispatch

The motivation of this operator is to avoid duplication of expression.

Takaaki T. proposed another idea, Object#nil? with block
(again, this name is temporary).

a[1].nil? {|str| str.strip.empty? }
h["key"].nil? {|h| h.dispatch }

This issue is still open.

[ruby-dev:28233] 1.8.5 release plan?

URABE Shyouhei proposed a rough release plan of Ruby 1.8.5,
assuming the release date is 1st Apr.

Week 0 (2/4) : Decide a plan.
Week 1 (2/11): Prohibit any feature changes on 1.8 branch.
Week 2 (2/18): Fixing bugs on 1.8 branch.
Week 3 (2/25): Preview 1; Prohibit non-critical bug fixes.
Week 4 (3/4) : Validate preview 1.
Week 5 (3/11): Preview 2; Prohibit non-critical bug fixes without

release engineer.
Week 6 (3/18): Validate preview 2.
Week 7 (3/25): Preview 3; Prohibit any changes without release
engineer.
Week 8 (4/1) : 1.8.5 release

[ruby-dev:28234] coding pragma

In 1.9 branch, you can use “coding pragma” to tell the ruby
interpreter
the encoding of program file:

#!/usr/bin/ruby
# -*- coding: UTF-8 -*-

KIMURA Koichi asked when this pragma is backported from 1.9 to 1.8.
Nobuyoshi N. said that is difficult because current implementation
calls ungetc() many times, which is not assured in C standards. Ruby
1.9 does not depend on stdio, multiple ungetc() call is not a problem.

For details of coding pragma, see the thread from [ruby-core:04881].

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

2

Minero A. [email protected] wrote:

h["key"].nil? {|h| h.dispatch }

This issue is still open.

Syntactically, a method might look better than an operator:

a[1].if?.strip.empty?
a[1].maybe.strip.empty?
a[1].and.strip.empty?

martin

3

On 02/02/06, Minero A. [email protected] wrote:

h["key"] and h["key"].dispatch

This issue is still open.

I would prefer the latter, but it doesn’t completely solve the repeated
expression issue. Worse, the use of #nil? would mean that anyone who has
overridden #nil? would have broken behaviour – and the behaviour is the
inverse of what I’d expect. (That is, I’d expect the block to be called
if the item is nil, not if it isn’t nil.)

Week 6 (3/18): Validate preview 2.
Week 7 (3/25): Preview 3; Prohibit any changes without release engineer.
Week 8 (4/1) : 1.8.5 release

Might I suggest not having a 4/1 release because of Poisson d’Avril?

-austin

4

On Thu, 2 Feb 2006, Minero A. wrote:

h[“key”] and h[“key”].dispatch

This issue is still open.

suggestion:

 harp:~ > cat a.rb
 #
 # predicate methods to avoid double evaluation of expr
 #
   module Kernel
     def iff?(a, &b) a.instance_eval &b if a end
     alias_method "if?", "iff?"
     def iff!(a, &b) a.instance_eval &b unless a end
     alias_method "if!", "iff!"
   end

   a = [ 42 ]
   b = [ false ]

 #
 # if, and only if
 #

   iff?(a.first){ p self }

 #
 # if, and only if not
 #

   iff!(b.first){ p self }



 harp:~ > ruby a.rb
 42
 false

kind regards.

-a

5

On 2 févr. 06, at 15:43, Martin DeMello wrote:

a[1].if?.strip.empty?
a[1].maybe.strip.empty?
a[1].and.strip.empty?

How about replacing ‘.’ by something else in those cases ? Something
with a slightly different semantic, like “send message only if the
receiver is not nil”.

For example, using ‘:’

if a[1] and a[1].strip.empty? ==> if a[1]:strip.empty?
h[“key”] and h[“key”].dispatch ==> h[‘key’]:dispatch

(I’ve tried with various other characters, ‘:’ is the one which looks
the best imho)

6

On Fri, 3 Feb 2006 [email protected] wrote:

Quoting Austin Z. [email protected]:

Worse, the use of #nil? would mean that anyone
who has overridden #nil? would have broken behaviour

Out of curiousity, has anyone on this list ever overriden #nil? ?
If so, why?

once. for a c-pointer extension i was playing with. never really used
it
though.

-a

7

[email protected] wrote:

           ||

harp:~ > cat a.rb
  a = [ 42 ]
#

kind regards.

-a

(Reposted to ruby-talk)

Nice. If only “if” were a Kernel method that we could tie it to back to
“if/else” constructs somehow:

iff a.first
…
else
…
end

Cue the Smalltalk weenies…

Regards,

Dan

8

Quoting Austin Z. [email protected]:

Worse, the use of #nil? would mean that anyone
who has overridden #nil? would have broken behaviour

Out of curiousity, has anyone on this list ever overriden #nil? ?
If so, why?

-mental

9

[email protected] wrote:

    def iff!(a, &b) a.instance_eval &b unless a end
    alias_method "if!", "iff!"
  end

a = nil

iff?(a.length > 2){ puts “yep” }

undefined method `length’ for nil:NilClass (NoMethodError)

I guess we need delayed evaluation. Would Nobu’s UDelegator help here?

http://tinyurl.com/7zhzb

Regards,

Dan

10

Minero A. wrote:

h["key"] &? dispatch

What about

   h["key"].?dispatch

It’s more visually similar to the ordinary method call

   h["key"].dispatch
11

[Joel VanderWerf [email protected], 2006-02-02 23.23 CET]

Minero A. wrote:

h[“key”] &? dispatch

What about

  h["key"].?dispatch

It’s more visually similar to the ordinary method call

  h["key"].dispatch

Or &. ?
k[“key”]&.chomp!&.dispatch