Joey Hess [Mon, 27 Jan 2025 20:55:07 +0000 (16:55 -0400)]
more OsPath conversion
keyFile has a nice improvement; since a Key is a ShortByteString, it can
be converted to an OsPath without needing the copy that was done before.
Unfortunately, fileKey has to convert from a ShortByteString to a
ByteString in order to use attoparsec, and then the results get
converted back to an OsPath, so there are now 2 copies.
Maybe attoparsec will eventually get a ShortByteString API,
see https://github.com/haskell/attoparsec/issues/225
Joey Hess [Mon, 27 Jan 2025 19:54:24 +0000 (15:54 -0400)]
optimise literalOsPath
Taking a ShortByteString and using OverloadedStrings should avoid it
being converted from a String.
The reason there is no IsString instance for OsPath is presumably the
bad behavior of IsString for ByteString on unicode btw. But
literalOsPath won't be used with unicode in git-annex.
luciusf [Sun, 26 Jan 2025 11:19:53 +0000 (11:19 +0000)]
rename bugs/rsyncurl_without___34____58____34___creates_local_folder_as_repo.mdwn to bugs/rsyncurl_without___34____58____34___creates_local_folder_as_remote.mdwn
Joey Hess [Sat, 25 Jan 2025 15:53:47 +0000 (11:53 -0400)]
OsPath conversion
Decent win in exportDirectories, since it operates on ShortByteString
end to end now without needing conversion. That made it worth
implementing an OsPath specific code path there.
And ExportLocation already being a ShortByteString is an good example of why
it's a good thing that OsPath uses that!
Joey Hess [Thu, 23 Jan 2025 15:07:29 +0000 (11:07 -0400)]
add System.FilePath to this conversion
It seems to make sense to convert both System.Directory and
System.FilePath uses to OsPath in one go. This will generally look like
replacing RawFilePath with OsPath in type signatures, and will be driven
by the now absolutely massive pile of compile errors.
Joey Hess [Wed, 22 Jan 2025 17:22:51 +0000 (13:22 -0400)]
simplify replaceFile using relatedTemplate
Now that truncateFilePath and relatedTemplate have both been optimised,
may as well use them in replaceFile, rather than the custom hack it
used.
Removed the windows-specific ifdef as well, because on Windows long
filepaths no longer really a problem, since ghc and git-annex use UNC
converted paths.
replaceFile no longer checks fileNameLengthLimit. That took a syscall,
and since we have an existing file, we know filenames of its length are
supported by the filesystem. Assuming that the withOtherTmp directory is
on the same filesystem as the file replaceFile is being called on, which
I believe it is.
Joey Hess [Wed, 22 Jan 2025 16:34:54 +0000 (12:34 -0400)]
optimize truncateFilePath
Often the filepath will be all ascii, or mostly so, and this
optimisation makes a file that has an ascii suffix of sufficient length
be roundtrip converted between String and ByteString only once, rather
than once per character.
Joey Hess [Tue, 21 Jan 2025 21:00:37 +0000 (17:00 -0400)]
use openTempFile from file-io
And follow-on changes.
Note that relatedTemplate was changed to operate on a RawFilePath, and
so when it counts the length, it is now the number of bytes, not the
number of code points. This will just make it truncate shorter strings
in some cases, the truncation is still unicode aware.
When not building with the OsPath flag, toOsPath . fromRawFilePath and
fromRawFilePath . fromOsPath do extra conversions back and forth between
String and ByteString. That overhead could be avoided, but that's the
non-optimised build mode, so didn't bother.
Joey Hess [Mon, 20 Jan 2025 22:03:26 +0000 (18:03 -0400)]
RawFilePath conversion of System.Directory
By using System.Directory.OsPath, which takes and returns OsString,
which is a ShortByteString. So, things like dirContents currently have the
overhead of copying that to a ByteString, but that should be less than
the overhead of using Strings which often in turn were converted to
RawFilePaths.
Added Utility.OsString and the OsString build flag. That flag is turned
on in the stack.yaml, and will be turned on automatically by cabal when
built with new enough libraries. The stack.yaml change is a bit ugly,
and that could be reverted for now if it causes any problems.
Note that Utility.OsString.toOsString on windows is avoiding only a
check of encoding that is documented as being unlikely to fail. I don't
think it can fail in git-annex; if it could, git-annex didn't contain
such an encoding check before, so at worst that should be a wash.
projects / git-annex.git / log