harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [classlib] Preprocessor - CHECKPOINT
Date Fri, 03 Nov 2006 03:54:43 GMT
So this has been a long and exciting thread, and it's still not clear 
that we understand each other.  There are at least two different models 

I'll go re-read and try and clarify the difference, and I suppose the 
next step for Etienne would be an example of how his approach works.  It 
will be fun to play with.


Geir Magnusson Jr. wrote:
> Tim Ellison wrote:
>> Geir Magnusson Jr. wrote:
>>> Etienne Gagnon wrote:
>>>> Geir Magnusson Jr. wrote:
>>>>>> The "communication" aspect of 2 can be quite helpful when doing
>>>>>> system-wide changes.  Just think about the effect of simply doing
>>>>>> system-wide reindentation of source code; this is a nightmare when
>>>>>> developing using branches, as diff/merge tools are line-based, not
>>>>>> syntax-based.  So, if your new indenter moves things across lines,
>>>>>> you're in hell.
>>>>> So here's where I'm starting to believe I'm missing something
>>>>> important :
>>>>> Can you give me an example of the "communication" that you imagine
>>>>> taking place here?  That's the part I'm just not grokking here.
>>>> How about: j2se5 developers, seeing that his planned modification to
>>>> some code will lead to utterly broken nearby j2se6 (commented) code
>>>> fragments, steps on this mailing list and asks j2se6 developers to help
>>>> him find the most harmless way to do the change (or, at least,warn them
>>>> about the problem)?
>>> Ok - we do that now.  I thought you were saying that your tool added
>>> somehow to communications.
>>>>>> I am not saying that using the tool should replace using branches
>>>>>> all situations, but there are situations where it would be more
>>>>>> effective not to use branches when the code is mostly identical.
>>>>> I want to avoid branches at all costs.
>>>> [somewhat off-topic]  I think that we should consider tools/approaches
>>>> on their merit.  Sometimes, branches are the right solution...  You
>>>> wouldn't want to use syntax-processing instead of branches for managing
>>>> sandboxes. ;-)
>>> I'm trying to figure out the merit here.
>> I believe that there will still be a role for branches, both for
>> sandboxes to experiment as Etienne said, and for the maintenance streams
>> of our releases.
> Of course we aren't going to ban branches.  The context is branching for 
> mainline code.  Lets stay focused...
>>>>> Clearly there's some confusion here.  My goal is to
>>>>> 1) Avoid branches at all costs so we can share as much code, and 
>>>>> get as
>>>>> much benefit for collaboration between different versions, and 
>>>>> different
>>>>> platforms, if that happens.
>>>> Agreed.
>>>>> 2) make it simple to work in either the 'master' code, or the 'target'
>>>>> code through tooling, including standard IDE activities like debugging
>>>> Agreed.
>>>>> 3) make it easy for users to report bugs based on 'target' code,
>>>>> including patches and line numbers
>>>> Ah!  That's something to add to my requirements.  Fine!  I hadn't
>>>> included the "patches" thing into account.  It doesn't break what I've
>>>> exposed so far; it simply adds to it.
>>> It has to be the case - we'll do snapshots and distributions of
>>> "src.jar" and when a developer goes into the debugger, they need to see
>>> normal Java SE 5 code.
>> Agreed -- our src.jar will be 'normal' Java code without multi-target
>> mark-ups.
>> <snip>
>>>> That's neat.  I like it.  Yet, we would encourage developers to work 
>>>> and
>>>> submit patches using devtarget code, instead of releasetarget code.
>>> I don't know this terminology.  I was using "master" being the code in
>>> SVN, and "target", being the code Y, so the map is :
>>>   master == devtarget
>>>   target == releasetarget
>>> right?  Ok.
>> There are multiple 'devtarget's -- each contains all the source code
>> marked-up for every target being developed, but each is distinct by
>> having different targets uncommented.  Since each devtarget contains the
>> entire source code it is possible to accurately transform from any one
>> devtarget to any other devtarget.  One of the devtargets is actually
>> stored in svn, and that is the canonical form of the devtarget code.
> So that's 'master'. and everythign else is a transformed master, right?
>>> I want to work in the master code w/ an IDE plugin that lets me think
>>> I'm in target (and lets me flip back to master).  No preprocessing of
>>> the tree is required to develop.
>>> However, end-users - people who take our JDK and work with it, will
>>> report bugs with stacktraces and line numbers that are from
>>> target/releasetarget code.
>> Screech -- the releasetarget, by definition, does not contain the source
>> for all possible targets so that it is consumable by end-users.
> That is correct.
> The only code that contains all code is master.
>>> So what to do with a patch?
>>> I can either
>>>   patch -p0 << reverse(patch.file)
>> I don't understand how you will ensure there is enough information in
>> patch.file to make the reverse() function exact?  I proposed that our
>> releasetarget code contains tie-points where it is out of sync with the
>> closest devtarget by some number of lines.
> I don't understand why you'd bother.  If you know that patch P creates 
> Y' from a given Y, and you can always create Y as you know everything to 
> do the xform from master source and the platform name, everything is known.
>>> on the main code or use patching facilities in an IDE to patch the
>>> transform view
>>> Man, this tooling is going to be fancy! :/
>>>> In other words, here's how I see the distribution(s):
>>>>  - Binary j2se5 Harmony release:  includes j2se5release src.jar for
>>>>    end-developers using debuggers to step through API code.
>>>>  - Source j2se5 Harmony release: API are in j2se5dev form.  The build
>>>>    process uses the processing tool to generate j2se5release src.jar.
>>>>  - Binary j2se6 Harmony release:  includes j2se6release src.jar for
>>>>    end-developers using debuggers to step through API code.
>>>>  - Source j2se5 Harmony release: API are in j2se6dev form.  The build
>>>>    process uses the processing tool to generate j2se6release src.jar.
>>> Yes.
>>>> Why?  Because reverse works much better with devtarget than
>>>> releasetarget code, and the communications benefit of devtarget that 
>>>> are
>>>> lost in releasetarget code (because of stream code erasure).  In
>>>> addition, using smart IDEs, there wouldn't be much difference for
>>>> developers between the "visible" formats of dev vs release code when
>>>> working on it.
>>> I don't think it matters, as I think that most people interested in
>>> working on the code will just check out of SVN.
>>>>> for X being a single class.  To produce a complete target source base,
>>>>> walk the single source tree as defined by a 'platform descriptor' :
>>>> I don't really understand the "platform descriptor" thing, yet I think
>>>> that it is, somehow, an orthogonal issue to the discussion above.
>>>> [Remember my long message describing 2 levels of processing:
>>>> file/directory-level and source-level.]  My first prototype tool would
>>>> attack source-level processing (discussed above), to validate the
>>>> approach.
>>> Right - the "platform descriptor" is the data that the
>>> file/directory-level thing uses.
>>>> Maybe you could try rephrasing your file/directory-level (right?)
>>>> proposal?  How does it differ from Tim's proposal?
>>> I get lost in who's proposal is who's.  I thought we were working
>>> towards one collectively owned solution.  can you describe what you
>>> think Tim's, your's and mine are?
>> It's all one proposal.  Etienne's principal idea with a few others
>> meddling on the side :-)
>> Regards,
>> Tim

View raw message