Max,
Sorry for being cranky:) You caught early in the morning before I
had coffee:)
It's good news, bad news ... the good news is that I can rely on
travis to do a ton of testing ... the bad news is that I don't have
test systems at my fingertips for Squeak or Pharo ... I develop
Metacello in GemStone and when Pharo/Squeak tests fail on Travis, I
can usually get away with editing the Squeak/Pharo packages in-place
in my filetree checkout:). I also depend up Frank Shearar, Tobias
and the HPI crew for tracking down specific issues that may show up
during testing...
I am always on the look out for bugs that may creep into the system
and bootstrapping Metacello has been a historically hard problem ...
in the last few years (thanks in large part to travis), I've been
able to keep bootstrapping issues from escaping into the wild... but
one never really knows ...
I am glad that you got to the bottom of this and I appreciate your
patience.
Dale
On 03/19/2015 02:28 PM, Max Leske
wrote:
Max,
Before I go
about trying to install Squeak on my machine, could you
provide me
with more details about the environment that you are
running in?
I’m sorry you had to write all this stuff. I’m usually more
thorrough with my reports.
I'm not seeing
any issues with my travis builds nor has anyone else run
into this
issue... So I'm suspicious that the root cause is going to
be
something
unique to your working environment. I haven't run Squeak
myself in
months:) and I rely on Travis .... So I have to find and
download all
the bits and pieces to install Squeak in my environment in
the hopes that
when I execute your expression I will see the same
corruption as
you are seeing (I don't have a great batting average in
this regards)
...
It certainly
appears that ConfigurationOfMetacello-dkh.800.mcz is not
corrupted up
on smalltalkhub or gemsource (the two repos accessed
during
bootstrapping)...
which also leads me to believe that the root cause is
in your setup
...
Your package
has been truncated it should be 128999 bytes and your copy
is 53989 ...
perhaps your copy of the package is corrupted in the
package-cache?
The next most
likely culprit is the vm ... which brings me back to why I
asked the
question at the top of the email ... if you give me the
details about
your setup - vm version is probably the most important,
since I get
the impression that there a lot of them running around and
the version
you have depends upon when you downloaded yours... but it
would help if
you told me where you got your images and changes files as
well ... oh
and the os version, too...
Dale
I've figured it out. Your were right, the newest Cog
VM doesn’t exhibit the problem. The problem seems to be the
method
ZipWriteStream>>deflateBlock:chainLength:goodMatch:. The
primitive in that method fails in 4.6 only when I open the 4.6
image with the VM packaged with the 4.5 all-in-one app ('Croquet
Closure Cog VM [CoInterpreter VMMaker.oscog-eem.331] 4.5’). The
fallback method generates an error.
This is reproducible when using the fallback instead
of the primitive with the other VM and a 4.5 image too, so there
is definitely something wrong with the Zip implementation.
Here’s a snippet for reproducing the problem:
ZipWriteStream removeSelector:
#deflateBlock:chainLength:goodMatch:.
package:
'Gofer-Core-lr.115.mcz';
(Smalltalk at: #Gofer) new
addPackage:
'ConfigurationOfMetacello';
So no need for you to fix anything about Metacello.
Sorry about the fuss.
Cheers,
Max
Locked
ConfigurationOfMetacello-dkh.800.mcz (72K)