On Wed, Jan 29, 2014 at 2:18 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 28.01.2014, at 23:38, Chris Muller <asqueaker at gmail.com> wrote:
>
> > You weren't clear about that.
>
> Really now, we're down to grammar?
>
> >  Your first sentence said you "don't want to proxify",
>
> Which was citing your commit message.
>
> > then you said, "proxying MC ancestry is a Bad Idea"
>
> Wherein I specify exactly which proxies I am talking about, not the
> general idea of proxies.
>
> > without saying why,
>
> 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.
>
> > and finally you said, "these proxies are brittle,"
> > possibly suggesting that another kind of proxy besides THESE proxies
> > would fit better..?
>
> No, I wrote "proxying MC ancestry is a Bad Idea", period.
>
> >  I still don't know which of these three
> > interpretations you mean, I guess either the 2nd or 3rd since you said
> > not the 1st..
>
> I meant precisely what I wrote. No need to guess. Proxying MC ancestry is
> a Bad Idea.
>
> > [... derisive schooling elided ...]
> >
> > If / when you get into the details of the problem (which, I hope you
> > do) and begin to wrestle with the issues of compatibility,
> > performance, transparency, and enabling a variable-sized lookback
> > history, while still preserving ALL history in case we need it -- At
> > that point you might strike an appreciation for how well the Proxy
> > solution aligns itself to the problem and associated issues.  Sure, if
> > its a ticking time-bomb of nitro-glycerin, we can't use it, but I
> > never understood why Proxy's are good for so many other similar cases
> > but not this one.
>
> 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.
>
> 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.
>
> 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.
>

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.

This would ensure that MC again is fully predictable, which you cannot
> guarantee with the proxy approach.
>
> - Bert -
>
> >   [... more vitriol disguised as pity ...]
> >
> > On Tue, Jan 28, 2014 at 3:56 PM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> >> 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.
> >>
> >> - Bert -
> >>
> >> On 28.01.2014, at 22:40, Chris Muller <asqueaker at gmail.com> wrote:
> >>
> >>> Bert, perhaps Eric Gamma would be interested in debating with you the
> >>> validity of Proxy pattern, I'm not.  The only thing I can do is direct
> >>> you to works of universally accepted design patterns [1] and scores of
> >>> systems that use Proxy's reliably, everyday (including Magma).
> >>>
> >>> Further, I already stated I'm not beholden to solving the problem with
> >>> the Proxy pattern, yet you continue to hammer your adjectives on it.
> >>> Why won't you say something about the problem it's targeting and/or
> >>> offer up one of your "much less brittle ways to achieve this..."?
> >>>
> >>> [1] -- (see Chapter 4)
> >>>
> 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
> >>>
> >>> or
> >>>
> >>>
> 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
> >>>
> >>> On Tue, Jan 28, 2014 at 11:26 AM, Bert Freudenberg <
> bert at freudenbergs.de> wrote:
> >>>>> - Don't proxify WorkingCopy ancestry for the release because we
> still have a bug.
> >>>>
> >>>> Chris,
> >>>>
> >>>> 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.
> >>>>
> >>>> - Bert -
>
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140129/f17ccad1/attachment.htm