March 2011 - MacRuby-devel - lists.macosforge.org

Help test a new MacRuby app
by Andre Lewis 15 Mar '11

15 Mar '11

Redwood is a "Spotlight for your web apps" -- it searches Basecamp, GMail, and GDocs from one search bar on your desktop. Developing in MacRuby has been a joy, and I'd like to make Redwood a showcase for desktop MacRuby. You can help by installing Redwood and let me know if you have any issues. We're using embedded, compiled gems, so I'd like to see it running successfully on a variety of Macs. Download: http://redwoodapp.com/system/Redwood.zip (note: OSX 10.6+ required) A little technical background: - MacRuby 0.9, embedded in the application bundle - Two gems: Nokogiri and GData, also embedded in the application bundle. We use macruby_deploy --gem, which makes gem bundling a breeze. - A few Obj-C libraries: Sqlite3 and FMDB for database, ASIHTTPRequest for HTTP, Sparkle for auto-update. The app started out in Obj-C. We moved to MacRuby, but some parts remain in Obj-C. As we go, anything that needs refactoring moves to Ruby. - all the usual Cocoa APIs, mostly used from Ruby. - the main UI is rendered primarily in HTML/CSS, and events are passed back and forth between an embedded Webview and Cocoa Please give it a whirl and let me know how it goes. Download link again: http://redwoodapp.com/system/Redwood.zip Thanks, Andre

5 5

Xcode 4
by Robert Rice 14 Mar '11

14 Mar '11

Hi: Is MacRuby fully compatible with Xcode 4 or should I wait a while before upgrading? Thanks, Bob Rice

2 1

TIL - Uncaught exceptions in threads cause SIGABRT in the main thread!
by Morgan Schweers 14 Mar '11

14 Mar '11

Greetings, Today I Learned :) if a thread throws an exception that isn't rescued by the top of the thread, it'll crash the app's main thread with 'Program received signal: “SIGABRT”.' That's been plaguing me since I started doing MacRuby development; every time I tried to start up multiple threads, the app became incredibly fragile and, unlike the main thread, it wouldn't show ruby traces. Now I just wrap threads in begin/rescue blocks, and I'm all good. Good programming practice anyway, but the failure mode is unobvious if you don't. Hopefully this helps someone else! -- Morgan

3 4

[ANN] MacBacon 1.3
by Eloy Duran 12 Mar '11

12 Mar '11

Hi, I’ve just released MacBacon 1.3. This release adds more NSRunLoop helpers: * you can now make the context a delegate and have spec execution pause until a delegate method has been called * pause spec execution until a KVO observable property of an object changes I forgot to email the list when I released 1.2, so here's that info: * load NIBs for window controllers easily * exit with a non-zero status if there were failures/errors, which makes it play nice with Xcode test bundles See the README (specifically the Objective-C section) for more info. Please give it try and let me know of anything that comes to mind :) Cheers, Eloy * https://github.com/alloy/MacBacon * http://rubygems.org/gems/mac_bacon

1 0

trunk depends on a new LLVM
by Laurent Sansonetti 11 Mar '11

11 Mar '11

For those compiling from the repository: MacRuby now requires LLVM 2.9. I tested revision 127367 to be okay, so I recommend this one. The README.rdoc file has been updated with newer instructions. Also, as trunk no longer builds for i386 by default, LLVM doesn't need to be built for it anymore, which results in a much faster build. For those using the nightly builds, we will make sure it gets updated. Laurent

1 0

Re: [MacRuby-devel] MacRuby build issues with LLVM
by Richard Sepulveda 11 Mar '11

11 Mar '11

