Discussion:
[ruby-core:18436] [ANN] Ruby 1.9.1 feature freeze
(too old to reply)
Yugui (Yuki Sonoda)
2008-09-02 06:09:50 UTC
Permalink
Hi all,

As announced before, Ruby 1.9.1 features will be frozen on 25 September.

After the time,
* Ruby level APIs must not changed.
* C level APIs will must not changed without discussion on
ruby-core/ruby-dev.
* All structures, data types, variables, functions and macros in
include/ruby/*.h are regarded as public C level APIs.
* Move it from include/ruby/*.h anything you want not to publish.

And I will create the ruby_1_9_1 branch and release 1.9.1 RC1 on 25
October. After the time,
* C level APIs will must not changed.

Also the C level APIs of 1.9.x must have backward binary-compatibility
to 1.9.1.


Regards,

-- Yuki Sonoda (Yugui) <***@yugui.jp>
Rocky Bernstein
2008-09-02 12:12:14 UTC
Permalink
Where do things stand with respect to the 1-byte trace instruction and
a trace instruction-replacement mechanism? There was some discussion a
while back as to whether or not this was going to get into 1.9.1.

Thanks.
Post by Yugui (Yuki Sonoda)
Hi all,
As announced before, Ruby 1.9.1 features will be frozen on 25 September.
After the time,
* Ruby level APIs must not changed.
* C level APIs will must not changed without discussion on
ruby-core/ruby-dev.
* All structures, data types, variables, functions and macros in
include/ruby/*.h are regarded as public C level APIs.
* Move it from include/ruby/*.h anything you want not to publish.
And I will create the ruby_1_9_1 branch and release 1.9.1 RC1 on 25
October. After the time,
* C level APIs will must not changed.
Also the C level APIs of 1.9.x must have backward binary-compatibility
to 1.9.1.
Regards,
SASADA Koichi
2008-09-02 12:32:58 UTC
Permalink
Hi,
Post by Rocky Bernstein
Where do things stand with respect to the 1-byte trace instruction and
a trace instruction-replacement mechanism? There was some discussion a
while back as to whether or not this was going to get into 1.9.1.
As I mentioned at [ruby-core:17686] and other posts, 1.9.1 should
not be include this feature, but 1.9.2 or later should.
--
// SASADA Koichi at atdot dot net
C.E. Thornton
2008-09-02 19:28:52 UTC
Permalink
Post by Yugui (Yuki Sonoda)
Hi all,
As announced before, Ruby 1.9.1 features will be frozen on 25 September.
After the time,
* Ruby level APIs must not changed.
* C level APIs will must not changed without discussion on
ruby-core/ruby-dev.
* All structures, data types, variables, functions and macros in
include/ruby/*.h are regarded as public C level APIs.
* Move it from include/ruby/*.h anything you want not to publish.
And I will create the ruby_1_9_1 branch and release 1.9.1 RC1 on 25
October. After the time,
* C level APIs will must not changed.
Also the C level APIs of 1.9.x must have backward binary-compatibility
to 1.9.1.
Regards,
Matz,

Will absolute_path() make it into this release??

Chuck
--
Competency and chastity have much in common,
they both encompass their own punishment!

-- C.E. Thornton -- Hawthorne Press --
Dave Thomas
2008-09-02 19:34:17 UTC
Permalink
Post by C.E. Thornton
Will absolute_path() make it into this release??
It's in HEAD right now


Dave
C.E. Thornton
2008-09-02 21:29:47 UTC
Permalink
Post by Dave Thomas
Post by C.E. Thornton
Will absolute_path() make it into this release??
It's in HEAD right now
Dave
Opps -- Sorry Dave, I didn't look at HEAD!
Chuck
--
Competency and chastity have much in common,
they both encompass their own punishment!

-- C.E. Thornton -- Hawthorne Press --
Roger Pack
2008-09-04 16:13:56 UTC
Permalink
Would it be possible to have a few patches applied before freeze [if
possible]-I know I would use them [for being able to run racc against
the original method definitions, etc.] :)

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12598

and/or

http://groups.google.com/group/ruby-core-google/browse_thread/thread/932c0ea1078e294a

I'd be happy to submit a more formal patch for them, as well, if desired.

Thanks!
-=R
hemant
2008-09-04 17:34:24 UTC
Permalink
Post by Roger Pack
Would it be possible to have a few patches applied before freeze [if
possible]-I know I would use them [for being able to run racc against
the original method definitions, etc.] :)
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12598
and/or
http://groups.google.com/group/ruby-core-google/browse_thread/thread/932c0ea1078e294a
I'd be happy to submit a more formal patch for them, as well, if desired.
This was a very wrong subject line to choose. :)
Charles Oliver Nutter
2008-09-06 18:38:38 UTC
Permalink
Post by hemant
Post by Roger Pack
Would it be possible to have a few patches applied before freeze [if
possible]-I know I would use them [for being able to run racc against
the original method definitions, etc.] :)
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12598
and/or
http://groups.google.com/group/ruby-core-google/browse_thread/thread/932c0ea1078e294a
I'd be happy to submit a more formal patch for them, as well, if desired.
This was a very wrong subject line to choose. :)
Definitely confused me!
Yukihiro Matsumoto
2008-09-06 19:53:43 UTC
Permalink
Hi,

In message "Re: [ruby-core:18452] [ANN] Ruby 1.9.1 feature freeze"
on Fri, 5 Sep 2008 01:13:56 +0900, "Roger Pack" <***@gmail.com> writes:

|Would it be possible to have a few patches applied before freeze [if
|possible]-I know I would use them [for being able to run racc against
|the original method definitions, etc.] :)
|
|http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12598

This is a proposal to add __file__ and __line__ methods to Method and
Proc objects. Issues are:

* the method names. I don't think proposed names that are
surrounded by underscores are appropriate.
* non-Ruby defined methods/procs. the patch raises TypeError, but
is it really appropriate? Should they return nil for such cases?
* use-case. the proposal comes with use-case sourceref.rb, but any
other use case?

matz.
Wilson Bilkovich
2008-09-06 21:23:28 UTC
Permalink
Post by Yukihiro Matsumoto
Hi,
In message "Re: [ruby-core:18452] [ANN] Ruby 1.9.1 feature freeze"
|Would it be possible to have a few patches applied before freeze [if
|possible]-I know I would use them [for being able to run racc against
|the original method definitions, etc.] :)
|
|http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12598
This is a proposal to add __file__ and __line__ methods to Method and
* the method names. I don't think proposed names that are
surrounded by underscores are appropriate.
* non-Ruby defined methods/procs. the patch raises TypeError, but
is it really appropriate? Should they return nil for such cases?
* use-case. the proposal comes with use-case sourceref.rb, but any
other use case?
RSpec currently uses eval("caller(0)", @a_proc_instance) to simulate
this behavior.
I had not seen this proposal before, but I like it.
I looked into this while working on RSpec for Rubinius, and this seems
to be the only way to determine where a particular block_pass or proc
was created.

RSpec cares about this because (as one example) it allows users to
specify 'examples' to run by regexp against their description.

These 'examples' could be in any spec file, so it uses what I have
taken to calling the 'declaration trace' .. in other words, what you
get when you eval Kernel#caller with a proc as binding.

Using eval for this is slow and ugly; it would be nice to have a clean
feature to implement.
I considered proposing Proc#caller when I first encountered this, but
__file__ and __line__ are nice.

While I am on the subject, here is the bug ticket I filed related to this:
http://redmine.ruby-lang.org/issues/show/146
Roger Pack
2008-09-08 04:02:26 UTC
Permalink
Sorry for the original subject line being wrong--my attempt to post on
the right thread went very awry :)
Post by Yukihiro Matsumoto
This is a proposal to add __file__ and __line__ methods to Method and
* the method names. I don't think proposed names that are
surrounded by underscores are appropriate.
Perhaps #definition_file/ #definition_line or
#declaration_file/#declaration_line?
Post by Yukihiro Matsumoto
* non-Ruby defined methods/procs. the patch raises TypeError, but
is it really appropriate? Should they return nil for such cases?
Nil is probably better, since it already returns nil in some cases.
Post by Yukihiro Matsumoto
* use-case. the proposal comes with use-case sourceref.rb, but any
other use case?
For me I'll use it to lookup where methods are defined so that I can
<gulp> hate to admit it--re-parse the methods [using racc or what
not], see if they can be optimized, combine them with sub methods, add
pseudo named parameter wrappers, that type of thing.

On second thought I'm wondering if the following would be more useful:
Method#iseq
Proc#iseq

and then add the file/line methods to iseq itself:
RubyVM::InstructionSequence#declaration_file
RubyVM::InstructionSequence#declaration_line

So looking up a method's declaration line would be like
klass.instance_method(:name).iseq.declaration_file

Then that would give us access to the iseq as well as to the file/line
positions. That would be even better for me [since I would then have
access to the iseq for proc's as well as method's--there seems to
currently be no way to disassemble procs, that I know of, so this
would also conveniently overcome this difficulty as well].
I'd be happy to submit a modified patch.
Thanks!
-=R
Nobuyoshi Nakada
2008-09-08 09:05:05 UTC
Permalink
Hi,

At Sun, 7 Sep 2008 04:53:43 +0900,
Post by Yukihiro Matsumoto
This is a proposal to add __file__ and __line__ methods to Method and
* the method names. I don't think proposed names that are
surrounded by underscores are appropriate.
* non-Ruby defined methods/procs. the patch raises TypeError, but
is it really appropriate? Should they return nil for such cases?
* use-case. the proposal comes with use-case sourceref.rb, but any
other use case?
I propose a new method, #location than those two new methods.


Index: proc.c
===================================================================
--- proc.c (revision 19215)
+++ proc.c (working copy)
@@ -510,9 +510,9 @@ proc_call(int argc, VALUE *argv, VALUE p
rb_proc_t *proc;
rb_block_t *blockptr = 0;
+ rb_iseq_t *iseq;
GetProcPtr(procval, proc);

- if (BUILTIN_TYPE(proc->block.iseq) == T_NODE ||
- proc->block.iseq->arg_block != -1) {
-
+ iseq = proc->block.iseq;
+ if (BUILTIN_TYPE(iseq) == T_NODE || iseq->arg_block != -1) {
if (rb_block_given_p()) {
rb_proc_t *proc;
@@ -621,8 +621,7 @@ get_proc_iseq(VALUE self)
}

-VALUE
-rb_proc_location(VALUE self)
+static VALUE
+iseq_location(rb_iseq_t *iseq)
{
- rb_iseq_t *iseq = get_proc_iseq(self);
VALUE loc[2];

@@ -640,4 +639,18 @@ rb_proc_location(VALUE self)
/*
* call-seq:
+ * prc.location => [String, Fixnum]
+ *
+ * returns the ruby source filename and line number containing this proc
+ * or nil if this proc was not defined in ruby (i.e. native)
+ */
+
+VALUE
+rb_proc_location(VALUE self)
+{
+ return iseq_location(get_proc_iseq(self));
+}
+
+/*
+ * call-seq:
* prc == other_proc => true or false
*
@@ -1438,4 +1451,37 @@ rb_obj_method_arity(VALUE obj, ID id)
}

+static rb_iseq_t *
+get_method_iseq(VALUE method)
+{
+ struct METHOD *data;
+ NODE *body;
+ rb_iseq_t *iseq;
+
+ Data_Get_Struct(method, struct METHOD, data);
+ body = data->body;
+ switch (nd_type(body)) {
+ case RUBY_VM_METHOD_NODE:
+ GetISeqPtr((VALUE)body->nd_body, iseq);
+ if (RUBY_VM_NORMAL_ISEQ_P(iseq)) break;
+ default:
+ return 0;
+ }
+ return iseq;
+}
+
+/*
+ * call-seq:
+ * meth.location => [String, Fixnum]
+ *
+ * returns the ruby source filename and line number containing this method
+ * or nil if this method was not defined in ruby (i.e. native)
+ */
+
+VALUE
+rb_method_location(VALUE method)
+{
+ return iseq_location(get_method_iseq(method));
+}
+
/*
* call-seq:
@@ -1769,4 +1815,5 @@ Init_Proc(void)
rb_define_method(rb_cProc, "binding", proc_binding, 0);
rb_define_method(rb_cProc, "curry", proc_curry, -1);
+ rb_define_method(rb_cProc, "location", rb_proc_location, 0);

/* Exceptions */
@@ -1803,4 +1850,5 @@ Init_Proc(void)
rb_define_method(rb_cMethod, "owner", method_owner, 0);
rb_define_method(rb_cMethod, "unbind", method_unbind, 0);
+ rb_define_method(rb_cMethod, "location", rb_method_location, 0);
rb_define_method(rb_mKernel, "method", rb_obj_method, 1);
rb_define_method(rb_mKernel, "public_method", rb_obj_public_method, 1);
@@ -1820,4 +1868,5 @@ Init_Proc(void)
rb_define_method(rb_cUnboundMethod, "owner", method_owner, 0);
rb_define_method(rb_cUnboundMethod, "bind", umethod_bind, 1);
+ rb_define_method(rb_cUnboundMethod, "location", rb_method_location, 0);

