[squeak-dev] MC 'check all packages for changes' fails because WebClient-Core-ul.116 is missing

Chris Cunningham cunningham.cb at gmail.com
Wed Jan 9 02:46:10 UTC 2019

I'm curious if you could reproduce it with a clean copy, except put a
WebClient-Core-pre.117(ul.116).mcd (or the, correct, one) into your
package-cache.  Wonder if that had something to do with it failing.

On Tue, Jan 8, 2019 at 5:50 PM David T. Lewis <lewis at mail.msen.com> wrote:

> On Tue, Jan 08, 2019 at 02:46:02PM -0800, tim Rowledge wrote:
> >
> >
> > > On 2019-01-08, at 2:21 PM, Levente Uzonyi <leves at caesar.elte.hu>
> wrote:
> > >
> > >
> > > Did you download a fresh image? Unfortunately, we had two images
> released as 5.2 with different content.
> >
> > An excellent question. I am pretty sure I had the latest but to be sure
> I downloaded the very latest 5.2 image and compared to the one I was using
> and it appears to be identical. Just to test, I used the new image to run
> the clean packages check on my iMac and it worked. This made me wonder
> about maybe the contents of package-cache, so I copied the new image to the
> Pi (where I had been having the problem - almost all my Squeak work is on a
> Pi just to keep testing the ARM cog), deleted the Pi version of
> package-cache and tried - no problem. I even tried the older-but-the-same
> image and it worked.
> >
> > So, it looks like maybe there is some edge case where the contents of
> package-cache interferes a little. Just in case it suggests anything to a
> keen MC implementor, I generally have many images in a single Squeak
> directory and thus a single package-cache directory that all of them write
> to. Perhaps this has some bearing?
> >
> In addition to the disk-based package cache, there is a good deal of
> in-image caching that can lead to bizarre problems.
> If you are able to reproduce your original problem, try doing
> "MCFileBasedRepository flushAllCaches" and see if the problem goes
> away.
> In my experience, the package-cache rarely causes problems, except in
> cases like (for example) an empty and therefore corrupt package version
> left in the package-cache folder after a failure of some sort.
> On the other hand, the in-image caching is a source of frequent problems,
> and I am in the habit of flushing the caches whenever I run into any
> kind of oddity related to MC versions.
> Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190108/312767e4/attachment.html>

More information about the Squeak-dev mailing list