Forum: Ruby-core Ruby 1.9.0-1 snapshot released

0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2008-03-01 08:47
(Received via mailing list)
Hi,

I just released released 1.9.0-1 at
<ftp://ftp.ruby-lang.org/pub/ruby/1.9/>.
MD5SUM are:

04b952ed2d14438497cefac3b9e2c0fc  ruby-1.9.0-1.tar.bz2
2537e40463f24d8f78c8ae389d3d7d48  ruby-1.9.0-1.tar.gz
7457c4b5b26ac39d571df7ce12373823  ruby-1.9.0-1.zip

Note that it is a snapshot as of March 1st, to accelerate development.
We have fixed a lot of bugs since 1.9.0-0, but we know we still have
many untouched bugs.  Don't hesitate to report bugs we might forget.

The following is the brief summary of changes since 1.9.0-0:

* Oniguruma 5.9.1
* added UTF-16,CP949,EUC-KR,GB12345,UCS-{2,4}{BE,LE},GBK,CP936,CP949,
  GB2312,UTF-7,BIG5,EUC-TW,GB18030,KOI8,KOI8-R,KOI8-U,Windows-1251
support.
* use locale encoding for scripts from -e and stdin unless explicitly
specified.
* DATA inherits script encoding.
* __ENCODING__ for current script encoding.
* encoding options Kernel#{putc,puts} invokes STDOUT.{putc,puts}
respectively.
* don't use locale dependent strcasecmp.
* -Ks options means Windows-31J, not Shift_JIS.
* string methods work better on UTF-16 strings.
* empty string is compatible with any encoding string add
* string methods run faster for UTF-8.
* String#gsub(pat,hash) use US-ASCII (not ASCII-8BIT) for human readable
text.
* allow empty symbol.
* rb_num_coerce_*() now require ID argument.
* Math.cbrt added.
* Math.{gamma,lgamma} added.
* more precise BigDecimal_to_f.
* "0x", "+" and "-" is not a valid integer.
* Proc#curry added.
* Time#strftime officially ignores locale.
* Time.<=> no longer supports comparison with numeric.
* Enumerable#zip behavior reverted to 1.8 one.  string
* ObjectSpace.each_obj returns an enumerator if no block given.
* Prime#each returns an enumerator if no block given.
* replace "illegal" to "invalid" in messages.
* Hash#flatten no longer work recursively.
* archdir is "1.9.0", not "1.9".
* added --disable-rubyopt flag.
* import RubyGems r1601.
* Benchmark#realtime a bit faster.
* check NUL in path operand for file operations.
* "make help" shows major targets.

              matz.
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2008-03-01 08:56
(Received via mailing list)
On Feb 29, 2008, at 23:45 PM, Yukihiro Matsumoto wrote:
> Note that it is a snapshot as of March 1st, to accelerate development.
> We have fixed a lot of bugs since 1.9.0-0, but we know we still have
> many untouched bugs.  Don't hesitate to report bugs we might forget.

For the next 1.9.0 snapshot, can we get a heads-up on the ruby-core
list?

I'm preparing for RubyGems 1.1, and finished up a bunch of bug fixes
on Wednesday.  I would have imported them into HEAD had I known a new
snapshot was coming out.
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2008-03-01 09:38
(Received via mailing list)
Hi,

In message "Re: Ruby 1.9.0-1 snapshot released"
    on Sat, 1 Mar 2008 16:55:18 +0900, Eric Hodel <drbrain@segment7.net>
writes:

|For the next 1.9.0 snapshot, can we get a heads-up on the ruby-core
|list?

In the near future, we will prepare RedMine tracker for the core
development.  I hope this would improve the situation.

|I'm preparing for RubyGems 1.1, and finished up a bunch of bug fixes
|on Wednesday.  I would have imported them into HEAD had I known a new
|snapshot was coming out.

We will tell you when the next snapshot date is fixed.

              matz.
165075b159565bfc6ac1f64e7c4fecd3?d=identicon&s=25 Tadashi Saito (Guest)
on 2008-03-01 11:56
(Received via mailing list)
Hello,

On Sat, 1 Mar 2008 16:45:18 +0900
Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

> Note that it is a snapshot as of March 1st, to accelerate development.

I'm just curious about what's the substantial difference between 1.9.0-1
and
snapshot.tar.gz.  Summarizing of ChangeLog is a great work I think, but
I felt something wrong little with the number "...1," just incremented
integer, not "20080301."

If you have a plan to release snapshot monthly/weekly as versioned one,
I propose to version these shots as "1.9.0-200803" or "200803w1" to
express

