Saving morphs to file

Hi,

how can I save a morph to a file so that I can load it back later ?

The morph is a UMLPackage made with Connectors (this package is very cool).


Thank you

Save project as with classic Etoys project?
But may be it is too wide for what you want to achieve.

Hilaire

Damien Cassou a écrit :
> Hi,
>
> how can I save a morph to a file so that I can load it back later ?
>
> The morph is a UMLPackage made with Connectors (this package is very cool).
>
>
> Thank you
>

hilaire wrote:
> Save project as with classic Etoys project?
> But may be it is too wide for what you want to achieve.

I have never used Etoys. I want to save the diagram to a file so that I
can load it later. I can use the classic deserialisation method if I
have nothing else I think, can't I ?

Damien Cassou a écrit :
> hilaire wrote:
>> Save project as with classic Etoys project?
>> But may be it is too wide for what you want to achieve.
>
> I have never used Etoys. I want to save the diagram to a file so that I
> can load it later. I can use the classic deserialisation method if I
> have nothing else I think, can't I ?

 From the Etoys point of view saving a project (for example from the
orange flap, you can use the Publish button to do so) will save all your
  mrophic instance of the current Morphic project. May be it is too wide
for what you want to do. And yes you can only save a few instance, I
forget which methods I used to do that :(
May be in the wiki there are some info about that.

Hilaire

Damien Cassou puso en su mail :

> Hi,
>
> how can I save a morph to a file so that I can load it back later ?
>
> The morph is a UMLPackage made with Connectors (this package is very cool).
>
>
> Thank you
Select the morph via halo, go to debug menu, select save morph in file.
And if you wish a more "intelligent morph" , what load in almost any Squeak.
In the debug menu select inspect.
In the lower pane write

| fileStream aFileName |
aFileName _ 'SmartTrashCan.morph'.
    fileStream _ FileStream newFileNamed: aFileName.
    fileStream fileOutClass: self class andObject: self.

I send the morph, for see in action drag and drop on any 3.8 or newer and
select via file list and load as morph in 3.7 and earlier.

This things "eats", all same class Morph on your desk (useful for puzzles
and games).

More questions ?

Edgar

Hi,

I'd like to point out that morph saving doesn't always work. I
encountred the problem with a PluggableListMoprh. Serializing such
morph leads to serializing a block context which needs it's orginal
method. How to workaround this?

Noury
Le 16 juil. 06, à 11:34, Lic. Edgar J. De Cleene a écrit :
------------------------------------------------------------------
Dr. Noury Bouraqadi - Enseignant/Chercheur
ARMINES - Ecole des Mines de Douai - Dept. G.I.P
http://csl.ensm-douai.fr/noury

European Smalltalk Users Group Board
http://www.esug.org

Squeak: a Free Smalltalk
http://www.squeak.org
------------------------------------------------------------------

Noury Bouraqadi puso en su mail :

> Hi,
>
> I'd like to point out that morph saving doesn't always work. I
> encountred the problem with a PluggableListMoprh. Serializing such
> morph leads to serializing a block context which needs it's orginal
> method. How to workaround this?

You are having some similar to pict ?

That's is why the actual way of exporting always use ImageSegments.
I have the hiphotesis what something is wrong and is the cause of not
working on 100% of cases.
Same as exporting projects in very loaded images.
Always you end with references to things what IMHO never was used in the
original project.

As I very busy with SqueakLight and trying to discover how load any Squeak
produced code from Squeak 1.3 era to new 3.9b images into it, hope soon
could find a unwise dirty solution and send to list.

Edgar

Le 17 juil. 06, à 13:37, Lic. Edgar J. De Cleene a écrit :
Exactly!
That would be cool. Good luck.

Noury
------------------------------------------------------------------
Dr. Noury Bouraqadi - Enseignant/Chercheur
ARMINES - Ecole des Mines de Douai - Dept. G.I.P
http://csl.ensm-douai.fr/noury

European Smalltalk Users Group Board
http://www.esug.org

Squeak: a Free Smalltalk
http://www.squeak.org
------------------------------------------------------------------

Hi Noury, if you are in 3.7 or 3.8 you can use Magma to transfer a
project containing Connected Morphs to another image.  Blocks and
CompiledMethods are no problem.

After loading the MagmaServerLoader package from the "MagmaTester"
project on SqueakSource, go outside the project you want to save, then
type:

  MagmaRepositoryController
    create: 'c:\temp\myProject'
    root: (Project named: 'the name of project you want to save'

Then, in target image:

  session := MagmaSession openLocal: 'c:\temp\myProject'.
  "Materialization alone will add it to AllProjects"
  session root inspect.
  session disconnectAndClose.

You can then go into the project.

Good luck,
  Chris


--- Noury Bouraqadi <[hidden email]> wrote:

Chris Muller wrote:
> Hi Noury, if you are in 3.7 or 3.8 you can use Magma to transfer a
> project containing Connected Morphs to another image.  Blocks and
> CompiledMethods are no problem.

Out of curiosity, how does Magma deal with a situation where you
serialize a block referring to an iVar and the shape of that class
changes? Can you detect it?

Cheers,
   - Andreas

Hmm, well your good question sent me on a big chase that led me to
enlightenment, thank you.  The short answer is "no".  The long answer
follows.

To my surprise and disappointment, it appears support for Blocks is not
as robust as I had thought.  It appears that blocks referencing inst
vars or "self" cannot be valued after rematerializing.  Blocks that
refer merely to their own arguments or globals or class-variables _can_
be valued after rematerializing.

This surprised me because the serialization test cases serialize four
different block fixtures:

blockSamples
        ^ {
        "self reference"
        [ self class name = #MaFixtureFactory ifFalse: [ self error: 'Block
home not correct' ] ].
        "global reference"
        [ : each | Transcript cr; show: each printString ].
        "local access only"
        [ : a : b | a name > b name ].
        "global and inst var reference"
        [ Transcript cr; show: allNonCollectionSamples size ] }

and then, upon rematerialization, performs the following comparison:

  maEquivalentForSerializationTest: aBlockContext
        aBlockContext class = self class ifFalse: [ ^ false ].
        ^ self method = aBlockContext method
        and: [ self numArgs = aBlockContext numArgs
        and: [ self startpc = aBlockContext startpc ] ]

and while all four blocks pass this test, this is apparently not
sufficient for valuing the ones that reference self or the inst-var.

I discovered this by trying it manually, created class TestObject with
inst var 'var2'.  I implemented:

  block2
        ^ [ Transcript cr; show: var2 ]

and then tested it:

  MaObjectSerializer testMaterialize: (TestObject new var2: 'hello
world'; block2)

This serializes the block, then instantiates a brand new one from
scratch from the serialized bytes and returns it.

It looks real close in the fully-expanded explorer, but "self value"
printed 26258680 in the Transcript instead of "hello world".  What
the..?  Debugging into it shows:

  DoIt
        ^ [Transcript cr; show: unknown0]

So the inst var did not get "hooked up" or something.

I've never had a need to store complex blocks, since they exist in the
context of a method, and methods are typically stored in the
code-maangement system (i.e., change sets or Monticello) then it seems
storing Blocks -> MethodContexts -> CompiledMethods could lead to
serious confusion anyway.  e.g., you could make a change to the block
in the code and but persisted block would still be performing the old
code..  It would seem better to use an alternative like MessageSends
that logically calls the most up-to-date methods.

Still, this was a surprise because I did put some work into saving and
restoring BlockContexts, MethodContexts and CompiledMethods.  Each is
serialized into a "MaBlockContextStorage", "MaMethodContextStorage" and
"MaCompiledMethodStorage", respectively.

BlockContextStorage captures nargs, startpc, and home (a
MethodContextStorage).  MethodContextStorage captures the 'method' (a
CompiledMethodStorage).  CompiledMethodStorage captures 'header
literals startPc endPc byteCodes sourcePointer className'.  Restoration
works backward, first the CompiledMethod:

  asCompiledMethod
        | answer |
        answer _
                CompiledMethod
                        newMethod: endPc - startPc + 1 + 4
                        header: header.
        literals withIndexDo:
                [ : each : index |
                answer
                        literalAt: index
                        put: each ].
" answer setSourcePointer: sourcePointer."  "<-- don't restore it, it
could be wrong."
"In fact..."
sourcePointer > 0 ifTrue: [ answer zapSourcePointer ].
        answer
                replaceFrom: startPc
                to: endPc
                with: byteCodes
                startingAt: 1.
        self restoreLiterals: answer.
        ^ answer

then the MethodContext:

  asMethodContext
        | cm |
        ^ (MethodContext newForMethod: (cm _ method asCompiledMethod))
                privRefreshWith: cm ;
                yourself

and, finally, the BlockContext:

  asBlockContext
        | methodContext |
        methodContext _ home asMethodContext.
        ^ (BlockContext newForMethod: methodContext method)
                home: methodContext
                startpc: startpc
                nargs: nargs

Whew!  Sorry for this deluge, but if anyone has any suggestions for
improving this I would be grateful.

 - Chris



--- Andreas Raab <[hidden email]> wrote:

Chris Muller wrote:
> Hmm, well your good question sent me on a big chase that led me to
> enlightenment, thank you.  The short answer is "no".  The long answer
> follows.

I'm actually slightly relieved because it means I didn't miss anything
stupidly simple ;-) I spent a *lot* of brainpower on this problem in
particular and I found it to be a really hard one.

> To my surprise and disappointment, it appears support for Blocks is not
> as robust as I had thought.  It appears that blocks referencing inst
> vars or "self" cannot be valued after rematerializing.  Blocks that
> refer merely to their own arguments or globals or class-variables _can_
> be valued after rematerializing.

Right. This is the classic situation because args are bound as offsets
to the home context (which is usually serialized along with the block)
and class vars are bound to actual objects (part of the literal frame of
the compiled method).

> It looks real close in the fully-expanded explorer, but "self value"
> printed 26258680 in the Transcript instead of "hello world".  What
> the..?  Debugging into it shows:
>
>   DoIt
> ^ [Transcript cr; show: unknown0]
>
> So the inst var did not get "hooked up" or something.

I think you're just getting lucky. My example (see comment in
ClassDescription>>updateInstancesFrom:) which illustrates the same
problem crashes fairly reliably.

> I've never had a need to store complex blocks, since they exist in the
> context of a method, and methods are typically stored in the
> code-maangement system (i.e., change sets or Monticello) then it seems
> storing Blocks -> MethodContexts -> CompiledMethods could lead to
> serious confusion anyway.  e.g., you could make a change to the block
> in the code and but persisted block would still be performing the old
> code..  It would seem better to use an alternative like MessageSends
> that logically calls the most up-to-date methods.

Yes. Alternatively, if we had a "literal object/class" syntax this would
be very simple, too.

> Whew!  Sorry for this deluge, but if anyone has any suggestions for
> improving this I would be grateful.

Heh. I know *exactly* how you are feeling. I think the cleanest solution
would be if Magma would simply detect any blocks that try to access
iVars and raise an error if you try to store one. If this is done early
on, people can compensate by using accessor messages (which is usually
simple). But this may not be possible if there is other people's code
involved.

Alternatively, you could store the iVar shape (at the very least the
minimum number of iVars so that you don't crash the VM when executing
the block) and raise an error if you read in a block which attempts to
access such iVars.

Cheers,
   - Andreas

On 18.07.2006, at 07:33, Andreas Raab wrote:

> Chris Muller wrote:
>> Hmm, well your good question sent me on a big chase that led me to
>> enlightenment, thank you.  The short answer is "no".  The long answer
>> follows.
>
> I'm actually slightly relieved because it means I didn't miss  
> anything stupidly simple ;-) I spent a *lot* of brainpower on this  
> problem in particular and I found it to be a really hard one.
>

The solution would be, of course, to not use offsets for instvar  
access in the bytecode... the binding name->offset happens far too  
early.

For everything but interpretation, bytecode sucks. Thus we should  
have a better representation for these kind of things and use bytecode
*only* for execution (if at all). Not as a meta model for methods,  
not for making code persistent and especially not for general code  
motion
in distributed systems. There are much better representations for  
that, see i.e. the research of Michael Franz (e.g. Slim Binaries an  
later SafeTSA).

      Marcus
 
 

On Tue, 18 Jul 2006 10:07:40 +0200, Marcus Denker wrote:
...
> For everything but interpretation, bytecode sucks. Thus we should have a  
> better representation for these kind of things and use bytecode
> *only* for execution (if at all).
+1
> Not as a meta model for methods,
+1
> not for making code persistent
+1
> and especially not for general code motion
> in distributed systems.
+1
> There are much better representations for that, see i.e. the research of  
> Michael Franz (e.g. Slim Binaries an later SafeTSA).

Thanks for the pointer.

/Klaus

>
>       Marcus
>

Marcus Denker wrote:
Use trees :-) Trees are so cool for that kind of things. And they are
already used for refactoring or pretty printing.

