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: Riccardo Mottola
Subject: Re: problem loading GWorkspace DesktopPreferences Gorm file
Date: Tue, 24 Apr 2012 09:11:07 +0200
User-agent: Mozilla/5.0 (X11; FreeBSD i386; rv:11.0) Gecko/20120414 Firefox/11.0 SeaMonkey/2.8

Sebastian Reitenbach wrote:

On Monday, April 23, 2012 21:48 CEST, Fred Kiefer<fredkiefer@gmx.de>  wrote:

On 23.04.2012 19:31, Sebastian Reitenbach wrote:
On Monday, April 23, 2012 10:49 CEST, "Sebastian 
Reitenbach"<sebastia@l00-bugdead-prods.de>   wrote:
On Monday, April 23, 2012 09:54 CEST, Riccardo 
Mottola<riccardo.mottola@libero.it>   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.
Another ugly hack is perhaps to "patch" the gorm file versions for your gorm files and remoember to remove the batch when the next core packages come out? would that work?

Of course be sure not to ever release upstream a file marked with the wrong version number.



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?
Well, more than a Gorm release in this case it is a bae release... And this normally doesn't happen. I, for example, run latest on my development machines. I usually do test before shipping against release packages though.

Riccardo



reply via email to

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