> it is a snapshot

explicitly.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2008-03-01 13:37
(Received via mailing list)
Hi --

On Sat, 1 Mar 2008, Yukihiro Matsumoto wrote:

> We have fixed a lot of bugs since 1.9.0-0, but we know we still have
> many untouched bugs.  Don't hesitate to report bugs we might forget.

I couldn't get it to compile until I changed the revision number in
revision.h from r15560 to 15560.

> * Hash#flatten no longer work recursively.

I'm not seeing that -- it seems to still work recursively. I'm not
sure what's intended here, though. Doesn't the optional depth argument
take care of that?


David
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2008-03-01 14:51
(Received via mailing list)
Hi,

In message "Re: Ruby 1.9.0-1 snapshot released"
    on Sat, 1 Mar 2008 21:35:36 +0900, "David A. Black"
<dblack@rubypal.com> writes:

|I couldn't get it to compile until I changed the revision number in
|revision.h from r15560 to 15560.

I am awfully sorry.  I made a last minute bug in the packaging
script.  I have uploaded repacked archives.  Could you try again?
Here's new md5sum:

4344e18188bbdf3e5f19cdd3ade902bb  ruby-1.9.0-1.tar.bz2
90b721dce088f455df914c9482508601  ruby-1.9.0-1.tar.gz
8e89b49e473ac1c209e3c73a6fd6610f  ruby-1.9.0-1.zip

|> * Hash#flatten no longer work recursively.
|
|I'm not seeing that -- it seems to still work recursively. I'm not
|sure what's intended here, though. Doesn't the optional depth argument
|take care of that?

I mean

  {a: [:a,1], b: 2}.flatten

to give

  [:a, [:a, 1], :b, 2]

not

  [:a, :a, 1, :b, 2]

as it used to.

              matz.
Fd0b1962554b36c867d8a4928b8da3cc?d=identicon&s=25 Kirill A. Shutemov (Guest)
on 2008-03-03 09:44
(Received via mailing list)
Attachment: signature.asc (198 Bytes)
On [Sat, 01.03.2008 16:45], Yukihiro Matsumoto wrote:
> The following is the brief summary of changes since 1.9.0-0:
>
> * archdir is "1.9.0", not "1.9".

Why?
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2008-03-03 09:51
(Received via mailing list)
Hi,

In message "Re: Ruby 1.9.0-1 snapshot released"
    on Mon, 3 Mar 2008 17:43:15 +0900, "Kirill A. Shutemov"
<k.shutemov@gmail.com> writes:

|> * archdir is "1.9.0", not "1.9".
|
|Why?

Since 1.9.0 is not stable yet, binary API might change before 1.9.1.

              matz.
Fd0b1962554b36c867d8a4928b8da3cc?d=identicon&s=25 Kirill A. Shutemov (Guest)
on 2008-03-03 10:03
(Received via mailing list)
Attachment: signature.asc (198 Bytes)
On [Mon, 03.03.2008 17:50], Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: Ruby 1.9.0-1 snapshot released"
>     on Mon, 3 Mar 2008 17:43:15 +0900, "Kirill A. Shutemov" <k.shutemov@gmail.com> 
writes:
>
> |> * archdir is "1.9.0", not "1.9".
> |
> |Why?
>
> Since 1.9.0 is not stable yet, binary API might change before 1.9.1.

Will it changed back when API become stable? It's not very suitable
for distribution packager to rebuild all modules on each new ruby
version.
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2008-03-03 10:22
(Received via mailing list)
Hi,

In message "Re: Ruby 1.9.0-1 snapshot released"
    on Mon, 3 Mar 2008 18:02:47 +0900, "Kirill A. Shutemov"
<k.shutemov@gmail.com> writes:

|Will it changed back when API become stable? It's not very suitable
|for distribution packager to rebuild all modules on each new ruby version.

Yes, it will be 1.9 when 1.9.1 released.

              matz.
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2008-03-06 00:33
(Received via mailing list)
まつもと ゆきひろです

In message "Re: [ruby-dev:33947] Ruby 1.9.0-1 snapshot released"
    on Thu, 6 Mar 2008 08:12:33 +0900, Yukihiro Matsumoto
<matz@ruby-lang.org> writes:

|I just released released 1.9.0-1 at <ftp://ftp.ruby-lang.org/pub/ruby/1.9/>.
|MD5SUM are:

なんでこんなにずれてポストされるんだ?
This topic is locked and can not be replied to.