All, I cannot separate the stakeholders (and their issues) from the roadmap. MacRuby will go where people who care to push want it to go. Barring getting a job where I am paid to push MacRuby in a certain direction, I will be at best a small addition to the overall effort. Given that, I would like to feel that 1) I am not pushing in a direction that will be nullified by more powerful stakeholders or 2) an indifferent universe will not cause any effort I put forth for MacRuby to be spilled out upon the sands. Apple is the 800-pound gorilla in the room and can certainly cause either outcome to happen, whether by malice or indifference. I don't need a blessing but a gesture would help a lot. It is one thing to get paid to write shelf-ware, and another to spend your spare time doing it!
So, to avoid the first problem I would like Apple to give some guidance to the community as to what it sees it's interest is in MacRuby. I know I am dreaming and this is totally against the Apple way. To avoid the second problem I would like to see some indication that Apple plans to move forward on including MacRuby in it's offerings as a first-class citizen on all platforms. Again, I am dreaming to think that could happen. This is all in response to the call for participation in the project. There aren't many people who have the skill set to work on MacRuby and the willingness to work on a project with such little transparency from the main stakeholder. So please don't be unrealistic about what support MacRuby is likely to garner. My point about iOS was that MacRuby depends on garbage collection which is not currently included in iOS, and it would take a big engineering effort to get a version of MacRuby that doesn't require garbage collection. If you have a spare man-year to dedicate to making a version of MacRuby that works without garbage collection, more power to you! But are you going to do that with the chance that Apple will add garbage collection support to iOS at any point? I won't. I don't have a spare man-year and if I did I would spend it on a less risky venture. I was talking about established bugs in the Trac database when I mentioned Fibers(https://www.macruby.org/trac/ticket/253) and encodings(Net:SSH:https://www.macruby.org/trac/ticket/530). There are gems that cannot run under MacRuby because these features are not supported. The code is already written, make it run! I have been looking into some of the more esoteric problems with the current implementation of MacRuby and am hesitant to put too much effort into it because of the "integrate into Objective-C" focus of the project. The changes to get some of the problems fixed with the problematic gems may or may not cause serious performance problems for all of MacRuby, or integration problems with Objective-C frameworks like cocoa. I don't see Apple being supportive of these kinds of changes. Again, this is where the stakeholders and the direction are inextricably entwined. I wouldn't be writing all of this if I didn't see a lot of potential for MacRuby. I want to see it succeed and be a blazingly fast ruby implementation. The better it supports all of the gems, the better it will support any arbitrary ruby code I write. I want MacRuby to succeed and be available. But, I accept that the only thing I may get out of working on MacRuby is the work. Jeff Hemmelgarn p.s. I think MacRuby should be the slam-dunk ruby for Apple devices. That requires being the best ruby on the Mac and iOS devices. cocoa integration goes a log way to that end, but compatibility, speed and usability are also important.
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
