Re: [MacRuby-devel] The future of MacRuby
y development discussions." > (mailto:[email protected])> > Subject: Re: [MacRuby-devel] The future of MacRuby > Message-ID: (mailto:[email protected])> > Content-Type: text/plain; charset="windows-1252" > > > Can you import before it's open? I just assumed it wasn't accessible at all > > until enable? It looks like forgeplucker > > (http://home.gna.org/forgeplucker/) has support to pull tickets out of trac > > and dump to JSON. Should be pretty easy to go from JSON to GitHub API I'd > > expect. > > Well, we?d open it once the import is ready to be performed. Until then it > can be tested out with a dummy repo :) > > > I can take a look and see what's involved. > > Awesome! Thanks. > -- next part -- > An HTML attachment was scrubbed... > URL: > <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20120408/dc0f1ed3/attachment-0001.html> > > -- > > ___ > MacRuby-devel mailing list > [email protected] (mailto:[email protected]) > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > > End of MacRuby-devel Digest, Vol 50, Issue 19 > * > > ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] The future of MacRuby
; -- >> >> Message: 3 >> Date: Sun, 8 Apr 2012 00:01:36 +0200 >> From: Eloy Duran >> To: "MacRuby development discussions." >> >> Subject: Re: [MacRuby-devel] The future of MacRuby >> Message-ID: >> Content-Type: text/plain; charset="windows-1252" >> >>> Can you import before it's open? I just assumed it wasn't accessible at all >>> until enable? It looks like forgeplucker >>> (http://home.gna.org/forgeplucker/) has support to pull tickets out of trac >>> and dump to JSON. Should be pretty easy to go from JSON to GitHub API I'd >>> expect. >> >> Well, we?d open it once the import is ready to be performed. Until then it >> can be tested out with a dummy repo :) >> >>> I can take a look and see what's involved. >> >> Awesome! Thanks. >> -- next part -- >> An HTML attachment was scrubbed... >> URL: >> <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20120408/dc0f1ed3/attachment-0001.html> >> >> -- >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >> >> End of MacRuby-devel Digest, Vol 50, Issue 19 >> * > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] The Future of MacRuby
On 7/04/2012, at 11:24 PM, Francis Chong wrote: > Automatic Reference Counting implements automatic memory management for > Objective-C objects and blocks. If you read MacRuby source code, you will > found that the VM is not even written in Objective-C! This is why a one page description of how MacRuby works would be useful. Henry ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] The future of MacRuby
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
Re: [MacRuby-devel] The future of MacRuby
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
Re: [MacRuby-devel] The Future of MacRuby
tl;dr: I propose getting tutorials and code under one structured collection, and to create classes that wrap Core Data in the same way HotCocoa wraps NSViews. I agree with the sentiments about "setting ourselves apart". How do we do that? Please allow me to pontificate. I apologize for the length. I think we have already answered this question: Cocoa is huge and hard to learn when you are getting started. Let's fix that! Let's make it easy - NAY - FUN to get started. That's what made Rails so darn popular, right? It's not because it was the fastest, or had a long history of support, or zero bugs, or stability. It was FUN. And that's what *Ruby* is about, too! I think we should also show off how "grown up" MacRuby already is. When I saw that there was already a Core Data project template, I was sold. If that *hadn't* been there, I would have balked, for sure, and maybe even walked away. Also, Matt Aimoetti's MacRuby book, and the upcoming book, MacRuby in Action, indicate that the support is out there. I think that HotCocoa is a great example of "fun" and "distinctive development cycle". It aims to be a replacement for Interface Builder. I don't think we need to stop there. We can replace *Xcode*. Hotcocoa already handles compilation, using macrake to run or deploy or embed a project. If we could go so far as to wrap up Core Data into ruby classes, hoohoo boy would we be having fun then! "HotCocoaData" anyone? For my part, I'd like to reach out to those of you that have collections of recipes and tutorials, and start creating a structured repository of these resources (jballanc/Josh recommended using the github wiki as this tutorial repository). I would *really* like it if our tutorials did the same things most do (pushing a button => prints "hello" - WOW!), but then always take that a few steps further. If it is easy to print "hello", why would you stop there? Do something useful, or at least something complicated, that provides food for thought. With help, I think we could create a project that allows us to create Core Data models using ruby code. At that point, *everything* could be done in ruby, but with full access to Cocoa, and then we'd be doing something really exciting. Not that MacRuby isn't already exciting - if it wasn't, we wouldn't be talking about this stuff! #colinta ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] The Future of MacRuby
Compare with ActiveRecord/DataMapper, i really have no love on Core Data. If MacRuby could run all those ActiveRecord/DataMapper adapters, there are few reason to use a Core Data wrapper (much like ruby dev will not ever normally use mysql/postgres gem directly). Certainly if such wrapper follow ActiveModel it would be very useful, but if we can already use AR to use sqlite db, why bother another layer of wrapper? Colin Thomas-Arnold 於 2012年4月9日 上午11:50 寫道： > tl;dr: I propose getting tutorials and code under one structured collection, > and > to create classes that wrap Core Data in the same way HotCocoa wraps NSViews. > > I agree with the sentiments about "setting ourselves apart". How do we do > that? > Please allow me to pontificate. I apologize for the length. > > I think we have already answered this question: Cocoa is huge and hard to > learn > when you are getting started. Let's fix that! > > Let's make it easy - NAY - FUN to get started. That's what made Rails so darn > popular, right? It's not because it was the fastest, or had a long history of > support, or zero bugs, or stability. It was FUN. And that's what *Ruby* is > about, too! > > I think we should also show off how "grown up" MacRuby already is. When I saw > that there was already a Core Data project template, I was sold. If that > *hadn't* been there, I would have balked, for sure, and maybe even walked > away. > Also, Matt Aimoetti's MacRuby book, and the upcoming book, MacRuby in Action, > indicate that the support is out there. > > I think that HotCocoa is a great example of "fun" and "distinctive development > cycle". It aims to be a replacement for Interface Builder. I don't think we > need to stop there. We can replace *Xcode*. Hotcocoa already handles > compilation, using macrake to run or deploy or embed a project. If we could go > so far as to wrap up Core Data into ruby classes, hoohoo boy would we be > having > fun then! "HotCocoaData" anyone? > > For my part, I'd like to reach out to those of you that have collections of > recipes and tutorials, and start creating a structured repository of these > resources (jballanc/Josh recommended using the github wiki as this tutorial > repository). > > I would *really* like it if our tutorials did the same things most > do (pushing a button => prints "hello" - WOW!), but then always take that a > few > steps further. If it is easy to print "hello", why would you stop there? Do > something useful, or at least something complicated, that provides food for > thought. > > With help, I think we could create a project that allows us to create Core > Data models using ruby code. At that point, *everything* could be done in > ruby, > but with full access to Cocoa, and then we'd be doing something really > exciting. > Not that MacRuby isn't already exciting - if it wasn't, we wouldn't be talking > about this stuff! > > #colinta > > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
