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
Please try a nightly build and let me know.
Thanks,
- Matt
On Wed, Dec 2, 2009 at 6:38 PM, Tim Rand
<timrandg@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 <timrandg@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/ruby/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
> MacRuby-devel@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20091202/7345279f/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 03 Dec 2009 01:10:55 -0000
From: "MacRuby" <ruby-noreply@macosforge.org>
To: undisclosed-recipients:;
Cc: macruby-devel@lists.macosforge.org
Subject: [MacRuby-devel] [MacRuby] #475: GCD Queues should print their
label as their "to_s" method
Message-ID: <057.640c7ea76d6c1fd19c556c0bfe2fc9e8@macosforge.org>
Content-Type: text/plain; charset="utf-8"
#475: GCD Queues should print their label as their "to_s" method
----------------------------------------+-----------------------------------
Reporter: ernest.prabhakar@? | Owner: lsansonetti@?
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:
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: <http://www.macruby.org/trac/ticket/475>
MacRuby <http://macruby.org/>
------------------------------
Message: 6
Date: Thu, 03 Dec 2009 01:37:26 -0000
From: "MacRuby" <ruby-noreply@macosforge.org>
To: undisclosed-recipients:;
Cc: macruby-devel@lists.macosforge.org
Subject: [MacRuby-devel] [MacRuby] #476: GCD Groups should be a
wrapper around dispatch, not its own invocation style
Message-ID: <057.6344b7e678c1ff126f8b5030506f04c2@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.prabhakar@? | Owner: lsansonetti@?
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: <http://www.macruby.org/trac/ticket/476>
MacRuby <http://macruby.org/>
------------------------------
Message: 7
Date: Thu, 03 Dec 2009 01:55:50 -0000
From: "MacRuby" <ruby-noreply@macosforge.org>
To: undisclosed-recipients:;
Cc: macruby-devel@lists.macosforge.org
Subject: [MacRuby-devel] [MacRuby] #477: Need GCD wrapper for
dispatch_once
Message-ID: <057.3a11f4f423762940939bbcc2f9e64307@macosforge.org>
Content-Type: text/plain; charset="utf-8"
#477: Need GCD wrapper for dispatch_once
----------------------------------------+-----------------------------------
Reporter: ernest.prabhakar@? | Owner: lsansonetti@?
Type: defect | Status: new
Priority: minor | Milestone: MacRuby 0.5
Component: MacRuby | Keywords:
----------------------------------------+-----------------------------------
We need an API for dispatch_once:
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/dispatch_once.3.html
http://developer.apple.com/mac/library/documentation/Performance/Reference/GCD_libdispatch_Ref/Reference/reference.html#//apple_ref/c/func/dispatch_once
http://www.opensource.apple.com/source/libdispatch/libdispatch-84.5.1/src/once.h
http://www.opensource.apple.com/source/libdispatch/libdispatch-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: <http://www.macruby.org/trac/ticket/477>
MacRuby <http://macruby.org/>
------------------------------
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
End of MacRuby-devel Digest, Vol 22, Issue 2
********************************************
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel