[MacRuby-devel] The future of MacRuby

Francis Chong francis at ignition.hk
Sun Apr 8 18:26:46 PDT 2012


While i totally agree the points here, a more pressing need, IMHO, is fixing bugs and incompatibility of MacRuby such that what works on other implementation just works in MacRuby,

For instance, require_relative is not implemented which breaks a lot of 1.9 ruby code. (http://www.macruby.org/trac/ticket/1164 https://github.com/MacRuby/MacRuby/pull/56) 

Another example is this issue which break JSON gem and many others (http://www.macruby.org/trac/ticket/1326)  gems, you really can't do much if you don't even able to load json gem!

just my 2c.

Andy Park 於 2012年4月9日 上午7:26 寫道:

> 
> On 6 Apr 2012, at 00:06, Matt Aimonetti wrote:
> 
>> Many of you have been wondering what is going on with the MacRuby project given the lack of up-to-date releases and overall communication.
>> I feel we owe you some explanation.
>> 
> 
> Matt, as someone trying to ship a product based on MacRuby, I'd like to say thanks for giving us an overall update on the project. It's good to see that you and many others want to see the project carry on further.
> 
>> Here is how I see things and I would love to hear more about what you guys think.
>> MacRuby is a great project, but: 
>> the target audience & projects aren't clear
>> 
> There are probably many target audiences and IMO I didn't get the impression that the project suffered from not knowing who to serve. 
> 
> I know I'm in the target audience, because I target OS X, and would like to leverage Ruby to maximise productivity. There's probably another (technically, potential) audience who would be interested in targeting iOS with MacRuby - I'm also one of them with a different hat.
> 
> Other types of audiences might also exist, but at least there are these 2 audience profiles, one of which is currently not being served, but as you mention below, if you think if we can identify them more clearly, it would help, it sounds good to me.
> 
> On the second point, if you mean that MacRuby would benefit from having more defined sub-projects under the MacRuby umbrella, I absolutely agree. Dealing with libauto deprecation is most likely one of these things with a lot of demand and is a chunky enough endeavour that it could go through debate, consensus finding, design and implementation stages as its own (sub-)project in its own right. (I know that could sound very irrelevant to OSS, and I admit, I have no idea actually - this is the first time I'm participating in a community project this size.)  Perhaps there are other such topics that people could nominate as worthy sub-projects for all to consider focusing on.
>> the target platform (OS X) isn't the one we all really want to target (iOS)
>> 
> You have my vote on this one.
>> Cocoa's API is awesome but not user friendly/easy to grasp
>> 
> You have my vote on this one too.
>> 
>> What I'd like to suggest is the following:
>> 
>> 1. Define clear goals for MacRuby that we can easily evaluate:
>> Focus primarily on making MacRuby the tool to use for quickly prototyping OS X and iOS applications.
>> Remove dependency on libauto so MacRuby can run post Mountain Lion and on iOS.
>> 2. Increase the number of contributors:
>> Define areas of contribution:
>> implementation itself (mainly requires C, C++ knowledge)
>> prototyping focus (templates, wrapper APIs, modules, tools: a full ecosystem aimed at being more productive)
>> documentation (getting started, guides, FAQs, wiki, demos, hacker guides)
>> support
>> empower contributors:
>> move the website to github for easier contribution
>> better release process and roadmap
>> better process to review pull requests & give commit rights
>> 3. Improve communication:
>> start an active and official chat room (IRC, campfire like or something else)
>> open discussions about plans for the project and progress made
>> better collaboration with other Ruby implementation teams (Rubinius, JRuby, MagLev and of course Matz/C Ruby)
>> 
> I think this is an excellent set of goals to shoot for.
> 
> My additional my 2p:
> 
> * Documentation: As a project using MacRuby grew to non-trivial size, I found there were many challenges I hadn't foreseen when I made the decision to base it on MacRuby, such as:
> 
> -- Profiling, e.g. that Instruments doesn't show MacRuby code all that well, so another layer of uncertainty is introduced in performance tuning tasks
> -- libauto jiving very badly with things like a filterable NSCollectionView set up with bindings and a few hundred items
> -- Subtler areas of ruby-objc bridging, such as using procs in place of obj-c blocks, dealing with situations that need a Pointer object etc.
> 
> While there were sometimes bits and pieces of information scattered on the mailing list, the trac wiki and the blog posts of the generous from the community, the overall impression I got was that the non-trivial knowhow wasn't effectively shared and evolved. I checked just now and saw traces of Laurent having put more stuff in https://github.com/macruby/macruby/wiki , and I think it would be excellent for those deep into MacRuby to lead by example by more actively sharing their expertise in the wiki as well as on the mailing list. Once you get your busy stuff sorted, or whatever.
> 
> To really 'throw the gauntlet', I'll pick my arse up and donate some time, albeit not a whole lot, to contribute to at least the sketches of the high-level topics is needed, namely to start putting some stuff on the mailing list that was 'juicy' for me personally, onto the wiki and see if this will assist the build-up.
> 
> 
> * iOS support: Alongside a more elaborate discussion of retiring libauto, I would love to see a more active discussion on an explicit target of bringing MacRuby on iOS.
> 
> I had tried to find information for this topics a few times, and actually saw very interesting stuff like this:
> https://github.com/takuma104/iphone-macruby
> 
> How about we start talking more concretely on what things must happen in order for getting MacRuby to target IOS? And how about we start this one without too much distraction on why we should do that, whether we should expend our breath on it over higher priorities etc, and just chip in their technical thoughts on it for a bit?
> 
> 
> -Andy
> _______________________________________________
> 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/20120409/d07095be/attachment.html>


More information about the MacRuby-devel mailing list