Nabble - ruby-core

[ruby-core:26932] [Bug #2389] REXML rails to format parsed SVGs created with inkscape

2009-11-28T17:47:06Z

Issue #2389 has been updated by Aaron Patterson.

Not sure why this isn't closed yet.

I've fixed it in r25956, but I don't seem to have permissions in redmine to close this ticket.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2389

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26931] Re: something broke ruby floats

2009-11-28T14:14:51Z

CC'ing ruby-core@

On Nov 28, 2009, at 09:38 , Joel VanderWerf wrote:

>
> Noticed this after rebuilding ruby (with configure args --disable-pthread --enable-shared):
>
> ~/src/ruby> RUBYOPT='' ./ruby -e 'x=0.123; puts x'
> 123.0
> ~/src/ruby> ldd ./ruby
> linux-gate.so.1 => (0x00b0e000)
> libruby.so.1.8 => /usr/local/lib/libruby.so.1.8 (0x00236000)
> libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00132000)
> libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0x007b8000)
> libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x00d63000)
> libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00394000)
> /lib/ld-linux.so.2 (0x0067e000)
> ~/src/ruby> ./ruby -v
> ruby 1.8.6 (2008-08-11 patchlevel 287) [i686-linux]
>
> (same after make install)
>
> Any ideas what broke? I've never seen anything like this before, and I've been using p287 on several systems for months (at least). This is on ubuntu karmic.
>
> Further info:
>
> ~/src/ruby> make check
> not ok float 1 -- ./sample/test.rb:1172
> not ok float 2 -- ./sample/test.rb:1173
> not ok float 3 -- ./sample/test.rb:1174
> not ok float 4 -- ./sample/test.rb:1175
> not ok float 5 -- ./sample/test.rb:1176
> not ok float 6 -- ./sample/test.rb:1177
> not ok float 7 -- ./sample/test.rb:1178
> not ok float 8 -- ./sample/test.rb:1179
> not ok float 9 -- ./sample/test.rb:1180
> test failed
> make: *** [test] Error 1
>
> --
> vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
>
>

[ruby-core:26930] [Bug #2396](Third Party's Issue) Time.strftime returns a wrong time zone as hour offset (%z)

2009-11-28T05:27:48Z

Issue #2396 has been updated by Nobuyoshi Nakada.

File tz.c added
Status changed from Assigned to Third Party's Issue

Seems a bug of Mac OS X's strftime().

$ uname -v
Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386
$ ./tz
tm_gmtoff = +0900, tm_zone = KST
tm_gmtoff = +0800, tm_zone = KST

Ruby 1.9 doesn't have this issue, since it uses missing/strftime.c.

----------------------------------------
http://redmine.ruby-lang.org/issues/show/2396

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26929] [Bug #2396] Time.strftime returns a wrong time zone as hour offset (%z)

2009-11-27T19:02:58Z

Issue #2396 has been updated by Chulki Lee.

Maybe a platform-dependent problem? (tzdata?)

Ubuntu 9.04, package ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]
=> working CORRECTLY - "+0900 (KST)"

Mac OS X 10.6.2, macport ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin10]
=> working INCORRECTLY - "+0800 (KST)"

Mac OS X 10.6.2, apple ruby 1.8.7 (2008-08-11 patchlevel 72) [universal-darwin10.0]
=> working INCORRECTLY - "+0800 (KST)"
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2396

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26928] Re: Caching #to_s for immutables (and a possible future for constant-folding)

2009-11-27T18:48:21Z

NARUSE, Yui wrote:
> Kurt Stephens wrote:
>> I have a proof-of-concept patch to MRI that caches #to_s values for
>> immutable values. It is implemented using a few fixed size hash tables.
>
> I'm interested this idea,
>
I'll clean it up and send it along in the next couple days.

>> It requires a minor semantic change to Ruby core. In practice, most
>> Ruby String literals quickly become garbage. This minor change could
>> cascade into a huge performance improvement for all Ruby implementations
>> -- as will be illustrated below:
>>
>> #to_s may return frozen Strings.
>
> This restriction seems big.

The "restriction" is what makes it possible.

>
>> Let me know if anyone is interested in this idea and patch:
>
> If you have a patch, attach it, and we can try it in real world.
>

