On Wed, Dec 1, 2010 at 10:18 AM, Peter Lobsinger <[email protected]> wrote: > I get the sense there's an expectation that rakudo should always build > and run cleanly against parrot head. I don't recall this ever being > explicitly supported, and I think that it is not feasible in the > general case (I do agree that in this specific case it would have been > a possibility).
We certainly can't support that kind of expectation, but as Moritz points out this really isn't the purpose of the discussion. We all need to accept the fact that there are changes and breakages, and we need to find ways to minimize the disruption caused by them. The problem (at least as I think it would be from Rakudo's perspective) is that Parrot is a moving target. It's not because we're just fooling around and breaking things for the sake of breaking them, but we have a lot of really hard work to do to bring Parrot up to the level that our users want and deserve. What we really need to know are the exact parameters that Rakudo is willing to put up with during these kinds of disruptions, with the obvious tradeoff being that more tolerance towards disruptions brings more features and better performance, and brings all these things faster. It's a fine line that we have to walk, because if Parrot never improves it will become a clearly inferior and unusable platform in the face of other alternatives. If we improve too much and constantly break the interface, we will be left behind for something more stable. Parrot obviously does not want to lose Rakudo as a user, so we need to work closely together with them to find out what they need in this regard. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
