On Thursday, December 22, 2011 at 11:15 PM, Jeff Hemmelgarn wrote:
> 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!
There are already shipping, money-making MacRuby apps in the App Store. I think
that pretty much refutes your "shelf-ware" concerns.
> 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.
>
>
>
MacRuby is an Open Source project with a permissive license. Regardless of what
direction Apple chooses to take the project in, I can personally assure you
that any effort you put into the project will not be nullified. It is important
to note that, despite it's name, MacRuby is an implementation of Ruby on the
Objective-C runtime and Apple's Objective-C runtime is not the only game in
town. While there has not been any effort to build and run MacRuby on GNUStep,
there is no reason to think that it could not be done with some effort.
Moreover, MacRuby's dependence on Objective-C is very, very low-level. For
Apple to make a move that would disable MacRuby, they would effectively have to
rewrite the entire Objective-C runtime (which has been under continuous
development longer than either the JVM or the CLR).
> 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.
>
>
>
Instead of worrying about whether or not Apple will decide to call MacRuby
"first-class", how about we discuss what "first-class" would mean. Does it mean
the ability to run compiled code without any runtime bridging costs? MacRuby
already has that. Does it mean a debugger? Ok, what sort of debugger? Is a
command-line interface ok, or would we want something more visual? If it means
full integration with Xcode on par with Objective-C, then I'm afraid we are out
of luck. However, there is no reason that we can't use MacRuby to develop our
own tools. Such tools would have the added benefit of being open and relatively
easy to hack on for fellow MacRuby developers.
MacRuby itself is technology-wise not all that different from many other
implementations of Ruby or other languages. I suspect that there are a great
many number of developers with the skill set to hack on MacRuby, and so long as
you understand some basics of C++, it wouldn't be too hard to get up to speed
on the project. Regarding transparency, every commit to the MacRuby project is
available for public inspection on Github. As for support, obviously we will
take all that we can get, but the core team works on MacRuby because it is
something that we like to do. We'll continue doing that so long as we can. Yes,
that will mean that the project has high and low points, but that is true for
almost every Open Source project (for example, Rubinius went from 2 developers
to something like 8 developers down to 1 developer in the course of a year…and
now look where they are).
> 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.
Lua depends on garbage collection and runs on iOS. C# depends on garbage
collection and runs on iOS. Scheme, JavaScript, and at least a handful of other
languages all depend on garbage collection and run on iOS.
Let me try to clarify the GC/iOS situation with MacRuby… Ruby is a garbage
collected language. The C implementation of Ruby uses a fairly straight-forward
mark-and-sweep collector. At the time the MacRuby project was getting started,
garbage collection had recently been added to Objective-C, so the decision was
made to go with libauto (Objective-C's GC) for MacRuby. Honestly, any collector
could work. It would not be impossible to hook up an off the shelf Boehm
collector to MacRuby. Heck, the GC functions are even fairly well factored into
a couple pre-processor macros and an abstracted allocation call. It wouldn't
necessarily be easy, but I don't think it would be anything quite like a
man-year to accomplish. To assert that the only way for MacRuby to ever run on
iOS is for Apple to add GC to iOS is just wrong.
> 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!
Good! Now we're talking. So, for the Net::SSH bug, if there is just an encoding
issue standing in the way of getting things to run, then let's smash that bug!
The last comment I see is from 10 months ago and indicates v0.8. Have you tried
running it recently? We made a decent dent in the C APIs for encodings right
around that time. I wouldn't be surprised if this was already fixed, but if
not, let's build a trivial test case and hammer away at it.
As for Fibers…hmm…I don't think we've ever given much serious consideration to
Fibers since they don't seem to be a horribly popular feature of Ruby proper,
and because implementation could be problematic. That said, I wonder how much
of the specs we could get to passing with a GCD-based pure-ruby implementation
of Fibers. Anyone up for the challenge?
> 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.
Again, why are you asking for Apple's support? Send a pull request and see if
it gets accepted. Until then, idle speculation on what Apple is or is not being
supportive of seems a bit premature. That said, since the primary use case for
MacRuby (at present) is for implementing performant, Cocoa-based apps, I don't
think it is unreasonable to be wary of a change that adds to Ruby support at
the expense of speed or integration. If you disagree, let's argue on specific
points instead of abstract generalities.
> 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.
…and the experience! :-)
- Josh
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
