November 2010 - macruby-tickets - lists.macosforge.org

[MacRuby] #1015: mark Cocoa as multithreaded by default
by MacRuby 02 Dec '10

02 Dec '10

#1015: mark Cocoa as multithreaded by default -------------------------------------+-------------------------------------- Reporter: mattaimonetti@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.8 Component: MacRuby | Keywords: -------------------------------------+-------------------------------------- {{{ >> framework 'Foundation' => true >> Thread.new{} => #<Thread:0x2000de8e0 run> >> NSThread.multiThreaded? => false >> cocoa_lock = NSThread.alloc.init => #<NSThread:0x200220c00> >> NSThread.multiThreaded? => false >> cocoa_lock.start => #<NSThread:0x200220c00> >> NSThread.multiThreaded? => true }}} Using MacRuby threads doesn't mark cocoa as multithreaded which could potentially cause issues as per the documentation: Protecting the Cocoa Frameworks For multithreaded applications, Cocoa frameworks use locks and other forms of internal synchronization to ensure they behave correctly. To prevent these locks from degrading performance in the single-threaded case, however, Cocoa does not create them until the application spawns its first new thread using the NSThread class. If you spawn threads using only POSIX thread routines, Cocoa does not receive the notifications it needs to know that your application is now multithreaded. When that happens, operations involving the Cocoa frameworks may destabilize or crash your application. To let Cocoa know that you intend to use multiple threads, all you have to do is spawn a single thread using the NSThread class and let that thread immediately exit. Your thread entry point need not do anything. Just the act of spawning a thread using NSThread is enough to ensure that the locks needed by the Cocoa frameworks are put in place. If you are not sure if Cocoa thinks your application is multithreaded or not, you can use the isMultiThreaded method of NSThread to check. http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Mult… -- Ticket URL: <http://www.macruby.org/trac/ticket/1015> MacRuby <http://macruby.org/>

1 1

[MacRuby] #1002: AXUIElement functions won't accept Pointers of type :id
by MacRuby 02 Dec '10

02 Dec '10

#1002: AXUIElement functions won't accept Pointers of type :id ---------------------------+------------------------------------------------ Reporter: haxie1@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.8 Component: MacRuby | Keywords: ---------------------------+------------------------------------------------ I am working with the Carbon Accessibility API and running into an issue with Pointers. {{{ framework 'ApplicationServices' pid = (Safari's pid) safari = AXUIElementCreateApplication(pid) titlePtr = Pointer.new(:id) err = AXUIElementCopyAttributeValue(safari, "AXTitle", titlePtr) }}} error: TypeError: expected instance of Pointer of type `^v', got `@' Passing: {{{ ... titlePtr = Pointer.new("^v") err = AXUIElementCopyAttributeValue(safari, "AXTitle", titlePtr) }}} returns successfully but titlePtr is nil. Since AXUIElementCopyAttributeValue takes a pointer to a CFTypeRef, shouldn't I be able to pass a Pointer of type :id? I am running the latest MacRuby nightly and have BridgeSupportPreview1 installed. Regards, Kam -- Ticket URL: <http://www.macruby.org/trac/ticket/1002> MacRuby <http://macruby.org/>

1 9

[MacRuby] #1012: Inconsistent Regex behaviour
by MacRuby 01 Dec '10

01 Dec '10

#1012: Inconsistent Regex behaviour -------------------------------------------+-------------------------------- Reporter: harry@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: -------------------------------------------+-------------------------------- I've been trying to use Ruby's built in Net::IMAP but haven't got beyond the first hurdle. require 'net/imap' imap = Net::IMAP.new("imap.gmail.com", 25, false) // crashes with 'can't convert nil into String (TypeError)' I've traced it to an inconsistency in the Regex handling between vanilla Ruby and MacRuby (tested on the latest nightly build of 0.8 as of the 25th of November): $ macruby --version MacRuby 0.8 (ruby 1.9.2) [universal-darwin10.0, x86_64] $ macruby regex-test.rb 0 '220' versus $ ruby --version ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0] $ ruby regex-test.rb 0 '220' 3 ' ' 4 'mx.google.com' 17 ' ' 18 'ESMTP' 23 ' ' 24 'n40sm3793094weq.29' -- Ticket URL: <http://www.macruby.org/trac/ticket/1012> MacRuby <http://macruby.org/>

1 15

Re: [MacRuby] #135: macgem won't install hpricot
by MacRuby 28 Nov '10

28 Nov '10

#135: macgem won't install hpricot ----------------------------------+----------------------------------------- Reporter: masterkain@… | Owner: lsansonetti@… Type: defect | Status: closed Priority: blocker | Milestone: MacRuby 0.8 Component: MacRuby | Resolution: fixed Keywords: macgem hpricot | ----------------------------------+----------------------------------------- Changes (by watson1978@…): * status: new => closed * resolution: => fixed * milestone: => MacRuby 0.8 Comment: could install a hpricot with MacRuby Latest. -- Ticket URL: <http://www.macruby.org/trac/ticket/135#comment:6> MacRuby <http://macruby.org/>

1 0

[MacRuby] #1013: Segmentation fault when using readline
by MacRuby 27 Nov '10

27 Nov '10

#1013: Segmentation fault when using readline ------------------------------+--------------------------------------------- Reporter: pelsen@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: MacRuby 0.7 Component: MacRuby | Keywords: ------------------------------+--------------------------------------------- Dear MacRuby Developers, When messing aound with MacRuby, I tried readline, but whenever I use it it exits, saying "Segmentation fault". I don't think that's good :). I am running Mac OS X on a Mac Mini, uname -a output: Darwin Brutus.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 macirb --version output: DietRB (0.5.1) macruby --version output: MacRuby 0.7 (ruby 1.9.2) [universal-darwin10.0, x86_64] How to reproduce: Brutus:~ patrick$ macirb irb(main):001:0> readline Segmentation fault Brutus:~ patrick$ -- Ticket URL: <http://www.macruby.org/trac/ticket/1013> MacRuby <http://macruby.org/>

