Folks, I am pleased to announce that the very first preview of Ruby 1.8.7 has finally been released. The new version of Ruby includes many bug fixes, lots of feature enhancements and some performance improvements since 1.8.6 while maintaining stability and backward compatibility with the previous release to a high degree. The source code package is available in three formats at the following locations: ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-preview1.tar.bz2 ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-preview1.tar.gz ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-preview1.tar.zip Checksums: MD5 (ruby-1.8.7-preview1.tar.bz2) = a916996720d8891f4f0bf0c9fbb5bb6c SHA256 (ruby-1.8.7-preview1.tar.bz2) = e432ab1ab9b4570c0b7fe5c0c2730de0fda4c49a47811ea3a9170a311cf110b9 SIZE (ruby-1.8.7-preview1.tar.bz2) = 4007006 MD5 (ruby-1.8.7-preview1.tar.gz) = 522b8a1dffb04984a602d1d85b355a1a SHA256 (ruby-1.8.7-preview1.tar.gz) = 19f17c9546a61dddf1a44d5f9b460e34a01440195b5375ce70000f89fa425f68 SIZE (ruby-1.8.7-preview1.tar.gz) = 4705632 MD5 (ruby-1.8.7-preview1.zip) = a754af64daa0613055b58813da50cd7d SHA256 (ruby-1.8.7-preview1.zip) = 45fbbf34f04a750cf72d5e9a8a23412a57fd933dd077d3f23fd7be62e3478b32 SIZE (ruby-1.8.7-preview1.zip) = 5788496 For a brief list of user visible changes and a full list of all changes, see the bundled files named NEWS and ChangeLog, which are also available at the following locations: http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7_pr... http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7_pr... Please test it out and drop us a report in the following tracker if you find any problem: http://rubyforge.org/tracker/?atid=22040&group_id=... Some known problems are on the list and when you find one it may be fixed already, so please look through all items querying with "State" set to "Any" before submitting a new one. The next preview is planned on next Saturday. (This time I will keep the schedule!) Regards,
on 2008-04-15 22:57
on 2008-04-16 00:44
On Tue, Apr 15, 2008 at 5:55 PM, Akinori MUSHA <knu@idaemons.org> wrote: > > MD5 (ruby-1.8.7-preview1.tar.gz) = 522b8a1dffb04984a602d1d85b355a1a > It seems the settracefunc test missed the first preview. Results from One-Click Installer with MinGW build: 1867 tests, 1343975 assertions, 3 failures, 0 errors 1) Failure: test_event(TestSetTraceFunc) [../ruby_1_8/test/ruby/test_settracefunc.rb:56]: <["line", 23, :test_event, TestSetTraceFunc]> expected but was <["c-call", 23, :==, Fixnum]>. 2) Failure: test_to_proc(TestSymbol) [../ruby_1_8/test/ruby/test_symbol.rb:80]: Exception raised: Class: <ArgumentError> Message: <"no receiver given"> ---Backtrace--- ../ruby_1_8/test/ruby/test_symbol.rb:58:in `to_proc' ../ruby_1_8/test/ruby/test_symbol.rb:80:in `call' ../ruby_1_8/test/ruby/test_symbol.rb:80:in `test_to_proc' ../ruby_1_8/test/ruby/test_symbol.rb:80:in `test_to_proc' --------------- 3) Failure: test_cgi(TestWEBrickCGI) [../ruby_1_8/test/webrick/test_cgi.rb:27:in `test_cgi' D:/Users/Luis/projects/oss/oci/installer3/dev/sandbox/ruby_1_8/lib/net/http.rb:1053:in `request' D:/Users/Luis/projects/oss/oci/installer3/dev/sandbox/ruby_1_8/lib/net/http.rb:2136:in `reading_body' D:/Users/Luis/projects/oss/oci/installer3/dev/sandbox/ruby_1_8/lib/net/http.rb:1052:in `request' D:/Users/Luis/projects/oss/oci/installer3/dev/sandbox/ruby_1_8/lib/net/http.rb:1037:in `request' D:/Users/Luis/projects/oss/oci/installer3/dev/sandbox/ruby_1_8/lib/net/http.rb:543:in `start' D:/Users/Luis/projects/oss/oci/installer3/dev/sandbox/ruby_1_8/lib/net/http.rb:1035:in `request' ../ruby_1_8/test/webrick/test_cgi.rb:27:in `test_cgi' ../ruby_1_8/test/webrick/utils.rb:26:in `call' ../ruby_1_8/test/webrick/utils.rb:26:in `start_server' ../ruby_1_8/test/webrick/utils.rb:34:in `start_httpserver' ../ruby_1_8/test/webrick/test_cgi.rb:24:in `test_cgi']: <"/webrick.cgi"> expected but was <"<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\">\n<HTML>\n <HEAD><TITLE>Internal Server Error</TITLE></HEAD>\n <BODY>\n <H1>Internal Server Error</H1>\n Premature end of script headers: D:/Users/Luis/projects/oss/oci/installer3/dev/sandbox/ruby_1_8/test/webrick/webrick.cgi\n <HR>\n <ADDRESS>\n WEBrick/1.3.1 (Ruby/1.8.7/2008-04-15) OpenSSL/0.9.7c at\n 127.0.0.1:1328\n </ADDRESS>\n </BODY>\n</HTML>\n">. -- Luis Lavena Multimedia systems - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams
on 2008-04-16 04:41
From: Akinori MUSHA [mailto:knu@iDaemons.org] # For a brief list of user visible changes and a full list of all # changes, see the bundled files named NEWS and ChangeLog, which are # also available at the following locations: # http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7_pr... # http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7_pr... chuck-full, this looks like ruby1.9 without the vm :) can't wait to test this. thanks and kind regards -botp
on 2008-04-16 04:47
At Wed, 16 Apr 2008 07:44:01 +0900, Luis Lavena wrote: > It seems the settracefunc test missed the first preview. > > Results from One-Click Installer with MinGW build: > > 1867 tests, 1343975 assertions, 3 failures, 0 errors > > 1) Failure: > test_event(TestSetTraceFunc) [../ruby_1_8/test/ruby/test_settracefunc.rb:56]: > <["line", 23, :test_event, TestSetTraceFunc]> expected but was > <["c-call", 23, :==, Fixnum]>. Yes, and I fixed the test. http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=r... http://rubyforge.org/tracker/index.php?func=detail... > --------------- I'll tackle this problem later.
on 2008-04-16 17:10
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm citing a message from talk, but I think it better fits into core:
On Apr 16, 2008, at 4:40 AM, Pena, Botp wrote:
> chuck-full, this looks like ruby1.9 without the vm :)
Thats pretty much why i'm not looking forward to the 1.8.7 release.
Ruby 1.8 is the major ruby version that is marked production-ready.
While there are cases where changes are necessary, this should mean
that the API is stable - at least when it comes to core classes, but
to some extend, this should also be true for the standard library. The
core should be frozen.
Those changes are not minor. While they are backwards-compatible, they
severely break forward-compatibility between 1.8.6 and 1.8.7. While
those changes are nice, it gets increasingly hard to track what
features a specific minor(!) core(!!) version of Ruby actually
supports. As there are still many interpreter installations out there
that are not even on 1.8.6-level those features are essentially
useless. For example, some Linux packaging tools do not even install
1.8.6 (apt for example). If you target your code towards a minor
version, you will be in a world of pain. As developers often use the
most recent version for development, chances are there that you run
into that trap. You can multitest, but it artificially increases
testing complexity. This is beginning to get a real problem when it
comes to configuration management.
Also, as we do have multiple interpreters for the standard-1.8.6-
distribution, it breaks compatibility for those.
There are cases where backporting would make sense (in edge cases
where there is really only a brutal hack in use [e.g. #instance_exec,
which does not seem to be backported]). But in case of all those
Enumerators: If I use them, my code breaks on all older versions. So,
any sane person keeps his hands off them. Where is the point in
supporting them?
I also believe that the invested time in backporting is better
invested to improve ruby1.9.
I support and like Rubys bazaar-style development, but a bazaar begins
to fall apart when huts change their position every other day.
There are multiple solutions to this problem:
* freeze the core-api for major versions upon release candidates.
* freeze the core-api before developing a new release (python style).
This might not fit the usual ruby development style but would make it
easier for non-mri interpreter teams to develop some kind of standards
ahead of an MRI release.
* provide a backport-library (or gem) that implements those features
for all older versions of a series (can be hard in some cases) that
all developers of "edge"- libraries can depend on.
* be sane about adding features inside a series. Ruby is rich on
sugar, but you should not add sugar to a cake that is already
finished. "Sane" is intentional: make a lax statement on what should
and what should not be added in a minor version, without specifying
hard rules. This means that a discussion is needed on whether those
changes were "sane" or "not sane".
Also, this kind of release policy is known in the administrator world
and it gets increasingly hard for me to get people to even consider
ruby because of it's erratic nature when comes to the core.
Regards,
Florian Gilcher
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkgGFq8ACgkQJA/zY0IIRZbqzwCeI1amP3v4P5d1/hMglc57q5S7
l00AoKPLXbgy4vZAuL2IfHATUQERb4Gb
=d/un
-----END PGP SIGNATURE-----
on 2008-04-16 18:38
On Apr 16, 11:09 am, Florian Gilcher <f...@andersground.net> wrote: > > supports. As there are still many interpreter installations out there > that are not even on 1.8.6-level those features are essentially > useless. For example, some Linux packaging tools do not even install > 1.8.6 (apt for example). If you target your code towards a minor > version, you will be in a world of pain. As developers often use the > most recent version for development, chances are there that you run > into that trap. You can multitest, but it artificially increases > testing complexity. This is beginning to get a real problem when it > comes to configuration management. > Also, as we do have multiple interpreters for the standard-1.8.6- > distribution, it breaks compatibility for those. As much as I like having these changes, I feel somewhat the same way. I just got through adding "if ruby 1.9" clauses to various part of Facets, and now I will have to go back and add "if ruby 1.8.7" clauses. I'm torn. I'd rather just move on to 1.9 as fast as possible, in which case I'd rather not see all these new features in 1.8.7. OTOH, if 1.9 isn't really ready for production yet and won't be for a while, then these features are better to have than not to have. T.
on 2008-04-16 21:18
Hi, On Tue, Apr 15, 2008 at 10:55 PM, Akinori MUSHA <knu@idaemons.org> wrote: > since 1.8.6 while maintaining stability and backward compatibility > with the previous release to a high degree. The latest 1_8 branch currently fails about 60+ spec tests ('the rubyspecs' hosted by Rubinius folks), and SIGSEGV's on some Kernel rubyspecs (I believe there was a thread about that some time ago). I can provide the detailed list of the tests that fail on 1.8.7 but pass on 1.8.6pl114, if there's interest. (Well, running the rubyspecs against 1.8.7 is pretty easy, if you'd like to try). :) Thanks, --Vladimir
on 2008-04-16 21:31
On Wed, Apr 16, 2008 at 4:17 PM, Vladimir Sizikov <vsizikov@gmail.com> wrote: > > I can provide the detailed list of the tests that fail on 1.8.7 but > pass on 1.8.6pl114, if there's interest. (Well, running the rubyspecs > against 1.8.7 is pretty easy, if you'd like to try). :) > Vladimir, I'm highly interested on that. Can you share with us proper setup of the spec/mspec environment? Thanks in advance, -- Luis Lavena Multimedia systems - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams
on 2008-04-16 21:46
Hi Luis, On Wed, Apr 16, 2008 at 9:31 PM, Luis Lavena <luislavena@gmail.com> wrote: > > Vladimir, I'm highly interested on that. > > Can you share with us proper setup of the spec/mspec environment? Excellent! :) The very quick guide is on my blog here: http://blog.emptyway.com/2008/04/06/the-rubyspecs-... You just 'git clone' the rubinius repository, and use the appropriate command to launch the spec tests. One of the parameters, '-t', specifies the actual implementation under test, so you could have -t jruby or -t /opt/ruby1.8.7/bin/ruby, etc The typical command is: bin/mspec -t /path/to/ruby spec/ruby/1.8/ That 'spec/ruby/1.8.' - is the place for all Ruby 1.8.6 specs, divided into subdirs (core, language, library). Most specs should pass fine on Ruby 1.8.6 pl114 (there will be few failures due to platform dependent behavior, and we really should clean those up, but it's good enough for now). So, when you specify different targets via -t switch , you'll see what passes with 1.8.6 and fails with 1.8.7. Thanks, --Vladimir
on 2008-04-16 21:49
On Wed, Apr 16, 2008 at 4:45 PM, Vladimir Sizikov <vsizikov@gmail.com> wrote: > > > That 'spec/ruby/1.8.' - is the place for all Ruby 1.8.6 specs, divided > into subdirs (core, language, library). > > Most specs should pass fine on Ruby 1.8.6 pl114 (there will be few > failures due to platform dependent behavior, and we really should > clean those up, but it's good enough for now). > > So, when you specify different targets via -t switch , you'll see what > passes with 1.8.6 and fails with 1.8.7. > Thank you. I'll try them with One-Click using MinGW :-) Will let you know if anything else is broken :-) -- Luis Lavena Multimedia systems - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams
on 2008-04-16 21:51
Luis, Oh, and one more thing, knowing that you most probably interested in Windows part, the Win32 support in rubyspecs is very experimental at the moment, since most developers are on MacOS/Linux at the moment... There is a way to run the tests on windows, but amount of noise/failures is just scary. And cleaning it up would be one of the future tasks... :) Thanks, --Vladimir
on 2008-04-16 21:54
On Wed, Apr 16, 2008 at 4:50 PM, Vladimir Sizikov <vsizikov@gmail.com> wrote: > Luis, > > Oh, and one more thing, knowing that you most probably interested in > Windows part, the Win32 support in rubyspecs is very experimental at > the moment, since most developers are on MacOS/Linux at the moment... > > There is a way to run the tests on windows, but amount of > noise/failures is just scary. And cleaning it up would be one of the > future tasks... :) > No worry, I'm used to live in the edge... maybe could provide some patches :-) Thank you for your time. -- Luis Lavena Multimedia systems - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams
on 2008-04-16 22:18
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I'm torn. I'd rather just move on to 1.9 as fast as possible, in which > case I'd rather not see all these new features in 1.8.7. OTOH, if 1.9 > isn't really ready for production yet and won't be for a while, then > these features are better to have than not to have. My point is: is the pain of not having these features in core really bigger than not having them (but available via libs)? I mean - the most used functionality in ruby just got a whole lot bigger. Thats great. But i have to keep my finger from it, because it doesn't fit into the rest of the series - so, why bother? facets at least gives me such functionality in a way that works across ruby1.8. I also see this as a problem of selling ruby to the world: you can't sell without a certain notion of being "stable". As a programmer that has total control over his system, I would always vote for new features. But the reality that our target systems can be managed by others - and they don't see ruby with the eyes of someone that reads this group. I know more than one person that would really like to use ruby in a corporate environment but can't - because they can't sell ruby as stable. Regards, Florian Gilcher -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkgGXusACgkQJA/zY0IIRZZhpACgvo9I2F5rVVyeqwfedf2/z0yq c84An0/Fw0DsYUeDI2WKtYyQ7RiDdWc6 =WHXI -----END PGP SIGNATURE-----
on 2008-04-16 22:48
Hi, At Thu, 17 Apr 2008 00:09:58 +0900, Florian Gilcher wrote: > I'm citing a message from talk, but I think it better fits into core: > > On Apr 16, 2008, at 4:40 AM, Pena, Botp wrote: > > chuck-full, this looks like ruby1.9 without the vm :) I may digress, but Ruby 1.9 is far more than just VM. There are so many fancy things we regret being unable to backport. > Thats pretty much why i'm not looking forward to the 1.8.7 release. > > Ruby 1.8 is the major ruby version that is marked production-ready. > While there are cases where changes are necessary, this should mean > that the API is stable - at least when it comes to core classes, but > to some extend, this should also be true for the standard library. The > core should be frozen. It all depends on your standpoint, really. If you are a mission critical production application developer, you would just want bug fixes and nothing else. If you are an average production application developer, performance improvement would also be welcome. If you are a library developer, the bigger the difference between 1.8 and 1.9 the more difficult it is to develop and maintain your library. If you drop support for 1.8, you are leaving average users behind. If you stick with 1.8 and hesitate to support 1.9 until it is production ready, you are left behind when 1.9 is ready. So changes that makes 1.8 closer to 1.9 may help you. If you are a bleeding edge developer, you couldn't care less about 1.8 as you say. But after all above, if you are a Ruby developer like me, you must care about all kinds of people using Ruby in various ways. I'll tell my thoughts in detail below. > into that trap. You can multitest, but it artificially increases > testing complexity. This is beginning to get a real problem when it > comes to configuration management. > Also, as we do have multiple interpreters for the standard-1.8.6- > distribution, it breaks compatibility for those. You could think about forward compatibility between 1.8 and 1.9 as well. To encourage users to stop using a feature in 1.8 that are deprecated in 1.9, it is sometimes an optimal solution to backport the new method to 1.8. Generally the newer version is (re)designed based on better methods, styles and techniques, so it is often a good idea to make people get used to them through backports, rather than asking them to make big changes after a long time has passed. > There are cases where backporting would make sense (in edge cases > where there is really only a brutal hack in use [e.g. #instance_exec, > which does not seem to be backported]). But in case of all those > Enumerators: If I use them, my code breaks on all older versions. So, > any sane person keeps his hands off them. Where is the point in > supporting them? It doesn't make much sense to me. Why would users who stick to older releases of Ruby suddenly decide to introduce a new library, or use new features when writing one? You probably know but there are the Ruby 1.8.X-pX series for the last two releases for those who don't want changes but just bug fixes. Considering 1.8.5 was a bug fix release of 1.8.4, it has been maintained for more than 2 years. Even if the 1.8.5 maintenance were to be dropped, you could then move to a newer release without much difficulty, because backward compatibility is kept pretty well and a few exceptions are documented. > I also believe that the invested time in backporting is better > invested to improve ruby1.9. Backporting a radical development branch to a stable branch is like making steps for gradual migration instead of giant leap migration, which often demands you a complete rewrite of a big part of your code. If you froze a branch soon after the first or maybe second release from the branch, what would happen? As the difference between ruby branches gets bigger and bigger, every library author would: a) Have to maintain one branch for each ruby branch, b) Write and maintain bridge code on his/her own, Or: c) Feel conservative about using new features aggressively, and the new features would not get used as hard as they deserve. What we have been doing in the 1.8 development is eliminating each developer's duplicated effort of a) and b) to avoid the worst case, c). If people did not use or even know about new features for a long time, the development branch would eventually be full of experimental, untested features. Decent tests would not be performed widely until after several years of aggressive development, while the stable series solely enjoys its heyday without any changes. Then one day, when the first release from the development branch is about to release, you will be told: "OK, the new version of ruby is getting ready. Before we release it, we would like you folks to test these 1000 new features with your applications and libraries. Beware, you'll have to fix your code around before running it with the new version if you are using any of those 100 features that have incompatibilities with the previous series". It is not my imagination. Similar things actually happened a few times before, albeit the figures above are a bit exaggerated. Every time that happened the average user got confused by and complained about the incompatibilities and unknown new features suddenly introduced when a new major version was released. That caused the new version to take much longer time than expected to become stable and get widely used. We used to lose users because of all that. > I support and like Rubys bazaar-style development, but a bazaar begins > to fall apart when huts change their position every other day. As I said above, we have been improving the development scheme to offer reasonable options for various kinds of users and scenes. I can say we have been and will always be consistent with that. > sugar, but you should not add sugar to a cake that is already > finished. "Sane" is intentional: make a lax statement on what should > and what should not be added in a minor version, without specifying > hard rules. This means that a discussion is needed on whether those > changes were "sane" or "not sane". > > Also, this kind of release policy is known in the administrator world > and it gets increasingly hard for me to get people to even consider > ruby because of it's erratic nature when comes to the core. I agree. Sooner or later we will have to make a switch, but I don't think we are ready to go for that. For 1.8 and 1.9, it's so late it doesn't pay. Maybe from 2.0? It's matz's call though.
on 2008-04-16 23:05
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 16, 2008, at 10:48 PM, Akinori MUSHA wrote: > [many things] > > -- > Akinori MUSHA / http://akinori.org/ I will not have time to answer to this in the next time, but first of all: thanks for this extensive explanation. It shed some light into things for me. Regards, Florian Gilcher -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkgGadcACgkQJA/zY0IIRZaJ4gCgmZcAqoNkkqQaO99DWrLXsuZh j+IAnjskY1WeTGTIDT8PHy57VkVYowED =fTvl -----END PGP SIGNATURE-----
on 2008-04-16 23:19
At Thu, 17 Apr 2008 00:09:58 +0900, Florian Gilcher wrote: > * provide a backport-library (or gem) that implements those features > for all older versions of a series (can be hard in some cases) that > all developers of "edge"- libraries can depend on. Actually we did that before to ease the migration from 1.6 to 1.8. I created a project called ruby-shim. That was a lesson and a hint to the current development policy of the 1.8 series since 1.8.6. > * be sane about adding features inside a series. Ruby is rich on > sugar, but you should not add sugar to a cake that is already > finished. "Sane" is intentional: make a lax statement on what should > and what should not be added in a minor version, without specifying > hard rules. This means that a discussion is needed on whether those > changes were "sane" or "not sane". That kind of decision based on a set of lax rules is arbitrary anyway. My set of rules include "Do not break backward compatibility of a document feature for no good reason" (briefly) and that's my definition of sanity, and that was officially announced a while ago.
on 2008-04-16 23:57
At Thu, 17 Apr 2008 06:04:29 +0900, Florian Gilcher wrote: > I will not have time to answer to this in the next time, but first of > all: > thanks for this extensive explanation. It shed some light into things > for me. No problem at al, take your time. It was me who didn't pay enough attention to communicate in English. I take this exchange a precious experience and opportunity to express my views I missed to state before. After reading my post, I found I put my lines between wrong paragraphs of yours in some places. Please read my paragraphs as you think fit, I'm sure I read your reply. Regards,
Enable email notification
Enable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.