On Jan 26, 2011, at 12:49 AM, Charles Oliver Nutter wrote:
> On Mon, Jan 24, 2011 at 11:13 AM, Joshua Ballanco wrote:
>> Regarding the potential bug...well...where to begin? So, yes, MacRuby blocks
>> have the same semantics as regular Ruby blocks, *except* when they are
>> dispatched through GCD.
Hi Charles!
Sorry for the late response.
As others have noted, in this snippet, #apply is called on a sequential queue
(queues created by Queue.new are always sequential), therefore there shouldn't
be any problem here. If the queue was concurrent, however, there would be a
thread safety issue.
On 2011-01-26, at 20:22 , Laurent Sansonetti wrote:
>
> For 1.0, we should either document this or try to make
> proposedSelRangePtr[0].location=42 work, as I suspect people will hit the
> same problem. Could you file a ticket? We will continue the investigation
> there.
Ok, will get on to tha
Hi Caio,
Sorry for the late response. This is a limitation of our implementation of
pointers. Sadly, I don't recall the problem anymore (as I wrote that stuff 2
years ago), but I think it's related to the way we cache the Pointer internal
data.
For 1.0, we should either document this or try to
Hi Watson,
Sorry for late response. I think your benchmark code contains too much side
effects (such as the allocation of 'a' string and hash internals during
rehash). If you just benchmark h[42]=42 you should see a difference.
Anyways, I corrected the change to use the mask flag in r5187.
Lau
On Mon, Jan 24, 2011 at 11:13 AM, Joshua Ballanco wrote:
> Regarding the potential bug...well...where to begin? So, yes, MacRuby blocks
> have the same semantics as regular Ruby blocks, *except* when they are
> dispatched through GCD. In that case, ivars are shared, but local variable
> get copied
