Re: Scrub last - better patch....
Thanks ... looked OK and seemed to work (not break my existing code) so I applied it, though I don't have any testcases for what it's supposed to do. I've got some that I use for internal testing - but the most obvious is that you should now be able to read any valid UTF-8 sequence into a string and write it out again and get the same bytes. This was not ture before. It may also help the large cut-and-paste problem, though I need to update on my work machine to test that. BTW- I dont understand some of the GNUstep architecture that well. There are several implementations of rangeOfComposedCharaterSequenecAtIndex - how do I know which is used when ? I note that one of them appears not to use the isnonsp stuff, and thus I neeed to alter it and find a way to test it. A brief explanation would be much appreciated ! thanks for applying the patch BTW, -bat. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Scrub last - better patch....
On Wednesday, September 10, 2003, at 11:46 AM, Pete French wrote: BTW- I dont understand some of the GNUstep architecture that well. There are several implementations of rangeOfComposedCharaterSequenecAtIndex - how do I know which is used when ? I note that one of them appears not to use the isnonsp stuff, and thus I neeed to alter it and find a way to test it. A brief explanation would be much appreciated ! The one in NSString.m is used whenever anyone implements their own subclass of NSString. The ones in GSString.m are used for the private concrete subclasses dealing with unicode strings, unicode mutable strings, byte encoded strings and byte encoded mutable strings. Since the byte encoded strings cannot possible contain multibyte sequences, the implementation for that always returns the single character at the specified index. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Scrub last - better patch....
The one in NSString.m is used whenever anyone implements their own subclass of NSString. O.K., so I can test that by making an empty subclass of NSString then ? -bat. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Scrub last - better patch....
On Wednesday, September 10, 2003, at 12:34 PM, Pete French wrote: The one in NSString.m is used whenever anyone implements their own subclass of NSString. O.K., so I can test that by making an empty subclass of NSString then ? Unfortunately not quite that simple ... NSString is the semi-abstract interface of a class cluster ... it doesn't actually have any ivars to store data in ... so to subclass it, you need to add some ivars and implement a few primitive methods (-length and -characterAtIndex: and -initWithCharacters:length:freeWhenDone:) All the other methods should already be implemented in NSString.m in terms of those primitives. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Scrub last - better patch....
On Wednesday, September 10, 2003, at 01:01 PM, Pete French wrote: All the other methods should already be implemented in NSString.m in terms of those primitives. Are there any existing subclasses of NSString which use these methods Not that I know of. that I could use for testing, or is it best to actually make my own subclass for testing purposes ? Currently it sounds like these implementations are there just in case someone makes an NSString subclass rather than actually being used by any of the current code. Yes, it's a mix ... some of the NSString.m methods are re-implemented in concrete classes and others aren't (the most commonly used ones are generally reimplemented by subclasses for performance). ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Scrub last - better patch....
Hi Pete, just tired this with your favourit UTF-8 page and I was able to copy it from Mozilla over to Ink. Great now all that Unicode copying should be working. (Not that I ever wanted to copy that page anyway) Cheers Fred Richard Frith-Macdonald wrote: On Tuesday, September 9, 2003, at 10:41 PM, Pete French wrote: Sorry about this, please ignore the last UTF8/UTF16 patch, this one has a slight change which makes it better (but got missed in the original email). The addition is to consider the high word of the surrogate pairs as non-spacing. That is a very convenient way for the rest of the code which does not understand UTF-16 to look at it, as well as having a nice side effect of causing the rangeOfComposedCharacterSequenceAtIndex: method to functionas it does on OSX - i.e. give the range of the surrogate pair when applied to either of them individually. Thanks ... looked OK and seemed to work (not break my existing code) so I applied it, though I don't have any testcases for what it's supposed to do. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Scrub last - better patch....
This patch seems to have broken parts of the string handling. When I tried running the test suite today, it not only failed, it dumped core during the string tests. Our test suite isn't complete in any way, but it does cover a lot of things, and a fair amount of important stuff. I'd like to strongly suggest that it be run before committing changes (if not all, then at least for large changes, and periodically otherwise). Bugs that cause regressions are bugs that could have been easily avoided. - Alexander Malmberg ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Scrub last - better patch....
On Thursday, September 11, 2003, at 02:09 AM, Alexander Malmberg wrote: This patch seems to have broken parts of the string handling. When I tried running the test suite today, it not only failed, it dumped core during the string tests. I re-ran the tests and it was fine ... then I checked and found that I must have done a 'make debug=yes' rather than a 'make debug=yes install' to build the base library so the testsuite was picking up the old version of the library :-( Our test suite isn't complete in any way, but it does cover a lot of things, and a fair amount of important stuff. I'd like to strongly suggest that it be run before committing changes (if not all, then at least for large changes, and periodically otherwise). Bugs that cause regressions are bugs that could have been easily avoided. Yes ... and make sure that you are testing what you want to be testing! The current code in CVS passes the tests ... I spent a few hours going through and checking/fixing. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
