An item of curiosity more than anything else... I note that on the MacRuby.org web site, under the heading of "Why MacRuby?" the subheading of "Interpreter Performance"... it makes the claim that MacRuby is using YARV. Is this still the case? I was under the (perhaps mistaken) impression that LLVM was used as a replacement for YARV. Scott
You are correct, the website would need an update. - Matt On Thu, Jun 3, 2010 at 2:53 PM, Scott Thompson <easco@mac.com> wrote:
An item of curiosity more than anything else...
I note that on the MacRuby.org web site, under the heading of "Why MacRuby?" the subheading of "Interpreter Performance"... it makes the claim that MacRuby is using YARV. Is this still the case? I was under the (perhaps mistaken) impression that LLVM was used as a replacement for YARV.
Scott
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi, yesterday I did my first steps with GCD: parsing a very big CSV-file, processing and filtering it and displaying the result in a table view. Before GCD the UI was blocked for more than a minute, now the user can continue working instantly. Hey that’s really, really great! There are some issues I don’t understand: 1. @job.group.notify(Dispatch::Queue.main) {} # gives an error... @job.group.notify(Dispatch::Queue.concurrent) {} # …..while is working 2. @job.group.notify(Dispatch::Queue.concurrent) {} # the block is called twice or more times 3. the proxy object does not work here (I’m not sure, that I am using it correctly) I made a small Xcode project demo out my project and attached it to this mail. (you can multi-click on the job button) - Bernd ###### require 'dispatch' class AppController attr_accessor :calculations, :running def initialize self.calculations = [] @prefix = 1 @job = Dispatch::Job.new #the main queue is used here because the UI is bound to the calculations array @calc_queue = Dispatch::Queue.main end def calc_sync &block @calc_queue.async { block.call } end def nextPrefix prefix = @prefix @prefix += 1 prefix end def calc1 # @calc_proxy = Dispatch::Proxy.new(self.calculations,@job.group,@calc_queue) @job.add do prefix = nextPrefix 10.times do |i| dur = rand / 4 + 0.2 sleep(dur) c = Calculation.new("#{prefix}:#{i}",dur) calc_sync { self.calculations += [c] } # proxy does not work here: # @calc_proxy += [c] end #NSLog self.calculations.inspect end # why can the notify block be called twice ore more? # if true if !running self.running = true # notifying on the main queue is crashing here: # @job.group.notify(@calc_queue) { NSLog "notify“; self.running = false } @job.group.notify(Dispatch::Queue.concurrent) { NSLog "notify"; self.running = false } end end def jobAction sender calc1 end def clearAction sender self.calculations = [] end end
Hi Bernd, On Jun 4, 2010, at 1:28 AM, B. Ohr wrote:
Hi,
yesterday I did my first steps with GCD: parsing a very big CSV-file, processing and filtering it and displaying the result in a table view. Before GCD the UI was blocked for more than a minute, now the user can continue working instantly. Hey that’s really, really great!
:-)
There are some issues I don’t understand:
:-(
1. @job.group.notify(Dispatch::Queue.main) {} # gives an error... @job.group.notify(Dispatch::Queue.concurrent) {} # …..while is working
2. @job.group.notify(Dispatch::Queue.concurrent) {} # the block is called twice or more times
Hmm, you should NOT need to call "group" on the @job for normal usage. Could you just use "@job.join" to get the behavior you want?
3. the proxy object does not work here (I’m not sure, that I am using it correctly)
Yeah, the "+=" thing actually replaces the -variable- instead of mutating the object, so it won't do what you want. Look at the README.rdoc for more details: http://github.com/masterkain/macruby/tree/master/lib/dispatch/ Sorry about the formatting... -- Ernie P.
I made a small Xcode project demo out my project and attached it to this mail. (you can multi-click on the job button)
- Bernd
######
require 'dispatch'
class AppController
attr_accessor :calculations, :running
def initialize self.calculations = [] @prefix = 1 @job = Dispatch::Job.new #the main queue is used here because the UI is bound to the calculations array @calc_queue = Dispatch::Queue.main end
def calc_sync &block @calc_queue.async { block.call } end
def nextPrefix prefix = @prefix @prefix += 1 prefix end
def calc1 # @calc_proxy = Dispatch::Proxy.new(self.calculations,@job.group,@calc_queue) @job.add do prefix = nextPrefix 10.times do |i| dur = rand / 4 + 0.2 sleep(dur) c = Calculation.new("#{prefix}:#{i}",dur) calc_sync { self.calculations += [c] } # proxy does not work here: # @calc_proxy += [c] end #NSLog self.calculations.inspect end # why can the notify block be called twice ore more? # if true if !running self.running = true # notifying on the main queue is crashing here: # @job.group.notify(@calc_queue) { NSLog "notify“; self.running = false } @job.group.notify(Dispatch::Queue.concurrent) { NSLog "notify"; self.running = false } end end
def jobAction sender calc1 end
def clearAction sender self.calculations = [] end
end
<gcd_demo.zip>
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi Ernest, Am 04.06.2010 um 19:03 schrieb Ernest N. Prabhakar, Ph.D.:
Hmm, you should NOT need to call "group" on the @job for normal usage.
Could you just use "@job.join" to get the behavior you want?
Thanks, I am using join now! Unfortunately join is crashing too with the main queue (Dispatch::Queue.concurrent is working): $ macruby -r dispatch -e 'Dispatch::Job.new {sleep 1}.join(Dispatch::Queue.main) {puts "!"}' /Library/Frameworks/MacRuby.framework/Versions/0.7/usr/lib/ruby/1.9.0/dispatch/job.rb:29:in `join:': expected Queue object, but got Dispatch::Queue (ArgumentError) from /Developer/Examples/Ruby/MacRuby/Scripts/-e:1:in `<main>’ - Bernd
Hi Bernd, Hmm. Just got around to looking at this. I'm stumped. I added better diagnostics to gcd.c, and wrote up the bug for Laurent: Ticket URL: <http://www.macruby.org/trac/ticket/796> #796: Dispatch::Queue.main created with a different Queue class?!? -- Ernie P.
Not sure if macruby.org cares, but a search for macruby @ apple.com comes up with no links, but a page with MacRuby 0.4 (not 0.6) ... also in need of an update... On Thu, 3 Jun 2010 19:17:56 -0700 Matt Aimonetti <mattaimonetti@gmail.com> wrote:
You are correct, the website would need an update.
- Matt
On Thu, Jun 3, 2010 at 2:53 PM, Scott Thompson <easco@mac.com> wrote:
An item of curiosity more than anything else...
I note that on the MacRuby.org web site, under the heading of "Why MacRuby?" the subheading of "Interpreter Performance"... it makes the claim that MacRuby is using YARV. Is this still the case? I was under the (perhaps mistaken) impression that LLVM was used as a replacement for YARV.
Scott
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (5)
-
B. Ohr
-
Ernest N. Prabhakar, Ph.D.
-
macruby＠djc.net
-
Matt Aimonetti
-
Scott Thompson