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

Alan Skipp al_skipp at fastmail.fm
Thu Dec 3 05:04:01 PST 2009


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"
<mattaimonetti at 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]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
  <[2]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/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-devel at 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-noreply at macosforge.org>
  To: undisclosed-recipients:;
  Cc: [7]macruby-devel at lists.macosforge.org
  Subject: [MacRuby-devel] [MacRuby] #475: GCD Queues should
  print their
         label as their "to_s" method
  Message-ID:
  <[8]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:
   [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-noreply at macosforge.org>
  To: undisclosed-recipients:;
  Cc: [13]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:
  <[14]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: <[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-noreply at macosforge.org>
  To: undisclosed-recipients:;
  Cc: [18]macruby-devel at lists.macosforge.org
  Subject: [MacRuby-devel] [MacRuby] #477: Need GCD wrapper for
         dispatch_once
  Message-ID:
  <[19]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:
   [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-devel at 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-devel at lists.macosforge.org
  [29]http://lists.macosforge.org/mailman/listinfo.cgi/macruby-d
  evel

References

1. mailto:timrandg at gmail.com
2. mailto:timrandg at gmail.com
3. mailto:MacRuby-devel at 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-noreply at macosforge.org
7. mailto:macruby-devel at lists.macosforge.org
8. mailto:057.640c7ea76d6c1fd19c556c0bfe2fc9e8 at 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-noreply at macosforge.org
  13. mailto:macruby-devel at lists.macosforge.org
  14. mailto:057.6344b7e678c1ff126f8b5030506f04c2 at macosforge.org
  15. http://www.macruby.org/trac/ticket/476
  16. http://macruby.org/
  17. mailto:ruby-noreply at macosforge.org
  18. mailto:macruby-devel at lists.macosforge.org
  19. mailto:057.3a11f4f423762940939bbcc2f9e64307 at 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 at lists.macosforge.org
  27. http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
  28. mailto:MacRuby-devel at lists.macosforge.org
  29. http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
-- 
  Alan Skipp
  al_skipp at fastmail.fm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20091203/d63c4e43/attachment-0001.html>


More information about the MacRuby-devel mailing list