[#586] irb aborts in 1.7.3 on Solaris — Jim Freeze <jim@...>
Hi:
6 messages
2002/12/06
[#598] irb Abort on Solaris Backtrace — Jim Freeze <jim@...>
Hi:
12 messages
2002/12/09
[#599] Re: irb Abort on Solaris Backtrace
— ts <decoux@...>
2002/12/09
>>>>> "J" == Jim Freeze <jim@freeze.org> writes:
[#600] Re: irb Abort on Solaris Backtrace
— Jim Freeze <jim@...>
2002/12/09
On Tuesday, 10 December 2002 at 1:44:43 +0900, ts wrote:
[#602] Re: irb Abort on Solaris Backtrace
— matz@... (Yukihiro Matsumoto)
2002/12/09
Hi,
[#603] Re: irb Abort on Solaris Backtrace
— Jim Freeze <jim@...>
2002/12/09
On Tuesday, 10 December 2002 at 3:24:46 +0900, Yukihiro Matsumoto wrote:
[#606] Re: irb Abort on Solaris Backtrace
— matz@... (Yukihiro Matsumoto)
2002/12/09
Hi,
[#609] Re: irb Abort on Solaris Backtrace
— Jim Freeze <jim@...>
2002/12/10
On Tuesday, 10 December 2002 at 7:59:33 +0900, Yukihiro Matsumoto wrote:
[#601] Re: irb Abort on Solaris Backtrace — "Garriss, Michael" <Michael.Garriss@...>
I tried: `ruby -r socket -e 0` and got no error. I would really like to
5 messages
2002/12/09
[#633] Error installing some extensions under non-default prefix — Jos Backus <jos@...>
Fyi: with today's CVS, when I run
4 messages
2002/12/13
[#636] doc/NEWS — Matt Armstrong <matt@...>
22 messages
2002/12/15
[#640] Re: [patch] doc/NEWS
— nobu.nokada@...
2002/12/15
Hi,
[#641] Re: [patch] doc/NEWS
— Matt Armstrong <matt@...>
2002/12/16
[#637] Re: [patch] doc/NEWS
— "Akinori MUSHA" <knu@...>
2002/12/15
At Mon, 16 Dec 2002 02:07:40 +0900,
[#639] Re: [patch] doc/NEWS
— matz@... (Yukihiro Matsumoto)
2002/12/15
Hi,
[#644] Re: [patch] doc/NEWS
— Tanaka Akira <akr@...17n.org>
2002/12/16
In article <1039993469.392945.14311.nullmailer@picachu.netlab.jp>,
[#667] Segfault in Ruby 1.7.x/1.8 Proc#to_s — Michael Granger <ged@...>
Hello,
8 messages
2002/12/29
Re: [patch] doc/NEWS
From:
nobu.nokada@...
Date:
2002-12-17 11:06:55 UTC
List:
ruby-core #658
Hi,
At Tue, 17 Dec 2002 17:43:24 +0900,
Matt Armstrong wrote:
> I'll try to understand this new string code, but I wonder if you could
> explain a few things. My basic problem is that STR_ASSOC and
> ELTS_SHARED are not clear to me.
>
> ELTS_SHARED -- means string shares same data buffer with some other
> string -- must make copy to modify.
>
> STR_ASSOC -- I could not figure it out.
Related to Array#pack/String#unpack. It means that the string
is made by pack("p")/pack("P") and contains pointer values of
packed objects.
> > + !FL_TEST(str, STR_ASSOC)) {
>
> And when the original string is not ??? (what is STR_ASSOC?)
>
> > + if (!FL_TEST(str, ELTS_SHARED)) str = rb_str_new4(str);
>
> If the old string is ELTS_SHARED, create a new ELTS_SHARED string copy
> that is frozen. Maybe I miss something here.
`If the old string is *not* ELTS_SHARED'.
Only one string not ELTS_SHARED is necessary for GC, and this
is the reason why I didn't make small string shared.
STR_ASSOC'ed string can't have reference to this non-shared
string, as it's used to refer associated objects.
--
Nobu Nakada