[#31589] [Bug #3457] URI.encode does not escape square brackets — Shyouhei Urabe <redmine@...>
Issue #3457 has been updated by Shyouhei Urabe.
2010/8/2 Shyouhei Urabe <redmine@ruby-lang.org>:
[#31614] Release engineering status of 1.9.2-p0 — Yusuke ENDOH <mame@...>
Hi,
[#31666] [Bug #3677] unable to run certain gem binaries' in windows 7 — Roger Pack <redmine@...>
Bug #3677: unable to run certain gem binaries' in windows 7
Issue #3677 has been updated by Roger Pack.
[#31681] [Bug #3683] getgrnam on computer with NIS group (+)? — Rocky Bernstein <redmine@...>
Bug #3683: getgrnam on computer with NIS group (+)?
Issue #3683 has been updated by Rocky Bernstein.
Hi,
[#31706] [Bug #3690] method_missing in a BasicObject's singleton class - infinite recursion segfaults — Jan Lelis <redmine@...>
Bug #3690: method_missing in a BasicObject's singleton class - infinite recursion segfaults
[#31730] [Bug #3701] Gem.find_files returns empty array — Yusuke Endoh <redmine@...>
Bug #3701: Gem.find_files returns empty array
[#31739] [Backport #3702] segmentation fault while compiling 1.9.1-p430 on debian squeeze — Tomasz Pajor <redmine@...>
Backport #3702: segmentation fault while compiling 1.9.1-p430 on debian squeeze
[#31757] [Bug #3712] SEGV fails to produce stack dump / backtrace in debug build — Peter Weldon <redmine@...>
Bug #3712: SEGV fails to produce stack dump / backtrace in debug build
[#31761] [Feature #3714] Add getters for Enumerator — Marc-Andre Lafortune <redmine@...>
Feature #3714: Add getters for Enumerator
[#31762] [Backport #3715] Enumerator#size and #size= — Marc-Andre Lafortune <redmine@...>
Backport #3715: Enumerator#size and #size=
[#31798] [Bug #3726] require degradation from 1.9.1 — Yura Sokolov <redmine@...>
Bug #3726: require degradation from 1.9.1
[#31805] [Backport #3728] IO.select is not documented. — Mike Perham <redmine@...>
Backport #3728: IO.select is not documented.
[#31806] 1.9.1 has marshal bugs in everything but p129 — Ryan Davis <ryand-ruby@...>
Is there any chance we can release a 1.9.1 that fixes the current marshal bugs? It is fixed in 1.9.2, so I know the patch exists somewhere and could be merged over. Otherwise I think I'm going to have to drop support for 1.9.1 early.
[#31843] Garbage Collection Question — Asher <asher@...>
This question is no doubt a function of my own lack of understanding, but I think that asking it will at least help some other folks see what's going on with the internals during garbage collection.
> The question in short: when an object goes out of scope and has no
Right - so how does a pointer ever get off the stack?
On 8/26/10 11:51 AM, Asher wrote:
I very much appreciate the response, and this is helpful in describing the narrative, but it's still a few steps behind my question - but it may very well have clarified some points that help us get there.
You have introduced something called a "root node" without defining it. What do you mean by this?
[#31851] [Bug #3747] Possible bug of String#count? — Ruohao Li <redmine@...>
Bug #3747: Possible bug of String#count?
[#31868] [Bug #3750] SEGV: ruby -rprofile test/ruby/test_assignment.rb — Peter Weldon <redmine@...>
Bug #3750: SEGV: ruby -rprofile test/ruby/test_assignment.rb
[#31885] Avoiding $LOAD_PATH pollution — Eric Hodel <drbrain@...7.net>
Last year Nobu asked me to propose an API for adding an object to
Hi Eric,
On Jan 8, 2011, at 12:08, zimbatm ... wrote:
Just a note for future references. While playing with require, I found
> The lookup object pushed onto $LOAD_PATH must respond to #path_for. The
On Aug 28, 2010, at 19:30, Run Paint Run Run wrote:
>> How confident are we that this API would be sufficient for replacing the
[#31914] [Ruby 1.8.7-RubySpec#3757][Open] GC bug after loading gem — Joel VanderWerf <redmine@...>
RubySpec #3757: GC bug after loading gem
[#31929] Proposal: Autoload with block — Magnus Holm <judofyr@...>
= A proposal for autoload w/block:
Sorry to plug my own stuff, but you might find subload of some interest here. It's unfinished, but provides some flexibility in these matters that might be of interest. I also have a fair amount of notes about possible other use cases that aren't covered yet in the subload code. Whilst on the topic, some consideration for thread safety might be worth the time - not that I'm proposing it can be 'fixed', merely considered to avoid worst cases.
Magnus, have you seen http://redmine.ruby-lang.org/issues/show/462 ?
That's interesting, but I don't buy matz' argument:
[#31947] not use system for default encoding — Roger Pack <rogerdpack2@...>
It strikes me as a bit "scary" to use system locale settings to
> It strikes me as a bit "scary" to use system locale settings to *arbitrarily*
NARUSE, Yui wrote on 2010-11-15 11:07:
[#31969] [Ruby 1.9-Feature#3773][Open] Module#parent — Thomas Sawyer <redmine@...>
Feature #3773: Module#parent
[#31971] Change Ruby's License to BSDL + Ruby's dual license — "NARUSE, Yui" <naruse@...>
Ruby's License will change to BSDL + Ruby's dual license
On 01/09/10 at 01:30 +0900, NARUSE, Yui wrote:
(2010/09/01 2:36), Lucas Nussbaum wrote:
I wrote a concrete patch.
(2010/09/01 1:30), NARUSE, Yui wrote:
On Aug 31, 2010, at 9:50 AM, NARUSE, Yui wrote:
[ruby-core:31614] Release engineering status of 1.9.2-p0
Hi, I'm reporting the status of 1.9.2-p0 release which has been planned at early this month. (1) backports from trunk into ruby_1_9_2 (2) busyness of the release manager (1) Currently, we have roughly backported patches that was committed by 23 Jul. In principle, I will no longer backport any patch for 1.9.2-p0. A brand-new patch should have a certain amount of "soak time" in trunk. *Almost all* patches that have just been committed into trunk are not stable yet. They may often cause another issue, or may not been fixed completely. Backporting such patches will never stabilize ruby_1_9_2 branch. In fact, I actually had some trouble about one patch that requires another patch that requires another patch... (about 5 times). I think this lesson (soak time) should be applied in the next release. Meanwhile in this time, I decide that I will backport only patches that meat any following conditions: - SEGV or [BUG] problem on supported platform - build failure on supported or besteffort platform - other really really fatal issues If you notice a patch that meats any condition is not backported, please let me know ASAP (by Friday, at the latest). Of course, other issues will be fixed by patch releases after 1.9.2-p0. (2) The release managaer, Yugui, apparently can do release engineering at only week end. So I guess the next release will be at Saturday or Sunday. Some committers say that RC3 be released before 1.9.2-p0, but I'm afraid that it is impossible (RC2 and RC3 had not been planned, originally). The branch ruby_1_9_2 will be nearly-unchanged until p0 is released. So I ask all platform maintainers to test ruby_1_9_2 branch. Though release candidate will not released publicly, to prevent wrong packaging, we will directly ask the maintainers for besteffort platforms to check tar ball. Thank you in advance for your help. 遠藤です。 8 月上旬予定の 1.9.2 リリースの状況についてお伝えします。 (1) trunk から ruby_1_9_2 へのバックポート (2) リリースマネージャの多忙 (1) 現状では、7/23 (金) までに trunk にコミットされたパッチはバック ポートできていると思います。 ですが、これ以上は原則バックポートしないことにしたいと思います。 trunk に入ったばかりのパッチは安定性に疑問があります。他の問題を引き 起こしていたり、完全に修正されていなかったりします。実際、「修正を 修正するコミット」が数日おきに最近まで 5 回連なっている例がありました。 そういうパッチをリリース直前にすべてバックポートしていくと、いつまで たっても ruby_1_9_2 が安定しません。 trunk での soak time (検証期間) を考慮すべきだったのですが、反省は後 にして、とりあえず今回は、下記のいずれかの条件を満たすコミット以外は これ以上バックポートしません。 - supported な環境で SEGV する - supported または besteffort な環境でビルドが通らない - その他、本当に致命的と考えられる問題 いずれかの条件を満たすパッチでバックポートが漏れているものがあれば 早急に (遅くとも金曜までに) 連絡してください。 それ以外の問題も、p0 以降のパッチリリースでは修正されると思います。 (2) Yugui さんはほぼ土日しか作業できないようなので、リリースは早くて 次の土日になるのではないかと思います。 「1.9.2-p0 リリースの前に RC3 を出すべき」という声もありますが、この 状況では無理だと思います (あと、当初の予定には RC 1 つしかなかった) 。 ruby_1_9_2 ブランチはもう p0 リリースまでほとんど変わらないと思います ので、プラットフォームメンテナは ruby_1_9_2 ブランチを試しておいて 欲しいと思います。 パッケージングのミスを防ぐため、besteffort 以上のメンテナにはリリース 直前に tar ball が回付されると思います (いつもどおり) 。 -- Yusuke Endoh <mame@tsg.ne.jp>