gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gorm loading problem / binary compatibility


From: Riccardo Mottola
Subject: Re: gorm loading problem / binary compatibility
Date: Sun, 17 Mar 2013 22:06:55 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16

Hi,

Fred Kiefer wrote:
Thank you for pointing out this issue. It looks like different compilers treat enumerators differently. Some seem to turn them into unsigned int, while others use int. To prevent this sort of problems I went through the whole gui encoding code and replaced enumerator types with the basic types that we used before. The should solve the problem for the future.
Indeed. Apparently this happened with gcc 4.7.2 vs an older gcc 4.x version
For your specific gorm file it would be best to recreate it from scratch or from an older backup. If this is not possible you could try to apply only half the change I made for NSParagraphStyle, the encoding bit and leave the decoding as it was. That way you are able to load the file in the incorrect format and store it in the corrected one. But don't forget to switch to the full change after that, or you wont be able to load the file again.
With your change I am able to load the Gorm file actually, so it gets decoded properly, it is the NetBSD machine that needs the fix. I'll experiment around and let you know. Sadly, there is no backup or, worse actually, the back up I have was already not working.

This also means that we need to do another gui release very soon, to prevent others from creating incorrect gorm files. (Although I don't expect to many people will store paragraph styles or events in gorm files) And that we need a lot more testing code for gui. If we had code that tries to load pre-created archives for every class that supports encoding, we would have noticed earlier.
Actually, I did nothing special. Could it just be that this paragraph style gets encoded when you alight left or right a NSTextField used as label? This would be reasonably common.

This is a bug that could be only caught when playing with different computers and compiler versions, on a single machine everything was clean and consistent.

A release would be good probably. I'll email you privately a better test case for the table cells, so that perhaps we can finalize that too before a minor update release, which is going to happen for base too!

Riccardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]