<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 29, 2014 at 2:18 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 28.01.2014, at 23:38, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
<br>
> You weren't clear about that.<br>
<br>
</div>Really now, we're down to grammar?<br>
<div class="im"><br>
> Your first sentence said you "don't want to proxify",<br>
<br>
</div>Which was citing your commit message.<br>
<div class="im"><br>
> then you said, "proxying MC ancestry is a Bad Idea"<br>
<br>
</div>Wherein I specify exactly which proxies I am talking about, not the general idea of proxies.<br>
<br>
> without saying why,<br>
<br>
The whole conversation is about the problems your proxies generate, and it goes back for months, as you remember, so I don't feel the need to restate it.<br>
<div class="im"><br>
> and finally you said, "these proxies are brittle,"<br>
> possibly suggesting that another kind of proxy besides THESE proxies<br>
> would fit better..?<br>
<br>
</div>No, I wrote "proxying MC ancestry is a Bad Idea", period.<br>
<div class="im"><br>
> I still don't know which of these three<br>
> interpretations you mean, I guess either the 2nd or 3rd since you said<br>
> not the 1st..<br>
<br>
</div>I meant precisely what I wrote. No need to guess. Proxying MC ancestry is a Bad Idea.<br>
<br>
> [... derisive schooling elided ...]<br>
<div class="im">><br>
> If / when you get into the details of the problem (which, I hope you<br>
</div>> do) and begin to wrestle with the issues of compatibility,<br>
<div class="im">> performance, transparency, and enabling a variable-sized lookback<br>
> history, while still preserving ALL history in case we need it -- At<br>
> that point you might strike an appreciation for how well the Proxy<br>
> solution aligns itself to the problem and associated issues. Sure, if<br>
> its a ticking time-bomb of nitro-glycerin, we can't use it, but I<br>
> never understood why Proxy's are good for so many other similar cases<br>
> but not this one.<br>
<br>
</div>Because MC is a dev tool, not an end-user application. Having a proxy materialization kick in while you're debugging stuff is highly detrimental. They are inherently unpredictable. Just looking at them causes a cross-atlantic network fetch.<br>
<br>
The basic problem is that loading the full ancestry happens as a side-effect of some unrelated operation. You're adding more and more patches trying to avoid materializing the proxies. But you can never be sure you found the last one.<br>
<br>
The proper way to go about this is to make Monticello aware that the full ancestry might not be available. Then at a few select places where it really needs the full ancestry, insert calls to load that ancestry.<br></blockquote>
<div><br></div><div>IMO, there's another thing worth doing, and that is sorting and uniqueifying the history. I see duplicate entries in the ancestry which causes it to bloat (I suspect this happens on e.g. merge, but I'm not sure). I have seen my manual attempts at uniqueifying ancestry shrink significantly the size of mcz files.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This would ensure that MC again is fully predictable, which you cannot guarantee with the proxy approach.<br>
<br>
- Bert -<br>
<br>
> [... more vitriol disguised as pity ...]<br>
<div class=""><div class="h5">><br>
> On Tue, Jan 28, 2014 at 3:56 PM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
>> I am not going to argue your straw man. I am talking about MC ancestry specifically, not proxies in general, as you are well aware. You keep saying "my proxies are great if we just fix this last bug here". I disagree.<br>
>><br>
>> - Bert -<br>
>><br>
>> On 28.01.2014, at 22:40, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
>><br>
>>> Bert, perhaps Eric Gamma would be interested in debating with you the<br>
>>> validity of Proxy pattern, I'm not. The only thing I can do is direct<br>
>>> you to works of universally accepted design patterns [1] and scores of<br>
>>> systems that use Proxy's reliably, everyday (including Magma).<br>
>>><br>
>>> Further, I already stated I'm not beholden to solving the problem with<br>
>>> the Proxy pattern, yet you continue to hammer your adjectives on it.<br>
>>> Why won't you say something about the problem it's targeting and/or<br>
>>> offer up one of your "much less brittle ways to achieve this..."?<br>
>>><br>
>>> [1] -- (see Chapter 4)<br>
>>> <a href="http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_1?ie=UTF8&qid=1390944300&sr=8-1&keywords=design+patterns" target="_blank">http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_1?ie=UTF8&qid=1390944300&sr=8-1&keywords=design+patterns</a><br>
>>><br>
>>> or<br>
>>><br>
>>> <a href="http://www.amazon.com/The-Design-Patterns-Smalltalk-Companion/dp/0201184621/ref=sr_1_2?ie=UTF8&qid=1390944324&sr=8-2&keywords=design+patterns+smalltalk" target="_blank">http://www.amazon.com/The-Design-Patterns-Smalltalk-Companion/dp/0201184621/ref=sr_1_2?ie=UTF8&qid=1390944324&sr=8-2&keywords=design+patterns+smalltalk</a><br>
>>><br>
>>> On Tue, Jan 28, 2014 at 11:26 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
>>>>> - Don't proxify WorkingCopy ancestry for the release because we still have a bug.<br>
>>>><br>
>>>> Chris,<br>
>>>><br>
>>>> we don't want to proxify not just because it's buggy, but because proxying MC ancestry is a Bad Idea. There are much less brittle ways to achieve this. Our dev tools need to be rock-solid. These proxies are unpredictable and therefore have no place in a stable release.<br>
>>>><br>
>>>> - Bert -<br></div></div></blockquote></div>-- <br>best,<div>Eliot</div>
</div></div>