My customers with new MacBook Pro's have confirmed that the new version of my QuickAlarm app with the new MacRuby 0.1/LLVM works! Good job everybody! > Yes, it was a problem in LLVM, which wasn't generating code for the proper architecture. I hope this was an exception and that we won't need to target new LLVM versions each time new architectures are introduced :) > > Thanks for verifying the fixes. I will release trunk as 0.10 tomorrow evening. > > Laurent > > On Mar 10, 2011, at 3:00 AM, Nick Ludlam wrote: > >> I can also confirm this now builds correctly. Thanks very much for the speedy turnaround, Laurent. >> >> Out of interest, do you know why the Core i7 chip in this laptop behaves differently to the Core 2 Duo in my previous laptop? Is it perhaps just that LLVM is failing to detect the CPU correctly, and is creating code based on incorrect assumptions? >> >> On 10 Mar 2011, at 02:27, Laurent Sansonetti wrote: >> >>> I got confirmation that trunk as of r5271 should work. Because of the severity of this problem, and the recent changes in macruby_deploy regarding App Store submissions, I think we should release 0.10 as soon as possible now. I will work on it. >>> >>> Laurent >>> >>> On Mar 9, 2011, at 4:09 PM, Laurent Sansonetti wrote: >>> >>>> Okay, I committed support for LLVM 2.9 as of r5269 and verified that no regression is introduced (the spec suite runs fine). >>>> >>>> Please update your repository, do a rake clean, then build with the CFLAGS="-D__SUPPORT_LLVM_29__" option. Example: $ rake CFLAGS="-D__SUPPORT_LLVM_29__" jobs=8 >>>> >>>> If this fixes the problem, we might need to roll out a MacRuby release with this new LLVM soon, as I suspect the problem will hit many people. >>>> >>>> Laurent >>>> >>>> On Mar 9, 2011, at 2:10 PM, Laurent Sansonetti wrote: >>>> >>>>> Okay, API breakage, but I can reproduce that on my machine :) I will hack on it later today and post a message here once it's supposed to compile, this way you can continue testing. >>>>> >>>>> Laurent >>>>> >>>>> On Mar 9, 2011, at 2:03 PM, Nick Ludlam wrote: >>>>> >>>>>> Ok, well it's not failing in the same way, but it's still failing: >>>>>> >>>>>> /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 -I./icu-1060 -c ucnv.c -o .objs/ucnv.o >>>>>> /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 -I./icu-1060 -c encoding.c -o .objs/encoding.o >>>>>> /usr/bin/g++-4.2 -I. -I./include -fblocks -g -Wall -Wno-deprecated-declarations -Werror -arch x86_64 -I/opt/llvm-macruby/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fno-rtti -fno-common -Woverloaded-virtual -I./icu-1060 -c main.cpp -o .objs/main.o >>>>>> In file included from vm.h:593, >>>>>> from main.cpp:17: >>>>>> compiler.h:82: error: ISO C++ forbids declaration of ?DIFactory? with no type >>>>>> compiler.h:82: error: expected ?;? before ?*? token >>>>>> rake aborted! >>>>>> Command failed with status (1): [/usr/bin/g++-4.2 -I. -I./include -fblocks ...] >>>>>> >>>>>> (See full trace by running task with --trace) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 9 Mar 2011, at 21:34, Laurent Sansonetti wrote: >>>>>> >>>>>>> It looks like it might take a while until I get my hands on a new MBP, so could one try the following? >>>>>>> >>>>>>> 1) Grab a copy of https://llvm.org/svn/llvm-project/llvm/branches/release_29 using svn, then build it using the same instructions in README.rdoc. I am just hoping that this new version of LLVM supports the new hardware and that it doesn't introduce API breakage. >>>>>>> 2) Re-build and install MacRuby trunk after doing a rake clean. >>>>>>> >>>>>>> Laurent >>>>>>> >>>>>>> On Mar 9, 2011, at 1:08 PM, Laurent Sansonetti wrote: >>>>>>> >>>>>>>> Sorry the late reply. It's probably because this version of LLVM that we use cannot target the new CPU yet. I will investigate :) >>>>>>>> >>>>>>>> Laurent >>>>>>>> >>>>>>>> On Mar 9, 2011, at 12:10 PM, Nick Ludlam wrote: >>>>>>>> >>>>>>>>> Yes, this looks like it's exactly the problem I'm having, from the look of the log, so perhaps it's a Sandy Bridge / Core i5/7 issue. Curious! >>>>>>>>> >>>>>>>>> On 9 Mar 2011, at 19:56, Richard Sepulveda wrote: >>>>>>>>> >>>>>>>>>> I have a customer that is also having this same problem with my MacRuby Mac App Store application running on his new MacBook Pro. I don't have >>>>>>>>>> access to this type of Mac so I haven't been able to reproduce this problem. >>>>>>>>>> >>>>>>>>>> He has tried MacRuby 0.8 and 0.9 versions of my app with the same results. >>>>>>>>>> >>>>>>>>>> I can provide copies of my app to developers that would like to try to reproduce the problem. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Richard

