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

[MacRuby] #896: U_REGEX_BAD_ESCAPE_SEQUENCE on unicode escape in literal regex
by MacRuby 04 Dec '10

04 Dec '10

#896: U_REGEX_BAD_ESCAPE_SEQUENCE on unicode escape in literal regex -----------------------------------+---------------------------------------- Reporter: smparkes@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -----------------------------------+---------------------------------------- /\u{A6}/ gives regexp `\u{A6}' compilation error: U_REGEX_BAD_ESCAPE_SEQUENCE Works in 1.9.2. Regexp.new "\u{A6}" works. -- Ticket URL: <http://www.macruby.org/trac/ticket/896> MacRuby <http://macruby.org/>

1 1

[MacRuby] #1011: Sinatra fails silently on MacRuby 0.8 nightly builds
by MacRuby 04 Dec '10

04 Dec '10

#1011: Sinatra fails silently on MacRuby 0.8 nightly builds ------------------------------------+--------------------------------------- Reporter: mrada@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- Trying to run the 'Hello, world' example from the Sinatra website does not seem to work on MacRuby. However, when I try the example in macirb it does work! I can even get the Control Tower Sinatra example to work. -- Ticket URL: <http://www.macruby.org/trac/ticket/1011> MacRuby <http://macruby.org/>

1 2

[MacRuby] #922: Writing a MacFUSE fs doesn't work when delegating methods
by MacRuby 04 Dec '10

04 Dec '10

#922: Writing a MacFUSE fs doesn't work when delegating methods ------------------------------+--------------------------------------------- Reporter: kourge@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 0.7 Component: MacRuby | Keywords: ------------------------------+--------------------------------------------- I tried implementing a simple HelloFS on MacFUSE through MacRuby by referring to the [http://code.google.com/p/macfuse/source/browse/trunk /filesystems-objc/HelloFS/HelloFuseFileSystem.m HelloFuseFileSystem.m] sample. (See hellofs_working.rb) However, if the necessary methods delegate the response of another method on self, MacRuby aborts. (See hellofs.rb) This seems to occur in both 0.5 (on Leopard) and 0.6 (on Snow Leopard). -- Ticket URL: <http://www.macruby.org/trac/ticket/922> MacRuby <http://macruby.org/>

1 2

[MacRuby] #978: macirb gives a weird error when I dereference a pointer to a CFArray
by MacRuby 04 Dec '10

04 Dec '10

#978: macirb gives a weird error when I dereference a pointer to a CFArray ------------------------------------+--------------------------------------- Reporter: mrada@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: macirb error ------------------------------------+--------------------------------------- The error is: TypeError: can't convert Class into String I have attached a short script to demo this. The message is not printed when you require the file or run it with macruby. If you copy and paste the code into macirb you will see the error message. -- Ticket URL: <http://www.macruby.org/trac/ticket/978> MacRuby <http://macruby.org/>

1 3

[MacRuby] #974: Failed assertion when creating pointer Pointers
by MacRuby 04 Dec '10

04 Dec '10

#974: Failed assertion when creating pointer Pointers ------------------------------------+--------------------------------------- Reporter: mrada@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- # macirb irb(main):001:0> Pointer.new '^' Assertion failed: (len > 0), function compile_const_global_string, file compiler.cpp, line 595. zsh: abort macirb -- Ticket URL: <http://www.macruby.org/trac/ticket/974> MacRuby <http://macruby.org/>

1 3

[MacRuby] #920: macirb takes too long to launch
by MacRuby 04 Dec '10

04 Dec '10

#920: macirb takes too long to launch ---------------------------------------+------------------------------------ Reporter: matt.massicotte@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ---------------------------------------+------------------------------------ macirb takes between 1 and 2 seconds to produce a prompt. That's a very long time, and significantly longer than irb. -- Ticket URL: <http://www.macruby.org/trac/ticket/920> MacRuby <http://macruby.org/>

1 1

[MacRuby] #941: curb gem does not build under MacRuby
by MacRuby 04 Dec '10

04 Dec '10

#941: curb gem does not build under MacRuby ------------------------------------+--------------------------------------- Reporter: mrada@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- Ripped almost verbatim from the macruby-dev mailing list: curb does not compile successfully for MacRuby. Normally you have to compile curb with a universal binary of libcurl to get it running on MRI, so I suspect that architecture incompatibility has something to do with why the build is failing. I get the following when I try to install with macgem: /usr/bin/gcc -I. -I/Library/Frameworks/MacRuby.framework/Versions/0.7/usr/include/ruby-1.9.2 /universal-darwin10.0 -I/Library/Frameworks/MacRuby.framework/Versions/0.7/usr/include/ruby-1.9.2/ruby/backward -I/Library/Frameworks/MacRuby.framework/Versions/0.7/usr/include/ruby-1.9.2 -I. -DRUBY_EXTCONF_H=\"curb_config.h\" -fno-common -arch i386 -arch x86_64 -fexceptions -fno-common -pipe -O3 -g -Wall -I/opt/local/include -g -Wall -arch i386 -arch x86_64 -o curb_multi.o -c curb_multi.c curb_multi.c: In function ‘rb_curl_multi_mark_all_easy’: curb_multi.c:38: warning: implicit declaration of function ‘rb_gc_mark’ curb_multi.c: In function ‘curl_multi_free’: curb_multi.c:64: warning: implicit declaration of function ‘RHASH’ curb_multi.c:64: error: invalid type argument of ‘->’ curb_multi.c: In function ‘rb_curl_multi_mark_all_easy’: curb_multi.c:38: warning: implicit declaration of function ‘rb_gc_mark’ curb_multi.c: In function ‘curl_multi_free’: curb_multi.c:64: warning: implicit declaration of function ‘RHASH’ curb_multi.c:64: error: invalid type argument of ‘->’ lipo: can't open input file: /var/tmp//ccbAYK9V.out (No such file or directory) make: *** [curb_multi.o] Error 1 > It looks like this C extension is using an element of the MRI C API that we do not support yet. I am guessing it's poking at the RHASH structure, which we won't probably support any time soon. >> Should I create a ticket for this? >>> Why not... but I don't think it will be ever fixed :( -- Ticket URL: <http://www.macruby.org/trac/ticket/941> MacRuby <http://macruby.org/>

1 1

[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

[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

[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