gmane.comp.lang.ruby.core

[ruby-core:19132] [Feature #615] "with" operator

Feature #615: "with" operator
http://redmine.ruby-lang.org/issues/show/615

Author: Lavir the Whiolet
Status: Open, Priority: Normal
Category: core, Target version: 2.0

"with" operator is required. It must work like an ordinary method which gets one arguemnt and a block. All
expressions in the block are not required to point the argument explicitly; all method calls are related
to the argument by default.

Example:

x = "Sample"
with x do
  puts class
  puts reverse
end

would produce:

String
elpmaS

----------------------------------------
http://redmine.ruby-lang.org

headers

Tomas Matousek | 5 Oct 04:27

[ruby-core:19127] Autoload and class definition

I've found an interesting corner case of autoload behavior, which I think is wrong.
Let's create a file load_c.rb with following 2 definitions:

module M
  C = 1
end

class F
  include M
end

---

Now this works:

class F
  require 'load_c'
  class C                # [1]
  end
end

It's because the class definition [1] of C doesn't look for constant C in included modules, only in the class
F itself (if it did look in the included modules we would indeed get "C is not a class" TypeError).

Now, let's do the same using constant auto-loading instead:

class F
  autoload(:C, "load_c");

  class C  # => uninitialized constant F::C (NameError)

(Continue reading)

headers

Charles Oliver Nutter | 3 Oct 22:22

[ruby-core:19126] JRuby deprioritizing support for 1.8.7 behavior

Just FYI, we've pretty much made the decision that JRuby will not make 
1.8.7 API support a priority in the near term. We will continue to 
support 1.8.6 behavior and have started filling out 1.9 behavior, but we 
have seen no evidence that 1.8.7 compatibility is needed or desired by 
JRuby users.

Discussion is welcome, and if anyone has a compelling reason why we 
should support 1.8.7, we're willing to listen.

- Charlie

headers

Thomas Sawyer | 3 Oct 15:37

[ruby-core:19120] [Feature #614] instance_method(ancestor)

Feature #614: instance_method(ancestor)
http://redmine.ruby-lang.org/issues/show/614

Author: Thomas Sawyer
Status: Open, Priority: Normal
Category: core

Currently Module#instance_methods takes a single argument, true or false, as to whether to include all
ancestor's methods. However sometimes limiting the search at a particular ancestor is helpful.
Currently this requires code along the lines of:

    meths = []
    FooClass.ancestors[0..FooClass.ancestors.index(FooAncestor)].each do |anc|
      meths = meths | anc.instance_methods(false)
    end

But it would be nice if we could simply use:

    instance_methods(FooAncestor)

This change is, practically-speaking, backward compatible, since 'true' can be the same as 'Kernel',
encompassing the entire ancestry.

This change is applicable to the entire family of "methods" methods, including Kernel#methods.

This change also helps eliminate the widely disliked true|false arguments.

The particular use case that brought this to mind was trying to write a Module#conflict? method that lists
the methods two modules or classes have in common, but excluding the methods that they share from a common ancestor.

(Continue reading)

headers

Aman Gupta | 3 Oct 01:10

[ruby-core:19114] GC.reachability_paths

I modified the patch at
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151854 to
work with 1.8.7-p72, but it dies with the following error:

ruby-1.8.7-p72 aman$ ruby -e 'o = Object.new; p GC.reachability_paths(o)'
-e:1:in `inspect': method `inspect' called on terminated object
(0x13cd38) (NotImplementedError)
       from -e:1:in `p'
       from -e:1

The patch (http://gist.github.com/14471):

diff --git a/gc.c b/gc.c
index 45facf0..a246ce9 100644
--- a/gc.c
+++ b/gc.c
@@ -74,7 +74,12 @@ static unsigned long malloc_increase = 0;
 static unsigned long malloc_limit = GC_MALLOC_LIMIT;
 static void run_final();
 static VALUE nomem_error;
+#ifdef DEBUG_REACHABILITY
+static VALUE garbage_collect0 _((VALUE));
+#define garbage_collect() garbage_collect0(0)
+#else
 static void garbage_collect();
+#endif

 int ruby_gc_stress = 0;

@@ -761,16 +766,55 @@ rb_gc_mark_maybe(obj)

(Continue reading)

headers

Martin Duerst | 2 Oct 07:49

[ruby-core:19106] Re: Indented Heredoc Whitespace Stripping

I didn't know this idea was around, but I would definitely
appreciate it very much; code with here documents either
is difficult to parse, or the data ends up with lots of
useless (and potentially harmful) blanks.

I only fear that this won't make the feature deadline
(which was September 25th).

Regards,    Martin.

At 05:25 08/10/02, James Gray wrote:
>Wasn't there a plan to strip leading whitespace out of indented  
>heredocs in Ruby 1.9?  It doesn't look that is being done:
>
>$ cat heredoc_whitespace.rb
>def hi
>               <<-END_HI
>               Hi!
>               END_HI
>end
>
>p hi
>$ ruby_dev heredoc_whitespace.rb
>"\t\tHi!\n"
>
>Am I missing something?
>
>James Edward Gray II
>

(Continue reading)

headers

Martin Duerst | 2 Oct 06:33

[ruby-core:19103] Re: Encoding.default_internal

At 07:59 08/10/02, Michael Selig wrote:
>On Thu, 02 Oct 2008 00:15:01 +1000, James Gray <james <at> grayproductions.net>  
>wrote:

>> To be honest, I doubt I would have made the effort if I had known this  
>> change was coming.  It was challenging and I'm a wimp.  ;)

>Someone had to be the trailblazer, James, even if it was only to find out  
>that it wasn't the best path 

Yes indeed. I think your experience helped Matz quite a bit
for his decision.

>But I agree with you: if a library can be confident that its inputs are at  
>least ASCII-comptible, quite a bit of your efforts could be saved.
>If on top of that, if it can be reasonably sure that all its inputs are  
>encoding compatible, then it's even better.

I think this is not about confidence. In the software world,
there is no confidence about input. It's much more about what
expectation a library sets and documents. I think there are
quite a few possibilities:

a) The library accepts and produces only UTF-8. Best used with -U.

b) The library accepts, in one run, a single arbitrary encoding,
   and returns the same encoding, if that encoding is ASCII-compatible.

c) Same as before, but extended for non-ASCII-compatible.
   (what James has done with the CVS library, as far I understand it)

(Continue reading)

headers

James Gray | 1 Oct 22:22

[ruby-core:19090] Indented Heredoc Whitespace Stripping

Wasn't there a plan to strip leading whitespace out of indented  
heredocs in Ruby 1.9?  It doesn't look that is being done:

$ cat heredoc_whitespace.rb
def hi
		<<-END_HI
		Hi!
		END_HI
end

p hi
$ ruby_dev heredoc_whitespace.rb
"\t\tHi!\n"

Am I missing something?

James Edward Gray II

headers

James Gray | 1 Oct 19:57

[ruby-core:19075] Request For Removal: No Operator Concatenation

I'm disappointed that Ruby still supports this goofy syntax:

   $ ruby_dev -ve 'p "a" "bc"'
   ruby 1.9.0 (2008-09-27 revision 0) [i386-darwin9.5.0]
   "abc"

I'm not sure I've ever seen this used on purpose, but I know I've seen  
it several times as a bug now (usually missing a comma between them).   
Ruby makes these bugs harder to find just to give us a concatenation  
syntax no one seems to use.

I vote we use 1.9 as a good excuse to remove this dubious feature.

James Edward Gray II

headers

Martin Duerst | 1 Oct 12:08

[ruby-core:19064] Fwd: [ruby-dev:36523] Re: Encoding.default_internal

There has been some disconnect lately between ruby-dev and ruby-core
about default_internal. For a while, I planned to help out a bit,
but didn't get around to it until today.

Basically, what happened was that in [ruby-dev:36523], Matz made a new,
far-reaching proposal re. default_internal. Since then, various details
(as well as the proposal itself) have been discussed extensively on
ruby-dev.

I'll try to translate the salient points of the proposal below.
Please try to read the whole mail before responding; the discussion
has moved ahead considerably on details that are not covered here.

>Date: Thu, 25 Sep 2008 00:49:10 +0900
>From: Yukihiro Matsumoto <matz <at> ruby-lang.org>
>Subject: [ruby-dev:36523] Re: Encoding.default_internal  のためのパッチ
>To: ruby-dev <at> ruby-lang.org (ruby developers list)

>まつもと ゆきひろです
>
>In message "Re: [ruby-dev:36517] Re: Encoding.default_internal         のためのパッチ"
>    on Wed, 24 Sep 2008 21:23:48 +0900, "NARUSE, Yui" <naruse <at> airemix.jp> writes:
>
>|Martin Duerst wrote:
>|> [ruby-core:18774] に Michael Selig から Encoding::default_internal
>|> の提案がありました。

[Martin:]
In ruby-core:18774, there was a proposal from Michael Selig re.
Encoding::default_internal.

(Continue reading)

headers

Joe Damato | 1 Oct 02:32

[ruby-core:19059] Ruby class name from C extensions

Hi -

If I have ruby source that looks like this:

class Test
  def ....
end

and in a ruby C extension I have something like:

fprintf(stderr, "class name: %s\n", 
RSTRING(rb_class_path(obj->as.basic.klass))->ptr);

I get output like this:

class name: #<Class:0xb7e1158> Why doesn't it output something like: 
#<Test:0x...> ? 

There are two possibilities: either I am not using the correct obj 
struct or I am misusing/misunderstanding rb_class_path().

I am fairly certain I am using the correct struct, so I am probably 
misunderstanding how rb_class_path and related functions work -- is 
there a function I can call that if I pass in a klass or a VALUE it will 
return either a c string or an RSTRING that contains the class name?

Any other hints or advice is greatly appreciated.

Thanks,
Joe

(Continue reading)

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31