Thanks to the effort of SeanDiNigris, we continue trying to find out the problem. Sean asked me if the package contained non-asci characters..and yes, it has widestrings directly in the literal of a method (this is on purpose). The method is #testWideString Dale Henrichs told me there could be some problems with WideStrings and Gemstone in the ss3. So far I didn't find anyone...but now it seems we do? i think this problem was forever..and the unziping from the OS fails, but somehow the unziping from Monticello does work? Any ideas? Thanks! On Mon, Jun 25, 2012 at 9:17 AM, Pavel Krivanek <pavel.krivanek@gmail.com>wrote:

Can you try to file-in the uncompressed file? Or at least look if the file is complete. Because I discovered this issue when trying to load Fuel tests into the Pharo Kernel (the download and unzip of the package is done directly by Pharo) and I had no problem with unzip of this file on Linux but the resultant file was not complete and the loading finished with syntax error.

-- Pavel

On Sun, Jun 24, 2012 at 11:58 PM, phil@highoctane.be <phil@highoctane.be> wrote:

...

I downloaded it, renamed the .mcz as a .zip and used the unarchiver on it. No issue.

3271 lines in source.st

OSX Lion over here.

Was able to get it back from my 1.4 on CogVM and browse the downloaded package.

Seems to be a OS X related issue. Rebooting a Mac may be rare, but may help... Network problems? Sometimes my NAS needs a kick in the butt..

Phil

2012/6/24 Mariano Martinez Peck <marianopeck@gmail.com>

...

Hi guys. I have a problem and I don't understand. If you download FuelTests-MarianoMartinezPeck.269 from http://ss3.gemstone.com/ss/Fueland try to unzip it, in my MacOSX I have an error saying the fie is

corrupted.

...

If I proceed anyway, and I open the .st it is CUT in the middle (it does not finish properly). I thought it was a problem with Traits (because FuelTest has traits), but I tried other packages even with traits and they are fine. Then I thought that that version of the package could be corrupted, but I went several versions ago in history and same problem. Then thoguht it was Monticello problem. I went to Pharo 2.0 20020 and again, same problem.

So I am lost. I remember something about the zip compression problem in Monticello.... could this be related?

thanks

-- Mariano http://marianopeck.wordpress.com

-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be

High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

-- Mariano http://marianopeck.wordpress.com

On Mon, Jun 25, 2012 at 6:05 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:

Mariano Martinez Peck wrote

...

Sean asked me if the package contained non-asci characters..and yes, it has widestrings directly in the literal of a method (this is on purpose). The method is #testWideString

testWideString contains wide characters. But the write is not failing inside testWideString because zip writing is buffered in 4096 byte chunks, so it fails at the beginning of that buffer write (in testTimestamp). If I remove the wide char literals from TestWideString, and resave the package, I can unzip it and file in source.st

Wow. I love this community. Pavel founds the problem. Sean debugs it and founds the real cause. Thank you guys, you cover our back when I don't have much time :) So...as a workaround, since the literals of a CM are visited as any other object, it is not really needed to have a test with WideStrings in the source code. So I have just have: testWideString self assertSerializationEqualityOf: 'aString' asWideString. self assertSerializationEqualityOf: (WideString streamContents: [ :stream | 2000 timesRepeat: [ stream nextPut: (256 to: 1000) atRandom asCharacter ] ] ). and that should work :)

The write logic is in ZipArchiveMember>>copyDataWithCRCTo: ... data := self readRawChunk: (4096 min: readDataRemaining). aStream nextPutAll: data. ...

When #readRawChunk: returns a WideString, all hell breaks loose. I don't know what the solution is, but at least we found the problem...

We should try to write a unit test for this. I will at least open an issue ;)

-- View this message in context: http://forum.world.st/Problem-with-Monticelo-package-and-corrupted-sourcecod... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- Mariano http://marianopeck.wordpress.com

Stéphane Ducasse wrote

I'm unclear. Does it mean that we have a problem with zip? Package?

I don't really know enough about text encoding to say. It seems that people have run into things like this before. I collected all the references I could find and made an issue: Issue 6160: Monticello: Zipping Wide Characters http://code.google.com/p/pharo/issues/detail?id=6160 Pharo2.0a Latest update: #20160 If one has a method with wide character literals, when Monticello saves the package, the source.st file inside the mcz file will only be valid if unzipped inside Squeak/Pharo. This is because Pharo writes zip files in 4096 byte chunks, which will all be ByteStrings, except the ones containing wide characters, which will be WideStrings. Thus, source.st will be a random mashup of such 4096 byte stretches. See the following for possibly related info: * http://forum.world.st/Monticello-mcz-files-write-their-DataStream-and-a-port... * https://code.google.com/p/pharo/issues/detail?id=2697 * http://code.google.com/p/pharo/issues/detail?id=6143 * https://code.google.com/p/pharo/issues/detail?id=830 Squeak/Pharo encoding in general * http://www.visoracle.com/squeak/faq/unicode-utf8byte.html * http://forum.world.st/squeak-dev-WideString-UTF-8-UTF-32-UCS2-td74243.html * http://forum.world.st/WideString-performance-td4077404.html HTH, Sean -- View this message in context: http://forum.world.st/Problem-with-Monticelo-package-and-corrupted-sourcecod... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.