Re: [MacRuby-devel] NSEvent MacRuby (updated)
Well... Yes my macbook is a 32 bit system... So there not going to be a solution fro my problem in the near future. Anyway I made a kind of workaround... Thank you for your help! anyway I hope the bug will be solved. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] Objective-c Class -> methods
Hi there!
I'm having problems of getting a list of methods from Classes, declared in
Objective-C.
I have a class compiled, and fully working, look like this:
// Vector.h
@interface Vector : NSObject {
float x,y,z;
}
@property float x,y,z;
@property float length;
@end
// Vector.m
@implementation Vector
@synthesize x,y,z;
-(Vector*)vectorByAdd:(Vector*)vector{
Vector* newVector=[[Vector new] autorelease];
newVector.x=self.x+vector.x;
newVector.y=self.y+vector.y;
newVector.z=self.z+vector.z;
return newVector;
}
[...]
@end
when I call the ruby method :methods on a Vector, it returns the methods of
an Object class, and I cant get neither the accesors of the x,y,z property, nor
the other methods appears
Once I read something about how to get the obj-c methods, but I couldn-t
find it.
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Objective-c Class -> methods
HI,
I think for calling the .methods method from MacRuby you should add two
additional MacRuby specific arguments.
to get the list of all methods use this:
.methods(true,true)or.methods true, true
--- András Zalavári schrieb am So, 21.11.2010:
Von: András Zalavári
Betreff: [MacRuby-devel] Objective-c Class -> methods
An: "MacRuby development discussions."
Datum: Sonntag, 21. November, 2010 18:55 Uhr
Hi there!
I'm having problems of getting a list of methods from Classes, declared in
Objective-C.I have a class compiled, and fully working, look like this:
// vecto...@interface Vector : NSObject {
float x,y,z;
}
@property float x,y,z;
@property float length;
@end
// Vector.m
@implementation Vector
@synthesize x,y,z;
-(Vector*)vectorByAdd:(Vector*)vector{
Vector* newVector=[[Vector new] autorelease];
newVector.x=self.x+vector.x;
newVector.y=self.y+vector.y;
newVector.z=self.z+vector.z;
return newVector;
}[...]
@end
when I call the ruby method :methods on a Vector, it returns the methods of an
Object class, and I cant get neither the accesors of the x,y,z property, nor
the other methods appears
Once I read something about how to get the obj-c methods, but I couldn-t find
it.
-Integrierter Anhang folgt-
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Objective-c Class -> methods
You can pass two arguments to #methods, which are to include methods from
ancestors and to include Objective-C methods, So you probably want:
vector.methods(false, true)
On 21 nov 2010, at 18:55, András Zalavári wrote:
> Hi there!
>
> I'm having problems of getting a list of methods from Classes, declared in
> Objective-C.
> I have a class compiled, and fully working, look like this:
>
> // Vector.h
> @interface Vector : NSObject {
> float x,y,z;
> }
> @property float x,y,z;
> @property float length;
> @end
>
> // Vector.m
>
> @implementation Vector
> @synthesize x,y,z;
> -(Vector*)vectorByAdd:(Vector*)vector{
> Vector* newVector=[[Vector new] autorelease];
> newVector.x=self.x+vector.x;
> newVector.y=self.y+vector.y;
> newVector.z=self.z+vector.z;
> return newVector;
> }
>
> [...]
> @end
>
> when I call the ruby method :methods on a Vector, it returns the methods of
> an Object class, and I cant get neither the accesors of the x,y,z property,
> nor the other methods appears
>
> Once I read something about how to get the obj-c methods, but I couldn-t find
> it.
>
>
>
>
>
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] Is is possible to debug a MacRuby Cocoa app?
Hello, and thank you very much to the developers of MacRuby. It's an amazing technology and I hope to see it continue to grow. I've managed to figure out, after an hour or two of wasted time, that although MacRuby now includes a debugger, that debugger can't be used to debug a MacRuby Cocoa app. Not only through XCode, but at all. Is that correct? The release notes proudly announce that MacRuby now includes a debugger but they neglect to mention how to use it. After some research I eventually discovered that there is no way to use the debugger to debug a Cocoa app. If that's true, then lack of a debugger eliminates any benefit that using Ruby could bring to the Cocoa experience. Objective C syntax is truly nasty, but if there is no debugger available for Cocoa apps written with MacRuby then it just doesn't make sense to use Ruby to make a Cocoa app. Especially with Objective C 2.0's simplified syntax and garbage collection. "You don't need a debugger for Ruby code", is simply not a realistic solution. TDD and BDD tools for desktop Cocoa apps are still inadequate, and even with TDD you often still need a debugger. MacRuby isn't going to go very far if developers are forced to revert to printf debugging to build Cocoa apps. I don't mind if the debugger doesn't have slick XCode integration like GDB. But there needs to be SOME way to debug a Cocoa app or else the sensible path for developer productivity on the Mac will be Objective C 2.0 instead of MacRuby. Sacrificing any hope of using a debugger to gain relatively minor syntactic improvements is not a tradeoff that makes any sense. I don't intend to disparage MacRuby, I just want to share my perspective as both a professional Rubyist and a professional Cocoa developer. MacRuby is an amazing technology, but to gain traction as a realistic way to build Cocoa apps it will really need a debugger that works with Cocoa apps. -- Ryan ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Is is possible to debug a MacRuby Cocoa app?
On Nov 21, 2010, at 3:49 PM, Ryan Porter wrote: > I've managed to figure out, after an hour or two of wasted time, that > although MacRuby now includes a debugger, that debugger can't be used to > debug a MacRuby Cocoa app. Not only through XCode, but at all. Is that > correct? The release notes proudly announce that MacRuby now includes a > debugger but they neglect to mention how to use it. After some research I > eventually discovered that there is no way to use the debugger to debug a > Cocoa app. I think this is not a case of deliberate (or unknowing) omission so much as a little over-enthusiastic "marketing" of a command-line-only debugging feature that itself is just barely out of alpha-quality status. Calling what is currently there an "experimental debugger" would probably be more accurate, and set expectations more correctly, but you can't really blame the developers for an abundance of enthusiasm for something which is, at least, the start of something in this area. It's kind of an ugly truth about most interpreted languages, from Tcl to Python to Ruby, that the integrated debugging support basically sucks and is rarely designed into the default implementations of said languages. Proponents of those languages generally claim that it's so easy to sprinkle debugging "printfs" into their code, emit log messages, etc, that they don't *need* a debugger, whereas I suspect that the kind of debugging experience you're looking for probably involves a graphical IDE wi th debugging breakpoints set in the source browser/editor in addition to views for watched variables, calling context information, and all the other fun stuff you'd expect from an interpreted language debugger. Sorry, but such a thing has simply not been implemented yet! - Jordan ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] allowedFileTypes and NSOpenPanel
Hi Gregoire, I ran your snippet from the terminal and the panel was only able to select these file types, in my environment. What version of Mac OS X do you run? It's possible that there is a Cocoa bug somewhere. Laurent On Nov 13, 2010, at 5:38 AM, Gregoire LEJEUNE wrote: > Hi, > > I try to use setAllowedFileTypes with an NSOpenPanel using this code : > > panel = NSOpenPanel.openPanel() > panel.canChooseFiles = true > panel.allowedFileTypes = ["graphml", "gml", "xml"] > result = panel.runModal() > > But it doesn't work. I can chose any type of file. > > If I use the (10.6) deprecated runModalWithTypes, it works... So is it > me or setAllowedFileTypes which's buggy ? > > Thanks for your help. > > Greg > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Future MacRuby support for "name-mangling" ?
Hi Scott, Supporting this has been in discussion for a while, however I'm against it for consistency sake. If we allow methods to be defined or messaged using different styles, it can create confusion and ambiguity in some cases (especially if you start overloading methods). If you have a good feature proposal in mind, feel free to describe it, maybe this could be implemented in a way confusion and ambiguity will be avoided. Laurent On Nov 14, 2010, at 8:51 AM, Scott Lowe wrote: > Hello, > > Both JRuby and IronRuby support translation from 'native' CamelCase method > names to the > lowercase_with_underscores naming convention in idiomatic Ruby. > > They IronRuby guys call this "name-mangling": > http://ironruby.net/Documentation/.NET/Names > > I had an expectation that this would be the case with MacRuby, but I now know > that this is > not true. Are there any plans to implement this feature in the future? You > can probably guess > that I like this feature an awful lot. > > Regards, > > Scott > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Conforming to a protocol
I commented the #999 ticket, I believe there is a way to make MacRuby classes
automatically conform to protocols (once all required methods are implemented).
Let's try to get that done for the upcoming release :)
Laurent
On Nov 20, 2010, at 2:28 PM, Charles Steinman wrote:
> In case anyone needs it in the meantime, here is a working
> implementation of conformsToProtocol:
>
> def conformsToProtocol(protocol)
> supported = %w( AProtocol SomeOtherProtocol YetAnotherProtocol
> ).map {|name| Protocol.protocolWithName name} # List the protocols you
> want to conform to between the parns
> supported.any? {|candidate| protocol.isEqual candidate } or super
> end
>
> The reason this works is because Protocol *is* a real class, but it's
> derived from a base class different from NSObject. Obviously we'll
> want a better solution for MacRuby, but this will work in the
> meantime.
>
> — Chuck
>
> On Wed, Nov 17, 2010 at 4:42 AM, Eloy Duran wrote:
>> Regardless of the current state, having a real Protocol class and objects
>> that you can use to check against should be the goal. Let's discuss this
>> further on the ticket from now on, for completeness sake.
>> On Nov 17, 2010, at 12:44 PM, Thibault Martin-Lagardette wrote:
>>
>> These structures are currently handled by Foundation's BridgeSupport file
>> (/System/Library/Frameworks/Foundation.framework/Resources/BridgeSupport/Foundation.bridgesupport)
>> > type='{_NSPoint="x"f"y"f}'/>
>> > type64='{_NSRange="location"Q"length"Q}'
>> type='{_NSRange="location"I"length"I}'/>
>> It's not very humanly readable, but MacRuby understands what this means, and
>> then knows NSPoint is a structure :-).
>> However, just for proving myself wrong, there IS a Protocol Obj-C objet (
>> see http://opensource.apple.com/source/objc4/objc4-437.1/runtime/Protocol.h
>> ).
>> But I think my point stands, as I do think what is returned is the C struct,
>> not the class.
>> I think Laurent might know a little better though :-)
>> --
>> Thibault Martin-Lagardette
>>
>>
>> On Nov 17, 2010, at 12:19, Martijn Walraven wrote:
>>
>> Thanks for opening a ticket and describing the issue so well!
>> I'm not sure how this should be solved, but I was wondering how things
>> currently work for other C structs like NSRect or NSPoint. Are these handled
>> as special cases, or is there a more general way to deal with C structs?
>> Would it make sense to think about somehow mapping C structs to the Ruby
>> Struct class, or maybe a special CStruct class? It would be nice if this at
>> least offered a way to perform equality checks (==, eql?, equals?). For
>> structs that have defined attributes it would be great if this allowed
>> getting and setting attribute values (similar to what you can do with NSRect
>> and NSPoint).
>> I might be totally off, so maybe someone who knows more about the internals
>> of MacRuby can comment?
>> On Nov 17, 2010, at 11:33 , Thibault Martin-Lagardette wrote:
>>
>> This is because protocols, in the Obj-C runtime, are not Obj-C objets per
>> say, they are C structs.
>> +protocolWithName returns an (id) (aka obj-c objet), but the actual returned
>> pointer is just a pointer to a C struct, which causes the runtime to issue
>> those warnings. It says "Hey, this method returned an objet, but it doesn't
>> look like one!". Which is expected, but this should be improved.
>> While it is true that in the Obj-C runtime, classes and objects are C
>> structs too, they are obviously not the same kind of structures, which is
>> why it doesn't work :-).
>> In MacRuby, `Protocol` IS a real Obj-C objet, but not what
>> the +protocolWithName method returns. This means that whatever you do with
>> the returned valiue, it will crash, because it is not a real objet, and thus
>> does not respond to any message.
>> This also means that you cannot even do something like that:
>> Protocol.protocolWithName("NSCoding") ==
>> Protocol.protocolWithName("NSCoding")
>> Simply because doing this will call the `#==` method on the left-most value,
>> which is a C struct for a protocol, and not an Obj-C object.
>> I created https://www.macruby.org/trac/ticket/999 , related to protocols.
>> Please be aware that the attached patch still does not make it possible to
>> override conformsToProtocol:, because calling `#==` on non-objets will
>> crash, which is why I think MacRuby could handle Protocols a little better,
>> right now I'm not sure it's "usable" per say.
>> Sorry if I do repeat myself a little, but I want to make sure you understand
>> why this does not work yet, and what you can and cannot do with protocols as
>> of today :-).
>> --
>> Thibault Martin-Lagardette
>>
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> http://lists.
Re: [MacRuby-devel] calling Objective-C method with block parameter
Hi Alan, Indeed, if you link a specific framework into your project's executable in Xcode, its BridgeSupport file won't be loaded at runtime by MacRuby. I re-opened #1000 as I think MacRuby should do it for you, nevertheless. I believe this issue might hit other persons as MacRuby will gain popularity, so let's try to get it fixed for the upcoming release. Laurent On Nov 18, 2010, at 1:52 AM, Alan Skipp wrote: > A wonderful prize indeed! > > Regarding the bug, I think I've been led astray by Xcode. If I add the > framework in the usual way to an Xcode project, the class defintions within > the framework become accessible to macruby. Therefore I assumed that by > linking to the framework, macruby automatically loads it because I am able to > create objects from the framework's header file. The failure only occurs when > attempting to call methods that require a bridgesupport file. > > If I explicitly load the framework in 'rb_main.rb', everything works > correctly. I hadn't realised this step was necessary, as simply linking to > the framework in Xcode appears to load it and make it available to macruby > code. > > > On 17 Nov 2010, at 17:26, Matt Aimonetti wrote: > >> Congratulations!! You won a lifetime license to use MacRuby 0.7.1 for free ;) >> >> I tested your framework and I wasn't able to reproduce the bug mentioned. I >> closed the ticket https://www.macruby.org/trac/ticket/1000#comment:2 >> But feel free to investigate more and reopen it if you find something new. >> >> Thanks, >> >> - Matt >> >> On Wed, Nov 17, 2010 at 9:05 AM, Alan Skipp wrote: >> Ticket #1000 has been filed. >> Does the 1000th ticket get a special prize? >> >> On 17 Nov 2010, at 14:39, Eloy Duran wrote: >> >> > That’s no good. Can you file a ticket? (Preferably with the test framework >> > attached) >> > >> > On Nov 17, 2010, at 3:34 PM, Alan Skipp wrote: >> > >> >> Thanks for the reply. I have the bridgesupport file located in the >> >> '/Resources/BridgeSupport/' folder of the framework, but currently it is >> >> not automatically loaded. I've tried making a clean build to no avail and >> >> I've checked the built app package and the framework is copied and the >> >> bridgesupport file is present. I also created a new test project in Xcode >> >> (just in case something had went awry with the other project) and I had >> >> to explicitly call 'load_bridge_support_file' to get the framework >> >> working there also. >> >> >> >> >> >> On 17 Nov 2010, at 13:42, Eloy Duran wrote: >> >> >> >>> The BridgeSupport file should be in a BridgeSupport directory inside the >> >>> framework’s Resources directory. For example, Foundation’s BridgeSupport >> >>> file is at: >> >>> /System/Library/Frameworks/Foundation.framework/Resources/BridgeSupport/Foundation.bridgesupport >> >>> >> >>> On Nov 17, 2010, at 2:32 PM, Alan Skipp wrote: >> >>> >> Thanks for the info. I'd wrongly assumed that as blocks can be treated >> as Objective-C objects that I could just go ahead and use them in >> Macruby. >> I have it working now, which is great, though I do have one more >> question. >> Initially I was receiving the same errors after I'd included the >> framework with a bridgesupport file into my project. I finally got it >> working after invoking, 'load_bridge_support_file' in my controller >> class. Is there something I should be doing that would enable macruby >> to automatically detect and load the bridgesupport file included in my >> framework? >> >> Cheers, >> Al >> >> >> >> ___ >> >> MacRuby-devel mailing list >> >> [email protected] >> >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> > >> > ___ >> > MacRuby-devel mailing list >> > [email protected] >> > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] copied Proc objects cause crash when used as Objective-C blocks
Hi Alan,
Thanks for reporting that problem in the tracker. In the meantime, keeping a
reference to the Proc object in the Ruby side might work around the problem (as
I suspect that the proc here is being garbage-collected prematurely).
@b = TestBlock.alloc.initWithBlock (@tmp ||= Proc.new { puts "hello
from ruby"})
Laurent
On Nov 19, 2010, at 3:25 AM, Alan Skipp wrote:
> Whoops, sorry about that. I find that I can get away without assigning to
> self in 'init' when doing a quick hack, but certainly not the recommended
> approach, especially when attempting to track down another bug.
> I've amended the initializer now and I still encounter the same problem.
>
> Al
>
> On 19 Nov 2010, at 10:53, Thibault Martin-Lagardette wrote:
>
>> Hi Alan,
>>
>> I didn't look in further details yet, but clearly your initWithBlock method
>> is wrong, it should be:
>>
>> - (id)initWithBlock:(void (^)())aBlock;
>> {
>> if ((self = [super init])) {
>> block = [aBlock copy];
>> NSLog(@"Block: %@", block);
>> block();
>> }
>> return self;
>> }
>>
>> You are not assigning `self` to be equal to what `[super init]` returns, and
>> this is, even without macruby or blocks, prone to crashes :-)
>>
>> Can you try to fix this and then tell us if it's still crashing?
>>
>> --
>> Thibault Martin-Lagardette
>>
>>
>>
>> On Nov 19, 2010, at 10:14, Alan Skipp wrote:
>>
>>> I've been attempting to get an objective-c framework to work with macruby
>>> and I believe I've found a bug in the way ruby Proc objects are copied when
>>> used as objective-c blocks.
>>> The copied block doesn't seem to persist correctly beyond the scope in
>>> which it was copied. It isn't deallocated, but calling it results in a
>>> crash. Typical error messages are:
>>> wrong type NSCFSet (expected Proc) (TypeError)
>>> wrong type NSRectSet (expected Proc) (TypeError)
>>> I'm guessing that there's a pointer to the wrong memory location?
>>>
>>> Here's the Objective-C implementation:
>>>
>>> @implementation TestBlock
>>>
>>> - (id)initWithBlock:(void (^)())aBlock;
>>> {
>>> [super init];
>>> block = [aBlock copy];
>>> NSLog(@"Block: %@", block);
>>> block();
>>> return self;
>>> }
>>>
>>> - (void)callBlock;
>>> {
>>> NSLog(@"block: %@", block);
>>> block();
>>> }
>>>
>>> @end
>>>
>>>
>>> Within 'initWithBlock:', the copied block can be invoked without error.
>>> Attempting to do so from 'callBlock', results in a crash. The test
>>> framework can be used without error when using objective-c.
>>>
>>> Here's the ruby controller code:
>>>
>>> @b = TestBlock.alloc.initWithBlock Proc.new { puts "hello from ruby"}
>>>
>>> # this next line is called from a different scope and causes the crash
>>> @b.callBlock
>>>
>>>
>>> 2010-11-19 08:41:06.620 CallObjectiveCBlocks[7046:a0f] Block:
>>> <__NSAutoBlock__: 0x200be74a0>
>>> hello from ruby
>>>
>>> 2010-11-19 08:41:20.011 CallObjectiveCBlocks[7046:a0f] block:
>>> <__NSAutoBlock__: 0x200be74a0>
>>> 2010-11-19 08:41:20.012 CallObjectiveCBlocks[7046:a0f]
>>> /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/Controller.rb:21:in
>>> `call:': wrong type Array (expected Proc) (TypeError)
>>> from
>>> /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/rb_main.rb:23:in
>>> `'
>>> ___
>>> MacRuby-devel mailing list
>>> [email protected]
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] NSEvent MacRuby (updated)
Hi Andras, Let's try to get this fixed in the upcoming release. Could you file a ticket in our trac? (if not already done, I just had a quick glance at it so far). Thanks, Laurent On Nov 21, 2010, at 7:49 AM, András Zalavári wrote: > Well... Yes my macbook is a 32 bit system... So there not going to be a > solution fro my problem in the near future. Anyway I made a kind of > workaround... > > Thank you for your help! > anyway I hope the bug will be solved. > > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Is is possible to debug a MacRuby Cocoa app?
Hi Ryan, As Jordan mentioned, the debugger is alpha quality :) It should be able to debug Xcode apps assuming you tweak a few things out, but not out of the box, I'm afraid. Also, the code has been neglected a bit as we have been working on other things. If you file a ticket we will try to get things better in the upcoming release. We could then document the process in a short tutorial on the website. Laurent On Nov 21, 2010, at 3:49 PM, Ryan Porter wrote: > Hello, and thank you very much to the developers of MacRuby. It's an amazing > technology and I hope to see it continue to grow. > > I've managed to figure out, after an hour or two of wasted time, that > although MacRuby now includes a debugger, that debugger can't be used to > debug a MacRuby Cocoa app. Not only through XCode, but at all. Is that > correct? The release notes proudly announce that MacRuby now includes a > debugger but they neglect to mention how to use it. After some research I > eventually discovered that there is no way to use the debugger to debug a > Cocoa app. > > If that's true, then lack of a debugger eliminates any benefit that using > Ruby could bring to the Cocoa experience. Objective C syntax is truly nasty, > but if there is no debugger available for Cocoa apps written with MacRuby > then it just doesn't make sense to use Ruby to make a Cocoa app. Especially > with Objective C 2.0's simplified syntax and garbage collection. "You don't > need a debugger for Ruby code", is simply not a realistic solution. TDD and > BDD tools for desktop Cocoa apps are still inadequate, and even with TDD you > often still need a debugger. > > MacRuby isn't going to go very far if developers are forced to revert to > printf debugging to build Cocoa apps. I don't mind if the debugger doesn't > have slick XCode integration like GDB. But there needs to be SOME way to > debug a Cocoa app or else the sensible path for developer productivity on the > Mac will be Objective C 2.0 instead of MacRuby. Sacrificing any hope of > using a debugger to gain relatively minor syntactic improvements is not a > tradeoff that makes any sense. I don't intend to disparage MacRuby, I just > want to share my perspective as both a professional Rubyist and a > professional Cocoa developer. MacRuby is an amazing technology, but to gain > traction as a realistic way to build Cocoa apps it will really need a > debugger that works with Cocoa apps. > > -- > Ryan > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