1 0

re-implemention of attr_accessor and valueForKey:
by kyossi 11 Mar '11

11 Mar '11

Hi, I'm plan to add some functionality to existing attr_accessor. I've started with re-implement attr_accessor with same functionality, but when I implement it by define_method, it failed with Segmentation fault when I call valueForKey(:key). Am i doing wrong with class Base2??, The Code is #utility class String #upcase first char. "foo".upcaseFirstChar => "Foo" def upcaseFirstChar self[0].upcase + self[-self.size+1, self.size-1] end end #implement of my_attr_accessor with evaluate string. works fine class Base def self.my_attr_accessor(sym) class_eval %{ def #{sym} @#{sym} end def set#{sym.to_s.upcaseFirstChar}(val) @#{sym} = val end } end end class MyClass < Base my_attr_accessor :foo end obj = MyClass.new obj.setFoo(3) p obj.foo #=>3 p obj.valueForKey(:foo) #=>3 #another implement of my_attr_accessor class Base2 def self.my_attr_accessor(sym) define_method(sym) do instance_variable_get("@#{sym}") end define_method("set#{sym.to_s.upcaseFirstChar}") do |val| instance_variable_set("@#{sym}", val) end end end class MyClass2 < Base2 my_attr_accessor :foo end obj2 = MyClass2.new obj2.setFoo(7) p obj2.foo #=>7 p obj2.valueForKey(:foo) #=> Segmentation fault ===================== $ macruby my_attr_accessor.rb 3 3 7 Segmentation fault

2 2

Potential macirb issue
by Mark Rada 11 Mar '11

11 Mar '11

Hey all, I am getting an error when I add a #to_s method to NSURL: ± irb irb(main):001:0> class NSURL irb(main):002:1> alias_method :to_s, :absoluteString irb(main):003:0> end => NSURL irb(main):004:0> NSURL.URLWithString( 'macruby.org' ) RuntimeError: can't modify frozen/immutable string irb(main):005:0> test = NSURL.URLWithString( 'macruby.org' ) RuntimeError: can't modify frozen/immutable string irb(main):006:0> test.to_s => "macruby.org" irb(main):007:0> So the error seems to be macirb trying to do something to the string that is returned from #to_s. I'm not sure if this is unique to MacRuby, as the CRuby documentation for Object#to_s doesn't say whether the returned object should be frozen, but should I be making #to_s return a mutable/unfrozen string? Mark Rada mrada(a)marketcircle.com

2 1

Re: [MacRuby-devel] Note of warning about Xcode 4
by Sven Schwyn 11 Mar '11

11 Mar '11

Hi I'm on OS X 10.6.6 with MacRuby 0.9 installed via RVM on a older i386 MacBookPro2,2. Check out this screenshot: http://www.delirium.ch/test/connections.png Due to the lack of templates, I've created the project in Xcode 3 and then worked with it in Xcode 4 - which worked just fine in the last beta, the GM and now the final. And it works as well for newly created XIBs, not just for the generated MainMenu.xib. Cheers, -sven

1 0

Re: [MacRuby-devel] Note of warning about Xcode 4
by Sven Schwyn 11 Mar '11

11 Mar '11

Hi Laurent > What Vincent is referring to is the Xcode 3 feature where IB would automatically reveal the outlets and actions written in Ruby. This is not working in Xcode 4, and may be the reason why you want to stick to Xcode 3. Well, it works for me. At least if by "reveal the outlets and actions" you mean the following: Create application_controller.rb: class AppliationController attr_accessor foobar def do_this(sender) puts @foobar end end Edit MainMenu.XIB: - Add an NSObject and set it to class ApplicationController - Select the connection inspector for it - The outlet "foobar" and the action "do_this" show up an can be linked to elements Cheers -sven

4 3