Hi Dave,

 I think I sent you an mail saying that
> I had switched to your package version, but apparently I didn't actually
> get around to doing that on the server.


No worries, my main question was about whether you had "changed your mind"
about /ss.


> I looked at this again a couple
> of days ago so that I would respond to Tim's question about VNC and I
> realize that although we did merge the code, I never did actually
> activate the final version on squeaksource.com.
>
> Unfortunately this turns out to be a good thing, because although the
> merged version runs fine, it does not seem to work properly when
> restarting a saved image.
>
> If you would like to take a look at it that would be great. Install
> update.sscom-dtl.5.mcm in a clean image and work from there. You
> should be able to save the image, restart it, and everything should
> still keep working. Then try loading whichever package version you
> are using in the source.squeak.org image and see if it still works.
> There should be no errors or debuggers opening when you restart the
> saved image.


The /ss code relies 100% on its code versioned in MC packages, and has zero
dependence on image state.  This was the #1 primary design goal in the 2011
upgrade.  Loading the /ss code on top of the sscom-dtl code was never
tested or expected to work.  Instead, the initial image should be saved
ONLY with the Personal SqueakSource code loaded, and NO servers started
(RFB or web).

Then, the command-line to start the server should simply specify to use
SSImagePersistence in the run.st script, like this:
____
Smalltalk run:
    [ : webPort | MCHttpRepository clearCredentials.
    Smalltalk mitigateIfHeadless.
    webPort ifNotNil: [ SSRepository port: webPort asInteger ].
    (FileDirectory default fileExists: 'logo.jpg') ifTrue: [ SSFrame
makeLogo: (FileDirectory default fullNameFor: 'logo.jpg') ].
    SSRepository
         storage: SSImagePersistence new ;
         startServer: true ]
____

SSImagePersistence uses a Promise and ensures the image is saved with the
server and domain and safely restartable.  I tested with a full copy of
squeaksource.com several years ago.

For extra safety, we might consider using a SSCompositeStorage composed of
an SSImagePersistence and a SSFilesystem, so we have data.obj files as
backups in case the image saves corrupted.

I'm happy to support getting this up and running as specified above, but I
don't want to experiment with mixing the /ss code with the sscom-dtl code.
I'd rather see the sscom-dtl code integrated into the /ss code, and the
community coalesce on a single bespoke server codebase suitable for both
instances.

Regards,
  Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20221205/94dc6588/attachment.html>