context_pmc3 branch and backward compatibility.

Patrick R. Michaud pmichaud at pobox.com
Tue Aug 25 00:18:45 UTC 2009


On Mon, Aug 24, 2009 at 02:51:25PM -0700, chromatic wrote:
> On Monday 24 August 2009 01:13:49 Allison Randal wrote:
> 
> > Purely internal changes are fine. It's when changes start touching on
> > users that they become deprecation candidates.
> 
> Sure, but users who poke into internal structures (which are not in the list 
> of deprecation candidates in the documented support policy) don't get as much 
> support and warning as do users who stick to documented APIs (listed in the 
> support policy).
> 
> I think it's only Lua, Partcl, Rakudo, and Kea-CL which may have a problem 
> here, and they hew closely enough to Parrot trunk that they should be able to 
> handle it.

Rakudo doesn't mind if internal Parrot structures change that 
Rakudo currently relies upon, but we'd like any conflicts
caused by such changes to be short-lived -- one or two days
at most.

We certainly would not want potential conflicts like this to occur 
around the time of a Parrot monthly release, because that may leave 
Rakudo with an unfortunate choice of (1) missing its own release 
date or (2) having to release a version of Rakudo tied to an unreleased 
version of Parrot.  (See postscript [1] below for recent examples
of this.)

Rakudo tries to avoid as much as possible any reliance on Parrot 
internals that aren't explicitly marked as part of the API.  In 
those few places that we do make use of Parrot internals or
otherwise stray beyond Parrot's documented interfaces or policies, 
we either (1) feel we currently have no choice or (2) don't 
explicitly recognize that we're doing so.

At this point in development, Rakudo has a much stronger need for
Parrot to evolve and improve than for Parrot to be providing any 
sort of API stability at the C level.  In particular, we 
*desperately need* the improvements to calling conventions and 
context handling that PDS 2008 targeted as being likely done by 1.0
but (as of today) have yet to land.  If it turns out that Rakudo will 
have to wait until February 2010 for these things to appear in a
Parrot release, that is a serious problem for us.

So I'm in favor of getting these changes into Parrot as quickly as
possible, even if it risks some API breakage.  Yes, I may grumble a 
bit when branch merges to trunk cause Rakudo to no longer build against
Parrot head (as recently occurred after the Parrot_sub refactor), but 
(1) I fully recognize that Rakudo is working more tightly with Parrot 
head than called for by Parrot's policies, and (2) as long as things 
can be quickly repaired (as also occurred with the Parrot_sub refactor) 
then I have no real qualms with the breakages.

However, if our overall progress is likely to be stymied for 
months because of Parrot's deprecation policy, I think we need to 
find some different policies or practices that avoid the imposition 
of such long delays in development.

Pm


[1] An example of a recent internals change that caused problems for 
    Rakudo was the changing of Hash PMC semantics less than a week 
    before the 1.4 release.  I completely grant that Rakudo should 
    not have been relying on Hash's "ordered" semantics, but the 
    truth is that none of us had any idea that Rakudo was relying on 
    those semantics.  We only found out about it after things broke.  
    And because of the timing of the change, I had less than 24 hours 
    available to me to troubleshoot and fix the problem in Rakudo 
    before the release (and this required postponing/rescheduling 
    my previous plans for that period).  Again, it's not the change
    itself that was troubling, it was that there was such little time
    available for us to analyze and react to the change before Parrot's
    subsequent release.  A similar story occurred with the recent
    removal of the Random PMC immediately prior to the 1.5 release.

[2] Many of the problems with Rakudo not building after a major branch
    merge can likely be avoided altogether if we simply run a Rakudo 
    spectest on a branch _prior_ to the branch being committed to trunk.
    AFAICT this isn't hard to do, and if it is currently hard to do, 
    then we should find ways to make it easier.



More information about the parrot-dev mailing list