I've added a little more information to Issue 2697 and I'm willing to
help on the GemStone-side. It looks like a WideString has snuck into the
mcz file ... seems to be similar to the WideStrings showing up in the
changes file issue (Issue 830 ... which appears to resurface
periodicaly:)), but I haven't looked closely at how it could happen,
although if the changes file had a WideString in it then the WideString
could easily migrate into the mcz file...
Dale
Paul DeBruicker wrote:
Hi-
I created an issue in the tracker:
https://code.google.com/p/pharo/issues/detail?id=2697
Some packages that were created with and load fine into Pharo 1.1 release do
not load into Gemstone because of the use of WideStrings while creating the mcz
files. I don't know how to dissect the mcz files at this time but in
describing my issue on the GLASS list, Dale Henrichs was able to reproduce the
problem and diagnose it. His diagnosis is pasted below.
To recreate my issue you must be using Gemstone 2.4.4.1, Glass 1.0-beta8.2, and
GemTools for Gemstone 2.4.4. First load the ConfigurationOfJQueryWidgetBox
package from the Metacello Repository on SqueakSource. Then run:
(ConfigurationOfJQueryWidgetBox project latestVersion)
load: #('JQWidgetBox-FullCalendar-Core').
It will attempt to load the package but complain that a dependency for the
JQFullCalendar Class is not met. The JQFullCalendar class is provided by the
JQWidgetBox-FullCalendar-Core package.
Our entire discussion leading up to his diagnosis is here:
http://forum.world.st/aFilePackage-cannot-perform-the-selector-preamble-with-the-arguments-in-anArray-aChangeRecord-td2291748.html#a2294376
Is there a way to write the mcz files using something other than WideStrings
that will allow me to attempt to load them into Gemstone and perhaps get a
different result?
Thanks
Paul
Paul,
Okay, it looks to me like your mcz file(s) are "corrupted" ... probably
due to a bug in Pharo 1.2 (that's the version you're using right?).
In an mcz file the snapshot of the definitions are serialized using two
formats:
1. a DataStream on an ordered collection of MCDefintions
2. a chunk-file formatted string.
It appears that for the DataStream, the entire(?) stream is written as a
WideString ... WideString is Squeak/Pharo dependent and is not portable
at all ... this is new. When GemStone hits the widestring an error is
thrown and Monticello tries to use the chunk-file format (which is why
you ran into the preamble probelm ... chunk file format is normally hit
(nor is it desirable to hit it)...
The chunk file-file is partially written as a WideString again...because
the WideString is not portable it breaks the parsing algorithms for
GemStone ... interestingly enough the chunk-file string looks to be a
WideString for the first hundred characters or so ...
One of three things is happening:
1. someone in Pharo land decided it was a "good idea" to create mcz
files using WideString
2. The that you used to create the class had a WideString in it
3. there is a bug somewhere in the pharo/monticello implementation
I can't guess which of those 3 the problem is and I can't guess what the
solution might be either.
If you bring up this bug on the Pharo list, I'll monitor the list and if
I can step in and help, I will.
Dale
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
