-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Ruby 1.9.3-p0 has just been released. This is the first release of Ruby
1.9.3, the new stable series of Ruby.
== Changes
Ruby 1.9.3 is basically an implementation-improved version of Ruby
1.9.2. Library loading or locking in multi-threaded program is improved,
for example.
Also the license of Ruby has changed. Previously Ruby has been released
under GPLv2 and “Ruby” license. But Ruby 1.9.3 is released under a joint
2-clause BSD license and “Ruby” license.
There are some new features. Multilingualization now supports Unicode
6.0, a new library io/console, …
See NEWS file [1] and ChangeLog [2] for more details.
*1: http://svn.ruby-lang.org/repos/ruby/tags/v1_9_3_0/NEWS
*2: http://svn.ruby-lang.org/repos/ruby/tags/v1_9_3_0/ChangeLog
== Downloads
Regards,
Yuki Yugui S. [email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6tWAQACgkQOXzH5JLb/AWCLQCeP4DTOmdWhslWCRtsgDtww2uA
IlcAnRDnfugdSQHOmS/UgTAyQFqkiK/o
=wbuz
-----END PGP SIGNATURE-----
Hello,
2011/10/30 Yuki S. (Yugui) [email protected]:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Ruby 1.9.3-p0 has just been released. This is the first release of Ruby
1.9.3, the new stable series of Ruby.
[…]
Bug #5407 was still open and affects Windows developers with GCC 4.6.1
(ones using mingw.org releases or TDM releases)
Issue was marked as urgent and waiting for feedback from other
platform maintainers without response.
Today I’m working on a patch for both trunk and ruby_1_9_3 which seems
to be working, but now is too late to be backported and included in
Ruby 1.9.3-p0 release (because is already out).
I did raise my concerns on the maintainers email you sent a month ago,
but never received response from any other maintainer except Usaku
Nakamura.
To other Windows developers: please accept my apologies for not been
able to tackle this on time. To my bad daily work has left not much
time for Ruby over the past months.
On Sun, Oct 30, 2011 at 11:11 PM, Luis L. [email protected]
wrote:
Today I’m working on a patch for both trunk and ruby_1_9_3 which seems
to be working, but now is too late to be backported and included in
Ruby 1.9.3-p0 release (because is already out).
I heard that -fno-omit-frame-pointier solves the problem.
On Sun, Oct 30, 2011 at 11:20 AM, Yugui [email protected] wrote:
On Sun, Oct 30, 2011 at 11:11 PM, Luis L. [email protected] wrote:
Today I’m working on a patch for both trunk and ruby_1_9_3 which seems
to be working, but now is too late to be backported and included in
Ruby 1.9.3-p0 release (because is already out).
I heard that -fno-omit-frame-pointier solves the problem.
That is correct, but the patch was not included in the release.
Why you can’t change OPTFLAGS by yourself?
My concern is: Ruby don’t need to introduce a workaround for gcc
X.Y.1. Unfortunately
they are often too buggy and we can’t rescue it. As similar, we
finally reverted llvm-gcc
specific hack (it was introduced for OS X Lion support) from 193 branch.
I think we need to wait one more year. If it is gcc 4.6.x generic
issue, we have to care it.
IOW, we can’t rescue all of buggy gcc version. They are too much
unfortunately. (;_;
On Sun, Oct 30, 2011 at 11:20 AM, Yugui [email protected] wrote:
On Sun, Oct 30, 2011 at 11:11 PM, Luis L. [email protected] wrote:
Today I’m working on a patch for both trunk and ruby_1_9_3 which seems
to be working, but now is too late to be backported and included in
Ruby 1.9.3-p0 release (because is already out).
I heard that -fno-omit-frame-pointier solves the problem.
That is correct, but the patch was not included in the release.
On Sun, Oct 30, 2011 at 3:17 PM, KOSAKI Motohiro
[email protected] wrote:
Why you can’t change OPTFLAGS by yourself?
Not that I can’t change it, is there is no mention about it.
Also, building with Visual Studio, as commented by Usaku Nakamura,
uses a similar option by default.
My concern is: Ruby don’t need to introduce a workaround for gcc
X.Y.1.
A workaround for Visual Studio (mswin) is already in place, why not for
MinGW?
I think we need to wait one more year. If it is gcc 4.6.x generic
issue, we have to care it.
IOW, we can’t rescue all of buggy gcc version. They are too much
unfortunately. (;_;
We have too many workarounds in place…
Hi,
(11/11/01 5:56), KOSAKI Motohiro wrote:
My concern is: Ruby don’t need to introduce a workaround for gcc
X.Y.1.
A workaround for Visual Studio (mswin) is already in place, why not for MinGW?
Visual Studio optimization issue is version independent. AFAIK.
Do MinGW issue really independ on gcc version? Are you sure?
In short, gcc’s bugs are fixed, but VC’s not.
My concern is: Ruby don’t need to introduce a workaround for gcc
X.Y.1.
A workaround for Visual Studio (mswin) is already in place, why not for MinGW?
Visual Studio optimization issue is version independent. AFAIK.
Do MinGW issue really independ on gcc version? Are you sure?
If so, I have no reason to argue this. please go ahead.
My point is, gcc periodically released buggy version and we can’t rescue
all of them. Not beyond it.
I think we need to wait one more year. If it is gcc 4.6.x generic
issue, we have to care it.
IOW, we can’t rescue all of buggy gcc version. They are too much
unfortunately. (;_;
We have too many workarounds in place…
Yup.
Yuki S. (Yugui) wrote in post #1029201:
Ruby 1.9.3-p0 has just been released.
Many thanks and congrats to everyone who worked on this release!
Ruby 1.9.3 is significantly more power-efficient than previous
versions on my laptop: I went from 110 CPU wakeups-from-idle per
second (per Ruby process) down to 13, as reported by powertop 1!
This is important to me because my window manager configuration 2
is written in Ruby, so a Ruby is always running in the background.
Sugoku Arigatou! 
Suraj K. wrote in post #1029686:
Ruby 1.9.3 is significantly more power-efficient than previous
versions on my laptop: I went from 110 CPU wakeups-from-idle per
second (per Ruby process) down to 13, as reported by powertop [1]!
Correction: I had some extra unrelated Ruby daemons running in the
background so my previous observation was incorrect. Now I see that
Ruby 1.9.3 consumes even less power on my laptop, causing around 2
wakeups from idle per second per process! Truly amazing; thanks again!
PowerTOP version 1.13 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies)
C0 (cpu running) ( 5.0%)
polling 0.1ms ( 0.0%)
C1 mwait 0.1ms ( 1.1%)
C3 mwait 3.4ms (93.9%)
Wakeups-from-idle per second : 485.3 interval: 10.0s
no ACPI power usage estimate available
Top causes for wakeups:
28.8% ( 47.0) [hda_intel]
14.6% ( 23.9) [kernel scheduler] Load balancing tick
11.9% ( 19.4) [ath9k]
11.8% ( 19.3) kworker/0:0
8.0% ( 13.1) [kernel core] hrtimer_start (tick_sched_timer)
6.1% ( 10.0) kworker/u:3
3.1% ( 5.0) syndaemon
2.8% ( 4.6) [acpi]
2.5% ( 4.0) [kernel core] usb_hcd_poll_rh_status (rh_timer_func)
1.5% ( 2.5) wmii
1.3% ( 2.1) liferea
1.2% ( 2.0) kworker/u:2
1.2% ( 1.9) ruby
1.0% ( 1.7) X
0.7% ( 1.2) ario
0.6% ( 1.0) [kernel core] tpt_trig_timer (tpt_trig_timer)
0.6% ( 1.0) ntpd
0.3% ( 0.5) [ahci]
0.3% ( 0.5) watchdog/0
