summaryrefslogtreecommitdiff
path: root/Utility/Misc.hs
Commit message (Collapse)AuthorAge
* implement massReplaceGravatar Joey Hess2013-04-08
| | | | | | This looks at the string one char at a time, which is hardly efficient.. but more than good enough for expanding variables in relatively short command lines.
* finished where indentation changesGravatar Joey Hess2012-12-13
|
* better fix for zombie problem, which turns out to be a zombie ssh started by ↵Gravatar Joey Hess2012-10-17
| | | | | | | | | | | | | | | | | | | | | rsync When rsyncProgress pipes rsync's stdout, this turns out to cause a ssh process started by rsync to be left behind as a zombie. I don't know why, but my recent zombie reaping cleanup was correct, it's just that this other zombie, that's not directly started by git-annex, was no longer reaped due to changes in the cleanup. Make rsyncProgress reap the zombie started by rsync, as a workaround. FWIW, the process tree looks like this. It seems like the rsync child is for some reason starting but not waiting on this extra ssh process. Ssh connection caching may be involved -- disabling it seemed to change the shape of the tree, but did not eliminate the zombie. 9378 pts/14 S+ 0:00 | \_ rsync -p --progress --inplace -4 -e 'ssh' '-S' ... 9379 pts/14 S+ 0:00 | | \_ ssh ... 9380 pts/14 S+ 0:00 | | \_ rsync -p --progress --inplace -4 -e 'ssh' '-S' ... 9381 pts/14 Z+ 0:00 | \_ [ssh] <defunct>
* Bug fix: A recent change caused git-annex-shell to crash.Gravatar Joey Hess2012-10-15
|
* added preferred-content log, and allow editing it with vicfgGravatar Joey Hess2012-10-04
| | | | | | | | | | | | | | This includes a full parser for the boolean expressions in the log, that compiles them into Matchers. Those matchers are not used yet. A complication is that matching against an expression should never crash git-annex with an error. Instead, vicfg checks that the expressions parse. If a bad expression (or an expression understood by some future git-annex version) gets into the log, it'll be ignored. Most of the code in Limit couldn't fail anyway, but I did have to make limitCopies check its parameter first, and return an error if it's bad, rather than erroring at runtime.
* optimised rsync output reader to read whole blocks at a timeGravatar Joey Hess2012-09-20
|
* better ordering of alertsGravatar Joey Hess2012-07-29
|
* add debuggingGravatar Joey Hess2012-07-17
|
* add fields to git-annex-shellGravatar Joey Hess2012-07-02
|
* factor out Utility.FileSystemEncodingGravatar Joey Hess2012-03-09
|
* Merge branch 'master' into ghc7.4Gravatar Joey Hess2012-02-03
|\ | | | | | | | | Conflicts: Utility/Misc.hs
| * IO exception reworkGravatar Joey Hess2012-02-03
| | | | | | | | | | | | ghc 7.4 comaplains about use of System.IO.Error to catch exceptions. Ok, use Control.Exception, with variants specialized to only catch IO exceptions.
* | support all filename encodings with ghc 7.4Gravatar Joey Hess2012-02-03
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under ghc 7.4, this seems to be able to handle all filename encodings again. Including filename encodings that do not match the LANG setting. I think this will not work with earlier versions of ghc, it uses some ghc internals. Turns out that ghc 7.4 has a special filesystem encoding that it uses when reading/writing filenames (as FilePaths). This encoding is documented to allow "arbitrary undecodable bytes to be round-tripped through it". So, to get FilePaths from eg, git ls-files, set the Handle that is reading from git to use this encoding. Then things basically just work. However, I have not found a way to make Text read using this encoding. Text really does assume unicode. So I had to switch back to using String when reading/writing data to git. Which is a pity, because it's some percent slower, but at least it works. Note that stdout and stderr also have to be set to this encoding, or printing out filenames that contain undecodable bytes causes a crash. IMHO this is a misfeature in ghc, that the user can pass you a filename, which you can readFile, etc, but that default, putStr of filename may cause a crash! Git.CheckAttr gave me special trouble, because the filenames I got back from git, after feeding them in, had further encoding breakage. Rather than try to deal with that, I just zip up the input filenames with the attributes. Which must be returned in the same order queried for this to work. Also of note is an apparent GHC bug I worked around in Git.CheckAttr. It used to forkProcess and feed git from the child process. Unfortunatly, after this forkProcess, accessing the `files` variable from the parent returns []. Not the value that was passed into the function. This screams of a bad bug, that's clobbering a variable, but for now I just avoid forkProcess there to work around it. That forkProcess was itself only added because of a ghc bug, #624389. I've confirmed that the test case for that bug doesn't reproduce it with ghc 7.4. So that's ok, except for the new ghc bug I have not isolated and reported. Why does this simple bit of code magnet the ghc bugs? :) Also, the symlink touching code is currently broken, when used on utf-8 filenames in a non-utf-8 locale, or probably on any filename containing undecodable bytes, and I temporarily commented it out.
* typoGravatar Joey Hess2012-01-20
|
* moveGravatar Joey Hess2011-12-15
|
* cleanupGravatar Joey Hess2011-12-12
|
* some work on avoiding partial functionsGravatar Joey Hess2011-12-09
| | | | | There are still hundreds of places that use partial functions head, tail, init, and last.
* factored out some useful error catching methodsGravatar Joey Hess2011-11-10
|
* indentGravatar Joey Hess2011-11-07
|
* playing with >=>Gravatar Joey Hess2011-10-31
| | | | | Apparently in haskell if you teach a man to fish, he'll write more pointfree code.
* broke up UtilityGravatar Joey Hess2011-10-16