[MacRuby-devel] MacRuby, changing the Ruby ecosystem

[Matt Aimonetti]

I wrote a blog post explaining why I think MacRuby is a game changer, feel
free to let me know what you think.

http://merbist.com/2009/05/27/macruby-changing-the-ruby-ecosystem/

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

Re: [MacRuby-devel] Using performRubySelector

[Jeremy Voorhis]

Mike,

Is your code available anywhere, e.g. on github? I haven't looked at
the PyObjC code myself, but I'd be interested in having really decent
CoreMIDI support available in MacRuby.

Btw, when C extensions are supported, simple apps will be able to use
my MusicPlayer lib at
http://github.com/jvoorhis/music_player/tree/master, which wraps much
of the MusicPlayer/MusicSequence api in AudioToolbox.framework. It's
short on documentation, but it's easy to get up and running on MRI
1.8.x or 1.9.1.

Best,

Jeremy

On Wed, May 27, 2009 at 11:25 PM, Mike Laurence  wrote:
> Hmmm... I'm doing several things different, perhaps one or more of
> them are impossible :-)
>
> Basically, I'm trying to get MIDI support into Ruby via the PYMIDI
> obj-c library, which is really just a wrapper around CoreMIDI. One way
> I had thought of: create an additional obj-c class (MidiReceiver)
> which processes incoming packets for a given MIDI source and then call
> methods such as "note", "controlChange", "clockTick", etc. This
> MidiReceiver class can then be overridden by a custom ruby class that
> contains those same methods.
>
> Here is a quick version of the MidiReceiver class (with only the
> clockTick method for simplicity):
>
> - MidiReceiver --
>
> #import 
> #include 
>
> @interface MidiReceiver : NSObject
>
> - (void) processMIDIPacket: (MIDIPacket*) packet;
> - (void) clockTick;
>
> @end
>
> @implementation MidiReceiver
>
> - (void) processMIDIPacket: (MIDIPacket*) packet {
>    if (packet->length > 0) {
>
>        int statusByte = packet->data[0];
>        int status = statusByte >= 0xf0 ? statusByte : statusByte >> 4 << 4;
>
>        switch (status) {
>        case 0x90: // Note on, etc...
>        case 0xf8: // Clock tick
>            [self performRubySelector:@selector(clockTick)];
>            break;
>        }
>    }
> }
>
> - (void) clockTick {
> }
>
> @end
>
> 
>
> Then, I have a ruby subclass of MidiReceiver that overrides clockTick, etc.:
>
> class LiveMidiReceiver < MidiReceiver
>  def clockTick
>    puts "tick!"
>  end
> end
>
> And then, in my Ruby ApplicationController, I'm finding the MIDI
> source and adding an instance of LiveMidiReceiver as a MIDI receiver:
>
> @src = PYMIDIManager.sharedInstance.realSources.find{ |s|
> s.displayName == 'KONTROL49 PORT A' }
> receiver = LiveMidiReceiver.new
> @src.addReceiver(receiver)
>
> The LiveMidiReceiver instance, upon receiving a midi packet, is called
> properly up to the point of the performRubySelector, but thereafter it
> launches into the debugger with EXC_BAD_ACCESS messages or other
> unsightly stack dumps.
>
> ---
>
> An even *better* interface would be to have the "clockTick" and other
> calls be performable on an arbitrary ruby object without having to
> subclass MidiReceiver (e.g., have MidiReceiver send "clockTick", etc.
> to a delegate object which has been created solely in Ruby). I tried
> that and it gave me similar results, although strangely it only
> crashed the first time on a clean build - thereafter I saw no crashes,
> but still no confirmation of ruby method calls either.
>
> To test that, I just added a delegate object to MidiReceiver, and then
> I changed the clockTick recipient from self to delegate:
>
> [delegate performRubySelector:@selector(clockTick)];
>
> Then set receiver.delegate = self in my ApplicationController. I'll
> bet I need some more hooks than that, although it sure would be nice
> to send ruby messages from obj-c willy-nilly :-)
>
> ---
>
> I hope I'm making some sense here! I greatly appreciate any info that
> you can send my way. Hopefully when I get this all figured out I can
> write a nice, fat blog post about it :-)
>
> Regards,
> Mike Laurence
>
> On Wed, May 27, 2009 at 8:18 PM, Laurent Sansonetti
>  wrote:
>> Hi Mike,
>>
>> On May 26, 2009, at 5:45 PM, Mike Laurence wrote:
>>
>>> Hello,
>>>
>>> I'm trying to get some obj-c code to talk back to my ruby. After
>>> encountering some "EXC_BAD_ACCESS" messages and scouring the web, I've
>>> concluded that I'm probably supposed to use performRubySelector
>>> instead of just expecting selectors to work when overridden by ruby
>>> subclasses, etc.
>>>
>>> What is the preferred way to get this to work? I looked through some
>>> of Elysium's old code (which used performRubySelector), but I'm having
>>> trouble wrapping my head around how you're supposed to use the MacRuby
>>> sharedRuntime to get things to happen. If someone could give me a
>>> quick example of how to call arbitrary ruby methods, I would highly
>>> appreciate it.
>>>
>>> Of course, if I'm completely off base and there's some other way to
>>> call ruby code, please let me know!
>>
>> Calling Ruby from Objective-C can be problematic, depending if you want to
>> call a pure Ruby method or a Ruby method that overrides an Objective-C one.
>> If you want to dispatch the method by yourself (and if it's a Ruby method
>> that override

Re: [MacRuby-devel] Using performRubySelector

[Matt Aimonetti]

I second what Jeremy said. A nice Midi wrapper would be great.
Jeremy, regarding your MusicPlayer lib, the other option is to port it to
FFI and therefore making it JRuby and MacRuby compatible.

- Matt

On Thu, May 28, 2009 at 10:32 AM, Jeremy Voorhis  wrote:

> Mike,
>
> Is your code available anywhere, e.g. on github? I haven't looked at
> the PyObjC code myself, but I'd be interested in having really decent
> CoreMIDI support available in MacRuby.
>
> Btw, when C extensions are supported, simple apps will be able to use
> my MusicPlayer lib at
> http://github.com/jvoorhis/music_player/tree/master, which wraps much
> of the MusicPlayer/MusicSequence api in AudioToolbox.framework. It's
> short on documentation, but it's easy to get up and running on MRI
> 1.8.x or 1.9.1.
>
> Best,
>
> Jeremy
>
> On Wed, May 27, 2009 at 11:25 PM, Mike Laurence 
> wrote:
> > Hmmm... I'm doing several things different, perhaps one or more of
> > them are impossible :-)
> >
> > Basically, I'm trying to get MIDI support into Ruby via the PYMIDI
> > obj-c library, which is really just a wrapper around CoreMIDI. One way
> > I had thought of: create an additional obj-c class (MidiReceiver)
> > which processes incoming packets for a given MIDI source and then call
> > methods such as "note", "controlChange", "clockTick", etc. This
> > MidiReceiver class can then be overridden by a custom ruby class that
> > contains those same methods.
> >
> > Here is a quick version of the MidiReceiver class (with only the
> > clockTick method for simplicity):
> >
> > - MidiReceiver --
> >
> > #import 
> > #include 
> >
> > @interface MidiReceiver : NSObject
> >
> > - (void) processMIDIPacket: (MIDIPacket*) packet;
> > - (void) clockTick;
> >
> > @end
> >
> > @implementation MidiReceiver
> >
> > - (void) processMIDIPacket: (MIDIPacket*) packet {
> >if (packet->length > 0) {
> >
> >int statusByte = packet->data[0];
> >int status = statusByte >= 0xf0 ? statusByte : statusByte >> 4 <<
> 4;
> >
> >switch (status) {
> >case 0x90: // Note on, etc...
> >case 0xf8: // Clock tick
> >[self performRubySelector:@selector(clockTick)];
> >break;
> >}
> >}
> > }
> >
> > - (void) clockTick {
> > }
> >
> > @end
> >
> > 
> >
> > Then, I have a ruby subclass of MidiReceiver that overrides clockTick,
> etc.:
> >
> > class LiveMidiReceiver < MidiReceiver
> >  def clockTick
> >puts "tick!"
> >  end
> > end
> >
> > And then, in my Ruby ApplicationController, I'm finding the MIDI
> > source and adding an instance of LiveMidiReceiver as a MIDI receiver:
> >
> > @src = PYMIDIManager.sharedInstance.realSources.find{ |s|
> > s.displayName == 'KONTROL49 PORT A' }
> > receiver = LiveMidiReceiver.new
> > @src.addReceiver(receiver)
> >
> > The LiveMidiReceiver instance, upon receiving a midi packet, is called
> > properly up to the point of the performRubySelector, but thereafter it
> > launches into the debugger with EXC_BAD_ACCESS messages or other
> > unsightly stack dumps.
> >
> > ---
> >
> > An even *better* interface would be to have the "clockTick" and other
> > calls be performable on an arbitrary ruby object without having to
> > subclass MidiReceiver (e.g., have MidiReceiver send "clockTick", etc.
> > to a delegate object which has been created solely in Ruby). I tried
> > that and it gave me similar results, although strangely it only
> > crashed the first time on a clean build - thereafter I saw no crashes,
> > but still no confirmation of ruby method calls either.
> >
> > To test that, I just added a delegate object to MidiReceiver, and then
> > I changed the clockTick recipient from self to delegate:
> >
> > [delegate performRubySelector:@selector(clockTick)];
> >
> > Then set receiver.delegate = self in my ApplicationController. I'll
> > bet I need some more hooks than that, although it sure would be nice
> > to send ruby messages from obj-c willy-nilly :-)
> >
> > ---
> >
> > I hope I'm making some sense here! I greatly appreciate any info that
> > you can send my way. Hopefully when I get this all figured out I can
> > write a nice, fat blog post about it :-)
> >
> > Regards,
> > Mike Laurence
> >
> > On Wed, May 27, 2009 at 8:18 PM, Laurent Sansonetti
> >  wrote:
> >> Hi Mike,
> >>
> >> On May 26, 2009, at 5:45 PM, Mike Laurence wrote:
> >>
> >>> Hello,
> >>>
> >>> I'm trying to get some obj-c code to talk back to my ruby. After
> >>> encountering some "EXC_BAD_ACCESS" messages and scouring the web, I've
> >>> concluded that I'm probably supposed to use performRubySelector
> >>> instead of just expecting selectors to work when overridden by ruby
> >>> subclasses, etc.
> >>>
> >>> What is the preferred way to get this to work? I looked through some
> >>> of Elysium's old code (which used performRubySelector), but I'm having
> >>> trouble wrapping my head around how you're supposed to use the MacRuby

