[self-interest] Filing Out A Composite Morph?

Russell Allen mail at russell-allen.com
Mon Dec 27 01:20:50 UTC 2010 

I suspect the Squeak segments tech is useful not because it is correct but because it is very fast. Croquet uses it in conjunction with its Islands, which are very isolated large scale object clusters.  The advantage they have, which NewSpeak has even more and we don't, is that they can treat classes as immutable and therefore easily shared. I'm not sure it is possible to safely segment a Self world any further than the world itself.

To answer Josh's question, I've played around with the ImageSegment approach at the Self level, but without leveraging the garbage collector I think its likely to be too slow to be all that much use.

- Russell

On 26/12/2010, at 6:24 PM, ungar at mac.com wrote:

> I've looked a little at the Squeak segments, and suspect there are tough problems unsolved there. Perhaps it is useful in ST because that language
> 
> is less dynamic than Self. Filing out a composite morph is something I worked on and decided it was inherently difficult. Just as in the transporter paper,
> there are lots of cases where you simply need input from the human to know the right thing to do. That was my experience, anyway.
> But feel free to tackle the problem. You might crack it!
> 
> - David
> 
> 
> On Dec 25, 2010, at 10:56 PM, Josh Flowers wrote:
> 
>>  
>> 
>> Thanks for the links Russell, both were interesting and written to be understood (neither trait which I find common in the world of CS).
>> 
>> Also agree that having something like ImageSegments in Self would be nice - any feel for how much work it would take?
>> 
>>> Being able to hand edit saved objects with minimal tools in an emergency is quite handy, and saving them in a form which git understands is also handy.
>>> 
>>> What we don't have which would be nice is the image segment technology that Dan put in Squeak. That's really nice (and, outside Croquet, mostly underused and ignored). The key is that it can mark out object graphs using the garbage collector (ie really quickly).
>>> 
>>> Don't underestimate the transporter, its actually pretty cool. I'd recommend reading Dave's paper on it:
>>> 
>>> http://labs.oracle.com/self/papers/transporter_95.pdf    (I don't know why this isn't on the selflanguage.org site - I'll add it)
>>> 
>>> and also, more generally, Peck et al's paper on the issues with using image segments:
>>> 
>>> http://hal.inria.fr/docs/00/53/15/65/PDF/Mart10b-Smalltalks2010-Swapper-ImageSegments.pdf
>>> 
>>> My current thinking is that the only real difference between filing a module out to disk and transporting a complex object like a morph to another world is that the module has a preferred root (ie the lobby) and the complex object doesn't care...
>>> 
>>> - Russell
>>> 
>>> 
>>> On 24/12/2010, at 12:51 AM, Jan-Paul Bultmann wrote:
>>> 
>>>> True,
>>>> 
>>>> I prefer the second approach, although it means breaking one of the last bridges connecting us to traditional computing and file systems. The only practical use I see in classical filling out is to be able to edit code with a text editor. But since the .self format is hard to edit by hand due to all the annotations and bootstrapping code I don't see that much value in it.
>>>> Maybe the way to go is some sort of micro snapshot that can be imported into a real one?
>>>> 
>>>> Cheers Jan
>>>> On Dec 23, 2010, at 1:47 PM, Thorsten Dittmar wrote:
>>>> 
>>>>>  
>>>>> to file out "living" objects is a little bit tricky. they have to be self contained, otherwise you will run into trouble during the file in. I remember gemstone have done something like that for the GEODE environment years and years ago... maybe I should try to reactive my old sun machine to have a look how that was done. maybe somebody else on the list has still access to that stuff?
>>>>> 
>>>>> 
>>>>> the lego metaphor was a good one... Russel, if you move your lego stuff into the cupboard it is still "running" in your world. It is only not visible anymore. even if you send it to somebody else via a "transporter" it is still in the same world with all the same "basic libraries" like the physics etc. 
>>>>> 
>>>>> we should clearly separate two approaches:
>>>>> 
>>>>> 1. to construct an object via script.. this is what the transporter is doing
>>>>> 2. to move an object from one world to another. this is more like distributed computing then like filing in and out. 
>>>>> 
>>>>> from my point of view it makes no sense to implement something which tries to do both things with one mechanism, but maybe i'm wrong or i got you wrong
>>>>> 
>>>>> best regards 
>>>>> 
>>>>> thorsten
>>>>> 
>>>>> On Dec 23, 2010, at 1:11 PM, Jan-Paul Bultmann wrote:
>>>>> 
>>>>>>  
>>>>>> 
>>>>>> Hey,
>>>>>> I totally agree that one should simply save a morph as is without any textual additions.
>>>>>> What if we didn't care about the state the morph currently has. We simply dryfreeze it and revive it later.
>>>>>> I think the reason the whole filing out thing is so darn complex with annotations and creator slots e.t.c is because they didn't wan't to drag over state.
>>>>>> But what is wrong with that :)? I mean how cool would it be to send a document over the air not as a text file, but as a bunch of living objects. (I am ignoring the security risk for now since you can also inject malicious code with the transporter.).
>>>>>> The same goes for the global hierarchy, why are there creator slots and initialization values. The values in the prototypes should be initialized to the right value anyways, and I think it won't be that hard to detect cyclic object creation or multiple references (If this is not already done anyways :)).
>>>>>> 
>>>>>> Thoughts?
>>>>>> 
>>>>>> cheers Jan
>>>>>> On Dec 23, 2010, at 3:33 AM, Russell Allen wrote:
>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>> Josh was kind enough to share his snapshot with me, and I've been looking at this; I don't yet have a conclusion but here is my process:
>>>>>>> 
>>>>>>> First I filed out the ircChannelMorph and filed it into a new world, but it was missing all of its copy down slots (so no rawMorphs etc).  This turned out to be because the transporter thinks in slots: from its perspective the annotation for the ircChannelMorph is in the 'ircChannelMorph' slot on 'globals' (which wasn't part of the ircClient module) and not really in ircChannelMorph itself.  When that was changed, the ircChannelMorph filed out and then back it with its annotation and hence its copied down slots (rawMorph etc).
>>>>>>> 
>>>>>>> Now, although the rawMorphs copied down slot was present, it no longer had any submorphs in it.  Partly this seems to be because the transporter doesn't maintain local values for copied down slots but re-copies their value when saving and loading (so rawMorphs is initialised to a vector copy).
>>>>>>> 
>>>>>>> Removing the rawMorphs slot from the copy down list so it was just a normal slot on ircChannelMorph, and then drilling down setting creator slots and modules meant the next level of submorphs were filed out and in - but then their rawMorphs were similarly missing!
>>>>>>> 
>>>>>>> Now unless I am doing something wrong, this seems a bit of an incompatibility between the transporter, copy down slots, and morphic.
>>>>>>> 
>>>>>>> The obvious solution is to add an 'initialiseMorph' method which is called when filing in and builds the appropriate prototype structure for the morph. This is more or less what I did when I used to use Squeak's morphic.
>>>>>>> 
>>>>>>> Personally I don't like it.  When I build a lego castle and then put it away in a cupboard, it is still in one piece when I take it out later to play. I don't have to write down my castle building instructions and redo them every time.
>>>>>>> 
>>>>>>> It turns mophic into a programatic ui where we construct our morphs from text descriptions. Icky.
>>>>>>> 
>>>>>>> I'm open to suggestions and solutions, meanwhile, back to thinking...
>>>>>>> 
>>>>>>> - Russell
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 18/12/2010, at 8:05 PM, Josh Flowers wrote:
>>>>>>> 
>>>>>>>>  
>>>>>>>> 
>>>>>>>> Unfortunately that didn't work either.
>>>>>>>> 
>>>>>>>> A Morph saved using saveMorphInFile can only reference a limited 
>>>>>>>> set of other object types (strings, methods, morphs, collections of 
>>>>>>>> morphs, and 'concrete' objects) - mine references a ircServer object  
>>>>>>>> Clearly there are a couple different ways I can refactor the code, just 
>>>>>>>> need to spend some time thinking about which one I like....
>>>>>>>> 
>>>>>>>>> That looks promising - I'll try it out this weekend. 
>>>>>>>>> 
>>>>>>>>> Thanks Jan,
>>>>>>>>> 
>>>>>>>>> Josh
>>>>>>>>> 
>>>>>>>>> On Dec 9, 2010, at 2:08 AM, Jan-Paul Bultmann wrote:
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> There is a passage about this in the manual. http://docs.selflanguage.org/morphic.html
>>>>>>>>>> 6.4. Saving a Composite Morph
>>>>>>>>>> The System for filling out morphs seems pretty raw around the edges and really needs to be improved if we want to create usefull apps.
>>>>>>>>>> 
>>>>>>>>>> Hope this helps,
>>>>>>>>>> cheers Jan
>>>>>>>>>> On Dec 9, 2010, at 5:12 AM, Josh Flowers wrote:
>>>>>>>>>> 
>>>>>>>>>>> Does Self support filing out composited morphs? I composited a number of morphs to create an irc chat UI, but I'm having troubles writing it out.
>>>>>>>>>>> 
>>>>>>>>>>> I turned an instance of the morph into a prototype; added it to a module; setup the copy-down slots to Copydown parent: 'rowMorph', Copydown selector: 'copyRemoveAllMorphs'... and I think that's about it.
>>>>>>>>>>> 
>>>>>>>>>>> The module files out and in without errors, but when I try and create an instance of the prototype I get an error message about 'rawMorphs' being missing. I can fix this by manually setting the irc morph's copy-down attributes (they don't seem to copy over as part of the file-in/out process) but then the original submorphs don't exist.
>>>>>>>>>>> 
>>>>>>>>>>> Besides having trouble describing the problem - am I doing something wrong?
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20101227/0403d7f8/attachment.html>

More information about the Self-interest mailing list