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

[MacRuby] #861: Abort occurs when throws an exception within Signal handler.
by MacRuby 04 Dec '10

04 Dec '10

#861: Abort occurs when throws an exception within Signal handler. ----------------------------------+----------------------------------------- Reporter: watson1978@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- Test Script: {{{ #!ruby cat t.rb begin Signal.trap(:INT) { raise "Interrupt" } Process.kill :INT, Process.pid sleep 1 rescue => e p e end }}} Result of Ruby 1.9.1: {{{ $ ruby t.rb #<RuntimeError: Interrupt> }}} Result of MacRuby Trunk: {{{ $ DYLD_LIBRARY_PATH=. ./macruby -I./lib t.rb 2010-08-20 16:22:32.883 macruby[88979:903] *** Terminating app due to uncaught exception 'RuntimeError', reason: '/Users/watson/src/MacRuby/t.rb:2:in `block': Interrupt (RuntimeError) from /Users/watson/src/MacRuby/t.rb:2:in `<main>' ' *** Call stack at first throw: ( 0 CoreFoundation 0x00007fff81865cc4 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x00007fff812050f3 objc_exception_throw + 45 2 libmacruby.1.9.2.dylib 0x00000001001535e5 rb_vm_raise + 437 3 libmacruby.1.9.2.dylib 0x00000001000400cb rb_f_raise + 43 4 libmacruby.1.9.2.dylib 0x0000000100140c69 rb_vm_dispatch + 6841 5 ??? 0x0000000103e00780 0x0 + 4359980928 6 ??? 0x0000000103e00c5d 0x0 + 4359982173 7 libmacruby.1.9.2.dylib 0x0000000100142569 rb_vm_block_eval + 1401 8 libmacruby.1.9.2.dylib 0x0000000100140c69 rb_vm_dispatch + 6841 9 libmacruby.1.9.2.dylib 0x0000000100100c95 rb_eval_cmd + 677 10 libmacruby.1.9.2.dylib 0x00000001000bc62a sighandler + 266 11 libSystem.B.dylib 0x00007fff8158a35a _sigtramp + 26 12 ??? 0x0000000000000000 0x0 + 0 13 libmacruby.1.9.2.dylib 0x0000000100140c69 rb_vm_dispatch + 6841 14 ??? 0x0000000103e00780 0x0 + 4359980928 15 ??? 0x0000000103e0023c 0x0 + 4359979580 16 libmacruby.1.9.2.dylib 0x000000010014dbb8 rb_vm_run + 488 17 libmacruby.1.9.2.dylib 0x000000010003f600 ruby_run_node + 80 18 macruby 0x0000000100000d28 main + 152 19 macruby 0x0000000100000c88 start + 52 20 ??? 0x0000000000000003 0x0 + 3 ) terminate called after throwing an instance of 'NSException' zsh: abort DYLD_LIBRARY_PATH=. ./macruby -I./lib t.rb }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/861> MacRuby <http://macruby.org/>

1 2

Re: [MacRuby] #827: Assertion fails when calls String#tr and String#tr! with replace string to above-mentioned "\u0000FFFF".
by MacRuby 04 Dec '10

04 Dec '10

#827: Assertion fails when calls String#tr and String#tr! with replace string to above-mentioned "\u0000FFFF". ----------------------------------+----------------------------------------- Reporter: watson1978@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: MacRuby Later Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- Changes (by lsansonetti@…): * milestone: => MacRuby Later Comment: Screening for later. -- Ticket URL: <http://www.macruby.org/trac/ticket/827#comment:1> MacRuby <http://macruby.org/>

1 0

Re: [MacRuby] #19: Problems with method_missing
by MacRuby 04 Dec '10

04 Dec '10

#19: Problems with method_missing ----------------------------------------+----------------------------------- Reporter: vincent.isambart@… | Owner: lsansonetti@… Type: defect | Status: closed Priority: blocker | Milestone: MacRuby 0.8 Component: MacRuby | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Changes (by lsansonetti@…): * status: new => closed * resolution: => fixed * milestone: MacRuby 0.5 => MacRuby 0.8 Comment: Looks like it's fixed for me in trunk. {{{ $ ./miniruby t.rb method unknown_method missing /Users/lrz/src/macruby-trunk/t.rb:4:in `method_missing:': super: no superclass method `method_missing' for #<NSObject:0x4004a0800> (NoMethodError) from /Users/lrz/src/macruby-trunk/t.rb:8:in `<main>' $ ruby t.rb method unknown_method missing t.rb:4:in `method_missing': super: no superclass method `unknown_method' (NoMethodError) from t.rb:8 }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/19#comment:6> MacRuby <http://macruby.org/>

1 0

Re: [MacRuby] #424: performance regression from ruby 1.8 and 1.9
by MacRuby 04 Dec '10