/* Module#*_method */
--
Nobu Nakada
Yukihiro Matsumoto
2008-09-08 09:36:21 UTC
Permalink
Hi,

In message "Re: [ruby-core:18490] Re: [ANN] Ruby 1.9.1 feature freeze"
on Mon, 8 Sep 2008 18:05:05 +0900, Nobuyoshi Nakada <***@ruby-lang.org> writes:

|At Sun, 7 Sep 2008 04:53:43 +0900,
|Yukihiro Matsumoto wrote in [ruby-core:18471]:
|> This is a proposal to add __file__ and __line__ methods to Method and
|> Proc objects.

|I propose a new method, #location than those two new methods.

I like the idea. How others think?

matz.
Trans
2008-09-08 11:22:58 UTC
Permalink
Post by Yukihiro Matsumoto
Hi,
In message "Re: [ruby-core:18490] Re: [ANN] Ruby 1.9.1 feature freeze"
|At Sun, 7 Sep 2008 04:53:43 +0900,
|> This is a proposal to add __file__ and __line__ methods to Method and
|> Proc objects.
|I propose a new method, #location than those two new methods.
I like the idea.  How others think?
Seems reasonable if __FILE__ and __LINE__ can't do the job.

But, will it lead to wanting a general #location method to use in
place of __FILE__ and __LINE__? If so, a more specialized name, eg.
#source_location, would be better.

Also, should the method be defined for Binding too?

T.


P.S. A bit aside, but could we also have a method for

binding.eval{ self }

too (eg. Binding#context)?
Yukihiro Matsumoto
2008-09-09 08:30:42 UTC
Permalink
Hi,

In message "Re: [ruby-core:18493] Re: [ANN] Ruby 1.9.1 feature freeze"
on Mon, 8 Sep 2008 20:22:58 +0900, Trans <***@gmail.com> writes:

|But, will it lead to wanting a general #location method to use in
|place of __FILE__ and __LINE__? If so, a more specialized name, eg.
|#source_location, would be better.

I like #source_location best.

|Also, should the method be defined for Binding too?

Probably a good idea.

|P.S. A bit aside, but could we also have a method for
|
| binding.eval{ self }
|
|too (eg. Binding#context)?

Is self really a context?

matz.
Trans
2008-09-09 23:39:11 UTC
Permalink
Post by Yukihiro Matsumoto
|P.S. A bit aside, but could we also have a method for
|
|  binding.eval{ self }
|
|too (eg. Binding#context)?
Is self really a context?
For lack of a better word.

T.
Wilson Bilkovich
2008-09-08 14:41:06 UTC
Permalink
Post by Yukihiro Matsumoto
Hi,
In message "Re: [ruby-core:18490] Re: [ANN] Ruby 1.9.1 feature freeze"
|At Sun, 7 Sep 2008 04:53:43 +0900,
|> This is a proposal to add __file__ and __line__ methods to Method and
|> Proc objects.
|I propose a new method, #location than those two new methods.
I like the idea. How others think?
This is a specialized feature. Having a specialized name appeals to
me; 'location' is good.
Roger Pack
2008-09-08 15:20:26 UTC
Permalink
I think Trans' #source_location is nice.

I would prefer to rewrite this patch to become

RubyVM::InstructionSequence#source_location # or whatever name we use

And then also provide
Method#iseq
and
Proc#iseq
methods

To also provide the added capability of accessing Proc's iseq's [and
disassembling it, etc.--currently unavailable]

except I am having trouble creating Proc#iseq [Method#iseq is here[1]].

Any pointers on how to accomplish this? :)
Thanks for your help.
-=R
[1] http://groups.google.com/group/ruby-core-google/browse_thread/thread/932c0ea1078e294a
Post by Yukihiro Matsumoto
Hi,
In message "Re: [ruby-core:18490] Re: [ANN] Ruby 1.9.1 feature freeze"
|At Sun, 7 Sep 2008 04:53:43 +0900,
|> This is a proposal to add __file__ and __line__ methods to Method and
|> Proc objects.
|I propose a new method, #location than those two new methods.
I like the idea. How others think?
matz.
--
Thanks!
-=R
--
Thanks!
-=R
Wilson Bilkovich
2008-09-08 18:26:30 UTC
Permalink
Post by Roger Pack
I think Trans' #source_location is nice.
I would prefer to rewrite this patch to become
RubyVM::InstructionSequence#source_location # or whatever name we use
And then also provide
Method#iseq
and
Proc#iseq
methods
To also provide the added capability of accessing Proc's iseq's [and
disassembling it, etc.--currently unavailable]
except I am having trouble creating Proc#iseq [Method#iseq is here[1]].
I much prefer 'location', because it is something that every Ruby
implementation can provide. iseq is super super low-level, and we
should think hard about the API before calling it public.
Charles Oliver Nutter
2008-09-09 01:40:36 UTC
Permalink
Post by Wilson Bilkovich
I much prefer 'location', because it is something that every Ruby
implementation can provide. iseq is super super low-level, and we
should think hard about the API before calling it public.
I would also hope any "location" methods added will refer only to static
information, like the place the Proc was created, rather than adding yet
another method with "special" knowledge of the caller's context
(requiring the ability to look across invocation frames).

- Charlie
Roger Pack
2008-09-09 18:21:20 UTC
Permalink
Post by Wilson Bilkovich
I much prefer 'location', because it is something that every Ruby
implementation can provide. iseq is super super low-level, and we
should think hard about the API before calling it public.
True. I suppose my suggestion was a little bit MRI-centric after all :)

Could I then also make a request for a few MRI specific functions, either
Post by Wilson Bilkovich
p = proc { |n| n + 2 }
=> #<Proc:...>
Post by Wilson Bilkovich
RubyVM::InstructionSequence.disassemble p # this doesn't currently work
or the before mentioned
Proc#iseq
(Unbound)Method#iseq [see [1]]

These would yield some very welcome functionality for projects like
[2,3,4] since it would allow users to potentially parse blocks [and
rewrite them] before executing them, which has some strong potential.
This is available in 1.8.x because the AST is made available to c
functions, but not (yet) for 1.9.

Thanks for your help.
-=R

[1] http://groups.google.com/group/ruby-core-google/browse_thread/thread/932c0ea1078e294a
[2] http://rewrite.rubyforge.org/
[3] http://parsetree.rubyforge.org/
[4] http://code.google.com/p/ruby-roger-useful-functions/wiki/NamedParameters
Paul Brannan
2008-09-10 17:01:31 UTC
Permalink
Post by Roger Pack
Post by Wilson Bilkovich
I much prefer 'location', because it is something that every Ruby
implementation can provide. iseq is super super low-level, and we
should think hard about the API before calling it public.
True. I suppose my suggestion was a little bit MRI-centric after all :)
Could I then also make a request for a few MRI specific functions, either
Post by Wilson Bilkovich
p = proc { |n| n + 2 }
=> #<Proc:...>
Post by Wilson Bilkovich
RubyVM::InstructionSequence.disassemble p # this doesn't currently work
With ruby-internal (http://github.com/cout/ruby-internal) you can do this:

irb(main):001:0> require 'internal/proc'
=> true
irb(main):002:0> p = proc { |n| n + 2 }
=> #<Proc:0x40275ed0@(irb):2>
irb(main):003:0> puts p.body.disasm
== disasm: <ISeq:block (3 levels) in irb_binding@(irb)>=================
== catch table
| catch type: redo st: 0000 ed: 0006 sp: 0000 cont: 0000
| catch type: next st: 0000 ed: 0006 sp: 0000 cont: 0006
|------------------------------------------------------------------------
local table (size: 1, argc: 1 [opts: 0, rest: -1, post: 0, block: -1] s3)
[ 1] n<Arg>
0000 getdynamic n, 0 ( 2)
0003 putobject 2
0005 opt_plus
0006 leave
=> nil
Post by Roger Pack
or the before mentioned
Proc#iseq
(Unbound)Method#iseq [see [1]]
These would yield some very welcome functionality for projects like
[2,3,4] since it would allow users to potentially parse blocks [and
rewrite them] before executing them, which has some strong potential.
This is available in 1.8.x because the AST is made available to c
functions, but not (yet) for 1.9.
AFAICT the AST is discarded once the method is compiled to bytecode.

Paul
Roger Pack
2008-09-16 20:10:19 UTC
Permalink
Post by Roger Pack
To also provide the added capability of accessing Proc's iseq's [and
disassembling it, etc.--currently unavailable]
except I am having trouble creating Proc#iseq [Method#iseq is here[1]].
Any pointers on how to accomplish this? :)
Thanks to Paul Brannan for his pointers.
I have included here a patch with a prototype
VM::InstructionSequence.disassemble_proc
method with the functionality that I was hoping could be added.
I was unsure how to rewrite
VM::InstructionSequence.disassemble

to handle both methods and procs, so just wrote a separate method.

Thoughts?
-=R
Index: iseq.c
===================================================================
--- iseq.c (revision 19392)
+++ iseq.c (working copy)
@@ -928,6 +928,21 @@
return ret;
}

+static VALUE
+iseq_s_disasm_proc(VALUE klass, VALUE proc)
+{
+ VALUE ret = Qnil;
+ rb_proc_t *proc_pointer;
+ GetProcPtr(proc, proc_pointer);
+ VALUE iseqval = (VALUE) proc_pointer->block.iseq->self;
+ if (RUBY_VM_NORMAL_ISEQ_P(iseqval))
+ ret = ruby_iseq_disasm(iseqval);
+
+ return ret;
+}
+
+
+
const char *
ruby_node_name(int node)
{
@@ -1339,5 +1354,6 @@
rb_define_singleton_method(rb_cISeq, "compile_option=",
iseq_s_compile_option_set, 1);
rb_define_singleton_method(rb_cISeq, "disasm", iseq_s_disasm, 1);
rb_define_singleton_method(rb_cISeq, "disassemble", iseq_s_disasm, 1);
+ rb_define_singleton_method(rb_cISeq, "disassemble_proc",
iseq_s_disasm_proc, 1);
}
Robert Klemme
2008-09-08 15:24:13 UTC
Permalink
Post by Yukihiro Matsumoto
Hi,
In message "Re: [ruby-core:18490] Re: [ANN] Ruby 1.9.1 feature freeze"
|At Sun, 7 Sep 2008 04:53:43 +0900,
|> This is a proposal to add __file__ and __line__ methods to Method and
|> Proc objects.
|I propose a new method, #location than those two new methods.
I like the idea. How others think?
Good! I'd like to suggest a name alternative though

#defined_at

IMHO #location is very general and #defined_at better expresses what's
being returned (at least from what I gathered should be the semantics
of this method). Usage would be

def foo(&b)
file, line = b.defined_at
$stderr.printf "calling block which was defined at %s:%d\n", file, line
b.call
end

Kind regards

