[MacRuby-devel] [MacRuby] #560: __method__ and __callee__ always return nil

2010-01-18 Thread MacRuby 
#560: __method__ and __callee__ always return nil
+---
 Reporter:  lastobe...@…|   Owner:  lsansone...@…
 Type:  defect  |  Status:  new  
 Priority:  minor   |   Milestone:   
Component:  MacRuby |Keywords:   
+---
 I'm not sure whether these have not been implemented or whether this is a
 bug?

 Leopard, r3290

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #557: Ruby exceptions aren't catched when calling at_exit block (was: Ruby exceptions aren't cached when calling at_exit block)

2010-01-18 Thread MacRuby 
#557: Ruby exceptions aren't catched when calling at_exit block
-+--
 Reporter:  eloy.de.en...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:   
-+--

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] GCD and NSURLConnection

2010-01-18 Thread steve ross 
You're right, no ivars are being written in concurrent threads in the bug 
report code. However, in the NSURLConnection example, two ivars are used. The 
is the code to execute (the block). The second is the data buffer that will be 
changed as the HTTP response data returns.

In either case, there are potential problems. If there is a context switch 
while @block is being reassigned, the code in the block may be incomplete at 
the time of the switch. I don't know. In the case of the buffer, it is very 
likely to be stepped on in a context switch as the whole point of executing 
HTTP GETs in parallel is to switch context while blocked on network response.

I only know this because I'm in the middle of (not yet successfully) trying to 
solve the same problem with native threads.

Steve


On Jan 17, 2010, at 10:34 PM, Joshua Ballanco wrote:
> 
> I'd have to look at the NSURLConnection example again, but in the code from 
> the bug report, there's no unsafe variable access in the Ruby code. Each Bar 
> holds a reference to its own Foo in @foo, and we're dispatching to multiple 
> Bars in turn. If you run that sample (you might need to tweak some of the 
> parameters, depending on your machine) I think you'll find a fun error 
> message that indicates this is definitely a MacRuby bug. :-)
> 
> Cheers,
> 
> Josh
> 
> 
> On Jan 17, 2010, at 10:25 PM, steve ross wrote:
> 
>> But... both examples show multiple threads accessing a single instance 
>> variable without taking any precautions to make the access atomic. Could it 
>> be that kind of concurrency issue?
>> 
>> Steve
>> 
>> On Jan 17, 2010, at 6:01 PM, Joshua Ballanco wrote:
>>> 
>>> Hey Darin,
>>> 
>>> Looks like you're hitting https://www.macruby.org/trac/ticket/511
>>> 
>>> Cheers,
>>> 
>>> Josh
>> 


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #557: Ruby exceptions aren't catched when calling at_exit block

2010-01-18 Thread MacRuby 
#557: Ruby exceptions aren't catched when calling at_exit block
-+--
 Reporter:  eloy.de.en...@…  |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  blocker  |Milestone:  MacRuby 0.6  
Component:  MacRuby  |   Resolution:  fixed
 Keywords:   |  
-+--
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  => MacRuby 0.6


Comment:

 Should be fixed by r3293

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] [MacRuby] #561: serialization/archiving of ruby and obj-c objects

2010-01-18 Thread MacRuby 
#561: serialization/archiving of ruby and obj-c objects
-+--
 Reporter:  mattaimone...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  MacRuby 0.6  
Component:  MacRuby  |Keywords:   
-+--
 In Ruby archiving is done using the Marshal class, while in Cocoa, the
 NSCoder abstract class is being used.

 On one hand, currently, in MacRuby, you can marshal down pure Obj-C
 objects and of course things don't look too good when they are restored.
 On the other hand, you can't archive Ruby objects using Cocoa API since
 Ruby objects don't implement the NSCoding protocol.

 We probably need to add NSCoder support in marshal
 And also add the NSCoding protocol methods to new MacRuby classes.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel