Re: problem loading GWorkspace DesktopPreferences Gorm file

[Sebastian Reitenbach]

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.

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

cheers,
Sebastian


> 
> Fred
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep