Windows GNUstep does not support XML plists :(

[dajt]

I have spent significant time over the last couple of days trying to get a start on oolite for Windows. I am beginning to wonder exactly what GNUstep for Windows does support, other than crashing.

The problem of GNUstep not dealing with NSImages is pretty bad but will go away when I have managed to get SDL surfaces tranlating to OpenGL textures.

However I found a more fundamental problem: GNUstep on Windows doesn't support XML plists! libxml doesn't compile in the GNUstep build environment, and I've been hacking around with a pre-compiled version but it isn't happening either - every time I get rid of a missing reference from GNUstep Base another takes its place.

If someone out there feels like writing a program to translate XML plists to the other format and converts all of oolites plist files, I'll have another go.

Basically, GNUstep on Windows doesn't work for any reasonable definition of the word "work". Don't hold your breath on this one - it won't be working any time soon.

[aegidian]

IIf someone out there feels like writing a program to translate XML plists to the other format and converts all of oolites plist files, I'll have another go.

To convert XML propertuy lists to old-style ASCII property lists this could be done with a very simple script on a find-and-replace basis.

It would mean that any Windows users would have to convert the contents of expansion packs as well, but if the script were part of the game package...

How about this:

Rewrite the ResourceManager class to load the text file requested for a dictionary as a NSString and check it for a prefix of some part of the <?xml version="1.0" encoding="UTF-8"?> line.

If it's there, pass the string to a new method (you will have to write) + (NSObject *) parseXMLPropertyListToObjectFromString:(NSString*) plistString that will parse the content of the string and return a suitable object (NSNumber, NSString, NSArray, NSDictionary).

This method should:

1. replace any 'empty' tags like <true/>, <false/>, <array/>, <dict/> with pairs of tags (use <real>1.0</real> and <real>0.0</real> for </true> and </false>)

2. strip out any tags that aren't <dict></dict>, <string></string>, <integer></integer>, <real></real>, <array></array> or <key></key>

3. consider the outermost tag and either:
3.1 return a simple object if it's <string> or <real> or <integer>
3.2 recursively parse and return collection objects like <array> or <dict>


That's a tedious task, but not too taxing. There may already be pre-existing code in the GNUStep repository that can be borrowed for this.

The linux code could borrow this implementation to avoid the 'unknown DTD' message problem as well.

[JensAyton]

Ahh, something I can do on the G3.

<fx: furious typing>

Done. One really awful crock of an XML-plist parser, which handles all types except Data and Date. (Do we need Data? I'm pretty sure we don't need Date.) Will e-mail to Giles.

Note: this parser doesn't do proper XML parsing. It will handle some malformed XML, and there are probably plists it will fail on. Most failures should result in a reasonably neat exception. Oh, and it only does UTF-8. Still, I don't think anyone's done any spectacularly weird stuff in OXP plists.

[aegidian]

Cool - and no, I think we can simply raise a custom exception if we encounter data or date objects and return nil.

[dajt]

Cool Arhuman, thanks.

Giles, would you please e-mail that to me when you get it?

[dajt]

Ahh, something I can do on the G3.

<fx: furious typing>

Done. One really awful crock of an XML-plist parser, which handles all types except Data and Date. (Do we need Data? I'm pretty sure we don't need Date.) Will e-mail to Giles.

Note: this parser doesn't do proper XML parsing. It will handle some malformed XML, and there are probably plists it will fail on. Most failures should result in a reasonably neat exception. Oh, and it only does UTF-8. Still, I don't think anyone's done any spectacularly weird stuff in OXP plists.

I tried your code and it complains about an unknown tag "<key>". If the code is working on your system it would be much easier (for me ;) if you just ran the conversion there and sent me the converted files.

In any case thanks for having a go at it. I did try to write a converter in a spare hour today and it came out with what I thought was an okay properties file, but GNUstep would not load it.

[aegidian]

...t would be much easier (for me if you just ran the conversion there and sent me the converted files.

Erk - the point is to use this code to parse the files for Oolite-pc/linux so that files in expansion packs (and the main package) don't have to be converted.

Otherwise every expansion pack would have to be checked and converted for use with your versions, and I'm determined that expansion packs should remain cross-platform.

[dajt]

I know that's the ultimate goal, but I don't have the patience to muck around trying to make that work when the thing won't even show me any pretty blinky lights yet.

I wrote a tiny Obj-C program to translate plists - luckily when you ask GNUstep to save a dictionary or array it does so in the openstep format and not XML (listen closely, you won't hear this often... yay GNUstep!)

I downloaded the openstep format plists to try and keep making progress.

[JensAyton]

dajt, which plist causes the "unrecognised tag <key>" thing?

(Actually, e-mail me the answer -- there's a button button below -- and I'll e-mail back the fixed files. ;-)

[JensAyton]

fix0red.

Brokenness was to do with not handling empty <array/> and <dict/> elements. Fixes (I'd post a diff, but I seem to have lost the original):

Code: Select all

static id ReadXMLPListArray(const uint8_t *inBuffer, NSRange *ioRange, NSRange inTag)
{
	NSMutableArray			*array;
	id						result = nil;
	NSRange					tag;
	NSRange					temp;
	
	if (RangePrefixMatch(inBuffer, inTag, "array/"))
	{
		return [NSArray array];
	}
	
	array = [[NSMutableArray alloc] init];
	
	/* Continues as before ... */


static id ReadXMLPListDictionary(const uint8_t *inBuffer, NSRange *ioRange, NSRange inTag)
{
	NSMutableDictionary		*dict;
	id						result = nil;
	NSRange					tag;
	NSRange					key;
	
	if (RangePrefixMatch(inBuffer, inTag, "dict/"))
	{
		return [NSDictionary dictionary];
	}
	
	dict = [[NSMutableDictionary alloc] init];
	
	/* Continues as before ... */

And, in NextXMLPListObject():

Code: Select all

	if (RangePrefixMatch(inBuffer, tag, "array")) return ReadXMLPListArray(inBuffer, ioRange, tag);
	if (RangePrefixMatch(inBuffer, tag, "dict")) return ReadXMLPListDictionary(inBuffer, ioRange, tag);

[aegidian]

Sorry to work by discarding your code Ahruman, but I thought I'd have a bash at an XML parser myself, using some standard Obj-C/GNUStep stuff.

I'm not sure how bullet-proof it is, but I just committed changes to the oolite-linux/pc code that should parse XML plists (assuming that none of the code I used to achieve this is also a problem for Windows/GNUStep).

[Selezen]

...and, of course, assuming the PC version will ever recompile...

[dajt]

After getting libxml2 compiled I decided to go for broke and recompile the GNUstep base DLL to see what would happen. Amazingly, it recognised libxml2 and now reads XML plists.

I commented out all of the Oolite XML reading code to make sure, and all the DTD warnings come up showing GNUstep is doing the parsing itself.

I'm not sure where to take this yet. The standard GNUstep dist for Windows still won't be able to do this, so if I start using it it means Oolite will be using a non-standard installation, which I don't like the sound of.

Looking at the GNUstep wiki it seems they already know the latest version of libxml2 is usable with MinGW, so I expect it will become a standard part of the release eventually.