Ruby Forum Ruby-core > [ANN] Ruby 1.9.1 feature freeze

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@yugui.jp>

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.

Hi,

Rocky Bernstein wrote:
> 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.

Yugui (Yuki Sonoda) wrote:
>    * Move it from include/ruby/*.h anything you want not to publish.
>
> -- Yuki Sonoda (Yugui) <yugui@yugui.jp>
>
>
>   
Matz,

Will absolute_path() make it into this release??

Chuck

On Sep 2, 2008, at 2:28 PM, C.E. Thornton wrote:

> Will absolute_path() make it into this release??

It's in HEAD right now


Dave

Dave Thomas wrote:
>
Opps -- Sorry Dave, I didn't look at HEAD!
Chuck

Yugui (Yuki Sonoda) wrote:
>    * 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

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


On Mon, Sep 8, 2008 at 3:36 AM, Yukihiro Matsumoto <matz@ruby-lang.org> 
wrote:
> |I propose a new method, #location than those two new methods.
>
> I like the idea.  How others think?
>
>                                                        matz.
>
>



--
Thanks!
-=R

On 9/8/08, Roger Pack <rogerpack2005@gmail.com> wrote:
>  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.

Wilson Bilkovich wrote:
> 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

> 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

>> p = proc { |n| n + 2 }
=> #<Proc:...>
>> 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

On Wed, Sep 10, 2008 at 03:21:20AM +0900, Roger Pack wrote:
> >> 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

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

On Tue, Sep 2, 2008 at 3:09 PM, Yugui (Yuki Sonoda) <yugui@yugui.jp> 
wrote:
> 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

Michael Fellinger schrieb:
> 
> == 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

On 12/09/2008, Michael Neumann <mneumann@ntecs.de> wrote:
> > >  * Ruby level APIs must not changed.
> >  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

Hi --

On Fri, 12 Sep 2008, Michal Suchanek wrote:

>>>> After the time,
>>>    end
> 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

On 12/09/2008, David A. Black <dblack@rubypal.com> wrote:
> > >
> > > > >
> > > >   def self.[](*args)
> > >  Are you sure this trailing "," is not the source of the syntax error?
>  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

On Fri, Sep 12, 2008 at 9:57 PM, Michal Suchanek <hramrach@centrum.cz> 
wrote:
> 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

> 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);
 }

Hi,

2008/9/2 Yugui (Yuki Sonoda) <yugui@yugui.jp>:
> 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) ?

2008/9/17 Yusuke ENDOH <mame@tsg.ne.jp>:
> 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.

On Sep 17, 2008, at 09:41 AM, Michael Klishin wrote:
> 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).

On Sep 17, 2008, at 08:51 AM, Yusuke ENDOH wrote:
> 2008/9/2 Yugui (Yuki Sonoda) <yugui@yugui.jp>:
>> 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.

Hi,

2008/9/19 Eric Hodel <drbrain@segment7.net>:
>> latest rubygems manually) ?
>
> I plan on making the deadline.

Great!  I look forward to having it.

Hi, Yusuke

Yusuke ENDOH wrote:
> 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.

Hi,

2008/9/24 Yugui (Yuki Sonoda) <yugui@yugui.jp>:
> Hi, Yusuke
>
> Yusuke ENDOH wrote:
>> 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?

From: "Yugui (Yuki Sonoda)" <yugui@yugui.jp>
>
> Yusuke ENDOH wrote:
>> 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" <dblack@rubypal.com>
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Friday, September 12, 2008 4:37 PM
Subject: Re: Advanced conditionals
>>> => #<Enumerable::Enumerator:0x3d7444>
> 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

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.


At 18:38 08/09/24, Yugui (Yuki Sonoda) wrote:
>Hi, Yusuke
>
>Yusuke ENDOH wrote:
>> 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:duerst@it.aoyama.ac.jp

On Sep 24, 2008, at 5:29 AM, Martin Duerst wrote:

> 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

On Sep 24, 2008, at 8:03 AM, James Gray wrote:

> 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

On Sep 24, 2008, at 02:38 AM, Yugui (Yuki Sonoda) wrote:
> Yusuke ENDOH wrote:
>> 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).

On Sep 24, 2008, at 03:17 , Yusuke ENDOH wrote:

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

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

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

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

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

Ryan Davis wrote:
> 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.


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

On Sep 25, 2008, at 2:48 AM, Ryan Davis wrote:

> 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

Ryan Davis wrote:
> 
> 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)


> 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

On Sep 25, 2008, at 3:19 AM, SASADA Koichi wrote:

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

Dave Thomas wrote:
> 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.

On Sep 25, 2008, at 8:28 AM, SASADA Koichi wrote:

> 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

On Sep 25, 2008, at 9:41 AM, Dave Thomas wrote:

> On Sep 25, 2008, at 8:28 AM, SASADA Koichi wrote:
>
>> 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.

On Sep 25, 2008, at 8:59 AM, Jim Weirich wrote:

> 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 wrote:
> 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(?

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

On Sep 25, 2008, at 10:12 AM, Dave Thomas wrote:

>
> On Sep 25, 2008, at 8:59 AM, Jim Weirich wrote:
>
>> 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.

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

On Sep 25, 2008, at 06:59 , Jim Weirich wrote:

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

On Sep 25, 2008, at 03:33 , daz wrote:

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

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.

On Sep 25, 2008, at 1:49 PM, Ryan Davis wrote:
>> 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

On Sep 25, 2008, at 11:52 , Dave Thomas wrote:

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

On Sep 25, 2008, at 2:49 PM, Ryan Davis wrote:

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

On Sep 25, 2008, at 2:05 PM, Ryan Davis wrote:

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

On Fri, Sep 26, 2008 at 01:02:52AM +0900, Yukihiro Matsumoto wrote:
> 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

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

> Nobuyoshi Nakada wrote:
> 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

Hi,

At Fri, 26 Sep 2008 13:17:25 +0900,
Roger Pack wrote in [ruby-core:18970]:
> > Nobuyoshi Nakada wrote:
> > 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.

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

>> 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 :)

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

Hi,

At Sat, 27 Sep 2008 01:19:37 +0900,
Roger Pack wrote in [ruby-core:18981]:
> I prefer #source_location but #location is livable :)
Methods are #source_location, C functions are still
*_location().

> >> 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 */

