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 21:16:19 GMT
BTW, I'm more than happy if you just do a quick sketch of what you're 
thinking, and we resume the convo from there.

I just wanted to clear up some confusion I had.

geir


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

Mime
View raw message