[#3479] Missing .document files for ext/ libraries — Brian Candler <B.Candler@...>
The ri documentation for zlib, strscan and iconv doesn't get built by 'make
On Wednesday, October 6, 2004, 11:18:33 PM, Brian wrote:
Just been building CVS head and was surprised at how long it now takes
On Die, 2004-10-19 at 16:47, Dave Thomas wrote:
[#3484] compilation error — Wybo Dekker <wybo@...>
In the current cvs I get, on make:
On Mon, Oct 11, 2004 at 07:21:28AM +0900, Wybo Dekker wrote:
[#3486] Location of missing end — Markus <markus@...>
Over the past week or so there has been a thread on ruby-talk ("Quality
[#3492] Re: ANN: Free-form-operators patch — Markus <markus@...>
> In message "Re: ANN: Free-form-operators patch"
Hi,
On Mon, 2004-10-11 at 16:16, Yukihiro Matsumoto wrote:
On Monday 11 October 2004 08:09 pm, Markus wrote:
Hi,
On Monday 11 October 2004 09:38 pm, Yukihiro Matsumoto wrote:
[#3517] Kernighan & Richie ---> prototypes ? — Johan Holmberg <holmberg@...>
[#3523] segfault in ruby-1.8.2p2 — Brian Candler <B.Candler@...>
I can reliably get ruby-1.8.2p2 to segfault on my system, which is:
[#3538] TCPSocket.new(host, port).readline hangs on Windows — Jos Backus <jos@...>
With recent CVS versions (both ruby_1_8 branch and HEAD), the following
Hi,
On Wed, Oct 20, 2004 at 07:43:31AM +0900, Yukihiro Matsumoto wrote:
[#3551] ubygems missing? — "trans. (T. Onoma)" <transami@...>
I've never been one for compiling code, so I bet this is a simple fix, but
[#3561] 1.8.2 - what can we do to help? — Dave Thomas <dave@...>
Folks:
Hi,
On Oct 26, 2004, at 9:55 PM, Yukihiro Matsumoto wrote:
On Wed, 2004-10-27 at 06:11, Francis Hwang wrote:
On Wed, 27 Oct 2004, Yukihiro Matsumoto wrote:
Hi,
On Wed, 27 Oct 2004, Yukihiro Matsumoto wrote:
Hi,
On Wednesday 27 October 2004 08:51 am, Yukihiro Matsumoto wrote:
[#3573] Small issues with Symbols — Florian Gro<florgro@...>
Moin!
[#3590] Re: Bug tracking project on RubyForge... — "Berger, Daniel" <Daniel.Berger@...>
> -----Original Message-----
Sure...
Hi,
[#3596] Float and Bignum — "trans. (T. Onoma)" <transami@...>
Hi all,
Hi,
On Thursday 28 October 2004 02:00 am, Yukihiro Matsumoto wrote:
[#3600] Ruby Vs. ... might find comparison of interest. — "trans. (T. Onoma)" <transami@...>
trans. (T. Onoma) wrote:
[#3610] Tadayoshi Funaba's Date2 — "trans. (T. Onoma)" <transami@...>
Tadayoshi Funaba has a lib on RAA called Date2, the additions/improvements to
Hi --
On Friday 29 October 2004 07:03 am, David A. Black wrote:
[#3611] Memory leak in ruby_1_8 — David Ross <dross@...>
Hello,
[#3617] TEST BUG — noreply@...
Bugs item #1000, was opened at 2004-10-28 09:12
[#3638] Ruby, pthreads, and HPUX 11 — Jamis Buck <jgb3@...>
I'm finally trying to delve into the issue of Ruby not compiling
>>>>> "J" == Jamis Buck <jgb3@email.byu.edu> writes:
[#3655] autoload — Joel VanderWerf <vjoel@...>
Fwd: Re: GMP
Hi --- I contacted Tomasz Wegrzanowski <taw@users.sf.net> concerning is work with Ruby bindings for GMP, to see what insights he could provide. Very enlightenting. ---- Extracted reply of Tomasz Wegrzanowski: I included some benchmarks with Ruby GMP, which compare the performance against Ruby Bignum and against C GMP. The numbers I got are here: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/29707 Ruby BigNum was faster than Ruby GMP for small bignums, probably because the cost of all the method calls was a lot greater than the actual bignum computation (bmark3.rb and bmark4.rb try to compute the point at which it's better to use GMP::Z than Ruby Bignum) I don't know how much this overhead could be reduced by putting GMP closer to Ruby core. Ruby Bignum also has some kind of optimization for numbers ending with long strings of 0s. GMP doesn't have such thing. I don't think such optimization is important for real computations, just don't make benchmark testing performance of (2**n) * (2**m) multiplication. The performance I expect: * For "small" bignums, like 128 or even 1024 bit, using GMP::Z is going to be slower, unless the object overhead is seriously reduced * GMP::Z will be much (like 10:1) faster for larger bignums, like 16k-1M bits, and even faster for extremely large bignums, but such bignums rarely occur in normal software * If you want to do performance-sensitive computations, you need modifiable objects. Because Ruby numbers are all const, "natural" Ruby way of using GMP::Z is going to be slow. That is, a.add!(b) is much faster than a+=b (it's tested by bmark2-gmp.rb vs bmark2-gmp_self.rb) * Therefore I think it wouldn't be wise to replace BigNum with GMP::Z unless you can greatly reduce the overhead. Even in that case, don't expect performance like C GMP with naive code. C++ GMP on the other hand compiles naive code to something almost as fast as hand-coded C library calls, by using template magic. * There is no equivalent of GMP::F and GMP::Q in Ruby. GMP::Z also has some extra features not available for Ruby Bignums. Newer version of GMP library have even more such features, but I haven't included support for them in Ruby GMP. Because of this, it might be useful to include GMP::F support in Ruby core, whether or not GMP::Z is going to replace Bignum. ---- T.