On Sep 25, 2008, at 06:28 , SASADA Koichi wrote:

> Dave Thomas wrote:
>> 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.

On Sep 25, 2008, at 09:02 , Yukihiro Matsumoto wrote:

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

On Sep 26, 2008, at 06:55 , Paul Brannan wrote:

> On Fri, Sep 26, 2008 at 01:02:52AM +0900, Yukihiro Matsumoto wrote:
>> 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.

On Sep 29, 2008, at 11:45 PM, Ryan Davis wrote:

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

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.

On Sep 29, 2008, at 21:31 , Jim Weirich wrote:

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

On Sep 30, 2008, at 1:27 AM, Ryan Davis wrote:

> 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

Hi Ryan,

2008/9/30 Ryan Davis <ryand-ruby@zenspider.com>:
>
> On Sep 25, 2008, at 09:02 , Yukihiro Matsumoto wrote:
>
>> 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.

On Thu, Sep 25, 2008 at 8:49 PM, Ryan Davis 
<ryand-ruby@zenspider.com>wrote:

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

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

On Sep 30, 9:58 am, "Meinrad Recheis" <meinrad.rech...@gmail.com>
wrote:
> >> Note this oddity in English grammar:
> > 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.

OMG! Just leave it alone. I don't want to have to fix my tests over
something so pedantic.

T.

On Sep 30, 2008, at 2:27 AM, Ryan Davis wrote:

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

On Sep 30, 2008, at 11:47 AM, Jim Weirich wrote:
>> deprecated stuff will drop off, making it even lighter/better/ 
>
>
> 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.

Hi,

How about reconsidering the feature freeze plan.

Yugui (Yuki Sonoda) wrote:
> 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.

On Oct 2, 2008, at 6:01 PM, NARUSE, Yui wrote:

> However, Ruby is still changing now and near future.


Ruby will always be changing. That's _why_ a freeze is needed... :)


Dave

NARUSE, Yui wrote:
> 
> 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

On Fri, Oct 3, 2008 at 12:01 AM, David Flanagan 
<david@davidflanagan.com> wrote:
> 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

Hi,

NARUSE, Yui wrote:
> 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.

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

At 14:37 08/10/03, Yugui (Yuki Sonoda) wrote:

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

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

>(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:duerst@it.aoyama.ac.jp

On Oct 2, 2008, at 11:35 PM, Austin Ziegler wrote:

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

On Fri, Oct 3, 2008 at 9:46 AM, Dave Thomas <dave@pragprog.com> wrote:
> On Oct 2, 2008, at 11:35 PM, Austin Ziegler wrote:
>> 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

On Oct 3, 2008, at 9:37 AM, Austin Ziegler wrote:

> 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

On Oct 3, 9:46 am, Dave Thomas <d...@pragprog.com> wrote:
> "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.

2008/9/30 Yusuke ENDOH <mame@tsg.ne.jp>:
>> I don't think anyone has claimed that ruby is English or that in belongs to
>
>
> 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.

On Sep 30, 2008, at 05:24 , Dave Thomas wrote:

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

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

On Wed, Oct 8, 2008 at 3:05 AM, Ryan Davis <ryand-ruby@zenspider.com> 
wrote:
> 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.

> 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
> stone for that matter):

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

