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
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
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.
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.
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.
Gosh, 3.8 is even further back than the 4.4 I was anticipating!
On 2023-10-22, at 1:01 PM, Chris Muller asqueaker@gmail.com wrote:
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.
That doesn't look too hard to split up if needed.
There's also the issue of ensuring HttpView2 wouldn't have any issues in the newer Squeak.
Is there any special reason to use HttpView2 instead of Seaside? The latter is, admittedly very quietly, maintained and will run in post-3.8 images.
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.
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.
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.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One of the early failures of electroshock therapy.
On Sun, Oct 22, 2023 at 3:21 PM Tim Rowledge tim@rowledge.org wrote:
Gosh, 3.8 is even further back than the 4.4 I was anticipating!
On 2023-10-22, at 1:01 PM, Chris Muller asqueaker@gmail.com wrote:
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.
That doesn't look too hard to split up if needed.
There's also the issue of ensuring HttpView2 wouldn't have any issues in
the newer Squeak.
Is there any special reason to use HttpView2 instead of Seaside? The latter is, admittedly very quietly, maintained and will run in post-3.8 images.
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.
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.
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.
- Chris
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!"
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!"
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
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.
The server image is pretty easy to run locally. You could put a halt in the error message and the full stack of how it's getting there will be presented in all its clarity. Do you have it? Requires 32-bit interpreter VM.
On Sun, Oct 22, 2023 at 8:27 PM Tim Rowledge tim@rowledge.org wrote:
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.
Either 32-bit or 64-bit interpreter VM is fine. Sorry if I am being pedantic but it may be important for Tim, who would probably be compiling the VM on his 64-bit Raspberry Pi. There is no need for 32-bit libraries, the VM will be compiled as a 64-bit executable that interprets the 32-bit image. See https://wiki.squeak.org/squeak/6354
Dave
On 2023-10-24 01:38, Chris Muller wrote:
The server image is pretty easy to run locally. You could put a halt in the error message and the full stack of how it's getting there will be presented in all its clarity. Do you have it? Requires 32-bit interpreter VM.
On Sun, Oct 22, 2023 at 8:27 PM Tim Rowledge tim@rowledge.org wrote:
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.
Latest info on this continuing problem - Bruce suggested comparing the results of 'sha1sum' on the relevant file(s). I've now tested on x64 ubuntu arm64 pi armv7 pi (ie 32bit system) mac with images back to 4.6 and the results of SecureHashAlgorithm new hashStream: (FileStream fileNamed: 'foo' for various files) is consistently not the same as sha1sum for the same file. I also tried without the primitive support just in case.
As an example for the attached file Squeak consistently reports 1040456478707692947869256263227370279496083563594 whereas sha1sum says b63fae9e7e4ca1e21390449752355ff5d3b7e44a
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCVP: Destroy another Computer Via Phone-link
Excuse the earthquake tremors you are currently feeling. That's me banging on my head as I realise the Squeak result needs to be converted to hex to compare directly with the sha1sum value.
On 2023-11-01, at 3:31 PM, Tim Rowledge tim@rowledge.org wrote:
Latest info on this continuing problem - Bruce suggested comparing the results of 'sha1sum' on the relevant file(s). I've now tested on x64 ubuntu arm64 pi armv7 pi (ie 32bit system) mac with images back to 4.6 and the results of SecureHashAlgorithm new hashStream: (FileStream fileNamed: 'foo' for various files) is consistently not the same as sha1sum for the same file. I also tried without the primitive support just in case.
As an example for the attached file Squeak consistently reports 1040456478707692947869256263227370279496083563594 whereas sha1sum says b63fae9e7e4ca1e21390449752355ff5d3b7e44a
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCVP: Destroy another Computer Via Phone-link
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- QUE SERA SERF - Life is feudal
On 2023-11-01, at 3:39 PM, Tim Rowledge tim@rowledge.org wrote:
Excuse the earthquake tremors you are currently feeling. That's me banging on my head as I realise the Squeak result needs to be converted to hex to compare directly with the sha1sum value.
This does not, however solve anything wrt the SqueakMap problem. Sigh.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IOP: Insult OPerator
Assuming that we are looking for some difference in the checksum calculations on the SqueakMap server versus the same calculation on your much newer (trunk) client image, I tried doing this on a trunk image, and comparing the result to the same evaluation on a Squeak 3.8 image:
fs := FileStream fileNamed: '/home/lewis/squeak/Squeak5.3/Squeak5.3-19431-64bit.image.gz'. fs binary. result := SecureHashAlgorithm new hashStream: fs. fs close. result.
The results are the same for Squeak 3.8 and latest Squeak trunk (except that the old 3.8 image has a hard time printing the LargePositiveInteger result, but that is not relevant here).
This does not tell us what is going wrong in SqueakMap, but it does suggest that the issue is not anything directly related to the checksum calculation.
I guess this still does leave open the possibility of some difference in LargePositiveInteger arithmetic in the VM. It seems unlikely, but maybe we should check to be sure.
Tim, can you try running a checksum in Squeak on some known file from squeak.org downloads, and I'll try running it on my PC and see if we get the same LPI result?
Dave
On 2023-11-01 22:31, Tim Rowledge wrote:
Latest info on this continuing problem - Bruce suggested comparing the results of 'sha1sum' on the relevant file(s). I've now tested on x64 ubuntu arm64 pi armv7 pi (ie 32bit system) mac with images back to 4.6 and the results of SecureHashAlgorithm new hashStream: (FileStream fileNamed: 'foo' for various files) is consistently not the same as sha1sum for the same file. I also tried without the primitive support just in case.
As an example for the attached file Squeak consistently reports 1040456478707692947869256263227370279496083563594 whereas sha1sum says b63fae9e7e4ca1e21390449752355ff5d3b7e44a
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCVP: Destroy another Computer Via Phone-link
Hmm, try https://files.squeak.org/Experiments/updates/9408ShoutCore-ar.8.cs
I get the same value from sha1sum & squeak
(SecureHashAlgorithm new hashStream: (FileStream fileNamed: '/home/tim/DizietFS/Downloads/9408ShoutCore-ar.8.cs') ) hex
'16r2D6533F0A936CA1AAB61F220C5A48DA3A5ABFEB7'
I *think* a relevant part of the SM server code is SMFileUploadActiob>go, where it saves the file. After that... no idea. Somewhere it involves SMPackageRelease>>#refreshInCache which is where the sha1sum for the package gets set.
On 2023-11-01, at 5:16 PM, lewis@mail.msen.com wrote:
Assuming that we are looking for some difference in the checksum calculations on the SqueakMap server versus the same calculation on your much newer (trunk) client image, I tried doing this on a trunk image, and comparing the result to the same evaluation on a Squeak 3.8 image:
fs := FileStream fileNamed: '/home/lewis/squeak/Squeak5.3/Squeak5.3-19431-64bit.image.gz'. fs binary. result := SecureHashAlgorithm new hashStream: fs. fs close. result.
The results are the same for Squeak 3.8 and latest Squeak trunk (except that the old 3.8 image has a hard time printing the LargePositiveInteger result, but that is not relevant here).
This does not tell us what is going wrong in SqueakMap, but it does suggest that the issue is not anything directly related to the checksum calculation.
I guess this still does leave open the possibility of some difference in LargePositiveInteger arithmetic in the VM. It seems unlikely, but maybe we should check to be sure.
Tim, can you try running a checksum in Squeak on some known file from squeak.org downloads, and I'll try running it on my PC and see if we get the same LPI result?
Dave
On 2023-11-01 22:31, Tim Rowledge wrote:
Latest info on this continuing problem - Bruce suggested comparing the results of 'sha1sum' on the relevant file(s). I've now tested on x64 ubuntu arm64 pi armv7 pi (ie 32bit system) mac with images back to 4.6 and the results of SecureHashAlgorithm new hashStream: (FileStream fileNamed: 'foo' for various files) is consistently not the same as sha1sum for the same file. I also tried without the primitive support just in case.
As an example for the attached file Squeak consistently reports 1040456478707692947869256263227370279496083563594 whereas sha1sum says b63fae9e7e4ca1e21390449752355ff5d3b7e44a
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCVP: Destroy another Computer Via Phone-link
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Thinks "Private Enterprise" means owning a personal starship.
Printing and hex conversion on the large positive integer is failing on Squeak 3.8, so in the results below I am just dumping the digit values to compare.
The hex value calculated in a trunk image is '16r2D6533F0A936CA1AAB61F220C5A48DA3A5ABFEB7' which matches the value that you are getting. Results are the same on Squeak 3.8 and trunk.
Here are the results that I see, first on Squeak trunk and then on an old Squeak 3.8 running on interpreter VM:
"Squeak trunk" file := '/home/lewis/Downloads/9408ShoutCore-ar.8.cs'. fs := FileStream fileNamed: file. fs binary. result := SecureHashAlgorithm new hashStream: fs. fs close.che (1 to: 30) collect: [ :e | result digitAt: e ]. #(183 254 171 165 163 141 164 197 32 242 97 171 26 202 54 169 240 51 101 45 0 0 0 0 0 0 0 0 0 0)
"Squeak 3.8" file := '/home/lewis/Downloads/9408ShoutCore-ar.8.cs'. fs := FileStream fileNamed: file. fs binary. result := SecureHashAlgorithm new hashStream: fs. fs close. (1 to: 30) collect: [ :e | result digitAt: e ]. #(183 254 171 165 163 141 164 197 32 242 97 171 26 202 54 169 240 51 101 45 0 0 0 0 0 0 0 0 0 0)
So, regardless of what the sha1sum utility may be saying, we see no difference in any of the checksum calculations in Squeak from version 3.8 through trunk, and no difference in what you get on your Raspberry Pi versus what I see on my generic linux box.
Whatever might be going wrong on the SqueakMap server, I don't think we can blame it on the checksum calculations.
Dave
On 2023-11-02 01:01, Tim Rowledge wrote:
Hmm, try https://files.squeak.org/Experiments/updates/9408ShoutCore-ar.8.cs
I get the same value from sha1sum & squeak
(SecureHashAlgorithm new hashStream: (FileStream fileNamed: '/home/tim/DizietFS/Downloads/9408ShoutCore-ar.8.cs') ) hex
'16r2D6533F0A936CA1AAB61F220C5A48DA3A5ABFEB7'
I *think* a relevant part of the SM server code is SMFileUploadActiob>go, where it saves the file. After that... no idea. Somewhere it involves SMPackageRelease>>#refreshInCache which is where the sha1sum for the package gets set.
On 2023-11-01, at 5:16 PM, lewis@mail.msen.com wrote:
Assuming that we are looking for some difference in the checksum calculations on the SqueakMap server versus the same calculation on your much newer (trunk) client image, I tried doing this on a trunk image, and comparing the result to the same evaluation on a Squeak 3.8 image:
fs := FileStream fileNamed: '/home/lewis/squeak/Squeak5.3/Squeak5.3-19431-64bit.image.gz'. fs binary. result := SecureHashAlgorithm new hashStream: fs. fs close. result.
The results are the same for Squeak 3.8 and latest Squeak trunk (except that the old 3.8 image has a hard time printing the LargePositiveInteger result, but that is not relevant here).
This does not tell us what is going wrong in SqueakMap, but it does suggest that the issue is not anything directly related to the checksum calculation.
I guess this still does leave open the possibility of some difference in LargePositiveInteger arithmetic in the VM. It seems unlikely, but maybe we should check to be sure.
Tim, can you try running a checksum in Squeak on some known file from squeak.org downloads, and I'll try running it on my PC and see if we get the same LPI result?
Dave
On 2023-11-01 22:31, Tim Rowledge wrote:
Latest info on this continuing problem - Bruce suggested comparing the results of 'sha1sum' on the relevant file(s). I've now tested on x64 ubuntu arm64 pi armv7 pi (ie 32bit system) mac with images back to 4.6 and the results of SecureHashAlgorithm new hashStream: (FileStream fileNamed: 'foo' for various files) is consistently not the same as sha1sum for the same file. I also tried without the primitive support just in case.
As an example for the attached file Squeak consistently reports 1040456478707692947869256263227370279496083563594 whereas sha1sum says b63fae9e7e4ca1e21390449752355ff5d3b7e44a
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCVP: Destroy another Computer Via Phone-link
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Thinks "Private Enterprise" means owning a personal starship.
On 2023-11-01, at 6:38 PM, lewis@mail.msen.com wrote:
Whatever might be going wrong on the SqueakMap server, I don't think we can blame it on the checksum calculations.
Well, I guess that leaves some part of either the storing of the value into the saved package files, or the retrieving of them. This is very puzzling.
Hmm. In SMClient>>#uploadFile: which I believe id the method which actually sends the file to the SM server, we do some fiddling with the content of the file, doing an encodeMultipartForm:. Is that perhaps what gets checksummed instead of just the 'true' file content? It could explain the different checksum values.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim To err is human; to really foul things up requires a computer.
On 2023-10-23, at 6:38 PM, Chris Muller asqueaker@gmail.com wrote:
The server image is pretty easy to run locally. You could put a halt in the error message and the full stack of how it's getting there will be presented in all its clarity. Do you have it? Requires 32-bit interpreter VM.
No, I don't have the image, nor can I spot any place I could download it from. Pointers?
I've (attempted to) loaded the SMServer-gk.40 package and after some fudging to try to find a plausible HttpView2 package I loaded HV-gc.144 which seems so old it surely can't be the appropriate one.
The *only * place I can find that sets the sha1sum for a package is SMAccountPackageView>>#updateServerCache: and that is only sent by SMAccountPackageView>>#editreleases. Given that we are fairly convinced that the sha1 calculation is both correct and unchanged it seems there must be something that is getting the wrong data to hash. Either the server is hashing the wrong data, or the client is.
The server is displaying the hash value it knows on the web page. The client is calculating the hash from the script file it receives. They should be the same!
An example that does have matching values is Markus Denker's 'Benchmarks' package on SM. That has no install script, just an mcz file. The hash values match. Similarly, rob wither's BlogBrowser has jsut an mcz and matches hashes.
Rob Hawley's CalculatorMorph has an st file with all the code in, rather than an install script, but the hashes match ok.
My version 24 MQTT package from 6 october 2018 (holy cow, that long ago?) has a simple install script .st file and the hashes match. My Version25 release from a couple of weeks ago has a simple install .st file and the hashes do not match. I am now baffled as to how that could happen.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Suffers from Clue Deficit Disorder.
Hey Tim,
This might be a long shot but could the problem be line endings? Any chance you uploaded the code from one machine to monticello and released it from another? Calculating the sha on cr but then storing as lf. Were you ever able to verify where the hash is coming from? Does the wrong hash match the install script (we discussed earlier) or uncompressed package or something like that? (apologies if this has already been discussed).
Or could you have uploaded a new version of the code with the same name after releasing it to squeak map? In that case the error is correct, they don't match.
All the best,
*Ron Teitelbaum* *Chief Executive Officer**3D Immersive Collaboration Corp* ron@3dicc.com www.3dicc.com
https://www.facebook.com/3DICC https://twitter.com/RonTeitelbaum https://www.linkedin.com/in/ronteitelbaum
On Thu, Nov 2, 2023 at 3:18 PM Tim Rowledge tim@rowledge.org wrote:
On 2023-10-23, at 6:38 PM, Chris Muller asqueaker@gmail.com wrote:
The server image is pretty easy to run locally. You could put a halt in
the error message and the full stack of how it's getting there will be presented in all its clarity. Do you have it? Requires 32-bit interpreter VM.
No, I don't have the image, nor can I spot any place I could download it from. Pointers?
I've (attempted to) loaded the SMServer-gk.40 package and after some fudging to try to find a plausible HttpView2 package I loaded HV-gc.144 which seems so old it surely can't be the appropriate one.
The *only * place I can find that sets the sha1sum for a package is SMAccountPackageView>>#updateServerCache: and that is only sent by SMAccountPackageView>>#editreleases. Given that we are fairly convinced that the sha1 calculation is both correct and unchanged it seems there must be something that is getting the wrong data to hash. Either the server is hashing the wrong data, or the client is.
The server is displaying the hash value it knows on the web page. The client is calculating the hash from the script file it receives. They should be the same!
An example that does have matching values is Markus Denker's 'Benchmarks' package on SM. That has no install script, just an mcz file. The hash values match. Similarly, rob wither's BlogBrowser has jsut an mcz and matches hashes.
Rob Hawley's CalculatorMorph has an st file with all the code in, rather than an install script, but the hashes match ok.
My version 24 MQTT package from 6 october 2018 (holy cow, that long ago?) has a simple install script .st file and the hashes match. My Version25 release from a couple of weeks ago has a simple install .st file and the hashes do not match. I am now baffled as to how that could happen.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Suffers from Clue Deficit Disorder.
I replied to this earlier but my reply may be getting blocked by various spam filters, so the TLDR version is that the image is probably 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
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Chris Muller -
lewis＠mail.msen.com -
Ron Teitelbaum -
Tim Rowledge