Hi,
I want to report you the status of Ruby 1.9.0-5 release.
- Encoding.default_internal will not be included in 1.9.0-5.
It will be included in 1.9.1 PR1.
- Some tests of RDoc seem to fail.
- miniunit has little problems.
== Encoding.default_internal
Matz said it takes more time to decide its specification and implement
it at [ruby-dev:36600]. So I will release 1.9.0-5 before
default_internal will be implemented.
default_internal will effect many libraries. So this feature possibly
make us reschedule the release of 1.9.1. But Matz decided to import this
feature into 1.9.1.
I will, by 25 Oct, decide whether we need rescheduling. I want to
release 1.9.1 at 20 Dec, but it will possibly be at 25 Jan.
Perhaps, some of standard libraries need to be fixed for
default_internal. I want you to fix the libraries by 20 Oct.
Basically the standard libraries are already frozen. Do not modify them
except bug fixes or for default_internal. Other exceptions are, now
cgi.rb, rdoc, rubygems, rake, miniunit, adding encodings, and
internationalization related changes.
Are there any libraries which should not be frozen? OK?
== RDoc
Some tests of RDoc seem to fail. Perhaps, it need some fixes.
== miniunit
Ryan did a great job. I read miniunit and it was clean and had good
readability.
But miniunit has little problems.
-
Error messages should have more information. [ruby-core:18929].
-
Some of existing tests fail because of incompatibility.
[ruby-core:18928].
-
Where are tests for miniunit? It should be imported into
$(srcdir)/test/mini/*.
-
When will the gem version of test/unit be available?
It means, when can we run programs based on the old test/unit by Ruby
1.9.0-5?
Regards,
Hi,
On Sat, 27 Sep 2008 17:39:51 +1000, Yugui (Yuki S.) [email protected]
wrote:
- Encoding.default_internal will not be included in 1.9.0-5.
It will be included in 1.9.1 PR1.
OK
release 1.9.1 at 20 Dec, but it will possibly be at 25 Jan.
Perhaps, some of standard libraries need to be fixed for
default_internal. I want you to fix the libraries by 20 Oct.
The design of default_internal (the patch I just posted) means that it
should not break libraries, and some should be able to use it without
modification eg: OpenURI (yet to be tested!).
However, some libraries should be modified to take better advantage of
it.
So I think that including default_internal should have immediate
benefits
and little downside.
Cheers
Mike
Hi,
2008/9/27 Yugui (Yuki S.) [email protected]:
== miniunit
Ryan did a great job. I read miniunit and it was clean and had good
readability.
That’s it. I also prefer almost all parts of miniunit to test/unit.
It means, when can we run programs based on the old test/unit by Ruby
1.9.0-5?
I think the method name problem must be added:
- assert_raise or _raises [ruby-core:18933]
- refute_* or assert_not_* [ruby-core:18899]
It is very ruby-level API and must be settled by 1.9 freeze.
I’d like to add output format of miniunit [ruby-core:18905] too, if
it is ruby-level API.
On Sep 27, 2008, at 00:39 AM, Yugui (Yuki S.) wrote:
== RDoc
Some tests of RDoc seem to fail. Perhaps, it need some fixes.
Something in RDoc’s test setup is not properly resetting state. When
run in isolation the tests pass.
I’m looking into it.
On Sep 29, 2008, at 11:31 AM, Eric H. wrote:
On Sep 27, 2008, at 00:39 AM, Yugui (Yuki S.) wrote:
== RDoc
Some tests of RDoc seem to fail. Perhaps, it need some fixes.
Something in RDoc’s test setup is not properly resetting state.
When run in isolation the tests pass.
Only one RDoc test currently fails now due to RubyGems polluting
ENV[‘HOME’]. I fixed one of the pollution points, and I’m looking for
a second.
Hi,
At Sat, 27 Sep 2008 20:40:27 +0900,
Yusuke ENDOH wrote in [ruby-core:18988]:
I think the method name problem must be added:
- assert_raise or _raises [ruby-core:18933]
- refute_* or assert_not_* [ruby-core:18899]
It is very ruby-level API and must be settled by 1.9 freeze.
And, bin/testrb doesn’t work due to lack of Test::Unit::AutoRunner.
Also, miniunit exits with failures and errors count, but it can
overflow easily and isn’t portable. It should `exit false’.
On Sep 27, 2008, at 13:50 , Nobuyoshi N. wrote:
At Sat, 27 Sep 2008 20:40:27 +0900,
Yusuke ENDOH wrote in [ruby-core:18988]:
I think the method name problem must be added:
- assert_raise or _raises [ruby-core:18933]
- refute_* or assert_not_* [ruby-core:18899]
It is very ruby-level API and must be settled by 1.9 freeze.
And, bin/testrb doesn’t work due to lack of Test::Unit::AutoRunner.
I’ll delete it. I have yet to see ANYONE use it in the 8 years I’ve
been coding ruby. Even ruby-core doesn’t use it, the Makefile invokes
test/runner.rb. testrb is incredibly inconvenient to use (doesn’t take
-I arg so you’re forced to run with ruby -I... -S testrb ...). In
short, it is a lame duck and I want to see it shot dead.
Also, miniunit exits with failures and errors count, but it can
overflow easily and isn’t portable. It should `exit false’.
it overflows? BUG IN RUBY! 
fixed. #run still returns the count, but at_exit exits with false.
On Sep 27, 2008, at 00:39 , Yugui (Yuki S.) wrote:
== miniunit
Ryan did a great job. I read miniunit and it was clean and had good
readability.
But miniunit has little problems.
- Error messages should have more information. [ruby-core:18929].
- assert_kind_of and assert_instance_of do not tell a class of an
actual object.
done
- assert_respond_to does not tell a class of an actual object.
done
- assert_same does not tell object_id.
done
- assert_send does not tell arguments.
fixed already, just not imported.
- Some of existing tests fail because of incompatibility.
[ruby-core:18928].
assert_raise does not output stack trace when different exception
from expected one is raised.
lame bug. the code was there, it just wasn’t going anywhere. 
assert_send does not work at all.
also a lame bug. muscle memory ftl. 
- Where are tests for miniunit? It should be imported into
$(srcdir)/test/mini/*.
they’re in my repository… I can add them to my core update script.
- When will the gem version of test/unit be available?
It means, when can we run programs based on the old test/unit by
Ruby
1.9.0-5?
it was released months ago, so you should be able to already.
On Sep 29, 2008, at 21:14 , Nobuyoshi N. wrote:
-I arg so you’re forced to run with ruby -I... -S testrb ...). In
short, it is a lame duck and I want to see it shot dead.
Do you mean anything other than this?
$ testrb --help | grep -e -I
-I, --load-path=DIR[:DIR…] Appends directory list to
$LOAD_PATH.
I’ve thought to move process_args in autorunner to testrb,
instead.
grr… nobu… you’re only allowed to point out ONE new thing to me a
day. You already showed me the two arg expand_path form (which is
still bending my brain).
Blame eric. He said it didn’t work (and maybe last time we tried it,
it didn’t… I dunno).
Does anyone use testrb? Maybe it is used more in Japan? I’m serious
when I said that I’ve NEVER paired with anyone (in the tens! :P) who
uses it. We use autotest. We use rake. We use plain ruby… we don’t
ever use testrb.
I don’t want it. I don’t want to maintain it. It is just more code and
in MY use cases it is completely superfluous.
Hello,
In message “[ruby-core:19037] Re: miniunit problems and release of Ruby
1.9.0-5”
on Sep.30,2008 14:10:29, [email protected] wrote:
Does anyone use testrb? Maybe it is used more in Japan? I’m serious
when I said that I’ve NEVER paired with anyone (in the tens! :P) who
uses it. We use autotest. We use rake. We use plain ruby… we don’t
ever use testrb.
I often use testrb.
It’s very convenient to run all test scripts in a directory.
I’m wondering how other people run tests at such time without
testrb.
And, I also use --runner=tk always. But I will be able to endure
removing GUI runner support…
BTW, I like code of miniunit. So I’m expecting that miniunit
completely replaces test/unit very much. Therefore, I want you
to keep compatibility as much as possible about the functions.
Regards,
Hi,
At Tue, 30 Sep 2008 12:45:25 +0900,
Ryan D. wrote in [ruby-core:19031]:
And, bin/testrb doesn’t work due to lack of Test::Unit::AutoRunner.
I’ll delete it. I have yet to see ANYONE use it in the 8 years I’ve
been coding ruby. Even ruby-core doesn’t use it, the Makefile invokes
test/runner.rb. testrb is incredibly inconvenient to use (doesn’t take
-I arg so you’re forced to run with ruby -I... -S testrb ...). In
short, it is a lame duck and I want to see it shot dead.
Do you mean anything other than this?
$ testrb --help | grep -e -I
-I, --load-path=DIR[:DIR…] Appends directory list to
$LOAD_PATH.
I’ve thought to move process_args in autorunner to testrb,
instead.
Also, miniunit exits with failures and errors count, but it can
overflow easily and isn’t portable. It should `exit false’.
it overflows? BUG IN RUBY! 
It depends on OSs.
SUSv2 http://www.opengroup.org/onlinepubs/007908799/xsh/wait.html:
WEXITSTATUS(stat_val)
If the value of WIFEXITED(stat_val) is non-zero, this macro
evaluates to the low-order 8 bits of the status argument
that the child process passed to _exit() or exit(), or the
value the child process returned from main().
On Sep 30, 2008, at 1:10 AM, Ryan D. wrote:
Does anyone use testrb? Maybe it is used more in Japan? I’m serious
when I said that I’ve NEVER paired with anyone (in the tens! :P) who
uses it. We use autotest. We use rake. We use plain ruby… we don’t
ever use testrb.
Although it is not the default, rake does provide support for using
testrb in the standard Test Task.
“U.Nakamura” [email protected] writes:
It’s very convenient to run all test scripts in a directory.
I’m wondering how other people run tests at such time without
testrb.
I used it all the time, when there are Test::Unit tests.
My own frameworks also have testrunners in that spirit (bin/specrb,
bin/bacon).
On Tue, Sep 30, 2008 at 05:28:57PM +0900, U.Nakamura wrote:
I often use testrb.
It’s very convenient to run all test scripts in a directory.
I’m wondering how other people run tests at such time without
testrb.
I rolled my own, partly because I didn’t know about testrb, and partly
because it isn’t terribly difficult to do.
Paul