[ruby-core:26927] [Bug #1730](Closed) Returning inside for loop inside lambda crashes

2009-11-27T14:10:54Z

Issue #1730 has been updated by ujihisa ..

Status changed from Open to Closed

This change is intentional. The return behaviours are different between 1.8 and 1.9.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1730

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26926] [Feature #2408] better error reporting in windows when you try to run a directory

2009-11-27T11:17:10Z

Issue #2408 has been updated by Vladimir Sizikov.

Yeah, *all* MRI versions from 1.8.6, through 1.8.7, 1.9.0, 1.9.1, 1.9.2-dev, all report "Permission denied" on Windows. Except for cygwin ruby :) Actually, even JRuby reports Permission denied.

This difference between platforms is indeed unfortunate.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2408

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26925] [Feature #2408] better error reporting in windows when you try to run a directory

2009-11-27T10:48:07Z

Feature #2408: better error reporting in windows when you try to run a directory
http://redmine.ruby-lang.org/issues/show/2408

Author: Roger Pack
Status: Open, Priority: Normal

Currently in linux, you may get this:

$ ruby -c wbo_backup
ruby: Is a directory - wbo_backup (Errno::EISDIR)

however we are not so fortunate in windows

C:\dev\ruby\p2pwebclient\documents\writeup\final>ruby logs
ruby: Permission denied -- logs (LoadError)

It would be nice to get a similar error message in windows.

Thanks!
-r

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26924] Re: [Bug #2378] Regression in ParseDate.parsedate('nn-nn')

2009-11-27T02:31:15Z

On 2009/11/25 23:29, Rick DeNatale wrote:

> On Mon, Nov 23, 2009 at 9:59 PM, Hiro Asari<redmine@...> wrote:
>> Issue #2378 has been updated by Hiro Asari.
>>
>>
>> I beg to differ. If you tell 100 programmers that "11-09" is some combination of date and time, I wager that the vast majority will answer: "November 9th", "11th of September" or "November, 2009", maybe "2011 September".
>>
>> Maybe we should only support ISO 8601, in which case "nn-nn" seems invalid (please correct me if I'm wrong).
>
> ISO 8601 is really for computer interchange of time date information
> as I understand it.
>
> That's important, but most use cases of date parsing would I think
> deal with parsing user input, and that has to deal with the vagaries
> of world culture:
>
> http://en.wikipedia.org/wiki/Date_and_time_notation_by_country
>
> To most non-Americans 9/11 means September 11, but to the rest of the

I think that should read "To most Americans 9/11 means September 11".

> world it means November 9. Personally when I write dates I tend to
> write either 11 September or 9 November for this reason.
>
> Ruby 1.8 tried to deal with this with heuristics, but I realize that
> the problem is pretty hard,

Yes. "pretty hard" is a strong understatement, actually.

Regards, Martin.

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@...

[ruby-core:26923] [Bug #2406] Regression in RSS 2.0 creation

2009-11-27T01:20:35Z

Bug #2406: Regression in RSS 2.0 creation
http://redmine.ruby-lang.org/issues/show/2406

Author: Petteri Räty
Status: Open, Priority: Normal
ruby -v: ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-linux]

I used to be able to use Strings for dates in ruby 1.8.6 but it doesn't work any more:

<pre><code class="ruby">
i.date = (d >> 1).strftime('%a, %d %b %Y %H:%M:%S %z')
</pre></code>

Results

<pre>
/per/usr/lib64/ruby/1.8/rss/dublincore.rb:143:in `content=': value <Wed, 25 Nov 2009 00:00:00 +0000> of tag <dc:date> is not available. (RSS::NotAvailableValueError)
from /usr/lib64/ruby/1.8/rss/dublincore.rb:114:in `initialize'
from /usr/lib64/ruby/1.8/rss/utils.rb:31:in `new'
from /usr/lib64/ruby/1.8/rss/utils.rb:31:in `new_with_value_if_need'
from /usr/lib64/ruby/1.8/rss/dublincore.rb:30:in `dc_date='
from /usr/lib64/ruby/1.8/rss/dublincore.rb:41:in `date='
from /usr/lib64/ruby/1.8/rss/maker/base.rb:226:in `__send__'
from /usr/lib64/ruby/1.8/rss/maker/base.rb:226:in `setup_values'
from /usr/lib64/ruby/1.8/rss/maker/base.rb:221:in `each'
from /usr/lib64/ruby/1.8/rss/maker/base.rb:221:in `setup_values'
from /usr/lib64/ruby/1.8/rss/maker/0.9.rb:260:in `to_feed'
from /usr/lib64/ruby/1.8/rss/maker/0.9.rb:251:in `to_feed'
from /usr/lib64/ruby/1.8/rss/maker/0.9.rb:250:in `each'
from /usr/lib64/ruby/1.8/rss/maker/0.9.rb:250:in `to_feed'
from /usr/lib64/ruby/1.8/rss/maker/0.9.rb:44:in `setup_items'
from /usr/lib64/ruby/1.8/rss/maker/0.9.rb:32:in `to_feed'
from /usr/lib64/ruby/1.8/rss/maker/base.rb:370:in `setup_channel'
from /usr/lib64/ruby/1.8/rss/maker/0.9.rb:21:in `setup_elements'
from /usr/lib64/ruby/1.8/rss/maker/base.rb:406:in `to_feed'
from /usr/lib64/ruby/1.8/rss/maker/base.rb:397:in `make'
from /usr/lib64/ruby/1.8/rss/maker/base.rb:361:in `make'
from /usr/lib64/ruby/1.8/rss/maker.rb:11:in `make'
from /home/betelgeuse/bin/rss-changelog:153
</pre>

The full script is here http://github.com/betelgeuse/scripts/blob/324ec2a18d473c39dfd9e3e12edc4fc0ecaa5990/rss-changelog

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26922] [Bug #2147](Closed) Cannot pp DelegateClass derived classes: undefined method `inspect' NameError

2009-11-26T18:57:07Z

Issue #2147 has been updated by Yuki Sonoda.

Status changed from Open to Closed
% Done changed from 0 to 100

This issue was solved with changeset r25951.
Mike, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

----------------------------------------
http://redmine.ruby-lang.org/issues/show/2147

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26921] [Bug #1157] missing zlib.rb?

2009-11-26T15:06:09Z

Issue #1157 has been updated by Ryan Bigg.

I too have encountered this issue with a completely bare-bones installation of Ruby 1.9.1-p243.

To fix it, I followed Lutz steps about downloading and compiling zlib and then I cd'd into the /ext/zlib directory, ran ruby extconf.rb && make && sudo make install then "sudo gem install rails" worked. I feel that going through the whole Ruby ./configure && make && sudo make install process is excessive.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1157

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26920] Re: email from redmine

2009-11-26T14:37:13Z

> On Tue, Nov 24, 2009 at 12:17 PM, <danielcavanagh@...> wrote:
>> i'm just wondering how i get redmine to send out an email to this list
>> when i update an issue. i made an update on the 17th and it still hasn't
>> come through (to this list), so i'm guessing there is something else i
>> need to do?
>
> Which issue? It was possibly a bug of redmine.
>
> -- Yuki Sonoda (Yugui)

thanks yugui

the issue is http://redmine.ruby-lang.org/issues/show/452

[ruby-core:26919] Re: email from redmine

2009-11-26T14:29:31Z

[ruby-core:26918] [Backport #2326] 1.8.7 Segmentation fault

2009-11-26T11:50:20Z

Issue #2326 has been updated by Bryan McLellan.

I'm sending a patch containing Kirk's fix to debian and ubuntu as it is affecting a number of users on Ubuntu 9.10 (karmic).

https://bugs.launchpad.net/ruby/+bug/488115
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557924
http://tickets.opscode.com/browse/CHEF-530
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2326

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26917] Re: email from redmine

2009-11-26T03:47:23Z

On Tue, Nov 24, 2009 at 12:17 PM, <danielcavanagh@...> wrote:
> i'm just wondering how i get redmine to send out an email to this list
> when i update an issue. i made an update on the 17th and it still hasn't
> come through (to this list), so i'm guessing there is something else i
> need to do?

Which issue? It was possibly a bug of redmine.

-- Yuki Sonoda (Yugui)

[ruby-core:26916] [Bug #2404](Closed) [PATCH] force_encoding on frozen string in gem_prelude

2009-11-26T03:45:52Z

Issue #2404 has been updated by Yui NARUSE.

Category set to core
Status changed from Assigned to Closed
Target version set to 1.9.2

fixed at r25932.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2404

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26915] Re: Caching #to_s for immutables (and a possible future for constant-folding)

2009-11-26T03:43:06Z

Kurt Stephens wrote:
> I have a proof-of-concept patch to MRI that caches #to_s values for
> immutable values. It is implemented using a few fixed size hash tables.

I'm interested this idea,

> It requires a minor semantic change to Ruby core. In practice, most
> Ruby String literals quickly become garbage. This minor change could
> cascade into a huge performance improvement for all Ruby implementations
> -- as will be illustrated below:
>
> #to_s may return frozen Strings.

This restriction seems big.

> Let me know if anyone is interested in this idea and patch:

If you have a patch, attach it, and we can try it in real world.

--
NARUSE, Yui <naruse@...>

[ruby-core:26914] [Bug #2403](Closed) Segment fault when converting method to block

2009-11-25T22:54:05Z

Issue #2403 has been updated by Nobuyoshi Nakada.

Status changed from Assigned to Closed

Already fixed in 1.8.7 (2009-02-19 patchlevel 128).
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2403

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26913] [Feature #2022](Assigned) Patch for openssl-1.0

2009-11-25T17:52:36Z

Issue #2022 has been updated by Yui NARUSE.

Status changed from Open to Assigned

What's current status?
Fedora 12 uses openssl 1.0 Beta 3; So Fedora people can't build ruby now.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2022

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26912] [Bug #2404] [PATCH] force_encoding on frozen string in gem_prelude

2009-11-25T13:37:19Z

Issue #2404 has been updated by Jeremy Kemper.

To replicate on any platform:

GEM_HOME=foo ruby -e ''

Verified that the patch fixes it.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2404

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26911] [Bug #2404] [PATCH] force_encoding on frozen string in gem_prelude

2009-11-25T13:07:32Z

Issue #2404 has been updated by Sam Ruby.

Problem only occurs if the GEM_HOME environment variable is set.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2404

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26910] [Bug #2404] [PATCH] force_encoding on frozen string in gem_prelude

2009-11-25T12:46:07Z

Bug #2404: [PATCH] force_encoding on frozen string in gem_prelude
http://redmine.ruby-lang.org/issues/show/2404

Author: Sam Ruby
Status: Open, Priority: High
Category: core
ruby -v: ruby 1.9.2dev (2009-11-26 trunk 25926) [i686-linux]

Simply entering any gem command or even irb on Ubuntu produces the following:

Error loading gem paths on load path in gem_prelude
can't modify frozen string
<internal:gem_prelude>:70:in `force_encoding'
<internal:gem_prelude>:70:in `set_home'
<internal:gem_prelude>:38:in `dir'
<internal:gem_prelude>:83:in `set_paths'
<internal:gem_prelude>:47:in `path'
<internal:gem_prelude>:227:in `push_all_highest_version_gems_on_load_path'
<internal:gem_prelude>:301:in `<compiled>'

Note: on Linux, File::ALT_SEPARATOR=nil, so the gsub will not be executed.

Patch attached.

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26909] [Bug #2403] Segment fault when converting method to block

2009-11-25T10:48:00Z

Bug #2403: Segment fault when converting method to block
http://redmine.ruby-lang.org/issues/show/2403

Author: Jan Berdajs
Status: Open, Priority: High
ruby -v: ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]

When trying to convert a method to a block with the ampersand operator, I get a segfault. I'm on Ubuntu, ruby from packages (see version).
Test code: http://www.pastie.org/714918
Temp. fix: change &:metoda to &method(:metoda)

Error output:
test.rb:10: [BUG] Segmentation fault
ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]

Aborted

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26908] [Bug #2394] [BUG] pthread_mutex_lock: 22 revisited

2009-11-25T08:40:15Z

Issue #2394 has been updated by Roger Pack.

ruby -e 'fork { puts }' doesn't seem to quite do it, though maybe it would if I ran it over and over again.

Here's a more minimalistic test for it (reproduces every time):

require 'forkoff' # gem
a = File.open('bii', 'w')
[1].forkoff { |n|
a.write '1'
}

[BUG] pthread_mutex_lock: Invalid argument (EINVAL)
ruby 1.9.2dev (2009-11-26 trunk 25926) [i686-linux]

-- control frame ----------
---------------------------

-- C level backtrace information -------------------------------------------
/home/rdp/installs/ruby_trunk_installed//lib/libruby.so.1.9(rb_vm_bugreport+0x72) [0xb7e76992]
/home/rdp/installs/ruby_trunk_installed//lib/libruby.so.1.9 [0xb7d53581]
/home/rdp/installs/ruby_trunk_installed//lib/libruby.so.1.9(rb_bug+0x3a) [0xb7d5363a]
/home/rdp/installs/ruby_trunk_installed//lib/libruby.so.1.9(rb_bug_errno+0x7f5) [0xb7d543c5]
/home/rdp/installs/ruby_trunk_installed//lib/libruby.so.1.9(rb_thread_blocking_region+0x1fa) [0xb7e7d35a]
/home/rdp/installs/ruby_trunk_installed//lib/libruby.so.1.9 [0xb7d78d9a]
/home/rdp/installs/ruby_trunk_installed//lib/libruby.so.1.9 [0xb7d7b2be]
/home/rdp/installs/ruby_trunk_installed//lib/libruby.so.1.9(rb_io_fptr_finalize+0xe4) [0xb7d7b4d4]
/home/rdp/installs/ruby_trunk_installed//lib/libruby.so.1.9 [0xb7d69746]
/home/rdp/installs/ruby_trunk_installed//lib/libruby.so.1.9 [0xb7d6a632]
/home/rdp/installs/ruby_trunk_installed//lib/libruby.so.1.9(ruby_cleanup+0x12e) [0xb7d58f9e]
/home/rdp/installs/ruby_trunk_installed//lib/libruby.so.1.9 [0xb7e7c71e]
/home/rdp/installs/ruby_trunk_installed//lib/libruby.so.1.9 [0xb7e7c761]
/lib/libpthread.so.0 [0xb7cdffc0]
/lib/libc.so.6(clone+0x5e) [0xb7bfea1e]
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2394

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26907] Re: [Bug #2378] Regression in ParseDate.parsedate('nn-nn')

2009-11-25T06:29:19Z

On Mon, Nov 23, 2009 at 9:59 PM, Hiro Asari <redmine@...> wrote:
> Issue #2378 has been updated by Hiro Asari.
>
>
> I beg to differ. If you tell 100 programmers that "11-09" is some combination of date and time, I wager that the vast majority will answer: "November 9th", "11th of September" or "November, 2009", maybe "2011 September".
>
> Maybe we should only support ISO 8601, in which case "nn-nn" seems invalid (please correct me if I'm wrong).

ISO 8601 is really for computer interchange of time date information
as I understand it.

That's important, but most use cases of date parsing would I think
deal with parsing user input, and that has to deal with the vagaries
of world culture:

http://en.wikipedia.org/wiki/Date_and_time_notation_by_country

To most non-Americans 9/11 means September 11, but to the rest of the
world it means November 9. Personally when I write dates I tend to
write either 11 September or 9 November for this reason.

Ruby 1.8 tried to deal with this with heuristics, but I realize that
the problem is pretty hard,

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

[ruby-core:26906] Re: [Bug #1525](Closed) Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork?

2009-11-25T01:48:08Z

On 25/11/2009, at 5:57 PM, Tanaka Akira wrote:

> In article <4B07C4C5.8060102@...>,
> Hongli Lai <hongli@...> writes:
>
>>> % ./ruby -e 'fork { puts }'
>>> -e:1: [BUG] native_mutex_unlock return non-zero: 1
>>> ruby 1.9.2dev (2009-11-19 trunk 25848) [x86_64-freebsd6.4]
>>
>> This is what I get on FreeBSD 7.1-RELEASE:
>
> FreeBSD 8.0-RELEASE behaves similar to FreeBSD 6.4.
>
> % uname -mrsv
> FreeBSD 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 root@...:/usr/obj/usr/src/sys/GENERIC i386
> % ./ruby -e 'fork { puts }'
> -e:1: [BUG] pthread_mutex_unlock: Operation not permitted (EPERM)
> ruby 1.9.2dev (2009-11-25 trunk 25911) [i386-freebsd8.0]
>
> -- control frame ----------
> c:0009 p:---- s:0020 b:0020 l:000019 d:000019 CFUNC :write
> c:0008 p:---- s:0018 b:0018 l:000017 d:000017 CFUNC :puts
> c:0007 p:---- s:0016 b:0016 l:000015 d:000015 CFUNC :puts
> c:0006 p:0009 s:0013 b:0013 l:0010a4 d:000012 BLOCK -e:1
> c:0005 p:---- s:0011 b:0011 l:000010 d:000010 FINISH
> c:0004 p:---- s:0009 b:0009 l:000008 d:000008 CFUNC :fork
> c:0003 p:0009 s:0006 b:0006 l:0010a4 d:000004 EVAL -e:1
> c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
> c:0001 p:0000 s:0002 b:0002 l:0010a4 d:0010a4 TOP
> ---------------------------
> -e:1:in `<main>'
> -e:1:in `fork'
> -e:1:in `block in <main>'
> -e:1:in `puts'
> -e:1:in `puts'
> -e:1:in `write'

exactly the same thing happens on netbsd 5.0.1, if that helps

[ruby-core:26905] [Backport #2267](Assigned) IO#sync = true causes offset to not be updated after writing on OS X/FreeBSD

2009-11-25T00:48:04Z

Issue #2267 has been updated by Shyouhei Urabe.

Status changed from Closed to Assigned
Assigned to set to Kirk Haines

I don't have neither environment to reproduce so please reject it if not, but it seems to me that this issue affects 1.8.6.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2267

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26904] Re: [Bug #1525](Closed) Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork?

2009-11-24T23:57:29Z

In article <4B07C4C5.8060102@...>,
Hongli Lai <hongli@...> writes:

>> % ./ruby -e 'fork { puts }'
>> -e:1: [BUG] native_mutex_unlock return non-zero: 1
>> ruby 1.9.2dev (2009-11-19 trunk 25848) [x86_64-freebsd6.4]
>
> This is what I get on FreeBSD 7.1-RELEASE:

FreeBSD 8.0-RELEASE behaves similar to FreeBSD 6.4.

% uname -mrsv
FreeBSD 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 root@...:/usr/obj/usr/src/sys/GENERIC i386
% ./ruby -e 'fork { puts }'
-e:1: [BUG] pthread_mutex_unlock: Operation not permitted (EPERM)
ruby 1.9.2dev (2009-11-25 trunk 25911) [i386-freebsd8.0]

-- control frame ----------
c:0009 p:---- s:0020 b:0020 l:000019 d:000019 CFUNC :write
c:0008 p:---- s:0018 b:0018 l:000017 d:000017 CFUNC :puts
c:0007 p:---- s:0016 b:0016 l:000015 d:000015 CFUNC :puts
c:0006 p:0009 s:0013 b:0013 l:0010a4 d:000012 BLOCK -e:1
c:0005 p:---- s:0011 b:0011 l:000010 d:000010 FINISH
c:0004 p:---- s:0009 b:0009 l:000008 d:000008 CFUNC :fork
c:0003 p:0009 s:0006 b:0006 l:0010a4 d:000004 EVAL -e:1
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:0010a4 d:0010a4 TOP
---------------------------
-e:1:in `<main>'
-e:1:in `fork'
-e:1:in `block in <main>'
-e:1:in `puts'
-e:1:in `puts'
-e:1:in `write'

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html
--
Tanaka Akira

[ruby-core:26903] [Backport #2240](Assigned) returning from Monitor#synchronize causes 'ThreadError: killed thread' when no waiting thread is alive

2009-11-24T23:47:31Z

Issue #2240 has been updated by Shyouhei Urabe.

Status changed from Closed to Assigned
Assigned to set to Kirk Haines

1.8.6 also fails on this test case.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2240

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26902] [Backport #2202](Assigned) Call to a removed method doesn't raise an exception

2009-11-24T23:23:39Z

Issue #2202 has been updated by Shyouhei Urabe.

Status changed from Closed to Assigned
Assigned to set to Kirk Haines
Priority changed from High to Normal

As the original message reports, 1.8.6 has this issue and should backport the fix.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2202

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26901] Re: [Bug #2400] string formating in, e. g. rb_raise, is truncated differently depending on OS/build environment

2009-11-24T22:05:13Z

Hi,

At Wed, 25 Nov 2009 09:22:52 +0900,
Florian Frank wrote in [ruby-core:26899]:
> I am not sure if this is a problem. A method like this:

I don't think it is.

> The same happens also in rb_warn and maybe a lot of other
> ruby functions. Apparently the variable BUFSIZ defined in
> stdio.h determines the length of this formatting buffer in
> the source file error.c, but it has a different value on
> different platforms. Maybe the buffers should all have the
> same length?

Rather, you should get rid of such too long messages, IMO.
Who wants to see the flood by a message?

--
Nobu Nakada

[ruby-core:26900] [Bug #2378] Regression in ParseDate.parsedate('nn-nn')

2009-11-24T21:42:43Z

Issue #2378 has been updated by Hiro Asari.

I agree that the intended meaning of "11-09" is ambiguous, but the current behavior is surprising all the same.

I am OK with Ruby behaving the way it is, as long as it is specified.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2378

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26899] [Bug #2400] string formating in, e. g. rb_raise, is truncated differently depending on OS/build environment

2009-11-24T16:22:52Z

Bug #2400: string formating in, e. g. rb_raise, is truncated differently depending on OS/build environment
http://redmine.ruby-lang.org/issues/show/2400

Author: Florian Frank
Status: Open, Priority: Normal
Category: core
ruby -v: ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin9.7.0]

I am not sure if this is a problem. A method like this:

static VALUE mFoo_raise(VALUE self, VALUE msg)
{
rb_raise(rb_eRuntimeError, "'%s'", RSTRING_PTR(msg));
}

causes different length in Exception#message on different platforms:

>> [ RUBY_PLATFORM, RUBY_VERSION, RUBY_PATCHLEVEL ] * ' '
# => "i686-linux 1.8.7 174"
>> Foo.raise "a" * 10_000 rescue $!.message.size
# => 8191

>> [ RUBY_PLATFORM, RUBY_VERSION, RUBY_PATCHLEVEL ] * ' '
# => "i686-darwin9.7.0 1.8.7 174"
>> Foo.raise "a" * 10_000 rescue $!.message.size
# => 1023

Under Windows this seems to be 511.

The same happens also in rb_warn and maybe a lot of other ruby functions. Apparently the variable BUFSIZ defined in stdio.h determines the length of this formatting buffer in the source file error.c, but it has a different value on different platforms. Maybe the buffers should all have the same length?

----------------------------------------
http://redmine.ruby-lang.org

[ruby-core:26898] [Bug #2399] pthread_mutex_lock: 22

2009-11-24T12:15:41Z

Bug #2399: pthread_mutex_lock: 22
http://redmine.ruby-lang.org/issues/show/2399

Author: Tim Pease
Status: Open, Priority: Normal
ruby -v: ruby 1.9.1p243

While working with some code that is forking two children and then registering signal handlers in the child processes, the following error crops up from time to time. The children are trapping on SIGHUP and then sending a message to the parent process (using a unix socket pair) that will restart the child.

[BUG] pthread_mutex_lock: 22
ruby 1.9.1p243 (2009-07-16 revision 24175) [i686-darwin10.2.0]

-- control frame ----------
---------------------------
-- Ruby level backtrace information-----------------------------------------

-- C level backtrace information -------------------------------------------
0x1001085ed 0 ruby 0x00000001001085ed rb_vm_bugreport + 77
0x100027ce4 1 ruby 0x0000000100027ce4 report_bug + 260
0x100027e78 2 ruby 0x0000000100027e78 rb_bug + 200
0x100108f0f 3 ruby 0x0000000100108f0f native_mutex_lock + 31
0x10010c3be 4 ruby 0x000000010010c3be set_unblock_function + 78
0x10010e2cd 5 ruby 0x000000010010e2cd rb_thread_blocking_region + 93
0x1000404ac 6 ruby 0x00000001000404ac rb_write_internal + 44
0x1000472ff 7 ruby 0x00000001000472ff io_binwrite + 383
0x1000476e0 8 ruby 0x00000001000476e0 io_write + 528
0x100102521 9 ruby 0x0000000100102521 vm_call0 + 833
0x10010296f 10 ruby 0x000000010010296f rb_funcall + 527
0x100042192 11 ruby 0x0000000100042192 rb_io_puts + 114
0x1000f8b51 12 ruby 0x00000001000f8b51 vm_call_cfunc + 337
0x1000fa400 13 ruby 0x00000001000fa400 vm_call_method + 896
0x1000fb33c 14 ruby 0x00000001000fb33c vm_exec_core + 3164
0x10010054e 15 ruby 0x000000010010054e vm_exec + 1102
0x100101f93 16 ruby 0x0000000100101f93 rb_vm_invoke_proc + 691
0x10010cfe3 17 ruby 0x000000010010cfe3 thread_start_func_2 + 835
0x10010d101 18 ruby 0x000000010010d101 thread_start_func_1 + 17
0x7fff84bc6f8e 19 libSystem.B.dylib 0x00007fff84bc6f8e _pthread_start + 331
0x7fff84bc6e41 20 libSystem.B.dylib 0x00007fff84bc6e41 thread_start + 13

[NOTE]
You may encounter a bug of Ruby interpreter. Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html

----------------------------------------
http://redmine.ruby-lang.org