Re: XML GNUstep defaults (was: [flame] NEWS file is useless)
On 26 Nov 2009, at 17:35, Wolfgang Lux wrote: Richard Frith-Macdonald wrote: I think directly ~/GNUstep/Defaults/.GNUstepDefaults ? That's XML for me now and it wasn't. Oh, that's a hidden file for private use by the base library ... kind of surprising that anyone would notice, and certainly not something which should appear in news/release notes as it's internal information. Indeed, one shouldn't notice -- except that there was a bug in NSPropertyList.m, which did use an incorrect translation for ASCII control characters (it was using the old Java \U notation instead of numerical character encodings). Due to this bug the position of menus was no longer persistent. I've just committed a fix for this in svn and now torn-off menus will reappear again the next time you start an app. I partially reverted that ... the code to generate the escape sequences was correct, the problem was a failure to parse them on reading the result back. The underlying issue is that certain characters are illegal in XML, even when encoded using the #...; syntax! The list of illegal characters includes ascii code 27 (escape), yet OSX uses the escape character as the key for the top-level menu. If you feed such data to a proper XML parser (such as libxml2), it will abort parsing when it encounters the illegal character. The OSX property list parser is not actually an XML parser it's really handling something which just looks a lot like XML. So the use of the \U... syntax was/is there to encode characters in property lists, hiding them from the XML parser ... then the property list parser needs to decode these sequences after the XML parser has done with them. Now, we have a (rather immature) XML parser in base which is currently being trialled as a replacement for libxml2. It treats all characters as legal and can therefore handle property lists containing illegal characters. So perhaps we can remove the additional encoding of illegal characters. The question is, do we want to write illegal XML in property lists? At the moment the code can write legal XML or illegal (OSX compatible) XML depending on the OSX compatibility defaults setting. If we assume that 'XML' property lists will never actually be processed by real XML parsers, we don't need the additional encoding. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [flame] NEWS file is useless
Also, A ChangeLog is easy to search. When something breaks I grep in the changelog. Old habits. Why is: cat ChangeLog | grep easier than: svn log | grep Because using a ChangeLog doesn't require internet access, and it is *much* faster. :-) And for people who get a source tarball, they don't even need to have subversion installed, or know where the repository is located or how to access it. Anyway, it seems a long discussion on a minor point. I suggest we could simply manually copy the ChangeLog entry in the svn commit message every time we do a commit. Then the ChangeLog entry would be available also via svn log for people who use svn logs instead of ChangeLogs to track development. I guess this could be automated so a subversion hook would check that every commit contains a ChangeLog entry, and would automatically copy it into the subversion commit message. As hooks would slow down an already slow repository, we could also simply agree to do it manually. If someone gets it wrong it will be immediately obvious by looking at the svn logs and can be corrected. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: XML GNUstep defaults (was: [flame] NEWS file is useless)
On 27 Nov 2009, at 08:39, Richard Frith-Macdonald wrote: The question is, do we want to write illegal XML in property lists? At the moment the code can write legal XML or illegal (OSX compatible) XML depending on the OSX compatibility defaults setting. If we assume that 'XML' property lists will never actually be processed by real XML parsers, we don't need the additional encoding. I think the best bet would be to be compatible with other property list parsers. How does the NetBSD XML property list parser cope with illegal characters? Does WindowMaker support XML plists and, if so, can it handle them? David -- Sent from my PDP-11 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
XML GNUstep defaults (was: [flame] NEWS file is useless)
Richard Frith-Macdonald wrote: I think directly ~/GNUstep/Defaults/.GNUstepDefaults ? That's XML for me now and it wasn't. Oh, that's a hidden file for private use by the base library ... kind of surprising that anyone would notice, and certainly not something which should appear in news/release notes as it's internal information. Indeed, one shouldn't notice -- except that there was a bug in NSPropertyList.m, which did use an incorrect translation for ASCII control characters (it was using the old Java \U notation instead of numerical character encodings). Due to this bug the position of menus was no longer persistent. I've just committed a fix for this in svn and now torn-off menus will reappear again the next time you start an app. Wolfgang. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Notification centre and threads
Hi, I've noticed a couple of places in the GNUstep source where the NSNotificationCentre is cached the first time a class is created and then used by all instances. With the documented behaviour for the notification centre on OS X, this will do undefined things when the instance is not in the same thread as the one where the notification centre was created. Does GNUstep have some special logic for handling cross-thread notifications (and is this documented somewhere) or are all of these uses potential bugs? David -- Send from my Jacquard Loom ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Notification centre and threads
On 27 Nov 2009, at 17:22, David Chisnall wrote: Hi, I've noticed a couple of places in the GNUstep source where the NSNotificationCentre is cached the first time a class is created and then used by all instances. With the documented behaviour for the notification centre on OS X, this will do undefined things when the instance is not in the same thread as the one where the notification centre was created. Does GNUstep have some special logic for handling cross-thread notifications (and is this documented somewhere) or are all of these uses potential bugs? I'm not sure ... I think NSNotificationCenter is thread-safe in GNUstep ... what problems would that cause? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Notification centre and threads
On 27 Nov 2009, at 17:43, Richard Frith-Macdonald wrote: On 27 Nov 2009, at 17:22, David Chisnall wrote: Hi, I've noticed a couple of places in the GNUstep source where the NSNotificationCentre is cached the first time a class is created and then used by all instances. With the documented behaviour for the notification centre on OS X, this will do undefined things when the instance is not in the same thread as the one where the notification centre was created. Does GNUstep have some special logic for handling cross-thread notifications (and is this documented somewhere) or are all of these uses potential bugs? I'm not sure ... I think NSNotificationCenter is thread-safe in GNUstep ... what problems would that cause? I had a quick look at the current OSX documentation for the class, and I didn't see anything saying that it 'will do undefined things when the instance is not in the same thread as the one where the notification centre was created' ... what did I miss? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: XML GNUstep defaults (was: [flame] NEWS file is useless)
On 27 Nov 2009, at 18:28, Lars Sonchocky-Helldorf wrote: Am 27.11.2009 um 09:39 schrieb Richard Frith-Macdonald: On 26 Nov 2009, at 17:35, Wolfgang Lux wrote: Richard Frith-Macdonald wrote: I think directly ~/GNUstep/Defaults/.GNUstepDefaults ? That's XML for me now and it wasn't. Oh, that's a hidden file for private use by the base library ... kind of surprising that anyone would notice, and certainly not something which should appear in news/release notes as it's internal information. Indeed, one shouldn't notice -- except that there was a bug in NSPropertyList.m, which did use an incorrect translation for ASCII control characters (it was using the old Java \U notation instead of numerical character encodings). Due to this bug the position of menus was no longer persistent. I've just committed a fix for this in svn and now torn-off menus will reappear again the next time you start an app. I partially reverted that ... the code to generate the escape sequences was correct, the problem was a failure to parse them on reading the result back. The underlying issue is that certain characters are illegal in XML, even when encoded using the #...; syntax! The list of illegal characters includes ascii code 27 (escape), yet OSX uses the escape character as the key for the top-level menu. If you feed such data to a proper XML parser (such as libxml2), it will abort parsing when it encounters the illegal character. Isn't that a bug? No ... it's what the XML spec says. http://www.w3.org/TR/xml11/#sec-xml11 says that Finally, there is considerable demand to define a standard representation of arbitrary Unicode characters in XML documents. Therefore, XML 1.1 allows the use of character references to the control characters #x1 through #x1F, most of which are forbidden in XML 1.0. For reasons of robustness, however, these characters still cannot be used directly in documents. That's really interesting ... I didn't know that this was changed for XML 1.1 Or are xml-plists still based on XML 1.0? Yes ... they pre-date XML 1.1. Here's the header of a property list copied from my (snow-leopard) OSX system: ?xml version=1.0 encoding=UTF-8?!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd;plist version=1.0 If we assume that 'XML' property lists will never actually be processed by real XML parsers, we don't need the additional encoding. One never knows, maybe at one day somebody wants to write some sort of converter using XSLT. Locking out XML tools makes the whole idea of using XML for plists somewhat pointless Perhaps we can change to using XML 1.1 for our plists? rant I think the old or classic format is much better readable and less verbose - and nowadays after the XML hype people start using JSON ( http://en.wikipedia.org/wiki/JSON ) for formerly XMLish purposes which is a lot like the classic plist format. /rant Yes, the old plist is better in almost every way (addition of date, boolean, and numeric types were good extensions though). I just tried an experiment on OSX. I copied an existing OSX XML property list, edited it with vi, and set the xml version in the header to 1.1 rather than 1.0 I then opened it in the 'Property List Editor' application ... it opened perfectly well and I was able to make a small edit. I then saved it ... the saved output has the '1.0' version header again. So it looks like OSX can read XML 1.1 but still writes 1.0 If there's no problem with OSX reading it ... I see no real reason why we can't update our plist code to output XML version 1.1 rather than 1.0 ... the only worry then would be that older XML software, which didn't support version 1.1, might have trouble with it. That's probably acceptable. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: XML GNUstep defaults (was: [flame] NEWS file is useless)
Am 27.11.2009 um 20:36 schrieb Richard Frith-Macdonald: On 27 Nov 2009, at 18:28, Lars Sonchocky-Helldorf wrote: Am 27.11.2009 um 09:39 schrieb Richard Frith-Macdonald: On 26 Nov 2009, at 17:35, Wolfgang Lux wrote: Richard Frith-Macdonald wrote: I think directly ~/GNUstep/Defaults/.GNUstepDefaults ? That's XML for me now and it wasn't. Oh, that's a hidden file for private use by the base library ... kind of surprising that anyone would notice, and certainly not something which should appear in news/release notes as it's internal information. Indeed, one shouldn't notice -- except that there was a bug in NSPropertyList.m, which did use an incorrect translation for ASCII control characters (it was using the old Java \U notation instead of numerical character encodings). Due to this bug the position of menus was no longer persistent. I've just committed a fix for this in svn and now torn-off menus will reappear again the next time you start an app. I partially reverted that ... the code to generate the escape sequences was correct, the problem was a failure to parse them on reading the result back. The underlying issue is that certain characters are illegal in XML, even when encoded using the #...; syntax! The list of illegal characters includes ascii code 27 (escape), yet OSX uses the escape character as the key for the top-level menu. If you feed such data to a proper XML parser (such as libxml2), it will abort parsing when it encounters the illegal character. Isn't that a bug? No ... it's what the XML spec says. http://www.w3.org/TR/xml11/#sec-xml11 says that Finally, there is considerable demand to define a standard representation of arbitrary Unicode characters in XML documents. Therefore, XML 1.1 allows the use of character references to the control characters #x1 through #x1F, most of which are forbidden in XML 1.0. For reasons of robustness, however, these characters still cannot be used directly in documents. That's really interesting ... I didn't know that this was changed for XML 1.1 Or are xml-plists still based on XML 1.0? Yes ... they pre-date XML 1.1. Here's the header of a property list copied from my (snow-leopard) OSX system: ?xml version=1.0 encoding=UTF-8?!DOCTYPE plist PUBLIC -// Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/ PropertyList-1.0.dtdplist version=1.0 If we assume that 'XML' property lists will never actually be processed by real XML parsers, we don't need the additional encoding. One never knows, maybe at one day somebody wants to write some sort of converter using XSLT. Locking out XML tools makes the whole idea of using XML for plists somewhat pointless Perhaps we can change to using XML 1.1 for our plists? rant I think the old or classic format is much better readable and less verbose - and nowadays after the XML hype people start using JSON ( http://en.wikipedia.org/wiki/JSON ) for formerly XMLish purposes which is a lot like the classic plist format. /rant Yes, the old plist is better in almost every way (addition of date, boolean, and numeric types were good extensions though). I just tried an experiment on OSX. I copied an existing OSX XML property list, edited it with vi, and set the xml version in the header to 1.1 rather than 1.0 I then opened it in the 'Property List Editor' application ... it opened perfectly well and I was able to make a small edit. I then saved it ... the saved output has the '1.0' version header again. So it looks like OSX can read XML 1.1 but still writes 1.0 If there's no problem with OSX reading it ... I see no real reason why we can't update our plist code to output XML version 1.1 rather than 1.0 ... the only worry then would be that older XML software, which didn't support version 1.1, might have trouble with it. That's probably acceptable. Maybe we should file a bug with OS X on that by explaining them that they're writing invalid XML 1.0. A fix would be simple for Apple, I think there's nothing to stop them from fixing this. On what occasion does the ascii code 27 (escape) get written? Where can I find such an invalid XML? What do you think? regards, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: XML GNUstep defaults (was: [flame] NEWS file is useless)
On 27 Nov 2009, at 20:05, Lars Sonchocky-Helldorf wrote: Maybe we should file a bug with OS X on that by explaining them that they're writing invalid XML 1.0. I did that some years ago. Possibly they fixed it. A fix would be simple for Apple, I think there's nothing to stop them from fixing this. On what occasion does the ascii code 27 (escape) get written? Well, it used to get written as the key for the autosaved location of the main menu in OPENSTEP and Rhapsody (possibly early OSX) before they completely removed the ability to use vertical menus, and I think it's cropped up in some text NIB files, but I don't have an example. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