On Wed, Oct 08, 2008 at 09:28:22PM +0900, Austin Ziegler wrote:
> 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

2008/10/8 Paul Brannan <pbrannan@atdesk.com>:
> On Wed, Oct 08, 2008 at 09:28:22PM +0900, Austin Ziegler wrote:
>> 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

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.

Hi --

On Thu, 9 Oct 2008, Jim Freeze wrote:

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

> 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

Uh, yeah. Thanks for  correcting my method arguments David.

On Wed, Oct 8, 2008 at 4:38 PM, Pit Capitain <pit.capitain@gmail.com> 
wrote:
> 2008/10/8 Paul Brannan <pbrannan@atdesk.com>:
>> On Wed, Oct 08, 2008 at 09:28:22PM +0900, Austin Ziegler wrote:
>>> 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

http://radarek.jogger.pl - mój blog

On Oct 8, 2:47 pm, "Rados³aw Bu³at" <radek.bu...@gmail.com> wrote:
> Ruby's api doesn't have to be poetry. Seriously.
For the obvious impaired there is

  assert_unequal

However, I admit the pattern doesn't carry over to the other
assertions. I mean who ever heard of assert_unraises? Perhaps helpful
in zombie situations, but I generally avoid those in all usecases.

On the other hand, we could take a queue from '!' as in  "!=" and
write:

  assert_equal!

Read it like "assert equal, NOT!"

See http://www.spike.com/video/borat-not-joke/2782157 for cultural
significance.

T.

Trans wrote:
> On the other hand, we could take a queue from '!' as in  "!=" and
> write:
> 
>   assert_equal!
> 
> Read it like "assert equal, NOT!"
> 
> See http://www.spike.com/video/borat-not-joke/2782157 for cultural
> significance.

I like this idea!

(get it?)

- Charlie

On Wed, Oct 8, 2008 at 3:48 PM, Charles Oliver Nutter
<charles.nutter@sun.com> wrote:
>> significance.
>
> I like this idea!

Please no. This conflicts with the current meaning of ! being
destructive and it is difficult to glance and see the difference
between equal and equal!.

Jim Freeze wrote:
>>> See http://www.spike.com/video/borat-not-joke/2782157 for cultural
>>> significance.
>> I like this idea!
> 
> Please no. This conflicts with the current meaning of ! being
> destructive and it is difficult to glance and see the difference
> between equal and equal!.
> 

I don't think you got the joke.

Good one, Charlie.  :)

On Wed, Oct 8, 2008 at 4:02 PM, daz <dooby@d10.karoo.co.uk> wrote:
> Jim Freeze wrote:
>>
>> Please no. This conflicts with the current meaning of ! being
>> destructive and it is difficult to glance and see the difference
>> between equal and equal!.
>
> I don't think you got the joke.
>
> Good one, Charlie.  :)

Oh, that Charlie is a sly one. :)

BTW Charlie, I very much like your description that refutes the use of 
refute.

On Oct 8, 2008, at 3:58 PM, Jim Freeze wrote:

>> I like this idea!
>
> Please no. This conflicts with the current meaning of ! being
> destructive and it is difficult to glance and see the difference
> between equal and equal!.

Mr Nutter was being reflexive: if ! means not, then "I like this
idea!" means...

At 16:05 08/10/08, Ryan Davis wrote:
>
>On Sep 30, 2008, at 05:24 , Dave Thomas wrote:
>
>> 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.

I think this is true. Finding out what's dead weight is difficult,
and gets more difficult the bigger our systems get.

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

I think that per se is okay. It wasn't the announcement, it was
the actual replacement that produced the shockwaves. When people
hear something, it goes in through one ear and out through the other.
When they feel it, they start to notice.

The fact that the actual replacement came very close to the feature
freeze deadline definitely didn't help; that should have happened
earlier.

>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'd personally be more interested in new and exciting functionality,
but I'm glad there are people like you who think like this.

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

This is also true, except that, as discussion just very recently
has shown, there is quite some disagreement about what's the best
naming convention, whereas for String#[n], while some people in
some cases be helped if that addressed bytes, it's rather clear
that the new way is the right way once you have understood the
difference between bytes and character.


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

Again, assuming that there would be reasonable agreement about
the direction to go with the names, that would be fine,

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

There is a huge difference between "hey, look at this and try it out"
(just a few people looking at it) and putting it into the mainstream,
replacing something well-known (everybody gets hit, and starts
complaining).

Regards,     Martin.



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