[squeak-dev] The solution of (Was: Creating an image from first principles)

> On Thursday 07 Aug 2008 8:45:12 pm tim Rowledge wrote:
>> On 7-Aug-08, at 5:18 AM, K. K. Subramaniam wrote:
>>> I think the original question about creating an image from first
>>> principles
>>> was about transmutation, not cloning.
>>
>> The SystemTracer can easily create new images from specs rather than
>> 'merely cloning' an existing image.
> SystemTracer is a Smalltalk utility. So it does not qualify as a  
> transmutation
> tool.

>
>
>>> How does one create a Smalltalk
>>> environment (i.e. an image) starting with an environment that has  
>>> only
>>> imperative programming tools (e.g. C/C++, Forth etc.)? What is
>>> sought is a
>>> process that can be replicated by anyone proficient in the  
>>> imperative
>>> environment.
>>
>> Why waste time using crappy tools...
> Mmm.. Why do the tools and utilities required to build a VM, garbage
> collector, primitives and plugins suddenly become "crappy" when  
> building an
> initial image?

>
> On 7-Aug-08, at 11:21 AM, Igor Stasenko wrote:
>>
>>
>> Maybe i was not precise (sorry for my bad English).
>> SystemTracer alone doesn't provide any sophisticated means how to
>> terminate a subgraph by replacing edges to something different,
>> neither any criteria upon which edges can be replaced/removed etc.
>> I mean, this is completely up to you - what objects will/can be placed
>> in swapMap.
>>
> It gives you complete and total control over what goes into the wordarray
> that will be written out as an image, not just what gets swapped or clamped.
> Making a variant tracer that read a spec from XML (or whatever) and created
> objects in the 'new OM' is entirely possible. The hardest part (from my
> point of view) would be reading the xml and understanding it. Oh, and
> designing the entire spec of an image in XML would be kinda amusing too.
>

> Much more sensible would be creating some tools in a decent language
> (Squeak, duh) to allow us to define a class graph for the new image along
> with specs for whole it all gets written out. Since the new objects would
> not need to execute anything in the 'old' image there would be no problem
> with compatibility. Then you create a script that writes out suitable
> instances of the essential objects for the new image; you do not need to
> have ever created them in the old image, though it may well be simpler to do
> so in most cases.
>
> You could create an image with a totally different object format, image
> layout, class tree, bytecode set, etc this way. And of course you could
> modify the simulation code so that you could run it all before ever
> compiling a 'real VM. That's what it is all there for.
>

>
>> > > ...SystemTracer [doesn't give us a way to] truncate unwanted stuff
>> > > from the current image to produce a new, smaller one.
>> >
>> > Yes, it does. It's called "clamping". See the class comment for
>> > SystemTracer. :)
>>
>> I have a SystemTracer2, which comment reads... [no mention of
>> clamping]
>
>     I was referring to the class comment for SystemTracer (in, for example,
> Squeak 3.2). In particular, it says "The tracer has built-in support for
> clamping unwanted (or unneeded) objects out of the system."
>
>     More importantly, Tim has used it extensively and been-there-done-that
> with all of this. :)
>

> 2008/8/8 Craig Latta <[hidden email]>:
> >
> >     More importantly, Tim has used it extensively and been-there-done-that
> > with all of this. :)
>
> Tim, could you please pick some books from dusty shelves for me? ;)
>
> If you have freely available sources & samples, which could be useful,
> please let me know.
>

> 2008/8/8 tim Rowledge <[hidden email]>:
>>
>> On 7-Aug-08, at 11:21 AM, Igor Stasenko wrote:
>>>
>>>
>>> Maybe i was not precise (sorry for my bad English).
>>> SystemTracer alone doesn't provide any sophisticated means how to
>>> terminate a subgraph by replacing edges to something different,
>>> neither any criteria upon which edges can be replaced/removed etc.
>>> I mean, this is completely up to you - what objects will/can be placed
>>> in swapMap.
>>>
>> It gives you complete and total control over what goes into the wordarray
>> that will be written out as an image, not just what gets swapped or clamped.
>> Making a variant tracer that read a spec from XML (or whatever) and created
>> objects in the 'new OM' is entirely possible. The hardest part (from my
>> point of view) would be reading the xml and understanding it. Oh, and
>> designing the entire spec of an image in XML would be kinda amusing too.
>>
> No XML please.  :)
> Few lines of smalltalk code can do literally same as few megabytes of XML spec.
>
>> Much more sensible would be creating some tools in a decent language
>> (Squeak, duh) to allow us to define a class graph for the new image along
>> with specs for whole it all gets written out. Since the new objects would
>> not need to execute anything in the 'old' image there would be no problem
>> with compatibility. Then you create a script that writes out suitable
>> instances of the essential objects for the new image; you do not need to
>> have ever created them in the old image, though it may well be simpler to do
>> so in most cases.
>>
>> You could create an image with a totally different object format, image
>> layout, class tree, bytecode set, etc this way. And of course you could
>> modify the simulation code so that you could run it all before ever
>> compiling a 'real VM. That's what it is all there for.
>>
>
> Very good. Is it available somewhere (SystemTracer, not SystemTracer2)
> so i can download it as separate package?
>
> As you may guess, i'm not interesting in mutating object formats or
> bytecodes or whatever, but to define a small subset of image (either
> by creating a brand new objects or by reusing already existing
> objects) to be transferred into new image & run within new Hydra
> thread.
>
> In this regard, the most interesting to me - mentioned 'clamping'
> techniques seem completely wiped out from SystemTracer2.
>

> >> Why waste time using crappy tools...
> >
> > Mmm.. Why do the tools and utilities required to build a VM, garbage
> > collector, primitives and plugins suddenly become "crappy" when
> > building an
> > initial image?
>
> They don't. They're crappy to begin with. I've spent decades fighting
> with C compilers and debuggers etc etc etc and anyone that claims
> they're good is clearly either totally inexperienced with using them
> or deluded.

> On Friday 08 Aug 2008 5:21:45 am tim Rowledge wrote:
>> On 7-Aug-08, at 10:25 AM, K. K. Subramaniam wrote:
>> > SystemTracer is a Smalltalk utility. So it does not qualify as a
>> > transmutation
>> > tool.
>>
>> What? Don't be silly.
> No. I am dead serious. I am curious about what does it take for a
> non-smalltalk system to self host a Smalltalk environment? If there is
> already a Smalltalk environment then the question doesn't arise at all.
>
>> >> Why waste time using crappy tools...
>> >
>> > Mmm.. Why do the tools and utilities required to build a VM, garbage
>> > collector, primitives and plugins suddenly become "crappy" when
>> > building an
>> > initial image?
>>
>> They don't. They're crappy to begin with. I've spent decades fighting
>> with C compilers and debuggers etc etc etc and anyone that claims
>> they're good is clearly either totally inexperienced with using them
>> or deluded.
> Different strokes for different folks, I suppose. Back to the main query -
> what is so mysterious ;-) in a image that can't be captured in an imperative
> environment?
>

>
>> ...what is called 'clamping' in SytemTracer is literally same what is
>> called swapMap in SystemTracer2 - there are same thechnique behind it:
>> replace one oop with another during tracing.
>
>     It's also used to omit objects entirely. This is a clearly critical
> feature, since you usually want to include objects created during the trace.
>
>     At any rate, I still claim that the hard (and interesting) part of this
> problem is deciding which objects you want to put in the new image, and you
> haven't addressed that at all.
>