Re: [MacRuby-devel] sub classing with hot cocoa

[Benjamin Stiglitz]

I am sure there is an easy answer to this question, but I have not  
figured it out after some experimenting (nor can I find an example  
in the examples)


What do I do if i want to subclass (say) an NSView ? And yet still  
employ that subclass with all the rest of the hot cocoa magic? (so  
without using nib/xibs)


I would do this to overwrite the drawRect callback for NSView for  
example - perhaps to do some animation.


class MyView < NSView
  def drawRect(r)

  end
end

or, even better in some cases

a = view(:something)
class << a
  def drawRect(r)

  end
end

-Ben
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] [MacRuby] #171: [trunk/#762] build fails in ripper extension

[MacRuby]

#171: [trunk/#762] build fails in ripper extension
-+--
 Reporter:  [EMAIL PROTECTED]|   Owner:  [EMAIL PROTECTED]  
  
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  MacRuby 0.4  
Component:  MacRuby  |Keywords:  bison, ripper
-+--
 Trunk at both #760 and #762 fails the same way inside the ripper
 extension:

 I have bison 2.4 from macports, running on 10.5.5.

 compiling ripper
 bison -t -v -oy.tab.c ripper.y
 ripper.y:2920.25-26: $$ for the midrule at $6 of `primary' has no declared
 type
 make: *** [ripper.c] Error 1
 rake aborted!
 Command failed with status (1): [./miniruby -I./lib -I.ext/common -I./-
 -r]
 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:971:in `sh'
 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:984:in `call'
 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:984:in `sh'
 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1072:in `sh'
 /Users/roberto/Build/SVN/MacRuby/rakefile:549
 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `call'
 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `execute'
 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `each'
 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `execute'
 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:578:in
 `invoke_with_call_chain'
 /opt/local/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 [...]

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #171: [trunk/#762] build fails in ripper extension

[MacRuby]

#171: [trunk/#762] build fails in ripper extension
-+--
 Reporter:  [EMAIL PROTECTED]|   Owner:  [EMAIL PROTECTED]  
  
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  MacRuby 0.4  
Component:  MacRuby  |Keywords:  bison, ripper
-+--

Comment(by [EMAIL PROTECTED]):

 Sorry, formatting is messed up...

 {{{
 compiling ripper
 bison -t -v -oy.tab.c ripper.y
 ripper.y:2920.25-26: $$ for the midrule at $6 of `primary' has no declared
 type
 make: *** [ripper.c] Error 1
 rake aborted!
 Command failed with status (1): [./miniruby -I./lib -I.ext/common -I./-
 -r]
 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:971:in `sh'
 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:984:in `call'
 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:984:in `sh'
 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1072:in `sh'
 /Users/roberto/Build/SVN/MacRuby/rakefile:549
 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `call'

 }}}

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] HotCocoa Part I

[Rich Morin]

At 10:10 -0500 11/12/08, Richard Kilmer wrote:
>> "HotCocoa is an idiomatic Ruby API that simplifies the configuration
>> and wiring together of complex ObjC/Cocoa classes."
>>
>> I realize this will not be all things to all people, and that some
>> may not see the much value in this. I do, and I think that HotCocoa
>> should NOT try and be all things to all people.  Let me even get
>> more specific.  I don't think that HotCocoa should strive to contain
>> simplifications for all frameworks in Cocoa.
>>
>> If core audio needs to be simplified though a wonderful Ruby API
>> then it should be done with a wonderful Ruby API, but that is not
>> HotCocoa, its a core audio MacRuby library.  Something that uses
>> HotCocoa could also use that wonderfully simplified core audio
>> library.  To try and say every simplified use of ObjC frameworks is
>> included in HotCocoa creates a truly unwieldy beast.

It's clear that HC provides a lot of useful infrastructure for making
Cocoa programming more palatable to Rubyists.  More to the point, it
makes it easy for developers to create even more useful infrastructure.