Re: [MacRuby-devel] Using performRubySelector

[Jeremy Voorhis]

I'd love to do it in FFI, but getting this far in C was a lot of work!

... so here's another crackpot idea of mine. Another project I have
been following is the Pure Language
. It aims to be a simple,
interpreted functional language based on term-rewriting, and also has
an LLVM JIT compiler. Using LLVM, they support a literal syntax for
declaring foreign functions.

To assist in creating wrappers for libraries, they created a tool
called pure-gen that parses C header files and dumps out a .pure file
containing FFI declarations. The tool is written in Haskell using a
module called Language.C, but I wonder if we could bootstrap something
similar by wrapping up Clang's libparse. They've managed to create
wrappers for gsl, gtk+ and some other libraries by starting with the
generated FFI decls, and adding some syntactic sugar and abstraction
within Pure as appropriate.

Implementing such a tool is probably going to take a lot of effort,
but the benefits are pretty clear – especially since generated
wrappers might be usable in JRuby and MRI. I also don't know how much
this overlaps with BridgeSupport, but I just wanted to put the idea
out there.

Best,

Jeremy

On Thu, May 28, 2009 at 10:38 AM, Matt Aimonetti
 wrote:
> I second what Jeremy said. A nice Midi wrapper would be great.
> Jeremy, regarding your MusicPlayer lib, the other option is to port it to
> FFI and therefore making it JRuby and MacRuby compatible.
>
> - Matt
>
> On Thu, May 28, 2009 at 10:32 AM, Jeremy Voorhis  wrote:
>>
>> Mike,
>>
>> Is your code available anywhere, e.g. on github? I haven't looked at
>> the PyObjC code myself, but I'd be interested in having really decent
>> CoreMIDI support available in MacRuby.
>>
>> Btw, when C extensions are supported, simple apps will be able to use
>> my MusicPlayer lib at
>> http://github.com/jvoorhis/music_player/tree/master, which wraps much
>> of the MusicPlayer/MusicSequence api in AudioToolbox.framework. It's
>> short on documentation, but it's easy to get up and running on MRI
>> 1.8.x or 1.9.1.
>>
>> Best,
>>
>> Jeremy
>>
>> On Wed, May 27, 2009 at 11:25 PM, Mike Laurence 
>> wrote:
>> > Hmmm... I'm doing several things different, perhaps one or more of
>> > them are impossible :-)
>> >
>> > Basically, I'm trying to get MIDI support into Ruby via the PYMIDI
>> > obj-c library, which is really just a wrapper around CoreMIDI. One way
>> > I had thought of: create an additional obj-c class (MidiReceiver)
>> > which processes incoming packets for a given MIDI source and then call
>> > methods such as "note", "controlChange", "clockTick", etc. This
>> > MidiReceiver class can then be overridden by a custom ruby class that
>> > contains those same methods.
>> >
>> > Here is a quick version of the MidiReceiver class (with only the
>> > clockTick method for simplicity):
>> >
>> > - MidiReceiver --
>> >
>> > #import 
>> > #include 
>> >
>> > @interface MidiReceiver : NSObject
>> >
>> > - (void) processMIDIPacket: (MIDIPacket*) packet;
>> > - (void) clockTick;
>> >
>> > @end
>> >
>> > @implementation MidiReceiver
>> >
>> > - (void) processMIDIPacket: (MIDIPacket*) packet {
>> >    if (packet->length > 0) {
>> >
>> >        int statusByte = packet->data[0];
>> >        int status = statusByte >= 0xf0 ? statusByte : statusByte >> 4 <<
>> > 4;
>> >
>> >        switch (status) {
>> >        case 0x90: // Note on, etc...
>> >        case 0xf8: // Clock tick
>> >            [self performRubySelector:@selector(clockTick)];
>> >            break;
>> >        }
>> >    }
>> > }
>> >
>> > - (void) clockTick {
>> > }
>> >
>> > @end
>> >
>> > 
>> >
>> > Then, I have a ruby subclass of MidiReceiver that overrides clockTick,
>> > etc.:
>> >
>> > class LiveMidiReceiver < MidiReceiver
>> >  def clockTick
>> >    puts "tick!"
>> >  end
>> > end
>> >
>> > And then, in my Ruby ApplicationController, I'm finding the MIDI
>> > source and adding an instance of LiveMidiReceiver as a MIDI receiver:
>> >
>> > @src = PYMIDIManager.sharedInstance.realSources.find{ |s|
>> > s.displayName == 'KONTROL49 PORT A' }
>> > receiver = LiveMidiReceiver.new
>> > @src.addReceiver(receiver)
>> >
>> > The LiveMidiReceiver instance, upon receiving a midi packet, is called
>> > properly up to the point of the performRubySelector, but thereafter it
>> > launches into the debugger with EXC_BAD_ACCESS messages or other
>> > unsightly stack dumps.
>> >
>> > ---
>> >
>> > An even *better* interface would be to have the "clockTick" and other
>> > calls be performable on an arbitrary ruby object without having to
>> > subclass MidiReceiver (e.g., have MidiReceiver send "clockTick", etc.
>> > to a delegate object which has been created solely in Ruby). I tried
>> > that and it gave me similar results, although strangely it only
>> > crashed the first time on a clean build - thereafter I saw no crashes,
>> > but still no confirmation of ruby

