Smalltalk › Squeak › Squeak - Dev

It's not yet clear how serialization should work in the presence of environments

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

David T. Lewis

It's not yet clear how serialization should work in the presence of environments

Currently we have:

Binding>>objectForDataStream: refStream
"It's not yet clear how serialization should work in the presence of environments"

self shouldBeImplemented.

This prevents us from being able to save projects to local disk
in Squeak trunk. See Mantis entry at:

http://bugs.squeak.org/view.php?id=7814

Any thoughts as to how this should be implemented?

Taking the method comment literally, I would expect that serialization in
the presence of environments should work identically to serialization in
the absence of environments, at least as a default behavior. I suspect that
is not hard to make this happen, but I don't know how to do it.

Dave

Colin Putney-3

Re: It's not yet clear how serialization should work in the presence of environments

On Sat, Sep 27, 2014 at 7:20 PM, David T. Lewis <[hidden email]> wrote:

Currently we have:

Binding>>objectForDataStream: refStream
"It's not yet clear how serialization should work in the presence of environments"

self shouldBeImplemented.

This prevents us from being able to save projects to local disk
in Squeak trunk. See Mantis entry at:

http://bugs.squeak.org/view.php?id=7814

Any thoughts as to how this should be implemented?

Taking the method comment literally, I would expect that serialization in
the presence of environments should work identically to serialization in
the absence of environments, at least as a default behavior. I suspect that
is not hard to make this happen, but I don't know how to do it.

Hi Dave,

Sorry about that. I really shouldn't have left that method unimplemented.

The easy fix for the default case is to use the same implementation as Association>>objectForDataStream:. This will make save and reloading of object work in the case where there's only one environment in the image.

The case of multiple environments boils down to this: saving objects to disk would have to be done from the perspective of a given environment, and loading would have to be done from that of an equivalent environment. Association's implementation special-cases instances that represent global variables so that they get looked up in "Smalltalk globals" when the objects are reloaded from disk. That should be replaced with "Environment current" so that the lookup happens in the environment we're loading against, rather than the environment where Binding is compiled.

Looking further up the layers of abstraction, each Project should probably have its own environment, which would be used for compiling custom code for that project, and serializing the project to disk.

In the meantime, though, let's fix the simple case. :-)

Colin

Herbert König

Re: It's not yet clear how serialization should work in the presence of environments

Am 28.09.2014 um 05:01 schrieb Colin Putney:

In the meantime, though, let's fix the simple case. :-)

Colin

Thanks a lot, Colin

Hannes Hirzel

Re: It's not yet clear how serialization should work in the presence of environments

On 9/28/14, Herbert König <[hidden email]> wrote:
> Am 28.09.2014 um 05:01 schrieb Colin Putney:
>>
>>
>> In the meantime, though, let's fix the simple case. :-)
>>
>> Colin
>>
> Thanks a lot, Colin
>

This simple case where there is only one environment is described in
http://bugs.squeak.org/view.php?id=7814

And currently probably nearly 100% of the users still have only one
environment.

What would it mean to fix this case?

--Hannes

Colin Putney-3

Re: It's not yet clear how serialization should work in the presence of environments

On Tue, Nov 24, 2015 at 1:01 PM, H. Hirzel <[hidden email]> wrote:

This simple case where there is only one environment is described in
http://bugs.squeak.org/view.php?id=7814

And currently probably nearly 100% of the users still have only one
environment.

What would it mean to fix this case?

Ok, I think I've got it sorted out. I've made the following changes in trunk:

- Bindings implement #objectForDataStream: by always creating a DiskProxy

- Association should never create a DiskProxy, so no longer implement #objectForDataStream:

- DiskProxy now uses the current environment in #comeUpFullyOnReload:, rather than Smalltalk

That should take care of the single-environment case. It should also work for multi-environment images, if we create UI for setting the "current" environment, or actually make use of the "environment" instance variable in Project.

