I get an error from
'Macintosh HD:Fun with 3.2:Squeak.15.gif' asURL
in Squeak as of #4795.
Michael produced a work-around so I could open this file, but presumably asURL should be fixed.
- Dan
Why should that work? Shouldn't that be of the form:
'file:/Macintosh HD/Fun with 3.2/Squeak.15.gif' asUrl
Or, perhaps some new construct:
'Macintosh HD:Fun with 3.2:Squeak.15.gif' asFilename asUrl (if Filename classes were implemented)
Or even: 'Macintosh HD:Fun with 3.2:Squeak.15.gif' asUrlFromFilename
- Stephen
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Dan Ingalls Sent: Thursday, March 07, 2002 12:26 AM To: squeak-dev@lists.squeakfoundation.org Subject: [BUG] String asURL fails
I get an error from
'Macintosh HD:Fun with 3.2:Squeak.15.gif' asURL
in Squeak as of #4795.
Michael produced a work-around so I could open this file, but presumably asURL should be fixed.
- Dan
Stephen & Dan:
This work's fine on my Mac: 'file:///PBG3/html/short.html' asUrl
It answers a FileURL with a path of: OrderedCollection('PBG3' 'html' 'short.html')
Don't forget that it takes THREE slashes, not the usual two.
Dave
At 0:49 -0500 3/7/02, Stephen Pair wrote:
Why should that work? Shouldn't that be of the form:
'file:/Macintosh HD/Fun with 3.2/Squeak.15.gif' asUrl
Or, perhaps some new construct:
'Macintosh HD:Fun with 3.2:Squeak.15.gif' asFilename asUrl (if Filename classes were implemented)
Or even: 'Macintosh HD:Fun with 3.2:Squeak.15.gif' asUrlFromFilename
- Stephen
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Dan Ingalls Sent: Thursday, March 07, 2002 12:26 AM To: squeak-dev@lists.squeakfoundation.org Subject: [BUG] String asURL fails
I get an error from
'Macintosh HD:Fun with 3.2:Squeak.15.gif' asURL
in Squeak as of #4795.
Michael produced a work-around so I could open this file, but presumably asURL should be fixed.
- Dan
"David N. Smith (IBM)" dnsmith@watson.ibm.com wrote:
Stephen & Dan:
This work's fine on my Mac: 'file:///PBG3/html/short.html' asUrl
It answers a FileURL with a path of: OrderedCollection('PBG3' 'html' 'short.html')
Don't forget that it takes THREE slashes, not the usual two.
Actually, in Squeak, it's either one slash or zero, depending on whether you want an absolute locator or a relative one. I'm not sure what is right, but this seems sensible.
-Lex
Dan Ingalls Dan@SqueakLand.org wrote:
I get an error from
'Macintosh HD:Fun with 3.2:Squeak.15.gif' asUrl
in Squeak as of #4795.
Michael produced a work-around so I could open this file, but presumably asURL should be fixed.
Okay, the attached changeset should do what you need. Instead of using #asUrl, you can then do this:
FileUrl fromFileName: 'Macintosh HD:Fun with 3.2:Squeak.15.gif'
I can't test on a Mac, but this changeset should at least be very close. You'll have to change the #asUrl to this new selector, but hopefully that's okay.
Anyone who wants to know more can read onward. But it's about the workings of the grodie World Wide Web. The innocent and the pure of heart may wish to stop here.
| | | | | | | | | | | |
purity maintenance space
| | | | | ||| | | | | || | |
Okay, the root issue is that this isn't a valid URL. (What? Yes, it's true. If this grosses you out already, then maybe you should have heeded the purity space.) The proper format would be:
'file:/Macintosh HD/Fun with 3.2/Squeak.15.gif'
(This must look really ugly to a Mac user.) Focus mind over stomache, and notice in particular that:
1. It begins with 'file:' .
2. It uses $/ instead of $: or $, regardless of the platform.
3. It starts an absolute path name with the $/ delimiter, even on a Mac.
One idea here is that this format works on all platforms. Thus, the U in URL, for "universal". Another idea is that the same format can be used for http, gopher, telnet, mail, or whatever else-- the initial 'file:' is a whole bunch of tag bits. URL's are actually a pretty decent idea. It's even been argued that URL's are the prettiest part of the WWW.... whoops, sorry, I said "pretty" and "WWW" in the same sentense. Approach this thought carefully, lest it overwhelm you with revolsion. There's no rush. Even the WWW can have one or two nice ide---whoops, sorry, I'll stop.
Now, some might be wondering why #asUrl doesn't just deal with all of this. Web browsers do it, right? And that thing is obviously a file for a Macintosh, right? The issue is that you can't always guess right. Here's a nasty example:
'win.com'
Is this the FILE named win.com in the current directory, or the HTTP server named win.com ? Either answer could be correct.
We don't have to guess. If we simply call a method like #asUrlFromFilename instead of just #asUrl, then the system will know it is a filename. The invoked method will be able to do the Right Thing in all cases, and there will be no ambiguity.
-Lex
PS -- it has been suggested before that Filename would be a good class to have around. It would certainly be useful here!
I can't test on a Mac, but this changeset should at least be very close. You'll have to change the #asUrl to this new selector, but hopefully that's okay.
I think this needs to go a step further. The construct:
FileUrl fromFileName: 'Macintosh HD:Fun with 3.2:Squeak.15.gif'
should work no matter what platform you are on, or alternatively you should be able to to be explicit about the platform (with the previous example parsing based on the current platform)...for example:
FileUrl fromMacFileName: 'Macintosh HD:Fun with 3.2:Squeak.15.gif'
There might be situations where you have to deal with a filename formatted for an OS that you don't happen to be using at the moment. I would propose the following methods:
fromFileName: - uses the delimiter for the current plaform fromFileName:usingDirectoryClass: - uses the specified FileDirectory class to parse the path fromMacFileName: - uses $: for the delimiter fromDosFileName: - uses $\ for the delimiter fromUnixFileName: - uses $/ for the delimiter ...etc...
Unfortunately, there are many methods that assume you want the local file name convention and directly use "FileDirectory pathNameDelimiter" or FileDirectory activeDirectoryClass. Also, shouldn't "MacFileDirectory on: 'Macintosh HD:Fun with 3.2:Squeak.15.gif'" give me an instance of a MacFileDirectory? It currently doesn't work unless you happen to be running on the mac plaform.
The attached change set implements these methods, and adds "FileDirectory class>>basicOn:", which gives you an instance of the receiver (not (necessarily) an instance "FileDirectory activeDirectoryClass"). FileDirectory class>>on: is refactored to use #basicOn:. So, no matter which platform you are running on, you have the ability take a path name for any platform and convert it to a Url.
- Stephen
"Stephen Pair" spair@advantive.com wrote:
I can't test on a Mac, but this changeset should at least be very close. You'll have to change the #asUrl to this new selector, but hopefully that's okay.
I think this needs to go a step further. The construct:
FileUrl fromFileName: 'Macintosh HD:Fun with 3.2:Squeak.15.gif'
should work no matter what platform you are on, or alternatively you should be able to to be explicit about the platform (with the previous example parsing based on the current platform)...for example:
FileUrl fromMacFileName: 'Macintosh HD:Fun with 3.2:Squeak.15.gif'
How about sticking it in the FileDirectory classes? Then you can customize an application by handing it the relevant FileDirectory subclass. Such a beast will also come along with other platform-specific name management tools like splitName:to:.
FileDirectory urlForFilename: blah FileDirectory urlForDirectoryName: blah
MacFileDirectory urlForFilename: blah
That is, vary the class, instead of the selector, to get different behaviors. In fact, if you implement the methods in class FileDirectory, you can probably get away with just one method for filenames and one method for directory names -- the methods will be implicitly customized by the particular subclass that was used!
Unfortunately, there are many methods that assume you want the local file name convention and directly use "FileDirectory pathNameDelimiter" or FileDirectory activeDirectoryClass.
Well, yes, that's true. I happen to think this is normal and correct, but I doubt we'll agree. I never have reason to process a windows or a MacOS or a RiscOS filename, and it's hard for me to imagine cases where I'd want to. Filenames are implicitly a local thing, IMHO.
Also, shouldn't "MacFileDirectory on: 'Macintosh HD:Fun with 3.2:Squeak.15.gif'" give me an instance of a MacFileDirectory? It currently doesn't work unless you happen to be running on the mac plaform.
Interesting. Whether this *should* work I don't know, because you can think of a FileDirectory object as *being* the directory, which is impossible except on a Macintosh. Still, it would be nice to have *some* way to manage filenames from a foreign OS....
-Lex
On Thursday 07 March 2002 08:40 am, Lex Spoon wrote:
Well, yes, that's true. I happen to think this is normal and correct, but I doubt we'll agree. I never have reason to process a windows or a MacOS or a RiscOS filename, and it's hard for me to imagine cases where I'd want to. Filenames are implicitly a local thing, IMHO.
Unless they're not local.
Any time you get filenames from an external source, you run into having to convert them. A case in point is the storage of filenames in Zip archives. They're all normalized to look like Unix filenames (forward slashes as separators). So you could treat them as Unix filenames and convert to local flavors as needed.
Every time you do this, you can lose information, of course. An example is when you have a Mac file whose name contains a '/' and you want to translate it for Unix or Win32. Or a Unix file named 'c:\xyz' and you want to translate for Mac or Win32.
The same issues come up with CVS, with tape backup, with building web sites, etc.
How about sticking it in the FileDirectory classes? Then you can customize an application by handing it the relevant FileDirectory subclass. Such a beast will also come along with other platform-specific name management tools like splitName:to:.
FileDirectory urlForFilename: blah FileDirectory urlForDirectoryName: blah
MacFileDirectory urlForFilename: blah
That is, vary the class, instead of the selector, to get different behaviors. In fact, if you implement the methods in class FileDirectory, you can probably get away with just one method for filenames and one method for directory names -- the methods will be implicitly customized by the particular subclass that was used!
Yep...that seems cleaner.
Well, yes, that's true. I happen to think this is normal and correct, but I doubt we'll agree. I never have reason to process a windows or a MacOS or a RiscOS filename, and it's hard for me to imagine cases where I'd want to. Filenames are implicitly a local thing, IMHO.
It's only normal and correct if you want to use the local file system convention. If you ever have a need to use a file name generated for a foreign file system, then you're out of luck with the way things are currently. Granted, it is a rare thing to need, but there's no reason not to support it. I wonder if the hierarchy would be better arranged as:
AbstractFileDirectory FileDirectory DosFileDirectory UnixFileDirectory AcornFileDirectory MacFileDirectory ...etc...
FileDirectory would just override a few key class methods to forward them on to the appropriate class for the current platform. No instances of FileDirectory would ever actually exist. This might make it easier for implementing class side methods such as #on: to do the thing you would expect.
"UnixFileDirectory on: '/etc'" would give you a Unix file directory no matter what platform you are currently running on. "FileDirectory on: '/etc'" would give you a file directory class for the current platform (which better be Unix). As it is now, you have to implement a #basicOn: method (as I did), or override #on: for every single subclass.
Also, shouldn't "MacFileDirectory on: 'Macintosh HD:Fun with
3.2:Squeak.15.gif'" give
me an instance of a MacFileDirectory? It currently doesn't work unless you happen to be running on the mac plaform.
Interesting. Whether this *should* work I don't know, because you can think of a FileDirectory object as *being* the directory, which is impossible except on a Macintosh. Still, it would be nice to have *some* way to manage filenames from a foreign OS....
Right...yet another reason to have a FileName class heirarchy for this stuff. FileDirectories would *be* the directory, and thus the specific subclass would only be useful on the platform they are designed for. Of course, if this were the case, we may find that only one FileDirectory class is needed, since the primitive interface should be the same for all platforms.
- Stephen
Stephen Pair wrote:
Right...yet another reason to have a FileName class heirarchy for this stuff. FileDirectories would *be* the directory, and thus the specific subclass would only be useful on the platform they are designed for. Of course, if this were the case, we may find that only one FileDirectory class is needed, since the primitive interface should be the same for all platforms.
I've spent quite some time (on and off (more off than on though :-( ) for the last couple of months) rewriting the directory and file handling stuff. I've been through a couple of versions and finally decided to try a rather radical approach by normalizing everything to URIs. So, within Squeak you will always deal with URIs and only have to convert those while crossing over to file system or remote server functions. At these points you always will know where a filename came from and can parse it according to the current platform's conventions. E.g., Mac filenames containing a / would be escaped according to the URI conventions. Most of the time is actually spent on figuring out all the "creative" uses of paths and FileDirectory. Scary stuff... ;-)
Michael
Michael Rueger m.rueger@acm.org is claimed by the authorities to have written:
I've spent quite some time (on and off (more off than on though :-( ) for the last couple of months) rewriting the directory and file handling stuff. I've been through a couple of versions and finally decided to try a rather radical approach by normalizing everything to URIs. So, within Squeak you will always deal with URIs and only have to convert those while crossing over to file system or remote server functions.
I do hope you've kept in touch with Craig about this - there is a great deal of potentially useful code from Interval to do all this stuff. I'd hate to see duplicated effort.
tim
Tim Rowledge wrote:
I do hope you've kept in touch with Craig about this - there is a great deal of potentially useful code from Interval to do all this stuff. I'd hate to see duplicated effort.
I made sure I stay above stream level, so Craig's IO and Stream refactoring would go nicely with this. It does though conflict with some (not all) of the Correspondents stuff, but uses some of the ideas :-) Let's just see where this experiment (and that's what it is in the current state) leads us...
Michael
squeak-dev@lists.squeakfoundation.org
-
Dan Ingalls -
David N. Smith (IBM) -
Lex Spoon -
Michael Rueger -
Ned Konz -
Stephen Pair -
Tim Rowledge