[MacRuby-devel] has anyone else noticed hotcocoa/graphics is no longer working..

Matt Aimonetti mattaimonetti at gmail.com
Wed Dec 2 18:44:25 PST 2009


Please try a nightly build and let me know.

Thanks,

- Matt

On Wed, Dec 2, 2009 at 6:38 PM, Tim Rand <timrandg at 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 at 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 at 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 at macosforge.org>
>> To: undisclosed-recipients:;
>> Cc: macruby-devel at lists.macosforge.org
>> Subject: [MacRuby-devel] [MacRuby] #475: GCD Queues should print their
>>        label as their "to_s" method
>> Message-ID: <057.640c7ea76d6c1fd19c556c0bfe2fc9e8 at 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 at macosforge.org>
>> To: undisclosed-recipients:;
>> Cc: macruby-devel at 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 at 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 at macosforge.org>
>> To: undisclosed-recipients:;
>> Cc: macruby-devel at lists.macosforge.org
>> Subject: [MacRuby-devel] [MacRuby] #477: Need GCD wrapper for
>>        dispatch_once
>> Message-ID: <057.3a11f4f423762940939bbcc2f9e64307 at 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 at 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 at 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/22a966ed/attachment.html>


More information about the MacRuby-devel mailing list