Re: [MacRuby-devel] Using performRubySelector

[Mike Laurence]

I'll try and post what I was working on to Github, but it's fairly
incomplete, as I didn't want to get too far and then find out I
couldn't send messages to ruby the way I thought :-)

This little MIDI project of mine was just to get my formerly-RubyCocoa
(and thus formerly Midiator / DL / rbcoremidi compatible) app working
in MacRuby, but the more I think about it, the more it feels like we
should do something about this fragmented ruby MIDI situation. Since
that's really a topic for the Ruby-MIDI forum, I posted my thoughts
over there:
http://groups.google.com/group/ruby-midi/browse_thread/thread/2cacf04770abf242

Let the firestorm begin! Or, maybe just a happy storm. That would be better.

Mike

On Thu, May 28, 2009 at 1:02 PM, Jeremy Voorhis  wrote:
> I'd love to do it in FFI, but getting this far in C was a lot of work!
>
> ... so here's another crackpot idea of mine. Another project I have
> been following is the Pure Language
> . It aims to be a simple,
> interpreted functional language based on term-rewriting, and also has
> an LLVM JIT compiler. Using LLVM, they support a literal syntax for
> declaring foreign functions.
>
> To assist in creating wrappers for libraries, they created a tool
> called pure-gen that parses C header files and dumps out a .pure file
> containing FFI declarations. The tool is written in Haskell using a
> module called Language.C, but I wonder if we could bootstrap something
> similar by wrapping up Clang's libparse. They've managed to create
> wrappers for gsl, gtk+ and some other libraries by starting with the
> generated FFI decls, and adding some syntactic sugar and abstraction
> within Pure as appropriate.
>
> Implementing such a tool is probably going to take a lot of effort,
> but the benefits are pretty clear – especially since generated
> wrappers might be usable in JRuby and MRI. I also don't know how much
> this overlaps with BridgeSupport, but I just wanted to put the idea
> out there.
>
> Best,
>
> Jeremy
>
> On Thu, May 28, 2009 at 10:38 AM, Matt Aimonetti
>  wrote:
>> I second what Jeremy said. A nice Midi wrapper would be great.
>> Jeremy, regarding your MusicPlayer lib, the other option is to port it to
>> FFI and therefore making it JRuby and MacRuby compatible.
>>
>> - Matt
>>
>> On Thu, May 28, 2009 at 10:32 AM, Jeremy Voorhis  wrote:
>>>
>>> Mike,
>>>
>>> Is your code available anywhere, e.g. on github? I haven't looked at
>>> the PyObjC code myself, but I'd be interested in having really decent
>>> CoreMIDI support available in MacRuby.
>>>
>>> Btw, when C extensions are supported, simple apps will be able to use
>>> my MusicPlayer lib at
>>> http://github.com/jvoorhis/music_player/tree/master, which wraps much
>>> of the MusicPlayer/MusicSequence api in AudioToolbox.framework. It's
>>> short on documentation, but it's easy to get up and running on MRI
>>> 1.8.x or 1.9.1.
>>>
>>> Best,
>>>
>>> Jeremy
>>>
>>> On Wed, May 27, 2009 at 11:25 PM, Mike Laurence 
>>> wrote:
>>> > Hmmm... I'm doing several things different, perhaps one or more of
>>> > them are impossible :-)
>>> >
>>> > Basically, I'm trying to get MIDI support into Ruby via the PYMIDI
>>> > obj-c library, which is really just a wrapper around CoreMIDI. One way
>>> > I had thought of: create an additional obj-c class (MidiReceiver)
>>> > which processes incoming packets for a given MIDI source and then call
>>> > methods such as "note", "controlChange", "clockTick", etc. This
>>> > MidiReceiver class can then be overridden by a custom ruby class that
>>> > contains those same methods.
>>> >
>>> > Here is a quick version of the MidiReceiver class (with only the
>>> > clockTick method for simplicity):
>>> >
>>> > - MidiReceiver --
>>> >
>>> > #import 
>>> > #include 
>>> >
>>> > @interface MidiReceiver : NSObject
>>> >
>>> > - (void) processMIDIPacket: (MIDIPacket*) packet;
>>> > - (void) clockTick;
>>> >
>>> > @end
>>> >
>>> > @implementation MidiReceiver
>>> >
>>> > - (void) processMIDIPacket: (MIDIPacket*) packet {
>>> >    if (packet->length > 0) {
>>> >
>>> >        int statusByte = packet->data[0];
>>> >        int status = statusByte >= 0xf0 ? statusByte : statusByte >> 4 <<
>>> > 4;
>>> >
>>> >        switch (status) {
>>> >        case 0x90: // Note on, etc...
>>> >        case 0xf8: // Clock tick
>>> >            [self performRubySelector:@selector(clockTick)];
>>> >            break;
>>> >        }
>>> >    }
>>> > }
>>> >
>>> > - (void) clockTick {
>>> > }
>>> >
>>> > @end
>>> >
>>> > 
>>> >
>>> > Then, I have a ruby subclass of MidiReceiver that overrides clockTick,
>>> > etc.:
>>> >
>>> > class LiveMidiReceiver < MidiReceiver
>>> >  def clockTick
>>> >    puts "tick!"
>>> >  end
>>> > end
>>> >
>>> > And then, in my Ruby ApplicationController, I'm finding the MIDI
>>> > source and adding an instance of LiveMidiReceiver as a MIDI receiver:
>>> >
>>> > @src = PYMIDIM

