On 2 Dec 2008, at 07:15, Niels Grewe wrote: > Hello all, > > since I am not usually using StepChat I just stumbled upon a > problem with it after playing around with XMPPKit a little bit, > but the problem is there with XMPPKit unmodified. (I.e. the > problem concerns StepChat both in stable and in trunk) > Apparently, the newest gnustep-trunk (r27183, fresh install) > thinks that the MainMenu.nib in StepChat is invalid. At least I > get the following output when trying to run StepChat: > > 2008-12-02 08:05:34.563 StepChat[5637] Exception occured while > loading model: subclass NSKeyedUnarchiver(instance) should override > versionForClassName: > 2008-12-02 08:05:34.563 StepChat[5637] Failed to load Nib > 2008-12-02 08:05:34.564 StepChat[5637] Could not load Gorm file: / > home/thebeing/GNUstep/Applications/StepChat.app/Resources/ > English.lproj/MainMenu.nib > > Gorm also fails with the Exception on NSKeyedUnarchiver when > trying to open the .nib. (the .gorm file works fine, though). So > my question here is: Is there actually something wrong with the > .nib or am I being bitten by a bug in gnustep? Any help is > greatly appreciated.
I believe this is a (new) bug in GNUstep, since it did work with the version I was using until a few weeks ago. I've CC'd this to Gregory so he can have a look. Gregory: The nib in question is in Services/User/Jabber/English.lproj in our SVN. > best regards > > > Niels > > (PS: Just in case you‘re wondering: I‘m presently working on SRV > lookups for XMPPKit. I‘ll post my patches on the review board as > soon as I get any actual testing done.) I began writing an ETSocket class a while ago which uses getaddrinfo() and so works with SRV records (and IPv6) automatically. The aim was to allow you to push filters onto a stack, allowing SSL and gzip (or anything else you thought of) to be added after a connection is established (the APIs in NSStream do not allow SSL negotiation after the connection is completed, which is a problem for XMPP and a number of other protocols). My plan was then to rewrite some of XMPPConnection to use this class. If you're working on this, then I can send you my initial work (which, sadly, isn't much - I got distracted early on) if you like. I'd rather see some generally-useful code in EtoileFoundation and a simplified XMPPKit than some extra special-case code in XMPPKit (I may have mentioned before, but the XMPPConnection class is a horrible mess in need of some serious work). David _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