04 Dec '10

#424: performance regression from ruby 1.8 and 1.9 -------------------------------------+-------------------------------------- Reporter: jordan.breeding@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: MacRuby Later Component: MacRuby | Keywords: -------------------------------------+-------------------------------------- Changes (by lsansonetti@…): * milestone: => MacRuby Later Comment: Screening for Later. -- Ticket URL: <http://www.macruby.org/trac/ticket/424#comment:17> MacRuby <http://macruby.org/>

1 0

Re: [MacRuby] #834: Inspecting a string with multibyte characters from an application prints escaped characters
by MacRuby 04 Dec '10

04 Dec '10

#834: Inspecting a string with multibyte characters from an application prints escaped characters -------------------------------------+-------------------------------------- Reporter: eloy.de.enige@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: MacRuby 1.0 Component: MacRuby | Keywords: interactive-macruby -------------------------------------+-------------------------------------- Changes (by lsansonetti@…): * milestone: => MacRuby 1.0 Comment: Screening for 1.0. -- Ticket URL: <http://www.macruby.org/trac/ticket/834#comment:1> MacRuby <http://macruby.org/>

1 0

Re: [MacRuby] #772: Assertion fails with 4 bytes non-BMP UTF-8.
by MacRuby 04 Dec '10

04 Dec '10

#772: Assertion fails with 4 bytes non-BMP UTF-8. ----------------------------------+----------------------------------------- Reporter: watson1978@… | Owner: vincent.isambart@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- Comment(by vincent.isambart@…): Should be fixed (at least for chop and reverse) in r4975 -- Ticket URL: <http://www.macruby.org/trac/ticket/772#comment:5> MacRuby <http://macruby.org/>

1 0

[MacRuby] #875: super dispatches aren't cached
by MacRuby 04 Dec '10

04 Dec '10

#875: super dispatches aren't cached -----------------------------------+---------------------------------------- Reporter: lsansonetti@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: 0.7-blocker -----------------------------------+---------------------------------------- As in trunk, calls to the super dispatcher aren't cached. This needs to be fixed for 0.7. -- Ticket URL: <http://www.macruby.org/trac/ticket/875> MacRuby <http://macruby.org/>

1 1

Re: [MacRuby] #235: Problems with adding objects to scriptable applications via scripting bridge
by MacRuby 04 Dec '10

04 Dec '10

#235: Problems with adding objects to scriptable applications via scripting bridge -----------------------------------+---------------------------------------- Reporter: i.script@… | Owner: lsansonetti@… Type: defect | Status: closed Priority: blocker | Milestone: Component: MacRuby | Resolution: invalid Keywords: ScriptingBridge Error | -----------------------------------+---------------------------------------- Changes (by lsansonetti@…): * status: new => closed * resolution: => invalid * milestone: MacRuby 0.4 => Comment: Sorry about the so long reply. It doesn't seem to be a bug with MacRuby itself but more with the ScriptingBridge framework. You may want to report that problem to DEVONthink or Apple (for ScriptingBridge). -- Ticket URL: <http://www.macruby.org/trac/ticket/235#comment:1> MacRuby <http://macruby.org/>

1 0

[MacRuby] #1003: Copied Proc objects cause crash when used as Objective-C blocks
by MacRuby 03 Dec '10

03 Dec '10

#1003: Copied Proc objects cause crash when used as Objective-C blocks ----------------------------------+----------------------------------------- Reporter: al_skipp@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- Objective-C objects which copy a C block to invoke later can cause a crash/error when used in macruby. The Objective-C code is as follows (also attached as a framework): {{{ #import <Cocoa/Cocoa.h> @interface TestBlock : NSObject { void (^block)(void); } - (id)initWithBlock:(void (^)())aBlock; - (void)callBlock; @end #import "TestBlock.h" @implementation TestBlock - (id)initWithBlock:(void (^)())aBlock; { if ((self = [super init])) { block = [aBlock copy]; NSLog(@"Block: %@", block); block(); } return self; } - (void)callBlock; { NSLog(@"block: %@", block); block(); } @end }}} The following code will work if saved in an .rb file and called from Macruby. However the same code in Macirb will fail. {{{ framework File.expand_path('BlockFrameworkTest.framework') b = TestBlock.alloc.initWithBlock Proc.new { puts "hello"} b.callBlock }}} Also included is a small Xcode project that shows that the code fails when invoked from macruby, but not from objective-c. My guess is that when the object is initialized and the 'callBlock' method are invoked within the same iteration of the run loop, then the error doesn't occur. If the 'callBlock' method call occurs in a later run loop iteration, the error will occur. But that's a guess. -- Ticket URL: <http://www.macruby.org/trac/ticket/1003> MacRuby <http://macruby.org/>

1 6

[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