A large part of HC's value lies in the fact that it's so easy to wrap
ObjC and Cocoa goo in nice Rubyish idioms.  This encourages HC users to
create frameworks as they go along.  Encounter an obnoxious API, write a
framework to wrap it, then get on with creating the app...

Consequently, IMHO, the question of whether HC _should_ include zillions
of random frameworks is rather off the mark.  Clearly, if HC becomes even
slightly popular, community members _will_ be creating these frameworks.

The critical question, then, is how to create an environment that allows
(nay, encourages!) frameworks to be created, tested, polished, documented,
indexed, shared, etc.  My intuition is that GitHub should be part of this,
because it promotes free-flowing cooperation, merging, etc.  However, I'm
quite sure that GitHub isn't the entire solution.  So, ideas are welcome!

-r


P.S.

One specific suggestion is that there should be a set of guidelines for
framework creation.  That is, how do I tell if I'm creating my framework
in a manner that will be usable by other developers, similar in style,
etc?  Some of this can be gleaned from perusal of the code, to be sure,
but explicit guidelines can help to make things clearer...
-- 
http://www.cfcl.com/rdmRich Morin
http://www.cfcl.com/rdm/resume [EMAIL PROTECTED]
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] lazydoc Re: HotCocoa Part I

[Ernest N. Prabhakar, Ph.D.]

Hi Rich,

On Dec 2, 2008, at 2:48 PM, Rich Morin wrote:
The critical question, then, is how to create an environment that  
allows
(nay, encourages!) frameworks to be created, tested, polished,  
documented,
indexed, shared, etc.  My intuition is that GitHub should be part of  
this,
because it promotes free-flowing cooperation, merging, etc.   
However, I'm
quite sure that GitHub isn't the entire solution.  So, ideas are  
welcome!


On the subject of documentation, I was intrigued by the new LazyDoc  
utility from Tap, which auto-generates self-describing documentation  
from the comments:


http://github.com/bahuvrihi/lazydoc/tree/lazydoc-0.1.0

I'm not sure how well this translates from a CLI to an API, but I  
suspect we need something with a similarly low barrier to entry . I'm  
not sure if RubyDoc is accessible enough to be widely adopted by  
people writing HotCocoa plug-ins, and perhaps the added structure of  
coming from Cocoa might enable simpler solutions.


-enp
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] HotCocoa Part I

[Chris McGrath]

On 2 Dec 2008, at 22:48, Rich Morin wrote:

The critical question, then, is how to create an environment that  
allows
(nay, encourages!) frameworks to be created, tested, polished,  
documented,
indexed, shared, etc.  My intuition is that GitHub should be part of  
this,
because it promotes free-flowing cooperation, merging, etc.   
However, I'm
quite sure that GitHub isn't the entire solution.  So, ideas are  
welcome!


One thing I've been considering since watching your RubyConf  
presentation via confreaks is auto-generating documentation about  
what's mapped to what. I haven't looked at the code enough to know if  
it's feasible, but I'd like to see something like:


text_field -> NSTextField (selectable: false, bordered: false, ...)  
#i.e. the defaults


Most of these would be obvious, but are currently "hidden" away down  
in the MacRuby source. I'd like to see mappings both ways, so as  
someone who knows a bit of cocoa I can easily go check if NSFoo has  
been wrapped by someone and what the wrappings are. I love how the  
mappings are implemented, but I won't be able to keep them all in my  
head!


Cheers,

Chris
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] HotCocoa Part I

[Rich Morin]

At 01:27 + 12/3/08, Chris McGrath wrote:
> One thing I've been considering since watching your RubyConf
> presentation via confreaks is ...

Just to be clear, Rich Kilmer is the HC developer that made the
RubyConf presentation; I'm just a MacRuby and HotCocoa wannabe...