robert
--
use.inject do |as, often| as.you_can - without end
Joel VanderWerf
2008-09-08 19:27:10 UTC
Permalink
Post by Robert Klemme
#defined_at
IMHO #location is very general and #defined_at better expresses what's
being returned (at least from what I gathered should be the semantics
of this method). Usage would be
Agree. It is convenient to use subclasses of Procs. Having such a
general method name taken away is sob-optimal.
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Roger Pack
2008-09-20 18:49:50 UTC
Permalink
Post by Nobuyoshi Nakada
I propose a new method, #location than those two new methods.
...
Post by Nobuyoshi Nakada
--
Nobu Nakada
Interestingly, there already was an rb_proc_location method in 1.9
[just no Proc#location nor Method#location nor Binding#location].

Anyway, here's Nobu Nakada's patch with the method name changed to
source_location [should work against SVN head].

Note also the recent creation of
Feature #578: add method to disassemble Proc objects

Thanks for your help. I know I'm annoying with this :)
-=R

Index: proc.c
===================================================================
--- proc.c (revision 19438)
+++ proc.c (working copy)
@@ -509,11 +509,11 @@
{
rb_proc_t *proc;
rb_block_t *blockptr = 0;
+ rb_iseq_t *iseq;
GetProcPtr(procval, proc);
+ iseq = proc->block.iseq;
+ if (BUILTIN_TYPE(iseq) == T_NODE || iseq->arg_block != -1) {

- if (BUILTIN_TYPE(proc->block.iseq) == T_NODE ||
- proc->block.iseq->arg_block != -1) {
-
if (rb_block_given_p()) {
rb_proc_t *proc;
VALUE procval;
@@ -620,10 +620,9 @@
return iseq;
}

-VALUE
-rb_proc_location(VALUE self)
+static VALUE
+iseq_location(rb_iseq_t *iseq)
{
- rb_iseq_t *iseq = get_proc_iseq(self);
VALUE loc[2];

if (!iseq) return Qnil;
@@ -639,6 +638,20 @@

/*
* call-seq:
+ * prc.source_location => [String, Fixnum]
+ *
+ * returns the ruby source filename and line number containing this proc
+ * or nil if this proc was not defined in ruby (i.e. native)
+ */
+
+VALUE
+rb_proc_source_location(VALUE self)
+{
+ return iseq_location(get_proc_iseq(self));
+}
+
+/*
+ * call-seq:
* prc == other_proc => true or false
*
* Return <code>true</code> if <i>prc</i> is the same object as
@@ -1437,7 +1450,40 @@
return rb_mod_method_arity(CLASS_OF(obj), id);
}

+static rb_iseq_t *
+get_method_iseq(VALUE method)
+{
+ struct METHOD *data;
+ NODE *body;
+ rb_iseq_t *iseq;
+
+ Data_Get_Struct(method, struct METHOD, data);
+ body = data->body;
+ switch (nd_type(body)) {
+ case RUBY_VM_METHOD_NODE:
+ GetISeqPtr((VALUE)body->nd_body, iseq);
+ if (RUBY_VM_NORMAL_ISEQ_P(iseq)) break;
+ default:
+ return 0;
+ }
+ return iseq;
+}
+
/*
+ * call-seq:
+ * meth.source_location => [String, Fixnum]
+ *
+ * returns the ruby source filename and line number containing this method
+ * or nil if this method was not defined in ruby (i.e. native)
+ */
+
+VALUE
+rb_method_source_location(VALUE method)
+{
+ return iseq_location(get_method_iseq(method));
+}
+
+/*
* call-seq:
* meth.to_s => string
* meth.inspect => string
@@ -1768,6 +1814,7 @@
rb_define_method(rb_cProc, "lambda?", proc_lambda_p, 0);
rb_define_method(rb_cProc, "binding", proc_binding, 0);
rb_define_method(rb_cProc, "curry", proc_curry, -1);
+ rb_define_method(rb_cProc, "source_location", rb_proc_source_location, 0);

/* Exceptions */
rb_eLocalJumpError = rb_define_class("LocalJumpError", rb_eStandardError);
@@ -1802,6 +1849,7 @@
rb_define_method(rb_cMethod, "name", method_name, 0);
rb_define_method(rb_cMethod, "owner", method_owner, 0);
rb_define_method(rb_cMethod, "unbind", method_unbind, 0);
+ rb_define_method(rb_cMethod, "source_location",
rb_method_source_location, 0);
rb_define_method(rb_mKernel, "method", rb_obj_method, 1);
rb_define_method(rb_mKernel, "public_method", rb_obj_public_method, 1);

@@ -1819,6 +1867,7 @@
rb_define_method(rb_cUnboundMethod, "name", method_name, 0);
rb_define_method(rb_cUnboundMethod, "owner", method_owner, 0);
rb_define_method(rb_cUnboundMethod, "bind", umethod_bind, 1);
+ rb_define_method(rb_cUnboundMethod, "source_location",
rb_method_source_location, 0);

/* Module#*_method */
rb_define_method(rb_cModule, "instance_method", rb_mod_instance_method, 1);
Index: thread.c
===================================================================
--- thread.c (revision 19438)
+++ thread.c (working copy)
@@ -528,10 +528,10 @@
}
GetThreadPtr(thread, th);
if (th->first_args) {
- VALUE rb_proc_location(VALUE self);
+ VALUE rb_proc_source_location(VALUE self);
VALUE proc = th->first_proc, line, loc;
const char *file;
- if (!proc || !RTEST(loc = rb_proc_location(proc))) {
+ if (!proc || !RTEST(loc = rb_proc_source_location(proc))) {
rb_raise(rb_eThreadError, "already initialized thread");
}
file = RSTRING_PTR(RARRAY_PTR(loc)[0]);
Nobuyoshi Nakada
2008-09-25 01:18:33 UTC
Permalink
Hi,

At Sun, 21 Sep 2008 03:49:50 +0900,
Post by Roger Pack
Anyway, here's Nobu Nakada's patch with the method name changed to
source_location [should work against SVN head].
Are you proposing the change of C functions names together?
--
Nobu Nakada
Roger Pack
2008-09-26 04:17:25 UTC
Permalink
Post by Nobuyoshi Nakada
Post by Roger Pack
Interestingly, there already was an rb_proc_location method in 1.9
[just no Proc#location nor Method#location nor Binding#location].
Anyway, here's Nobu Nakada's patch with the method name changed to
source_location [should work against SVN head].
Are you proposing the change of C functions names together?
Yeah I was thinking it would be less confusing to only have one
function name [source_location] and have it apply to both proc and
method.

Also note that it was mentioned that Binding#source_location would be
nice--I just have no idea how to add it so the current patch doesn't
include it.

Note also Feature #578: add method to disassemble Proc objects
Any feedback on having that added as well?

-=R
Nobuyoshi Nakada
2008-09-26 14:09:39 UTC
Permalink
Hi,

At Fri, 26 Sep 2008 13:17:25 +0900,
Post by Roger Pack
Post by Nobuyoshi Nakada
Are you proposing the change of C functions names together?
Yeah I was thinking it would be less confusing to only have one
function name [source_location] and have it apply to both proc and
method.
Meanwhile, I added the methods without changing the function
names. The names are another story.

# I've thought I'd committed it already, but forgotten.
Post by Roger Pack
Also note that it was mentioned that Binding#source_location would be
nice--I just have no idea how to add it so the current patch doesn't
include it.
What is the line number of Binding?
--
Nobu Nakada
Roger Pack
2008-09-26 16:19:37 UTC
Permalink
Post by Nobuyoshi Nakada
Post by Roger Pack
Yeah I was thinking it would be less confusing to only have one
function name [source_location] and have it apply to both proc and
method.
Meanwhile, I added the methods without changing the function
names. The names are another story.
# I've thought I'd committed it already, but forgotten.
Thanks for adding those. I see them in SVN now.
I prefer #source_location but #location is livable :)
Post by Nobuyoshi Nakada
Post by Roger Pack
Also note that it was mentioned that Binding#source_location would be
nice--I just have no idea how to add it so the current patch doesn't
include it.
What is the line number of Binding?
There isn't one in that patch. I'm unsure how to create Binding#source_location
Thanks!
-=R
Nobuyoshi Nakada
2008-09-26 18:25:19 UTC
Permalink
Hi,

At Sat, 27 Sep 2008 01:19:37 +0900,
Post by Roger Pack
Post by Nobuyoshi Nakada
Post by Roger Pack
Yeah I was thinking it would be less confusing to only have one
function name [source_location] and have it apply to both proc and
method.
Meanwhile, I added the methods without changing the function
names. The names are another story.
# I've thought I'd committed it already, but forgotten.
Thanks for adding those. I see them in SVN now.
I prefer #source_location but #location is livable :)
Methods are #source_location, C functions are still
*_location().
Post by Roger Pack
Post by Nobuyoshi Nakada
Post by Roger Pack
Also note that it was mentioned that Binding#source_location would be
nice--I just have no idea how to add it so the current patch doesn't
include it.
What is the line number of Binding?
There isn't one in that patch. I'm unsure how to create Binding#source_location
It's easy to implement, if it is OK to return the beginning of
the code block where the binding was made.


Index: proc.c
===================================================================
--- proc.c (revision 19593)
+++ proc.c (working copy)
@@ -29,4 +29,5 @@ static VALUE bmcall(VALUE, VALUE);
static int method_arity(VALUE);
static VALUE rb_obj_is_method(VALUE m);
+static VALUE iseq_location(rb_iseq_t *iseq);

/* Proc */
@@ -339,4 +340,22 @@ bind_eval(int argc, VALUE *argv, VALUE b
}

+/*
+ * call-seq:
+ * binding.source_location => [String, Fixnum]
+ *
+ * returns the ruby source filename and line number containing this binding
+ * or nil if this binding was not defined in ruby (i.e. native)
+ */
+VALUE
+rb_bind_location(VALUE self)
+{
+ rb_binding_t *bind;
+ rb_env_t *env;
+
+ GetBindingPtr(self, bind);
+ GetEnvPtr(bind->env, env);
+ return iseq_location(env->block.iseq);
+}
+
static VALUE
proc_new(VALUE klass, int is_lambda)
@@ -1923,4 +1942,5 @@ Init_Binding(void)
rb_define_method(rb_cBinding, "dup", binding_dup, 0);
rb_define_method(rb_cBinding, "eval", bind_eval, -1);
+ rb_define_method(rb_cBinding, "source_location", rb_bind_location, 0);
rb_define_global_function("binding", rb_f_binding, 0);
}
Index: ruby.c
===================================================================
--- ruby.c (revision 19593)
+++ ruby.c (working copy)
@@ -1478,4 +1478,5 @@ ruby_prog_init(void)

rb_define_global_const("ARGV", rb_argv);
+ rb_define_global_const("TOPLEVEL_BINDING", rb_binding_new());

#ifdef MSDOS
Index: vm.c
===================================================================
--- vm.c (revision 19594)
+++ vm.c (working copy)
@@ -1241,7 +1241,4 @@ rb_iseq_eval(VALUE iseqval)
vm_set_top_stack(th, iseqval);

- if (!rb_const_defined(rb_cObject, rb_intern("TOPLEVEL_BINDING"))) {
- rb_define_global_const("TOPLEVEL_BINDING", rb_binding_new());
- }
val = vm_exec(th);
tmp = iseqval; /* prohibit tail call optimization */
--
Nobu Nakada
Charles Oliver Nutter
2008-09-09 01:36:35 UTC
Permalink
Post by Yugui (Yuki Sonoda)
Hi all,
As announced before, Ruby 1.9.1 features will be frozen on 25 September.
After the time,
* Ruby level APIs must not changed.
* C level APIs will must not changed without discussion on
ruby-core/ruby-dev.
* All structures, data types, variables, functions and macros in
include/ruby/*.h are regarded as public C level APIs.
* Move it from include/ruby/*.h anything you want not to publish.
And I will create the ruby_1_9_1 branch and release 1.9.1 RC1 on 25
October. After the time,
* C level APIs will must not changed.
Also the C level APIs of 1.9.x must have backward binary-compatibility
to 1.9.1.
Is there a plan to gather a list of changes from Ruby 1.8.x at that
point? Some of those lists exist already, but I'm not sure they've
tracked trunk development. Once the feature freeze starts, we will begin
implementing 1.9 features in JRuby in earnest, so we're keen to get an
"official list" of what to do.

Where can I find an official list of 1.9 features/differences from 1.8?

- Charlie
Michael Fellinger
2008-09-12 05:14:07 UTC
Permalink
Post by Yugui (Yuki Sonoda)
Hi all,
As announced before, Ruby 1.9.1 features will be frozen on 25 September.
After the time,
* Ruby level APIs must not changed.
I was wondering about the syntax change from 1.8 to 1.9 regarding the
`[]` method

== The source
class Dictionary
def self.[](*args)
args
end
end

p Dictionary[1,2,3,]

== The results
=== For ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-linux]

[1, 2, 3]


=== For ruby 1.9.0 (2008-09-12 revision 19298) [i686-linux]

test.rb:7: syntax error, unexpected ']'

I'm not quite sure what the reason behind this change is, but it does
break some of my code between the two versions and it introduces a
syntactic differences between the syntax for array "[]" and "obj[]"
I would be glad if this could be clarified before set into stone.

Thanks in advance,
^ manveru
Post by Yugui (Yuki Sonoda)
* C level APIs will must not changed without discussion on
ruby-core/ruby-dev.
* All structures, data types, variables, functions and macros in
include/ruby/*.h are regarded as public C level APIs.
* Move it from include/ruby/*.h anything you want not to publish.
And I will create the ruby_1_9_1 branch and release 1.9.1 RC1 on 25
October. After the time,
* C level APIs will must not changed.
Also the C level APIs of 1.9.x must have backward binary-compatibility
to 1.9.1.
Regards,
Michael Neumann
2008-09-12 07:06:38 UTC
Permalink
Post by Michael Fellinger
Post by Yugui (Yuki Sonoda)
Hi all,
As announced before, Ruby 1.9.1 features will be frozen on 25 September.
After the time,
* Ruby level APIs must not changed.
I was wondering about the syntax change from 1.8 to 1.9 regarding the
`[]` method
== The source
class Dictionary
def self.[](*args)
args
end
end
p Dictionary[1,2,3,]
^^^

Are you sure this trailing "," is not the source of the syntax error?

Regards,

Michael
Michal Suchanek
2008-09-12 08:51:09 UTC
Permalink
Post by Michael Neumann
Post by Michael Fellinger
Post by Yugui (Yuki Sonoda)
Hi all,
As announced before, Ruby 1.9.1 features will be frozen on 25 September.
After the time,
* Ruby level APIs must not changed.
I was wondering about the syntax change from 1.8 to 1.9 regarding the
`[]` method
== The source
class Dictionary
def self.[](*args)
args
end
end
p Dictionary[1,2,3,]
^^^
Are you sure this trailing "," is not the source of the syntax error?
Disallowing that will also break stuff. And I will surely miss it. It
makes lists easier to modify - you can add and delete at the end as
well, not only in the middle.

Thanks

Michal
David A. Black
2008-09-12 12:36:03 UTC
Permalink
Hi --
Post by Michal Suchanek
Post by Michael Neumann
Post by Michael Fellinger
Post by Yugui (Yuki Sonoda)
Hi all,
As announced before, Ruby 1.9.1 features will be frozen on 25 September.
After the time,
* Ruby level APIs must not changed.
I was wondering about the syntax change from 1.8 to 1.9 regarding the
`[]` method
== The source
class Dictionary
def self.[](*args)
args
end
end
p Dictionary[1,2,3,]
^^^
Are you sure this trailing "," is not the source of the syntax error?
Disallowing that will also break stuff. And I will surely miss it. It
makes lists easier to modify - you can add and delete at the end as
well, not only in the middle.
You can still do this with array and hash constructors:

a = [1,2,3,4,] # etc.


David
--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL *
* Co-taught with Patrick Ewing!
See http://www.rubypal.com for details and updates!
Michal Suchanek
2008-09-12 12:57:53 UTC
Permalink
Post by Yugui (Yuki Sonoda)
Hi --
Post by Michal Suchanek
Post by Michael Neumann
Post by Michael Fellinger
Post by Yugui (Yuki Sonoda)
Hi all,
As announced before, Ruby 1.9.1 features will be frozen on 25
September.
Post by Michal Suchanek
Post by Michael Neumann
Post by Michael Fellinger
Post by Yugui (Yuki Sonoda)
After the time,
* Ruby level APIs must not changed.
I was wondering about the syntax change from 1.8 to 1.9 regarding the
`[]` method
== The source
class Dictionary
def self.[](*args)
args
end
end
p Dictionary[1,2,3,]
^^^
Are you sure this trailing "," is not the source of the syntax error?
Disallowing that will also break stuff. And I will surely miss it. It
makes lists easier to modify - you can add and delete at the end as
well, not only in the middle.
a = [1,2,3,4,] # etc.
Then it introduces a distinction between things that were previously
made look the same by choice of syntax. This looks bad in my view.

Thanks

Michal
Michael Fellinger
2008-09-13 05:41:22 UTC
Permalink
Post by Michal Suchanek
Then it introduces a distinction between things that were previously
made look the same by choice of syntax. This looks bad in my view.
That's the point i was trying to make, it doesn't give us any benefits either.

^ manveru
Yusuke ENDOH
2008-09-17 15:51:47 UTC
Permalink
Hi,
Post by Yugui (Yuki Sonoda)
As announced before, Ruby 1.9.1 features will be frozen on 25 September.
I'd like to confirm one thing; will the stardard libraries be also frozen?
I'm waiting rubygems to be upgraded ([ruby-core:18391], [ruby-core:18422]).
But if it will miss the deadline, must I wait for ruby 2.0 (or install
latest rubygems manually) ?
--
Yusuke ENDOH <***@tsg.ne.jp>
Michael Klishin
2008-09-17 16:41:33 UTC
Permalink
Post by Yusuke ENDOH
I'd like to confirm one thing; will the stardard libraries be also frozen?
I'm waiting rubygems to be upgraded ([ruby-core:18391], [ruby-core:18422]).
But if it will miss the deadline, must I wait for ruby 2.0 (or install
latest rubygems manually) ?
Next version of RubyGems, AFAIK, is gonna have some updates that reduce memory
consumption of any Ruby application that uses RubyGems. If possible,
it'd be great
to have that version in the standard library.
--
MK
Eric Hodel
2008-09-18 23:53:34 UTC
Permalink
Post by Michael Klishin
Post by Yusuke ENDOH
I'd like to confirm one thing; will the stardard libraries be also frozen?
18422]).
But if it will miss the deadline, must I wait for ruby 2.0 (or install
latest rubygems manually) ?
Next version of RubyGems, AFAIK, is gonna have some updates that reduce memory
consumption of any Ruby application that uses RubyGems. If possible,
it'd be great
to have that version in the standard library.
RubyGems in 1.9 already uses very little memory (gem_prelude.rb).
Eric Hodel
2008-09-18 23:53:54 UTC
Permalink
Post by Yusuke ENDOH
Post by Yugui (Yuki Sonoda)
As announced before, Ruby 1.9.1 features will be frozen on 25
September.
I'd like to confirm one thing; will the stardard libraries be also frozen?
18422]).
But if it will miss the deadline, must I wait for ruby 2.0 (or install
latest rubygems manually) ?
I plan on making the deadline.
Yusuke ENDOH
2008-09-20 15:40:43 UTC
Permalink
Hi,
Post by Eric Hodel
Post by Yusuke ENDOH
Post by Yugui (Yuki Sonoda)
As announced before, Ruby 1.9.1 features will be frozen on 25 September.
I'd like to confirm one thing; will the stardard libraries be also frozen?
I'm waiting rubygems to be upgraded ([ruby-core:18391],
[ruby-core:18422]).
But if it will miss the deadline, must I wait for ruby 2.0 (or install
latest rubygems manually) ?
I plan on making the deadline.
Great! I look forward to having it.
--
Yusuke ENDOH <***@tsg.ne.jp>
Yugui (Yuki Sonoda)
2008-09-24 09:38:33 UTC
Permalink
Hi, Yusuke
Post by Yusuke ENDOH
I'd like to confirm one thing; will the stardard libraries be also frozen?
The standard libraries will also be frozen.
If you have changes of some libraries or features, let me know it by
replying to this message by tomorrow and commit it as soon as possible.
Yusuke ENDOH
2008-09-24 10:17:45 UTC
Permalink
Hi,
Post by Yugui (Yuki Sonoda)
Hi, Yusuke
Post by Yusuke ENDOH
I'd like to confirm one thing; will the stardard libraries be also frozen?
The standard libraries will also be frozen.
If you have changes of some libraries or features, let me know it by
replying to this message by tomorrow and commit it as soon as possible.
Understand. Thank you.


Well, miniunit was added almost too late.

miniunit does not have enough experience with ruby 1.9. I guess we will
need not only bug fix but also discussion/improvement that may involve
change of behavior/specification.

For instance, I think readability of output of miniunit requires greater
consideration: use of pretty_inspect instead of inspect, appropriate line
feeds (when failure message is too long), etc.
In other instances, `assert_raise' is deprecated for unexplained reasons.
I think other issues will become clear during further use of miniunit.

So I would suggest postponing miniunit freeze until the end of Oct.
What do you think?
--
Yusuke ENDOH <***@tsg.ne.jp>
Ryan Davis
2008-09-25 07:48:27 UTC
Permalink
Post by Yusuke ENDOH
Well, miniunit was added almost too late.
yeah. sorry. I got bummed after proposing with approval then
reproposing and having it poo-poo'd (and eventually approved)... so I
took a break from it and then dropped the ball until the deadline was
announced.
Post by Yusuke ENDOH
miniunit does not have enough experience with ruby 1.9. I guess we will
need not only bug fix but also discussion/improvement that may involve
change of behavior/specification.
Actually I'd been using multiruby to test it to ensure it passed on
both 1.8 and 1.9. So in that sense it has experience. It only recently
blew up because of the encoding changes... But I suspect you mean more
with the 1.9 developers... THAT is absolutely true.
Post by Yusuke ENDOH
For instance, I think readability of output of miniunit requires greater
consideration: use of pretty_inspect instead of inspect, appropriate line
feeds (when failure message is too long), etc.
pretty_inspect vs inspect: speed. This had a HUGE impact. If you
override mu_pp(obj) you can change it as you deem appropriate. I
certainly plan to for my sexp/parser code, but won't elsewhere.

appropriate line feeds: I simply didn't think about it. All the code
I've been working on has HUGE output whether horizontal or vertical,
so I have to use unit_diff to make it readable at all... I assume this
mostly centers on your preference of pretty_inspect. Again, that can
be addressed via mu_pp. I think I like leaving it up to the user so
they can tweak as they deem appropriate. But I'm open to suggestions
here.
Post by Yusuke ENDOH
In other instances, `assert_raise' is deprecated for unexplained reasons.
I think other issues will become clear during further use of miniunit.
I just saw that Nobu rolled the undeprecated name from assert_raises
to assert_raise. Unfortunately the deprecation was NOT a typo and is
intentional. It is both a better English word choice and it is more
consistent with the other assertions (assert_includes, assert_throws,
etc).

I've rolled Nobu's change back, pending more dialog on the topic. My
preference is to have assert_raises and deprecate assert_raise.
Barring that, assert_raise could be an alias and stick around for
those folk who prefer it.
Post by Yusuke ENDOH
So I would suggest postponing miniunit freeze until the end of Oct.
What do you think?
I'm fine with that... tho I doubt it will need that much dialog tho...
We could probably set a freeze date 2-3 days after the next
implementors meeting. I'll attend that so we can get this stuff
resolved.

I'd like to simply say __Thank You__ to everyone who's given me
feedback both here and on the Seattle.rb list. I really do appreciate
it.
SASADA Koichi
2008-09-25 08:19:58 UTC
Permalink
Post by Ryan Davis
Post by Yusuke ENDOH
For instance, I think readability of output of miniunit requires greater
consideration: use of pretty_inspect instead of inspect, appropriate line
feeds (when failure message is too long), etc.
pretty_inspect vs inspect: speed. This had a HUGE impact. If you
override mu_pp(obj) you can change it as you deem appropriate. I
certainly plan to for my sexp/parser code, but won't elsewhere.
appropriate line feeds: I simply didn't think about it. All the code
I've been working on has HUGE output whether horizontal or vertical, so
I have to use unit_diff to make it readable at all... I assume this
mostly centers on your preference of pretty_inspect. Again, that can be
addressed via mu_pp. I think I like leaving it up to the user so they
can tweak as they deem appropriate. But I'm open to suggestions here.
That is one of the reasone why I proposed lazy message building.
Now we don't need more cost if the test succeeds.
Post by Ryan Davis
Post by Yusuke ENDOH
In other instances, `assert_raise' is deprecated for unexplained reasons.
I think other issues will become clear during further use of miniunit.
I just saw that Nobu rolled the undeprecated name from assert_raises to
assert_raise. Unfortunately the deprecation was NOT a typo and is
intentional. It is both a better English word choice and it is more
consistent with the other assertions (assert_includes, assert_throws, etc).
I've rolled Nobu's change back, pending more dialog on the topic. My
preference is to have assert_raises and deprecate assert_raise. Barring
that, assert_raise could be an alias and stick around for those folk who
prefer it.
I want to ask Matz about it (naming policy).
--
// SASADA Koichi at atdot dot net
Dave Thomas
2008-09-25 13:18:51 UTC
Permalink
Post by SASADA Koichi
Post by Ryan Davis
I've rolled Nobu's change back, pending more dialog on the topic. My
preference is to have assert_raises and deprecate assert_raise. Barring
that, assert_raise could be an alias and stick around for those folk who
prefer it.
I want to ask Matz about it (naming policy).
In this case, I agree with Ryan: assert_raises reads better.

I don't think I'd support assert_raise as an alias: mini/test is
already a big break with test unit, and there's no need to even
pretend to be compatible, so we may as well use the correct names.


Dave
SASADA Koichi
2008-09-25 13:28:39 UTC
Permalink
I don't think I'd support assert_raise as an alias: mini/test is already
a big break with test unit, and there's no need to even pretend to be
compatible, so we may as well use the correct names.
Don't break!! test/unit (using mini/test) should be compatible IMO.
--
// SASADA Koichi at atdot dot net
Dave Thomas
2008-09-25 13:41:37 UTC
Permalink
Post by SASADA Koichi
Don't break!! test/unit (using mini/test) should be compatible IMO.
It already isn't compatible. Matz made that decision when allowing it
in. So let's not carry past mistakes forward for compatibility reasons.


Dave
Jim Weirich
2008-09-25 13:59:30 UTC
Permalink
Post by Dave Thomas
Post by SASADA Koichi
Don't break!! test/unit (using mini/test) should be compatible IMO.
It already isn't compatible. Matz made that decision when allowing
it in. So let's not carry past mistakes forward for compatibility
reasons.
Does it make sense to have require 'test/unit' be a test/unit
compatible shim on top of mini/test? Then require 'mini/test' can use
all the improved nomenclature and techniques.
--
-- Jim Weirich
-- ***@gmail.com
SASADA Koichi
2008-09-25 14:09:16 UTC
Permalink
Post by Dave Thomas
Post by SASADA Koichi
Don't break!! test/unit (using mini/test) should be compatible IMO.
It already isn't compatible. Matz made that decision when allowing it
in. So let's not carry past mistakes forward for compatibility reasons.
Does it make sense to have require 'test/unit' be a test/unit compatible
shim on top of mini/test? Then require 'mini/test' can use all the
improved nomenclature and techniques.
+1

In fact I like mini/unit because of that short code, but there is
some compatibility/look issues.

I want to believe Ryan's post:
[ruby-core:17200] miniunit to replace test/unit in 1.9(?
I proposed replacing it with miniunit, which is 100% compatible on the test side (but not on the runner side).
--
// SASADA Koichi at atdot dot net
Dave Thomas
2008-09-25 14:12:04 UTC
Permalink
Post by Jim Weirich
Does it make sense to have require 'test/unit' be a test/unit
compatible shim on top of mini/test? Then require 'mini/test' can
use all the improved nomenclature and techniques.
A lot has been removed (the GUI, testsuites, and so on). I personally
don't miss any of that, annd don't feel that we need to reimplement
them in minitest.

But I'd 100% support adding back compatible assertions. If we did
that, though, minitest/unit should be self contained and have no
dependencies on test/unit: all dependencies should flow the other way.


Dave
Jim Weirich
2008-09-25 14:37:30 UTC
Permalink
Post by Dave Thomas
Post by Jim Weirich
Does it make sense to have require 'test/unit' be a test/unit
compatible shim on top of mini/test? Then require 'mini/test' can
use all the improved nomenclature and techniques.
A lot has been removed (the GUI, testsuites, and so on). I
personally don't miss any of that, annd don't feel that we need to
reimplement them in minitest.
Neither do I. But on the overlapping feature set, requiring 'test/
unit' should give the old assertion names.
Post by Dave Thomas
But I'd 100% support adding back compatible assertions. If we did
that, though, minitest/unit should be self contained and have no
dependencies on test/unit: all dependencies should flow the other way.
Agreed.

And I'd be happy to start targeting mini/test semantics. But it would
be nice to have the compatibility mode for stuff that lives in both
1.8 and 1.9 (e.g. rake).
--
-- Jim Weirich
-- ***@gmail.com
Ryan Davis
2008-09-25 18:49:01 UTC
Permalink
Post by Jim Weirich
Post by Dave Thomas
Post by SASADA Koichi
Don't break!! test/unit (using mini/test) should be compatible IMO.
It already isn't compatible. Matz made that decision when allowing
it in. So let's not carry past mistakes forward for compatibility
reasons.
Does it make sense to have require 'test/unit' be a test/unit
compatible shim on top of mini/test? Then require 'mini/test' can
use all the improved nomenclature and techniques.
That is EXACTLY what test/unit.rb is and it has been like that and
released for review for almost a year...

Yes... I'm frustrated (and pre-caffeine). Calibrate accordingly.
Dave Thomas
2008-09-25 18:52:37 UTC
Permalink
Post by Ryan Davis
Post by Jim Weirich
Does it make sense to have require 'test/unit' be a test/unit
compatible shim on top of mini/test? Then require 'mini/test' can
use all the improved nomenclature and techniques.
That is EXACTLY what test/unit.rb is and it has been like that and
released for review for almost a year...
Well, to be fair, it isn't really compatible.


Dave
Ryan Davis
2008-09-25 19:05:41 UTC
Permalink
Post by Dave Thomas
Post by Ryan Davis
Post by Jim Weirich
Does it make sense to have require 'test/unit' be a test/unit
compatible shim on top of mini/test? Then require 'mini/test' can
use all the improved nomenclature and techniques.
That is EXACTLY what test/unit.rb is and it has been like that and
released for review for almost a year...
Well, to be fair, it isn't really compatible.
where? I've done a lot to make sure that it is 100% compatible for
tests. It is NOT compatible with the old internals, and that is out of
scope for this project. We ensured that if that was a blocker that it
was taken care of by releasing test/unit as a gem.
Dave Thomas
2008-09-25 20:40:36 UTC
Permalink
Post by Ryan Davis
Post by Dave Thomas
Well, to be fair, it isn't really compatible.
where? I've done a lot to make sure that it is 100% compatible for
tests. It is NOT compatible with the old internals, and that is out
of scope for this project. We ensured that if that was a blocker
that it was taken care of by releasing test/unit as a gem.
It complains about the deprecation of many of the Test::Unit tests,
which kind of makes the running of existing tests very noisy. I guess
that, for me, compatible would mean a silent shoe-in.

Now, is it wrong to deprecate these tests? I don't think so. But I
think it is misleading from a programmer's point of view that the
interface to load the library is the same

require 'test/unit'

but the behavior is different.

I think I'd rather see minitest/unit as an entity in its own right. If
it is better, then people will just use it (and it has the added
advantage of being built-in). But folks who prefer Test::Unit will
still be able to 'require test/unit' (after installing the Gem) and
unambiguously run the old library.

My suggestion is not to do with the functionality. It's simply the
overloading of the require.


Dave
Jim Weirich
2008-09-25 19:10:22 UTC
Permalink
Post by Ryan Davis
Post by Jim Weirich
Does it make sense to have require 'test/unit' be a test/unit
compatible shim on top of mini/test? Then require 'mini/test' can
use all the improved nomenclature and techniques.
That is EXACTLY what test/unit.rb is and it has been like that and
released for review for almost a year...
Yes... I'm frustrated (and pre-caffeine). Calibrate accordingly.
Sorry for the frustration. I think I just realized you mean 100%
compatible except with deprecated warnings. I'm thinking that you
should drop the deprecated warning on each time the methods are
called. If you really must show a deprecated warning, show it once
when test/unit is loaded (but I'm thinking its not really needed there
either).
--
-- Jim Weirich
-- ***@gmail.com
Ryan Davis
2008-09-30 03:45:26 UTC
Permalink
Post by SASADA Koichi
I don't think I'd support assert_raise as an alias: mini/test is already
a big break with test unit, and there's no need to even pretend to be
compatible, so we may as well use the correct names.
Don't break!! test/unit (using mini/test) should be compatible IMO.
deprecation is NOT breaking... for a while:

tu_deprecate :assert_raise, :assert_raises #
2010-06-01

I'll remove it a LOOOONG time from now.
Jim Weirich
2008-09-30 04:31:21 UTC
Permalink
Post by Ryan Davis
tu_deprecate :assert_raise, :assert_raises #
2010-06-01
I'll remove it a LOOOONG time from now.
Are they deprecated in test/unit? Or in mini/test?

If they are really deprecated in test/unit then leave them.

If test/unit doesn't plan on deprecating them, then the notice should
not be displayed when mini/unit is masquerading as test/unit.
--
-- Jim Weirich
-- ***@gmail.com
Ryan Davis
2008-09-30 06:27:54 UTC
Permalink
Post by Jim Weirich
Post by Ryan Davis
tu_deprecate :assert_raise, :assert_raises #
2010-06-01
I'll remove it a LOOOONG time from now.
Are they deprecated in test/unit? Or in mini/test?
If they are really deprecated in test/unit then leave them.
If test/unit doesn't plan on deprecating them, then the notice
should not be displayed when mini/unit is masquerading as test/unit.
I think the main thing I've been learning from you and Dave is that
your (collective) perception of miniunit is vastly different than mine.

miniunit, in my mind, doesn't "masquerade" as test/unit... at least,
no more than any duck typing "masquerades" as the thing it is being
used as. It IS test/unit's mutated child and can be used in place of
test/unit... I just think of it as test/unit 2.0... it maintains full
backwards compatibility, for now, and later the deprecated stuff will
drop off, making it even lighter/better/happier.
Dave Thomas
2008-09-30 12:24:02 UTC
Permalink
Post by Ryan Davis
I think the main thing I've been learning from you and Dave is that
your (collective) perception of miniunit is vastly different than mine.
miniunit, in my mind, doesn't "masquerade" as test/unit... at least,
no more than any duck typing "masquerades" as the thing it is being
used as. It IS test/unit's mutated child and can be used in place of
test/unit... I just think of it as test/unit 2.0... it maintains
full backwards compatibility, for now, and later the deprecated
stuff will drop off, making it even lighter/better/happier.
Ryan:

I applaud your efforts here, and don't want you to feel in any way put
upon. I think personally I just want to advocate for the average user
migrating to Ruby 1.9.

For example, the deprecations are fine in theory. But think about how
tests are supposed to work. You run them, and they're supposed to be
silent. Maybe a row of dots, but that's it. Any output means there's a
problem.

But now, when I run my tests, I get pages of stuff flying by, saying
stuff is deprecated. To someone who lives by tests, this is incredibly
scary.

You might say "change your tests". But I think that's being a little
harsh. Part of being compatible with Test::Unit is providing a similar
user-level experience to it. A minor heart attack the first time you
run is a different experience.

What I'd love to do in PickAxe 3 is to tell people "switch from
Test::Unit to minitest/unit. You get cooler assertions and more speed.
If you want to user Test::Unit, then install the gem." You'd remove
test/ from lib, so there was no ambiguity, and you'd add autorunner to
minitest/unit, making it self contained. That way it would be 100%
clear that we're running something which is the next generation. It
would also free you from the shackles of having to be compatible.

I just don't see the downside to this, and I see a lot of benefits.



Dave
Ryan Davis
2008-10-08 07:05:08 UTC
Permalink
Post by Dave Thomas
For example, the deprecations are fine in theory. But think about
how tests are supposed to work. You run them, and they're supposed
to be silent. Maybe a row of dots, but that's it. Any output means
there's a problem.
I think it is a cultural problem. We don't have or even support a
culture of deprecation, of shedding dead weight. Somehow, the idea of
announcing ahead of time that you intend to delete code (with a
suitable replacement) _sometime_in_the_future_ sends shockwaves of
terror throughout the ruby community. Personally, I find that rather
embarrassing as I see nothing better than to reduce the amount of
cruft we have and still maintain functionality.
Post by Dave Thomas
But now, when I run my tests, I get pages of stuff flying by, saying
stuff is deprecated. To someone who lives by tests, this is
incredibly scary.
You might say "change your tests". But I think that's being a little
harsh. Part of being compatible with Test::Unit is providing a
similar user-level experience to it. A minor heart attack the first
time you run is a different experience.
Except... we're talking about a __DOT-OH__ release. If this was 1.6.9
I'd completely agree, but this is 1.9.0 and we've had no problems with
incompatibilities thus far. Think about the number of tests that are
going to fail that expect String#[n] to return an int that are now
going to blow up. Somehow that's OK, yet deprecating poorly named API
is not? No. Dot-Ohs are where we introduce our incompatibilities.

And in this case, we're not even talking actual breakage... that's the
thing that is killing me. We're talking about 100% compatible API,
telling you that you're going to need to change it in the future. I
even documented WHEN I was going to do this and nothing is even
remotely close (or etched in stone for that matter):

tu_deprecate :assert_nothing_thrown, :assert_nothing_raised #
2009-06-01
tu_deprecate :assert_raise, :assert_raises #
2010-06-01
tu_deprecate :assert_not_equal, :refute_equal #
2009-06-01
tu_deprecate :assert_no_match, :refute_match #
2009-06-01
tu_deprecate :assert_not_nil, :refute_nil #
2009-06-01
tu_deprecate :assert_not_same, :refute_same #
2009-06-01
def assert_nothing_raised _ = :ignored #
2009-06-01
def build_message(user_message, template_message, *args) #
2009-06-01

Yet, somehow, this is a huge thing that is totally freaking everyone
out. I just don't get it at all, esp. given how long this has been in
the works and how shockingly little feedback there was that whole time.
Austin Ziegler
2008-10-08 12:28:22 UTC
Permalink
Post by Dave Thomas
For example, the deprecations are fine in theory. But think about how
tests are supposed to work. You run them, and they're supposed to be silent.
Maybe a row of dots, but that's it. Any output means there's a problem.
I think it is a cultural problem. We don't have or even support a culture of
deprecation, of shedding dead weight. Somehow, the idea of announcing ahead
of time that you intend to delete code (with a suitable replacement)
_sometime_in_the_future_ sends shockwaves of terror throughout the ruby
community. Personally, I find that rather embarrassing as I see nothing
better than to reduce the amount of cruft we have and still maintain
functionality.
I don't agree on several levels. This isn't merely about saying that
you're going to delete code in the future. It's the level of output.
When I was deprecating a mistake in one of my libraries, I did so over
three versions. The first version printed a warning the very first
time a deprecated feature was used and not after that. The second
version printed a warning every time a deprecated feature was used.
The third version removed the feature.

The change that's here now prints a message every time.
Post by Dave Thomas
But now, when I run my tests, I get pages of stuff flying by, saying stuff
is deprecated. To someone who lives by tests, this is incredibly scary.
You might say "change your tests". But I think that's being a little
harsh. Part of being compatible with Test::Unit is providing a similar
user-level experience to it. A minor heart attack the first time you run is
a different experience.
Except... we're talking about a __DOT-OH__ release. If this was 1.6.9 I'd
completely agree, but this is 1.9.0 and we've had no problems with
incompatibilities thus far. Think about the number of tests that are going
to fail that expect String#[n] to return an int that are now going to blow
up. Somehow that's OK, yet deprecating poorly named API is not? No. Dot-Ohs
are where we introduce our incompatibilities.
You're the only person that I've seen claiming that "assert_not_*" is
poorly named *and* that "refute_*" is a better name. You might not
like arguing semantics, but you're making a semantic decision for the
rest of us. Personally, I don't even think it has to come down to
semantic distinctions, even though I've already made clear why I think
that "refute_*" fails the semantic test.

If I don't know the entire Ruby unit test API, but I know that
"assert_equal" exists, I can reasonably guess that a negative test
would be called "assert_not_equal" because of consistency in naming
conventions. Never in a million years would I guess "refute_*", even
for looking up the method in the documentation. How am I supposed to
find that negative assertions begin with "refute_*"?

String#[] isn't exactly a great choice for comparison: a lot of people
who are new to Ruby find the 1.8 behaviour disconcerting because
they're used to other languages. There's also a good reason for the
change: we're making Ruby far more functional. I'm not at all
convinced that "refute_*" is a more functional or more meaningful name
than "assert_not_*". I'm not likely to be convinced, either, since it
violates consistency of API.

(Just as a side note, because my day job has a lot of C++ in it, I've
surveyed most of the C++ unit test frameworks out there. Some of them
are pretty out there in terms of how they do things, but all of them,
including the newest one from Google, use some form of ASSERT_* and no
one uses REFUTE_*. By switching to refute_*, you're making it harder
for people to migrate from other languages to Ruby, with what I see as
no good reason.)
And in this case, we're not even talking actual breakage... that's the thing
that is killing me. We're talking about 100% compatible API, telling you
that you're going to need to change it in the future. I even documented WHEN
I was going to do this and nothing is even remotely close (or etched in
It's not 100% compatible if there's a warning thrown where there
didn't used to be -- especially if that warning is thrown on every
call on something as high-traffic as tests.

Martin Dürst suggested that, if you insist upon deprecating
assert_not_*, you only print the message once, matches my experience
with deprecating things in my own libraries. Next version, switch it
to printing on every use.
Yet, somehow, this is a huge thing that is totally freaking everyone out. I
just don't get it at all, esp. given how long this has been in the works and
how shockingly little feedback there was that whole time.
Maybe it's because I don't follow ruby-talk anymore (because of the
volume), but I had no reason or opportunity to play with miniunit,
much less a test/unit shim. I suspect that the answer for a lot of
people would be similar regarding reason and opportunity.

-austin
--
Austin Ziegler * ***@gmail.com * http://www.halostatue.ca/
* ***@halostatue.ca * http://www.halostatue.ca/feed/
* ***@zieglers.ca
Paul Brannan
2008-10-08 13:35:18 UTC
Permalink
Post by Austin Ziegler
If I don't know the entire Ruby unit test API, but I know that
"assert_equal" exists, I can reasonably guess that a negative test
would be called "assert_not_equal" because of consistency in naming
conventions. Never in a million years would I guess "refute_*", even
for looking up the method in the documentation. How am I supposed to
find that negative assertions begin with "refute_*"?
I would look for either assert_not_equal or assertNotEqual, because
that's what other xUnit-style testing frameworks use.

Paul
Pit Capitain
2008-10-08 14:38:35 UTC
Permalink
Post by Paul Brannan
Post by Austin Ziegler
How am I supposed to
find that negative assertions begin with "refute_*"?
I would look for either assert_not_equal or assertNotEqual, because
that's what other xUnit-style testing frameworks use.
I'm one of the many non-native-english-speaking users of Ruby, and I
didn't even know that the word "refute" existed at all.

Regards,
Pit
Jim Freeze
2008-10-08 15:12:46 UTC
Permalink
So, currently we have

assert_equal a == b # I assert that a equals b
assert_equal a != b # I assert that a does not equal b

So, is the new plan to move to

assert_equal a == b
refute_equal a == b # I assert not that a == b

If so, that is hard for me to parse.
A few examples I think would help me understand the exact proposal.
--
Jim Freeze
David A. Black
2008-10-08 15:16:07 UTC
Permalink
Hi --
Post by Jim Freeze
So, currently we have
assert_equal a == b # I assert that a equals b
assert_equal a != b # I assert that a does not equal b
It's:

assert_equal(a,b)
assert_not_equal(a,b)

which is similar to:

assert(a == b)
assert(a != b)
Post by Jim Freeze
So, is the new plan to move to
assert_equal a == b
refute_equal a == b # I assert not that a == b
If so, that is hard for me to parse.
A few examples I think would help me understand the exact proposal.
I think it would be:

refute_equal(a,b)

and so forth.


David
--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL *
* Co-taught with Patrick Ewing!
See http://www.rubypal.com for details and updates!
Jim Freeze
2008-10-08 15:33:40 UTC
Permalink
Uh, yeah. Thanks for correcting my method arguments David.
Post by David A. Black
Hi --
Post by Jim Freeze
So, currently we have
assert_equal a == b # I assert that a equals b
assert_equal a != b # I assert that a does not equal b
assert_equal(a,b)
assert_not_equal(a,b)
assert(a == b)
assert(a != b)
Post by Jim Freeze
So, is the new plan to move to
assert_equal a == b
refute_equal a == b # I assert not that a == b
If so, that is hard for me to parse.
A few examples I think would help me understand the exact proposal.
refute_equal(a,b)
and so forth.
David
--
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL *
* Co-taught with Patrick Ewing!
See http://www.rubypal.com for details and updates!
--
Jim Freeze
Radosław Bułat
2008-10-08 18:47:17 UTC
Permalink
Post by Pit Capitain
Post by Paul Brannan
Post by Austin Ziegler
How am I supposed to
find that negative assertions begin with "refute_*"?
I would look for either assert_not_equal or assertNotEqual, because
that's what other xUnit-style testing frameworks use.
I'm one of the many non-native-english-speaking users of Ruby, and I
didn't even know that the word "refute" existed at all.
I'm not native and I didn't know word "refute" too. assert_not_equal
is very easy to understand for most of people because it's assertion
(assert) and it's about negate (not) equality (equal). refute_equal is
bad because:
- for most of non-native speaker tells nothing
- it's new method in test-unit world

Ruby's api doesn't have to be poetry. Seriously.
--
Radosław Bułat
Jim Weirich
2008-09-30 18:47:18 UTC
Permalink
Post by Ryan Davis
I think the main thing I've been learning from you and Dave is that
your (collective) perception of miniunit is vastly different than mine.
miniunit, in my mind, doesn't "masquerade" as test/unit... at least,
no more than any duck typing "masquerades" as the thing it is being
used as. It IS test/unit's mutated child and can be used in place of
test/unit... I just think of it as test/unit 2.0... it maintains
full backwards compatibility, for now, and later the deprecated
stuff will drop off, making it even lighter/better/happier.
Sorry, "masquerade" carried more of a pejorative connotation than I
intended. I meant nothing more than "Duck Typing" at a library level.

I agreed with Dave ... the deprecated line noise is *highly*
annoying. Especially in a project that I intend to remain compatible
with test/unit (for the moment at least).

Can we:

(a) Get a way of switching off the deprecation notices (perhaps a
command line switch),

... or ...

(b) Reduce the deprecation notices to a single notice. I'm thinking
that a notice after all the tests have run saying something along the
lines of "the following deprecated methods have been used ..." would
convey the same information but not make the test output so visually
appalling.

Thanks for taking the burden of crafting a lighter, faster test
framework.
--
-- Jim Weirich
-- ***@gmail.com
Eric Hodel
2008-09-30 19:06:39 UTC
Permalink
Post by Jim Weirich
Post by Ryan Davis
I think the main thing I've been learning from you and Dave is that
your (collective) perception of miniunit is vastly different than mine.
miniunit, in my mind, doesn't "masquerade" as test/unit... at
least, no more than any duck typing "masquerades" as the thing it
is being used as. It IS test/unit's mutated child and can be used
in place of test/unit... I just think of it as test/unit 2.0... it
maintains full backwards compatibility, for now, and later the
deprecated stuff will drop off, making it even lighter/better/
happier.
Sorry, "masquerade" carried more of a pejorative connotation than I
intended. I meant nothing more than "Duck Typing" at a library level.
I agreed with Dave ... the deprecated line noise is *highly*
annoying. Especially in a project that I intend to remain
compatible with test/unit (for the moment at least).
(a) Get a way of switching off the deprecation notices (perhaps a
command line switch),
... or ...
(b) Reduce the deprecation notices to a single notice. I'm thinking
that a notice after all the tests have run saying something along
the lines of "the following deprecated methods have been used ..."
would convey the same information but not make the test output so
visually appalling.
Thanks for taking the burden of crafting a lighter, faster test
framework.
My experience with deprecating features from RubyGems leads me to
believe that the only way to make people change their code is to be as
visually appalling as possible. I announced that require_gem would be
removed in a reasonable amount of time and printed no warning
messages. Several months later require_gem added a warning, and
people got rather upset. Eventually I removed it altogether and
people were up in arms about their software breaking.

I believe I would have had better luck printing out five lines of
warning every time require_gem was used instead of just one. Printing
out only one line is not going to encourage many people to bring
themselves up to date. They'll just ignore the message and move on,
then complain loudly once the feature is removed despite being told
every day that they've been doing it wrong for several months.
Yukihiro Matsumoto
2008-09-25 16:02:52 UTC
Permalink
Hi,

In message "Re: [ruby-core:18889] Re: [ANN] Ruby 1.9.1 feature freeze"
on Thu, 25 Sep 2008 17:19:58 +0900, SASADA Koichi <***@atdot.net> writes:

|> I've rolled Nobu's change back, pending more dialog on the topic. My
|> preference is to have assert_raises and deprecate assert_raise. Barring
|> that, assert_raise could be an alias and stick around for those folk who
|> prefer it.
|
|I want to ask Matz about it (naming policy).

Basically, the method names in ruby use plain form if they are verbs.
Ruby is not English, nor Ruby does not belong to English speaking
people (although it uses a lot of English words).

If you want to change the basic rule, we should discuss before
changing it. Or choose alternative name like #assert_exception,
which I like better.

matz.
Paul Brannan
2008-09-26 13:55:18 UTC
Permalink
Post by Yukihiro Matsumoto
If you want to change the basic rule, we should discuss before
changing it. Or choose alternative name like #assert_exception,
which I like better.
#assert_exception is what RUNIT uses (which we still use where I work).

Paul
Ryan Davis
2008-09-30 03:49:07 UTC
Permalink
Post by Paul Brannan
Post by Yukihiro Matsumoto
If you want to change the basic rule, we should discuss before
changing it. Or choose alternative name like #assert_exception,
which I like better.
#assert_exception is what RUNIT uses (which we still use where I work).
*blink*

that's... terrifying.
Ryan Davis
2008-09-30 03:48:41 UTC
Permalink
Post by Yukihiro Matsumoto
Basically, the method names in ruby use plain form if they are verbs.
Ruby is not English, nor Ruby does not belong to English speaking
people (although it uses a lot of English words).
I don't think anyone has claimed that ruby is English or that in
belongs to anyone or anything... but where it uses English, it should
use the best English choice available. To be clear... I don't want
anything like applescript, I just want to be able to read my ruby and
have it feel right. I realize that is entirely subjective, but I think
there is a good middle ground we can find that works for all of us.
Yusuke ENDOH
2008-09-30 13:06:39 UTC
Permalink
Hi Ryan,
Post by Yukihiro Matsumoto
Basically, the method names in ruby use plain form if they are verbs.
Ruby is not English, nor Ruby does not belong to English speaking
people (although it uses a lot of English words).
I don't think anyone has claimed that ruby is English or that in belongs to
anyone or anything...
matz said: ``Basically, the method names in ruby use plain form if
they are verbs.'' Why is only assert_raises an exception?
but where it uses English, it should use the best
English choice available.
I guess this thought is ``Ruby belongs to English speaking people.''

assert_raise is a mere method in the standard library of ruby. So I
think it should respect the basis of ruby unless there is a compelling
reason.


Especially about assert_raise, in test/unit, assert_raises is deprecated
and assert_raise is provided instead. Reversing them is too confusing
to me. If you want to deprecate assert_raise by any means, I think you
must suggest a new name that is neither assert_raise nor assert_raises.


Now, the most important problem is the fact that we have little time to
disscuss it. We must decide it ASAP. But according to my experience,
method name problems do often need long time.

I think that the suggestion that changes assert_raise was too late and
missed 1.9 freeze deadline.
--
Yusuke ENDOH <***@tsg.ne.jp>
Yusuke ENDOH
2008-10-07 14:31:33 UTC
Permalink
Post by Yusuke ENDOH
Hi Ryan,
Post by Yukihiro Matsumoto
Basically, the method names in ruby use plain form if they are verbs.
Ruby is not English, nor Ruby does not belong to English speaking
people (although it uses a lot of English words).
I don't think anyone has claimed that ruby is English or that in belongs to
anyone or anything...
matz said: ``Basically, the method names in ruby use plain form if
they are verbs.'' Why is only assert_raises an exception?
but where it uses English, it should use the best
English choice available.
I guess this thought is ``Ruby belongs to English speaking people.''
assert_raise is a mere method in the standard library of ruby. So I
think it should respect the basis of ruby unless there is a compelling
reason.
Especially about assert_raise, in test/unit, assert_raises is deprecated
and assert_raise is provided instead. Reversing them is too confusing
to me. If you want to deprecate assert_raise by any means, I think you
must suggest a new name that is neither assert_raise nor assert_raises.
Now, the most important problem is the fact that we have little time to
disscuss it. We must decide it ASAP. But according to my experience,
method name problems do often need long time.
I think that the suggestion that changes assert_raise was too late and
missed 1.9 freeze deadline.
We seem to get a little time to discuss this.

I still think that assert_raises is confusing and that another name is better.
--
Yusuke ENDOH <***@tsg.ne.jp>
James Gray
2008-09-25 09:46:34 UTC
Permalink
Post by Ryan Davis
Post by Yusuke ENDOH
In other instances, `assert_raise' is deprecated for unexplained reasons.
I think other issues will become clear during further use of
miniunit.
I just saw that Nobu rolled the undeprecated name from assert_raises
to assert_raise. Unfortunately the deprecation was NOT a typo and is
intentional. It is both a better English word choice and it is more
consistent with the other assertions (assert_includes,
assert_throws, etc).
I've rolled Nobu's change back, pending more dialog on the topic. My
preference is to have assert_raises and deprecate assert_raise.
Barring that, assert_raise could be an alias and stick around for
those folk who prefer it.
I agree. assert_raise() has always bothered me, grammar wise.

James Edward Gray II
daz
2008-09-25 10:33:54 UTC
Permalink
Post by Ryan Davis
I just saw that Nobu rolled the undeprecated name from assert_raises to
assert_raise. Unfortunately the deprecation was NOT a typo and is
intentional. It is both a better English word choice and it is more
consistent with the other assertions (assert_includes, assert_throws, etc).
Respect for defending the English language, Ryan, but this is Ruby.

Note this oddity in English grammar:

1) It [singular] raises.
2) They [plural] raise.

http://www.edufind.com/ENGLISH/GRAMMAR/Tenses2.cfm

------

Also, one definition of 'assert' is 'insist upon'.
Assert is insisting upon a single raise, not a group of raises
so why should it need to look like a plural noun rather than
what it is - a singular noun or a verb used from a singular
perspective?

Yes, it's contentious but the Ruby convention isn't without merit.

a = [ "a", "b", "c" ]
a.include?("b") # true
a.include?("z") # false
a.includes?("b")

rb172.tmp:4: undefined method `includes?' for ["a", "b", "c"]:Array
(NoMethodError)
Post by Ryan Davis
I've rolled Nobu's change back, pending more dialog on the topic. My
preference is to have assert_raises and deprecate assert_raise. Barring
that, assert_raise could be an alias and stick around for those folk who
prefer it.
I understand and may agree with your preference from an English
perspective only but, in Ruby, I'm used to expecting:

assert_raise
assert_include
assert_throw
etc.

(No aliases)


Swallow hard and ignore English unless absolutely necessary :)

Thanks for your work.


daz
Ryan Davis
2008-09-25 18:49:25 UTC
Permalink
Post by daz
Respect for defending the English language, Ryan, but this is Ruby.
1) It [singular] raises.
2) They [plural] raise.
We're talking about assertions in unit tests here. There is never a
plural subject.

assert_raises reads correctly for both singular and multiple arguments:

assert (that it) raises (a) SyntaxError.
assert (that it) raises (one of) SyntaxError or ArgumentError.
Meinrad Recheis
2008-09-30 13:58:33 UTC
Permalink
Post by daz
Respect for defending the English language, Ryan, but this is Ruby.
Post by daz
1) It [singular] raises.
2) They [plural] raise.
We're talking about assertions in unit tests here. There is never a plural
subject.
assert (that it) raises (a) SyntaxError.
assert (that it) raises (one of) SyntaxError or ArgumentError.
it depends entirely how you imagine the "missing" words. one could also read
it like this:

assert (the block to) raise (an) Exception

This is, of course, absurd. What I am trying to say is that we should read
method names as artificial commands and not as abbreviated English
sentences. I'd prefer assert_exception over assert_raise and that over
assert_raises.

-- henon
Trans
2008-09-30 15:03:06 UTC
Permalink
Post by Meinrad Recheis
 Respect for defending the English language, Ryan, but this is Ruby.
 1) It [singular] raises.
 2) They [plural] raise.
We're talking about assertions in unit tests here. There is never a plural
subject.
assert (that it) raises (a) SyntaxError.
assert (that it) raises (one of) SyntaxError or ArgumentError.
it depends entirely how you imagine the "missing" words. one could also read
assert (the block to) raise (an) Exception
This is, of course, absurd. What I am trying to say is that we should read
method names as artificial commands and not as abbreviated English
sentences. I'd prefer assert_exception over assert_raise and that over
assert_raises.
OMG! Just leave it alone. I don't want to have to fix my tests over
something so pedantic.

T.
Bill Kelly
2008-09-24 10:18:34 UTC
Permalink
Post by Yugui (Yuki Sonoda)
Post by Yusuke ENDOH
I'd like to confirm one thing; will the stardard libraries be also frozen?
The standard libraries will also be frozen.
If you have changes of some libraries or features, let me know it by
replying to this message by tomorrow and commit it as soon as possible.
Before it's too late, I wanted to plead for the possibility
of restoring the enumerator behavior David Black describes
below:


From: "David A. Black" <***@rubypal.com>
To: "ruby-talk ML" <ruby-***@ruby-lang.org>
Sent: Friday, September 12, 2008 4:37 PM
Subject: Re: Advanced conditionals
Post by Yugui (Yuki Sonoda)
Post by Yusuke ENDOH
irb(main):007:0> a = [1,2,3,4]
=> [1, 2, 3, 4]
irb(main):008:0> e = a.enum_for(:map, &lambda {|x| x * 10 })
=> #<Enumerable::Enumerator:0x3d7444>
irb(main):009:0> e.next
=> 10
You'll get 1 now, rather than 10. I'm still very puzzled by the
removal of this capability.
Maybe worth asking on ruby-core? Still 13 days till the
feature freeze...!
I did. Shugo did discuss it some, but I'm afraid I still didn't
understand, or maybe I just wasn't convinced. I think it probably
boils down to efficiency, though it seems to me to be an example of
something so powerful and potentially useful that efficiency wouldn't
(up to a point) be a deal-breaker.
It seems to me like one of those great features where ruby
pleasently surprises you by doing what you expected.

Matz, et al: Is there no possibility to retain this behavior?


Thanks for your consideration,

Bill
Martin Duerst
2008-09-24 10:29:07 UTC
Permalink
I can understand that you want to move on, and delaying things
is not a good idea.

On the other hand, as we have recently seen just with CSV,
most libraries are not at all up to speed with character encodings,
and this means that there is a high risk that Ruby 1.9.1 will
be perceived as a big problem because the libraries run into
all kinds of problems.

So I would be okay with a general feature freeze for libraries,
but not if changes are needed related to internationalization
(which may or may not result in changes (additions) to the
interface).


Regards, Martin.
Post by Yugui (Yuki Sonoda)
Hi, Yusuke
Post by Yusuke ENDOH
I'd like to confirm one thing; will the stardard libraries be also frozen?
The standard libraries will also be frozen.
If you have changes of some libraries or features, let me know it by
replying to this message by tomorrow and commit it as soon as possible.
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:***@it.aoyama.ac.jp
James Gray
2008-09-24 13:03:02 UTC
Permalink
Post by Martin Duerst
So I would be okay with a general feature freeze for libraries,
but not if changes are needed related to internationalization
(which may or may not result in changes (additions) to the
interface).
Yeah, I would love to see more libraries get encoding savvy before
release, though I realize that may not happen.

James Edward Gray II
Dave Thomas
2008-09-24 13:23:24 UTC
Permalink
Post by James Gray
Yeah, I would love to see more libraries get encoding savvy before
release, though I realize that may not happen.
Well, with features frozen, more effort can now go into internals.


Dave
Eric Hodel
2008-09-24 18:49:14 UTC
Permalink
Post by Yugui (Yuki Sonoda)
Post by Yusuke ENDOH
I'd like to confirm one thing; will the stardard libraries be also frozen?
The standard libraries will also be frozen.
If you have changes of some libraries or features, let me know it by
replying to this message by tomorrow and commit it as soon as
possible.
I will commit RubyGems and RDoc tonight (Pacific Time).
NARUSE, Yui
2008-10-02 23:01:29 UTC
Permalink
Hi,

How about reconsidering the feature freeze plan.
Post by Yugui (Yuki Sonoda)
As announced before, Ruby 1.9.1 features will be frozen on 25 September.
After the time,
* Ruby level APIs must not changed.
* C level APIs will must not changed without discussion on
ruby-core/ruby-dev.
* All structures, data types, variables, functions and macros in
include/ruby/*.h are regarded as public C level APIs.
* Move it from include/ruby/*.h anything you want not to publish.
And I will create the ruby_1_9_1 branch and release 1.9.1 RC1 on 25
October. After the time,
* C level APIs will must not changed.
Also the C level APIs of 1.9.x must have backward binary-compatibility
to 1.9.1.
When this plan is decided in July, it was based on the assumption that
most feature of Ruby 1.9 was already fixed and we could spend time to
make ruby stable.

However, Ruby is still changing now and near future.
This is because
* Ruby 1.9 haven't used in large applications yet.
* too radical changes of some libraries
We need more review to Ruby core and libraries.
This gap is enough to break the assumption.

So how about reconsidering the feature freeze plan.
But continual release is important for feedbacks.

My new plan is,
* Ruby 1.9.1 will be released in 2008-12-25.
* Ruby 1.9.1 doesn't assure ABI Compatibility to future Ruby 1.9 series.
* Ruby 1.9.2 may break compatibility to 1.9.1
if the change is allowed by people and matz and yugui.
--
NARUSE, Yui <***@airemix.jp>
Dave Thomas
2008-10-02 23:16:44 UTC
Permalink
Post by NARUSE, Yui
However, Ruby is still changing now and near future.
Ruby will always be changing. That's _why_ a freeze is needed... :)


Dave
David Flanagan
2008-10-03 04:01:10 UTC
Permalink
Post by NARUSE, Yui
So how about reconsidering the feature freeze plan.
But continual release is important for feedbacks.
My new plan is,
* Ruby 1.9.1 will be released in 2008-12-25.
* Ruby 1.9.1 doesn't assure ABI Compatibility to future Ruby 1.9 series.
* Ruby 1.9.2 may break compatibility to 1.9.1
if the change is allowed by people and matz and yugui.
I think that this would effectively make Ruby 1.9 back into an
odd-numbered development release like 1.7, and everyone will just wait
for 2.0 before migrating from 1.8

David Flanagan
Austin Ziegler
2008-10-03 04:35:12 UTC
Permalink
Post by David Flanagan
Post by NARUSE, Yui
So how about reconsidering the feature freeze plan.
But continual release is important for feedbacks.
My new plan is,
* Ruby 1.9.1 will be released in 2008-12-25.
* Ruby 1.9.1 doesn't assure ABI Compatibility to future Ruby 1.9 series.
* Ruby 1.9.2 may break compatibility to 1.9.1
if the change is allowed by people and matz and yugui.
I think that this would effectively make Ruby 1.9 back into an
odd-numbered development release like 1.7, and everyone will just wait
for 2.0 before migrating from 1.8
Is that necessarily a bad thing?

-austin
--
Austin Ziegler * ***@gmail.com * http://www.halostatue.ca/
* ***@halostatue.ca * http://www.halostatue.ca/feed/
* ***@zieglers.ca
Dave Thomas
2008-10-03 13:46:34 UTC
Permalink
Post by Austin Ziegler
Is that necessarily a bad thing?
Yes: most of the last minute issues folks are discussing now are
because there weren't many people using 1.9. Most of the
default_internal discussion was brought about because JEG actually
tried to write something using the new encoding scheme. Similarly, the
miniunit discussions all came about because suddenly people were made
to use it in the 1.9 tree.

One of the fundamental drivers behind agility is feedback. When the
"experimental" branches are sequestered away like this, the number of
people using the new release is small, and the feedback you get is
poor. As a result, the developers tend to tinker in something of a
vacuum. The release gets bigger and bigger, and the differences
between the new and the old get greater and greater. Then, when you do
finally drop the new 2.0, people will feel there's such a major
difference they will be reluctant to change.

I think the discipline of frequent, fixed freezes and releases can
only help the language development process. I'm disappointed that this
latest freeze has become slushy.



Dave
Austin Ziegler
2008-10-03 14:37:55 UTC
Permalink
Post by Austin Ziegler
Is that necessarily a bad thing?
Yes: most of the last minute issues folks are discussing now are because
there weren't many people using 1.9. [...]
One of the fundamental drivers behind agility is feedback. When the
"experimental" branches are sequestered away like this, the number of people
using the new release is small, and the feedback you get is poor. As a
result, the developers tend to tinker in something of a vacuum. The release
gets bigger and bigger, and the differences between the new and the old get
greater and greater. Then, when you do finally drop the new 2.0, people will
feel there's such a major difference they will be reluctant to change.
I'm sympathetic to this, but I'm also sympathetic to the fact that
sometimes freezes like this are dangerous to future migrations, too.
At work, we're *still* dealing with the fallout of several bad
technology decisions made years ago.

If we want 1.9.1 to be a binary API feature freeze, why don't we push
the release date back, rather than pushing the binary API feature
freeze back a version?

-austin
--
Austin Ziegler * ***@gmail.com * http://www.halostatue.ca/
* ***@halostatue.ca * http://www.halostatue.ca/feed/
* ***@zieglers.ca
Dave Thomas
2008-10-03 15:36:15 UTC
Permalink
Post by Austin Ziegler
If we want 1.9.1 to be a binary API feature freeze, why don't we push
the release date back, rather than pushing the binary API feature
freeze back a version?
I know what you're saying. But I'm also seeing a process that
seemingly has no end. I worry that we're falling into the Mr Creosote
syndrome—just one more wafer-thin change.


Dave
Trans
2008-10-03 16:32:06 UTC
Permalink
Yes: most of the last minute issues folks are discussing now are  
because there weren't many people using 1.9. Most of the  
default_internal discussion was brought about because JEG actually  
tried to write something using the new encoding scheme. Similarly, the  
miniunit discussions all came about because suddenly people were made  
to use it in the 1.9 tree.
One of the fundamental drivers behind agility is feedback. When the  
"experimental" branches are sequestered away like this, the number of  
people using the new release is small, and the feedback you get is  
poor. As a result, the developers tend to tinker in something of a  
vacuum. The release gets bigger and bigger, and the differences  
between the new and the old get greater and greater. Then, when you do  
finally drop the new 2.0, people will feel there's such a major  
difference they will be reluctant to change.
I think the discipline of frequent, fixed freezes and releases can  
only help the language development process. I'm disappointed that this  
latest freeze has become slushy.
It would help if 1.8.7 was for real, as it is intended to provide some
of the features of 1.9 while being essentially backward compatible
with 1.8.6. Actually, I think a lot of us would agree, 1.8.7 ought to
have been 1.9. That would have allowed it a little more flexibility in
migrating us to the current version which has many changes. But that
of course would force the current 1.9 version to 1.10 which isn't
liked... Are we being stymied by version number ideals?

Taking a step back might not be a bad idea. Consider how poorly this
transition is going compared to the transition from 1.6 to 1.8.

T.
Yugui (Yuki Sonoda)
2008-10-03 05:37:01 UTC
Permalink
Hi,
Post by NARUSE, Yui
When this plan is decided in July, it was based on the assumption that
most feature of Ruby 1.9 was already fixed and we could spend time to
make ruby stable.
OK. In these several days, I understood how dynamically Ruby is changing
and that Ruby needs more changes for 1.9.x series.
Post by NARUSE, Yui
My new plan is,
* Ruby 1.9.1 will be released in 2008-12-25.
* Ruby 1.9.1 doesn't assure ABI Compatibility to future Ruby 1.9 series.
* Ruby 1.9.2 may break compatibility to 1.9.1
if the change is allowed by people and matz and yugui.
In addition, I heard that some features will break the binary
compatibility, especially MVM.

We need to rebuild the plan for release and compatibility of 1.9.x.

(1) I'll release 1.9.0-5 tonight.
(2) We aim to release 1.9.1 on 20 Dec.
(3) After 1.9.0-5 will be released, you can change the explicitly
claimed features by 25 Oct.
I heard
* default_internal
* miniunit (I reverted it, but I'll recover it after the release of
1.9.0-5)
* cgi.rb
* adding encodings
* Anything M17N-releated - I think some of standard libraries need to
be changed for more supporting M17N.

If you have another feature to be changed, claim it immediately.

(4) I will remove supports for the following platforms.
* human68k
* djgpp
* Classic MacOS
* WinCE
* VMS
But always welcome a patch for supporting these platforms.

(5) I will create ruby_1_9_1 branch on 25 Oct.
(6) I will release Ruby 1.9.1 Preview Release-1 on 25 Oct.
(7) After the branch created, you can change features at trunk.

(8) When a new feature or a feature change breaks backward
compatibility, the change must satisfy the following conditions.
* It must be discussed at ruby-core, ruby-dev.
* Matz allows it.
* yugui allows it.

Thanks.
--
Yugui (Yuki Sonoda) <***@yugui.jp>
http://yugui.jp
Martin Duerst
2008-10-03 09:08:15 UTC
Permalink
Post by Yugui (Yuki Sonoda)
We need to rebuild the plan for release and compatibility of 1.9.x.
(1) I'll release 1.9.0-5 tonight.
Great! I hope everything will go fine.
Post by Yugui (Yuki Sonoda)
(2) We aim to release 1.9.1 on 20 Dec.
(5) I will create ruby_1_9_1 branch on 25 Oct.
(6) I will release Ruby 1.9.1 Preview Release-1 on 25 Oct.
What is the current plan for releases between 25 Oct. and
20 Dec.
Post by Yugui (Yuki Sonoda)
(7) After the branch created, you can change features at trunk.
(8) When a new feature or a feature change breaks backward
compatibility, the change must satisfy the following conditions.
* It must be discussed at ruby-core, ruby-dev.
Does this mean it has to be discussed at both mailing list,
or at one of them? Given current practice, I would assume
the later.


Regards, Martin.



#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:***@it.aoyama.ac.jp
Loading...