Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
On May 6, 2005, at 10:10 PM, Markus Hitter wrote: P.S.: All the methods handling C strings are in the depreceated section now. That is not quite true, actually many of them are replaced by methods taking an encoding parameter in addition. E.g. cString becomes cStringUsingEncoding: and so on. -Phil -- Philippe C.D. Robert http://www.nice.ch/~phip/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
Philippe C.D. Robert wrote: On May 6, 2005, at 10:10 PM, Markus Hitter wrote: P.S.: All the methods handling C strings are in the depreceated section now. That is not quite true, actually many of them are replaced by methods taking an encoding parameter in addition. E.g. cString becomes cStringUsingEncoding: and so on. That is right. As I see it, they are rightly trying to move things forward for better internationalisation. If you use a C string it needs to have a specific encoding. Relying on a "default" encoding and using a C string isn't a good idea. In the modern unix world you are much better off using UTF8 strings. In the modern windows world it should all be UTF16 I'm working on string methods now as part of my path & win32 effort, if anyone is interested. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
On 8. Mai 2005, at 04:00 Uhr, Sheldon Gill wrote: P.S.: All the methods handling C strings are in the depreceated section now. How disappointing! :-| I suppose it was dropped because people did not understand what it is doing / good for and misused the methods (pretty similiar to - fileSystemRepresentationWithPath: which is seldom used). That is not quite true, actually many of them are replaced by methods taking an encoding parameter in addition. E.g. cString becomes cStringUsingEncoding: and so on. Thats not the same. The -initWithCString: per definition takes strings in the system encoding, so if you are getting a value from a standard C-API (say readlink()) you now need to do: s = [NSString stringWithCString:buf encoding:[NSString defaultCStringEncoding]]; which obviously is a major inconvenience (and slowdown!) when interfacing with C. That is right. As I see it, they are rightly trying to move things forward for better internationalisation. I wonder how this is supposed to improve internationalization. A pretty good optimization which had _no_ drawback wrt internationalization was dropped in favor to a method which will hardly get used in practice. Instead they could have used their energy to add Cocoa API for supporting arbitary encodings without resorting to CoreFoundation. _That_ would have been an improvement for internationalization. Relying on a "default" encoding and using a C string isn't a good idea. Why not? This way its guaranteed to match. The "default" encoding is the encoding configured in your Unix environment. You know, modern Unix _has_ proper support for localization (see LANG, LC_xxx etc)? In the modern unix world you are much better off using UTF8 strings. In the modern windows world it should all be UTF16 Hm, yes? This is why UTF-8 or UTF-16 might be the default C-String encoding if this is the case. This is what -initWithCString: aka defaultCStringEncoding is made for! If your Unix does UTF-8, you just switch the default encoding and everything works instantly. Also your point doesn't apply since we already have - initWithUTF8String: (every C API which doesn't use the system encoding most likely uses UTF-8 on Unix) and -initWithCharacters:. So dropping -initWithCString: gains you nothing here. Oh well, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
Helge Hess wrote: How disappointing! :-| Yes, it is rather. I suppose it was dropped because people did not understand what it is doing / good for and misused the methods (pretty similiar to - fileSystemRepresentationWithPath: which is seldom used). I'm sure that has a lot to do with it. There isn't anything in the on-line documentation so far which would point to reasons. It could also be a prelude for newer APIs which rely on UTF16. That is not quite true, actually many of them are replaced by methods taking an encoding parameter in addition. E.g. cString becomes cStringUsingEncoding: and so on. Thats not the same. The -initWithCString: per definition takes strings in the system encoding, so if you are getting a value from a standard C-API (say readlink()) you now need to do: s = [NSString stringWithCString:buf encoding:[NSString defaultCStringEncoding]]; which obviously is a major inconvenience (and slowdown!) when interfacing with C. Yes, except on MacOS-X you'd go s = [NSString stringWithUTF8String: buf]; which is an easy update from s = [NSString stringWithCString: buf]; so for it isn't a significant inconvenience. As for slowdown, I'm not sure that Cocoa doesn't now call down to specify the encoding anyway. I'd also say that a Cocoa application should never call readlink() anyway. It's supposed to resolveSymLinksInPath ;) That is right. As I see it, they are rightly trying to move things forward for better internationalisation. I wonder how this is supposed to improve internationalization. A pretty good optimization which had _no_ drawback wrt internationalization was dropped in favor to a method which will hardly get used in practice. See above. I think you're right and encoding: will not be used very much. I'm sure this is what Apple wants. Instead they could have used their energy to add Cocoa API for supporting arbitary encodings without resorting to CoreFoundation. _That_ would have been an improvement for internationalization. Absolutely. It seems a very simple thing to do as well. Actually, a lot of the revisions are IMO half-way. Where there is a reasonable CF way they often point and that instead. Worse-is-better Relying on a "default" encoding and using a C string isn't a good idea. Why not? This way its guaranteed to match. The "default" encoding is the encoding configured in your Unix environment. You know, modern Unix _has_ proper support for localization (see LANG, LC_xxx etc)? I know. I can similarly argue that the "default" encoding is always UTF8 so just go with that. The real problem I see with relying on the "default" encoding is when moving from machine to machine. In the modern unix world you are much better off using UTF8 strings. In the modern windows world it should all be UTF16 Hm, yes? This is why UTF-8 or UTF-16 might be the default C-String encoding if this is the case. This is what -initWithCString: aka defaultCStringEncoding is made for! If your Unix does UTF-8, you just switch the default encoding and everything works instantly. You're forgetting. This is Cocoa and there is no your Unix and mine. There is only MacOS-X. Also your point doesn't apply since we already have - initWithUTF8String: (every C API which doesn't use the system encoding most likely uses UTF-8 on Unix) and -initWithCharacters:. So dropping -initWithCString: gains you nothing here. I do get your point. I think the rationale has more to do with social/human factors and technical merits. Oh well, Exactly. I'm trying to defend Apples decision so much as interpret it. I've come to the opinion that it isn't entirely without merit. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
On 2005-05-08 03:00:37 +0100 Sheldon Gill <[EMAIL PROTECTED]> wrote: I'm working on string methods now as part of my path & win32 effort, if anyone is interested. I'd be interested in knowing what exactly as I have a load of uncommitted windows path changes on my system (I was waiting for feedback on the last tranch of changes), and I'm also occasionally updating bits and pieces to match MacOS-X API. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
I'm working on string methods now as part of my path & win32 effort, if
anyone is interested.
I'd be interested in knowing what exactly as I have a load of
uncommitted windows path changes on my system (I was waiting for
feedback on the last tranch of changes), and I'm also occasionally
updating bits and pieces to match MacOS-X API.
Hmm...
In no particular order and off the top of my head:
* NSHomeDirectoryForUser() now finds other users on Win32
* Additional directory keys for NSSearchPath() including
all the new Tiger keys.
* GSSearchPath() for porting/compatibility
* New implemenation of SearchPathForDirectories; O(1)
Very much faster and more readily extensible
* Paths from registry in Win32 for mingw32 native
* standardised, improved way to determine win32 IsExecutableFile
* hide/show extensions on win32 in sync with Explorer
* Flexibilty improvements in FS layout for platform-specific packaging
Better PLATFORM_SUPPORT. {stuff I was mentioning to Helge}
* Some string methods do better argument checking and/or raise an
exception when invalid/nil
* Documentation for all this and more
Still progressing
* Path handling fixes in the rest of base and gui: where we have
assumptions about layout which are no longer valid or where
the code can be cleaned up
* More and better use of Unicode and Win32 api. We should be
using either Step or native methods as far as possible to
improve behaviour. This will be ongoing for a while...
* Framework support on win32. With my _find_framework() in NSBundle we
can now properly locate the framework directory and so know exactly
where the DLL is. We can load it explicitly when needed.
Its a case now of linking and symbol resolution.
A ways off (because of time)
* Remove PathHandling mode
I'm quite concerned about PathHandling mode and want to remove it. I
don't think it's necessary and adds more confusion and complexity.
Currently, it's a global variable. The mode could be changed by a
loadable bundle without the application code being aware of it.
Hence, code can be expecting to run in one mode and be invoked when it's
different.
Further, it could be changed in one thread and mess up the processing in
a different thread which happens to be executing at that time.
Under this scheme, to write safe code you need to
1 check what the current mode is and remember it
2 set it to what you expect
3 process
4 set it back to what it was so you don't confuse other things
5 pray no other thread is changes mode under you
I understand the concerns which lead to implementing the mode but I
really think it isn't needed and adds more complexity than it solves.
* review and recommendations for NSString & NSFileManager
I've argued that we don't need Local<->OpenStep conversion generally
We also don't need the special ~drive and [EMAIL PROTECTED] notations. For
starters, though I find it bizarre I have come across accounts with user
name eg 'a'. Anyway, we don't need the ~ encodings.
I'm working on demonstration code to remove these by defining clear path
handling semantics which are appropriate for *nix and for win32 without
confusing either.
Current behaviour can be apparently inconsistent and confusing:
Path string for test is /./Development
Standardised '/./Development'
FileSystem rep'\.\Development'
OSFromLocal gives '/./Development'
Path string for test is F:/./Development
Standardised 'F:/./Development'
FileSystem rep'F:\.\Development'
OSFromLocal gives '~F//./Development'
Path string for test is F:\.\Development
Standardised 'F:/./Development'
FileSystem rep'F:\.\Development'
OSFromLocal gives '~F/Development'
Path string for test is F:\\.\Development
Standardised 'F://Development'
FileSystem rep'F:\\Development'
OSFromLocal gives '~F/Development'
Path string for test is F://./Development
Standardised 'F://Development'
FileSystem rep'F:\\Development'
OSFromLocal gives '~F///./Development'
* string optimisations for the Win32 API where buffers are used
extensively. Initial testing suggests significant savings are possible
but I want to investigate further.
I'm sorry if this was a little terse but I'm pressed for time right now.
Off to see clients...
Regards,
Sheldon
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
On 2005-05-10 01:07:00 +0100 Sheldon Gill <[EMAIL PROTECTED]> wrote:
I'm working on string methods now as part of my path & win32 effort, if
anyone is interested.
I'd be interested in knowing what exactly as I have a load of
uncommitted windows path changes on my system (I was waiting for feedback
on the last tranch of changes), and I'm also occasionally updating bits
and
pieces to match MacOS-X API.
Hmm...
In no particular order and off the top of my head:
* NSHomeDirectoryForUser() now finds other users on Win32
* Additional directory keys for NSSearchPath() including
all the new Tiger keys.
* GSSearchPath() for porting/compatibility
* New implemenation of SearchPathForDirectories; O(1)
Very much faster and more readily extensible
* Paths from registry in Win32 for mingw32 native
* standardised, improved way to determine win32 IsExecutableFile
* hide/show extensions on win32 in sync with Explorer
* Flexibilty improvements in FS layout for platform-specific packaging
Better PLATFORM_SUPPORT. {stuff I was mentioning to Helge}
* Some string methods do better argument checking and/or raise an
exception when invalid/nil
* Documentation for all this and more
Wow ... that's a lot of changes.
Still progressing
* Path handling fixes in the rest of base and gui: where we have
assumptions about layout which are no longer valid or where
the code can be cleaned up
* More and better use of Unicode and Win32 api. We should be
using either Step or native methods as far as possible to
improve behaviour. This will be ongoing for a while...
* Framework support on win32. With my _find_framework() in NSBundle we
can now properly locate the framework directory and so know exactly
where the DLL is. We can load it explicitly when needed.
Its a case now of linking and symbol resolution.
A ways off (because of time)
Please could you submit individual patches for each of these dozen or more
changes?
If we get individual patches over a space of time as they are developed, we
can integrate them into GNUstep promptly ... which is definitely not the
case if we get a few large patches at once. Larger and more complex patches
take a long time to review, and have to wait for people to have that time
available ... which can mean that improvements which could have been
immediate take many months (perhaps so long that they become
irrelevant/unusable) to become available.
* Remove PathHandling mode
I'm quite concerned about PathHandling mode and want to remove it. I
don't think it's necessary and adds more confusion and complexity.
As you know, we had much discussion about path handling, and there was
definitely no consensus ... so the current code is a compromise allowing the
various viewpoints to be more or less satisfied, and switching of modes
during runtime was purely for testing that. I think the aim is to move to
the 'do the right thing' mode once people are generally happy (though
perhaps mode control on process startup using an environment variable will
be supported).
Currently, it's a global variable. The mode could be changed by a
loadable bundle without the application code being aware of it.
Hence, code can be expecting to run in one mode and be invoked when it's
different.
Further, it could be changed in one thread and mess up the processing in
a different thread which happens to be executing at that time.
It's a non-issue, switching is there for testing purposes and real programs
don't do it.
Once we are out of testing, programmatic switching of modes can be removed
(unless people want to keep it for some reason).
* review and recommendations for NSString & NSFileManager
I've argued that we don't need Local<->OpenStep conversion generally
We also don't need the special ~drive and [EMAIL PROTECTED] notations. For
starters, though I find it bizarre I have come across accounts with user
name eg 'a'. Anyway, we don't need the ~ encodings.
I'm working on demonstration code to remove these by defining clear path
handling semantics which are appropriate for *nix and for win32 without
confusing either.
I've already done that ...
That's why I wanted to know what you were doing :-)
* string optimisations for the Win32 API where buffers are used
extensively. Initial testing suggests significant savings are possible but
I
want to investigate further.
Sounds good.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
Richard Frith-Macdonald wrote: > On 2005-05-10 01:07:00 +0100 Sheldon Gill <[EMAIL PROTECTED]> wrote: > >> * Remove PathHandling mode >> >> I'm quite concerned about PathHandling mode and want to remove it. I >> don't think it's necessary and adds more confusion and complexity. > > > As you know, we had much discussion about path handling, and there was > definitely no consensus ... so the current code is a compromise allowing > the various viewpoints to be more or less satisfied, and switching of > modes during runtime was purely for testing that. I think the aim is to > move to the 'do the right thing' mode once people are generally happy > (though perhaps mode control on process startup using an environment > variable will be supported). > Indeed, please don't remove this yet. We (or rather I) haven't had time to change our code to use/test this yet. If there is a pressing reason that we need to decide on one or the other I can try to juggle priorities but that could still mean a few weeks from now. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
I'm working on string methods now as part of my path & win32 effort,
if anyone is interested.
I'd be interested in knowing what exactly as I have a load of
uncommitted windows path changes on my system (I was waiting for
feedback on the last tranch of changes), and I'm also occasionally
updating bits and pieces to match MacOS-X API.
Hmm...
In no particular order and off the top of my head:
* NSHomeDirectoryForUser() now finds other users on Win32
* Additional directory keys for NSSearchPath() including
all the new Tiger keys.
* GSSearchPath() for porting/compatibility
* New implemenation of SearchPathForDirectories; O(1)
Very much faster and more readily extensible
* Paths from registry in Win32 for mingw32 native
* standardised, improved way to determine win32 IsExecutableFile
* hide/show extensions on win32 in sync with Explorer
* Flexibilty improvements in FS layout for platform-specific packaging
Better PLATFORM_SUPPORT. {stuff I was mentioning to Helge}
* Some string methods do better argument checking and/or raise an
exception when invalid/nil
* Documentation for all this and more
Wow ... that's a lot of changes.
That's actually quite well contained, really. There is more of my
NSPathUtilities bit and a few more Win32 support routines. {Strings
excepted}
I found the new Tiger dirs to be amusing. I had to drop my
GSCacheDirectory and GSDesktopDirectory keys...
IsExecutable and show/hide extensions are pretty trivial NSFileManager
based on that.
I've also a rev for NSTimeZone which fixes some Win32 strangeness,
cleans a little code and provides for more flexible packaging but I
thought this was a little outside of this discussion. Again, it needs
the Win32 support improvements.
So I was thinking it'd be a reasonably straight-forward commit but there
is the binary compatibility break we're heading to, which is the right
time to do this.
* Remove PathHandling mode
I'm quite concerned about PathHandling mode and want to remove it. I
don't think it's necessary and adds more confusion and complexity.
As you know, we had much discussion about path handling, and there was
definitely no consensus ... so the current code is a compromise allowing
the various viewpoints to be more or less satisfied, and switching of
modes during runtime was purely for testing that. I think the aim is to
move to the 'do the right thing' mode once people are generally happy
(though perhaps mode control on process startup using an environment
variable will be supported).
In my view there should be one and only one mode. Well defined behaviour
that can be relied on.
The current behaviour of 'do the right thing' doesn't, in my view, do
the right thing and gives rise to some quite strange results on win32.
* review and recommendations for NSString & NSFileManager
I've argued that we don't need Local<->OpenStep conversion generally
We also don't need the special ~drive and [EMAIL PROTECTED] notations. For
starters, though I find it bizarre I have come across accounts with user
name eg 'a'. Anyway, we don't need the ~ encodings.
I'm working on demonstration code to remove these by defining clear path
handling semantics which are appropriate for *nix and for win32 without
confusing either.
I've already done that ...
That's why I wanted to know what you were doing :-)
I thought you might have. That's why I issued the invitation to ask ;)
Does this use the current path handling mode semantics?
* string optimisations for the Win32 API where buffers are used
extensively. Initial testing suggests significant savings are possible
but I want to investigate further.
Sounds good.
Yes and people will be happy that things are faster. I'm not sure
they'll like delving into the code, though. I'm taking GStr here.
Regards,
Sheldon
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
On 2005-05-10 10:01:03 +0100 Sheldon Gill <[EMAIL PROTECTED]> wrote:
Wow ... that's a lot of changes.
That's actually quite well contained, really. There is more of my
NSPathUtilities bit and a few more Win32 support routines. {Strings
excepted}
I found the new Tiger dirs to be amusing. I had to drop my GSCacheDirectory
and GSDesktopDirectory keys...
IsExecutable and show/hide extensions are pretty trivial NSFileManager
based
on that.
I've also a rev for NSTimeZone which fixes some Win32 strangeness, cleans a
little code and provides for more flexible packaging but I thought this was
a
little outside of this discussion. Again, it needs the Win32 support
improvements.
So I was thinking it'd be a reasonably straight-forward commit
I'd still like to see patches little and often ... it's amazing how often
something that seems simple to its author looks complex to others. If a
reviewer has ten minutes free, s/he can probably handle a patch of a few
lines in a single file ...
but there is
the binary compatibility break we're heading to, which is the right time to
do this.
I'm not sure ... Adam is the one to say when we want to make compatibility
breaks.
* Remove PathHandling mode
I'm quite concerned about PathHandling mode and want to remove it. I
don't think it's necessary and adds more confusion and complexity.
As you know, we had much discussion about path handling, and there was
definitely no consensus ... so the current code is a compromise allowing
the various viewpoints to be more or less satisfied, and switching of
modes
during runtime was purely for testing that. I think the aim is to move to
the 'do the right thing' mode once people are generally happy (though
perhaps mode control on process startup using an environment variable will
be supported).
In my view there should be one and only one mode. Well defined behaviour
that can be relied on.
Each mode can have well defined behavior which can be relied upon ... so
it's not a disaster if people can't agree on what mode they like.
The current behaviour of 'do the right thing' doesn't, in my view, do the
right thing and gives rise to some quite strange results on win32.
Well, the behavior is (barring unreported bugs) what all respondents said
should happen, and I explicitly asked for feedback when I put it in place
for testing. As far as I can tell from extensive reading of other
documentation on path handling, it should also be pretty much expected
behavior (ie like Perl, TCL and Java documentation says).
What are the specific strange results on win32? Example/test code would be
welcome.
Does this use the current path handling mode semantics?
Yes.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
On May 10, 2005, at 3:25 AM, Richard Frith-Macdonald wrote: I'm not sure ... Adam is the one to say when we want to make compatibility breaks. The next release of all the core libraries will be binary incompatible. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
