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.
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?