[MacRuby-devel] Experimental branch status

[Giampiero De Ciantis]

Laurent,

Looking at the check in notices it seems like you have made a lot of  
progress in the recent weeks. Anything worth noting or sharing? Any  
updates on the ship date of 0.5?


Btw, if you were to pick one thing that you would say "I wish someone  
in the community would do " what would that item be?  
I have been trying to see where I can contribute, but I haven't  
participated in an open source project before and I don't want to  
waste other people's and my own time doing something of low value.


Cheers,

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

Re: [MacRuby-devel] Experimental branch status

[Laurent Sansonetti]

Hi Giampiero,

Sorry for the lack of status... and thanks for the reminder. I will  
write one tomorrow. I will also try to include things that still need  
to be done.


As for the ship date, we are still far to be ready, so I don't want to  
give any promise, since history shows that ship dates of previous  
releases have never been honored :-)


Laurent

On May 28, 2009, at 8:15 PM, Giampiero De Ciantis wrote:


Laurent,

Looking at the check in notices it seems like you have made a lot of  
progress in the recent weeks. Anything worth noting or sharing? Any  
updates on the ship date of 0.5?


Btw, if you were to pick one thing that you would say "I wish  
someone in the community would do " what would  
that item be? I have been trying to see where I can contribute, but  
I haven't participated in an open source project before and I don't  
want to waste other people's and my own time doing something of low  
value.


