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.
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
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
> automaticall
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 bridgesuppo
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
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 w
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 cur
These structures are currently handled by Foundation's BridgeSupport file
(/System/Library/Frameworks/Foundation.framework/Resources/BridgeSupport/Foundation.bridgesupport)
It's not very humanly readable, but MacRuby understands what this means, and
then knows NSPoint is a struc
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 ma
Hi András,
From these two lines, I am guessing you are running on a 32-bits system :-).
The first warning, about NSATSGlyphGenerator, can be safely ignored. This is
because MacRuby, when registering classes in the runtime, has no choice but to
"wake-up" classes (like the ones in Cocoa that you
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 ret
Can you provide a simple failing example?
On Nov 17, 2010, at 9:26 AM, Martijn Walraven wrote:
> I actually tried this, but the problem seems to be that Protocol is not a
> true class. So if I try to do anything with the protocol parameter from
> MacRuby, I get an error:
>
> *** NSInvocation:
I actually tried this, but the problem seems to be that Protocol is not a true
class. So if I try to do anything with the protocol parameter from MacRuby, I
get an error:
*** NSInvocation: warning: object 0x7fff71192488 of class 'Protocol' does not
implement methodSignatureForSelector: -- troub
13 matches
Mail list logo