On 18.07.2006, at 06:11, Chris Muller wrote:


What I personally don't like is that blocks in Squeak mix the static  
with the dynamic.

For methods, we have the static (dead) description of  a method:  
CompiledMethod.
When it is run, a MethodContext is allocated. For blocks, we only  
have the
dynamic structure: BlockContext, even for the static structure of "a  
Block".

This is much nicer done in Anthony's design of blocks for the  
ClosureCompiler.

      Marcus

On 18.07.2006, at 10:50, Marcus Denker wrote:

As an example, have a look at a simple method accessing an iVar:

TT>>test
        ^[i].

Then we execute:

TT new test explore

For the old compiler, this gets us a horribly complicated structure  
referencing
the Context of both the Block and the Method:

[] in TT>>test {[i]}
root: [] in TT>>test {[i]}
        sender: nil
        pc: 18
        stackp: 0
        nargs: 0
        startpc: 18
        home: TT>>test
                sender: nil
                pc: nil
                stackp: 0
                method: a CompiledMethod (2302)
                receiverMap: nil
                receiver: a TT


With the NewCompiler, the structure of the Closure is completely static,
it just references a method that encodes the code of the block and the
environment for the iVar access:

a BlockClosure (1599)
root: a BlockClosure (1599)
        method: a CompiledMethod (1605)
        environment: a TT
                i: nil