1 2

[MacRuby] #1010: NSPoint/CGpoint =>NaN
by MacRuby 26 Nov '10

26 Nov '10

#1010: NSPoint/CGpoint =>NaN --------------------------------------+------------------------------------- Reporter: zalavariandris@… | Owner: lsansonetti@… Type: defect | Status: new Priority: trivial | Milestone: MacRuby 0.8 Component: MacRuby | Keywords: NSPoint, CGPoint, 32Bit, NaN, NSEVent --------------------------------------+------------------------------------- NSEvent.mouseLocation result in an NSPoint without the corresponding values. I have the same bug when getting the position of a CALayer. irb(main):003:0> NSEvent.mouseLocation => #<NSPoint x=NaN y=NaN> irb(main):007:0> layer=CALayer.new => #<CALayer:0x1b7a100> irb(main):008:0> layer.position => #<CGPoint x=NaN y=NaN> Macruby 0.8 | Ruby 1.9.2 MacOSX 01.6.5 (32bit ) -- Ticket URL: <http://www.macruby.org/trac/ticket/1010> MacRuby <http://macruby.org/>

1 4

Re: [MacRuby] #520: Confusion in data type names for Core OpenGL
by MacRuby 25 Nov '10

25 Nov '10

#520: Confusion in data type names for Core OpenGL ------------------------------------------------------+--------------------- Reporter: sojastar07@… | Owner: lsansonetti@… Type: defect | Status: closed Priority: blocker | Milestone: MacRuby 0.8 Component: MacRuby | Resolution: fixed Keywords: pointer Core OpenGL data types confusion | ------------------------------------------------------+--------------------- Changes (by mattaimonetti@…): * status: new => closed * resolution: => fixed * milestone: => MacRuby 0.8 Comment: This bug seems to have been solved in the new BridgeSupport preview, please reopen if needs be. -- Ticket URL: <http://www.macruby.org/trac/ticket/520#comment:2> MacRuby <http://macruby.org/>

1 0

Re: [MacRuby] #513: MacRuby gets confused about inheritance under certain conditions
by MacRuby 25 Nov '10

25 Nov '10

#513: MacRuby gets confused about inheritance under certain conditions -----------------------------------+---------------------------------------- Reporter: matthew@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -----------------------------------+---------------------------------------- Comment(by mattaimonetti@…): still valid as of today -- Ticket URL: <http://www.macruby.org/trac/ticket/513#comment:3> MacRuby <http://macruby.org/>

1 0

Re: [MacRuby] #422: Kernel#caller compatibilty
by MacRuby 25 Nov '10

25 Nov '10

#422: Kernel#caller compatibilty -------------------------------------+-------------------------------------- Reporter: mattaimonetti@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -------------------------------------+-------------------------------------- Old description: > In a file: > > {{{ > class Foo > def self.bar > puts caller(1) > end > end > > Foo.bar > }}} > > macruby: > {{{ > core:in `caller:' > simple_caller.rb:3:in `bar' > simple_caller.rb:7:in `<main>' > }}} > > ruby1.9: > {{{ > simple_caller.rb:7:in `<main>' > }}} > > A tiny bit more advanced example: > > {{{ > class Foo > def self.bar > baz do > puts caller(1) > end > end > > def self.baz(&block) > block.call > end > end > > Foo.bar > }}} > > macruby: > > {{{ > core:in `caller:' > caller_proc.rb:9:in `baz' > caller_proc.rb:3:in `bar' > caller_proc.rb:13:in `<main>' > }}} > > ruby1.9: > > {{{ > caller_proc.rb:9:in `call' > caller_proc.rb:9:in `baz' > caller_proc.rb:3:in `bar' > caller_proc.rb:13:in `<main> > }}} > > Files attached. New description: In a file: Example: {{{ class Foo def self.bar baz do puts caller(1) end end def self.baz(&block) block.call end end Foo.bar }}} macruby: {{{ core:in `caller:' caller_proc.rb:9:in `baz' caller_proc.rb:3:in `bar' caller_proc.rb:13:in `<main>' }}} ruby1.9: {{{ caller_proc.rb:9:in `call' caller_proc.rb:9:in `baz' caller_proc.rb:3:in `bar' caller_proc.rb:13:in `<main> }}} Files attached. -- Comment(by mattaimonetti@…): The first example now works fine, block calls still don't get listed in the caller list so I'm leaving this ticket open. -- Ticket URL: <http://www.macruby.org/trac/ticket/422#comment:3> MacRuby <http://macruby.org/>

1 0

Re: [MacRuby] #382: undefined constants in Snow Leopard
by MacRuby 25 Nov '10

25 Nov '10

#382: undefined constants in Snow Leopard --------------------------------+------------------------------------------- Reporter: rich@… | Owner: lsansonetti@… Type: defect | Status: closed Priority: blocker | Milestone: MacRuby 0.8 Component: MacRuby | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by mattaimonetti@…): * status: new => closed * resolution: => fixed * milestone: => MacRuby 0.8 Comment: Closing this ticket since everything seems to be working fine, especially with the new BridgeSupport -- Ticket URL: <http://www.macruby.org/trac/ticket/382#comment:2> MacRuby <http://macruby.org/>

1 0