[#6548] 1.8.4 p1, warning roundup — Daniel Berger <Daniel.Berger@...>
Hi all,
[#6552] Socket Documentation — zdennis <zdennis@...>
Attached is a patch against the latest socket.c in the ruby_1_8 branch. It covers all Socket
On 11/3/05, zdennis <zdennis@mktec.com> wrote:
Gavin Sinclair wrote:
zdennis wrote:
On 11/9/05, Zach Dennis <zdennis@mktec.com> wrote:
Hi.
[#6558] Method of feeding input to regexp matching — Nikolai Weibull <mailing-lists.ruby-core@...>
I would very much like to be able to provide a Regexp object input from
[#6572] Stack trace consumes information. patch... — Hugh Sasse <hgs@...>
I have just had output like this from rails:
[#6588] Object#clone missing documentation — Eero Saynatkari <ruby-ml@...>
It appears that Object#clone, unlike Object#dup, retains
Hi,
I've attached a documentation patch which tries to address this shortcoming.
Kev Jackson wrote:
[#6602] Re: Unpack Endian Bug — "Berger, Daniel" <Daniel.Berger@...>
> -----Original Message-----
Berger, Daniel wrote:
[#6604] Sandboxing without $SAFE — why the lucky stiff <ruby-core@...>
I've been playing with Ruby sandboxing alot over the past several
[#6619] Wildness: Purpose of NOEX_PUBLIC Flag in rb_add_method? — "Charles E. Thornton" <ruby-core@...>
Several Different references to 'noex'
Charles E. Thornton wrote:
[#6625] Array::fill causes segfaults after many calls — noreply@...
Bugs item #2824, was opened at 2005-11-14 23:11
Hi,
[#6629] Strange error messages using DRb/TupleSpace — Eric Hodel <drbrain@...7.net>
Using
[#6636] alarming changes — "Ara.T.Howard" <ara.t.howard@...>
[#6639] Tuple Class — TRANS <transfire@...>
If I put together a good Tuple class for Ruby could it go into core? I
[#6650] REXML Update Please — zdennis <zdennis@...>
I submitted this as an RCR, but I didn't know that RCR's aren't for the stdlib. Matz commented on
Hi,
Yukihiro Matsumoto wrote:
[#6660] Ruby on Neko ? — Nicolas Cannasse <ncannasse@...>
Hi folks,
Nicolas Cannasse wrote:
Florian Growrote:
Nicolas Cannasse <ncannasse@motion-twin.com> writes:
On Sun, 20 Nov 2005, Christian Neukirchen wrote:
[#6672] testing for hardlink with "test(?-, ...)" flawed on Windows — noreply@...
Bugs item #2858, was opened at 2005-11-20 16:35
Hi,
--- nobuyoshi nakada <nobuyoshi.nakada@ge.com> wrote:
[#6684] semenatics of if/unless/while statement modifiers — Stefan Kaes <skaes@...>
Hi all,
On Tue, Nov 22, 2005 at 08:22:59AM +0900, Stefan Kaes wrote:
Mauricio Fern疣dez wrote:
On Nov 21, 2005, at 4:37 PM, Stefan Kaes wrote:
Eric Hodel wrote:
Hi,
Yukihiro Matsumoto wrote:
mathew wrote:
Stefan Kaes wrote:
On Tuesday 22 November 2005 12:31, Steven Jenkins wrote:
Hi --
>>>>> "m" == mathew <meta@pobox.com> writes:
Hi,
Yukihiro Matsumoto wrote:
Hi,
Yukihiro Matsumoto wrote:
Hi,
Yukihiro Matsumoto wrote:
On Nov 21, 2005, at 9:37 PM, Stefan Kaes wrote:
Eric Hodel wrote:
URABE Shyouhei wrote:
On Tue, 22 Nov 2005, Stefan Kaes wrote:
Ara.T.Howard wrote:
Hi --
David A. Black wrote:
Hi --
David A. Black wrote:
Hi --
David A. Black wrote:
Hi -
On Tuesday 22 November 2005 15:37, David A. Black wrote:
Hi --
On Tue, 22 Nov 2005, Stefan Kaes wrote:
Mathieu Bouchard wrote:
[#6721] String#index does not work correctly on SuSE10.0 x86_64 — "Kanis, Lars" <Kanis@...>
Hi folks,
[#6798] ruby 1.8.4 preview2 — Yukihiro Matsumoto <matz@...>
Hi,
On Nov 30, 2005, at 8:03 AM, Yukihiro Matsumoto wrote:
>>>>> "E" == Eric Hodel <drbrain@segment7.net> writes:
On Dec 4, 2005, at 4:07 AM, ts wrote:
>>>>> "E" == Eric Hodel <drbrain@segment7.net> writes:
On 11/30/05, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
Hi,
Yukihiro Matsumoto wrote:
Hi.
Re: Ruby on Neko ?
On Sunday 20 November 2005 04:38, Nicolas Cannasse wrote: > Looking at Ruby implementation, every object needs to allocate a fairly > big hashtable (11 buckets by default) in order to get a real O(1) access > in practice - which can be O(n) in the worst case - and that cost (a) > memory and (b) GC cycles when scanning it. > > When Neko for example is running into Apache, that's several hundreds of > process having all theses living objects so in that case you're more > often memory-bound than CPU-bound, it then makes sense to trade CPU for > memory. I have to agree that there are more considerations than just access speed. I'm running into this in REXML, where people are complaining that loading any document of a couple of megs will exhaust their memory, and even 1GB systems choke on documents greater than 5MB[1]. Part of the problem (perhaps the dominant problem) is that REXML Element nodes use hashtables for Attribute lists; so every Element has a hashtable[2]. A program being too slow is certainly a problem, but I'd argue that it isn't as big of a problem as having the program run your machine out of memory and then fail terribly. Anyway, this doesn't meaningfully contribute to the discussion, but the thread is apropos to a problem I'm struggling with at the moment. [1] This isn't a Ruby problem, of course. This is programmer error, in failing to anticipate the large data sets. My XML problem domains are always small, so, of course, are everyone else's :-) [2] The problem in REXML is actually worse; I use Ruby hashes all over the place, with little regard, and now I'm having to go back and strip them out and replace them with balanced trees. One thing I'm anticipating is having REXML choose between hash and red-black trees (or whatever I settle on) intelligently if it can determine the size of the document, and use trees if it can't. However, it is more critical to make sure that REXML doesn't choke on large data sets. -- --- SER "As democracy is perfected, the office of president represents, more and more closely, the inner soul of the people. On some great and glorious day the plain folks of the land will reach their heart's desire at last and the White House will be adorned by a downright moron." - H.L. Mencken (1880 - 1956)