On Oct 13, 2005, at 8:40 PM, Daniel Vainsencher wrote:
>>
>>  There are manual ways for an experienced developer to  integrate  
>> Traits into whatever image I give them.  There may be  challenges  
>> unique to any particular image, but they would certainly  be  
>> solvable.
>>
> Here we dont - the challenges for Traits are not unique for some  
> specific image at all. Adrian and I have already created and run  
> such a script, so while we don't yet have something I'd put on the  
> update stream, we know what the issues are.
>
> They are specific to Traits, but quite independent of the image -  
> when you change the mechanism for adding methods, to use new  
> methods, then those methods need to be loaded before any changes  
> happen. This is true in any image that has never had those methods  
> (true across images). Furthermore, from Stef's more recent example,  
> this problem happens whenever you change any mechanism that is  
> somehow involved in updating methods - such as drawing the progress  
> bar... therefore its a technical problems that will happen in many  
> cases. Feels very strange to tell you this - the solution in this  
> situation is fixing the infrastructure, not smart people applying  
> their brains every time, manually, for every image.
>
>
>> And once solved, it's very likely that any further  updates to  
>> Traits - loading new versions of the various Traits  packages -  
>> would be much easier.  Maybe still a manual process in  some  
>> cases, but easy enough that it could be done at regular   
>> intervals.  And anyone who was a client of that image line would  
>> get  that integration for free, by downloading the newly  
>> integrated image.
>>
> So the person most qualified to solve the problem (the person that  
> wrote the change) - now finds it impossible to help in the solution  
> of this problem. This is because he doesn't even know about, never  
> mind take part in the development of all image-lines.
>
> Instead this work is thrown on image-line maintainers (for whom it  
> takes time to understand the change) in a way they cannot share  
> between them, so each wastes time on it anew..

Ah, good, I was waiting for you to respond ;)

So I think this goes back to our discussion when you were in  
Vancouver about how to specify (one-off) dependencies between package  
versions: I was arguing that in many cases simply putting a comment  
on one saying "you have to load version B of package Q at the same  
time" would suffice, rather than coming up with an automated  
technical solution (that probably wouldn't solve the interesting edge  
cases anyway).

I'd make the same argument here: if you have a script for how to load  
Traits, that's great.  It certainly makes the job of all of those  
fictional image-line maintainers much easier, and the more we can  
build tools to make their job easier, the better.  Monticello,  
obviously, falls into this category, and even if we got rid of the  
SqF update stream, I would still be interested in improving MC to the  
point where it *could* be used for an update stream (or at least be  
95% of the way there), especially since I expect some users (Tweak  
etc) to continue to use it in that context.

But there's a big difference between saying "the more we can automate  
an update the better", and saying "if we can't automate it, it  
doesn't get in".  The latter is the situation we're in right now, and  
I think it's counter productive - especially when the full burden of  
automatability is placed on the (small number of) integrators vs. the  
(larger number of) package maintainers.  If we're going to ease that  
bottleneck, we need as a community to be stricter in what we produce  
(eg, MC versions of packages derived from the minimally required  
ancestor) and more liberal in what we accept (images and instructions  
rather than a perfect  automated update stream).

>>
>> I enjoy solving hard problems, but not for their own sake.  If I  
>> can  see a way to be lazy and avoid them, I take it every time...
>>
> But at some point you realize that these are coming all the time,  
> and its worth working once to kill them all - if the cost is  
> reasonable.
>
> Do you estimate we're not there yet for solving this issue of  
> method dependencies?
>
> Just as a quick sanity check, the following code does not  
> immediately crash the image
>
> firsts _ ProtoObject withAllSubclasses asArray collect: [:cl |  cl  
> methodDictionary].
> seconds _ ProtoObject withAllSubclasses asArray collect: [:cl |  cl  
> methodDictionary copy].
> firsts elementsForwardIdentityTo: seconds
>
> So the atomic load method you suggested is probably not impossible.

That's good to know, and definitely worth experimenting with.  As I  
said above, I'm very interested in moving MC forward to solve as many  
of these problems as possible - but I'd rather that our process  
wasn't absolutely dependent on them being solved in the meantime.  It  
may be that by expecting less of our tools short term, we'll end up  
ahead in the long run.  I don't know; but it seemed like a question  
worth asking.

Cheers,
Avi