[squeak-dev] re: MicroSqueak

Igor Stasenko siguctua at gmail.com
Tue Mar 3 01:32:32 UTC 2009


2009/3/3 Igor Stasenko <siguctua at gmail.com>:
> - Show quoted text -
> 2009/3/3 Eliot Miranda <eliot.miranda at gmail.com>:
>>
>>
>> On Mon, Mar 2, 2009 at 3:51 PM, Eliot Miranda <eliot.miranda at gmail.com>
>> wrote:
>>>
>>>
>>> On Mon, Mar 2, 2009 at 3:25 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>>>
>>>> 2009/3/3 Eliot Miranda <eliot.miranda at gmail.com>:
>>>> - Show quoted text -
>>>> - Show quoted text -
>>>> >
>>>> >
>>>> > On Mon, Mar 2, 2009 at 1:48 PM, Stephen Pair <stephen at pairhome.net>
>>>> > wrote:
>>>> >>
>>>> >> On Mon, Mar 2, 2009 at 12:38 AM, Eliot Miranda
>>>> >> <eliot.miranda at gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>>
>>>> >>> On Sun, Mar 1, 2009 at 9:20 PM, Craig Latta <craig at netjam.org> wrote:
>>>> >>>>
>>>> >>>> [snip]
>>>> >>>>     As for whether to produce an object memory statically and then
>>>> >>>> set
>>>> >>>> it running, or transform an object memory which is always running...
>>>> >>>> I think
>>>> >>>> the resulting memory will need to load modules live anyway, so one
>>>> >>>> might as
>>>> >>>> well do all the transformations that way. Perhaps this is simply an
>>>> >>>> aesthetic choice.
>>>> >>>
>>>> >>> Surely repeatability mandates that one roduce an object memory
>>>> >>> statically
>>>> >>> and then set it running?  Because of things like delays the always
>>>> >>> running
>>>> >>> memory is almost never in a predictable state, so one always ends up
>>>> >>> with
>>>> >>> different bits even if they represent the same functionality.
>>>> >>> E.
>>>> >>
>>>> >> Maybe you could get the repeatability with a process that is roughly:
>>>> >> a) write the spec for the capability of the image (a method that
>>>> >> exercises
>>>> >> everything you want to be able to do)
>>>> >> b) use the class/method copying & DNU trickery and do the runtime
>>>> >> analysis
>>>> >> to figure out the classes and methods needed to support that
>>>> >> capability
>>>> >> c) do something a little more surgical to build a new image by copying
>>>> >> over the behaviors and methods, but construct the processes and stacks
>>>> >> more
>>>> >> deliberately (so you aren't so tied to the running image's state)
>>>> >> I'd think in this way you could do something that was reproducible to
>>>> >> the
>>>> >> extent that resulting image was only dependent on the running image
>>>> >> for its
>>>> >> behaviors and other necessary objects (various singletons and
>>>> >> whatnot), but
>>>> >> otherwise not affected by various processes and random other things
>>>> >> that
>>>> >> might be in that image.  Once you had (b) and (c) mostly ironed out,
>>>> >> it
>>>> >> would be a process of refining the specification in (a) to get to a
>>>> >> suitable
>>>> >> minimal image.
>>>> >
>>>> > Agreed.  The nice thing is being able to run a) in the IDE so that when
>>>> > something is missing it manifests as an Undeclared or an MNU.
>>>> > One thing is ensuring that when simulating objects like nil, true and
>>>> > false
>>>> > behave as they will in the result, not as defined in the host image.
>>>> >  One
>>>> > thing one could do is arrange that the compiler for MObject uses
>>>> > instances
>>>> > of MSymbol for all code under MObject.  Then e.g. a doesNotUnderstand:
>>>> > handler on SmallInteger, UndefinedObject, Boolean et al might be able
>>>> > to
>>>> > forward things correctly and arrange that the simulation was more
>>>> > accurate.
>>>> >
>>>>
>>>> - Show quoted text -
>>>> Thats why i wrote own parser/compiler in Moebius.
>>>> It is designed in a way, that a parser & compiler output is under full
>>>> control of an object which plays role as environment.
>>>> So, you can produce an instance of CompiledMethod as output, or encode
>>>> result in machine code, or represent methods as a raw bytes which then
>>>> could be put in the image you constructing.
>>>> Even nil,true,false singleton values are under control of environment.
>>>>
>>>> Read more about it here.
>>>> http://code.google.com/p/moebius-st/wiki/Parser
>>>>
>>>> Simulation of SmallInts could be made easy - we could simply make a
>>>> class, named BoxedSmallInteger
>>>> and use it for representing all literal values in methods. At final
>>>> stage of image creating we can unbox them and replace by smallints.
>>>
>>> Cool.  So the compiler can avoid using the pushNil, pushFalse and pushTrue
>>> bytecodes.  It must send some message to coerce every MBoolean result into a
>>> host Boolean before doing a conditional jump.  It must wrap all
>>> MSmallInteger relational primitive invocations with code to coerce the
>>> Booleran to the matching MBoolean.
>
> right , something like:
>
> MSmallInteger >> #<
> < object
>   ^ MBoolean from: boxed < object boxedValue
>
>>> A doesNotUnderstand: will produce an instance of Message and send
>>> doesNotUnderstand:, do MObject needs a doesNtUnderstand: handler that sends
>>> MSymbol #doesNotUnderstand: with a coercion of the Message to an MMessage.
>
> why care converting it, when you can simply replace a Message class
> with MMessage in special objects array, while running a 'sandboxed'
> code :)
>
> Second thing about #doesNotUnderstand:
> Often people forgetting that some classes could have own custom
> #doesNotUnderstand: method.
> I'd rather do not put any expectations on DNU while designing
> micro-image bootstrapper.
>
> And i seem missing the direction where this discussion turned out.
> Where/when we would want to run a code in host environment?
>
> In Moebius, since it is hosted in Squeak, and since we having better
> parser ;) i could simulate the method behavior at multiple stages
> including just after parsing a method.
> I created a simple MockContext class, which can evaluate things
> strictly in a manner how it is parsed from method source.
> This, for instance, allows us to test parser output in a complete
> black-box fashion:
>
> testEvaluateParserOutput
>        | method |
>
>        method := self parse: ' = x  ^ x == self ' class: Object.
>        self assert: [
>                (CVMockContext evaluate: method arguments: #(1 1)) == true.].
>        self assert: [
>                (CVMockContext evaluate: method arguments: #(true false)) == false.]
>
> testEvaluateParserOutput2
>        | method |
>        method := self parse: ' foo ^ #(nil true false) ' class: Object.
>        self assert: [
>                (CVMockContext evaluate: method arguments: #(nil)) = #(nil true false)].
>        method := self parse: ' foo ^ #(#a #b #c) ' class: Object.
>        self assert: [
>                (CVMockContext evaluate: method arguments: #(nil)) = #(#a #b #c)].
>        method := self parse: ' foo ^ #() ' class: Object.
>        self assert: [
>                (CVMockContext evaluate: method arguments: #(nil)) = #()].
>
> note, that 'method' above is not a CompiledMethod, it is an AST form
> of parsed source, encoded as lambda message sends.
>
>
>>>  Any other holes that need to be plugged?
>>> Alternatively just create a subclass of InstructionStream and/or
>>> ContextPart and interpret all code and have the interpretation manage
>>> MObject.  That might be slow but easier to get going.
>
>>
>> But perhaps a better alternative is just to use Hydra and provide a remote
>> debugging interface to another Hydra space.  So there's a version of the
>> Hydra spawn operation that constructs the heap from MObject.  That machinery
>> would be easy to extend, right Igor?
>
> Right, this is what i'm writing between the lines :)
> I willing to have a generic toolset which could easily produce a
> micro-images for any purposes, including a kernel-image, of course.
> Lately , we discussed a one more little primitive for Hydra with Klaus
> , and one more kind of channel - an object channel. It will allow you
> to transfer objects (even cloning a subgraphs) between images , not
> just dumb raw number of bytes :) This could ease developing tools
> which require interaction between images, because you don't have to
> care about serializing/deserializing stuff - you literally just send
> what you want to other side.
>
A little more about that.
VM is capable to recognize a most basic object types (ints, strings,
bytes etc), to allow us to transfer objects in JSON-like style.
Suppose you want to transfer an instance of class #Foo, which can't be
recognized by VM.
You can serialize it as an array, like:
#(#Foo ivar1value ivar2value ...)

then, at receiving side, it is quite simple to reconstruct it into
instance of Foo class.
Compare this with amount of processing you may need if you limited
only to exchange using raw byte buffers.

>> How about the remote debugging?  How minimal is the debugging stub that must
>> exist in the spawned MImage? Would one need VM changes (e.g. a callback
>> handler for a recursive doesNotUnderstand: error)?
>>
>
> I think that putting debugger support into VM will be a big mistake.
> Debugging is a fairly complex domain, and i don't think that we need
> to deal with this at VM level, where is no objects but oops, headers &
> bits.. This is right way to get a hellishly complex & unmanageable
> artifact.
>
> Debugger, as anything else is invoked using regular message send -
> (during Error>>signal). So, it is easy to hook into it and turn into
> right direction.
> I made a simple class HydraDebugToolSet, which replaces an image
> default toolset for images which running in background.
> In result, when error happens, it sends an error message to a
> #transcript channel of main interpreter.
> Nothing stops us from getting a bit further and request main
> interpreter to establish a remote debugging session (except that we
> don't have Debuggers with remote debugging capabilities ;) ).
> But i know there is already at least one remote debugger
> implementation in Squeak - GemStone tools. It is using OB tools to
> generate UI & other stuff.
> I'm not sure, what license it having, and could it be took as base for
> remote debugging tool for Squeak.
> (it would be nice to have a basic remote debugging framework in
> squeak, which could allow different backends - either G/S , remote
> socket connection, or via Hydra channels).
>
>>>> We're in smalltalk, after all, where such things is possible to do,
>>>> unlike many other languages :)
>>>
>>> Right on!
>>>
>>>>
>>>> >>
>>>> >> - Stephen
>>>> - Show quoted text -
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>
>
> --
> - Show quoted text -
> Best regards,
> Igor Stasenko AKA sig.
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list