From: kimura w. <kimuraw@i.nifty.jp> - 2013-11-17 03:37:32
|
Hi, We released RubyCocoa 1.1.0. https://sourceforge.net/projects/rubycocoa/files/RubyCocoa/1.1.0/ RubyCocoa is a Mac OS X framework that allows Cocoa programming in the object-oriented scripting language Ruby. In other words, it is a bridge that let you access Objective-C objects from Ruby, and vice-versa. You can learn more about RubyCocoa on our website: http://rubycocoa.sourceforge.net/ A source tarball as well as binary installers for Mac OS X 10.9 and 10.8 are provided. This version deprecates some minor APIs, and does not support Mac OS X 10.5 and 10.4. The release notes are following. Enjoy! KIMURA Wataru == Changes 1.1.0 from 1.0.7: 2013-11-17 === Improvements * Support Xcode 5 "Modules". * Developers can disable internal Objective-C -> Ruby objects cache via a new global variable $RUBYCOCOA_USE_OC2RBCACHE to avoid crashes from inconsistency between the cache and Ruby's GC. [Experimental] The crash may occurs delegate of NSTableView. # rb_main.rb require 'osx/cocoa' def rb_main_init : end $RUBYCOCOA_USE_OC2RBCACHE = false # <= add rb_main_init === Fixes * Fixed standaloneify.rb error with ruby-2.0 or rubygems-2.1. * Fixed SEGV at Object#dup for some Objective-C objects. === Deprecates * Deprecated Objective-C class "RubyCocoa" in <RubyCocoa/RubyCocoa.h>. developers can use RBRuntime functions to call ruby from Objective-C. - bundleInitWithProgram:class:param: -> RBBundleInit() - applicationInitWithProgram:argc:argv:param: -> RBApplicationInit() - applicationMainWithProgram:argc:argv: -> RBApplicationMain() * Deprecated NSString|String methods depends "NKF" extension. - NSString.guess_nsencoding - NSString.guess_encoding - NSString.stringWithRubyString - NSMutableString.stringWithRubyString - String.nsencoding === Note * Mac OS X 10.5 or earlier not supported. === Files - RubyCocoa-1.1.0-OSX10.9.dmg * MD5(RubyCocoa-1.1.0-OSX10.9.dmg)= 45c281ee2af5dc770adb7c69c4b7ea2c * SHA1(RubyCocoa-1.1.0-OSX10.9.dmg)= 630205d1a0ab55514965eec4023e3741881cdb61 - RubyCocoa-1.1.0-OSX10.8.dmg * MD5(RubyCocoa-1.1.0-OSX10.8.dmg)= 5ef68123f9ed8a64571413f722d91205 * SHA1(RubyCocoa-1.1.0-OSX10.8.dmg)= 297649dba3bed5fec5484b27cc5027afd9319e42 - RubyCocoa-1.1.0.tar.gz * MD5(RubyCocoa-1.1.0.tar.gz)= c1a8fd46893b30f4cb7129d46ac3ed57 * SHA1(RubyCocoa-1.1.0.tar.gz)= 55e80bab6a3f7edeb27559560fc73fa7995e9a4e -- kimura wataru |
From: Dave H. <gro...@gr...> - 2014-11-02 06:54:58
|
I sat down to update an old program, resigned to having to rewrite it for MacRuby, only to discover that “the replacement for RubyCocoa” is, in fact, dead. I’m awfully glad RubyCocoa is still here; there’s no way I”m ever going to waste time with Objective-C, but I admit I’m wondering if anybody else is using RubyCocoa, either, since I can’t seem to find anybody having mentioned the fact that XCode 5.1’s Interface Builder seems to have lost the ability to find the outlets. My app’s controller class AppController << OSX::NSWindowController blah blah blah end is no longer comprehensible or visible to Interface Builder. Is this being fixed, or is there some bit that didn’t get installed, or am I just really lucky and it’s only my install that’s broken? |
From: Axel R. <axe...@ro...> - 2014-11-02 09:09:58
|
I also have some old projects in RubyCocoa and deploying them with libraries was always troublesome. I was reluctant to convert the heavy string manipulations into Objective-C. Have a look at swift: Apple's new language. It might well be that they killed off MacRuby because they knew swift was coming. It is not ruby, but highly inspired, shall we say? https://developer.apple.com/swift/ Cheers, Axel Roest Sent from the road, so beware of bumps in the text! > On 2 nov. 2014, at 06:17, Dave Howell <gro...@gr...> wrote: > > I sat down to update an old program, resigned to having to rewrite it for MacRuby, only to discover that “the replacement for RubyCocoa” is, in fact, dead. > > I’m awfully glad RubyCocoa is still here; there’s no way I”m ever going to waste time with Objective-C, but I admit I’m wondering if anybody else is using RubyCocoa, either, since I can’t seem to find anybody having mentioned the fact that XCode 5.1’s Interface Builder seems to have lost the ability to find the outlets. My app’s controller > > class AppController << OSX::NSWindowController > blah blah blah > end > > is no longer comprehensible or visible to Interface Builder. Is this being fixed, or is there some bit that didn’t get installed, or am I just really lucky and it’s only my install that’s broken? > ------------------------------------------------------------------------------ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
From: grimmwerks <gr...@gr...> - 2014-11-02 09:48:45
|
Have you looked at RubyMotion? And I second looking at Swift. Sent from my iPhone > On Nov 2, 2014, at 1:17 AM, Dave Howell <gro...@gr...> wrote: > > I sat down to update an old program, resigned to having to rewrite it for MacRuby, only to discover that “the replacement for RubyCocoa” is, in fact, dead. > > I’m awfully glad RubyCocoa is still here; there’s no way I”m ever going to waste time with Objective-C, but I admit I’m wondering if anybody else is using RubyCocoa, either, since I can’t seem to find anybody having mentioned the fact that XCode 5.1’s Interface Builder seems to have lost the ability to find the outlets. My app’s controller > > class AppController << OSX::NSWindowController > blah blah blah > end > > is no longer comprehensible or visible to Interface Builder. Is this being fixed, or is there some bit that didn’t get installed, or am I just really lucky and it’s only my install that’s broken? > ------------------------------------------------------------------------------ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
From: Gregory C. <gr...@in...> - 2014-11-02 16:30:53
|
I’m also incredibly grateful that RubyCocoa is still here. I’ve been using it since 2008. I had one app written in MacRuby to try it out, but when garbage collection was deprecated in Mavericks it stopped working, so I rewrote it in RubyCocoa. The automatic outlets disappeared awhile ago for me. Simple solution is to create an Objective C header file with matching ib_outlets and ib_actions . For example: #import <Cocoa/Cocoa.h> @interface AppController : NSObject { IBOutlet NSWindow *mainWindow; IBOutlet NSButton *openFileButton; IBOutlet NSTextField *fileName; IBOutlet NSWindow *progressWindow; IBOutlet NSView *progressView; IBOutlet NSProgressIndicator *progressIndicator; IBOutlet NSTextField *progressMessage; } - (IBAction)chooseFile:(id)sender; - (IBAction)saveFile:(id)sender; @end > On Nov 1, 2014, at 10:17 PM, Dave Howell <gro...@gr...> wrote: > > I sat down to update an old program, resigned to having to rewrite it for MacRuby, only to discover that “the replacement for RubyCocoa” is, in fact, dead. > > I’m awfully glad RubyCocoa is still here; there’s no way I”m ever going to waste time with Objective-C, but I admit I’m wondering if anybody else is using RubyCocoa, either, since I can’t seem to find anybody having mentioned the fact that XCode 5.1’s Interface Builder seems to have lost the ability to find the outlets. My app’s controller > > class AppController << OSX::NSWindowController > blah blah blah > end > > is no longer comprehensible or visible to Interface Builder. Is this being fixed, or is there some bit that didn’t get installed, or am I just really lucky and it’s only my install that’s broken? > ------------------------------------------------------------------------------ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
From: Dave H. <gro...@gr...> - 2014-11-07 00:23:59
|
I should have changed the subject in the first place. Oops. > The automatic outlets disappeared awhile ago for me. Simple solution is to create an Objective C header file with matching ib_outlets and ib_actions . Awesome. I’d never have figured that out. What I actually did, though, was use TimeMachine to recover a version of MainMenu.nib from before the InterfaceBuilder in XCode 5 touched it. Then I opened my project in XCode 3.x under 10.6, or at least opened the .nib file with that version of Interface Builder. My new outlets were right where I expected them to be. I made the new connections, saved it, then opened the project back under 10.10 and XCode 5 for compilation. As I’d expected, “new” XCode will still happily use old-school .nib files. I suspect I can …. {checks version numbers} oh, really??? Interesting! So “interface builder” is now built into XCode, but there’s still a copy of Interface Builder 3.2.6 on my OSX 10.10 machine, which is the same version on my OSX 10.6 machine. If I open the .nib file in Interface Builder rather than XCode, it looks like the outlets and whatnot are still available for connecting. How very useful . . . . I just have to make sure not to accidentally open and save the .nib in XCode, or it will no longer be possible to use Interface Builder to edit it. Also, thanks to those of you who pointed me at Swift. However, most of my programming isn’t really for OS X. Most of it’s database<->web work running on an Ubuntu server, and I don’t think Swift is going to be a terribly workable replacement for that any time soon, so I’d really rather just stick with one language for now, especially since, as a hobbyist, I spend a not-inconsiderable amount of time just re-learning what I used to know when I sit down to program (as in, oh, every couple of months). |