> ... auto-generating documentation about what's mapped to what.
> I haven't looked at the code enough to know if it's feasible,
> but I'd like to see something like:
>
> text_field -> NSTextField (selectable: false, bordered: false, ...)
> #i.e. the defaults
>
> Most of these would be obvious, but are currently "hidden" away down
> in the MacRuby source. I'd like to see mappings both ways, so as
> someone who knows a bit of cocoa I can easily go check if NSFoo has
> been wrapped by someone and what the wrappings are. I love how the
> mappings are implemented, but I won't be able to keep them all in my
> head!

OK; here's a partly-baked idea, loosely inspired by Python docstrings.


The HC declarations are (I assume) stashing information away in some
sort of data structure.  If not, they certainly could be (:-).  Once
the information is available at runtime, any HC script could retrieve
them for use in online documentation.

Of course, as RK indicates, HC is lazy about loading frameworks.  So,
a comprehensive documentation generator would have to force loading of
all possible frameworks.

It may also be that HC doesn't store as much information as we'd like
to have in the docs.  No problem; add a few more methods (etc) to let
developers add these "annotations".


-r
-- 
http://www.cfcl.com/rdmRich Morin
http://www.cfcl.com/rdm/resume [EMAIL PROTECTED]
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] HotCocoa Part I

[Chris McGrath]

On 3 Dec 2008, at 00:45, Rich Morin wrote:


At 01:27 + 12/3/08, Chris McGrath wrote:

One thing I've been considering since watching your RubyConf
presentation via confreaks is ...


Just to be clear, Rich Kilmer is the HC developer that made the
RubyConf presentation; I'm just a MacRuby and HotCocoa wannabe...



Ooops, I must have some sort of richlexia, you aren't the first two  
I've got confused!



... auto-generating documentation about what's mapped to what.
I haven't looked at the code enough to know if it's feasible,
but I'd like to see something like:

text_field -> NSTextField (selectable: false, bordered: false, ...)
#i.e. the defaults

Most of these would be obvious, but are currently "hidden" away down
in the MacRuby source. I'd like to see mappings both ways, so as
someone who knows a bit of cocoa I can easily go check if NSFoo has
been wrapped by someone and what the wrappings are. I love how the
mappings are implemented, but I won't be able to keep them all in my
head!


OK; here's a partly-baked idea, loosely inspired by Python docstrings.


The HC declarations are (I assume) stashing information away in some
sort of data structure.  If not, they certainly could be (:-).  Once
the information is available at runtime, any HC script could retrieve
them for use in online documentation.

Of course, as RK indicates, HC is lazy about loading frameworks.  So,
a comprehensive documentation generator would have to force loading of
all possible frameworks.

It may also be that HC doesn't store as much information as we'd like
to have in the docs.  No problem; add a few more methods (etc) to let
developers add these "annotations".




On first skim, it seems that as well as adding ruby methods and  
constants, lib/hotcocoa/mapping.rb could be persuaded to do something  
like that. I'd envisage this being a tool you could run on a mapping  
file to spit out html / rdoc / whatever. I don't have time this week  
but I'd like to look into something like this soon.


Cheers,

Chris
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] HotCocoa Part I

[Richard Kilmer]

On Dec 2, 2008, at 9:00 PM, Chris McGrath wrote:



On 3 Dec 2008, at 00:45, Rich Morin wrote:


At 01:27 + 12/3/08, Chris McGrath wrote:

One thing I've been considering since watching your RubyConf
presentation via confreaks is ...


Just to be clear, Rich Kilmer is the HC developer that made the
RubyConf presentation; I'm just a MacRuby and HotCocoa wannabe...



Ooops, I must have some sort of richlexia, you aren't the first two  
I've got confused!


Sorry guys, just catching up with this thread...







... auto-generating documentation about what's mapped to what.
I haven't looked at the code enough to know if it's feasible,
but I'd like to see something like:

text_field -> NSTextField (selectable: false, bordered: false, ...)
#i.e. the defaults

Most of these would be obvious, but are currently "hidden" away down
in the MacRuby source. I'd like to see mappings both ways, so as
someone who knows a bit of cocoa I can easily go check if NSFoo has
been wrapped by someone and what the wrappings are. I love how the
mappings are implemented, but I won't be able to keep them all in my
head!


OK; here's a partly-baked idea, loosely inspired by Python  
docstrings.



The HC declarations are (I assume) stashing information away in some
sort of data structure.  If not, they certainly could be (:-).  Once
the information is available at runtime, any HC script could retrieve
them for use in online documentation.

Of course, as RK indicates, HC is lazy about loading frameworks.  So,
a comprehensive documentation generator would have to force loading  
of

all possible frameworks.

It may also be that HC doesn't store as much information as we'd like
to have in the docs.  No problem; add a few more methods (etc) to let
developers add these "annotations".



The mapping files do create data structures, I was totally going to  
get these to produce documentation on what was mapped, what the  
defaults were, what custom methods exist, etc.  Its pretty easy to do  
I think.  The issue I ran into was I want the rest of the  
documentation for the class.  All the indexes for the API docs are in  
SQLite DBs (although not documented).  If we could extract that and  
make an integrative documentation browser it would help a lot for  
folks trying to figure out what to do.







On first skim, it seems that as well as adding ruby methods and  
constants, lib/hotcocoa/mapping.rb could be persuaded to do  
something like that. I'd envisage this being a tool you could run on  
a mapping file to spit out html / rdoc / whatever. I don't have time  
this week but I'd like to look into something like this soon.


Cheers,

Chris
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] [MacRuby] #172: resurrection error

[MacRuby]

#172: resurrection error
--+-
 Reporter:  [EMAIL PROTECTED]  |   Owner:  [EMAIL PROTECTED]
 Type:  defect|  Status:  new  
 Priority:  minor |   Milestone:  MacRuby 0.4  
Component:  MacRuby   |Keywords:   
--+-
 I am trying to use some existing ruby code in my core data document based
 app.  After switching the application over to MacRuby I get a resurrection
 error upon closing the document's main window and opening a new document.
 The error is similar to the following:

  malloc: *** resurrection error for object 0x10f77a0:
 auto_zone_write_barrier: _NSThreadPerformInfo.argument[32](0x10b04a0)[12]
 = NSTrackingArea[48](0x10f77a0)

 I have been able to recreate this problem in a very simple application
 based on the core data document based application template.  The project
 is attached.  I have tested with the 0.3 release and revision 762 in the
 testing branch.

 I am not 100% sure if this is a defect in MacRuby or an error in my
 project.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #70: Need a RubyCocoa compatible layer

[MacRuby]

#70: Need a RubyCocoa compatible layer
---+
 Reporter:  [EMAIL PROTECTED]  |   Owner:  [EMAIL PROTECTED]
 Type:  defect |  Status:  new
 Priority:  blocker|   Milestone:  MacRuby 1.0
Component:  MacRuby|Keywords: 
---+
Changes (by [EMAIL PROTECTED]):

  * milestone:  MacRuby 0.4 => MacRuby 1.0


-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #157: MacRuby/miniruby segfaults while building

[MacRuby]

#157: MacRuby/miniruby segfaults while building
-+--
 Reporter:  [EMAIL PROTECTED]  |Owner:  [EMAIL PROTECTED]   
 
 Type:  defect   |   Status:  closed   
 Priority:  blocker  |Milestone:  MacRuby 0.4  
Component:  MacRuby  |   Resolution:  fixed
 Keywords:   |  
-+--
Changes (by [EMAIL PROTECTED]):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  => MacRuby 0.4


-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #89: [RubyCocoa Layer] Need to implement some of the RubyCocoa C API

[MacRuby]

