On Thu, Jun 17, 2010 at 8:11 AM, Mark Evenson evenson@panix.com wrote:
On 6/15/10 2:05 PM, Alessio Stalla wrote:
[…]
Eliminating the problem in the general case is harder and we'd better discuss the possible solutions. Here's my take at it:
- don't fix it. State clearly that literal pathnames in source are
OS-dependent.
- keep, for each pathname constructed via #P or parse-namestring, the
string passed by the user, until the pathname is destructively modified. When dumping it, use that string if available, else warn and use a calculated string.
I still don't understand how this approach solves the problem with ASDF. Wouldn't we still have the failure on non-Windows when "\foo\bar" is passed to the #P reader? Namely, that it would be interpreted as:
{ directory: nil, name: "\foo\bar" }
What is the point of the "destructively modified" condition?
- dump-object for pathnames outputs a MAKE-PATHNAME form that
reconstructs the pathname component by component.
I was thinking about
- Code a heuristic in the Pathname.init(String) that attempts to
interpret a Pathname from the other platform by converting all '' to '/'. Add something
a) If the Pathname begins with '\' i) if win interpret as UNC server ii) non-win signal a CONDITION
b) convert all '' to '/'
c) run the rest of the current init()
On win, the init() code (line 403++) will convert the '' back to '/'.
A problem arises for non-win Pathnames that contain true '' characters in a directory/file name, which then will have no pathname<-->namestring roundtripping. It should still be possible to construct such shaggy monsters via MAKE-PATHNAME.
As for load forms, I think simply marking the namestring as "transient" (i.e. not persisting it) will do the right thing as on first access it will be re-computed to the proper local conventions.
This still doesn't completely address the presence of win-specific Pathname components (HOST with a UNC server, DEVICE with a single character string [A-Z]) in non-win. Signal a CONDITION when this is detected?
N.B. All the above written without benefit of testing with ABCL, as my wrist still precludes heavy use of Emacs.
Yesterday Erik and I discussed this on IRC and we came up with a possible solution.
Fact 1: the problem is only related to how pathnames are printed/serialized. Find a way to print them in a platform independent way (one which ABCL can read back, of course) and the problem is solved.
Fact 2: the string representation of pathnames is completely implementation-dependent.
Fact 3: pathnames already can (and sometimes do) print themselves as a property list enumerating the components, for example #P(:name "foo" :directory (:absolute "bar" "baz")) - which is not ANSI compatible, by the way.
Proposed solution: let's invent an ABCL-specific way to print arbitrary pathnames. I proposed #P"abcl:(make-pathname ...)" which is ANSI-compatible and similar enough to what the current code in Pathname.writeToString can produce. Let's use that to print pathnames[1]. Reading them back is as simple as (eval (read-from-string ...)), and no other code needs to be modified.
What do you think?
[1] if not always, at least with dump-form, and when *print-readably* is T and the namestring can't be used. In the latter case currently the #P(...) syntax is used. Btw, probably dump-form *should* bind *print-readably* to T...
Alessio