Hi,
Wow; I mean I fully support the old "if it's not broke, don't fix it" idea
but I think we may want to try to make a newer release here. And we really, really, need to have on record the process to do new builds.
I echo these sentiments. The reason the SqueakMap server is still running on 3.8 is that it can't actually be ported to later versions of Squeak due to one method exceeding one metric of the current Squeak compiler's limits (too many literals..?) which didn't exist in the older image format. I think the method is SMAccountPackageView>>#edit. There's also the issue of ensuring HttpView2 wouldn't have any issues in the newer Squeak.
I'm trying to work out why SqueakMap appears to dislike my attempts to
create packages.
I've only ever noticed the issue you describe w.r.t. creating Releases, not Packages. Did you investigate my reference from the other email to a potential cause?
I plan to deploy a new SqueakMap server real soon now based on a simple and modern client API, with a website to follow. As this will require updates in the Squeak client image (trunk), we'll still need to keep the old server running to interpret the HttpView2 requests from older Squeak clients.
- Chris
On 2023-10-21, at 11:57 AM, lewis@mail.msen.com wrote:
I do not have access to the map.squeak.org server, but I hunted around
through
some old backup files and located a backup of the old server that I made
during
the great server crash of 2015. I think that's when we moved everything
over to
Rackspace, so this would be a backup that I took from the old server to
help
with the disaster recovery and move to Rackspace.
I unpacked that old backup, and here is what was being used as of about
2015:
lewis@pop-os:/tmp/squeak/home/squeakmap$ ls -lt *.image -rw-r--r-- 1 lewis lewis 17788512 Feb 10 2011 Squeak3.8-6665-sm.image -rw-r--r-- 1 lewis lewis 16106664 Feb 8 2011
Squeak3.8-6665-sm.new.image
-rw-r--r-- 1 lewis lewis 20597864 Sep 28 2010
Squeak3.8-6665-sm.old.image
lewis@pop-os:/tmp/squeak/home/squeakmap$ ckformat
Squeak3.8-6665-sm.image
6502 lewis@pop-os:/tmp/squeak/home/squeakmap$
I cannot say for sure (Chris Muller can probably confirm), but it's quite likely that we are still running the same thing today. It is based on
Squeak 3.8,
image format 6502, and presumably uses the 12 year old code that you
found on
squeaksource.com.
Dave
On 2023-10-21 00:48, Tim Rowledge wrote:
I'm trying to work out why SqueakMap appears to dislike my attempts to
create packages. The issue appears to centre around the generation of the sha1 checksum for the uploaded package loading script.
Digging around revealed the SMServer package on source.squeak.org
which is dated 12 years ago. Which I *think* means we are probably looking at the image being used to provide SM being 4.3 or 4.4 one? The server code appears to rely on a couple of packages that I can't find anywhere, which is what makes me think it probably hasn't been updated since circa 2012.
One aspect of the issue is that just a few weeks ago I was able to add
a new version of the MQTT package.
The proximate cause looks like being
SMAccountPackageView>>#updateServerCache: which seems to be the place where a checksum is calculated for the uploaded file, which is then set for the 'release'. So far as I can see, that means the file that we create when making a new release, ie the script to install all the other bits. Once that is set, and the package info updated in your SqueakMap UI, loading can't succeed since the checksum simply doesn't match what is created by the current image.
One of the problems is that all this SM server code relies upon
HVRootView - which is a class I don't remember but is part of the very out of date HttpView2 package. Which relies upon DynamicBindings, KomServices, KomHttpServer, HTMLBuilder, some of which I can't find in any repository. That could be a fun problem.
Which image version is SM based on? Can I get a copy of the SM server image to try to debug? Can we actually make a new version? Can we, should we, make a new version built on Seaside for future
maintenance?
Why would the checksum calculation differ across the two systems? Why do Lions? tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: PRM: PRint Money
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim To err is human; to really foul things up requires a computer.