discuss-gnustep
[Top][All Lists]
Advanced

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

Re: problem loading GWorkspace DesktopPreferences Gorm file


From: Fred Kiefer
Subject: Re: problem loading GWorkspace DesktopPreferences Gorm file
Date: Tue, 24 Apr 2012 09:33:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120328 Thunderbird/11.0.1

On 24.04.2012 01:21, Sebastian Reitenbach wrote:

On Monday, April 23, 2012 21:48 CEST, Fred Kiefer<address@hidden>  wrote:

On 23.04.2012 19:31, Sebastian Reitenbach wrote:
On Monday, April 23, 2012 10:49 CEST, "Sebastian Reitenbach"<address@hidden>   
wrote:
On Monday, April 23, 2012 09:54 CEST, Riccardo Mottola<address@hidden>   wrote:
Sebastian Reitenbach wrote:
I'm testing GWorkspace for a new release, and found, that the
DesktopPrefs Gorm file doesn't load anymore:

2012-04-15 19:41:40.380 GWorkspace[7146] Exception occured while loading model: 
expected array count 8 and got 134479950
2012-04-15 19:41:40.381 GWorkspace[7146] Failed to load Gorm
2012-04-15 19:41:40.381 GWorkspace[7146] Exception occured while loading model: 
expected array count 8 and got 134479950
2012-04-15 19:41:40.381 GWorkspace[7146] Failed to load Gorm
2012-04-15 19:41:40.381 GWorkspace[7146] failed to load DesktopPref!
2012-04-15 19:41:41.036 GWorkspace[7146] prfsname {"fsn_info_type" = 0; geometry = "508 93 450 675 0 0  1024 768 "; 
"hligh_table_col" = 0; iconposition = 5; iconsize = 48; labeltxtsize = 12; lastselection = ("/"); "list_view_columns" = 
{0 = {identifier = 0; minwidth = 80; position = 0; width = 140; }; 1 = {identifier = 1; minwidth = 80; position = 3; width = 129; }; 2 = {identifier 
= 2; minwidth = 80; position = 1; width = 90; }; 3 = {identifier = 3; minwidth = 50; position = 2; width = 50; }; }; shelfdicts = ({index = 0; paths 
= ("/home/sebastia"); }, {index = 1; paths = ("/usr/local/libexec/GNUstep"); }); shelfheight = 77; singlenode = 0; spatial = 0; 
viewtype = Browser; }

Riccardo said, this file was edited lately.
When I see those large numbers I guess, it may be that while editing that file 
on amd64, after the NSNotFound change with Gorm, that Gorm did encode some 
garbage in it?

I have seen a similar problem with a Gorm file of PRICE too while testing that.
The problem with GWorkspace only tested on i386 so far, the problem with PRICE 
I have seen on i386 and amd64.

Any idea where this could come from and what to do about it?
I have no clue, I hope others can help. This kind of errors happened
when you had a bogus version number, remember? But here it should be
fine in the gorm file, please check.
I hope other core guys can jump in, describe your configuration more
precisely?

I am able to open GWorkspace's preferences panel on most 32bit platforms
I have: NetBSD Sparc&x86, linux and even OpenBSD (using gcc and the
whole sourcetree built from our repository, not ports). It works also on
linux x86-64.

Philippe asked me to test his SimpleAgenda, there I run into the same problem.
He is using gnustep-core from svn. So I'll try installing gnustep-core from
svn to see whether those failures will vanish.
If yes, this still doesn't help me much to get those Applications running with
the latest releases...

So, I did the promised test, and found with gnustep core from svn, all is 
working fine,
PRICE, GWorkspace, and also SimpleAgenda, at least with regard to the Gorm 
loading problem.
Not much else tested so far. As it seems, their Gorm files were all edited with
gnustep core newer than the latest releases.
So the question I have now, is there an easy way to get them working with
the latest releases to make packagers like me happy? ;)

That is just what I expected to be the problem. If you need to backport
some code, this will most likely be the method
-decodeArrayOfObjCType:count:at: on NSUnarchiver (and maybe in
NSPortCoder as well, if you need interaction with newer code). I am

This backporting would help just only me for the OpenBSD packages, but what's 
with all
those other *BSD and lots of Linux distributions. Now as a packager I have 
three major options:
  * Do not upgrade those broken applications until next gnustep-core release
  * upgrade, but they may be completely or partially be broken, and let them get 
"automatically"
     fixed later, with the next gnustep core update
  * backport the needed fixes from svn

The second one is a no-go, therefore I care too much about the apps, instead of 
providing broken packages.
The first one, may be the way to go, due to time constraints
The third one, would probably the overall best, but would only help me on 
OpenBSD, and otherwise
the other *BSD, and lots of Linux and Windows, .... they would still face the 
same problem.

still wondering, why we don't raise an exception in base, when the
version found in the archive is incompatible with the version we are
running on. But even that change wont help you, as this code would only
be in the new code :-(

When a developer runs SVN, then that's fine. He usually knows, when using a new 
class/method in the code,
and they can decide, whether the next release of their app will be before or 
after the next core release.
But those binary changes to the Gorm files, they are not so obvious. This 
obviously trapped some long time
GNUstep developers.
Does there exist a technical way that could prevent this happening in the 
future? So not only make
the core libraries backward compatible, but also potentially more future 
compatible?
Or is it just the developers discipline, in case he wants to release Apps 
against the latest releases,
that he is supposed to use the releases while developing?

I'm just thinking, whether Gorm for example could open a Gorm binary file, and 
save the representation
as a .plist file? Which then in turn could be opened by Gorm again, to save it 
again as a binary again?
That would probably make porting Gorm files to older versions of gnustep easier.

There is one more option we could think about here. We could change the method NSArciver -encodeArrayOfObjCType:count:at: to be backward compatible. That means this method should store all array sizes that fit into an 32 bit integer in that space and only use the new technique for bigger sizes. This will mean that we'll have two version checks instead of one and of course another version increase in base. But all these drawbacks seems minimal when compared to the current situation where old code wont be able to load newer Gorm files.

Richard, what is your position on all this? You are definitely the expert here and we may have overlooked a much cleaner solution.




reply via email to

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