[#6864] ruby 1.8.4 rc breaks alias_method/rails in bad ways — "Ara.T.Howard" <ara.t.howard@...>

20 messages 2005/12/09
[#6870] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — =?ISO-8859-15?Q?Florian_Gro=DF?= <florgro@...> 2005/12/12

Ara.T.Howard wrote:

[#6872] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — ara.t.howard@... 2005/12/12

On Tue, 13 Dec 2005, [ISO-8859-15] Florian Growrote:

[#6873] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — James Edward Gray II <james@...> 2005/12/12

On Dec 12, 2005, at 1:19 PM, ara.t.howard@noaa.gov wrote:

[#6874] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — ara.t.howard@... 2005/12/12

On Tue, 13 Dec 2005, James Edward Gray II wrote:

[#6891] Time.utc! and Time.localtime! — Daniel Hobe <hobe@...>

Writing a script yesterday I found out, much to my surprise, that the

16 messages 2005/12/14

[#6918] change to yaml in 1.8.4 — ara.t.howard@...

14 messages 2005/12/16

[#6934] 1.8.x, YAML, and release management — Ryan Davis <ryand-ruby@...>

I'm concerned that 1.8.3's acceptance of non-backwards-compatible

28 messages 2005/12/18

[#6996] Problems building 1.8.4 with VS8 C++ Express Edition (cl 14.00) — Austin Ziegler <halostatue@...>

Visual Studio C++ 2005 Express Edition (VS 8.0)

20 messages 2005/12/27

Re: Ruby + GCC4 on OS X (Was: Strange error messages using DRb/TupleSpace{

From: Steven Lumos <steven@...>
Date: 2005-12-22 23:00:54 UTC
List: ruby-core #6983
Eric Hodel <drbrain@segment7.net> writes:
> On Dec 3, 2005, at 2:39 PM, Eric Hodel wrote:
>
>> On Nov 15, 2005, at 3:44 PM, Eric Hodel wrote:
>>
>>> Using
>>>
>>> $ ruby184p1 -v
>>> ruby 1.8.4 (2005-10-29) [powerpc-darwin8.3.0]
>>>
>>> or
>>>
>>> $ ruby182-orig -v
>>> ruby 1.8.2 (2004-12-25) [powerpc-darwin8.0]
>>>
>>> or
>>>
>>> $ ruby -v
>>> ruby 1.8.3 (2005-09-21) [powerpc-darwin8.2.0]
>>>
>>> Using the scripts in [ruby-talk:165935] I receive strange errors
>>> that crash the client process that all look like this:
>>>
>>> (druby://localhost:61676) /usr/local/lib/ruby/1.8/rinda/
>>> tuplespace.rb:446:in `move': undefined method `push'  for
>>> :compact!:Symbol (NoMethodError)
>>>         from (druby://localhost:61676) /usr/local/lib/ruby/1.8/
>>> monitor.rb:229:in `synchronize'
>>>         from (druby://localhost:61676) /usr/local/lib/ruby/1.8/
>>> rinda/tuplespace.rb:443:in `move'
>>>         from (druby://localhost:61676) /usr/local/lib/ruby/1.8/drb/
>>> drb.rb:1552:in `perform_without_block'
>>>         from (druby://localhost:61676) /usr/local/lib/ruby/1.8/drb/
>>> drb.rb:1512:in `perform'
>>>         from (druby://localhost:61676) /usr/local/lib/ruby/1.8/drb/
>>> drb.rb:1586:in `main_loop'
>>>         from (druby://localhost:61676) /usr/local/lib/ruby/1.8/drb/
>>> drb.rb:1582:in `main_loop'
>>>         from (druby://localhost:61676) /usr/local/lib/ruby/1.8/drb/
>>> drb.rb:1578:in `main_loop'
>>>         from (druby://localhost:61676) /usr/local/lib/ruby/1.8/drb/
>>> drb.rb:1427:in `run'
>>>         from (druby://localhost:61676) /usr/local/lib/ruby/1.8/drb/
>>> drb.rb:1424:in `run'
>>>         from (druby://localhost:61676) /usr/local/lib/ruby/1.8/drb/
>>> drb.rb:1344:in `initialize'
>>>         from (druby://localhost:61676) /usr/local/lib/ruby/1.8/drb/
>>> drb.rb:1624:in `start_service'
>>>         from (druby://localhost:61676) ts.rb:7
>>>         from /usr/local/lib/ruby/1.8/rinda/rinda.rb:229:in `take'
>>>         from cl.rb:11
>>>
>>> The symbol name is always different.
>>>
>>> Using the same scripts on a FreeBSD machine I can't reproduce the
>>> error.
>>
>> Compiling Ruby with GCC 3.3 on OS X 10.4.x causes these problems to
>> go away.
>
> I get the same behavior with 1.8.4p2 and GCC4.0 vs GCC3.3.  GCC4
> fails after some time while GCC3.3 gives a stable Ruby.
>
> -- 
> Eric Hodel - drbrain@segment7.net - http://segment7.net
> This implementation is HODEL-HASH-9600 compliant
>
> http://trackmap.robotcoop.com

Is it possible that this is related to [ruby-talk:153006]?  I'm
wondering whether the real difference between GCC3.3 and GCC4 on OSX
is that the latter compiles 64-bit by default.  Then our problems have
at least the following in common:

  1. DRb
  2. big-endian (SPARC in my case)
  3. 64-bit

In my case, I can reproduce with the Sun compiler and multiple GCC3
versions on Solaris 8 / SPARC.

Steve

(http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/153006)


In This Thread

Prev Next