I noticed the same thing also (though haven't tested the latest nightly build). I do have a fix for this, but I don't know how to submit a patch. The problem is in the colors.rb where methods are dynamically generated for the color names. Also the image.rb uses an inefficient method for loading images, I have rewrote it to use CGimagesourceref and it is significantly faster loading large image files. I could email my changes to someone if that would be convenient, but probably not until tomorrow.
Al On Wed, 02 Dec 2009 18:44 -0800, "Matt Aimonetti" <mattaimone...@gmail.com> wrote: Please try a nightly build and let me know. Thanks, - Matt On Wed, Dec 2, 2009 at 6:38 PM, Tim Rand <[1]timra...@gmail.com> wrote: I am running 0.5 beta2 not the latest development trunk. I'll try updating. I believe I fixed this bug after 0.5 beta2, what version are you on? - Matt On Wed, Dec 2, 2009 at 3:51 PM, Tim Rand <[2]timra...@gmail.com> wrote: > Though the following code works on macruby 0.4 and mac OS 10.5.8, it no > longer works for me since updating macruby and the OS: > > macruby -e 'require "hotcocoa/graphics"' > -e:1:in `<main>': private method `define_method' called for Class:Class > (NoMethodError) > > I am running: > OS 10.6.2 > MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0, x86_64] > (with ruby version 1.9.0) > > I don't see a define_method call anywhere in the source code in the > /Library/Frameworks/MacRuby.framework/Versions/0.5/usr/lib/rub y/1.9.0/hotcocoa/graphics.rb > file. > > I just want to tinker with HotCocoa::Graphics. > Any advice or explanation would be appreciated. > > Thanks, > Tim > > _______________________________________________ > MacRuby-devel mailing list > [3]macruby-de...@lists.macosforge.org > [4]http://lists.macosforge.org/mailman/listinfo.cgi/macruby-de vel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <[5]http://lists.macosforge.org/pipermail/macruby-devel/attach ments/20091202/7345279f/attachment-0001.html> ------------------------------ Message: 5 Date: Thu, 03 Dec 2009 01:10:55 -0000 From: "MacRuby" <[6]ruby-nore...@macosforge.org> To: undisclosed-recipients:; Cc: [7]macruby-de...@lists.macosforge.org Subject: [MacRuby-devel] [MacRuby] #475: GCD Queues should print their label as their "to_s" method Message-ID: <[8]057.640c7ea76d6c1fd19c556c0bfe2fc...@macosforge.org> Content-Type: text/plain; charset="utf-8" #475: GCD Queues should print their label as their "to_s" method ----------------------------------------+--------------------- -------------- Reporter: ernest.prabha...@? | Owner: lsansone...@? Type: enhancement | Status: new Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: ----------------------------------------+--------------------- -------------- Right no, GCD Queues have a generic (i.e., mostly useless) "to_s" method. Why not just make the GCD "label" method act as to_s: [9]http://github.com/masterkain/macruby/blob/master/gcd.c rb_objc_define_method(cQueue, "to_s", rb_queue_label, 0); That avoids additional API, and lets it generally "do the right thing" -- Ticket URL: <[10]http://www.macruby.org/trac/ticket/475> MacRuby <[11]http://macruby.org/> ------------------------------ Message: 6 Date: Thu, 03 Dec 2009 01:37:26 -0000 From: "MacRuby" <[12]ruby-nore...@macosforge.org> To: undisclosed-recipients:; Cc: [13]macruby-de...@lists.macosforge.org Subject: [MacRuby-devel] [MacRuby] #476: GCD Groups should be a wrapper around dispatch, not its own invocation style Message-ID: <[14]057.6344b7e678c1ff126f8b5030506f0...@macosforge.org> Content-Type: text/plain; charset="utf-8" #476: GCD Groups should be a wrapper around dispatch, not its own invocation style ----------------------------------------+--------------------- -------------- Reporter: ernest.prabha...@? | Owner: lsansone...@? Type: enhancement | Status: new Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: gcd ----------------------------------------+--------------------- -------------- Right now, GCD Groups are treated almost like a Queue, so developers call dispatch on them -- except that: - you need to specify a queue as a parameter -- or use (atypically) have it invisibly invoke the default queue - there's no way to specify synchronous dispatch This works well if you really just want async concurrency, but becomes awkward (and IMHO confusing) for anything else. g = Dispatch::Group.new g.dispatch {work_function(i)}} g.dispatch(q_a) {work_function(i)}} g.dispatch(q_b, false) {work_function(i)}} g.wait I don't know if it is possible, but what I'd prefer is for Groups to take a block *containing* multiple dispatch invocations, and auto-magically associate them with a group. So for example, you could do: g = Dispatch::Group.new g.wait do q_a.dispatch(true) {work_function(i)} q_b.dispatch(false) {work_function(i)} end In this case, the "group" is synchronous so it automatically does a wait until the "child" dispatches complete. For async behavior, simply do: g.on_completion { puts "I'm all done" } g.notify do q_a.dispatch {work_function(i)} q_b.dispatch {work_function(i)} end If you want to add some invocations to the group but neither wait or notify yet, use a "shovel" to add them: g << { q_c.dispatch {work_function(i)} } As a bonus, one could provide a convenience class method for the synchronous case that avoids the need for any variable at all: Dispatch::Group.wait do q_a.dispatch(true) {work_function(i)} q_b.dispatch(false) {work_function(i)} end While this does require you to be more explicit in the concurrency async case, I think this API better reflects the full semantics of GCD groups. Of course, this presumes that queue dispatches would need to check if they're executing inside a group; I'm sure that must be possible, but I don't know what the performance implications might be. Still, I wanted to raise it now before 0.5 is final and people start relying on the current API. -- Ticket URL: <[15]http://www.macruby.org/trac/ticket/476> MacRuby <[16]http://macruby.org/> ------------------------------ Message: 7 Date: Thu, 03 Dec 2009 01:55:50 -0000 From: "MacRuby" <[17]ruby-nore...@macosforge.org> To: undisclosed-recipients:; Cc: [18]macruby-de...@lists.macosforge.org Subject: [MacRuby-devel] [MacRuby] #477: Need GCD wrapper for dispatch_once Message-ID: <[19]057.3a11f4f423762940939bbcc2f9e64...@macosforge.org> Content-Type: text/plain; charset="utf-8" #477: Need GCD wrapper for dispatch_once ----------------------------------------+--------------------- -------------- Reporter: ernest.prabha...@? | Owner: lsansone...@? Type: defect | Status: new Priority: minor | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: ----------------------------------------+--------------------- -------------- We need an API for dispatch_once: [20]http://developer.apple.com/mac/library/documentation/Darw in/Reference/ManPages/man3/dispatch_once.3.html [21]http://developer.apple.com/mac/library/documentation/Perf ormance/Reference/GCD_libdispatch_Ref/Reference/reference.html #//apple_ref/c/func/dispatch_once [22]http://www.opensource.apple.com/source/libdispatch/libdis patch-84.5.1/src/once.h [23]http://www.opensource.apple.com/source/libdispatch/libdis patch-84.5.1/src/once.c Ideally something as simple as: Dispatch::Once.new { run_this_once } The tricky part is that the "Once" would have to allocate (the equivalent of) a global or static dispatch_once_t (i.e., a long). Could that be done with class variables? -- Ticket URL: <[24]http://www.macruby.org/trac/ticket/477> MacRuby <[25]http://macruby.org/> ------------------------------ _______________________________________________ MacRuby-devel mailing list [26]macruby-de...@lists.macosforge.org [27]http://lists.macosforge.org/mailman/listinfo.cgi/macruby-d evel End of MacRuby-devel Digest, Vol 22, Issue 2 ******************************************** _______________________________________________ MacRuby-devel mailing list [28]macruby-de...@lists.macosforge.org [29]http://lists.macosforge.org/mailman/listinfo.cgi/macruby-d evel References 1. mailto:timra...@gmail.com 2. mailto:timra...@gmail.com 3. mailto:MacRuby-devel@lists.macosforge.org 4. http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel 5. http://lists.macosforge.org/pipermail/macruby-devel/attachments/20091202/7345279f/attachment-0001.html 6. mailto:ruby-nore...@macosforge.org 7. mailto:macruby-devel@lists.macosforge.org 8. mailto:057.640c7ea76d6c1fd19c556c0bfe2fc...@macosforge.org 9. http://github.com/masterkain/macruby/blob/master/gcd.c 10. http://www.macruby.org/trac/ticket/475 11. http://macruby.org/ 12. mailto:ruby-nore...@macosforge.org 13. mailto:macruby-devel@lists.macosforge.org 14. mailto:057.6344b7e678c1ff126f8b5030506f0...@macosforge.org 15. http://www.macruby.org/trac/ticket/476 16. http://macruby.org/ 17. mailto:ruby-nore...@macosforge.org 18. mailto:macruby-devel@lists.macosforge.org 19. mailto:057.3a11f4f423762940939bbcc2f9e64...@macosforge.org 20. http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/dispatch_once.3.html 21. http://developer.apple.com/mac/library/documentation/Performance/Reference/GCD_libdispatch_Ref/Reference/reference.html#//apple_ref/c/func/dispatch_once 22. http://www.opensource.apple.com/source/libdispatch/libdispatch-84.5.1/src/once.h 23. http://www.opensource.apple.com/source/libdispatch/libdispatch-84.5.1/src/once.c 24. http://www.macruby.org/trac/ticket/477 25. http://macruby.org/ 26. mailto:MacRuby-devel@lists.macosforge.org 27. http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel 28. mailto:MacRuby-devel@lists.macosforge.org 29. http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel -- Alan Skipp al_sk...@fastmail.fm
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
