[MacRuby-devel] [ANN] MacBacon 1.3
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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Help test a new MacRuby app
The app crashes on startup on my macbook: core 2 duo, osx 10.6.6 12-03-11 18:18:02 Redwood[22169] starting Redwood 12-03-11 18:18:04 [0x0-0x475475].com.highgroove.redwood[22169] dlopen(/System/Library/Frameworks/CoreFoundation.framework/Resources/BridgeSupport/CoreFoundation.dylib, 1): no suitable image found. Did find: 12-03-11 18:18:04 [0x0-0x475475].com.highgroove.redwood[22169] /System/Library/Frameworks/CoreFoundation.framework/Resources/BridgeSupport/CoreFoundation.dylib: mach-o, but wrong architecture (RuntimeError) 12-03-11 18:18:04 com.apple.launchd.peruser.501[576] ([0x0-0x475475].com.highgroove.redwood[22169]) Exited with exit code: 1 % file /System/Library/Frameworks/CoreFoundation.framework/Resources/BridgeSupport/CoreFoundation.dylib /System/Library/Frameworks/CoreFoundation.framework/Resources/BridgeSupport/CoreFoundation.dylib: Mach-O 64-bit dynamically linked shared library x86_64 % file /Users/eloy/Downloads/Redwood.app/Contents/MacOS/Redwood /Users/eloy/Downloads/Redwood.app/Contents/MacOS/Redwood: Mach-O executable i386 Not sure if that BridgeSupport file was updated by the preview installers, but it seems that your app does not want to load mine because your app is only compiled for i368. HTH On 10 mrt 2011, at 19:00, Andre Lewis wrote: > 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 > > > ___ > MacRuby-devel mailing list > MacRuby-devel@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] "framework" method gotcha
Hey All, I just spent a few hours banging my head against a gotcha with the `framework` method -- if there happens to be a file or directory in the current directory with the name of the framework, the method fails: $ touch Cocoa $ macruby -e 'framework "Cocoa"' -e:1:in `': framework at path `Cocoa' cannot be located (RuntimeError) $ rm Cocoa; mkdir Cocoa $ macruby -e 'framework "Cocoa"' -e:1:in `': framework at path `Cocoa' cannot be loaded: Error Domain=NSCocoaErrorDomain Code=4 UserInfo=0x200241e20 "The bundle “Cocoa” couldn’t be loaded because its executable couldn’t be located." I ran into this while trying to setup unit testing for a Cocoa framework I'm writing. XCode 4 automatically creates a directory for each target you create. Thus, when I tried to load my framework, it saw my project target directory and thought it had found the framework. I think the `framework` method should be updated to avoid this gotcha. Currently, it just tests for existence of a file or directory. I'm happy to start working on a patch, but wanted to ask if there's any possible reason the `framework` method is this naïve? christian. ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] Proposal: splitting macrubyc UI from logic
Hi, I have completed a proof of concept patch for MacRuby where I have split the UI of macrubyc from the underlying logic so that tools like macruby_deploy can make use of the compiler without having to spawn a new macruby process for each file that needs to be compiled. This should also be beneficial for compiling gems and the standard library. After having made this patch, I realized that there are still several places in the compiler where a new process is spawned to perform part of the compilation. I'm not really sure how much else can be lib-ified from the other required components. Overall there are still a few places that I know I can optimize without much work needed. Right now, compile time for ruby files with about 100-200 lines of code is about 1(+/-0.1) seconds on my MBP. Spawning a new macruby process and processing the macrubyc options takes about 0.25 seconds; so I think the patch is still useful in the general case. The code for the changes is located in my MacRuby fork on github: https://github.com/ferrous26/MacRuby/tree/libify-rubyc Mark Rada mr...@marketcircle.com ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] "framework" method gotcha
Hi Christian, As long as performance isn't affected, I think that making #framework smarter shouldn't be a problem. - Matt Sent from my iPhone On Mar 12, 2011, at 17:19, Christian Niles wrote: > Hey All, > > I just spent a few hours banging my head against a gotcha with the > `framework` method -- if there happens to be a file or directory in the > current directory with the name of the framework, the method fails: > > $ touch Cocoa > $ macruby -e 'framework "Cocoa"' > -e:1:in `': framework at path `Cocoa' cannot be located (RuntimeError) > > $ rm Cocoa; mkdir Cocoa > $ macruby -e 'framework "Cocoa"' > -e:1:in `': framework at path `Cocoa' cannot be loaded: Error > Domain=NSCocoaErrorDomain Code=4 UserInfo=0x200241e20 "The bundle “Cocoa” > couldn’t be loaded because its executable couldn’t be located." > > I ran into this while trying to setup unit testing for a Cocoa framework I'm > writing. XCode 4 automatically creates a directory for each target you > create. Thus, when I tried to load my framework, it saw my project target > directory and thought it had found the framework. > > I think the `framework` method should be updated to avoid this gotcha. > Currently, it just tests for existence of a file or directory. I'm happy to > start working on a patch, but wanted to ask if there's any possible reason > the `framework` method is this naïve? > > christian. > ___ > MacRuby-devel mailing list > MacRuby-devel@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] "framework" method gotcha
Cool. I've compiled MacRuby from source and discovered a test for the 'framework' method in test-macruby/cases/framework_test.rb. What's the best way to run the tests in this directory? It doesn't seem to be run by `rake spec` and I couldn't find another task that seemed to run these. On Mar 12, 2011, at 8:35 PM, Matt Aimonetti wrote: > Hi Christian, > > As long as performance isn't affected, I think that making #framework smarter > shouldn't be a problem. > > - Matt > > Sent from my iPhone > > On Mar 12, 2011, at 17:19, Christian Niles wrote: > >> Hey All, >> >> I just spent a few hours banging my head against a gotcha with the >> `framework` method -- if there happens to be a file or directory in the >> current directory with the name of the framework, the method fails: >> >> $ touch Cocoa >> $ macruby -e 'framework "Cocoa"' >> -e:1:in `': framework at path `Cocoa' cannot be located (RuntimeError) >> >> $ rm Cocoa; mkdir Cocoa >> $ macruby -e 'framework "Cocoa"' >> -e:1:in `': framework at path `Cocoa' cannot be loaded: Error >> Domain=NSCocoaErrorDomain Code=4 UserInfo=0x200241e20 "The bundle “Cocoa” >> couldn’t be loaded because its executable couldn’t be located." >> >> I ran into this while trying to setup unit testing for a Cocoa framework I'm >> writing. XCode 4 automatically creates a directory for each target you >> create. Thus, when I tried to load my framework, it saw my project target >> directory and thought it had found the framework. >> >> I think the `framework` method should be updated to avoid this gotcha. >> Currently, it just tests for existence of a file or directory. I'm happy to >> start working on a patch, but wanted to ask if there's any possible reason >> the `framework` method is this naïve? >> >> christian. >> ___ >> MacRuby-devel mailing list >> MacRuby-devel@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > ___ > MacRuby-devel mailing list > MacRuby-devel@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
