[squeak-dev] Hydra/Spoon

>
> 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)]
>
>
>