One other change was required to get loading a project to work, but this has nothing to do with environments. In the Inbox, I've uploaded a version of Morphic that implements PasteUpMorph>>referencePool, which creates a new reference pool... whatever that is. Could someone who knows more about Projects review that, please?

With these four changes, it's possible to save and load projects in a Squeak 4.6 image. It doesn't work in a trunk image, however. The Spur VM crashes when saving a project. I've reported that on the VM list. It also fails to load an image segment - looks like the primitive for that isn't quite finished in Spur.

Though I've tested these changes in a 4.6 image, I committed them to trunk only. What's the correct way to get them into the 4.6 update stream as well?

Colin

Karl Ramberg

Re: It's not yet clear how serialization should work in the presence of environments

Yay

Best,

Karl

On Sat, Nov 28, 2015 at 7:00 AM, Colin Putney <[hidden email]> wrote:

On Tue, Nov 24, 2015 at 1:01 PM, H. Hirzel <[hidden email]> wrote:

This simple case where there is only one environment is described in
http://bugs.squeak.org/view.php?id=7814

And currently probably nearly 100% of the users still have only one
environment.

What would it mean to fix this case?

Ok, I think I've got it sorted out. I've made the following changes in trunk:

- Bindings implement #objectForDataStream: by always creating a DiskProxy
- Association should never create a DiskProxy, so no longer implement #objectForDataStream:
- DiskProxy now uses the current environment in #comeUpFullyOnReload:, rather than Smalltalk

That should take care of the single-environment case. It should also work for multi-environment images, if we create UI for setting the "current" environment, or actually make use of the "environment" instance variable in Project.

One other change was required to get loading a project to work, but this has nothing to do with environments. In the Inbox, I've uploaded a version of Morphic that implements PasteUpMorph>>referencePool, which creates a new reference pool... whatever that is. Could someone who knows more about Projects review that, please?

With these four changes, it's possible to save and load projects in a Squeak 4.6 image. It doesn't work in a trunk image, however. The Spur VM crashes when saving a project. I've reported that on the VM list. It also fails to load an image segment - looks like the primitive for that isn't quite finished in Spur.

Though I've tested these changes in a 4.6 image, I committed them to trunk only. What's the correct way to get them into the 4.6 update stream as well?

Colin

David T. Lewis

Re: It's not yet clear how serialization should work in the presence of environments

In reply to this post by Colin Putney-3

On Fri, Nov 27, 2015 at 10:00:44PM -0800, Colin Putney wrote:

> On Tue, Nov 24, 2015 at 1:01 PM, H. Hirzel <[hidden email]> wrote:
>
>
> > This simple case where there is only one environment is described in
> > http://bugs.squeak.org/view.php?id=7814
> >
> > And currently probably nearly 100% of the users still have only one
> > environment.
> >
> > What would it mean to fix this case?
> >
>
> Ok, I think I've got it sorted out. I've made the following changes in
> trunk:

Colin,

Thank you for doing this!

>
> With these four changes, it's possible to save and load projects in a
> Squeak 4.6 image. It doesn't work in a trunk image, however. The Spur VM
> crashes when saving a project. I've reported that on the VM list. It also
> fails to load an image segment - looks like the primitive for that isn't
> quite finished in Spur.
>

Your message to vm-dev was initially blocked due to message size, but I
re-sent it to the list and put a copy of your crash-image.zip here:

http://squeakvm.org/~lewis/tmp/crash-image.zip

It's a holiday week in the US so you may not get an immediate response on
the crash issue.

The main thing is that you have it working in 4.6 (yay!) so we now have a
working baseline for image segments with Environments, and whatever issues
are appearing in 5.0/trunk can be much more easily understood and addressed.

> Though I've tested these changes in a 4.6 image, I committed them to trunk
> only. What's the correct way to get them into the 4.6 update stream as well?
>

I am not certain, but I expect we will want to merge them back into the
squeak46 repository, and possibly also consider doing a maintenance release
to the 4.6 image. Having an up to date image with working image segments
seems like a pretty big deal to me :-)

Dave