| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
catching exceptions.
As seen in this bug report, the lifted exception handling using the StateT
monad throws away state changes when an action throws an exception.
http://git-annex.branchable.com/bugs/git_annex_fork_bombs_on_gpg_file/
.. Which can result in cached values being redundantly calculated, or other
possibly worse bugs when the annex state gets out of sync with reality.
This switches from a StateT AnnexState to a ReaderT (MVar AnnexState).
All changes to the state go via the MVar. So when an Annex action is
running inside an exception handler, and it makes some changes, they
immediately go into affect in the MVar. If it then throws an exception
(or even crashes its thread!), the state changes are still in effect.
The MonadCatchIO-transformers change is actually only incidental.
I could have kept on using lifted-base for the exception handling.
However, I'd have needed to write a new instance of MonadBaseControl
for the new monad.. and I didn't write the old instance.. I begged Bas
and he kindly sent it to me. Happily, MonadCatchIO-transformers is
able to derive a MonadCatchIO instance for my monad.
This is a deep level change. It passes the test suite! What could it break?
Well.. The most likely breakage would be to code that runs an Annex action
in an exception handler, and *wants* state changes to be thrown away.
Perhaps the state changes leaves the state inconsistent, or wrong. Since
there are relatively few places in git-annex that catch exceptions in the
Annex monad, and the AnnexState is generally just used to cache calculated
data, this is unlikely to be a problem.
Oh yeah, this change also makes Assistant.Types.ThreadedMonad a bit
redundant. It's now entirely possible to run concurrent Annex actions in
different threads, all sharing access to the same state! The ThreadedMonad
just adds some extra work on top of that, with its own MVar, and avoids
such actions possibly stepping on one-another's toes. I have not gotten
rid of it, but might try that later. Being able to run concurrent Annex
actions would simplify parts of the Assistant code.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is enough to let the configure program build.
|
| |
|
|
| |
build.
|
| |
|
|
| |
built. This may fix builds on s390x and sparc, which are failing to link -lHSrts_thr
|
| |
|
|
|
| |
Presumably, if the filesystem doesn't support file permissions, it's not
much of a multiuser system.
|
| |
|
|
| |
with, since yesod 1.2 has a great many changes that will require extensive work on the webapp.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
That is very dodgy; it makes *every* C file compiled have that header added
to it. Apparently sys/event.h needs some other header files to be included
on some OS's, and so this leads to compile failures in completely unrelated
places to the code that actually uses sys/event.h
This reverts commit a767040a53182cde16434cba686252bbaf776cf9, which added
this with no rationalle and I must have missed in amoung the other patches
when merging.
Also, Utility/kqueue.c already includes sys/event.h
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This will make it easier to use the Evil Splicer, when it needs to add
package qualified imports
And there's no real downside.
|
| |
|
|
|
|
|
| |
connecting to it from another.
Does not yet use HTTPS. I'd need to generate a certificate, and I'm not
sure what's the best way to do that.
|
| | |
|
| |
|
|
| |
attached
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
rather buggy.
|
| |
|
|
| |
rm was blocked waiting for input
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
explicitly specified
The current use of the 'Fast' and 'Production' flags is both inconsistent and
redundant. It's inconsistent, because users are allowed to specify both '-fFast
-fProduction' at the same time -- thereby enabling two contradicting features.
The flags are redundant, because Cabal allows users to specify '-O0' at
configure time, which is essentially the same as '-fFast'. Since 'Production'
is just the opposite of 'Fast', this means that neither flag is needed.
|
| |
|
|
| |
building on BSD
|
| |
|
|
|
| |
Git-annex doesn't actually depend on mtl version 2.1. By relaxing this
constraint, builds can succeed on Ubuntu 12.04.
|
| | |
|
| | |
|
| |
|
|
| |
Cannot get QuickCheck to install just now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have seen some other programs do this, and think it's pretty cool. Means
you can test wherever it's deployed, as well as at build time.
My other reason for doing it is less happy. Cabal's handling of test suites
sucks, requiring duplicated info, and even when that's done, it fails to
preprocess hsc files here. Building it in avoids that and avoids having
to explicitly tell cabal to enable test suites, which would then make it
link the test executable every time, which is unnecessarily slow.
This also has the benefit that now "make fast test" does a max speed build
and tests it.
|
| |
|
|
|
|
| |
Stopped checking the assistant flag for flags like webapp and xmpp,
because cabal disables the assistant if the other flag's dependencies
cannot be satisfied.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
Joey Hess
Joey Hess
Peter Simons
Peter Simons