Hi, Today I merged my code for the RubyCocoa layer. It's still very premature. There are some notes in sample-macruby/ RubyCocoa/README about what still needs to to be done. Also it is now in lib/osx/rubycocoa.rb and there's a osx/cocoa.rb. The latter will probably be removed as to not have RubyCocoa applications work by default. This needs to be discussed further. For now the main issues are the super_foo style methods and also some method missing like behaviour for objc methods that check if a method exists before dispatching. The latter is currently being worked around, but that should definitely move out. Cheers, Eloy
Oh and also the problem that #initialize isn't called from #init should be fixed :) Eloy On 23 jun 2008, at 23:20, Eloy Duran wrote:
Hi,
Today I merged my code for the RubyCocoa layer. It's still very premature. There are some notes in sample-macruby/ RubyCocoa/README about what still needs to to be done.
Also it is now in lib/osx/rubycocoa.rb and there's a osx/cocoa.rb. The latter will probably be removed as to not have RubyCocoa applications work by default. This needs to be discussed further.
For now the main issues are the super_foo style methods and also some method missing like behaviour for objc methods that check if a method exists before dispatching. The latter is currently being worked around, but that should definitely move out.
Cheers, Eloy
This one was fixed a couple of days ago :) Laurent On Jun 24, 2008, at 6:24 AM, Eloy Duran wrote:
Oh and also the problem that #initialize isn't called from #init should be fixed :)
Eloy
On 23 jun 2008, at 23:20, Eloy Duran wrote:
Hi,
Today I merged my code for the RubyCocoa layer. It's still very premature. There are some notes in sample-macruby/ RubyCocoa/README about what still needs to to be done.
Also it is now in lib/osx/rubycocoa.rb and there's a osx/cocoa.rb. The latter will probably be removed as to not have RubyCocoa applications work by default. This needs to be discussed further.
For now the main issues are the super_foo style methods and also some method missing like behaviour for objc methods that check if a method exists before dispatching. The latter is currently being worked around, but that should definitely move out.
Cheers, Eloy
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Oh serious? It is still failing in my tests. Here's the output of running the tests: D..F........F........ Finished in 1.439062 seconds. 1) should load AppKit when the osx/cocoa file is loaded is disabled 2) Failure: test_spec {NSObject additions} 002 [should call initialize from init if it exists](NSObject additions) method block (2 levels) in <main> in rubycocoa_test.rb at line 76 method run in test_case_adapter.rb at line 19 <"represent!"> expected but was <nil>. 3) Failure: test_spec {NSObject additions} 011 [should be possible to call super_foo type methods](NSObject additions) method block (2 levels) in <main> in rubycocoa_test.rb at line 123 method run in test_case_adapter.rb at line 19 Exception raised: Class: <NoMethodError> Message: <"undefined method `super_init' for #<TestRubyCocoaStyleSuperMethod: 0x26ec2f0>:TestRubyCocoaStyleSuperMethod"> ---Backtrace--- /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/1.9.0/ osx/rubycocoa.rb:67:in `method_missing' /Users/eloy/Documents/DEVELOPMENT/RubyCocoa/src/MacRuby/src/test- macruby/rubycocoa_test.rb:36:in `init' /Users/eloy/Documents/DEVELOPMENT/RubyCocoa/src/MacRuby/src/test- macruby/rubycocoa_test.rb:123:in `block (3 levels) in <main>' /Users/eloy/Documents/DEVELOPMENT/RubyCocoa/src/MacRuby/src/test- macruby/rubycocoa_test.rb:123:in `block (2 levels) in <main>' /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/ site_ruby/mocha/test_case_adapter.rb:19:in `run' --------------- 21 tests, 36 assertions, 2 failures, 0 errors The first failure tests if #initialize was called: class NSObjectSubclassWithInitialize < OSX::NSObject attr_reader :set_from_initialize def initialize @set_from_initialize = 'represent!' end end NSObjectSubclassWithInitialize.alloc.init.set_from_initialize.should == 'represent!' And as you can see that still fails.... :/ Eloy On 24 jun 2008, at 02:52, Laurent Sansonetti wrote:
This one was fixed a couple of days ago :)
Laurent
On Jun 24, 2008, at 6:24 AM, Eloy Duran wrote:
Oh and also the problem that #initialize isn't called from #init should be fixed :)
Eloy
On 23 jun 2008, at 23:20, Eloy Duran wrote:
Hi,
Today I merged my code for the RubyCocoa layer. It's still very premature. There are some notes in sample-macruby/ RubyCocoa/README about what still needs to to be done.
Also it is now in lib/osx/rubycocoa.rb and there's a osx/cocoa.rb. The latter will probably be removed as to not have RubyCocoa applications work by default. This needs to be discussed further.
For now the main issues are the super_foo style methods and also some method missing like behaviour for objc methods that check if a method exists before dispatching. The latter is currently being worked around, but that should definitely move out.
Cheers, Eloy
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
It's because you subclass NSObject. Try subclassing Object, and it will work. $ ./miniruby -ve "class Foo; def initialize; p 42; end; end; Foo.alloc.init" MacRuby version 0.3 (ruby 1.9.0 2008-06-03) [universal-darwin9.0] 42 The machinery is implemented in Object. # You should not subclass NSObject from MacRuby. An exception will probably be raised in the future. Laurent On Jun 24, 2008, at 5:20 PM, Eloy Duran wrote:
Oh serious? It is still failing in my tests. Here's the output of running the tests:
D..F........F........ Finished in 1.439062 seconds.
1) should load AppKit when the osx/cocoa file is loaded is disabled
2) Failure: test_spec {NSObject additions} 002 [should call initialize from init if it exists](NSObject additions) method block (2 levels) in <main> in rubycocoa_test.rb at line 76 method run in test_case_adapter.rb at line 19 <"represent!"> expected but was <nil>.
3) Failure: test_spec {NSObject additions} 011 [should be possible to call super_foo type methods](NSObject additions) method block (2 levels) in <main> in rubycocoa_test.rb at line 123 method run in test_case_adapter.rb at line 19 Exception raised: Class: <NoMethodError> Message: <"undefined method `super_init' for #<TestRubyCocoaStyleSuperMethod: 0x26ec2f0>:TestRubyCocoaStyleSuperMethod"> ---Backtrace--- /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/1.9.0/ osx/rubycocoa.rb:67:in `method_missing' /Users/eloy/Documents/DEVELOPMENT/RubyCocoa/src/MacRuby/src/test- macruby/rubycocoa_test.rb:36:in `init' /Users/eloy/Documents/DEVELOPMENT/RubyCocoa/src/MacRuby/src/test- macruby/rubycocoa_test.rb:123:in `block (3 levels) in <main>' /Users/eloy/Documents/DEVELOPMENT/RubyCocoa/src/MacRuby/src/test- macruby/rubycocoa_test.rb:123:in `block (2 levels) in <main>' /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/ site_ruby/mocha/test_case_adapter.rb:19:in `run' ---------------
21 tests, 36 assertions, 2 failures, 0 errors
The first failure tests if #initialize was called:
class NSObjectSubclassWithInitialize < OSX::NSObject attr_reader :set_from_initialize def initialize @set_from_initialize = 'represent!' end end
NSObjectSubclassWithInitialize.alloc.init.set_from_initialize.should == 'represent!'
And as you can see that still fails.... :/
Eloy
On 24 jun 2008, at 02:52, Laurent Sansonetti wrote:
This one was fixed a couple of days ago :)
Laurent
On Jun 24, 2008, at 6:24 AM, Eloy Duran wrote:
Oh and also the problem that #initialize isn't called from #init should be fixed :)
Eloy
On 23 jun 2008, at 23:20, Eloy Duran wrote:
Hi,
Today I merged my code for the RubyCocoa layer. It's still very premature. There are some notes in sample-macruby/ RubyCocoa/README about what still needs to to be done.
Also it is now in lib/osx/rubycocoa.rb and there's a osx/cocoa.rb. The latter will probably be removed as to not have RubyCocoa applications work by default. This needs to be discussed further.
For now the main issues are the super_foo style methods and also some method missing like behaviour for objc methods that check if a method exists before dispatching. The latter is currently being worked around, but that should definitely move out.
Cheers, Eloy
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Ah ok, but that is not what is needed for the layer. The behaviour I'm talking about is behaviour that works in RubyCocoa. So it still fails... :) Eloy On 24 jun 2008, at 16:09, Laurent Sansonetti wrote:
It's because you subclass NSObject. Try subclassing Object, and it will work.
$ ./miniruby -ve "class Foo; def initialize; p 42; end; end; Foo.alloc.init" MacRuby version 0.3 (ruby 1.9.0 2008-06-03) [universal-darwin9.0] 42
The machinery is implemented in Object.
# You should not subclass NSObject from MacRuby. An exception will probably be raised in the future.
Laurent
On Jun 24, 2008, at 5:20 PM, Eloy Duran wrote:
Oh serious? It is still failing in my tests. Here's the output of running the tests:
D..F........F........ Finished in 1.439062 seconds.
1) should load AppKit when the osx/cocoa file is loaded is disabled
2) Failure: test_spec {NSObject additions} 002 [should call initialize from init if it exists](NSObject additions) method block (2 levels) in <main> in rubycocoa_test.rb at line 76 method run in test_case_adapter.rb at line 19 <"represent!"> expected but was <nil>.
3) Failure: test_spec {NSObject additions} 011 [should be possible to call super_foo type methods](NSObject additions) method block (2 levels) in <main> in rubycocoa_test.rb at line 123 method run in test_case_adapter.rb at line 19 Exception raised: Class: <NoMethodError> Message: <"undefined method `super_init' for #<TestRubyCocoaStyleSuperMethod: 0x26ec2f0>:TestRubyCocoaStyleSuperMethod"> ---Backtrace--- /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/ 1.9.0/ osx/rubycocoa.rb:67:in `method_missing' /Users/eloy/Documents/DEVELOPMENT/RubyCocoa/src/MacRuby/src/test- macruby/rubycocoa_test.rb:36:in `init' /Users/eloy/Documents/DEVELOPMENT/RubyCocoa/src/MacRuby/src/test- macruby/rubycocoa_test.rb:123:in `block (3 levels) in <main>' /Users/eloy/Documents/DEVELOPMENT/RubyCocoa/src/MacRuby/src/test- macruby/rubycocoa_test.rb:123:in `block (2 levels) in <main>' /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/ site_ruby/mocha/test_case_adapter.rb:19:in `run' ---------------
21 tests, 36 assertions, 2 failures, 0 errors
The first failure tests if #initialize was called:
class NSObjectSubclassWithInitialize < OSX::NSObject attr_reader :set_from_initialize def initialize @set_from_initialize = 'represent!' end end
NSObjectSubclassWithInitialize.alloc.init.set_from_initialize.should == 'represent!'
And as you can see that still fails.... :/
Eloy
On 24 jun 2008, at 02:52, Laurent Sansonetti wrote:
This one was fixed a couple of days ago :)
Laurent
On Jun 24, 2008, at 6:24 AM, Eloy Duran wrote:
Oh and also the problem that #initialize isn't called from #init should be fixed :)
Eloy
On 23 jun 2008, at 23:20, Eloy Duran wrote:
Hi,
Today I merged my code for the RubyCocoa layer. It's still very premature. There are some notes in sample-macruby/ RubyCocoa/README about what still needs to to be done.
Also it is now in lib/osx/rubycocoa.rb and there's a osx/cocoa.rb. The latter will probably be removed as to not have RubyCocoa applications work by default. This needs to be discussed further.
For now the main issues are the super_foo style methods and also some method missing like behaviour for objc methods that check if a method exists before dispatching. The latter is currently being worked around, but that should definitely move out.
Cheers, Eloy
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
After thinking about it, I will change MacRuby to automatically subclass Object instead of NSObject and print a warning. So, this bug will be fixed, and also a warning will be printed to notice the developer that he should not subclass NSObject. http://ruby.macosforge.org/trac/ticket/88 Laurent On Jun 24, 2008, at 11:37 PM, Eloy Duran wrote:
Ah ok, but that is not what is needed for the layer. The behaviour I'm talking about is behaviour that works in RubyCocoa. So it still fails... :)
Eloy
On 24 jun 2008, at 16:09, Laurent Sansonetti wrote:
It's because you subclass NSObject. Try subclassing Object, and it will work.
$ ./miniruby -ve "class Foo; def initialize; p 42; end; end; Foo.alloc.init" MacRuby version 0.3 (ruby 1.9.0 2008-06-03) [universal-darwin9.0] 42
The machinery is implemented in Object.
# You should not subclass NSObject from MacRuby. An exception will probably be raised in the future.
Laurent
On Jun 24, 2008, at 5:20 PM, Eloy Duran wrote:
Oh serious? It is still failing in my tests. Here's the output of running the tests:
D..F........F........ Finished in 1.439062 seconds.
1) should load AppKit when the osx/cocoa file is loaded is disabled
2) Failure: test_spec {NSObject additions} 002 [should call initialize from init if it exists](NSObject additions) method block (2 levels) in <main> in rubycocoa_test.rb at line 76 method run in test_case_adapter.rb at line 19 <"represent!"> expected but was <nil>.
3) Failure: test_spec {NSObject additions} 011 [should be possible to call super_foo type methods](NSObject additions) method block (2 levels) in <main> in rubycocoa_test.rb at line 123 method run in test_case_adapter.rb at line 19 Exception raised: Class: <NoMethodError> Message: <"undefined method `super_init' for #<TestRubyCocoaStyleSuperMethod: 0x26ec2f0>:TestRubyCocoaStyleSuperMethod"> ---Backtrace--- /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/ 1.9.0/ osx/rubycocoa.rb:67:in `method_missing' /Users/eloy/Documents/DEVELOPMENT/RubyCocoa/src/MacRuby/src/test- macruby/rubycocoa_test.rb:36:in `init' /Users/eloy/Documents/DEVELOPMENT/RubyCocoa/src/MacRuby/src/test- macruby/rubycocoa_test.rb:123:in `block (3 levels) in <main>' /Users/eloy/Documents/DEVELOPMENT/RubyCocoa/src/MacRuby/src/test- macruby/rubycocoa_test.rb:123:in `block (2 levels) in <main>' /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/ site_ruby/mocha/test_case_adapter.rb:19:in `run' ---------------
21 tests, 36 assertions, 2 failures, 0 errors
The first failure tests if #initialize was called:
class NSObjectSubclassWithInitialize < OSX::NSObject attr_reader :set_from_initialize def initialize @set_from_initialize = 'represent!' end end
NSObjectSubclassWithInitialize.alloc.init.set_from_initialize.should == 'represent!'
And as you can see that still fails.... :/
Eloy
On 24 jun 2008, at 02:52, Laurent Sansonetti wrote:
This one was fixed a couple of days ago :)
Laurent
On Jun 24, 2008, at 6:24 AM, Eloy Duran wrote:
Oh and also the problem that #initialize isn't called from #init should be fixed :)
Eloy
On 23 jun 2008, at 23:20, Eloy Duran wrote:
Hi,
Today I merged my code for the RubyCocoa layer. It's still very premature. There are some notes in sample- macruby/ RubyCocoa/README about what still needs to to be done.
Also it is now in lib/osx/rubycocoa.rb and there's a osx/ cocoa.rb. The latter will probably be removed as to not have RubyCocoa applications work by default. This needs to be discussed further.
For now the main issues are the super_foo style methods and also some method missing like behaviour for objc methods that check if a method exists before dispatching. The latter is currently being worked around, but that should definitely move out.
Cheers, Eloy
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Jun 24, 2008, at 6:20 AM, Eloy Duran wrote:
Hi,
Today I merged my code for the RubyCocoa layer. It's still very premature. There are some notes in sample-macruby/ RubyCocoa/README about what still needs to to be done.
Excellent, thanks!
Also it is now in lib/osx/rubycocoa.rb and there's a osx/cocoa.rb. The latter will probably be removed as to not have RubyCocoa applications work by default. This needs to be discussed further.
As I said earlier I don't think osx/cocoa.rb is a good idea, I would prefer rubycocoa.rb instead. This is a temporarily compatible layer, designed to help people port their RubyCocoa app to MacRuby. The purpose is not to provide a layer on which people can rely on eternally. So having developers explicitly require rubycocoa.rb is better IMHO (and anyway, in the most cases, this will be an Xcode app that has to be modified to link against MacRuby.) Also, I don't think it's a good idea to duplicate the whole osx/*.rb environment then.
For now the main issues are the super_foo style methods and also some method missing like behaviour for objc methods that check if a method exists before dispatching. The latter is currently being worked around, but that should definitely move out.
I will address these. Regarding your commit: - could you install the layer as part of instruby.rb instead? And respect destdir. - I wonder if it's necessary to commit the RubyCocoa samples in sample- macruby as you did. Ultimately we might be able to run all RubyCocoa samples, but we probably don't want to have all of them in macruby- sample, right? Maybe some of the samples could be moved in the test directory, for testing purposes? I think people will be confused to see a RubyCocoa directory in / Developer/Examples/Ruby/MacRuby. Laurent
Also it is now in lib/osx/rubycocoa.rb and there's a osx/cocoa.rb. The latter will probably be removed as to not have RubyCocoa applications work by default. This needs to be discussed further.
As I said earlier I don't think osx/cocoa.rb is a good idea, I would prefer rubycocoa.rb instead.
This is a temporarily compatible layer, designed to help people port their RubyCocoa app to MacRuby. The purpose is not to provide a layer on which people can rely on eternally. So having developers explicitly require rubycocoa.rb is better IMHO (and anyway, in the most cases, this will be an Xcode app that has to be modified to link against MacRuby.)
Also, I don't think it's a good idea to duplicate the whole osx/*.rb environment then.
I don't completely agree with you on these points. As for now I do not intend to completely port my apps to MacRuby, also because I simply don't have the time. But I would like to be able to develop further on MacRuby while still being able to use RC if it's necessary. So this is I guess the main difference in our points of view. But to get back to the real issue at hand, sure I understand it's better to remind developers that using the layer is not the optimal way of using MacRuby. I'll remove osx/cocoa.rb and add it to Rucola.
For now the main issues are the super_foo style methods and also some method missing like behaviour for objc methods that check if a method exists before dispatching. The latter is currently being worked around, but that should definitely move out.
I will address these.
Groovy!
Regarding your commit:
- could you install the layer as part of instruby.rb instead? And respect destdir.
- I wonder if it's necessary to commit the RubyCocoa samples in sample- macruby as you did. Ultimately we might be able to run all RubyCocoa samples, but we probably don't want to have all of them in macruby- sample, right? Maybe some of the samples could be moved in the test directory, for testing purposes?
I think people will be confused to see a RubyCocoa directory in / Developer/Examples/Ruby/MacRuby.
Hmm I understand, not 100% sure that moving them to test/ feels better, but let's see :) Eloy
On Jun 24, 2008, at 1:27 AM, Eloy Duran wrote:
Also it is now in lib/osx/rubycocoa.rb and there's a osx/cocoa.rb. The latter will probably be removed as to not have RubyCocoa applications work by default. This needs to be discussed further.
As I said earlier I don't think osx/cocoa.rb is a good idea, I would prefer rubycocoa.rb instead.
I don't completely agree with you on these points. As for now I do not intend to completely port my apps to MacRuby, also because I simply don't have the time. But I would like to be able to develop further on MacRuby while still being able to use RC if it's necessary. So this is I guess the main difference in our points of view.
But to get back to the real issue at hand, sure I understand it's better to remind developers that using the layer is not the optimal way of using MacRuby.
I kind of think you're both right... As a developer, I need a way to dip my toe into MacRuby without having to port too much code. At least until Laurent says "MacRuby is farther along then RubyCocoa". However, since MacRuby requires a different project file anyways, what if everything went through a layer of indirection. That is, you setup both projects so that the RubyCocoa projects included one shim file, and the MacRuby project includes a different shim file (or you do a similar thing via require). So 99% of your code can be tweaked to run on both platforms. The MacRubyShim would look like this: class ShimObject < Object end While the RubyCocoaShim would look like this require 'osx/cocoa' class ShimObject < NSObject end So then I search and replace all my NSObject inheritances into ShimObject, and they work in both places. Just an idea. Pierce
On Jun 24, 2008, at 5:27 PM, Eloy Duran wrote:
Also it is now in lib/osx/rubycocoa.rb and there's a osx/cocoa.rb. The latter will probably be removed as to not have RubyCocoa applications work by default. This needs to be discussed further.
As I said earlier I don't think osx/cocoa.rb is a good idea, I would prefer rubycocoa.rb instead.
This is a temporarily compatible layer, designed to help people port their RubyCocoa app to MacRuby. The purpose is not to provide a layer on which people can rely on eternally. So having developers explicitly require rubycocoa.rb is better IMHO (and anyway, in the most cases, this will be an Xcode app that has to be modified to link against MacRuby.)
Also, I don't think it's a good idea to duplicate the whole osx/*.rb environment then.
I don't completely agree with you on these points. As for now I do not intend to completely port my apps to MacRuby, also because I simply don't have the time. But I would like to be able to develop further on MacRuby while still being able to use RC if it's necessary. So this is I guess the main difference in our points of view.
But to get back to the real issue at hand, sure I understand it's better to remind developers that using the layer is not the optimal way of using MacRuby.
I'll remove osx/cocoa.rb and add it to Rucola.
After thinking about this, I changed my mind, and agree with yours. Let's stick to osx/cocoa. Also, I filed http://ruby.macosforge.org/trac/ticket/89 regarding pure C RubyCocoa APIs that also need to be emulated (I will take care of this). Laurent
After thinking about this, I changed my mind, and agree with yours. Let's stick to osx/cocoa.
Also, I filed http://ruby.macosforge.org/trac/ticket/89 regarding pure C RubyCocoa APIs that also need to be emulated (I will take care of this).
Ok :) One thing I forgot to mention, but we already discussed off list, is that we should raise warnings to let the user know he/she is not using the most optimal code for MacRuby. Eloy
On Jun 24, 2008, at 1:27 AM, Eloy Duran wrote:
- I wonder if it's necessary to commit the RubyCocoa samples in sample- macruby as you did. Ultimately we might be able to run all RubyCocoa samples, but we probably don't want to have all of them in macruby- sample, right? Maybe some of the samples could be moved in the test directory, for testing purposes?
I think people will be confused to see a RubyCocoa directory in / Developer/Examples/Ruby/MacRuby.
Hmm I understand, not 100% sure that moving them to test/ feels better, but let's see :)
Actually, since the RubyCocoa examples are already available in / Developer/Examples/Ruby/RubyCocoa, and that in theory the layer should just run them without any modification, why not just keeping a RUBYCOCOA_README text file (like the one you wrote) with the list of samples that work, and those which not. Or we can do this in the wiki alternatively. Anyway, the RubyCocoa samples should not IMHO be duplicated in sample- macruby. (Have a good vacation :)) Laurent
On Jul 6, 2008, at 3:29 PM, Laurent Sansonetti wrote:
On Jun 24, 2008, at 1:27 AM, Eloy Duran wrote:
- I wonder if it's necessary to commit the RubyCocoa samples in sample- macruby as you did. Ultimately we might be able to run all RubyCocoa samples, but we probably don't want to have all of them in macruby- sample, right? Maybe some of the samples could be moved in the test directory, for testing purposes?
I think people will be confused to see a RubyCocoa directory in / Developer/Examples/Ruby/MacRuby.
Hmm I understand, not 100% sure that moving them to test/ feels better, but let's see :)
Actually, since the RubyCocoa examples are already available in / Developer/Examples/Ruby/RubyCocoa, and that in theory the layer should just run them without any modification, why not just keeping a RUBYCOCOA_README text file (like the one you wrote) with the list of samples that work, and those which not. Or we can do this in the wiki alternatively.
Anyway, the RubyCocoa samples should not IMHO be duplicated in sample- macruby.
BTW, the rubycocoa layer isn't quite working for me yet: 2008-07-07 15:12:30.032 Frictionless[14025:813] fetchedpassword /Users/pierce/svnProjects/build/Release/Frictionless.app/Contents/ Resources/Action-mr.rb:847:in `isUrgent': undefined local variable or method `super_isUrgent' for #<Action_Action_:0x196a6a0> (NameError) from /Users/pierce/svnProjects/build/Release/Frictionless.app/ Contents/Resources/Action-mr.rb:1003:in `appLaunch' def isUrgent result = super_isUrgent result = 0 unless result != nil result end The superclass definition of isUrgent is on the ObjC side, so the full inheritance path is: Action (Ruby) < Machine_Action_rb (Ruby) < Machine_Action (ObjC) : KSExtensibleManagedObject : NSManagedObject Though its the Machine_Action.m file that defines isUrgent: - (NSNumber*)isUrgent { [self willAccessValueForKey:@"isUrgent"]; NSNumber *result = [self primitiveValueForKey:@"isUrgent"]; [self didAccessValueForKey:@"isUrgent"]; return result; }
On Mon, Jul 7, 2008 at 3:26 PM, Pierce T. Wetter III <pierce@twinforces.com> wrote:
On Jul 6, 2008, at 3:29 PM, Laurent Sansonetti wrote:
On Jun 24, 2008, at 1:27 AM, Eloy Duran wrote:
- I wonder if it's necessary to commit the RubyCocoa samples in sample- macruby as you did. Ultimately we might be able to run all RubyCocoa samples, but we probably don't want to have all of them in macruby- sample, right? Maybe some of the samples could be moved in the test directory, for testing purposes?
I think people will be confused to see a RubyCocoa directory in / Developer/Examples/Ruby/MacRuby.
Hmm I understand, not 100% sure that moving them to test/ feels better, but let's see :)
Actually, since the RubyCocoa examples are already available in / Developer/Examples/Ruby/RubyCocoa, and that in theory the layer should just run them without any modification, why not just keeping a RUBYCOCOA_README text file (like the one you wrote) with the list of samples that work, and those which not. Or we can do this in the wiki alternatively.
Anyway, the RubyCocoa samples should not IMHO be duplicated in sample- macruby.
BTW, the rubycocoa layer isn't quite working for me yet:
2008-07-07 15:12:30.032 Frictionless[14025:813] fetchedpassword /Users/pierce/svnProjects/build/Release/Frictionless.app/Contents/ Resources/Action-mr.rb:847:in `isUrgent': undefined local variable or method `super_isUrgent' for #<Action_Action_:0x196a6a0> (NameError) from /Users/pierce/svnProjects/build/Release/Frictionless.app/ Contents/Resources/Action-mr.rb:1003:in `appLaunch'
Looks like the layer doesn't catch isUrgent as a missing method. Are you sure you loaded osx/cocoa.rb before? Laurent
Looks like the layer doesn't catch isUrgent as a missing method. Are you sure you loaded osx/cocoa.rb before?
Ah, as in I have a mixture of RubyCocoa code and MacRuby code from my last attempt. Could be. Doh! Yep. Ok, adding require 'osx/cocoa' Hmmm.... /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/1.9.0/ osx/rubycocoa.rb:52:in `instance_methods': stack level too deep (SystemStackError) from /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/ 1.9.0/osx/rubycocoa.rb:52:in `method_missing' from /Users/pierce/svnProjects/build/Release/Frictionless.app/ Contents/Resources/Action-mr.rb:847:in `isUrgent' from /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/ 1.9.0/osx/rubycocoa.rb:53:in `__super_objc_send__' from /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/ 1.9.0/osx/rubycocoa.rb:53:in `method_missing' from /Users/pierce/svnProjects/build/Release/Frictionless.app/ Contents/Resources/Action-mr.rb:847:in `isUrgent' from /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/ 1.9.0/osx/rubycocoa.rb:53:in `__super_objc_send__' from /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/ 1.9.0/osx/rubycocoa.rb:53:in `method_missing' from /Users/pierce/svnProjects/build/Release/Frictionless.app/ Contents/Resources/Action-mr.rb:847:in `isUrgent' ... 3083 levels... Pierce
participants (4)
-
Eloy Duran
-
Laurent Sansonetti
-
Laurent Sansonetti
-
Pierce T. Wetter III