Cheers,

-Gp
___
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] Experimental branch status

[Jordan K. Hubbard]

On May 28, 2009, at 8:15 PM, Giampiero De Ciantis wrote:

Btw, if you were to pick one thing that you would say "I wish  
someone in the community would do " what would  
that item be? I have been trying to see where I can contribute, but  
I haven't participated in an open source project before and I don't  
want to waste other people's and my own time doing something of low  
value.



I'm not Laurent, but I do have a list of such things:

1. Volunteers to help maintain the web site and handle "PR" when the  
project's primary developers are busy doing other things (like hacking  
on code).  Sometimes that might involve collating/reporting on MacRuby- 
related developments in the MacRuby blog, since what's a blog without  
regular entries, and other times that might involving sending folks  
like Laurent and/or Rich messages on a semi-regular basis, encouraging  
them to provide a quick list of status bullets which the volunteers  
can then format and edit appropriately for the web site, again sparing  
the primary developers some of the admin work (and serving as their  
alarm clock to provide information to the masses :).


2. Writing tutorials / sample code for MacRuby, since anyone who's new  
to the project needs a place to start.


3. Writing RSpecs for MacRuby.

4. Reporting bugs, writing docs, providing words of encouragement,  
etc. :)


- Jordan

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

Re: [MacRuby-devel] Experimental branch status

