[#10830] New kill_thread function in eval.c conflict with a BeOS system function — <noreply@...>
Bugs item #9736, was opened at 01/04/2007 16:20
[#10834] Hefty patch for mkmf.rb — <noreply@...>
Patches item #9762, was opened at 2007-04-02 09:55
[#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:
Hi,
On 4/3/07, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
[#10867] defined? operator changed in ruby 1.9: bug or feature? — David Flanagan <david@...>
The behavior of the defined? operator is different in current ruby 1.9
Hi,
[#10875] Ruby shouldn't process shebang! — "Kirill A. Shutemov" <k.shutemov@...>
> echo -e '#!test\nputs "test passed"' | ruby=20
On 4/5/07, Kirill A. Shutemov <k.shutemov@gmail.com> wrote:
[#10884] Ruby 1.9/1.8 compatibility: String#lines — murphy <murphy@...>
It seems the most important change in 1.9, in terms of compatibility, is
[#10907] install (/bin/install) path hardcoded at build — <noreply@...>
Bugs item #10004, was opened at 2007-04-10 13:21
[#10909] Turning off verbose output for mkmf — Daniel Berger <Daniel.Berger@...>
Hi all,
[#10923] block_given? => true in main(). — "Adam Bozanich" <adam.boz@...>
Hi all.
[#10933] Cannot build with extra library path if previous version already installed — <noreply@...>
Bugs item #10140, was opened at 2007-04-16 17:32
Hi,
On 4/16/07, nobu@ruby-lang.org <nobu@ruby-lang.org> wrote:
Hi,
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 ^
Hi,
[#10944] IRHG - "Three Stuffing" — Charles Thornton <ceo@...>
Can a japanese speaker give a translation
[#10947] backwards compatibility for 'raise Interrupt' — Ryan Davis <ryand-ruby@...>
** BEFORE:
Hi,
Hi,
[#10968] IRHG - Manuscript Hunt — Charles Thornton <ceo@...>
Does anyone know of a Text Copy (Not PDF) of this manuscript:
[#10981] ruby 1.9 crash on cygwin — "Anton Ivanov" <Anton.Ivanov@...>
Hi,
[#11003] miniruby loads extensions from already installed ruby — <noreply@...>
Bugs item #10303, was opened at 2007-04-23 10:44
Hi,
On 23/04/07, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
Hi,
On 26/04/07, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
Hi,
[#11012] Ruby 1.9: multiple splats on rvalues in parallel assignment — David Flanagan <david@...>
This has got to be a bug...
[#11025] gsub with backslash characters in replacement string — "Adam Bozanich" <adam.boz@...>
Hello, spotted this one the other day:
Hi,
On 4/26/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
On 4/26/07, Adam Bozanich <adam.boz@gmail.com> wrote:
On 4/26/07, Marte Raphael Y. Soliza <myrtactle@gmail.com > wrote:
[#11029] Proc#arity regression or bug in RDoc — Mauricio Fernandez <mfp@...>
On Thu, Apr 26, 2007 at 06:55:46PM +0900, Mauricio Fernandez wrote:
[ ruby-Bugs-9410 ] Bignum.to_s fails for certain values and certain bases (1.8.6 regression)
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