[#10853] Why limit class def to a constant or colon node? — Charles Oliver Nutter <charles.nutter@...>

Is there a historical reason why I can't do something like these:

12 messages 2007/04/03

[#10933] Cannot build with extra library path if previous version already installed — <noreply@...>

Bugs item #10140, was opened at 2007-04-16 17:32

10 messages 2007/04/16
[#10934] Re: [ ruby-Bugs-10140 ] Cannot build with extra library path if previous version already installed — nobu@... 2007/04/16

Hi,

[#10960] Re: [ ruby-Bugs-10140 ] Cannot build with extra library path if previous version already installed — "Michal Suchanek" <hramrach@...> 2007/04/18

On 4/16/07, nobu@ruby-lang.org <nobu@ruby-lang.org> wrote:

[#10967] Re: [ ruby-Bugs-10140 ] Cannot build with extra library path if previous version already installed — Nobuyoshi Nakada <nobu@...> 2007/04/19

Hi,

[#10970] Re: [ ruby-Bugs-10140 ] Cannot build with extra library path if previous version already installed — "Michal Suchanek" <hramrach@...> 2007/04/19

On 4/19/07, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:> Hi,>> At Wed, 18 Apr 2007 20:21:44 +0900,> Michal Suchanek wrote in [ruby-core:10960]:> > Yes. And this should also apply to extensions. The mkmf tests are now> > fine but the extension is linked with -L/sw/lib before -L../..>> Indeed.>>> Index: configure.in> ===================================================================> --- configure.in (revision 12191)> +++ configure.in (working copy)> @@ -1385,5 +1385,4 @@ if test "$enable_rpath" = yes; then> fi>> -LDFLAGS="-L. $LDFLAGS"> AC_SUBST(ARCHFILE)>This would break the previous fix so I did not even try to apply this ^

[#11003] miniruby loads extensions from already installed ruby — <noreply@...>

Bugs item #10303, was opened at 2007-04-23 10:44

10 messages 2007/04/23

[#11025] gsub with backslash characters in replacement string — "Adam Bozanich" <adam.boz@...>

Hello, spotted this one the other day:

10 messages 2007/04/26

[ ruby-Bugs-9410 ] Bignum.to_s fails for certain values and certain bases (1.8.6 regression)

From: <noreply@...>
Date: 2007-04-03 04:54:43 UTC
List: ruby-core #10841
Bugs item #9410, was opened at 2007-03-21 04:38
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1698&aid=9410&group_id=426

Category: Core
Group: 1.8.6
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Daniel Azuma (dazuma)
Assigned to: Nobody (None)
Summary: Bignum.to_s fails for certain values and certain bases (1.8.6 regression)

Initial Comment:
irb(main):001:0> RUBY_VERSION
=> "1.8.6"
irb(main):002:0> RUBY_PLATFORM
=> "i686-darwin8.8.1"
irb(main):003:0> 18446744073709551615.to_s(32) # should be "fvvvvvvvvvvvv"
=> "vvvvvvvvvvvv"
irb(main):004:0> 18446744073709551616.to_s(32) # correct
=> "g000000000000"
irb(main):005:0> 18446744073709551615.to_s(36) # should be "3w5e11264sgsf"
=> "w5e11264sgsf"
irb(main):006:0> 18446744073709551616.to_s(36) # correct
=> "3w5e11264sgsg"
irb(main):005:0> 18446744073709551615.to_s(31) # correct
=> "nd075ib45k86f"
irb(main):006:0> 18446744073709551616.to_s(31) # correct
=> "nd075ib45k86g"

I verified this on i686-linux (Fedora Core 5) also.

18446744073709551616 is, of course, 2^64. At first glance, it looks like values less than that threshold, when converted to base 32 or above, are being truncated to 12 characters. Could this have been an optimization gone awry?


----------------------------------------------------------------------

Comment By: Nobuyoshi Nakada  (nobu)
Date: 2007-04-03 13:54

Message:
This bug is fixed in the repository.

----------------------------------------------------------------------

Comment By: Daniel Azuma (dazuma)
Date: 2007-03-21 06:54

Message:
Looking at the bignum.c, I believe this is related:

irb(main):017:0> 18446744073709551615.to_s(8)
=> "1777777777777777777777"
irb(main):018:0> -18446744073709551615.to_s(8)
=> "11777777777777777777777"

I only partially understand the algorithm at this point, but I believe the 
computation of "j" needs to be rounded up in lines 648 and 659 of bignum.c. 
e.g.:

648:   j = j / 3 + 1;

659:   j = j / 5 + 1;

This seems to fix the problem on the test cases I've tried.

Also, to clarify, this appears to be a regression. All the cases I've tried work 
correctly in 1.8.5.

----------------------------------------------------------------------

Comment By: Daniel Azuma (dazuma)
Date: 2007-03-21 04:47

Message:
In case architecture matters, this was reproduced on a MacBook Pro (core duo), 
Mac OS X 10.4.8, with gcc i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple 
Computer, Inc. build 5341), and on a Dell server (32-bit dual-core I believe, but 
I could be mistaken), Fedora 5, with gcc (GCC) 4.1.1 20060525 (Red Hat 
4.1.1-1).

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1698&aid=9410&group_id=426

In This Thread

Prev Next