[m-rev.] for review and benchmarking: speed up file name creation in write_deps_file.m
Zoltan Somogyi
zoltan.somogyi at runbox.com
Fri Sep 8 19:15:22 AEST 2023
On 2023-09-08 17:50 +10:00 AEST, "Julien Fischer" <jfischer at opturion.com> wrote:
>
> On Fri, 8 Sep 2023, Zoltan Somogyi wrote:
>
>> On 2023-09-08 16:44 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
>>> Making dir./ more understandable is good, but it's not about mangling.
>>> >> dir./ tries to return a valid path for a given FileName relative to a
>>> starting point of DirName. If FileName itself is an absolute path
>>> (or a drive-relative path), it's not obvious what the result should be,
>>> so dir./ throws an exception. You can't mangle an absolute path into a
>>> relative path.
>>> >> The other thing dir./ does is produce a normalised path, in that the
>>> result path uses the standard separator for the platform, and does not
>>> include redundant directory separators. (I had thought it might attempt
>>> to do something with "." or ".." components but it does not.)
>>
>> This "other thing" is what I was referring to by "mangling". Sloppy usage, I know.
>>
>> I like the term "normalised"; it is (in this case) a synonym for "canonicalised",
>> but shorter. We should include it in the name of any test predicate.
>>
>> There is something I don't understand about cygwin's use of directory separators.
>> (I pretty much know nothing about cygwin in general, by design.) The comments
>> say that cygwin distinguishes between // and \\ as the root directories of two
>> different systems, but does it distinguish between / and \ in any other contexts?
>
> According to documentation, there is a distinction as to whether a path
> is treated as a Windows or or POSIX path.
>
> See: <https://cygwin.com/cygwin-ug-net/using.html#using-pathnames.
Reading that page, I can only say one thing: I am sorry I asked :-(
This kind of thing is *exactly* why I don't want to learn how to program
for Windows.
Zoltan.
More information about the reviews
mailing list