Thanks for the clarification. There were indeed some misconceptions on 
my end regarding imprinting and inert method removal.

Cheers,
   - Andreas

Craig Latta wrote:
> 
> Hi--
> 
>      I think there were some misconceptions about Spoon on the part of 
> both Igor and Andreas; I'll try to clarify.
> 
>      Igor writes:
> 
>  > ...i think, best would be to incorporate Spoon features to VM. As i
>  > understand (Craig, correct me if i'm wrong), a Spoon VM changes are
>  > incremental and not breaking any compatibility.
> 
>      Andreas responds:
> 
>  > I'm not sure which changes you mean. If it's about imprinting, I'm no
>  > fan of that. I don't want methods automatically transferred between
>  > images...
> 
>      Imprinting is just the direct transfer of CompiledMethods from one 
> object memory to another (making source code, which in general is 
> ambiguous, an optional medium for behavior distribution). The scheme for 
> determining the content and timing of that transfer may vary.
> 
>      One scheme is to transfer each method that a providing object 
> memory runs, immediately, to a consuming object memory (the case you 
> mention above, let's call it "session imprinting"). I see that as useful 
> in a presentation situation (at a conference, for example), where the 
> audience may want to receive the behavior the presenter is 
> demonstrating. Each recipient could then duplicate the demo later, 
> without having to spend any effort on installation. I think using this 
> facility, in coordination with *good unit tests* for the subsystem being 
> presented, would be very useful. But I wouldn't rely on it to organize a 
> system in normal development.
> 
>      Another scheme, the one I'm working on now[1], is to organize all 
> the behavior of each system into clearly-delineated modules. Each module 
> can then imprint its methods onto a requesting system (nothing automatic 
> about it, necessarily). Each module can also describe its relationships 
> to other modules (dependency on other modules, containment of other 
> modules, etc.).
> 
>  > ...I want tools that I can use in a remote image to load and edit code
>  > just like I do in the "main" image. With the end result being a
>  > well-defined set of packages that are designed to work together.
> 
>      Right, this is what I intend.
> 
>      Igor responds:
> 
>  > I'm about marking oops while code running, to get a part of image
>  > which required to run your code and scrap the rest.
> 
>      Andreas responds:
> 
>  > Yes, and that's exactly what I'm no fan of  ;-)  In a realistic
>  > situation you'd really want to understand what is being used where -
>  > the fact that a particular method hasn't been touched during a
>  > particular run of the code is just as insignificant as the fact that
>  > during a debugging session you might touch code that isn't even in the
>  > product you're trying to design.
> 
>      Again I think there's a misunderstanding here about the intended 
> purpose of a Spoon feature. Indeed, I never intended for "inert method 
> removal" (as I've been calling it) to be used frequently. I only 
> intended to use it once, to help derive the absolute minimal object 
> memory from which all other object memories would derive (there's still 
> some manual labor after that to get to the absolute minimal system). 
> After this has been done, and after there is a modularity mechanism to 
> enable the clear organization of larger systems, one shouldn't need this 
> facility anymore.
> 
>      I suppose there will be a use for it whenever a system turns into 
> spaghetti (like Squeak is now :), but I think we can move past that.
> 
>      Igor responds:
> 
>  > Well, there is people who wish to see such capabilities, and if Spoon
>  > features orthogonal to your approach, then why not include them?
> 
>      Andreas responds:
> 
>  > ...I cannot see any situation in which someone would really want to
>  > rely on [inert method removal]. It seems to me that the approach is
>  > (as you said in an earlier email) a way to create smaller images
>  > "without much effort". I'm interested in the *hard* way of doing this
>  > (i.e., by going in and refactoring and removing things manually)
>  > because I think this is the only way in which it can be done in
>  > practice.
> 
>      I think we're in agreement here. After creating a clearly minimal 
> object memory, and a module system for adding behavior while maintaining 
> clear organization, I'm interested in the hard work of deciding what the 
> content of those modules should be for the behavior we want to deploy. I 
> do think that session imprinting (defined above) could be useful for 
> finding a first approximation of what behavior is used by a subsystem 
> (e.g., Morphic).
> 
>  > I just happen to think that the mechanism is fundamentally flawed and
>  > cannot possibly work the way in which people naively think it ought to
>  > work.
> 
>      The mechanism, when used for its intended purpose, is sound. I 
> wholeheartedly agree that some have misunderstood its purpose.
> 
>  > But be that as it may - the real question is this: Let's assume we
>  > have a tiny kernel image that is about 100k in size and that we can
>  > build up from. What good is the mechanism at this point? It seems to
>  > me that it is only useful to get to a small image but once this is
>  > achieved it's basically obsolete.
> 
>      That is my fervent hope. :)
> 
>  > And I'm definitely not in favor to modify the VM for something that
>  > will only have a very short window of usefulness.
> 
>      Again, I think the changes do not increase the complexity of the 
> virtual machine in any meaningful way. These are minute changes to the 
> garbage collector, which is already so complicated that you can count 
> the number of people who even dare to look at it on one hand. :)  (I'd 
> like to change that situation, by the way.) Furthermore, since the 
> usefulness of the changes during that short window is so high, and there 
> is the unfortunate possibility that the ability may be needed again in 
> the future, I think they would be justified even if they did impose some 
> significant increase in complexity.
> 
>      Finally, the new garbage collector behavior is accessed through a 
> function interface which is separate from the normal one; the normal 
> garbage collection behavior is unaffected and the new behavior is 
> optional (one invokes fullGCDisardingInertMethods and 
> incrementalGCDiscardingStaleMethods instead of fullGC and incrementalGC. 
> In turn, these new functions invoke distinct mark phase behavior.
> 
> 
>      thanks!
> 
> -C
> 
> [1] This is "Naiad" (short for "Name and Identity Are Distinct"),
>     Spoon's module system. Naiad has been my prime motivation for Spoon
>     from the beginning; it's my attempt to resolve what I have always
>     seen as Smalltalk's biggest shortcoming: poor support for deployment
>     in general and modularity in particular.
> 
> -- 
> Craig Latta
> improvisational musical informaticist
> www.netjam.org
> Smalltalkers do: [:it | All with: Class, (And love: it)]
> 
> 
>