[#44036] [ruby-trunk - Feature #6242][Open] Ruby should support lists — "shugo (Shugo Maeda)" <redmine@...>
[#44084] [ruby-trunk - Bug #6246][Open] 1.9.3-p125 intermittent segfault — "jshow (Jodi Showers)" <jodi@...>
[#44156] [ruby-trunk - Feature #6265][Open] Remove 'useless' 'concatenation' syntax — "rosenfeld (Rodrigo Rosenfeld Rosas)" <rr.rosas@...>
Hi,
(2012/04/09 14:19), Yukihiro Matsumoto wrote:
[#44163] [ruby-trunk - Bug #6266][Open] encoding related exception with recent integrated psych — "jonforums (Jon Forums)" <redmine@...>
[#44233] [ruby-trunk - Bug #6274][Open] Float addition incorrect — "swanboy (Michael Swan)" <swanyboy4@...>
[#44303] [ruby-trunk - Feature #6284][Open] Add composition for procs — "pabloh (Pablo Herrero)" <pablodherrero@...>
[#44329] [ruby-trunk - Feature #6287][Open] nested method should only be visible by nesting/enclosing method — "botp (bot pena)" <botpena@...>
[#44349] [ruby-trunk - Feature #6293][Open] new queue / blocking queues — "tenderlovemaking (Aaron Patterson)" <aaron@...>
On Sat, Apr 14, 2012 at 10:58:12AM +0900, mame (Yusuke Endoh) wrote:
Hi,
On Mon, Apr 16, 2012 at 06:25:59PM +0900, SASADA Koichi wrote:
[#44372] Possible merge error of code in Issue 4651 on to Ruby 1.9.3-p125? — "Blythe,Aaron" <ABLYTHE@...>
tl;dr I believe I have uncovered a merge error to ruby 1.9.3-p125 from Issue 4651. Please advise if this is the same issue, or if a separate issue needs to be logged. Details below.
[#44431] [Backport93 - Backport #6314][Open] Backport r35374 and r35375 — "drbrain (Eric Hodel)" <drbrain@...7.net>
[#44432] [ruby-trunk - Feature #6315][Open] handler to trace output of each line of code executed — "ankopainting (Anko Painting)" <anko.com+ruby@...>
[#44533] [ruby-trunk - Bug #6341][Open] SIGSEGV: Thread.new { fork { GC.start } }.join — "rudolf (r stu3)" <redmine@...>
Hello,
On Mon, Apr 23, 2012 at 11:17 PM, Yusuke Endoh <mame@tsg.ne.jp> wrote:
Hello,
(4/24/12 6:55 AM), Yusuke Endoh wrote:
> kosaki (Motohiro KOSAKI) wrote:
[#44540] [ruby-trunk - Bug #6343][Open] Improved Fiber documentation — "andhapp (Anuj Dutta)" <anuj@...>
[#44612] [ruby-trunk - Feature #6354][Open] Remove escape (break/return/redo/next support) from class/module scope — "ko1 (Koichi Sasada)" <redmine@...>
[#44630] [ruby-trunk - Feature #6361][Open] Bitwise string operations — "MartinBosslet (Martin Bosslet)" <Martin.Bosslet@...>
On Fri, Apr 27, 2012 at 8:53 PM, MartinBosslet (Martin Bosslet)
On Saturday, April 28, 2012 at 8:52 AM, KOSAKI Motohiro wrote:
[#44636] [ruby-trunk - Bug #6364][Open] Segmentation fault happend when running test_cptr.rb — "raylinn@... (ray linn)" <raylinn@...>
[#44667] possible YAML bug in ruby 1.9.3p125? — Young Hyun <youngh@...>
YAML in ruby 1.9.3p125 seems to have a bug reading in YAML from older Ruby versions. Specifically, YAML in 1.9.3p125 mis-parses text like "123_456" as a number (just as in Ruby) rather than as a string, which appears to be the correct behavior according to the YAML specification.
[#44686] [BUG] not a node 0x07 — ronald braswell <rpbraswell@...>
Running ruby 1.8.6 on Solaris 10.
2012/4/28 ronald braswell <rpbraswell@gmail.com>:
I have heard reports of this on 1.9.x. Do you know if this problem has
[#44704] [ruby-trunk - Feature #6373][Open] public #self — "trans (Thomas Sawyer)" <transfire@...>
Issue #6373 has been updated by Marc-Andre Lafortune.
[#44743] [ruby-trunk - Feature #6375][Open] Python notation for literal Hash — "alexeymuranov (Alexey Muranov)" <redmine@...>
[#44748] [ruby-trunk - Feature #6376][Open] Feature lookup and checking if feature is loaded — "trans (Thomas Sawyer)" <transfire@...>
On Thu, May 3, 2012 at 6:02 AM, mame (Yusuke Endoh) <mame@tsg.ne.jp> wrote:
[ruby-core:44350] [ruby-trunk - Bug #6288][Assigned] Change error message for thread block to be less misleading
Issue #6288 has been updated by mame (Yusuke Endoh).
Status changed from Feedback to Assigned
Assignee set to mame (Yusuke Endoh)
Hello,
2012/4/14 rklemme (Robert Klemme) <shortcutter@googlemail.com>:
> mame (Yusuke Endoh) wrote:
>> Is "possible deadlock detected" better?
>
> If I understand properly what the deadlock check does (see also #5258) it merely verifies that there is at least one thread left which could wake up this thread. So I'd rather have something like "No live threads left. Deadlock?", but then again my understanding of the code in question is not too thorough.
Looks reasonable to me. I'll commit unless there is no objection.
>> Please elaborate "a more complex scenario" with small example.
>
> $ ruby19 -r thread -e 'q=SizedQueue.new(100);r=Thread.new {until (x=q.deq).nil?; raise "SilentError";end};1000.times {|i| q.enq i};q.enq nil'
> /opt/lib/ruby/1.9.1/thread.rb:301:in `sleep': deadlock detected (fatal)
> from /opt/lib/ruby/1.9.1/thread.rb:301:in `block in push'
> from <internal:prelude>:10:in `synchronize'
> from /opt/lib/ruby/1.9.1/thread.rb:297:in `push'
> from -e:1:in `block in <main>'
> from -e:1:in `times'
> from -e:1:in `<main>'
>
> Basically what happens is that the reader thread silently dies as you can see if you set Thread.abort_on_exception:
It does not make sense. Did you write the code to wait forever?
If so, you should write "sleep" simply. If not, your code is
actually "deadlocked", in a common sense.
Why didn't you insist that Thread.abort_on_exception be true by
default? I can't understand why you blame deadlock detection.
--
Yusuke Endoh <mame@tsg.ne.jp>
----------------------------------------
Bug #6288: Change error message for thread block to be less misleading
https://bugs.ruby-lang.org/issues/6288#change-25892
Author: rklemme (Robert Klemme)
Status: Assigned
Priority: Normal
Assignee: mame (Yusuke Endoh)
Category: core
Target version:
ruby -v: ruby 1.9.3p125 (2012-02-16) [i386-cygwin]
Test case:
11:50:07 ~$ ruby19 -r thread -e 'q=SizedQueue.new 10;1_000_000.times {|i| p i;q.enq i}'
0
1
2
3
4
5
6
7
8
9
10
/opt/lib/ruby/1.9.1/thread.rb:301:in `sleep': deadlock detected (fatal)
from /opt/lib/ruby/1.9.1/thread.rb:301:in `block in push'
from <internal:prelude>:10:in `synchronize'
from /opt/lib/ruby/1.9.1/thread.rb:297:in `push'
from -e:1:in `block in <main>'
from -e:1:in `times'
from -e:1:in `<main>'
This is not a deadlock, but there is no other thread which could wake up main thread. Deadlock is misleading because in a more complex scenario where I had the error initially it wasn't obvious that the other thread had died and I looked for the wrong error in my code.
--
http://bugs.ruby-lang.org/