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
On Sat, Sep 27, 2014 at 7:20 PM, David T. Lewis lewis@mail.msen.com 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
On 9/28/14, Herbert König herbertkoenig@gmx.net 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
On Tue, Nov 24, 2015 at 1:01 PM, H. Hirzel hannes.hirzel@gmail.com 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
Yay
Best, Karl
On Sat, Nov 28, 2015 at 7:00 AM, Colin Putney colin@wiresong.com wrote:
On Tue, Nov 24, 2015 at 1:01 PM, H. Hirzel hannes.hirzel@gmail.com 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
On Fri, Nov 27, 2015 at 10:00:44PM -0800, Colin Putney wrote:
On Tue, Nov 24, 2015 at 1:01 PM, H. Hirzel hannes.hirzel@gmail.com 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
squeak-dev@lists.squeakfoundation.org
-
Colin Putney -
David T. Lewis -
H. Hirzel -
Herbert König -
karl ramberg