Re: [MacRuby-devel] Help test a new MacRuby app
The app now works :) However, I had filled in the wrong google credentials the first time, after which it was impossible for me to get it to use the right ones. It seems that it keeps using the password I had entered the first time. Basecamp search worked fine. On Mon, Mar 14, 2011 at 12:04 AM, Andre Lewis wrote: > HI Eloy, would you mind > trying http://redwoodapp.com/system/Redwood_macruby_trunk.zip -- it bundles > MacRuby 0.10/trunk, and is compiled for x86_64. Thanks! > Andre > > On Sat, Mar 12, 2011 at 9:25 AM, Eloy Duran wrote: >> >> 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 >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> > > > > -- > Scout Web Monitoring and Reporting ~ http://scoutapp.com > blog: http://blog.scoutapp.com > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Help test a new MacRuby app
Oh yes, I also had this problem, but forgot to mention it in my email to you. I'm not sure if I got my password wrong at first, but I was unable to log in even when I was sure I had the right credentials. On 14 Mar 2011, at 12:21, Eloy Duran wrote: > The app now works :) However, I had filled in the wrong google > credentials the first time, after which it was impossible for me to > get it to use the right ones. It seems that it keeps using the > password I had entered the first time. Basecamp search worked fine. > > On Mon, Mar 14, 2011 at 12:04 AM, Andre Lewis wrote: >> HI Eloy, would you mind >> trying http://redwoodapp.com/system/Redwood_macruby_trunk.zip -- it bundles >> MacRuby 0.10/trunk, and is compiled for x86_64. Thanks! >> Andre >> >> On Sat, Mar 12, 2011 at 9:25 AM, Eloy Duran wrote: >>> >>> 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 >>> [email protected] >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>> >>> >>> ___ >>> MacRuby-devel mailing list >>> [email protected] >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>> >> >> >> >> -- >> Scout Web Monitoring and Reporting ~ http://scoutapp.com >> blog: http://blog.scoutapp.com >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >> > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] TIL - Uncaught exceptions in threads cause SIGABRT in the main thread!
If you find this exception-shifting behavior troubling, please open a ticket. Could you explain why introducing the begin/rescue pair that is good programming practice? Matt On Mar 13, 2011, at 6:31 PM, Morgan Schweers wrote: > 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 > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel smime.p7s Description: S/MIME cryptographic signature ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] TIL - Uncaught exceptions in threads cause SIGABRT in the main thread!
Greetings, On Mon, Mar 14, 2011 at 6:57 AM, Matt Massicotte wrote: > If you find this exception-shifting behavior troubling, please open a > ticket. > What bugs me about the behavior in this case is that if the exact same operation is done on the main thread, it throws a very nice, normal Ruby exception trace, and I know immediately what boneheaded move I made. :) If it happens on an NSThread, it gives an absolutely opaque 'SIGABRT' on the main thread. I'll see if I can create a simple example that demonstrates it. Could you explain why introducing the begin/rescue pair that is good > programming practice? > Historically I've found that when I have a consumer thread that does 'work', I don't want an unanticipated failure of any one work unit to prevent future work units from being processed. So at the top level of any thread action (in this case, in the method triggered on NSTimer firing) I wrap the work-processing code in a rescue block, so if an unexpected failure happens, I log it, and move on to the next work unit. In some (most?) systems an uncaught exception will kill off the thread, and apparently something similar is true in MacRuby. Matt > Hope that helps. -- Morgan Schweers On Mar 13, 2011, at 6:31 PM, Morgan Schweers wrote: > > 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 > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] TIL - Uncaught exceptions in threads cause SIGABRT in the main thread!
On Mar 14, 2011, at 10:35 AM, Morgan Schweers wrote: > Greetings, > > On Mon, Mar 14, 2011 at 6:57 AM, Matt Massicotte wrote: > If you find this exception-shifting behavior troubling, please open a ticket. > > What bugs me about the behavior in this case is that if the exact same > operation is done on the main thread, it throws a very nice, normal Ruby > exception trace, and I know immediately what boneheaded move I made. :) If > it happens on an NSThread, it gives an absolutely opaque 'SIGABRT' on the > main thread. > > I'll see if I can create a simple example that demonstrates it. That would be great. This behavior is not macruby-specific, but bites anyone that sees exceptions on non-main threads. > > Could you explain why introducing the begin/rescue pair that is good > programming practice? > > Historically I've found that when I have a consumer thread that does 'work', > I don't want an unanticipated failure of any one work unit to prevent future > work units from being processed. So at the top level of any thread action > (in this case, in the method triggered on NSTimer firing) I wrap the > work-processing code in a rescue block, so if an unexpected failure happens, > I log it, and move on to the next work unit. In some (most?) systems an > uncaught exception will kill off the thread, and apparently something similar > is true in MacRuby. Ah. Yes, in the special-case of executing work that has zero side-effects on the rest of your system, this can be helpful. > > Matt > > Hope that helps. > > -- Morgan Schweers > > On Mar 13, 2011, at 6:31 PM, Morgan Schweers wrote: > >> 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 >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel smime.p7s Description: S/MIME cryptographic signature ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Proposal: splitting macrubyc UI from logic
Hi Mark, As macrubyc's compilation logic is essentially spawning several command-line tools, I wonder if calling the logic directly from macruby_deploy is going to bring significant advantages, vs the complexity of splitting macrubyc. I think a better strategy would be to optimize what's slow in macrubyc (such as command-line options parsing), and better include the compilation strategy into Xcode (if possible). Laurent On Mar 12, 2011, at 5:40 PM, Mark Rada wrote: > 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 > [email protected] > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] "framework" method gotcha
Hi Christian, These tests should probably be removed, they are not used anymore (these were used before we switched to RubySpec). The correct thing to do is probably make a macruby spec (under the spec/macruby directory). How do you intend to change #framework exactly? Maybe you should work on a patch first, and we can iterate on it, then write the spec/test later. Thanks for helping :) Laurent On Mar 12, 2011, at 10:54 PM, Christian Niles wrote: > 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 >>> [email protected] >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] TIL - Uncaught exceptions in threads cause SIGABRT in the main thread!
Hi Morgan, Well in theory, you should NOT get a segfault when doing that. When an exception isn't rescued inside a Thread, the correct behavior is that the thread will quit, and that the exception will be silently ignored. Then, once the Thread object is garbage collected, if the exception has not been retrieved from the Thread object (for instance, if #join has never been called on it), then a warning message is printed on stderr with the exception backtrace, for debugging purposes. It would be nice if you could reproduce the segfault in a small test case, because it looks bad (we should never segfault) :) Laurent On Mar 13, 2011, at 6:31 PM, Morgan Schweers wrote: > 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 > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] Xcode 4
Hi: Is MacRuby fully compatible with Xcode 4 or should I wait a while before upgrading? Thanks, Bob Rice ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Xcode 4
Xcode4 doesn't have any MacRuby templates yet and features that weren't working in Xcode 3 still don't work in Xcode 4 (indexation, debugger etc...). However, everything else works fine. I would wait until we release 0.10 with the Xcode 4 templates to switch tho (should be really soon now, Thibault is updating the templates). - Matt On Mon, Mar 14, 2011 at 2:14 PM, Robert Rice wrote: > Hi: > > Is MacRuby fully compatible with Xcode 4 or should I wait a while before > upgrading? > > Thanks, > Bob Rice > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Proposal: splitting macrubyc UI from logic
On 2011-03-14, at 16:05, Laurent Sansonetti wrote: > Hi Mark, > > As macrubyc's compilation logic is essentially spawning several command-line > tools, I wonder if calling the logic directly from macruby_deploy is going to > bring significant advantages, vs the complexity of splitting macrubyc. > The splitting macrubyc was a low hanging fruit; macrubyc was almost split already, so few changes were introduced. I don't think I introduced much complexity, and in turn some clutter was separated from the initialization process: - calls to #die were replaced with calls to #raise - the option parser was moved out of the compiler class, now Compiler#initialize takes a hash of options and just unpacks it - most of the extra tool lookups (#locate) were moved to constants so they only have to be looked up once > I think a better strategy would be to optimize what's slow in macrubyc (such > as command-line options parsing), I don't think it's the command line parsing, I thinks it's the spawning of new MacRuby processes which will have to JIT the compiler logic over and over again for each file. But I guess a lot of that can be mitigated by compiling the compiler when it becomes possible. > and better include the compilation strategy into Xcode (if possible). > That does sound like a much better idea for macruby_deploy. However, I am rarely using Xcode to work with MacRuby, and there are other places where calling the compiler directly will have benefit, such as a rake task or during gem installation. Perhaps I am speaking for a minority in these two cases Sent from my iDevice > Laurent > > On Mar 12, 2011, at 5:40 PM, Mark Rada wrote: > >> 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 >> [email protected] >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Help test a new MacRuby app
Seems to be working for me, and the UI of the search results looks very nice. Congratulations on the app! A few little bugs/notes: - In the Preferences dialog you have a typo, "Googe Docs". - When you open the Preferences dialog, and then switch out of the app (like say to go find your credentials to copy and paste), the dialog stays on screen, but when you click back on it, it closes itself. Odd and frustrating, and I'm not sure what the point is. ;-) - Also, it seems strange that you have to enter the ".basecamphq.com" subdomain—I'm sure many of us use multiple subdomains for different client accounts. I would think it would be possible to authenticate on the main domain and access a list of the user's subdomains... Anyway, keep up the good work! And if you feel like writing up any little tutorials I'm sure the MacRuby community would be interested in hearing how you got certain features of the app working - global key shortcuts, menubar items, etc. -Gabriel On Mon, Mar 14, 2011 at 5:32 AM, Nick Ludlam wrote: > Oh yes, I also had this problem, but forgot to mention it in my email to > you. I'm not sure if I got my password wrong at first, but I was unable to > log in even when I was sure I had the right credentials. > > On 14 Mar 2011, at 12:21, Eloy Duran wrote: > > > The app now works :) However, I had filled in the wrong google > > credentials the first time, after which it was impossible for me to > > get it to use the right ones. It seems that it keeps using the > > password I had entered the first time. Basecamp search worked fine. > > > > On Mon, Mar 14, 2011 at 12:04 AM, Andre Lewis > wrote: > >> HI Eloy, would you mind > >> trying http://redwoodapp.com/system/Redwood_macruby_trunk.zip -- it > bundles > >> MacRuby 0.10/trunk, and is compiled for x86_64. Thanks! > >> Andre > >> > >> On Sat, Mar 12, 2011 at 9:25 AM, Eloy Duran > wrote: > >>> > >>> 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 > >>> [email protected] > >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > >>> > >>> > >>>
