<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">True,<div>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.</div><div>Maybe the way to go is some sort of micro snapshot that can be imported into a real one?</div><div><br></div><div>Cheers Jan<br><div><div>On Dec 23, 2010, at 1:47 PM, Thorsten Dittmar wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div style="background-color: #fff;">
<span style="display:none"> </span>
<div id="ygrp-text"><p>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?</p><div><br></div><div>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. </div><div><br></div><div>we should clearly separate two approaches:</div><div><br></div><div>1. to construct an object via script.. this is what the transporter is doing</div><div>2. to move an object from one world to another. this is more like distributed computing then
like filing in and out. </div><div><br></div><div>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</div><div><br></div><div>best regards </div><div><br></div><div>thorsten</div><div><br><div><div>On Dec 23, 2010, at 1:11 PM, Jan-Paul Bultmann wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div style="background-color: #fff;">
<span> </span>
<div id="ygrp-text"><div><br class="webkit-block-placeholder"></div><div>Hey,</div><div>I totally agree that one should simply save a morph as is without any textual additions.</div><div>What if we didn't care about the state the morph currently has. We simply dryfreeze it and revive it later.</div><div>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.</div><div>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.).</div><div>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
:)).</div><div><br></div><div>Thoughts?</div><div><br></div><div>cheers Jan</div><div><div>On Dec 23, 2010, at 3:33 AM, Russell Allen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div style="background-color: rgb(255, 255, 255);">
<span> </span>
<div id="ygrp-text"><div><br class="webkit-block-placeholder"></div><div>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:</div><div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>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!</div><div><br></div><div>Now unless I am doing something wrong, this seems a bit of an incompatibility between the transporter, copy down slots, and morphic.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>It turns mophic into a programatic ui where we construct our morphs from text descriptions. Icky.</div><div><br></div><div>I'm open to suggestions and solutions, meanwhile, back to thinking...</div><div><br></div><div>- Russell</div><div><br></div><div><br></div><div><br></div><div><br></div><br><div><div>On 18/12/2010, at 8:05 PM, Josh Flowers wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div style="background-color: #fff;">
<span> </span>
<div id="ygrp-text"><div><br class="webkit-block-placeholder"></div><div>Unfortunately that didn't work either.</div><div><br></div><div>A Morph saved using saveMorphInFile can only reference a limited </div><div>set of other object types (strings, methods, morphs, collections of </div><div>morphs, and 'concrete' objects) - mine references a ircServer object. </div><div>Clearly there are a couple different ways I can refactor the code, just </div><div>need to spend some time thinking about which one I like....</div><div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate;font-family: Helvetica;font-style: normal;font-variant: normal;font-weight: normal;letter-spacing: normal;text-indent: 0px;text-transform: none;white-space: normal;word-spacing: 0px;"><div>That looks promising - I'll try it out this weekend. <br><div><br></div><div>Thanks
Jan,</div><div><br></div><div>Josh</div><div><br></div><div><div>On Dec 9, 2010, at 2:08 AM, Jan-Paul Bultmann wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate;font-family: Helvetica;font-style: normal;font-variant: normal;font-weight: normal;letter-spacing: normal;text-indent: 0px;text-transform: none;white-space: normal;word-spacing: 0px;"><div><br><br><div>There is a passage about this in the manual. <a href="http://docs.selflanguage.org/morphic.html">http://docs.selflanguage.org/morphic.html</a></div><div>6.4. Saving a Composite Morph</div><div>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.</div><div><br></div>Hope this helps,<div>cheers Jan<br><div><div>On Dec 9, 2010, at 5:12 AM, Josh Flowers wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="background-color:
rgb(255, 255, 255);"><div id="ygrp-text"><p>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.<br><br>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.<br><br>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.<br><br>Besides having trouble describing the problem - am I doing something wrong?<br></p></div></div></blockquote></div><br></div><br><br><div width="1" style="color: white;"></div></div></span></blockquote></div><br><br><br><div width="1" style="color: white;"></div></div></span></blockquote></div><br><div><br class="webkit-block-placeholder"></div>
</div>
</div>
<!-- end group email -->
</blockquote></div><br><div><br class="webkit-block-placeholder"></div>
</div>
</div>
<!-- end group email -->
</blockquote></div><br><div><br class="webkit-block-placeholder"></div>
</div>
</div>
<!-- end group email -->
</blockquote></div><br></div><div><br class="webkit-block-placeholder"></div>
</div>
</div>
<!-- end group email -->
</blockquote></div><br></div></body></html>