Oh, and I should have mentioned this - trying to load my MQTT package has the same problem now; mismatched checksums.
Have we changed anything in the RWBinaryOrTextStream related hierarchy recently that might impact the calculation of sha1 checksums? Here's any interesting factoid - try installing an *old* version of MQTT (say, Version24) and the checksums match.
On 2023-10-22, at 6:18 PM, Tim Rowledge tim@rowledge.org wrote:
Weird.
So I removed the package completely. Created another. Added a release. It saved the file. I can download that file from the SM website or via the link in the SM client and it is fine.
But still non-matching checksums. Just... nuts!
On 2023-10-22, at 5:09 PM, Chris Muller ma.chris.m@gmail.com wrote:
Interesting! My browser gave me a warning when I tried to download that file, that it "can't be downloaded safely". I was able to click past that and download it, but I don't get that warning on other files in SqueakMap.
sha1sum reports 4b8ef0bf50fbb44d2a1da1a3e09e2c173ec95ce7 on your file, which is different than what the Release entry shows.
I would recommend going into your account at map.squeak.org and then going into Uploaded Files, and deleting that file. Then you'll probably be able to reupload it with that exact same name.
Fingers crossed.
- Chris
On Sun, Oct 22, 2023 at 5:13 PM Tim Rowledge tim@rowledge.org wrote:
Technically it would be releases I'm having problems with. The checksum that gets incorporated by the server into the package info which then gets loaded into the SM client is not the same as that which gets calculated by the loading check code.
Did you investigate my reference from the other email to a potential cause?
Yeah, removed everything so it all gets fetched fresh etc.
By everything, do you mean your entire "sm" directory? Also, after that, purge your SMSqueakMap default to force it to re-retrieve from server.
Yup, dump sm, clear out the map. The file contents that it tries to evaluate to load are
'error occured retrieving http://map.squeak.org/accountbyid/4340a66e-2296-48b7-9aa8-5305d303752f/files...: Server map.squeak.org is not responding'
This is a bit strange since manually retrieving the contents works perfectly to get the install file I wrote.
Putting a break in SMFileCache>>#getStream: lets me see that the retrieved content at that point is correct but the checksum ivar for the SMPackageRelease does not match that calculated locally for the file content. Sometihng in the handling of that error created the erroneous message above.
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.
A quick look at the requests sent to save releases from the SMClient doesn't look like it would be much of a problem to handle in a seaside server, so just maybe we could avoid needing doubled up services.
Right now, we're certain the old server supports old Squeak clients. Switching such a complex model to Seaside would be a monumental project, requiring testing in all older Squeak clients. My rewrite entails introducing a modern, text-based API, which Seaside doesn't support. I've been working on it for a while, and plan to deploy it soon.
Sounds cool. Looking forward to seeing it.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "My name is Inigo Montoya. You killed my parent process. Prepare to vi!"
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: FCE: Fill Core with Epoxy
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't diddle code to make it faster; find a better algorithm.