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 Thu, 02 Nov 2006 20:51:40 GMT

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.

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

>> What I've suggested is  :
>>   forward(X, platform) -> Y
>>   reverse(X, platform, Y') -> X'
> OK.  I see this in *addition* to:
>  forward(X, devtarget) -> Y
>  reverse(Y') -> X'

I believe that

   reverse(X, palatform, Y') -> X'

is the same as

   reverse(Y') -> X'

as you need to know at least what platform Y' is, and what it came from. 
  You could always embed as metadata in the code itself in a comment, I 
suppose.  I was just being explicit.

> So, to simplify the discussion, let's rewrite your proposal as:
>  forward(X, releasetarget) -> Y
>  reverse(Y',X,releasetarget) ~~> X' (possibly reporting
>                                      conflicts/problems)
> 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.

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.

So what to do with a patch?

I can either

   patch -p0 << reverse(patch.file)

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.


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


View raw message