[MacRuby-devel] xcode question
….I am new to mac , macruby , ruby etc I have built an application using XCODE and when I click RUN on XCODE the application runs and does what I intended here to do. But … I don't find the way to run it OUTSIDE of XCODE , like any other app I have on my mac. When I look at the directory of my app , it does not have the structure of my regular applications located in /Applications folder. I tried to find an answer in MAC Developer library but got lost (??) so I apologize if this is too simple a question Many Thanks, David Kramf ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] xcode question
How do I export it as Application ? Thanks, David On Oct 24, 2012, at 7:24 PM, Jonathan Silverman wrote: > Build it in deploy mode > > Build > Archive > > Assuming you have provisioning profiles and your proper codesigning > certificates installed from developer.apple.com > > You can submit it to App Store (if you know how to use iTunes > Connect), or export as a Mac Installer or Application > > If you export as Application it will have the same format as other > .apps and can be moved into /Applications. If you export a Mac > Installer, it will create a package that will install itself into > Applications, this also seems to serve as the update mechanism. > > Make sure, if you use any gems, under Deployment that you use --gem > with macruby_deploy > > On Wed, Oct 24, 2012 at 10:15 AM, david kramf wrote: >> >> ….I am new to mac , macruby , ruby etc >> I have built an application using XCODE and when I click RUN on XCODE the >> application runs and does what I intended here to do. >> But … I don't find the way to run it OUTSIDE of XCODE , like any other app I >> have on my mac. >> When I look at the directory of my app , it does not have the structure of >> my regular applications located in /Applications folder. >> I tried to find an answer in MAC Developer library but got lost (??) so I >> apologize if this is too simple a question >> >> Many Thanks, >> David Kramf >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo/macruby-devel > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macruby-devel
[MacRuby-devel] Fwd: xcode question
I finally discovered how to export . Thank you for your help. David Begin forwarded message: > From: david kramf > Subject: Re: [MacRuby-devel] xcode question > Date: October 24, 2012 9:02:35 PM GMT+02:00 > To: "MacRuby development discussions." > > How do I export it as Application ? > Thanks, David > > On Oct 24, 2012, at 7:24 PM, Jonathan Silverman wrote: > >> Build it in deploy mode >> >> Build > Archive >> >> Assuming you have provisioning profiles and your proper codesigning >> certificates installed from developer.apple.com >> >> You can submit it to App Store (if you know how to use iTunes >> Connect), or export as a Mac Installer or Application >> >> If you export as Application it will have the same format as other >> .apps and can be moved into /Applications. If you export a Mac >> Installer, it will create a package that will install itself into >> Applications, this also seems to serve as the update mechanism. >> >> Make sure, if you use any gems, under Deployment that you use --gem >> with macruby_deploy >> >> On Wed, Oct 24, 2012 at 10:15 AM, david kramf wrote: >>> >>> ….I am new to mac , macruby , ruby etc >>> I have built an application using XCODE and when I click RUN on XCODE the >>> application runs and does what I intended here to do. >>> But … I don't find the way to run it OUTSIDE of XCODE , like any other app >>> I have on my mac. >>> When I look at the directory of my app , it does not have the structure of >>> my regular applications located in /Applications folder. >>> I tried to find an answer in MAC Developer library but got lost (??) so I >>> apologize if this is too simple a question >>> >>> Many Thanks, >>> David Kramf >>> ___ >>> MacRuby-devel mailing list >>> [email protected] >>> http://lists.macosforge.org/mailman/listinfo/macruby-devel >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo/macruby-devel > ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] Using Virtus or SmartProperty as outlets?
"Basically, I need to make sure that when I ask for an integer, I get an integer. And when I want a string - I can reject anything but strings." Can't you use Ruby services like is_a? to force it ? Thanks, David Kramf On Nov 21, 2012, at 10:04 PM, Carolyn Ann Grant wrote: > Basically, I need to make sure that when I ask for an integer, I get an > integer. And when I want a string - I can reject anything but strings. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macruby-devel
[MacRuby-devel] windows contrôler issue
Hi,
In MyController (copied below) the awakeFromNib is called but the other methods
are not . Can someone explain me what the problem is ?
Thanks, David
class MyController < NSWindowController
attr_accessor :window
def awakeFromNib
@window.delegate = self
puts " at end of awake from nib. title is #{@window.title}"
end
def windowWillLoad
puts "window will be soon loaded"
end
def windowDidLoad
puts "window loaded"
end
def windowTitleForDocumentDisplayName(displayName)
"Hello World"
end
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macruby-devel
[MacRuby-devel] Problem with a window controller
Hi,
In the copied below code only the awakeFromNib is executed . Can someone
explain me what do I do wrong ? Window is displayed and I expected all other
methods to be called.
Thanks, David
class MyController < NSWindowController
attr_accessor :window
def awakeFromNib
@window.delegate = self
puts " at end of awake from nib. title is #{@window.title}"
end
def windowWillLoad
puts "window will be soon loaded"
end
def windowDidLoad
puts "window loaded"
end
def windowTitleForDocumentDisplayName(displayName)
"Hello World"
end
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] Problem with a window controller
Thank you very much Andy and Jim
I followed your remarks , played with the code and I am still surprised. It
turns out that awakeFromNib is called before applicationDidFinishLaunching so
there MyController is already initialized and has the correct window as the his
instance variable. NSWindow has both a delegate protocol and a Controller class
and so I called setDelegate and setController . Everything seems OK but the
methods willLoad and didLoad are not called although clearly my class is both
the delegate and the controller of my window . So I am still left asking what
am I doing wrong (??).
Are there MacRuby code samples I can use. I read Lim,Chueng and McAnally book.
I wonder where can I find more samples. I am also not sure I am doing
everything correct with the IB . My blue box that represents MyController list
"showWindow: " as a "Received Action" , but I could not connect it to any
element of window draw in the XIB file.
David
class AppDelegate
attr_accessor :window
def applicationDidFinishLaunching(a_notification)
puts " Insert code here to initialize your application"
wCtrl = @window.delegate
puts "no delegate" if wCtrl == nil
win = wCtrl.window
puts "win is nil" if win == nil
puts "title of window is #{win.title}"
ctrl = @window.windowController
puts "no controller" if ctrl == nil
puts "class of delegate is #{wCtrl.class}"
puts "class of controller is #{ctrl.class}"
puts "both are equal " if wCtrl == ctrl
x = ctrl.showWindow
puts "x class is #{x.class} " unless x == nil
#puts "window nil " if win == nil
#wCtrl.close
end
end
class MyController < NSWindowController
attr_accessor :window
def initialize
puts "in initialize"
initWithWindowNibName("tow")
#puts "after initialization window is #{@window.title}"
end
def routine
puts "in routine"
end
#def initWithWindow(window)
# puts "in initWithWindow"
# super(@window)
#end
def awakeFromNib
@window.setDelegate(self)
@window.setWindowController(self)
puts " at end of awake from nib. title is #{@window.title}"
end
def windowWillLoad
puts "window will be soon loaded"
end
def windowDidLoad
puts "window loaded"
end
def windowTitleForDocumentDisplayName(displayName)
"Hello World"
end
def showWindow
puts "in showWindow"
super(self)
end
def close
puts "in close window is #{@window.title}"
super
end
end
at end of awake from nib. title is two
Insert code here to initialize your application
title of window is two
class of delegate is MyController
class of controller is MyController
both are equal
in showWindow
x class is MyController
On Dec 1, 2012, at 3:00 AM, Andy Park wrote:
> Without being able to verify anything for accuracy at the moment, it looks
> like your window's delegate is not set to the controller at the time the
> events are occurring.
>
> Check if you need to set this - try tracing the window's delegate at
> different points of the controller's lifecycle.
>
> On 30 Nov 2012, at 00:50, david kramf wrote:
>
>>
>> Hi,
>> In the copied below code only the awakeFromNib is executed . Can someone
>> explain me what do I do wrong ? Window is displayed and I expected all
>> other methods to be called.
>> Thanks, David
>>
>>
>> class MyController < NSWindowController
>> attr_accessor :window
>>
>> def awakeFromNib
>> @window.delegate = self
>> puts " at end of awake from nib. title is #{@window.title}"
>> end
>>
>> def windowWillLoad
>> puts "window will be soon loaded"
>> end
>>
>> def windowDidLoad
>> puts "window loaded"
>> end
>> def windowTitleForDocumentDisplayName(displayName)
>> "Hello World"
>> end
>>
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> http://lists.macosforge.org/mailman/listinfo/macruby-devel
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] Problem with a window controller
Hi Bob My code crashes if I omit the attr_accessor. Can you refer me to instructions of how to configure the IB to link to my controller as delegate (?) . In the examples I have in my book and ,if I am not mistaken, lectures I viewed in iTunes U ( the Stanford series ), they all used the awakeFromNib as point of initialization . Thanks, David On Dec 3, 2012, at 6:24 AM, Robert Carl Rice wrote: > Hi David, > > A couple of things I notice offhand in you code: > > The NSWindowController class defines accessor methods for "window" so you > shouldn't redefine it with the Ruby attr_accessor method. Note: similarly > NSViewController defines accessor methods for "view". > > You can configure IB to link the window delegate when the Nib is expanded so > that you don't need to set it in awakeFromNib. > > Bob Rice > > > On Nov 29, 2012, at 6:50 PM, david kramf wrote: > >> >> Hi, >> In the copied below code only the awakeFromNib is executed . Can someone >> explain me what do I do wrong ? Window is displayed and I expected all >> other methods to be called. >> Thanks, David >> > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] Problem with a window controller
Hi Bob I never programmed in Objective-C. When I open a MacRuby project I automatically get a window attar_accessor defined in my AppDelegate created code, but not in the controller which I write by my own. If I connect, using IB , the window to my controller parameter (object variable) , I get the same window property created both in my WindowController and in the appDelegate. So far during my plays with the code I don't encounter any other problem apart from the willLoad and didLoad delegates which I expected to be called . Since the @window variable is already instantiated when my awakeFromNib is called, I have a feeling that the Cocoa code already called them before he created MyController class. I am not sure about that , since this reasoning leads to a conclusion that this is some kind of a bug in Cocoa , but Cocoa exists for a long time and used a lot , so I am not sure. Since this is the only problem I faced so far , I decided to move on and be careful upon relying on these 2 delegates. Thanks, David. On Dec 4, 2012, at 2:06 AM, Robert Carl Rice wrote: > Hi David, > > You should consider the "window" Objective C property to be "owned" by > NSWindowController and it's confusing to define a Ruby class variable with > the same name. It should automatically appear as an IB outlet for your > NSWindowController subclass that you would "hook up" in IB just as you would > a MacRuby outlet assuming that you instantiate your NSWindowController > subclass with the same NIB with your NSWindow. > > As per the NSWindowController documentation, you would read the window > property using the method window() or self.window which will first load the > window if it not already loaded. > > You could set the window property using setWindow( window ), but normally you > have NIB expansion call setWindow. > > Similarly NSWindow automatically defines the delegate property that you can > hook up to your window controller in IB assuming that you instantiate your > NSWindowController subclass with the same NIB with your NSWindow. > > I removed a lot of initialization code from my applications once I better > understood how NIB file expansion works. You can hook up most of your > delegates and target actions in IB. You can even initialize static Popup and > comboBox option lists in IB. However, don't hookup dataSource in IB for > NSTableView or NSOutlineView because it will attempt to load table data > before you get awakeFromNib. > > Bob Rice > > On Dec 3, 2012, at 1:35 AM, david kramf wrote: > >> Hi Bob >> My code crashes if I omit the attr_accessor. >> Can you refer me to instructions of how to configure the IB to link to my >> controller as delegate (?) . In the examples I have in my book and ,if I am >> not mistaken, lectures I viewed in iTunes U ( the Stanford series ), they >> all used the awakeFromNib as point of initialization . >> Thanks, David >> On Dec 3, 2012, at 6:24 AM, Robert Carl Rice wrote: >> >>> Hi David, >>> >>> A couple of things I notice offhand in you code: >>> >>> The NSWindowController class defines accessor methods for "window" so you >>> shouldn't redefine it with the Ruby attr_accessor method. Note: similarly >>> NSViewController defines accessor methods for "view". >>> >>> You can configure IB to link the window delegate when the Nib is expanded >>> so that you don't need to set it in awakeFromNib. >>> >>> Bob Rice >>> >>> >>> On Nov 29, 2012, at 6:50 PM, david kramf wrote: >>> >>>> >>>> Hi, >>>> In the copied below code only the awakeFromNib is executed . Can someone >>>> explain me what do I do wrong ? Window is displayed and I expected all >>>> other methods to be called. >>>> Thanks, David >>>> >>> >>> ___ >>> MacRuby-devel mailing list >>> [email protected] >>> http://lists.macosforge.org/mailman/listinfo/macruby-devel >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo/macruby-devel > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] Problem with a window controller
Hi Bob I still have to get used to the IB. One of the things I find confusing is that after I define something using the IB I don't see the generated code . I think that initially I will rely less on the IB and more on the code. Many Thanks, David. On Dec 4, 2012, at 9:19 AM, Robert Carl Rice wrote: > Hi David, > > AppDelegate doesn't inherit from NSWindowController so you would need a > MacRuby outlet to obtain a link to the Main Menu window or any other object > instantiated in the NIB, but usually you don't need this. This outlet doesn't > need to be named "window". You could rename it to something like > :mainMenuWindow to be less confusing. Usually you would add additional > outlets to change controls within the Main Menu. These outlets don't need to > be in an NSWindowController subclass. The attr_writer or attr_accessor > pre-processor macros will define a class variable that you would reference > with a leading "@". > > If you instaintiate a subclass of NSWindowController by adding an object to > the XIB that you assign to your own subclass, then NSWindowController will > automatically add an IB outlet for "window" to your subclass that you would > normally "hookup" in IB to your own subclass of NSWindow instantiated by the > same NIB. You should not create MacRuby accessors for "window" in an > NSWindowController subclass rather you use the self.window superclass method. > The @window class variable should be undefined in your NSWindowController > subclass . Cocoa does not define MacRuby class variables; only MacRuby code > can do that. You would only get the same NSWindow instance for both your > AppDelegate and your NSWindowController subclass if you connect both your > AppDelegate and your NSWindowController subclass to the same window in IB. > > Bob Rice > > > On Dec 4, 2012, at 1:25 AM, david kramf wrote: > >> Hi Bob >> I never programmed in Objective-C. >> When I open a MacRuby project I automatically get a window attar_accessor >> defined in my AppDelegate created code, but not in the controller which I >> write by my own. If I connect, using IB , the window to my controller >> parameter (object variable) , I get the same window property created both in >> my WindowController and in the appDelegate. So far during my plays with the >> code I don't encounter any other problem apart from the willLoad and didLoad >> delegates which I expected to be called . Since the @window variable is >> already instantiated when my awakeFromNib is called, I have a feeling that >> the Cocoa code already called them before he created MyController class. I >> am not sure about that , since this reasoning leads to a conclusion that >> this is some kind of a bug in Cocoa , but Cocoa exists for a long time and >> used a lot , so I am not sure. >> Since this is the only problem I faced so far , I decided to move on and be >> careful upon relying on these 2 delegates. >> Thanks, David. >> >> On Dec 4, 2012, at 2:06 AM, Robert Carl Rice wrote: >> >>> Hi David, >>> >>> You should consider the "window" Objective C property to be "owned" by >>> NSWindowController and it's confusing to define a Ruby class variable with >>> the same name. It should automatically appear as an IB outlet for your >>> NSWindowController subclass that you would "hook up" in IB just as you >>> would a MacRuby outlet assuming that you instantiate your >>> NSWindowController subclass with the same NIB with your NSWindow. >>> >>> As per the NSWindowController documentation, you would read the window >>> property using the method window() or self.window which will first load the >>> window if it not already loaded. >>> >>> You could set the window property using setWindow( window ), but normally >>> you have NIB expansion call setWindow. >>> >>> Similarly NSWindow automatically defines the delegate property that you can >>> hook up to your window controller in IB assuming that you instantiate your >>> NSWindowController subclass with the same NIB with your NSWindow. >>> >>> I removed a lot of initialization code from my applications once I better >>> understood how NIB file expansion works. You can hook up most of your >>> delegates and target actions in IB. You can even initialize static Popup >>> and comboBox option lists in IB. However, don't hookup dataSource in IB for >>> NSTableView or NSOutlineView because it will attempt to load tab
Re: [MacRuby-devel] Problem with a window controller
Hi Bob, "As you become more familiar with IB, you will probably do more initialization of objects in IB and less in MacRuby. Nib file expansion instantiates objects and then makes calls to initialize the objects using the same methods that you are using to initialize objects in MacRuby. Actually, in a large application, it would difficult to hook up all of the outlets without using IB." >From my modest acquaintance with MacRuby that is not exactly the case since >when the NIB instantiates an NSWindowController object , it does not call >"initialize" ,as defined in Ruby , but calls "awakeFromNib". Only when you >instantiate your controller from the code itself , you get your >"initialize"method called. I know I still have a lot of practicing on IB. What I find disturbing ,is that when I do something with IB I cannot see the code created to accommodate my actions ( maybe because I only work in MacRuby and not Objective-C?). Thanks, David On Dec 6, 2012, at 7:42 PM, Robert Carl Rice wrote: > As you become more familiar with IB, you will probably do more initialization > of objects in IB and less in MacRuby. Nib file expansion instantiates objects > and then makes calls to initialize the objects using the same methods that > you are using to initialize objects in MacRuby. Actually, in a large > application, it would difficult to hook up all of the outlets without using > IB. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] Problem with a window controller
Hi Bob "What I don't like is the way MacRuby supports…" - I hope that MacRuby will improve on that point. I have not encountered that problem yet. > "myClass = MyClass.alloc.initWithArgument( argument )"… - I believe this will > work fine but this is not Ruby. In Ruby( to the best of my knowledge) you > never allocate . You call NEW and Ruby takes care of allocating, > initialization, calling your Initialize method and finally ( I hope!!) > destroying and releasing the space. The programmer should never worry about > that. I would expect that this behavior to be followed also when an Object is > instantiated from NIB , but I can understand how implementation issues make > it hard to implement. Thanks, David On Dec 8, 2012, at 9:52 AM, Robert Carl Rice wrote: > Hi David, > > IB will use the default Obj C initialization and, yes, the default Obj C > initialization is a little different from Ruby initialization so I have to > make minor changes when I change a class from MacRuby instantiation to IB > instantiation. > > The default Obj C initialization calls init with no arguments immediately > after instantiation. This is the equivalent of: myClass = MyClass.alloc.init > or myClass = MyClass.new. You can initialize ruby class variables in you own > init method, but the init method generally should include a call to super and > must return self. > > You could pass argument(s) to a new Obj C with the first call using something > like > , but it's usually easier to send a second message with arguments. > Someone else here could better provide details on how MacRuby initialization > maps to Obj C initialization. > > IB will later call awakeFromNib for all instantiated objects after it has > completed initializing all instantiated objects so all of your IBOutlets will > be connected. This behavior can be very convenient. > > You can examine an XIB file with any XML file editor for curiosity, but I > haven't found any need to decode it so long as the NIB file expansion does > what IB says it will do. > > What I don't like is the way MacRuby supports IB outlets because it becomes > much too slow for large applications. It begins processing all MacRuby > project files when I open the IB connections view. But it only needs to > refresh the MacRuby class object that I currently have selected in IB and its > MacRuby superclasses. Since filenames don't have to match class names, it > would still have to scan files to find my class definition (or definitions), > but that should be very much faster than processing all of the files to find > and update IB Outlets. > > Bob Rice > > > On Dec 7, 2012, at 12:48 PM, david kramf wrote: > >> Hi Bob, >> "As you become more familiar with IB, you will probably do more >> initialization of objects in IB and less in MacRuby. Nib file expansion >> instantiates objects and then makes calls to initialize the objects using >> the same methods that you are using to initialize objects in MacRuby. >> Actually, in a large application, it would difficult to hook up all of the >> outlets without using IB." >> >> From my modest acquaintance with MacRuby that is not exactly the case since >> when the NIB instantiates an NSWindowController object , it does not call >> "initialize" ,as defined in Ruby , but calls "awakeFromNib". Only when you >> instantiate your controller from the code itself , you get your >> "initialize"method called. >> I know I still have a lot of practicing on IB. What I find disturbing ,is >> that when I do something with IB I cannot see the code created to >> accommodate my actions ( maybe because I only work in MacRuby and not >> Objective-C?). >> >> Thanks, David >> On Dec 6, 2012, at 7:42 PM, Robert Carl Rice wrote: > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macruby-devel
[MacRuby-devel] NSPoint and CGPoint issue
Hello,
I am trying to create an NSPoint object so I can call setFrameOrigin but I get
in response a CGPoint object . When I pass the CGPoint to setFrameOrigin , it
crashes. How do I make NSMakePoint making an NSPoint object and not a CGPoint
object.
Thank you for your help,
David Kramf
def initLabel(h)
@label = NSTextField.alloc.initWithFrame(CGRectMake(0,0,250, 45))
@label.setStringValue(h)
@label.drawsBackground = false
@label.bezeled = false
@label.font = NSFont.fontWithName("Arial", size:45.0)
@label.editable = false
puts "class of label is #{@label.class}"
width =
(@window.contentView.frameSize.width/2.0)-(@label.frameSize.width/2.0)
height =
(@window.contentView.frameSize.height/2.0)-(@label.frameSize.height/2.0)
puts "width is #{width} heght is #{height}"
origin = NSMakePoint(width,height)
puts "class of origin is #{origin.class}"
@label.setFrameOrigin(origin)
end
class of label is NSTextField
width is 75.0 heght is 77.5
class of origin is CGPoint
2012-12-09 18:33:13.525 two[3836:503]
/Users/davidkramf/Library/Developer/Xcode/DerivedData/two-gdovgltwrnzjfbfpizcbgrudvizf/Build/Products/Debug/two.app/Contents/Resources/MyController.rb:34:in
`initLabel': undefined method `￯﾿ﾼ￯﾿ﾼ' for
# (NoMethodError)
from
/Users/davidkramf/Library/Developer/Xcode/DerivedData/two-gdovgltwrnzjfbfpizcbgrudvizf/Build/Products/Debug/two.app/Contents/Resources/MyController.rb:15:in
`initialize'
from /Users/davidkramf/Library/Developer___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] NSPoint and CGPoint issue
Hi Min,
This error message was produced by run environment and not by my code. I don't
do (knowingly ) anything with encoded text. Usually I get comprehendible error
messages when my code crashes.
Thanks, David
On Dec 10, 2012, at 2:10 AM, Min Soo Kim wrote:
> Hello David,
>
> In your error message it says
>> undefined method `￯﾿ﾼ￯﾿ﾼ'
>
> Why are you getting `￯﾿ﾼ￯﾿ﾼ' instead of 'setFrameOrigin'?
> Do you have some foreign encoded text somewhere?
>
> Min Soo Kim
>
>
> On Dec 10, 2012, at 1:41 AM, david kramf wrote:
>
>> Hello,
>> I am trying to create an NSPoint object so I can call setFrameOrigin but I
>> get in response a CGPoint object . When I pass the CGPoint to setFrameOrigin
>> , it crashes. How do I make NSMakePoint making an NSPoint object and not a
>> CGPoint object.
>> Thank you for your help,
>> David Kramf
>>
>> def initLabel(h)
>> @label = NSTextField.alloc.initWithFrame(CGRectMake(0,0,250, 45))
>> @label.setStringValue(h)
>> @label.drawsBackground = false
>> @label.bezeled = false
>> @label.font = NSFont.fontWithName("Arial", size:45.0)
>> @label.editable = false
>> puts "class of label is #{@label.class}"
>> width =
>> (@window.contentView.frameSize.width/2.0)-(@label.frameSize.width/2.0)
>> height =
>> (@window.contentView.frameSize.height/2.0)-(@label.frameSize.height/2.0)
>> puts "width is #{width} heght is #{height}"
>> origin = NSMakePoint(width,height)
>> puts "class of origin is #{origin.class}"
>> @label.setFrameOrigin(origin)
>> end
>>
>> class of label is NSTextField
>> width is 75.0 heght is 77.5
>> class of origin is CGPoint
>> 2012-12-09 18:33:13.525 two[3836:503]
>> /Users/davidkramf/Library/Developer/Xcode/DerivedData/two-gdovgltwrnzjfbfpizcbgrudvizf/Build/Products/Debug/two.app/Contents/Resources/MyController.rb:34:in
>> `initLabel': undefined method `￯﾿ﾼ￯﾿ﾼ' for
>> # (NoMethodError)
>> from
>> /Users/davidkramf/Library/Developer/Xcode/DerivedData/two-gdovgltwrnzjfbfpizcbgrudvizf/Build/Products/Debug/two.app/Contents/Resources/MyController.rb:15:in
>> `initialize'
>> from /Users/davidkramf/Library/Developer
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> http://lists.macosforge.org/mailman/listinfo/macruby-devel
>
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] NSPoint and CGPoint issue
Braxton,
Many Thanks for your advice . I will try to cast from CGPoint to NSPoint .
Nim,
I will try your code . In addition to the fact that we probably run on a
different OS or MacRuby version , the other difference is that you set the
width and height to full constants . The division operations that you commented
out produced fractions.
Thank You All,David
On Dec 10, 2012, at 11:35 AM, Braxton Sherouse wrote:
> I can't speak to the encoding issues, but I can attest to crashing
> issues with incorrectly assuming the compatibility of NSPoint and
> CGPoint.
>
> It depends what version of Mac OS you're on whether NSPoint can safely
> be cast as a CGPoint. In older versions of Mac OS, NSPoint used float
> for its members (32-bit) -- later, it switched to CGFloat (64-bit).
>
>
> There are functions in the Foundation framework that you can use, if
> you want to be safe: NSPointFromCGPoint and NSPointToCGPoint:
>
> https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_Functions/Reference/reference.html#//apple_ref/c/func/NSPointFromCGPoint
>
>
> Also, check out the documentation here, on NSPoint, which gives the
> version history:
>
> https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_DataTypes/Reference/reference.html#//apple_ref/doc/uid/TP40003794
>
> Best,
> -braxton
>
> On Mon, Dec 10, 2012 at 9:11 AM, Min Soo Kim wrote:
>> Hi David,
>>
>> I ran the following
>>
>> framework 'cocoa'
>> def initLabel(h)
>> @label = NSTextField.alloc.initWithFrame(CGRectMake(0,0,250, 45))
>> @label.setStringValue(h)
>> @label.drawsBackground = false
>> @label.bezeled = false
>> @label.font = NSFont.fontWithName("Arial", size:45.0)
>> @label.editable = false
>> puts "class of label is #{@label.class}"
>> # width =
>> (@window.contentView.frameSize.width/2.0)-(@label.frameSize.width/2.0)
>> # height =
>> (@window.contentView.frameSize.height/2.0)-(@label.frameSize.height/2.0)
>> width=100.0
>> height=200.0
>> puts "width is #{width} heght is #{height}"
>> origin = NSMakePoint(width,height)
>> puts "class of origin is #{origin.class}"
>> @label.setFrameOrigin(origin)
>> puts @label.frame.origin
>> end
>>
>> initLabel("Hello")
>>
>>
>> I got the following output.
>>
>> class of label is NSTextField
>> width is 100.0 heght is 200.0
>> class of origin is CGPoint
>> #class of origin is CGPoint
>> #
>>
>> It seem be to working for me. I think NSPoint and CGPoint can be mix used.
>> (Free ride)
>> I think the problem is in the `￯﾿ﾼ￯﾿ﾼ' whatever that is
>>
>> Min Soo Kim
>>
>> On Dec 10, 2012, at 3:37 PM, david kramf wrote:
>>
>> Hi Min,
>> This error message was produced by run environment and not by my code. I
>> don't do (knowingly ) anything with encoded text. Usually I get
>> comprehendible error messages when my code crashes.
>> Thanks, David
>>
>> On Dec 10, 2012, at 2:10 AM, Min Soo Kim wrote:
>>
>> Hello David,
>>
>> In your error message it says
>>
>> undefined method `￯﾿ﾼ￯﾿ﾼ'
>>
>>
>> Why are you getting `￯﾿ﾼ￯﾿ﾼ' instead of 'setFrameOrigin'?
>> Do you have some foreign encoded text somewhere?
>>
>> Min Soo Kim
>>
>>
>> On Dec 10, 2012, at 1:41 AM, david kramf wrote:
>>
>> Hello,
>> I am trying to create an NSPoint object so I can call setFrameOrigin but I
>> get in response a CGPoint object . When I pass the CGPoint to setFrameOrigin
>> , it crashes. How do I make NSMakePoint making an NSPoint object and not a
>> CGPoint object.
>> Thank you for your help,
>> David Kramf
>>
>> def initLabel(h)
>>@label = NSTextField.alloc.initWithFrame(CGRectMake(0,0,250, 45))
>>@label.setStringValue(h)
>>@label.drawsBackground = false
>>@label.bezeled = false
>>@label.font = NSFont.fontWithName("Arial", size:45.0)
>>@label.editable = false
>>puts "class of label is #{@label.class}"
>>width =
>> (@window.contentView.frameSize.width/2.0)-(@label.frameSize.width/2.0)
>>height =
>> (@window.contentView.frameSize.height/2.0)-(@label.frameSize.height/2.0)
>>puts "
Re: [MacRuby-devel] Problem with a window controller
Hi Jean-Denis 1. Thank you for your advice about awakeFromNib and InitWithCoder. 2. "That is a bonus you ..". This is not a bonus. This is Ruby. If you define a Ruby class you expect that any object will get instantiated through "initialize". I have a feeling that all who responded to me on the forum started their programming track from Objective-C and proceeded to Ruby. I am coming from the opposite direction. I come from Ruby and wants to deal with Objective-C as little as possible. So I expect MacRuby to be as much "Ruby" as it is possible. Many Thanks, David On Dec 10, 2012, at 11:27 AM, Jean-Denis MUYS wrote: > > On 7 déc. 2012, at 19:48:39, david kramf > wrote: >> >> Message: 1 >> Date: Fri, 7 Dec 2012 19:48:39 +0200 >> From: david kramf >> To: "MacRuby development discussions." >> >> Subject: Re: [MacRuby-devel] Problem with a window controller >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi Bob, >> "As you become more familiar with IB, you will probably do more >> initialization of objects in IB and less in MacRuby. Nib file expansion >> instantiates objects and then makes calls to initialize the objects using >> the same methods that you are using to initialize objects in MacRuby. >> Actually, in a large application, it would difficult to hook up all of the >> outlets without using IB." >> >> From my modest acquaintance with MacRuby that is not exactly the case since >> when the NIB instantiates an NSWindowController object , it does not call >> "initialize" > > Cocoa, whether accessed from Ruby, Python, Objective-C or any language, uses > the Cocoa initialization patterns. It's unrealistic to assume the framework > patterns to change when you change the client language. > >> ,as defined in Ruby , but calls "awakeFromNib". > > It does, but caveat: awakeFromNib is *not* an initialization method, even > though it is often used as such. I was bitten before. The correct > initialization method to use for Nib files is initWithCoder:. What's the > difference, says you (and me)? Behold: awakeFromNib can be called several > times in the lifetime of an object. This is no big deals for most > initializations, but becomes a major issue in others. In my case, I was > registering for notifications in awakeFromNib. Since I was registered several > times, I got the notifications multiple times, and since I only unsubscribed > once in dealloc, my app would crash. > > Many cases when awakeFromNib is called more than once are programming errors, > but not all. And since there *is* a real initializer, I recommend using it. > > So in that case why is there an awakeFromNib method at all? It is because at > initWithCoder: time, IB outlets are not yet loaded and are all nil. So > awakeFromNib is meant to for initialization code that configures outlet. > > So here is a recipe: > > 1- Does you initialization code requires IB outlets to be alive? If not, > override initWithCoder: > 2- If so, put it in awakeFromNib > 3- Does that awakeFromNib initialization code need to be called once only? if > so, make it conditional on it having been already be called. > 4- Optional: assert that awakeFromNib was not called before, and if that > assert fires, investigate whether the case is legitimate or due to a bug in > your code. > >> Only when you instantiate your controller from the code itself , you get >> your "initialize"method called. > > That is a bonus you just can be happy to have due to the deep integration of > MacRuby in the Objective-C runtime system. There is no reason to assume that > bonus to expand to objects created by the framework. > >> I know I still have a lot of practicing on IB. What I find disturbing ,is >> that when I do something with IB I cannot see the code created to >> accommodate my actions ( maybe because I only work in MacRuby and not >> Objective-C?). > > No. This is simply because there **no code created**. At all. IB does't > generate code. And lest I forget: Interface Builder is not a code generation > tool. IB instantiates and populates objects, and then serializes them to > disk. Those objects are then simply deserialized from disk in your app. At no > point ever is any code generated. Therefore, there is no "code created to > accommodate your actions" for you to see. Even in Objective-C. > > Best regards, > > Jean-Denis > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] NSPoint and CGPoint issue
Hi Min,
You are correct. The code doesn't crash now. I guess the reason is that Cocoa
succeeded in internally casting this CGPoint to NSPoint.
Thanks , David
On Dec 10, 2012, at 11:11 AM, Min Soo Kim wrote:
> Hi David,
>
> I ran the following
>
> framework 'cocoa'
> def initLabel(h)
>@label = NSTextField.alloc.initWithFrame(CGRectMake(0,0,250, 45))
>@label.setStringValue(h)
>@label.drawsBackground = false
>@label.bezeled = false
>@label.font = NSFont.fontWithName("Arial", size:45.0)
>@label.editable = false
>puts "class of label is #{@label.class}"
># width =
> (@window.contentView.frameSize.width/2.0)-(@label.frameSize.width/2.0)
># height =
> (@window.contentView.frameSize.height/2.0)-(@label.frameSize.height/2.0)
>width=100.0
>height=200.0
>puts "width is #{width} heght is #{height}"
>origin = NSMakePoint(width,height)
>puts "class of origin is #{origin.class}"
>@label.setFrameOrigin(origin)
>puts @label.frame.origin
> end
>
> initLabel("Hello")
>
>
> I got the following output.
>
> class of label is NSTextField
> width is 100.0 heght is 200.0
> class of origin is CGPoint
> #class of origin is CGPoint
> #
>
> It seem be to working for me. I think NSPoint and CGPoint can be mix used.
> (Free ride)
> I think the problem is in the `￯﾿ﾼ￯﾿ﾼ' whatever that is
>
> Min Soo Kim
>
> On Dec 10, 2012, at 3:37 PM, david kramf wrote:
>
>> Hi Min,
>> This error message was produced by run environment and not by my code. I
>> don't do (knowingly ) anything with encoded text. Usually I get
>> comprehendible error messages when my code crashes.
>> Thanks, David
>>
>> On Dec 10, 2012, at 2:10 AM, Min Soo Kim wrote:
>>
>>> Hello David,
>>>
>>> In your error message it says
>>>> undefined method `￯﾿ﾼ￯﾿ﾼ'
>>>
>>> Why are you getting `￯﾿ﾼ￯﾿ﾼ' instead of 'setFrameOrigin'?
>>> Do you have some foreign encoded text somewhere?
>>>
>>> Min Soo Kim
>>>
>>>
>>> On Dec 10, 2012, at 1:41 AM, david kramf wrote:
>>>
>>>> Hello,
>>>> I am trying to create an NSPoint object so I can call setFrameOrigin but I
>>>> get in response a CGPoint object . When I pass the CGPoint to
>>>> setFrameOrigin , it crashes. How do I make NSMakePoint making an NSPoint
>>>> object and not a CGPoint object.
>>>> Thank you for your help,
>>>> David Kramf
>>>>
>>>> def initLabel(h)
>>>> @label = NSTextField.alloc.initWithFrame(CGRectMake(0,0,250, 45))
>>>> @label.setStringValue(h)
>>>> @label.drawsBackground = false
>>>> @label.bezeled = false
>>>> @label.font = NSFont.fontWithName("Arial", size:45.0)
>>>> @label.editable = false
>>>> puts "class of label is #{@label.class}"
>>>> width =
>>>> (@window.contentView.frameSize.width/2.0)-(@label.frameSize.width/2.0)
>>>> height =
>>>> (@window.contentView.frameSize.height/2.0)-(@label.frameSize.height/2.0)
>>>> puts "width is #{width} heght is #{height}"
>>>> origin = NSMakePoint(width,height)
>>>> puts "class of origin is #{origin.class}"
>>>> @label.setFrameOrigin(origin)
>>>> end
>>>>
>>>> class of label is NSTextField
>>>> width is 75.0 heght is 77.5
>>>> class of origin is CGPoint
>>>> 2012-12-09 18:33:13.525 two[3836:503]
>>>> /Users/davidkramf/Library/Developer/Xcode/DerivedData/two-gdovgltwrnzjfbfpizcbgrudvizf/Build/Products/Debug/two.app/Contents/Resources/MyController.rb:34:in
>>>> `initLabel': undefined method `￯﾿ﾼ￯﾿ﾼ' for
>>>> # (NoMethodError)
>>>>from
>>>> /Users/davidkramf/Library/Developer/Xcode/DerivedData/two-gdovgltwrnzjfbfpizcbgrudvizf/Build/Products/Debug/two.app/Contents/Resources/MyController.rb:15:in
>>>> `initialize'
>>>>from /Users/davidkramf/Library/Developer
>>>> ___
>>>> MacRuby-devel mailing list
>>>> [email protected]
>>>> http://lists.macosforge.org/mailman/listinfo/macruby-devel
>>>
>>> ___
>>> MacRuby-devel mailing list
>>> [email protected]
>>> http://lists.macosforge.org/mailman/listinfo/macruby-devel
>>
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> http://lists.macosforge.org/mailman/listinfo/macruby-devel
>
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] NSPoint and CGPoint issue
Hi Braxton
Cocoa seems to be a bit schizophrenic when handling NSPoint and CGPoint. I
tried your advice and that what I got. Certainly one should be careful dealing
with these classes !!
Thanks, David
puts "width is #{width} heght is #{height}"
origin = NSPointFromCGPoint(NSMakePoint(width,height))
puts "class of origin is #{origin.class} "
width is 160.5 heght is 184.0
class of origin is CGPoint ()
puts
On Dec 10, 2012, at 11:35 AM, Braxton Sherouse wrote:
> I can't speak to the encoding issues, but I can attest to crashing
> issues with incorrectly assuming the compatibility of NSPoint and
> CGPoint.
>
> It depends what version of Mac OS you're on whether NSPoint can safely
> be cast as a CGPoint. In older versions of Mac OS, NSPoint used float
> for its members (32-bit) -- later, it switched to CGFloat (64-bit).
>
>
> There are functions in the Foundation framework that you can use, if
> you want to be safe: NSPointFromCGPoint and NSPointToCGPoint:
>
> https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_Functions/Reference/reference.html#//apple_ref/c/func/NSPointFromCGPoint
>
>
> Also, check out the documentation here, on NSPoint, which gives the
> version history:
>
> https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_DataTypes/Reference/reference.html#//apple_ref/doc/uid/TP40003794
>
> Best,
> -braxton
>
> On Mon, Dec 10, 2012 at 9:11 AM, Min Soo Kim wrote:
>> Hi David,
>>
>> I ran the following
>>
>> framework 'cocoa'
>> def initLabel(h)
>> @label = NSTextField.alloc.initWithFrame(CGRectMake(0,0,250, 45))
>> @label.setStringValue(h)
>> @label.drawsBackground = false
>> @label.bezeled = false
>> @label.font = NSFont.fontWithName("Arial", size:45.0)
>> @label.editable = false
>> puts "class of label is #{@label.class}"
>> # width =
>> (@window.contentView.frameSize.width/2.0)-(@label.frameSize.width/2.0)
>> # height =
>> (@window.contentView.frameSize.height/2.0)-(@label.frameSize.height/2.0)
>> width=100.0
>> height=200.0
>> puts "width is #{width} heght is #{height}"
>> origin = NSMakePoint(width,height)
>> puts "class of origin is #{origin.class}"
>> @label.setFrameOrigin(origin)
>> puts @label.frame.origin
>> end
>>
>> initLabel("Hello")
>>
>>
>> I got the following output.
>>
>> class of label is NSTextField
>> width is 100.0 heght is 200.0
>> class of origin is CGPoint
>> #class of origin is CGPoint
>> #
>>
>> It seem be to working for me. I think NSPoint and CGPoint can be mix used.
>> (Free ride)
>> I think the problem is in the `￯﾿ﾼ￯﾿ﾼ' whatever that is
>>
>> Min Soo Kim
>>
>> On Dec 10, 2012, at 3:37 PM, david kramf wrote:
>>
>> Hi Min,
>> This error message was produced by run environment and not by my code. I
>> don't do (knowingly ) anything with encoded text. Usually I get
>> comprehendible error messages when my code crashes.
>> Thanks, David
>>
>> On Dec 10, 2012, at 2:10 AM, Min Soo Kim wrote:
>>
>> Hello David,
>>
>> In your error message it says
>>
>> undefined method `￯﾿ﾼ￯﾿ﾼ'
>>
>>
>> Why are you getting `￯﾿ﾼ￯﾿ﾼ' instead of 'setFrameOrigin'?
>> Do you have some foreign encoded text somewhere?
>>
>> Min Soo Kim
>>
>>
>> On Dec 10, 2012, at 1:41 AM, david kramf wrote:
>>
>> Hello,
>> I am trying to create an NSPoint object so I can call setFrameOrigin but I
>> get in response a CGPoint object . When I pass the CGPoint to setFrameOrigin
>> , it crashes. How do I make NSMakePoint making an NSPoint object and not a
>> CGPoint object.
>> Thank you for your help,
>> David Kramf
>>
>> def initLabel(h)
>>@label = NSTextField.alloc.initWithFrame(CGRectMake(0,0,250, 45))
>>@label.setStringValue(h)
>>@label.drawsBackground = false
>>@label.bezeled = false
>>@label.font = NSFont.fontWithName("Arial", size:45.0)
>>@label.editable = false
>>puts "class of label is #{@label.class}"
>>width =
>> (@window.contentView.frameSize.width/2.0)-(@label.frameSize.width/2.0)
>>height =
>> (@window.contentView.frameSize.height/
[MacRuby-devel] Another Cocoa issue
Hello,
In the following code I analyze a textView , split it to lines , try to build a
Model object from each line , and if build failed I want to color that line in
red. I use setColor:range , but once called this method colors my entire view (
also previous lines ) in red. Can someone tell me what I do wrong?
Thanks, David Kramf
def textView(textView,doCommandBySelector:sel)
puts "#{sel.to_s}"
return false if sel.to_s != "insertNewline:"
puts " in doCommandBySelector selector is #{sel}"
@newline = true
enum = @textView.string.lines(seperaotr=$/)
@location = 0
enum.each_with_index do |l,i|
puts "location is #{@location}"
words = l.split
line = Line.new(words[0],words[1])
@lines[i] = line if @lines[i] != line
red = NSColor.redColor
range = NSMakeRange(@location,l.length)
puts "#{range.location}-#{range.length}"
@textView.setTextColor(red,range) if line.rule == nil
@location = @location + l.length
end
false
end
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macruby-devel
[MacRuby-devel] Mac App Store Submission question
Hi all, in the Mac App Store Submission github page one finds the following paragraph "An example might be something like this:--compile --embed --gem httparty --gem json_pure --codesign "3rd Party Mac Developer Application: Daniel Westendorf". This example will compile your source into .rbo files (instead of .rb files, don't let anyone steal your code!)" What are those .rbo files ? My application is heavily dependent on metaprogramming. Will it work as a compiled .rbo file? Thanks, David Kramf ___ MacRuby-devel mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macruby-devel
[MacRuby-devel] Fwd: OS X10.9 & MacRuby's future...
Is RubyMotion a full Ruby. Does it support reflection and metaprograming? Thanks, David Kramf Begin forwarded message: > From: Francis Chong > Subject: Re: [MacRuby-devel] OS X10.9 & MacRuby's future... > Date: May 17, 2013 2:15:40 PM GMT+03:00 > To: "MacRuby development discussions." > Reply-To: "MacRuby development discussions." > > > While I'm really happy about OS X support on RubyMotion, it is not a > replacement for MacRuby. > > IMHO MacRuby is far superior: > > It offer JIT compiler, you develop orders of magnitude faster as you dont > need clean and rebuild every time. > > You have full ruby compatibility, load standard library as you wish. > > It loads gems and framework dynamically like what you would expected from > regular ruby. > > You don't have to write new gems, or rewrite them. Many gems just work, even > native ones could work. > > You can use regular technique for meta programming, and generally you don't > enter a uncanny valley between dynamic language and static build system. > > Some of these limitations are inherited from RubyMotion due to iOS > restriction, I don't see them going away anytime soon. > > That said, RubyMotion team is the ones who know most of MacRuby, and their > direction is not like MacRuby in past. If you are going to develop Mac app, > your best choice is probably go RubyMotion, or just use Objective-C. > — > Sent from Mailbox for iPhone > > > On Fri, May 17, 2013 at 7:02 AM, Carolyn Ann Grant > wrote: > > I've changed my mind. :-) > > I translated part of a project into Obj-C, and it just wasn't the same. I > *like* the Ruby language, and while MacRuby has its foibles, it's still very > good. > > Here's my reasoning: Apple isn't going to do a consumer release of 10.9 any > time soon - according to the press reports I've read, it's being tested by > them, but the first developer release isn't expected until WWDC in June. > There's going to be a round of beta's, release candidates and so on, as per > normal, and then it'll have the consumer release, maybe by October, perhaps > November. I'm certainly not expecting anything as early as September! > > Now, if I keep up with using MacRuby, I then have the option of either > expanding my knowledge of MacRuby internals in meantime *and* be in a > position to use RubyMotion. If I switch to Obj-C now, switching to RubyMotion > or a newer MacRuby later will be either more work or not worth it. Meanwhile, > MacRuby works on Mountain Lion and while, as I said, it has it foibles, it's > still a lot more pleasurable writing code in Ruby than it is in Obj-C! > > I think that makes sense? > > Thanks again for the conversation! :-) > Carolyn > > > On May 16, 2013, at 3:05 PM, Carolyn Ann Grant > wrote: > >> Thanks, Mark! >> >> Yeah, I know the price is more than reasonable, Mark, it's just that right >> now, we're not in a position to afford much of anything. Without getting too >> personal, we're still digging out from the Great Recession, which hit my >> family pretty hard. (As they say in DC, "mistakes were made", and I seem to >> have gone out of my way to make sure they were doozies!) I agree that >> HipByte is likely to work toward their own success; I'll definitely be >> looking at them when I can. >> >> I think at this point, I have to stick to Objective-C, as much as I really >> don't want to. Ruby is just so much better! As for why, I need to have >> confidence that I'm not investing a large amount of time and effort into >> something that I'll have to abandon when OS X 10.9 comes out. I've chased >> more than a few promising technologies, only to see them wither on the vine, >> so to speak. I've made such a habit of it, that I was beginning to think >> that if I was interested in something, it was likely on its way out! At this >> point, I simply can't afford to do that again. So while I'm not delighted to >> be writing code in Obj-C, at least I know it's going to be around for a few >> years. And I don't have to try and figure out what I did wrong with bridge >> support files, etc. >> >> I am disappointed, and I do wish I had the time and knowledge to further >> MacRuby, but I have to prioritize what gets my attention and what I'd like >> to do but can't. >> >> Thank you, all! :-) >> >> /Carolyn >> >> On May 16, 2013, at 2:38 PM, Mark Villacampa wrote: &g
Re: [MacRuby-devel] OS X10.9 & MacRuby's future...
Francis, Ruby is very well defined language with a well defined standard. David On May 17, 2013, at 3:31 PM, Francis Chong wrote: > @david depends on your definition on full ruby. I would say standard library > is part is full ruby, where RubyMotion deliberately remove part of them > > @stephen thanks for the update, I should have tested that myself > — > Sent from Mailbox for iPhone > > > On Fri, May 17, 2013 at 8:26 PM, stephen horne wrote: > > From what I understand, the only thing missing in Rubymotion is eval() > > There's an article by Clay Allsop about meta-programming in Rubymotion at > http://clayallsopp.com/posts/rubymotion-metaprogramming/ > > I tested to see if eval() works in desktop Rubymotion apps (I read somewhere > that the reason it's not included is due to Apple restrictions on run-time > code evaluation in iOS, rather than a limit of Rubymotion), but it doesn't. > > fb > >> >> david kramf 17/05/2013 13:19 >> >> Is RubyMotion a full Ruby. Does it support reflection and metaprograming? >> Thanks, David Kramf >> >> >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> https://lists.macosforge.org/mailman/listinfo/macruby-devel >> >> Francis Chong17/05/2013 12:15 >> While I'm really happy about OS X support on RubyMotion, it is not a >> replacement for MacRuby. >> >> IMHO MacRuby is far superior: >> >> It offer JIT compiler, you develop orders of magnitude faster as you dont >> need clean and rebuild every time. >> >> You have full ruby compatibility, load standard library as you wish. >> >> It loads gems and framework dynamically like what you would expected from >> regular ruby. >> >> You don't have to write new gems, or rewrite them. Many gems just work, even >> native ones could work. >> >> You can use regular technique for meta programming, and generally you don't >> enter a uncanny valley between dynamic language and static build system. >> >> Some of these limitations are inherited from RubyMotion due to iOS >> restriction, I don't see them going away anytime soon. >> >> That said, RubyMotion team is the ones who know most of MacRuby, and their >> direction is not like MacRuby in past. If you are going to develop Mac app, >> your best choice is probably go RubyMotion, or just use Objective-C. >> — >> Sent from Mailbox for iPhone >> >> >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> https://lists.macosforge.org/mailman/listinfo/macruby-devel > > ___ > MacRuby-devel mailing list > [email protected] > https://lists.macosforge.org/mailman/listinfo/macruby-devel ___ MacRuby-devel mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] OS X10.9 & MacRuby's future...
Francis, I know nothing about RubyMotion but if I understand correctly it uses a compiler and not an interpreter. So I doubt if it can implement Metaprogramming and Reflection. If it does not , then it is not a Ruby . It might be an excellent language but not Ruby. To the best of my understanding Ruby is a very well defined language supported by a large community and works in what seems to me ( I know Ruby for no more than a year) in a very orderly way. David On May 19, 2013, at 3:52 AM, Francis Chong wrote: > David > > Yes? I got an impression it's just matz implementation. BTW, do RubyMotion > even run ruby spec? > — > Sent from Mailbox for iPhone > > > On Sun, May 19, 2013 at 5:04 AM, david kramf wrote: > > Francis, > Ruby is very well defined language with a well defined standard. > David > > On May 17, 2013, at 3:31 PM, Francis Chong wrote: > >> @david depends on your definition on full ruby. I would say standard library >> is part is full ruby, where RubyMotion deliberately remove part of them >> >> @stephen thanks for the update, I should have tested that myself >> — >> Sent from Mailbox for iPhone >> >> >> On Fri, May 17, 2013 at 8:26 PM, stephen horne wrote: >> >> From what I understand, the only thing missing in Rubymotion is eval() >> >> There's an article by Clay Allsop about meta-programming in Rubymotion at >> http://clayallsopp.com/posts/rubymotion-metaprogramming/ >> >> I tested to see if eval() works in desktop Rubymotion apps (I read somewhere >> that the reason it's not included is due to Apple restrictions on run-time >> code evaluation in iOS, rather than a limit of Rubymotion), but it doesn't. >> >> fb >> >>> >>> david kramf 17/05/2013 13:19 >>> >>> Is RubyMotion a full Ruby. Does it support reflection and metaprograming? >>> Thanks, David Kramf >>> >>> >>> >>> ___ >>> MacRuby-devel mailing list >>> [email protected] >>> https://lists.macosforge.org/mailman/listinfo/macruby-devel >>> >>> Francis Chong 17/05/2013 12:15 >>> While I'm really happy about OS X support on RubyMotion, it is not a >>> replacement for MacRuby. >>> >>> IMHO MacRuby is far superior: >>> >>> It offer JIT compiler, you develop orders of magnitude faster as you dont >>> need clean and rebuild every time. >>> >>> You have full ruby compatibility, load standard library as you wish. >>> >>> It loads gems and framework dynamically like what you would expected from >>> regular ruby. >>> >>> You don't have to write new gems, or rewrite them. Many gems just work, >>> even native ones could work. >>> >>> You can use regular technique for meta programming, and generally you don't >>> enter a uncanny valley between dynamic language and static build system. >>> >>> Some of these limitations are inherited from RubyMotion due to iOS >>> restriction, I don't see them going away anytime soon. >>> >>> That said, RubyMotion team is the ones who know most of MacRuby, and their >>> direction is not like MacRuby in past. If you are going to develop Mac app, >>> your best choice is probably go RubyMotion, or just use Objective-C. >>> — >>> Sent from Mailbox for iPhone >>> >>> >>> >>> ___ >>> MacRuby-devel mailing list >>> [email protected] >>> https://lists.macosforge.org/mailman/listinfo/macruby-devel >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> https://lists.macosforge.org/mailman/listinfo/macruby-devel > > > ___ > MacRuby-devel mailing list > [email protected] > https://lists.macosforge.org/mailman/listinfo/macruby-devel ___ MacRuby-devel mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] OS X10.9 & MacRuby's future...
Hi Ben, I am writing an OS X project that relies on Metaprogramming and Reflection. Does not seem like RubMotion is an option for me. All the best, David On May 16, 2013, at 10:05 PM, Carolyn Ann Grant wrote: > Thanks, Mark! > > Yeah, I know the price is more than reasonable, Mark, it's just that right > now, we're not in a position to afford much of anything. Without getting too > personal, we're still digging out from the Great Recession, which hit my > family pretty hard. (As they say in DC, "mistakes were made", and I seem to > have gone out of my way to make sure they were doozies!) I agree that HipByte > is likely to work toward their own success; I'll definitely be looking at > them when I can. > > I think at this point, I have to stick to Objective-C, as much as I really > don't want to. Ruby is just so much better! As for why, I need to have > confidence that I'm not investing a large amount of time and effort into > something that I'll have to abandon when OS X 10.9 comes out. I've chased > more than a few promising technologies, only to see them wither on the vine, > so to speak. I've made such a habit of it, that I was beginning to think that > if I was interested in something, it was likely on its way out! At this > point, I simply can't afford to do that again. So while I'm not delighted to > be writing code in Obj-C, at least I know it's going to be around for a few > years. And I don't have to try and figure out what I did wrong with bridge > support files, etc. > > I am disappointed, and I do wish I had the time and knowledge to further > MacRuby, but I have to prioritize what gets my attention and what I'd like to > do but can't. > > Thank you, all! :-) > > /Carolyn > > On May 16, 2013, at 2:38 PM, Mark Villacampa wrote: > >> I'm a longtime RubyMotion user, and MacRuby user before that. I want to >> share my view as to what is the current status of MacRuby and what can >> happen in the future. >> >> The momentum around MacRuby has been inexistent for almost a year and a >> half. That is, since Laurent Sansonetti (the original creator of MacRuby) >> left Apple, and that left the project without maintainers who were being >> paid to work on it. Only Watson and a couple other maintainers have been >> doing maintenance work and fixing a couple of bugs. >> >> Since nobody is being paid to maintain it, and (AFAIK) there is no >> company/individual whose main/critical systems depended on MacRuby, nobody >> has taken over the project. This is pretty much a chicken-egg situation. >> >> That said, a year ago, Laurent launched RubyMotion, a product based on >> MacRuby which introduces many new features, such as an ARC based memory >> model, and iOS support (dropping OSX support). Just a few days ago, in the >> first anniversary of RubyMotion, they introduced OSX support. >> >> Rubymotion is not open source, and the license costs 200$, plus an annual >> renewal fee of 99$. Two reasons that people sometimes argue for not >> investing in RM are: >> >> - "It's closed source, it might disappear at any moment": Actually, >> RubyMotion is probably more likely to stay in the long term than MacRuby was >> at the beginning. Despite Apple being a huge company, MacRuby was kind of an >> experiment that they could kill at any moment. For HipByte (the company >> behind Rubymotion), Rubymotion is its main product and the one that pays its >> employees. They are way more interested in watching RM succeed than Apple >> was in watching MacRuby succeed. >> >> - "It's too expensive": for playing around or releasing a pet project or >> free app that is not one of your ways of income, that might be the case. >> However, for a company or individual that wants to develop a product from >> which they hope to get some revenue, that price is ridiculous. I've seen PHP >> libraries for creating web forms more expensive than RubyMotion (nothing >> against those libraries). We're talking about a static compiler and a whole >> toolchain for developing iOS apps. If you're a student and want to play >> around with RubyMotion, there is a student discount available (send them an >> email for more information). >> >> So my conclusion is: If you want to develop OSX applications and you liked >> MacRuby, invest in getting a RubyMotion license, you probably won't be >> disappointed. >> >> Mark. >> >> On Thursday, May 16, 2013 at 8:01 PM, Christopher S Martin wrote: >> >>> They recently added support for OS X to rubymotion: >>> http://blog.rubymotion.com/post/49943751398/rubymotion-goes-2-0-and-gets-os-x-support-templates >>> That said, since rubymotion is (I believe) based off of macruby with some >>> additions specifically around static compilation of apps, I don't know if >>> the issues around GC/ARC would be any better in rubymotion on OS X, as I've >>> only used it for iOS. >>> >>> >>> On Thu, May 16, 2013 at 10:56 AM, Jeff Dyck wrote: Just wanted to ad
Re: [MacRuby-devel] OS X10.9 & MacRuby's future...
Thank you. I will definitely look into Objective -C and RubyMotion metaprogramming and reflection abilities. David On May 19, 2013, at 5:18 PM, Colin Thomas Arnold Gray wrote: > Just because RubyMotion is compiled doesn't mean it can't have > metaprogramming and reflection abilities. These features are not orthogonal > to each other. It is true that most compiled languages DON'T have these > features, but objective-c definitely DOES. > > For some light reading, check out (if you're curious) the Objective-C runtime > functions. It's easy to see how RubyMotion can take advantages of that > system. > > On the topic of "if it doesn't implement feature ‘X’ then its not Ruby": > There is not just one implementation of Ruby. The standard library and syntax > are defined by the MRI implementation, but JRuby, IronRuby, Maglev and > Rubinius all introduce different takes (and then there's mruby, but it's not > fair to compare that one). > > There is an oft-quoted Ruby-ism that applies here: "If it looks like Ruby, > and walks like Ruby, it's Ruby" ;-) > > #colinta > > ___ > MacRuby-devel mailing list > [email protected] > https://lists.macosforge.org/mailman/listinfo/macruby-devel ___ MacRuby-devel mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] Screen Saver Preferences
Craig, MacRuby ceased to be supported. They switched to a fee based product called RubyMotion which have the additional advantage of being able to run on an iPhone. I don't think it is a good idea to start using MacRuby now . All the Best, David Kramf On Oct 11, 2013, at 1:21 AM, Craig Read wrote: > Hi, > > I've just started using MacRuby, and I've had limited exposure to Objective-C > so my questions are going to be fairly 'newbyish'. > > Anyway, I'm writing a screen saver using MacRuby on Snow Leopard with XCode > 3.2.6 (on a fairly old Intel MacBook). I've got the screen saver working, > but I'm having difficulty getting my head around what's required to create a > preferences pane for it. I have found some examples (in Objective-C) of > using nib files for the preferences UI, but they seem to be for earlier > versions of XCode. > > To add to the complexity (or reduce it, I'm not sure yet), I'd much rather > create the preferences window programmatically. Any help / guidance / lmgtfy > links would be appreciated. > > Also, is there a searchable archive of this list? > > Cheers, > > Craig. > -- > Craig Read > > @Catharz > https://github.com/Catharz > http://stackoverflow.com/users/158893/catharz > ___ > MacRuby-devel mailing list > [email protected] > https://lists.macosforge.org/mailman/listinfo/macruby-devel ___ MacRuby-devel mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] MacRuby on Mavericks
Hi Guys, I have a project that written in MacRuby but I can split the code to logic in Ruby and the UI which I can translate to Objective-C . So My problem is how to run a pure Ruby from my app. I was thinking of opening an AppleScript terminal and running IRB there . Has anyone tried it? Do you have a better easier idea ? Is it doable ?? Thnks, David Kramf On Nov 7, 2013, at 4:00 AM, Robert Carl Rice wrote: > Hi Rob, > > Thanks for looking into this. > > The iTunes Store has notified me that my current binaries will be removed > from the store for not being compatible with the current OS release. Recoding > for either RubyMotion or Objective-C will be a big job and I'm not looking > forward to it. > > PS; the new Xcode renews the warning that Xcode 5 is scheduled to be the last > Xcode version to support GC, but I don't see anything that ties version 6 to > a scheduled OS update. > > Bob Rice > > > On Nov 6, 2013, at 4:27 PM, rob ista wrote: > >> Hi All, >> >> indeed the GC is still there on Mavericks and needs to be ‘required’ in >> Xcode while disabling ARC to avoid a conflict (thanks Steve). So far so >> good. I guess I had too many probe at the same time :). The malfunctioning >> again of the IB in Xcode5 with the outlets can be solved with the earlier >> published workaround of an accompanying ObjC Class.h file next to the >> MacRuby Class.rb file. It’s a bit additional work to create and maintain >> but we’re talking about a few minutes here so that should not be a problem >> unless you have to maintain many many classes with outlets. Obviously the >> rb-nibtool is not called or not working anymore even when properly installed. >> >> What is a bigger problem is that not all objects seem to be created at >> run-time resulting in no-method errors (e.g. with gems) and sometimes not >> connected outlets in delegate classes or unresolved IB-action methods. >> Pretty weird. The same sources compile and run fine on SL-L-ML . For me it’s >> difficult to trace why and where this happens so hopefully an expert can >> shine a light on this. Very simple apps run fine, bigger ones with just more >> classes and stuff crash. >> >> I am moving back to ML and keep may be a little "play machine” on a separate >> disk with Mavericks. I am to happy with my MacRuby apps :) … May be >> moving to RubyMotion after all. I will test it at least soon. Laurent >> deserves the support and its not that much money :). >> >> cheers, Rob >> >> >> >> On 05 Nov 2013, at 19:55, [email protected] wrote: >> >>> Send MacRuby-devel mailing list submissions to >>> [email protected] >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://lists.macosforge.org/mailman/listinfo/macruby-devel >>> or, via email, send a message with subject or body 'help' to >>> [email protected] >>> >>> You can reach the person managing the list at >>> [email protected] >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of MacRuby-devel digest..." >>> >>> >>> Today's Topics: >>> >>> 1. MacRuby on Mavericks (Robert Carl Rice) >>> 2. Re: MacRuby on Mavericks (Mark Villacampa) >>> 3. Re: MacRuby on Mavericks (Robert Carl Rice) >>> 4. Re: MacRuby on Mavericks (Stephen Horne) >>> >>> >>> -- >>> >>> Message: 1 >>> Date: Mon, 4 Nov 2013 22:02:58 -0500 >>> From: Robert Carl Rice >>> To: "MacRuby development discussions." >>> >>> Subject: [MacRuby-devel] MacRuby on Mavericks >>> Message-ID: <[email protected]> >>> Content-Type: text/plain; charset=us-ascii >>> >>> Hi, >>> >>> Nice that I sparked some discussion. >>> >>> One of the reasons that I continued to write MacRuby script even though >>> Xcode was giving me the warning that GC was deprecated is that I suspect >>> that was a mostly a political move to appease the egos of the IOS and ARC >>> guys and also to encourage programmers to write more efficient code. Even >>> if Apple is determined not to support GC on the mobile devices, there is >>> probable no really good technical reason to
