[MacRuby-devel] calling Objective-C method with block parameter
Hello everyone,
I'm attempting to call a method on an Objective-C object which takes a block as
its parameter, but I'm not having much luck. I can happily create the object
in Macruby and send the message with a Proc. The NSLog call within the
Objective-C method body succeeds, but the 'block()' doesn't. Am I doing
something obviously wrong here? (I'm using a nightly build from sometime last
week).
This is the Objective-C method:
- (void)callBlock:(void (^)())block;
{
NSLog(@"block: %@", block);
block();
}
Here is the ruby code:
b = TestBlock.new
b.callBlock( Proc.new { puts "hello" } )
The output is as follows:
block: #
Program received signal: “EXC_BAD_ACCESS”.___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] NSEvent MacRuby (updated)
(I'm not sure if the previous mail was sent otherwise sorry for the multiple posts) Hello, I'm new to MacRuby. I found an unexpected behavior of NSEvent. first of all in Cocoa [NSEvent mouseLocation] would return an NSPoint, with the mouse position. MacRuby NSEvent.mouseLocation return an NSPoint, but without the appropriate values. *irb(main):001:0> framework 'cocoa'* *2010-11-15 13:45:35.880 macruby[669:903] +[NSATSGlyphGenerator initialize] invocation. The class is deprecated.* *=> true* *irb(main):002:0> NSEvent.mouseLocation* *=> #* * * it does not even work within a mouseUp method, with an NSEvent instance. I tried the same code on an iMac, and it returns the appropriate code, as a CGPoint. so there must be differences between the two. I even got this warning Message NSATSGlyphGenerator on the MacBook, which I dont on the iMac Please help figure out the solution! Thanks Andras Zalavari I'm using Macbook, and MacRuby 7.0... or 7.1? how to check the version of MacRuby t? ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Neat MacRuby app, HotCocoa, and more!
Leigh,
The impression I got with HotCocoa is that the core MacRuby team was
busy enough with MacRuby to not want to get distracted with helping
develop it. I know that many including myself would be interested in
seeing it expand. (Rich did an awesome job with it, but it seemed to
have a long way to go the last time I used it.)
IMO anything you add would be awesome, especially if you have the time
to continue developing it.
Gary
On 11/13/10 10:08 PM, Leigh Caplan wrote:
Hey everybody,
I wanted to say hi to the list and introduce myself - I've been
lurking for awhile and come by when I need help, but RubyConf has me
all fired up, so I'd like to start engaging more with the community.
My name is Leigh Caplan, and I'm a developer in Seattle, WA. I like
long walks on the beach, dinner by candlelight, and not having to
write my Mac OS X apps in Objective C.
First, I wanted to tell everyone about a potentially useful menu extra
that I created called CobraMenu. It's meant to be a simple "traffic
light" for CI Joe (the super simple/awesome CI server written by the
Github guys). You can find more info at
http://texel.github.com/CobraMenu/ or just clone/fork it from
https://github.com/texel/CobraMenu
Next, developing this got me thinking about HotCocoa, and how it could
evolve into a really useful project in the future. I had a chat w/
Matt Aimonetti today, and he mentioned that Rich Kilmer, while still
interested in the project, both didn't have time to maintain it and
also wasn't convinced that its current goal as a DSL for creating UI
elements was necessarily useful for anything but trivial projects.
Apparently there's also been some discussion to this effect on this
list, but I'm a bit late to the party, so I apologize.
Now, I *can* see a need for a ruby-like DSL for Cocoa, but in my
opinion, it would be much more exciting if we endeavored to wrap other
Cocoa classes and idioms in a loving Ruby-like embrace. Here's a
rudimentary example (very much like something I've done in CobraMenu):
HotCocoa::URLConnection.get('http://google.com') do |c|
c.success { success_callback }
c.failure { failure_callback }
c.error { |e| error_handler.call_something e }
end
I'd be interested to see if other people think this is a good idea. If
so, I can formulate a strategy, and get to work :)
Leigh
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Weird behaviour for a weird line of code
On Nov 14, 2010, at 18:37 , Mark Rada wrote: > Now, when I try this out in macirb: (Case #3) > > require 'uri' > test = URI.parse url unless (url = 'http://macruby.org/').nil? # error > test = URI.parse url unless (url = 'http://wikipedia.org/').nil? # works > > If it doesn't work in the second case, why does it start working in the third > case? First off, I hate this style of coding. If you didn't assign in a conditional you'd avoid all of this crap to begin with. Assigning in conditionals is just a sloppy and error prone way of coding and you should avoid it. This has been a known anti-pattern in any algol-esque language since at least the 80s. That said... This actually has nothing to do with macruby and is an effect of the ruby parser. It is about variable visibility. In case 3: + The first line has "URI.parse url" followed by "unless (url = ...).nil?" + The first 'url' is actually parsed as a method call because the word has never been seen before and wasn't added to the variable table. The second url DOES add url to the variable table. + The second line has the same thing, but by now, "url" has been added to the variable table. This lets everything be parsed as a variable at parse time. Here is how you should code it: > require 'uri' > url = "http://macruby.org/"; > test = URI.parse url if url > url = "http://wikipedia.org/"; > test = URI.parse url if url no variable parse ambiguity. no testing for nil specifically (.nil? is almost NEVER needed, just test for truthiness--imagine what happens when someone sets url to false with your code). clean. readable. Your code all it's nerdiness: s(:block, s(:if, s(:call, s(:lasgn, :url, s(:str, "http://macruby.org/";)), :nil?, s(:arglist)), nil, s(:lasgn, :test, s(:call, s(:const, :URI), :parse, s(:arglist, s(:call, nil, :url, s(:arglist)), # HERE IT IS A CALL s(:if, s(:call, s(:lasgn, :url, s(:str, "http://wikipedia.org/";)), :nil?, s(:arglist)), nil, s(:lasgn, :test, s(:call, s(:const, :URI), :parse, s(:arglist, s(:lvar, :url)) ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Weird behaviour for a weird line of code
On 2010-11-15, at 4:50 PM, Ryan Davis wrote: > > On Nov 14, 2010, at 18:37 , Mark Rada wrote: > >> Now, when I try this out in macirb: (Case #3) >> >> require 'uri' >> test = URI.parse url unless (url = 'http://macruby.org/').nil? # error >> test = URI.parse url unless (url = 'http://wikipedia.org/').nil? # works >> >> If it doesn't work in the second case, why does it start working in the >> third case? > > First off, I hate this style of coding. If you didn't assign in a conditional > you'd avoid all of this crap to begin with. Assigning in conditionals is just > a sloppy and error prone way of coding and you should avoid it. This has been > a known anti-pattern in any algol-esque language since at least the 80s. > > That said... This actually has nothing to do with macruby and is an effect of > the ruby parser. It is about variable visibility. Ah, that is what I was not understanding. Thanks for explaining. > > In case 3: > > + The first line has "URI.parse url" followed by "unless (url = ...).nil?" > + The first 'url' is actually parsed as a method call because the word has > never been seen before and wasn't added to the variable table. The second url > DOES add url to the variable table. > + The second line has the same thing, but by now, "url" has been added to the > variable table. This lets everything be parsed as a variable at parse time. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
