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@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