#89: [RubyCocoa Layer] Need to implement some of the RubyCocoa C API
---+
 Reporter:  [EMAIL PROTECTED]  |   Owner:  [EMAIL PROTECTED]
 Type:  defect |  Status:  new  
 Priority:  blocker|   Milestone:  MacRuby 1.0  
Component:  MacRuby|Keywords:   
---+
Changes (by [EMAIL PROTECTED]):

  * milestone:  MacRuby 0.4 => MacRuby 1.0


-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #69: [RubyCocoa Layer] method_missing like behaviour for pure Objective-C objects that try to send messages to pure Ruby objects.

[MacRuby]

#69: [RubyCocoa Layer] method_missing like behaviour for pure Objective-C
objects that try to send messages to pure Ruby objects.
-+--
 Reporter:  [EMAIL PROTECTED]  |   Owner:  [EMAIL PROTECTED]
 Type:  enhancement  |  Status:  new  
 Priority:  trivial  |   Milestone:  MacRuby 1.0  
Component:  MacRuby  |Keywords:  rubycocoa layer  
-+--
Changes (by [EMAIL PROTECTED]):

  * milestone:  MacRuby 0.4 => MacRuby 1.0


-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] [MacRuby] #173: Need to expose the SVN revision number as a constant

[MacRuby]

#173: Need to expose the SVN revision number as a constant
---+
 Reporter:  [EMAIL PROTECTED]  |   Owner:  [EMAIL PROTECTED]
 Type:  defect |  Status:  new  
 Priority:  blocker|   Milestone:  MacRuby 1.0  
Component:  MacRuby|Keywords:   
---+
 It would be great for debugging purposes to expose the SVN revision number
 as a constant in !MacRuby. Maybe {{{MACRUBY_REVISION}}}.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #131: Dictionary arg not accepted

[MacRuby]

#131: Dictionary arg not accepted
-+--
 Reporter:  [EMAIL PROTECTED]   |Owner:  [EMAIL PROTECTED]  
  
 Type:  defect   |   Status:  closed   
 Priority:  major|Milestone:  MacRuby 0.4  
Component:  MacRuby  |   Resolution:  fixed
 Keywords:   |  
-+--
Changes (by [EMAIL PROTECTED]):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 The Pointer class was introduced in MacRuby trunk to specifically address
 these problems.

 {{{
   pattributes = Pointer.new_with_type('@')
   perror = Pointer.new_with_type('@')
   o = NSAttributedString.alloc.initWithData(data,
 options:NSCharacterEncodingDocumentOption, documentAttributes:pattributes,
 error:perror);
   unless o
 p perror[0]
   else
 p pattributes[0]
   end
 }}}

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] sub classing with hot cocoa

[John Shea]

Hi Ben,
thanks for your answer.

I tried that initially, but my subclass was having problems being  
added to the layout view.


Anyway - somehow I got something going a little further - the  
important thing was to have a create method which has :  
alloc.initWithFrame([0, 0, *GameSize]) in my NSView subclass...


I did not get much further than painting black (transparency etc did  
not work) - but its on the back burner while I experiment a bit more  
with plain MacRuby.


Cheers and thanks,
John

On Dec 2, 2008, at 10:37 PM, Benjamin Stiglitz wrote:

I am sure there is an easy answer to this question, but I have not  
figured it out after some experimenting (nor can I find an example  
in the examples)


What do I do if i want to subclass (say) an NSView ? And yet still  
employ that subclass with all the rest of the hot cocoa magic? (so  
without using nib/xibs)


I would do this to overwrite the drawRect callback for NSView for  
example - perhaps to do some animation.


class MyView < NSView
 def drawRect(r)

 end
end

or, even better in some cases

a = view(:something)
class << a
 def drawRect(r)

 end
end

-Ben
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] HotCocoa Part I

[John Shea]

I think its interesting that Hot Cocoa in inspiring such different  
ideas, I must admit my thoughts had not run anywhere as complex as  
those below.