[Matt Aimonetti]

The other thing that needs to be done is to port/fix the popular Ruby gems
which don't work on MacRuby yet. Also, writing wrappers for common obj-c
libraries/frameworks would be very useful.

If you are interested in writing tutorials/articles, feel free to contact me
offline so I can show you how to use our blog engine tool. (I think Rich is
planning on releasing a tutorial on how to do that, but that might not
happen right away)

- Matt



On Thu, May 28, 2009 at 9:35 PM, Jordan K. Hubbard  wrote:

>
> On May 28, 2009, at 8:15 PM, Giampiero De Ciantis wrote:
>
>  Btw, if you were to pick one thing that you would say "I wish someone in
>> the community would do " what would that item be? I have
>> been trying to see where I can contribute, but I haven't participated in an
>> open source project before and I don't want to waste other people's and my
>> own time doing something of low value.
>>
>
>
> I'm not Laurent, but I do have a list of such things:
>
> 1. Volunteers to help maintain the web site and handle "PR" when the
> project's primary developers are busy doing other things (like hacking on
> code).  Sometimes that might involve collating/reporting on MacRuby-related
> developments in the MacRuby blog, since what's a blog without regular
> entries, and other times that might involving sending folks like Laurent
> and/or Rich messages on a semi-regular basis, encouraging them to provide a
> quick list of status bullets which the volunteers can then format and edit
> appropriately for the web site, again sparing the primary developers some of
> the admin work (and serving as their alarm clock to provide information to
> the masses :).
>
> 2. Writing tutorials / sample code for MacRuby, since anyone who's new to
> the project needs a place to start.
>
> 3. Writing RSpecs for MacRuby.
>
> 4. Reporting bugs, writing docs, providing words of encouragement, etc. :)
>
> - Jordan
>
>
> ___
> 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] Experimental branch status

[dan sinclair]

2. Writing tutorials / sample code for MacRuby, since anyone who's  
new to the project needs a place to start.




