From ruby-noreply at macosforge.org Mon Aug 1 15:44:39 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Mon, 01 Aug 2011 22:44:39 -0000 Subject: [MacRuby] #1322: Xcode 4.1/4.2 In-Reply-To: <057.d1af71e9afb5deed33ab3294af73dc7b@macosforge.org> References: <057.d1af71e9afb5deed33ab3294af73dc7b@macosforge.org> Message-ID: <066.f553dd48145274503398622522c316ec@macosforge.org> #1322: Xcode 4.1/4.2 ----------------------------------------+----------------------------------- Reporter: d.dagostino@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------------+----------------------------------- Comment(by mattaimonetti@?): FYI: This is a follow up to Bug ID# 9850538. After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering. This issue has been filed in our bug database under the original Bug ID# 9828745. The original bug number being used to track this duplicate issue can be found in the State column, in this format: Duplicate/OrigBug#. Let's hope the next preview fixes this bug. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Mon Aug 1 15:46:21 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Mon, 01 Aug 2011 22:46:21 -0000 Subject: [MacRuby] #1371: MacRuby evaluates the first method defined using define_method through #send Message-ID: <053.1046a94cc489bf180742d2435257ef1b@macosforge.org> #1371: MacRuby evaluates the first method defined using define_method through #send ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: reduction ------------------------------------+--------------------------------------- Discovered this problem while on a crusade to eliminate string eval usage in hot cocoa: Reduction: {{{ a = Module.new a.send :define_method, :test do |value| puts 'first' end a.send :define_method, :something_else do |value| puts 'second' end }}} If you run the code, it will print 'first', but not second. If you then swap the order of the define_method calls and run it again, it will print 'second', but will not print 'first'. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Mon Aug 1 15:51:37 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Mon, 01 Aug 2011 22:51:37 -0000 Subject: [MacRuby] #1371: MacRuby evaluates the first method defined using define_method through #send In-Reply-To: <053.1046a94cc489bf180742d2435257ef1b@macosforge.org> References: <053.1046a94cc489bf180742d2435257ef1b@macosforge.org> Message-ID: <062.59fefe375bb10a2cd28350c2b9dc1d03@macosforge.org> #1371: MacRuby evaluates the first method defined using define_method through #send ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: reduction ------------------------------------+--------------------------------------- Comment(by mrada@?): I should also mention that this can be worked around by creating a Proc and passing it as an argument. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Mon Aug 1 16:17:56 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Mon, 01 Aug 2011 23:17:56 -0000 Subject: [MacRuby] #1322: Xcode 4.1/4.2 In-Reply-To: <057.d1af71e9afb5deed33ab3294af73dc7b@macosforge.org> References: <057.d1af71e9afb5deed33ab3294af73dc7b@macosforge.org> Message-ID: <066.fd8749d3e5836e925bd2098326ac7177@macosforge.org> #1322: Xcode 4.1/4.2 ----------------------------------------+----------------------------------- Reporter: d.dagostino@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------------+----------------------------------- Comment(by mrada@?): Woohoo! -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Mon Aug 1 18:55:17 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 02 Aug 2011 01:55:17 -0000 Subject: [MacRuby] #1322: Xcode 4.1/4.2 In-Reply-To: <057.d1af71e9afb5deed33ab3294af73dc7b@macosforge.org> References: <057.d1af71e9afb5deed33ab3294af73dc7b@macosforge.org> Message-ID: <066.33aa2926cd3895a3b6fc6d1d7fe2aa27@macosforge.org> #1322: Xcode 4.1/4.2 ----------------------------------------+----------------------------------- Reporter: d.dagostino@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------------+----------------------------------- Comment(by scott@?): @paolo.bosetti I discovered an issue with your workaround description. I've decided to be very pedantic with an example in the form of a [https://gist.github.com/1119430 gist]. tl;dr If you declare outlets in an Obj-C header file, don't redefine those outlets in the ruby file. Doing so will limit your ability to access the values that are initialized when the class in instantiated by the nib. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 3 11:58:44 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 03 Aug 2011 18:58:44 -0000 Subject: [MacRuby] #1372: Exceptions thrown inside dispatch queue blocks propagate as uncaught objective-c exceptions Message-ID: <053.457ed75ea3700d553efd27a1582e7887@macosforge.org> #1372: Exceptions thrown inside dispatch queue blocks propagate as uncaught objective-c exceptions ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: reduction ------------------------------------+--------------------------------------- Specifically, I had this problem because a test assertion inside of a block failed. Reduction: {{{ a = Dispatch::Queue.new 'org.macruby.test' a.sync { raise Exception, 'oh noses' } }}} -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 3 13:18:29 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 03 Aug 2011 20:18:29 -0000 Subject: [MacRuby] #1372: Exceptions thrown inside dispatch queue blocks propagate as uncaught objective-c exceptions In-Reply-To: <053.457ed75ea3700d553efd27a1582e7887@macosforge.org> References: <053.457ed75ea3700d553efd27a1582e7887@macosforge.org> Message-ID: <062.cd52e9a942e2a1b6253bd657c1c46664@macosforge.org> #1372: Exceptions thrown inside dispatch queue blocks propagate as uncaught objective-c exceptions ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: reduction ------------------------------------+--------------------------------------- Comment(by eloy.de.enige@?): From http://developer.apple.com/library/mac/#documentation/Performance/Reference/GCD_libdispatch_Ref/Reference/reference.html: {{{ GCD is a C level API; it does not catch exceptions generated by higher level languages. Your application must catch all exceptions before returning from a block submitted to a dispatch queue. }}} So I guess MacRuby does the same, might be a performance issue. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 3 14:06:13 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 03 Aug 2011 21:06:13 -0000 Subject: [MacRuby] #1372: Exceptions thrown inside dispatch queue blocks propagate as uncaught objective-c exceptions In-Reply-To: <053.457ed75ea3700d553efd27a1582e7887@macosforge.org> References: <053.457ed75ea3700d553efd27a1582e7887@macosforge.org> Message-ID: <062.77af1cc290916a1474fc6af9ba7ec56a@macosforge.org> #1372: Exceptions thrown inside dispatch queue blocks propagate as uncaught objective-c exceptions ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: reduction ------------------------------------+--------------------------------------- Comment(by mrada@?): The following case is handled (properly?): {{{ a = Dispatch::Queue.new 'org.macruby.test' a.sync { 1 + 'e' } }}} So you think it is just slow to handle in the general case? Seems weird since it might be possible for unexpected exceptions to crash MacRuby and the workaround is to catch the exception inside the block and then re-raise outside the block so the proper handler can deal with the exception. This would be the case with mintiest. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 3 14:11:13 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 03 Aug 2011 21:11:13 -0000 Subject: [MacRuby] #1372: Exceptions thrown inside dispatch queue blocks propagate as uncaught objective-c exceptions In-Reply-To: <053.457ed75ea3700d553efd27a1582e7887@macosforge.org> References: <053.457ed75ea3700d553efd27a1582e7887@macosforge.org> Message-ID: <062.d370cfe7bb8455c79f96d3f2ac9acdc1@macosforge.org> #1372: Exceptions thrown inside dispatch queue blocks propagate as uncaught objective-c exceptions ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: reduction ------------------------------------+--------------------------------------- Comment(by mrada@?): Actually, looks like variables are copied in, but not copied out afterwards: {{{ a = Dispatch::Queue.new 'org.macruby.test' exception = nil a.sync { begin raise Exception, 'oh noses' rescue Exception => e exception = e end } puts exception.inspect }}} So I'm not sure how to work around this issue. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 3 14:25:48 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 03 Aug 2011 21:25:48 -0000 Subject: [MacRuby] #1372: Exceptions thrown inside dispatch queue blocks propagate as uncaught objective-c exceptions In-Reply-To: <053.457ed75ea3700d553efd27a1582e7887@macosforge.org> References: <053.457ed75ea3700d553efd27a1582e7887@macosforge.org> Message-ID: <062.f862e5a0cfe16a709a25d3089f7576d8@macosforge.org> #1372: Exceptions thrown inside dispatch queue blocks propagate as uncaught objective-c exceptions ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: reduction ------------------------------------+--------------------------------------- Comment(by eloy.de.enige@?): Yes, local variables are copied. Instance variables, however, are not. Yup, lot's of rules :) -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 3 22:07:02 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Thu, 04 Aug 2011 05:07:02 -0000 Subject: [MacRuby] #1372: Exceptions thrown inside dispatch queue blocks propagate as uncaught objective-c exceptions In-Reply-To: <053.457ed75ea3700d553efd27a1582e7887@macosforge.org> References: <053.457ed75ea3700d553efd27a1582e7887@macosforge.org> Message-ID: <062.f6d0d1cc819da4e495e5635998518a02@macosforge.org> #1372: Exceptions thrown inside dispatch queue blocks propagate as uncaught objective-c exceptions ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: reduction ------------------------------------+--------------------------------------- Comment(by mrada@?): Ok, cool, at least there is a workaround. I can see why the rules exist, but they still make me say OMGCD. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 3 22:28:02 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Thu, 04 Aug 2011 05:28:02 -0000 Subject: [MacRuby] #1322: Xcode 4.1/4.2 In-Reply-To: <057.d1af71e9afb5deed33ab3294af73dc7b@macosforge.org> References: <057.d1af71e9afb5deed33ab3294af73dc7b@macosforge.org> Message-ID: <066.ed592c8b68423329a4c5242e644f3ca0@macosforge.org> #1322: Xcode 4.1/4.2 ----------------------------------------+----------------------------------- Reporter: d.dagostino@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------------+----------------------------------- Comment(by shaun@?): I discovered a workaround of my own but it is a bit involved. I am using VMWare Fusion to run a virtual machine with Snow Leopard Server (it can be done without the server version - google around) and Xcode 4.0.1 installed. I am opening a project in both Lion and Snow Leopard Server at the same time and I am using the Snow Leopard server virtual machine to connect the IB outlets and actions. I can then use Lion to code and test and the file builds without errors. HTH -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 3 22:47:59 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Thu, 04 Aug 2011 05:47:59 -0000 Subject: [MacRuby] #1102: segfault when trying const_get on unitialized constant with rspec2 In-Reply-To: <053.37de3bcf944850866110f1d562383682@macosforge.org> References: <053.37de3bcf944850866110f1d562383682@macosforge.org> Message-ID: <062.7a70da0d515b137b30e16be340fe1028@macosforge.org> #1102: segfault when trying const_get on unitialized constant with rspec2 ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- Comment(by scott@?): This still occurs with the latest nightly (Aug 3, 2011) and with rspec 2.6.0. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 3 22:55:12 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Thu, 04 Aug 2011 05:55:12 -0000 Subject: [MacRuby] #1373: Better error reporting is needed for infinite recursion Message-ID: <051.691108d64993a55b58943dd9d92b4340@macosforge.org> #1373: Better error reporting is needed for infinite recursion ----------------------------------+----------------------------------------- Reporter: scott@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- Infinite recursion in MRI reports that the stack is too deep. With MacRuby, "segmentation fault: 11" is dumped to the console. Here's a simple test: {{{ def recurse recurse end recurse }}} MRI output: {{{ test.rb:2:in `recurse': stack level too deep (SystemStackError) from test.rb:2:in `recurse' from test.rb:5 }}} MacRuby output: {{{ Segmentation fault: 11 }}} -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Thu Aug 4 10:03:23 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Thu, 04 Aug 2011 17:03:23 -0000 Subject: [MacRuby] #1322: Xcode 4.1/4.2 In-Reply-To: <057.d1af71e9afb5deed33ab3294af73dc7b@macosforge.org> References: <057.d1af71e9afb5deed33ab3294af73dc7b@macosforge.org> Message-ID: <066.de2fd05cce191f9db8b9f52aec54a7f3@macosforge.org> #1322: Xcode 4.1/4.2 ----------------------------------------+----------------------------------- Reporter: d.dagostino@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------------+----------------------------------- Comment(by paolo.bosetti@?): Hi all, After some testing, I just wanted to clarify my workaround. If your ruby window delegate class is named AppController, create a new Obj-C class named AppController, subclass of NSObject and conforming to NSApplicationDelegate protocol. Its interface file should be like this: {{{ @interface AppDelegate : NSObject { } @end }}} At this point, open side by side the nib file and the interface file (.h), add controls to the window, then control-drag from controls to the interface file. On the popover, choose action or outlet and give it the name. Now click on the project entry on the leftmost tree in Xcode window, and duplicate the target of your app. Call the duplicate "Workaround". In the target settings, under "build phases", REMOVE the AppDelegate.m file from the Compile Sources list. At this point, you simply have to switch to the "Workaround" target when you have to add/edit outlets or actions to your nib, then switch back to the main target, and edit accordingly the ruby interface file, i.e. add the same action methods and the same attar_accessor you defined in the Obj-C interface file. Essentially, you have two targets, one only used for nib setup (which includes the Obj-C files), and one used for ruby development and testing. I did a few tests and It seems to work fine. It is also easier than having a second virtualized SL installation as suggested by shaun. This should also answer to scott's objection. Cheers, -P. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Fri Aug 5 20:12:46 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Sat, 06 Aug 2011 03:12:46 -0000 Subject: [MacRuby] #1374: GC problems when using AVFoundation Message-ID: <053.e99964fd97511d98099906cc03b7a098@macosforge.org> #1374: GC problems when using AVFoundation ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- I have small script that I wrote to try out a new framework in Lion; it just does some screen capture and outputs it to a file. However, I get this message a lot when I run the attached example code: {{{ 2011-08-05 22:48:40.760 macruby[26457:5a03] storing a non-GC object 0x7f95de3eb678 in a GC collection, break on CFCollection_non_gc_storage_error to debug. }}} -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Sat Aug 6 03:29:48 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Sat, 06 Aug 2011 10:29:48 -0000 Subject: [MacRuby] #1375: GC doesn't like Hello World Message-ID: <042.d0c758a2f370ffaf49835e3bbfce98fc@macosforge.org> #1375: GC doesn't like Hello World -------------------------+-------------------------------------------------- Reporter: emil@? | Owner: lsansonetti@? Type: defect | Status: new Priority: major | Milestone: MacRuby 0.11 Component: MacRuby | Keywords: gc -------------------------+-------------------------------------------------- Hello World example works, but the GC doesn't seem happy when you click the hello world button: $ curl https://raw.github.com/mattetti/MacRuby--The-Definitive- Guide/master/chapter_1/hello_world.rb > hello_world.rb % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1074 100 1074 0 0 2152 0 --:--:-- --:--:-- --:--:-- 2658 $ macruby hello_world.rb Hello World! macruby(52532,0x10de04000) malloc: *** auto malloc[52532]: error: GC operation on unregistered thread. Thread registered implicitly. Break on auto_zone_thread_registration_error() to debug. Running os x 10.7 with MacRuby 0.10 installed from binary. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Sun Aug 7 08:36:42 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Sun, 07 Aug 2011 15:36:42 -0000 Subject: [MacRuby] #542: Attempt to unlock a mutex which is not locked (ThreadError) In-Reply-To: <054.1a4ef5ffee450b4e3f8e1220d38c91ee@macosforge.org> References: <054.1a4ef5ffee450b4e3f8e1220d38c91ee@macosforge.org> Message-ID: <063.a3015c94e7a6b1e021e362fc64228c3e@macosforge.org> #542: Attempt to unlock a mutex which is not locked (ThreadError) -------------------------------------+-------------------------------------- Reporter: valerii.hiora@? | Owner: lsansonetti@? Type: defect | Status: new Priority: major | Milestone: MacRuby 1.0 Component: MacRuby | Keywords: -------------------------------------+-------------------------------------- Comment(by jhemmelg@?): Re-locking the mutex at the end of mutex_sleep() (in thread.c) seems to fix this problem completely. Pull request sent. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Sun Aug 7 09:27:58 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Sun, 07 Aug 2011 16:27:58 -0000 Subject: [MacRuby] #542: Attempt to unlock a mutex which is not locked (ThreadError) In-Reply-To: <054.1a4ef5ffee450b4e3f8e1220d38c91ee@macosforge.org> References: <054.1a4ef5ffee450b4e3f8e1220d38c91ee@macosforge.org> Message-ID: <063.ba6e055008d10bb336463fc9599346e7@macosforge.org> #542: Attempt to unlock a mutex which is not locked (ThreadError) -------------------------------------+-------------------------------------- Reporter: valerii.hiora@? | Owner: lsansonetti@? Type: defect | Status: closed Priority: major | Milestone: MacRuby 0.11 Component: MacRuby | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Changes (by watson1978@?): * status: new => closed * resolution: => fixed * milestone: MacRuby 1.0 => MacRuby 0.11 Comment: Awesome! Thank you for your great works! Fixed with https://github.com/MacRuby/MacRuby/commit/a8e8922360d1e95c75483555eed570666ff95574 -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 9 14:16:26 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 09 Aug 2011 21:16:26 -0000 Subject: [MacRuby] #1376: C API should include RREGEXP Message-ID: <045.42ac169b52e10a0b255c7a3694725a9f@macosforge.org> #1376: C API should include RREGEXP ----------------------------+----------------------------------------------- Reporter: kyle@? | Owner: lsansonetti@? Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: ----------------------------+----------------------------------------------- The standard Ruby C API includes a macro, RREGEXP, which provides access to the source and options strings of a given Ruby regular expression. In addition, sometimes RREGEXP_SRC is defined, and it returns a Ruby string object. RREGEXP_OPTIONS is also often defined, and it returns a long integer. Is there any way that these macros can be made part of the public C API so that C extensions that work with other Ruby implementations will also work with MacRuby? -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 10 05:27:41 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 10 Aug 2011 12:27:41 -0000 Subject: [MacRuby] #203: Marshal.dump does not serialize an Exception's backtrace In-Reply-To: <057.7e85dbc51be90be2f8d5ea59f4581b5f@macosforge.org> References: <057.7e85dbc51be90be2f8d5ea59f4581b5f@macosforge.org> Message-ID: <066.0c3bbff45ed8ef73c9b4f656aeece551@macosforge.org> #203: Marshal.dump does not serialize an Exception's backtrace ----------------------------------------+----------------------------------- Reporter: vincent.isambart@? | Owner: lsansonetti@? Type: defect | Status: closed Priority: major | Milestone: MacRuby 0.11 Component: MacRuby | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Changes (by watson1978@?): * status: new => closed * resolution: => fixed * milestone: MacRuby 1.0 => MacRuby 0.11 Comment: Fixed with https://github.com/MacRuby/MacRuby/commit/9cad55f996ea489e8aa8224113019a2f66385dad -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 10 12:07:27 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 10 Aug 2011 19:07:27 -0000 Subject: [MacRuby] #1233: Abort occurs when kill a thread waiting with IO.select In-Reply-To: <051.31a4555dca3b4ede25ef1a1b95e65a9c@macosforge.org> References: <051.31a4555dca3b4ede25ef1a1b95e65a9c@macosforge.org> Message-ID: <060.b3683e01e148da97f5e1f0ad44e073ff@macosforge.org> #1233: Abort occurs when kill a thread waiting with IO.select ----------------------------------+----------------------------------------- Reporter: watson1978@? | Owner: lsansonetti@? Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- Comment(by jhemmelg@?): The same thing happens when you print in the thread: {{{ t = Thread.new do print "thread\n" end t.kill }}} {{{ $ macruby t2.rb terminate called after throwing an instance of 'RoxorThreadRaiseException*' Abort trap }}} So it may be a general I/O problem rather than being specific to the select call. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 10 17:39:13 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Thu, 11 Aug 2011 00:39:13 -0000 Subject: [MacRuby] #1326: Cannot create nested modules with names used by Cocoa classes when using the C API In-Reply-To: <053.186d3748fde5af2d087158bccdeaae1c@macosforge.org> References: <053.186d3748fde5af2d087158bccdeaae1c@macosforge.org> Message-ID: <062.db16f85697ef8fd952c053167a80cc72@macosforge.org> #1326: Cannot create nested modules with names used by Cocoa classes when using the C API ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- Comment(by mrada@?): This is caused by how constants are looked up. In variable.c both rb_const_defined_0 and rb_const_get_0 check for Cocoa classes even if the lookup should not be recursive. I think it is an easy fix that I can do tonight... -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 10 17:57:27 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Thu, 11 Aug 2011 00:57:27 -0000 Subject: [MacRuby] #1377: macirb should catch control-c like the CRuby irb Message-ID: <053.79b923f35ac0a41e8808f66716f68f01@macosforge.org> #1377: macirb should catch control-c like the CRuby irb ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- When I hit control+c in macirb it will always quit macirb, however, sometimes I just want to escape a long operation that I did incorrectly. When I hit control+c in the irb client that CRuby comes with the signal is caught and the operation is aborted, but the rib session continues to run. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Thu Aug 11 10:57:27 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Thu, 11 Aug 2011 17:57:27 -0000 Subject: [MacRuby] #1326: Cannot create nested modules with names used by Cocoa classes when using the C API In-Reply-To: <053.186d3748fde5af2d087158bccdeaae1c@macosforge.org> References: <053.186d3748fde5af2d087158bccdeaae1c@macosforge.org> Message-ID: <062.ebefe11331a15a3ac00bffd50bbb95e4@macosforge.org> #1326: Cannot create nested modules with names used by Cocoa classes when using the C API ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- Comment(by mrada@?): I made my fix and pushed to github: https://github.com/ferrous26/MacRuby/commit/33ccff6a9d86f616b30df6cbef9b79550e89e813 However, it is causing one of the specs to crash the entire test suite: {{{ 0 libunwind.dylib 0x00007fff899e5960 libunwind::LocalAddressSpace::getEncodedP(unsigned long long&, unsigned long long, unsigned char) + 234 1 libunwind.dylib 0x00007fff899e74e3 libunwind::CFI_Parser::decodeFDE(libunwind::LocalAddressSpace&, unsigned long long, libunwind::CFI_Parser::FDE_Info*, libunwind::CFI_Parser::CIE_Info*) + 335 2 libunwind.dylib 0x00007fff899e5b07 _unw_add_dynamic_fde + 31 3 libmacruby.dylib 0x000000010ed37dfb llvm::ExecutionEngine::RegisterTable(llvm::Function const*, void*) + 47 4 libmacruby.dylib 0x000000010ed360a3 (anonymous namespace)::JITEmitter::finishFunction(llvm::MachineFunction&) + 3413 5 libmacruby.dylib 0x000000010eb64317 (anonymous namespace)::Emitter::runOnMachineFunction(llvm::MachineFunction&) + 379 6 libmacruby.dylib 0x000000010ed961f5 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 117 7 libmacruby.dylib 0x000000010f05c898 llvm::FPPassManager::runOnFunction(llvm::Function&) + 306 8 libmacruby.dylib 0x000000010f05d9ba llvm::FunctionPassManagerImpl::run(llvm::Function&) + 212 9 libmacruby.dylib 0x000000010f05dad5 llvm::FunctionPassManager::run(llvm::Function&) + 79 10 libmacruby.dylib 0x000000010ed29c0f llvm::JIT::getPointerToFunction(llvm::Function*) + 599 11 libmacruby.dylib 0x000000010eae6361 RoxorCore::compile(llvm::Function*, bool) + 145 (vm.cpp:595) 12 libmacruby.dylib 0x000000010eaddb7b rb_vm_prepare_block + 1467 (dispatcher.cpp:1392) 13 ??? 0x0000000114575d1b 0 + 4636237083 }}} I guess something is going wrong when an exception is being raised? I'll try and track down the specific spec later... -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 16 20:20:41 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 17 Aug 2011 03:20:41 -0000 Subject: [MacRuby] #1375: GC doesn't like Hello World In-Reply-To: <042.d0c758a2f370ffaf49835e3bbfce98fc@macosforge.org> References: <042.d0c758a2f370ffaf49835e3bbfce98fc@macosforge.org> Message-ID: <051.5d40dbc0dc3a8e4527dceeb6239f16ce@macosforge.org> #1375: GC doesn't like Hello World -------------------------+-------------------------------------------------- Reporter: emil@? | Owner: lsansonetti@? Type: defect | Status: new Priority: major | Milestone: MacRuby 0.11 Component: MacRuby | Keywords: gc -------------------------+-------------------------------------------------- Comment(by watson1978@?): I rewrote a hello_world app by Objective-C. (enabled Objective-C's Garbage Collector) Similarly MacRuby app, this application prints a GC error message as following. {{{ hello_world(15357,0x108b39000) malloc: *** auto malloc[15357]: error: GC operation on unregistered thread. Thread registered implicitly. Break on auto_zone_thread_registration_error() to debug. }}} Is this Apple's framework issues? -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Thu Aug 18 11:53:11 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Thu, 18 Aug 2011 18:53:11 -0000 Subject: [MacRuby] #1378: RE2 gem will not compile Message-ID: <047.7503ffa00c07091428afa2c1e3aadb5c@macosforge.org> #1378: RE2 gem will not compile ------------------------------+--------------------------------------------- Reporter: xperts@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------+--------------------------------------------- I had thought that C based gems didn't work at all with MacRuby 1.0. But Matt suggested I make a ticket on this issue. I'm having an issue where I need named expression groups to work with my regexps, this doesn't work within MacRuby so I've tried to install RE2, but that doesn't work either: sudo macgem install re2 Password: Building native extensions. This could take a while... ERROR: Error installing re2: ERROR: Failed to build gem native extension. /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/bin/macruby extconf.rb checking for main() in -lstdc++... yes checking for main() in -lre2... yes creating Makefile make /usr/bin/g++ -I. -I/Library/Frameworks/MacRuby.framework/Versions/0.10/usr/include/ruby-1.9.2 /universal-darwin10.0 -I/Library/Frameworks/MacRuby.framework/Versions/0.10/usr/include/ruby-1.9.2/ruby/backward -I/Library/Frameworks/MacRuby.framework/Versions/0.10/usr/include/ruby-1.9.2 -I. -I/usr/local/include -fno-common -arch x86_64 -fexceptions -fno- common -pipe -O3 -g -Wall -Wall -Wextra -funroll-loops -arch x86_64 -arch x86_64 -o re2.o -c re2.cc re2.cc: In function ?void re2_matchdata_mark(re2_matchdata*)?: re2.cc:45: error: ?rb_gc_mark? was not declared in this scope re2.cc: In function ?VALUE re2_Replace(VALUE, VALUE, VALUE, VALUE)?: re2.cc:933: error: invalid conversion from ?const void*? to ?void*? re2.cc:933: error: initializing argument 1 of ?void* memcpy(void*, const void*, size_t)? re2.cc: In function ?VALUE re2_GlobalReplace(VALUE, VALUE, VALUE, VALUE)?: re2.cc:983: error: invalid conversion from ?const void*? to ?void*? re2.cc:983: error: initializing argument 1 of ?void* memcpy(void*, const void*, size_t)? make: *** [re2.o] Error 1 -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Thu Aug 18 16:10:03 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Thu, 18 Aug 2011 23:10:03 -0000 Subject: [MacRuby] #1379: Gem rev-0.3.2 fails to build Message-ID: <049.8787439a54b4413792aff2b286a51b33@macosforge.org> #1379: Gem rev-0.3.2 fails to build --------------------------------+------------------------------------------- Reporter: jhemmelg@? | Owner: lsansonetti@? Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- I am running the latest code from github. I was installing the gem msgpack-rpc which depends on rev. The build of the rev gem failed with the following message: {{{ /usr/bin/gcc-4.2 -I. -I/Library/Frameworks/MacRuby.framework/Versions/0.11/usr/include/ruby-1.9.2 /universal-darwin10.0 -I/Library/Frameworks/MacRuby.framework/Versions/0.11/usr/include/ruby-1.9.2/ruby/backward -I/Library/Frameworks/MacRuby.framework/Versions/0.11/usr/include/ruby-1.9.2 -I. -DRUBY_VERSION_CODE=192 -DHAVE_RB_THREAD_BLOCKING_REGION -DHAVE_RB_THREAD_BLOCKING_REGION -DHAVE_RB_THREAD_ALONE -DHAVE_RB_THREAD_ALONE -DHAVE_RB_STR_SET_LEN -DHAVE_RB_STR_SET_LEN -DHAVE_SYS_SELECT_H -DEV_USE_SELECT -DHAVE_POLL_H -DEV_USE_POLL -DHAVE_SYS_EVENT_H -DHAVE_SYS_QUEUE_H -DEV_USE_KQUEUE -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_SSL_H -DHAVE_SYS_RESOURCE_H -DHAVE_SYS_RESOURCE_H -DHAVE_SYSCTLBYNAME -DHAVE_SYSCTLBYNAME -fno-common -arch x86_64 -fexceptions -fno-common -pipe -O3 -g -Wall -arch x86_64 -o rev_loop.o -c rev_loop.c rev_loop.c: In function ?Rev_Loop_initialize?: rev_loop.c:93: warning: no return statement in function returning non-void rev_loop.c: In function ?Rev_Loop_run_nonblock?: rev_loop.c:278: error: ?TRAP_BEG? undeclared (first use in this function) rev_loop.c:278: error: (Each undeclared identifier is reported only once rev_loop.c:278: error: for each function it appears in.) rev_loop.c:280: error: ?TRAP_END? undeclared (first use in this function) make: *** [rev_loop.o] Error 1 }}} These gems installed successfully on 1.8.7 and 1.9.2. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Fri Aug 19 12:14:37 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Fri, 19 Aug 2011 19:14:37 -0000 Subject: [MacRuby] #1322: Xcode 4.1/4.2 In-Reply-To: <057.d1af71e9afb5deed33ab3294af73dc7b@macosforge.org> References: <057.d1af71e9afb5deed33ab3294af73dc7b@macosforge.org> Message-ID: <066.ccb202c1b7fd8cc1dc1f1bbd9e5a4306@macosforge.org> #1322: Xcode 4.1/4.2 ----------------------------------------+----------------------------------- Reporter: d.dagostino@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------------+----------------------------------- Comment(by mrada@?): Those with access to 4.2 betas should try with the latest seed. It seems to work for me. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Fri Aug 19 12:50:40 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Fri, 19 Aug 2011 19:50:40 -0000 Subject: [MacRuby] #1322: Xcode 4.1/4.2 In-Reply-To: <057.d1af71e9afb5deed33ab3294af73dc7b@macosforge.org> References: <057.d1af71e9afb5deed33ab3294af73dc7b@macosforge.org> Message-ID: <066.3d06b69fb897078b6247c8e0536deedd@macosforge.org> #1322: Xcode 4.1/4.2 ----------------------------------------+----------------------------------- Reporter: d.dagostino@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------------+----------------------------------- Comment(by guido.soranzio@?): I confirm: the latest beta calls rb_nibtool again. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Fri Aug 19 19:56:27 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Sat, 20 Aug 2011 02:56:27 -0000 Subject: [MacRuby] #958: Errno::EAGAIN occurs when read data from socket within Webrick. In-Reply-To: <051.0b2acefdeec4080a3d1cb1dc21f7b20d@macosforge.org> References: <051.0b2acefdeec4080a3d1cb1dc21f7b20d@macosforge.org> Message-ID: <060.4b510fa4e49fd102b24ed9130a4f4859@macosforge.org> #958: Errno::EAGAIN occurs when read data from socket within Webrick. ----------------------------------+----------------------------------------- Reporter: watson1978@? | Owner: lsansonetti@? Type: defect | Status: closed Priority: major | Milestone: MacRuby 0.11 Component: MacRuby | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Changes (by watson1978@?): * status: new => closed * resolution: => fixed * milestone: MacRuby 1.0 => MacRuby 0.11 Comment: Fixed with https://github.com/MacRuby/MacRuby/commit/f0633b34645dd1bfce264db367ae9417a778e4a9 -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Sat Aug 20 08:36:54 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Sat, 20 Aug 2011 15:36:54 -0000 Subject: [MacRuby] #1377: macirb should catch control-c like the CRuby irb In-Reply-To: <053.79b923f35ac0a41e8808f66716f68f01@macosforge.org> References: <053.79b923f35ac0a41e8808f66716f68f01@macosforge.org> Message-ID: <062.d6ff2ae83809cfdc285ad41108e38cc7@macosforge.org> #1377: macirb should catch control-c like the CRuby irb ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: closed Priority: major | Milestone: Component: MacRuby | Resolution: duplicate Keywords: | ------------------------------------+--------------------------------------- Changes (by eloy.de.enige@?): * status: new => closed * resolution: => duplicate Comment: The code actually does implement it and it works on CRuby (1.9). However, on MacRuby there's a bug :{ See #937. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Sun Aug 21 00:06:37 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Sun, 21 Aug 2011 07:06:37 -0000 Subject: [MacRuby] #1380: YAML problems in recent nightly builds Message-ID: <053.b0abedcc4c99962abfe31dee38478925@macosforge.org> #1380: YAML problems in recent nightly builds ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- rubygems can no longer parse gem specs if they contain strings that were assigned from a here doc. Example: {{{ s.description = <<-EOS HotCocoa is a Cocoa mapping library for MacRuby. It simplifies the use of complex Cocoa classes using DSL techniques. EOS }}} That example worked fine about a week ago. The gem will build without error, but it will not install and I will get the following error: {{{ scanning error encountered during parsing: could not find expected ':' (line 65, column 0), context while scanning a simple key (line 64, column 0) }}} If I unpack the gem and look at the decompressed metadata.gz, I find these at lines 64-66: {{{ description: | HotCocoa is a Cocoa mapping library for MacRuby. It simplifies the use of complex Cocoa classes using DSL techniques. email: }}} If I change the gem spec to not use a here doc then the gem builds and installs properly. {{{ s.description = <<' HotCocoa is a Cocoa mapping library for MacRuby. It simplifies the use of complex Cocoa classes using DSL techniques. ' }}} And in the unpacked metadata.gz I see the following: {{{ description: "\nHotCocoa is a Cocoa mapping library for MacRuby. It simplifies the use of complex Cocoa classes using DSL techniques.\n " email: }}} This broke pretty much all of my projects since I always use here docs for the description of the gem. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Sun Aug 21 01:07:21 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Sun, 21 Aug 2011 08:07:21 -0000 Subject: [MacRuby] #1380: YAML problems in recent nightly builds In-Reply-To: <053.b0abedcc4c99962abfe31dee38478925@macosforge.org> References: <053.b0abedcc4c99962abfe31dee38478925@macosforge.org> Message-ID: <062.83088d0d6da7c0eb88a85d3f7b869f55@macosforge.org> #1380: YAML problems in recent nightly builds ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- Comment(by watson1978@?): It seems there is whitespace immediately after 'description:' and the output is changed. {{{ require 'yaml' puts "description: \nHotCocoa is ...".to_yaml puts "description:\nHotCocoa is ...".to_yaml }}} {{{ $ ruby19 test_yaml.rb --- |- description: HotCocoa is ... --- |- description: HotCocoa is ... $ macruby test_yaml.rb --- "description: \nHotCocoa is ..." --- |- description: HotCocoa is ... }}} -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Mon Aug 22 17:59:46 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 23 Aug 2011 00:59:46 -0000 Subject: [MacRuby] #1381: Calling objective-c method with semicolon before 1st arg sometimes works Message-ID: <049.c56da4e9cc46e713e2d1acc3964ef136@macosforge.org> #1381: Calling objective-c method with semicolon before 1st arg sometimes works --------------------------------+------------------------------------------- Reporter: sohocoke@? | Owner: lsansonetti@? Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- [ilo-robbie at nibbler:~]$ macirb -f # demonstrate flexible syntax irb(main):002:0> s1 = NSString.stringWithString("hi") => "hi" irb(main):003:0> s2 = NSString.stringWithString:"hi" => "hi" # some other weirdness observed during equality tests using objective-c methods - didn't have time to look into this, could be related irb(main):004:0> s1.isEqual:s2 => 0 irb(main):005:0> s1.isEqualToString:s2 => 0 irb(main):006:0> s1 == s2 => true irb(main):007:0> s1.isEqual(s2) => 1 # demonstrate normal operation irb(main):009:0> p1 = "/tmp/macruby-file" => "/tmp/macruby-file" irb(main):010:0> `ls #{p1}` ls: /tmp/macruby-file: No such file or directory => "" irb(main):018:0> framework 'cocoa' => true irb(main):019:0> s1.writeToFile(p1, atomically:true, encoding:NSUTF8StringEncoding, error:nil) => true irb(main):020:0> `ls #{p1}` => "/tmp/macruby-file\n" irb(main):021:0> `rm #{p1}; ls #{p1}` ls: /tmp/macruby-file: No such file or directory => "" # demonstrate weird operation when using flexible syntax irb(main):022:0> s1.writeToFile:p1, atomically:true, encoding:NSUTF8StringEncoding, error:nil => true irb(main):023:0> `ls #{p1}` ls: /tmp/macruby-file: No such file or directory => "" # i'm going to guess that the symbol :p1 got passed to the call. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Mon Aug 22 18:00:34 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 23 Aug 2011 01:00:34 -0000 Subject: [MacRuby] #1381: Calling objective-c method with semicolon before 1st arg sometimes works In-Reply-To: <049.c56da4e9cc46e713e2d1acc3964ef136@macosforge.org> References: <049.c56da4e9cc46e713e2d1acc3964ef136@macosforge.org> Message-ID: <058.85ec317e48a92268310c1bd96b3b5ac3@macosforge.org> #1381: Calling objective-c method with semicolon before 1st arg sometimes works --------------------------------+------------------------------------------- Reporter: sohocoke@? | Owner: lsansonetti@? Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- Comment(by sohocoke@?): Sorry for the formatting. Here it is again: {{{ [ilo-robbie at nibbler:~]$ macirb -f # demonstrate flexible syntax irb(main):002:0> s1 = NSString.stringWithString("hi") => "hi" irb(main):003:0> s2 = NSString.stringWithString:"hi" => "hi" # some other weirdness observed during equality tests using objective-c methods - didn't have time to look into this, could be related irb(main):004:0> s1.isEqual:s2 => 0 irb(main):005:0> s1.isEqualToString:s2 => 0 irb(main):006:0> s1 == s2 => true irb(main):007:0> s1.isEqual(s2) => 1 # demonstrate normal operation irb(main):009:0> p1 = "/tmp/macruby-file" => "/tmp/macruby-file" irb(main):010:0> `ls #{p1}` ls: /tmp/macruby-file: No such file or directory => "" irb(main):018:0> framework 'cocoa' => true irb(main):019:0> s1.writeToFile(p1, atomically:true, encoding:NSUTF8StringEncoding, error:nil) => true irb(main):020:0> `ls #{p1}` => "/tmp/macruby-file\n" irb(main):021:0> `rm #{p1}; ls #{p1}` ls: /tmp/macruby-file: No such file or directory => "" # demonstrate weird operation when using flexible syntax irb(main):022:0> s1.writeToFile:p1, atomically:true, encoding:NSUTF8StringEncoding, error:nil => true irb(main):023:0> `ls #{p1}` ls: /tmp/macruby-file: No such file or directory => "" # i'm going to guess that the symbol :p1 got passed to the call. }}} -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 24 06:04:14 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 24 Aug 2011 13:04:14 -0000 Subject: [MacRuby] #1382: GCC 4.2 not installed with Xcode 4.2 Message-ID: <053.3cf58af3b2ae166092f62cb4b34ea976@macosforge.org> #1382: GCC 4.2 not installed with Xcode 4.2 ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- The new Xcode no longer ships with gcc-4.2. It leaves an old binary around if you installed 4.1 or an earlier 4.2 beta, but as of beta 6 it is no longer present. New machines that install Xcode will not be able to compile C extensions since mkmf gets the compiler path from RbConfig. A symlink to llvm-gcc seems to work for now. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Sat Aug 27 21:12:15 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Sun, 28 Aug 2011 04:12:15 -0000 Subject: [MacRuby] #1306: PUT request corrupts binary data (net/http) In-Reply-To: <053.6b4687efe073cdda9e599601686863a3@macosforge.org> References: <053.6b4687efe073cdda9e599601686863a3@macosforge.org> Message-ID: <062.9970d1469652e513a5b39813fce02dd4@macosforge.org> #1306: PUT request corrupts binary data (net/http) ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- Comment(by mrada@?): I think this is a duplicate of #1156 -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Mon Aug 29 14:06:43 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Mon, 29 Aug 2011 21:06:43 +0000 Subject: [MacRuby] #1222: tracer.rb isn't working In-Reply-To: <054.f0210f964e7ffb8b24dfac62b8c3fa07@macosforge.org> References: <054.f0210f964e7ffb8b24dfac62b8c3fa07@macosforge.org> Message-ID: <063.fa532518e4ca9a2e528c9ac46f71c4d4@macosforge.org> #1222: tracer.rb isn't working -------------------------------------+-------------------------------------- Reporter: mattaimonetti@? | Owner: lsansonetti@? Type: defect | Status: new Priority: trivial | Milestone: MacRuby Later Component: MacRuby | Keywords: -------------------------------------+-------------------------------------- Comment(by lastobelus@?): How big/hard a task do you guys think this would be for someone new to the macruby source code (and llvm)? There's a tool I'd really like to build that would require it. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Mon Aug 29 19:26:07 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 30 Aug 2011 02:26:07 +0000 Subject: [MacRuby] #1380: YAML problems in recent nightly builds In-Reply-To: <053.b0abedcc4c99962abfe31dee38478925@macosforge.org> References: <053.b0abedcc4c99962abfe31dee38478925@macosforge.org> Message-ID: <062.75abe2c01dd7539ca86ea26eb9159da6@macosforge.org> #1380: YAML problems in recent nightly builds ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: closed Priority: blocker | Milestone: Component: MacRuby | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by watson1978@?): * status: new => closed * resolution: => fixed Comment: To the same behavior as CRuby, it looks like needs many modified. [[BR]] so, I reverted my changing. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 07:57:30 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 30 Aug 2011 14:57:30 +0000 Subject: [MacRuby] #1380: YAML problems in recent nightly builds In-Reply-To: <053.b0abedcc4c99962abfe31dee38478925@macosforge.org> References: <053.b0abedcc4c99962abfe31dee38478925@macosforge.org> Message-ID: <062.56f0aac6bedc05257952817de5e2c320@macosforge.org> #1380: YAML problems in recent nightly builds ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: closed Priority: blocker | Milestone: Component: MacRuby | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Comment(by mrada@?): Thank you, Watson! -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 10:10:16 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 30 Aug 2011 17:10:16 +0000 Subject: [MacRuby] #1375: GC doesn't like Hello World In-Reply-To: <042.d0c758a2f370ffaf49835e3bbfce98fc@macosforge.org> References: <042.d0c758a2f370ffaf49835e3bbfce98fc@macosforge.org> Message-ID: <051.e6065c97ebd0c24c1492064f050d2810@macosforge.org> #1375: GC doesn't like Hello World -------------------------+-------------------------------------------------- Reporter: emil@? | Owner: lsansonetti@? Type: defect | Status: closed Priority: major | Milestone: Component: MacRuby | Resolution: wontfix Keywords: gc | -------------------------+-------------------------------------------------- Changes (by lsansonetti@?): * status: new => closed * resolution: => wontfix * milestone: MacRuby 0.11 => Comment: Good catch Watson, it looks like a bug in one of Mac OS X's frameworks, not in MacRuby itself. Closing the ticket as wontfix, the bug reporter should file an Apple bug: http://bugreporter.apple.com -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 10:12:33 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 30 Aug 2011 17:12:33 +0000 Subject: [MacRuby] #1376: C API should include RREGEXP In-Reply-To: <045.42ac169b52e10a0b255c7a3694725a9f@macosforge.org> References: <045.42ac169b52e10a0b255c7a3694725a9f@macosforge.org> Message-ID: <054.065659b212b779ed999dd7cc36011846@macosforge.org> #1376: C API should include RREGEXP ----------------------------+----------------------------------------------- Reporter: kyle@? | Owner: lsansonetti@? Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: ----------------------------+----------------------------------------------- Comment(by lsansonetti@?): That is possible to add, but some fields of that structure (such as `struct re_pattern_buffer *ptr') will not be accessible, as we use a different store to implement regexps. Could you provide the name of a C extension that makes use of these macros? This way we can verify that the change works as expected by testing it. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 10:14:10 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 30 Aug 2011 17:14:10 +0000 Subject: [MacRuby] #1374: GC problems when using AVFoundation In-Reply-To: <053.e99964fd97511d98099906cc03b7a098@macosforge.org> References: <053.e99964fd97511d98099906cc03b7a098@macosforge.org> Message-ID: <062.de11921e2754ea80f65ab6abdb92c7f4@macosforge.org> #1374: GC problems when using AVFoundation ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- Comment(by lsansonetti@?): Could it be a dup of #1375? -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 10:16:03 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 30 Aug 2011 17:16:03 +0000 Subject: [MacRuby] #1364: NameError: uninitialized class variable in NSObject In-Reply-To: <060.4b320934a4b3bcec8141fd746b2ef702@macosforge.org> References: <060.4b320934a4b3bcec8141fd746b2ef702@macosforge.org> Message-ID: <069.86e1a0d08972fea970734d9da763de32@macosforge.org> #1364: NameError: uninitialized class variable in NSObject -------------------------------------------+-------------------------------- Reporter: satoh@? | Owner: lsansonetti@? Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: class variables, @@ -------------------------------------------+-------------------------------- Changes (by lsansonetti@?): * milestone: MacRuby 0.11 => Old description: > satoh-MBP:trunk satounorio$ rvm use macruby > Using /Users/satounorio/.rvm/gems/macruby-0.10 > satoh-MBP:trunk satounorio$ irb > irb(main):001:0> module M > irb(main):002:1> @@hello = "hello" > irb(main):003:0> end > => "hello" > irb(main):004:0> include M > => NSObject > irb(main):005:0> @@hello > NameError: uninitialized class variable @@hello in NSObject > > irb(main):006:0> M.class_variables_get(:@@hello) > NoMethodError: undefined method `class_variables_get' for M:Class > > irb(main):007:0> M.class_variable_get(:@@hello) > => "hello" > irb(main):008:0> New description: {{{ satoh-MBP:trunk satounorio$ rvm use macruby Using /Users/satounorio/.rvm/gems/macruby-0.10 satoh-MBP:trunk satounorio$ irb irb(main):001:0> module M irb(main):002:1> @@hello = "hello" irb(main):003:0> end => "hello" irb(main):004:0> include M => NSObject irb(main):005:0> @@hello NameError: uninitialized class variable @@hello in NSObject irb(main):006:0> M.class_variables_get(:@@hello) NoMethodError: undefined method `class_variables_get' for M:Class irb(main):007:0> M.class_variable_get(:@@hello) => "hello" irb(main):008:0> }}} -- -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 10:17:25 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 30 Aug 2011 17:17:25 +0000 Subject: [MacRuby] #1364: NameError: uninitialized class variable in NSObject In-Reply-To: <060.4b320934a4b3bcec8141fd746b2ef702@macosforge.org> References: <060.4b320934a4b3bcec8141fd746b2ef702@macosforge.org> Message-ID: <069.8990ef1bcca0e1e76a5125455d76d419@macosforge.org> #1364: NameError: uninitialized class variable in NSObject -------------------------------------------+-------------------------------- Reporter: satoh@? | Owner: lsansonetti@? Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: class variables, @@ -------------------------------------------+-------------------------------- Comment(by lsansonetti@?): Indeed: {{{ $ ./miniruby -e "module M; @@hello=42; end; include M; p @@hello" -e:1:in `
': uninitialized class variable @@hello in NSObject (NameError) }}} -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 10:40:14 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 30 Aug 2011 17:40:14 +0000 Subject: [MacRuby] #1374: GC problems when using AVFoundation In-Reply-To: <053.e99964fd97511d98099906cc03b7a098@macosforge.org> References: <053.e99964fd97511d98099906cc03b7a098@macosforge.org> Message-ID: <062.25769a56260f67ff7055e426f89be809@macosforge.org> #1374: GC problems when using AVFoundation ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- Comment(by mrada@?): I'll try it out in Objective-C, probably today since I need to clean up that project. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 10:48:40 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 30 Aug 2011 17:48:40 +0000 Subject: [MacRuby] #1364: NameError: uninitialized class variable in NSObject In-Reply-To: <060.4b320934a4b3bcec8141fd746b2ef702@macosforge.org> References: <060.4b320934a4b3bcec8141fd746b2ef702@macosforge.org> Message-ID: <069.9247183d3acb40488f70ae50588002e3@macosforge.org> #1364: NameError: uninitialized class variable in NSObject -------------------------------------------+-------------------------------- Reporter: satoh@? | Owner: lsansonetti@? Type: defect | Status: closed Priority: major | Milestone: MacRuby 0.11 Component: MacRuby | Resolution: fixed Keywords: class variables, @@ | -------------------------------------------+-------------------------------- Changes (by lsansonetti@?): * status: new => closed * resolution: => fixed * milestone: => MacRuby 0.11 Comment: Should be fixed in https://github.com/MacRuby/MacRuby/commit/ee78786256b1b96f559dad53ef87759093d6e2af -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 10:50:52 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 30 Aug 2011 17:50:52 +0000 Subject: [MacRuby] #1363: macirb "framework 'AppKit' results in segfault In-Reply-To: <050.7efe924d149dc9e85e79fb3f2a462b51@macosforge.org> References: <050.7efe924d149dc9e85e79fb3f2a462b51@macosforge.org> Message-ID: <059.ae816655c9213ce14b0cbc32e0c21d69@macosforge.org> #1363: macirb "framework 'AppKit' results in segfault ---------------------------------+------------------------------------------ Reporter: will@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ---------------------------------+------------------------------------------ Comment(by lsansonetti@?): I presume the problem is when re-defining #copy. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 10:51:42 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 30 Aug 2011 17:51:42 +0000 Subject: [MacRuby] #1378: RE2 gem will not compile In-Reply-To: <047.7503ffa00c07091428afa2c1e3aadb5c@macosforge.org> References: <047.7503ffa00c07091428afa2c1e3aadb5c@macosforge.org> Message-ID: <056.b57413efd64b6250b25dc2ac661bea4f@macosforge.org> #1378: RE2 gem will not compile ------------------------------+--------------------------------------------- Reporter: xperts@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------+--------------------------------------------- Description changed by lsansonetti@?: Old description: > I had thought that C based gems didn't work at all with MacRuby 1.0. But > Matt suggested I make a ticket on this issue. I'm having an issue where > I need named expression groups to work with my regexps, this doesn't work > within MacRuby so I've tried to install RE2, but that doesn't work > either: > > sudo macgem install re2 > Password: > Building native extensions. This could take a while... > ERROR: Error installing re2: > ERROR: Failed to build gem native extension. > > /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/bin/macruby > extconf.rb > checking for main() in -lstdc++... yes > checking for main() in -lre2... yes > creating Makefile > > make > /usr/bin/g++ -I. > -I/Library/Frameworks/MacRuby.framework/Versions/0.10/usr/include/ruby-1.9.2 > /universal-darwin10.0 > -I/Library/Frameworks/MacRuby.framework/Versions/0.10/usr/include/ruby-1.9.2/ruby/backward > -I/Library/Frameworks/MacRuby.framework/Versions/0.10/usr/include/ruby-1.9.2 > -I. -I/usr/local/include -fno-common -arch x86_64 -fexceptions -fno- > common -pipe -O3 -g -Wall -Wall -Wextra -funroll-loops -arch x86_64 -arch > x86_64 -o re2.o -c re2.cc > re2.cc: In function ?void re2_matchdata_mark(re2_matchdata*)?: > re2.cc:45: error: ?rb_gc_mark? was not declared in this scope > re2.cc: In function ?VALUE re2_Replace(VALUE, VALUE, VALUE, VALUE)?: > re2.cc:933: error: invalid conversion from ?const void*? to ?void*? > re2.cc:933: error: initializing argument 1 of ?void* memcpy(void*, > const void*, size_t)? > re2.cc: In function ?VALUE re2_GlobalReplace(VALUE, VALUE, VALUE, > VALUE)?: > re2.cc:983: error: invalid conversion from ?const void*? to ?void*? > re2.cc:983: error: initializing argument 1 of ?void* memcpy(void*, > const void*, size_t)? > make: *** [re2.o] Error 1 New description: I had thought that C based gems didn't work at all with MacRuby 1.0. But Matt suggested I make a ticket on this issue. I'm having an issue where I need named expression groups to work with my regexps, this doesn't work within MacRuby so I've tried to install RE2, but that doesn't work either: {{{ sudo macgem install re2 Password: Building native extensions. This could take a while... ERROR: Error installing re2: ERROR: Failed to build gem native extension. /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/bin/macruby extconf.rb checking for main() in -lstdc++... yes checking for main() in -lre2... yes creating Makefile make /usr/bin/g++ -I. -I/Library/Frameworks/MacRuby.framework/Versions/0.10/usr/include/ruby-1.9.2 /universal-darwin10.0 -I/Library/Frameworks/MacRuby.framework/Versions/0.10/usr/include/ruby-1.9.2/ruby/backward -I/Library/Frameworks/MacRuby.framework/Versions/0.10/usr/include/ruby-1.9.2 -I. -I/usr/local/include -fno-common -arch x86_64 -fexceptions -fno- common -pipe -O3 -g -Wall -Wall -Wextra -funroll-loops -arch x86_64 -arch x86_64 -o re2.o -c re2.cc re2.cc: In function ?void re2_matchdata_mark(re2_matchdata*)?: re2.cc:45: error: ?rb_gc_mark? was not declared in this scope re2.cc: In function ?VALUE re2_Replace(VALUE, VALUE, VALUE, VALUE)?: re2.cc:933: error: invalid conversion from ?const void*? to ?void*? re2.cc:933: error: initializing argument 1 of ?void* memcpy(void*, const void*, size_t)? re2.cc: In function ?VALUE re2_GlobalReplace(VALUE, VALUE, VALUE, VALUE)?: re2.cc:983: error: invalid conversion from ?const void*? to ?void*? re2.cc:983: error: initializing argument 1 of ?void* memcpy(void*, const void*, size_t)? make: *** [re2.o] Error 1 }}} -- -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 10:54:13 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 30 Aug 2011 17:54:13 +0000 Subject: [MacRuby] #1374: GC problems when using AVFoundation In-Reply-To: <053.e99964fd97511d98099906cc03b7a098@macosforge.org> References: <053.e99964fd97511d98099906cc03b7a098@macosforge.org> Message-ID: <062.f42881972d36ccf8a8676a00e0402963@macosforge.org> #1374: GC problems when using AVFoundation ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- Comment(by lsansonetti@?): As AVFoundation is a new Lion framework it's possible GC support isn't completely done, so trying in pure Objective-C may be a good idea. I don't have a Lion machine nearby, but if the Objective-C version works, could you run the MacRuby snippet under gdb, break on CFCollection_non_gc_storage_error, then copy/paste the full backtrace? -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 12:54:49 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 30 Aug 2011 19:54:49 +0000 Subject: [MacRuby] #1375: GC doesn't like Hello World In-Reply-To: <042.d0c758a2f370ffaf49835e3bbfce98fc@macosforge.org> References: <042.d0c758a2f370ffaf49835e3bbfce98fc@macosforge.org> Message-ID: <051.41ee3420e3e5db7c2a74afc5e02a1c80@macosforge.org> #1375: GC doesn't like Hello World -------------------------+-------------------------------------------------- Reporter: emil@? | Owner: lsansonetti@? Type: defect | Status: closed Priority: major | Milestone: Component: MacRuby | Resolution: wontfix Keywords: gc | -------------------------+-------------------------------------------------- Comment(by emil@?): bug reported to apple on http://bugreporter.apple.com -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 16:46:22 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Tue, 30 Aug 2011 23:46:22 +0000 Subject: [MacRuby] #1383: Need to implement ENCODING_GET_INLINED Message-ID: <051.6f4157972333be9f0ef70a8d5beaa1d3@macosforge.org> #1383: Need to implement ENCODING_GET_INLINED ----------------------------------+----------------------------------------- Reporter: watson1978@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- {{{ $ brew install postgresql $ export PGDATA=/usr/local/pgsql/data $ initdb --encoding=UTF8 --no-locale $ pg_ctl -w start $ createdb test $ sudo macgem install pg $ macruby test_pg.rb dyld: lazy symbol binding failed: Symbol not found: _ENCODING_GET_INLINED Referenced from: /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/gems/pg-0.11.0/lib/pg_ext.bundle Expected in: flat namespace dyld: Symbol not found: _ENCODING_GET_INLINED Referenced from: /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/gems/pg-0.11.0/lib/pg_ext.bundle Expected in: flat namespace LOG: unexpected EOF on client connection zsh: trace trap macruby test_pg.rb }}} Test Script: {{{ #!ruby require 'rubygems' require 'pg' conn = PGconn.open(:dbname => 'test') begin conn.exec('drop table sample;') rescue end res = conn.exec('create table sample (name text, age int);') status = res.result_status p res.res_status(status) }}} -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 22:07:37 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 31 Aug 2011 05:07:37 +0000 Subject: [MacRuby] #1374: GC problems when using AVFoundation In-Reply-To: <053.e99964fd97511d98099906cc03b7a098@macosforge.org> References: <053.e99964fd97511d98099906cc03b7a098@macosforge.org> Message-ID: <062.30f4632ccc011f17ef54280d1b9263ad@macosforge.org> #1374: GC problems when using AVFoundation ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- Comment(by mrada@?): No need to worry, I've tried it in objective-c and I have the same problem! I'll log the bug with Apple. Sorry for the false alarm. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Tue Aug 30 23:57:29 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 31 Aug 2011 06:57:29 +0000 Subject: [MacRuby] #1374: GC problems when using AVFoundation In-Reply-To: <053.e99964fd97511d98099906cc03b7a098@macosforge.org> References: <053.e99964fd97511d98099906cc03b7a098@macosforge.org> Message-ID: <062.3d46a469b9b884a30affdd995aeab2cc@macosforge.org> #1374: GC problems when using AVFoundation ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: closed Priority: blocker | Milestone: Component: MacRuby | Resolution: wontfix Keywords: | ------------------------------------+--------------------------------------- Changes (by lsansonetti@?): * status: new => closed * resolution: => wontfix Comment: Excellent, closing as wontfix then :) -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 31 00:01:58 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 31 Aug 2011 07:01:58 +0000 Subject: [MacRuby] #1383: Need to implement ENCODING_GET_INLINED In-Reply-To: <051.6f4157972333be9f0ef70a8d5beaa1d3@macosforge.org> References: <051.6f4157972333be9f0ef70a8d5beaa1d3@macosforge.org> Message-ID: <060.6c3dc02066c18a2e7df8454dbcfbb56c@macosforge.org> #1383: Need to implement ENCODING_GET_INLINED ----------------------------------+----------------------------------------- Reporter: watson1978@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- Comment(by lsansonetti@?): Can you try again with https://github.com/MacRuby/MacRuby/commit/a09abe4201a0a5b7874a6a151d1d409b88bd06f6 ? Looking quickly, I think that defining ENCODING_GET_INLINED as ENCODING_GET should work. Normally users (such as the pg gem) are not supposed to call ENCODING_GET_INLINED directly. -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 31 00:11:12 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 31 Aug 2011 07:11:12 +0000 Subject: [MacRuby] #1383: Need to implement ENCODING_GET_INLINED In-Reply-To: <051.6f4157972333be9f0ef70a8d5beaa1d3@macosforge.org> References: <051.6f4157972333be9f0ef70a8d5beaa1d3@macosforge.org> Message-ID: <060.2f526553b6886437d9c33d056410bcef@macosforge.org> #1383: Need to implement ENCODING_GET_INLINED ----------------------------------+----------------------------------------- Reporter: watson1978@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- Comment(by watson1978@?): I tried with https://github.com/MacRuby/MacRuby/commit/a09abe4201a0a5b7874a6a151d1d409b88bd06f6 [[BR]] But, abort occurs. {{{ $ macruby test_pg.rb Assertion failed: (idx >= 0 && idx < ENCODINGS_COUNT), function rb_enc_associate_index, file encoding.c, line 590. LOG: unexpected EOF on client connection zsh: abort macruby test_pg.rb }}} {{{ rogram received signal SIGABRT, Aborted. 0x00007fff8a167ce2 in __pthread_kill () (gdb) bt #0 0x00007fff8a167ce2 in __pthread_kill () #1 0x00007fff898377d2 in pthread_kill () #2 0x00000001008153e6 in abort () #3 0x0000000100815438 in __assert_rtn () #4 0x00000001000d15dd in rb_enc_associate_index (obj=17184852000, idx=-1) at encoding.c:590 #5 0x0000000104f9f6f8 in pgresult_res_status (self=17184852064, status=) at pg.c:3030 #6 0x000000010136a1fe in ?? () #7 0x000000010012ebc2 in __rb_vm_rcall [inlined] () at /Users/watson/src /macruby-master/dispatcher.cpp:161 #8 0x000000010012ebc2 in ruby_dispatch [inlined] () at /Users/watson/src /macruby-master/dispatcher.cpp:466 #9 0x000000010012ebc2 in rb_vm_dispatch () at dispatcher.cpp:872 #10 0x000000010135e994 in ?? () #11 0x000000010135e228 in ?? () #12 0x000000010014a3b2 in rb_vm_run (fname=0x400496620 "/Users/watson/tmp/test_pg.rb", node=0x4004996e0, binding=0x0, inside_eval=false) at vm.cpp:4125 #13 0x0000000100028098 in ruby_run_node (n=0x4004996e0) at eval.c:211 #14 0x0000000100000be3 in main (argc=2, argv=0x100e167d0, envp=0x7fff5fbfec90) at main.cpp:40 }}} -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 31 01:10:03 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 31 Aug 2011 08:10:03 +0000 Subject: [MacRuby] #1318: Attempting to to_yaml recursive references causes segmentation fault in 0.10 In-Reply-To: <053.3ed85086240a8c9dd863c07292a5035a@macosforge.org> References: <053.3ed85086240a8c9dd863c07292a5035a@macosforge.org> Message-ID: <062.c1ffce8548e896be6d7af9baac539df1@macosforge.org> #1318: Attempting to to_yaml recursive references causes segmentation fault in 0.10 ------------------------------------+--------------------------------------- Reporter: leon.spencer@? | Owner: lsansonetti@? Type: defect | Status: new Priority: critical | Milestone: Component: MacRuby | Keywords: yaml, segfault ------------------------------------+--------------------------------------- Description changed by lsansonetti@?: Old description: > irb(main):001:0> require 'yaml' > => true > irb(main):002:0> a = [] > => [] > irb(main):003:0> a << a > => [[...]] > irb(main):004:0> a.to_yaml > Segmentation fault New description: {{{ irb(main):001:0> require 'yaml' => true irb(main):002:0> a = [] => [] irb(main):003:0> a << a => [[...]] irb(main):004:0> a.to_yaml Segmentation fault }}} -- -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 31 01:15:28 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 31 Aug 2011 08:15:28 +0000 Subject: [MacRuby] #1294: MacRuby crashes when loading files on the non-main thread In-Reply-To: <053.1357a704650881e3d927fbc6a275c293@macosforge.org> References: <053.1357a704650881e3d927fbc6a275c293@macosforge.org> Message-ID: <062.257d125ddead3514dad9926fe98ba1ed@macosforge.org> #1294: MacRuby crashes when loading files on the non-main thread ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: reduction 0.11-blocker ------------------------------------+--------------------------------------- Comment(by lsansonetti@?): Looking again, it seems that RoxorCore::copy_methods() needs to acquire the lock. However it's problematic as it calls class_getInstanceMethod() which may use the dynamic resolver (and create a deadlock). -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 31 01:27:11 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Wed, 31 Aug 2011 08:27:11 +0000 Subject: [MacRuby] #1294: MacRuby crashes when loading files on the non-main thread In-Reply-To: <053.1357a704650881e3d927fbc6a275c293@macosforge.org> References: <053.1357a704650881e3d927fbc6a275c293@macosforge.org> Message-ID: <062.ff3f96d618d4578f415dc25130d5fe6d@macosforge.org> #1294: MacRuby crashes when loading files on the non-main thread ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: reduction 0.11-blocker ------------------------------------+--------------------------------------- Comment(by lsansonetti@?): Following patch seems to fix the problem (for me, MBP quad-core), can someone else give it a try? {{{ diff --git a/vm.cpp b/vm.cpp index a959bf0..8480414 100644 --- a/vm.cpp +++ b/vm.cpp @@ -2464,6 +2464,8 @@ RoxorCore::copy_methods(Class from_class, Class to_class) Method *methods; unsigned int i, methods_count; + lock(); + // Copy existing Objective-C methods. methods = class_copyMethodList(from_class, &methods_count); if (methods != NULL) { @@ -2503,6 +2505,8 @@ RoxorCore::copy_methods(Class from_class, Class to_class) } } + unlock(); + // Force a resolving of these selectors on the target class. This must be // done outside the next loop since the resolver messes up the Core // structures. @@ -2512,6 +2516,8 @@ RoxorCore::copy_methods(Class from_class, Class to_class) class_getInstanceMethod(to_class, *iter); } + lock(); + // Now, let's really copy the lazy methods. std::vector sels_to_add; for (std::vector::iterator iter = sels_to_copy.begin(); @@ -2533,7 +2539,9 @@ RoxorCore::copy_methods(Class from_class, Class to_class) rb_vm_method_source_t *m_src = iter2->second; + unlock(); Method m = class_getInstanceMethod(to_class, sel); + lock(); if (m != NULL) { // The method already exists on the target class, we need to // JIT it. @@ -2568,6 +2576,8 @@ RoxorCore::copy_methods(Class from_class, Class to_class) method_source_sels.insert(std::make_pair(to_class, *i)); } #endif + + unlock(); } extern "C" }}} -- Ticket URL: MacRuby From ruby-noreply at macosforge.org Wed Aug 31 18:40:49 2011 From: ruby-noreply at macosforge.org (MacRuby) Date: Thu, 01 Sep 2011 01:40:49 +0000 Subject: [MacRuby] #1294: MacRuby crashes when loading files on the non-main thread In-Reply-To: <053.1357a704650881e3d927fbc6a275c293@macosforge.org> References: <053.1357a704650881e3d927fbc6a275c293@macosforge.org> Message-ID: <062.5d1dbc98e49f1d3f8572adfb67aa0719@macosforge.org> #1294: MacRuby crashes when loading files on the non-main thread ------------------------------------+--------------------------------------- Reporter: mrada@? | Owner: lsansonetti@? Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: reduction 0.11-blocker ------------------------------------+--------------------------------------- Comment(by watson1978@?): I tried your patch. [[BR]] Unfortunately, it seems to occur crashes yet. {{{ $ i=0; while true; do DYLD_LIBRARY_PATH=. ./macruby -I./lib ~/tmp/ticket/1294-test_require.rb; i=`expr $i + 1`; echo $i; done }}} When the invoked over 100 times, it seems to have crashed several times. {{{ Process: macruby [4681] Path: /Users/USER/*/macruby Identifier: macruby Version: ??? (???) Code Type: X86-64 (Native) Parent Process: zsh [2110] Date/Time: 2011-09-01 10:35:41.390 +0900 OS Version: Mac OS X 10.7.1 (11B26) Report Version: 9 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000010 VM Regions Near 0x10: --> __TEXT 0000000100569000-000000010056a000 [ 4K] r-x/rwx SM=COW /Users/USER/* Application Specific Information: objc[4681]: garbage collection is ON Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libstdc++.6.dylib 0x00007fff94d70a3f std::_Rb_tree_rotate_left(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*&) + 8 1 libstdc++.6.dylib 0x00007fff94d70bed std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) + 284 2 libmacruby.1.9.2.dylib 0x00000001006cc9da std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::pair const&) + 106 (stl_tree.h:844) 3 libmacruby.1.9.2.dylib 0x00000001006ce7dd std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique(std::_Rb_tree_iterator >, std::pair const&) + 397 (stl_tree.h:1008) 4 libmacruby.1.9.2.dylib 0x00000001006b7394 RoxorCore::constant_cache_get(unsigned long) + 260 (vm.cpp:788) 5 fileutils.rbo 0x00000001025661b0 0x102549000 + 119216 6 fileutils.rbo 0x000000010254abac MREP_211FE1EE56634397A16501F3704E7C18 + 12 7 libmacruby.1.9.2.dylib 0x00000001006c9160 rb_vm_dln_load + 128 (vm.h:1130) 8 libmacruby.1.9.2.dylib 0x0000000100653f34 dln_load + 493 (dln.c:132) 9 libmacruby.1.9.2.dylib 0x00000001005a1901 rb_require_safe + 253 (load.c:298) 10 libmacruby.1.9.2.dylib 0x00000001005a12d7 rb_f_require + 32 (load.c:145) 11 libmacruby.1.9.2.dylib 0x00000001005a12fa rb_f_require_imp + 33 (load.c:151) 12 libmacruby.1.9.2.dylib 0x00000001006ab78a rb_vm_dispatch + 5773 (dispatcher.cpp:161) 13 ??? 0x00000001023ee634 0 + 4332643892 14 ??? 0x00000001023ee162 0 + 4332642658 15 libmacruby.1.9.2.dylib 0x00000001006ca996 rb_vm_run + 470 (vm.cpp:4135) 16 libmacruby.1.9.2.dylib 0x0000000100598998 ruby_run_node + 93 (eval.c:212) 17 macruby 0x0000000100569be3 main + 173 (main.cpp:40) 18 macruby 0x00000001005699ec start + 52 }}} -- Ticket URL: MacRuby