harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] Preprocessor - CHECKPOINT
Date Thu, 02 Nov 2006 22:35:48 GMT
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 a
>>>> 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 for
>>>> 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.

>>> 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


>> 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.

> 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.

> 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.

> 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 :-)



Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message