even with an outer temp reference, the picture does not get more  
complicated:

test
        | t |
        t := 5.
        ^[t].

a BlockClosure (2739)
root: a BlockClosure (2739)
        method: a CompiledMethod (1814)
        environment: a ClosureEnvironment
                1: 5

The code of the method #test is compiled to reference the temp as the  
ivar in the Environment...
which is of course slowing down temp access for these kinds of shared  
temps.

     Marcus

Marcus Denker wrote:
>> I'm actually slightly relieved because it means I didn't miss anything
>> stupidly simple ;-) I spent a *lot* of brainpower on this problem in
>> particular and I found it to be a really hard one.
>
> The solution would be, of course, to not use offsets for instvar access
> in the bytecode... the binding name->offset happens far too early.

So what are practical alternatives? And how do they compare to what we
have today in terms of compactness, speed, and interpretation overhead?

> For everything but interpretation, bytecode sucks.

Perhaps so (in a serious discussion I'd have to disagree; I think there
are various good reasons for bytecodes). But isn't interpretation what
most of us care about most of the time?

Cheers,
   - Andreas

Marcus Denker wrote:
But temps aren't the problem (never have been except from the issue of
sharing those temps in the frame of the outer method). It's iVars which
are the problem and unless I'm completely mistaken, there is no solution
to that problem in CC either (if there is, please correct me).

Cheers,
   - Andreas

On 18.07.2006, at 11:27, Andreas Raab wrote:
No, this was not meant as a solution to the iVar problem. Just a  
general example that it's nice to distinguish between static and  
dynamic for blocks.

And, of course, it solves the problem  wie have with temps (aka true  
Closures) ;-)

     Marcus