[squeak-dev] The Trunk: Monticello-cmm.585.mcz

Chris Muller asqueaker at gmail.com
Wed Jan 29 15:59:31 UTC 2014


Good morning Bert,

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

I feel like I'm reading the same message, which is you don't like them
anywhere, not just in MC.  Some large database end-user apps are just
as important as MC.   I doubt you're saying it's okay for such an app
to endure "highly detrimental", "inherently unpredictable", Proxy's.
Maybe you mean for a video game it would be okay..

> The basic problem is that loading the full ancestry happens as a side-effect of some unrelated operation.

It happens when a message is sent to the Proxy, so it can't be THAT unrelated.

> You're adding more and more patches trying to avoid materializing the proxies.

I haven't touched it in months.

> But you can never be sure you found the last one.

You can never be sure you've found the last bug, of any type, in any
system.  But yes, Proxy's are slightly more-challenging to debug, and
invariably require some "patching".  But, in my experience, once
they've been debugged, they pay dividends for a long time without
having to touch it.  That last part is a pattern consistent with any
implementation.

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

Fine, my goal is to have the problem solved, not use Proxy's or
convince you to like them.  Let's tackle it in 4.6.

> This would ensure that MC again is fully predictable, which you cannot guarantee with the proxy approach.

I feel that oversells it a bit, but I understand your feelings.

>>   [... more vitriol disguised as pity ...]

I often feel like a junior-programmer when you lecture me.  The Cog VM
might crash or an Environments bug might cause Associations to be
shared across Dictionary's and you'll say nothing or something
helpful.  But I feel like you reserve your most dramatic and derisive
adjectives for MY work.

Hopefully we'll get each other figured out someday..  :)


More information about the Squeak-dev mailing list