[#15707] Schedule for the 1.8.7 release — "Akinori MUSHA" <knu@...>

Hi, developers,

21 messages 2008/03/01

[#15740] Copy-on-write friendly garbage collector — Hongli Lai <hongli@...99.net>

Hi.

31 messages 2008/03/03
[#15742] Re: Copy-on-write friendly garbage collector — Yukihiro Matsumoto <matz@...> 2008/03/03

Hi,

[#15829] Re: Copy-on-write friendly garbage collector — Daniel DeLorme <dan-ml@...42.com> 2008/03/08

Yukihiro Matsumoto wrote:

[#15756] embedding Ruby 1.9.0 inside pthread — "Suraj Kurapati" <sunaku@...>

Hello,

18 messages 2008/03/03
[#15759] Re: embedding Ruby 1.9.0 inside pthread — Nobuyoshi Nakada <nobu@...> 2008/03/04

Hi,

[#15760] Re: embedding Ruby 1.9.0 inside pthread — Yukihiro Matsumoto <matz@...> 2008/03/04

Hi,

[#15762] Re: embedding Ruby 1.9.0 inside pthread — "Suraj N. Kurapati" <sunaku@...> 2008/03/04

Yukihiro Matsumoto wrote:

[#15783] Adding startup and shutdown to Test::Unit — Daniel Berger <Daniel.Berger@...>

Hi all,

15 messages 2008/03/04

[#15835] TimeoutError in core, timeouts for ConditionVariable#wait — MenTaLguY <mental@...>

I've been reworking JRuby's stdlib to improve performance and fix

10 messages 2008/03/09

[#15990] Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...>

Hi,

35 messages 2008/03/23
[#15991] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/23

[#15993] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/23

Hi Dave,

[#15997] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/23

[#16024] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/26

Hi Dave,

[#16025] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16026] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16027] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16029] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16030] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16031] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16032] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/26

On Wed, Mar 26, 2008 at 7:01 PM, Dave Thomas <dave@pragprog.com> wrote:

[#16033] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16041] Re: Recent changes in Range#step behavior — David Flanagan <david@...> 2008/03/26

Dave Thomas wrote:

Re: RARRAY_PTR

From: Evan Phoenix <evan@...>
Date: 2008-03-16 06:10:45 UTC
List: ruby-core #15916
I second this idea. In fact, Laurent and I have discussed this kind of  
thing before at rubyconf.

I'd love for us to take this even further and have RSTRING_AT(), etc,  
and deprecated RSTRING_PTR, for exactly the same reasons, that expose  
the direct memory as the implementation makes these much more  
difficult for implementors, and more dangerous for users.

- Evan

On Mar 15, 2008, at 11:15 AM, Laurent Sansonetti wrote:

> On Sat, Mar 15, 2008 at 6:42 AM, Yukihiro Matsumoto <matz@ruby-lang.org 
> > wrote:
>> Hi,
>>
>> In message "Re: RARRAY_PTR"
>>
>>   on Sat, 15 Mar 2008 09:40:15 +0900, "Laurent Sansonetti" <laurent.sansonetti@gmail.com 
>> > writes:
>>
>> |Currently, ruby.h defines RARRAY_PTR as a macro to access the  
>> internal
>> |C array of the RArray structure (which represents the Array class).
>> |This macro is used in many places in the Ruby code (and  
>> extensions) to
>> |get an element at a particular index
>> |
>> |  VALUE v = RARRAY_PTR(ary)[42];
>> |
>> |But some people also use it to set values
>> |
>> |  RARRAY_PTR(ary)[0] = Qnil;
>> |
>> |I think this macro is dangerous because it exposes too much  
>> internals.
>> |Also, it is difficult to re-implement RArray using a different  
>> storage
>> |structure and efficiently support this macro at the same time. In
>> |MacRuby I am working on a new implementation of the Array class and
>> |will not be able to support this macro for inline modifications.
>>
>> How about officially declaring RARRAY_PTR() is read-only?  In fact,  
>> it
>> IS read-only.
>>
>
> I have been thinking about this, RARRAY_PTR could return a const
> value. Right now it doesn't seem to.
>
> But there is still the problem of accessing elements in the array.
> People use RARRAY_PTR(ary)[idx] for that. Nobu-san's RARRAY_AT macro
> idea is good because it doesn't expose the underlying implementation
> of the class (and it can also do a boundary check).
>
> If the genuine Ruby in the future wants to re-implement RArray using a
> different storage structure, the interface would already be there.
>
> # If you desire I can work on a patch.
>
> Laurent
>


In This Thread

Prev Next