[#5322] O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...>
I just did some benchmarks on push, pop, shift, and unshift
On Fri, 1 Jul 2005, Eric Mahurin wrote:
--- Mathieu Bouchard <matju@artengine.ca> wrote:
On Sat, 2 Jul 2005, Eric Mahurin wrote:
--- Mathieu Bouchard <matju@artengine.ca> wrote:
On Sun, 3 Jul 2005, Eric Mahurin wrote:
--- Mathieu Bouchard <matju@artengine.ca> wrote:
Hi,
--- Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
Hi,
Yukihiro Matsumoto wrote:
--- Florian Gro<florgro@gmail.com> wrote:
Eric Mahurin wrote:
--- Nikolai Weibull
Eric Mahurin wrote:
[#5388] Problem with socket communications on Windows — "Jim McMaster" <jim.mcmaster@...>
I recently installed PGP 9.0 on my Windows XP SP2 machine. At that point,
[#5391] Object#=~ — Ryan Davis <ryand-ruby@...>
Since Rexexp#=~ and String#=~ return nil if they fail to match,
Hi,
Hi,
--- Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
[#5409] socket.c - s_recvfrom — Zach Dennis <zdennis@...>
If I am reading s_recvfrom correctly in can throw an error which kills
[#5420] Sydney Developer Preview 1 released — Evan Webb <evanwebb@...>
Sydney, an experimental ruby interpreter, has been released!
Thanks everyone for the feedback so far!
Hi,
The MD5 sum is 53d1bde4542365caf4849c56e6274617.
Hi,
On 7/12/05, nobuyoshi nakada <nobuyoshi.nakada@ge.com> wrote:
Hi,
Hello,
[#5445] GC tweak — Stefan Kaes <skaes@...>
I have found that the performance of current garbage collector
[#5451] bug in pstore (ruby 1.8.2) on Windows ( Win XP) ? — noreply@...
Bugs item #2101, was opened at 2005-07-14 15:30
[#5470] Bogus age value from Etc — Daniel Berger <Daniel.Berger@...>
Hi all,
[#5471] make fail; ruby v182 not finding readline ? — OpenMacNews <OpenMacNews@...>
hi all,
[#5476] Bug in ruby's command line parsing — Lothar Scholz <mailinglists@...>
Hello,
On Sat, Jul 16, 2005 at 10:11:34AM +0900, Lothar Scholz wrote:
[#5492] ruby ( v183) bcc32: using Socket.new with timeout -> files not closed — noreply@...
Bugs item #2131, was opened at 2005-07-19 17:34
Possible Bug in Documentation or implementation of srand
According to documentation srand of 0 is supposed to reset srand to
some random value from the clock and whatnot. Unfortuneatly this only
actually occurs if you call srand with no argument. See example
below:
irb(main):001:0> srand 0
=> 0
irb(main):002:0> rand
=> 0.548813503927325
irb(main):003:0> rand
=> 0.715189366372419
irb(main):004:0> srand 0
=> 0
irb(main):005:0> rand
=> 0.548813503927325
irb(main):006:0> rand
=> 0.715189366372419
irb(main):007:0> srand
=> 0
irb(main):008:0> rand
=> 0.0934072350449292
irb(main):009:0>
Here is the apparently documentation that seems to be mistaken from my
interpretation
----------------------------------------------------------- Kernel#srand
srand(number=0) => old_seed
------------------------------------------------------------------------
Seeds the pseudorandom number generator to the value of
_number_.+to_i.abs+. If _number_ is omitted or zero, seeds the
generator using a combination of the time, the process id, and a
sequence number. (This is also the behavior if +Kernel::rand+ is
called without previously calling +srand+, but without the
sequence.) By setting the seed to a known value, scripts can be
made deterministic during testing. The previous seed value is
returned. Also see +Kernel::rand+.
It's possible that I may misinterpreting something in this description
but it seems like the line "If _number is omitted or zero, seeds the
generator" is not happening as exhibited in my above example.
Can anyone shed any light on this behavior? Is the code incorrect or
is the documentation incorrect?
Charles Comstock