<div dir="ltr"><div dir="ltr">Hi Dave,</div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I think I sent you an mail saying that<br>
I had switched to your package version, but apparently I didn't actually<br>
get around to doing that on the server. </blockquote><div><br></div><div>No worries, my main question was about whether you had "changed your mind" about /ss.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I looked at this again a couple<br>
of days ago so that I would respond to Tim's question about VNC and I<br>
realize that although we did merge the code, I never did actually<br>
activate the final version on <a href="http://squeaksource.com" rel="noreferrer" target="_blank">squeaksource.com</a>.<br>
<br>
Unfortunately this turns out to be a good thing, because although the<br>
merged version runs fine, it does not seem to work properly when<br>
restarting a saved image.<br>
<br>
If you would like to take a look at it that would be great. Install<br>
update.sscom-dtl.5.mcm in a clean image and work from there. You<br>
should be able to save the image, restart it, and everything should<br>
still keep working. Then try loading whichever package version you<br>
are using in the <a href="http://source.squeak.org" rel="noreferrer" target="_blank">source.squeak.org</a> image and see if it still works.<br>
There should be no errors or debuggers opening when you restart the<br>
saved image.</blockquote><div><br></div><div><div><div>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).</div><div><br></div><div>Then, the command-line to start the server should simply specify to use SSImagePersistence in the <a href="http://run.st">run.st</a> script, like this:</div><div>____</div><div>Smalltalk run:<br>    [ : webPort | MCHttpRepository clearCredentials.<br>    Smalltalk mitigateIfHeadless.<br>    webPort ifNotNil: [ SSRepository port: webPort asInteger ].<br>    (FileDirectory default fileExists: 'logo.jpg') ifTrue: [ SSFrame makeLogo: (FileDirectory default fullNameFor: 'logo.jpg') ].<br>    SSRepository<br>         storage: SSImagePersistence new ;<br>         startServer: true ]<br></div><div>____</div><div><br></div><div>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 <a href="http://squeaksource.com">squeaksource.com</a> several years ago.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div><div>Regards,</div></div><div>  Chris</div><div><br></div><div><br></div><div><br></div></div></div>