Speaking of tutorials, I created a couple tutorials on getting started  
with HotCocoa. They're available at:


  http://everburning.com/news/heating-up-with-hotcocoa-part-i/
  http://everburning.com/news/heating-up-with-hotcocoa-part-iI/
  http://everburning.com/news/heating-up-with-hotcocoa-part-iII/
  http://everburning.com/news/heating-up-with-hotcocoa-on-github/


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

Re: [MacRuby-devel] Experimental branch status

[Dave Chilson]

Funny you should ask because I was just searching around for the same  
thing. I'm not Laurent, nor Rich either, but it looks like HotCocoa  
mappings could use quite a bit of love.


http://www.macruby.org/trac/wiki/HotCocoaMappings

http://www.macruby.org/trac/wiki/HotCocoaStatus

-Dave

On May 28, 2009, at 9:35 PM, Jordan K. Hubbard wrote:



On May 28, 2009, at 8:15 PM, Giampiero De Ciantis wrote:

Btw, if you were to pick one thing that you would say "I wish  
someone in the community would do " what would  
that item be? I have been trying to see where I can contribute, but  
I haven't participated in an open source project before and I don't  
want to waste other people's and my own time doing something of low  
value.



I'm not Laurent, but I do have a list of such things:

1. Volunteers to help maintain the web site and handle "PR" when the  
project's primary developers are busy doing other things (like  
hacking on code).  Sometimes that might involve collating/reporting  
on MacRuby-related developments in the MacRuby blog, since what's a  
blog without regular entries, and other times that might involving  
sending folks like Laurent and/or Rich messages on a semi-regular  
basis, encouraging them to provide a quick list of status bullets  
which the volunteers can then format and edit appropriately for the  
web site, again sparing the primary developers some of the admin  
work (and serving as their alarm clock to provide information to the  
masses :).


2. Writing tutorials / sample code for MacRuby, since anyone who's  
new to the project needs a place to start.


3. Writing RSpecs for MacRuby.

4. Reporting bugs, writing docs, providing words of encouragement,  
etc. :)


- Jordan

___
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] #268: [HotCocoa] Add delegates to table_view

[MacRuby]

#268: [HotCocoa] Add delegates to table_view
-+--
 Reporter:  d...@…|   Owner:  lsansone...@…
 Type:  enhancement  |  Status:  new  
 Priority:  major|   Milestone:   
Component:  MacRuby  |Keywords:   
-+--
 Attached patch contains a first attempt at adding delegates to the
 table_view class.

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] HotCocoa status update

[Matt Aimonetti]

Here is a quick update to let you know the progress made on HotCocoa in
trunk.

* new MVC template. The template in HotCocoa 0.4 is great but as soon as you
try to build a rich/complicated GUI, you start having to build your own
"view" system. We spent some time designing a new templating solution for
HotCocoa. You will still be able to use the one file type approach provided
by 0.4, but we are trying to set some conventions for people in need of a
MVC approach.
Having well defined conventions makes delegation and code organization
easier.

* Documentation app. We started working on a documentation app to provide
Cocoa and HotCocoa documentation. The source code is available at
http://github.com/mattetti/macruby-doc-app/ but will soon be moved to trunk.
To play with the app, you need to have the latest version of trunk built on
your machine. The application uses the Cocoa docsets and parses the HotCocoa
mappings to show available methods, delegations and cocoa doc.
Most of the basic functionalities are available, we are now going to spend
some time making the app look good and intuitive.

* HotCocoa mappings. With more and more people using HotCocoa, mappings are
being improved and extended.

*Todos:*

* Better integration between Interface Builder and HotCocoa. Imagine
defining a startup view using Interface Builder and then manage everything
else using HotCocoa using the newly designed HotCocoa MVC conventions. We
have some ideas on how to do that in a transparent way but more experiments
are required.

* Tests. We would like to see HotCocoa being better tested and also provide
a decent testing solution for developers.

* Rucola integration. Rucola is a very interesting and inspiring RubyCocoa
project. We are looking forward to work closely with the Eloy Duran to offer
the same type of experience for MacRuby/HotCocoa.

* Wrap commonly used obj-c libraries and document the process.


As usual, your help would be appreciated.

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

Re: [MacRuby-devel] HotCocoa status update

[dan sinclair]

I've been shooting around in the dark with HotCocoa for a few days.  
Adding things here and there. Is there a priority list of things to  
do, or everything is equally good?


Is most HotCocoa discussion done on this list and in IRC?