My first thought was "Wow! I can make a generic (or  fairly static)  
launcher and get it to load remotely both my view and model from ruby  
files! Thats my RIA issue solved!"


I experimented and sure enough I could deliver to my client (me in  
this experiment ;-) ) rapidly changing versions of a beautiful GUI app  
(1 button) by only changing the source file on the server.


But maybe this is "old hat"?

J


On Dec 2, 2008, at 11:48 PM, Rich Morin wrote:


At 10:10 -0500 11/12/08, Richard Kilmer wrote:

"HotCocoa is an idiomatic Ruby API that simplifies the configuration
and wiring together of complex ObjC/Cocoa classes."

I realize this will not be all things to all people, and that some
may not see the much value in this. I do, and I think that HotCocoa
should NOT try and be all things to all people.  Let me even get
more specific.  I don't think that HotCocoa should strive to contain
simplifications for all frameworks in Cocoa.

If core audio needs to be simplified though a wonderful Ruby API
then it should be done with a wonderful Ruby API, but that is not
HotCocoa, its a core audio MacRuby library.  Something that uses
HotCocoa could also use that wonderfully simplified core audio
library.  To try and say every simplified use of ObjC frameworks is
included in HotCocoa creates a truly unwieldy beast.


It's clear that HC provides a lot of useful infrastructure for making
Cocoa programming more palatable to Rubyists.  More to the point, it
makes it easy for developers to create even more useful  
infrastructure.


A large part of HC's value lies in the fact that it's so easy to wrap
ObjC and Cocoa goo in nice Rubyish idioms.  This encourages HC users  
to
create frameworks as they go along.  Encounter an obnoxious API,  
write a

framework to wrap it, then get on with creating the app...

Consequently, IMHO, the question of whether HC _should_ include  
zillions
of random frameworks is rather off the mark.  Clearly, if HC becomes  
even
slightly popular, community members _will_ be creating these  
frameworks.


The critical question, then, is how to create an environment that  
allows
(nay, encourages!) frameworks to be created, tested, polished,  
documented,
indexed, shared, etc.  My intuition is that GitHub should be part of  
this,
because it promotes free-flowing cooperation, merging, etc.   
However, I'm
quite sure that GitHub isn't the entire solution.  So, ideas are  
welcome!


-r


P.S.

One specific suggestion is that there should be a set of guidelines  
for
framework creation.  That is, how do I tell if I'm creating my  
framework

in a manner that will be usable by other developers, similar in style,
etc?  Some of this can be gleaned from perusal of the code, to be  
sure,

but explicit guidelines can help to make things clearer...
--
http://www.cfcl.com/rdmRich Morin
http://www.cfcl.com/rdm/resume [EMAIL PROTECTED]
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #165: Embeddable MacRuby.framework misses the BridgeSupport dylib files

[MacRuby]

#165: Embeddable MacRuby.framework misses the BridgeSupport dylib files
-+--
 Reporter:  [EMAIL PROTECTED]   |Owner:  [EMAIL 
PROTECTED]
 Type:  defect   |   Status:  closed   
 Priority:  blocker  |Milestone:  MacRuby 0.4  
Component:  MacRuby  |   Resolution:  fixed
 Keywords:  crash,bridge support,gc  |  
-+--
Changes (by [EMAIL PROTECTED]):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 I committed the remaining changes as part of r765.

 For HotCocoa projects, {{{macrake deploy}}} will copy the .dylib files.

 For Xcode projects, a {{{Embed MacRuby}}} target is now installed as part
 of MacRuby. You can add the target to your project and building the target
 should embed MacRuby.framework inside the application bundle, change the
 linker install name and copy the .dylib files.

 The 'build_as_embeddable' Rakefile configuration variable has been
 removed, since it's no longer necessary.

 I will make sure this 'feature' will be appropriately documented in our
 future cookbook.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel