[#13087] importing forwardable — "Akinori MUSHA" <knu@...>

 石塚さんの forwardable.rb を標準添付ライブラリにするべく、

11 messages 2001/05/02

[#13169] SizedQueue#pop causes deadlock — "Okada Jun" <yun@...>

岡田です。

18 messages 2001/05/13
[#13171] Re: SizedQueue#pop causes deadlock — "Akinori MUSHA" <knu@...> 2001/05/13

At Sun, 13 May 2001 14:11:18 +0900,

[#13176] Re: SizedQueue#pop causes deadlock — matz@... (Yukihiro Matsumoto) 2001/05/13

まつもと ゆきひろです

[#13177] Re: SizedQueue#pop causes deadlock — "Akinori MUSHA" <knu@...> 2001/05/13

At Mon, 14 May 2001 00:24:45 +0900,

[#13187] Re: SizedQueue#pop causes deadlock — matz@... (Yukihiro Matsumoto) 2001/05/13

まつもと ゆきひろです

[#13202] Re: [ruby-list:29672] Re: Enumerator — "Akinori MUSHA" <knu@...>

 ruby-dev に移ります。

26 messages 2001/05/15
[#13208] Re: [ruby-list:29672] Re: Enumerator — matz@... (Yukihiro Matsumoto) 2001/05/15

まつもと ゆきひろです

[#13259] Enumerator -- Round 2 — "Akinori MUSHA" <knu@...>

 もう一度、 Enumerable/Enumerator についてみなさんのご意見を

29 messages 2001/05/20
[#13260] Re: Enumerator -- Round 2 — matz@... (Yukihiro Matsumoto) 2001/05/20

まつもと ゆきひろです

[#13265] Re: Enumerator -- Round 2 — "Akinori MUSHA" <knu@...> 2001/05/21

At Mon, 21 May 2001 06:04:32 +0900,

[#13268] Re: Enumerator -- Round 2 — Shin-ichiro HARA <sinara@...> 2001/05/21

原です。

[#13270] Re: Enumerator -- Round 2 — "Akinori MUSHA" <knu@...> 2001/05/21

At Mon, 21 May 2001 15:00:11 +0900,

[#13289] Re: Enumerator -- Round 2 — Shin-ichiro HARA <sinara@...> 2001/05/22

原です。

[#13290] Re: Enumerator -- Round 2 — "Akinori MUSHA" <knu@...> 2001/05/22

At Tue, 22 May 2001 19:02:10 +0900,

[#13291] Re: Enumerator -- Round 2 — Shin-ichiro HARA <sinara@...> 2001/05/22

原です。

[#13293] Re: Enumerator -- Round 2 — "Akinori MUSHA" <knu@...> 2001/05/22

At Tue, 22 May 2001 20:57:02 +0900,

[#13305] Re: Enumerator -- Round 2 — Shin-ichiro HARA <sinara@...> 2001/05/24

原です。

[#13322] Re: Enumerator -- Round 2 — "Akinori MUSHA" <knu@...> 2001/05/24

At Thu, 24 May 2001 15:44:14 +0900,

[#13277] ext/dbm in ruby 1.7 — Kazuhiro NISHIYAMA <zn@...>

ruby 1.7のext/dbmですが、

16 messages 2001/05/21
[#13280] Re: ext/dbm in ruby 1.7 — matz@... (Yukihiro Matsumoto) 2001/05/21

まつもと ゆきひろです

[#13292] Integer("X") rescue -1 が parse error — YASUI Kentarow <kenyasui@...>

安井です。

18 messages 2001/05/22
[#13294] Re: Integer("X") rescue -1 が parse error — matz@... (Yukihiro Matsumoto) 2001/05/22

まつもと ゆきひろです

[#13295] Re: Integer("X") rescue -1 が parse error — "Akinori MUSHA" <knu@...> 2001/05/23

At Wed, 23 May 2001 08:59:50 +0900,

[#13300] 1.6.4 preview3 (Re: Re: Integer("X") rescue -1 が parse error) — matz@... (Yukihiro Matsumoto) 2001/05/24

[#13304] Re: 1.6.4 preview3 (Re: Re: Integer("X") rescue -1 が parse error) — "Akinori MUSHA" <knu@...> 2001/05/24

At Thu, 24 May 2001 14:15:04 +0900,

[#13428] mswin32/ming32 system patch (experimental) — "U.Nakamura" <usa@...>

こんにちは、なかむら(う)です。

19 messages 2001/05/31
[#13435] Re: mswin32/ming32 system patch (experimental) — nobu.nakada@... 2001/06/01

なかだです。

[#13442] Re: mswin32/ming32 system patch (experimental) — "U.Nakamura" <usa@...> 2001/06/01

こんにちは、なかむら(う)です。

[#13446] Re: mswin32/ming32 system patch (experimental) — "U.Nakamura" <usa@...> 2001/06/02

こんにちは、なかむら(う)です。

[#13450] Re: mswin32/ming32 system patch (experimental) — nobu.nakada@... 2001/06/04

なかだです。

[ruby-dev:13369] Re: StringBuffer

From: Shugo Maeda <shugo@...>
Date: 2001-05-28 04:55:55 UTC
List: ruby-dev #13369
前田です。

At Mon, 28 May 2001 13:18:27 +0900,
Tanaka Akira <akr@m17n.org> wrote:
> > Rubyレベルで見せるかどうかは別として、JavaのStringBufferのような
> > クラスを用意して、それを利用するようにした方がよいのではないでしょ
> > うか。
> 
> String 自体が StringBuffer のようなものであってもいいんじゃないでしょ
> うか。

そうですね。

> 後ろにどんどんつけ加えていく、というもっともありがちなケースを救うだけ
> なら String が(使っている領域ではなく)確保している領域のサイズを覚えて
> おけばいいと思うのですが。Array みたいに。

些細な問題としては、何らかのトリックで解決可能ですが、RString構造
体に使える領域が残っていないという問題がありますね。

> と思っているにもかかわらず、なぜ Array#join のほうを話題に出したかとい
> うと Array#join の改善は明らかに可能であるのに対し、String 自体の変更
> はどこまで波及するかわからなかったからです。でも明らかに可能だと思って
> いるにもかかわらず実際に変更を行なわなかった理由は、多言語化したときに
> String の連結がメモリ領域の単なる連結ではなくなるような事態もあるかも
> 知れない、と思ったからなんです。

現状のruby_m17nブランチでは、encodingをチェックした上で以前と同様
の処理を行っているようですね。
たぶん、多少変更されたとしても、連結後に必要なメモリ領域が連結前
よりも大く必要なのに変わりはないでしょうから、上記のような方法の
効果はあるのではないでしょうか。

問題は(実装とか、コードのメンテナンス性などをふくめた)コストに見
合うだけの効果があるかどうかですが、速度的にはかなりの効果が期待
できそうな気がします。

-- 
前田 修吾

In This Thread