Thanks,
dan



On May 29, 2009, at 1:55 AM, Matt Aimonetti wrote:

Here is a quick update to let you know the progress made on HotCocoa  
in trunk.


* new MVC template. The template in HotCocoa 0.4 is great but as  
soon as you try to build a rich/complicated GUI, you start having to  
build your own "view" system. We spent some time designing a new  
templating solution for HotCocoa. You will still be able to use the  
one file type approach provided by 0.4, but we are trying to set  
some conventions for people in need of a MVC approach.
Having well defined conventions makes delegation and code  
organization easier.


* Documentation app. We started working on a documentation app to  
provide Cocoa and HotCocoa documentation. The source code is  
available at  http://github.com/mattetti/macruby-doc-app/ but will  
soon be moved to trunk. To play with the app, you need to have the  
latest version of trunk built on your machine. The application uses  
the Cocoa docsets and parses the HotCocoa mappings to show available  
methods, delegations and cocoa doc.
Most of the basic functionalities are available, we are now going to  
spend some time making the app look good and intuitive.


* HotCocoa mappings. With more and more people using HotCocoa,  
mappings are being improved and extended.


Todos:

* Better integration between Interface Builder and HotCocoa. Imagine  
defining a startup view using Interface Builder and then manage  
everything else using HotCocoa using the newly designed HotCocoa MVC  
conventions. We have some ideas on how to do that in a transparent  
way but more experiments are required.


* Tests. We would like to see HotCocoa being better tested and also  
provide a decent testing solution for developers.


* Rucola integration. Rucola is a very interesting and inspiring  
RubyCocoa project. We are looking forward to work closely with the  
Eloy Duran to offer the same type of experience for MacRuby/HotCocoa.


* Wrap commonly used obj-c libraries and document the process.


As usual, your help would be appreciated.

- Matt
___
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 status update

[Matt Aimonetti]

Thanks Dan for all your great patches. Most of the discussion is done on
this list or on a one to one basis via IM (but we are trying to keep that to
a minimum tho).

- Matt

On Thu, May 28, 2009 at 11:09 PM, dan sinclair  wrote:

> I've been shooting around in the dark with HotCocoa for a few days. Adding
> things here and there. Is there a priority list of things to do, or
> everything is equally good?
>
> Is most HotCocoa discussion done on this list and in IRC?
>
> Thanks,
> dan
>
>
>
>
> On May 29, 2009, at 1:55 AM, Matt Aimonetti wrote:
>
>  Here is a quick update to let you know the progress made on HotCocoa in
>> trunk.
>>
>> * new MVC template. The template in HotCocoa 0.4 is great but as soon as
>> you try to build a rich/complicated GUI, you start having to build your own
>> "view" system. We spent some time designing a new templating solution for
>> HotCocoa. You will still be able to use the one file type approach provided
>> by 0.4, but we are trying to set some conventions for people in need of a
>> MVC approach.
>> Having well defined conventions makes delegation and code organization
>> easier.
>>
>> * Documentation app. We started working on a documentation app to provide
>> Cocoa and HotCocoa documentation. The source code is available at
>> http://github.com/mattetti/macruby-doc-app/ but will soon be moved to
>> trunk. To play with the app, you need to have the latest version of trunk
>> built on your machine. The application uses the Cocoa docsets and parses the
>> HotCocoa mappings to show available methods, delegations and cocoa doc.
>> Most of the basic functionalities are available, we are now going to spend
>> some time making the app look good and intuitive.
>>
>> * HotCocoa mappings. With more and more people using HotCocoa, mappings
>> are being improved and extended.
>>
>> Todos:
>>
>> * Better integration between Interface Builder and HotCocoa. Imagine
>> defining a startup view using Interface Builder and then manage everything
>> else using HotCocoa using the newly designed HotCocoa MVC conventions. We
>> have some ideas on how to do that in a transparent way but more experiments
>> are required.
>>
>> * Tests. We would like to see HotCocoa being better tested and also
>> provide a decent testing solution for developers.
>>
>> * Rucola integration. Rucola is a very interesting and inspiring RubyCocoa
>> project. We are looking forward to work closely with the Eloy Duran to offer
>> the same type of experience for MacRuby/HotCocoa.
>>
>> * Wrap commonly used obj-c libraries and document the process.
>>
>>
>> As usual, your help would be appreciated.
>>
>> - Matt
>> ___
>> 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 mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel