| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
Does rsync stall and update its progress display? Dunno, but this was an
easy optimisation to throw in.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is handled differently for inotify, which can track modifications of
existing files, and kqueue, which cannot (TTBOMK). On the inotify side,
the TransferWatcher just waits for the file to be updated and reads the new
bytesComplete. On the kqueue side, the TransferPoller has to re-read the
file every update (currently 0.5 seconds, might need to increase that).
I did think about working around kqueue's limitations by somehow creating
a new file each time the size changed. But cleaning up all the files that
would result seemed difficult. And really, this is not a lot worse than
the TransferWatcher's behavior for downloads, which stats a file every 0.5
seconds. As long as the OS has decent file caching behavior..
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Current implementation parses rsync's output a character a time, which
is hardly efficient. It could be sped up a lot by using hGetBufSome,
but that would require going really lowlevel, down to raw C style buffers
(good example of that here: http://users.aber.ac.uk/afc/stricthaskell.html)
But rsync doesn't output very much, so currently it seems ok.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The webapp can only run on one of ipv4 and ipv6, no both. Some web browsers
may not support ipv6, so ipv4 is the safe choice.
The actual problem I ran into with it only listening to ipv6 was that
Utility.Url.exists was failing to connect to it. I doubt that haskell's
HTTP library is ipv4 only. More likely, it was only trying one address,
and tried ipv4 first.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Bug introduced in d1da9cf221aeea5c7ac8a313a18b559791a04f12, where
I removed a forkProcess when feeding gpg. Feeding it from a thread
solves the bug.
|
| |
|
|
|
|
| |
Actually 3 forms in one, this handles the initial passphrase entry, and the
confirmation, and also varys wording if the same user or a different user
is confirming.
|
| | |
|
| |
|
|
|
|
| |
To avoid conflict with different liftIO from MonadIO (in some version of
yesod not the one I have here), and because it's generally clearer, since
this module has both Wai and Yesod stuff, to qualify them both.
|
| | |
|
| |
|
|
|
|
| |
This deals with interruptions in network connectevity, by listening
for a new network interface coming up (using dbus to see when
network-manager or wicd do it), and forcing a rescan of
|
| |\
| |
| |
| |
| | |
Conflicts:
debian/changelog
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Old 1.0.1 version is still supported as well. Cabal autodetects
which version is available, but in the Makefile, WITH_OLD_YESOD
has to be configured appropriately.
I have not squashed all the $newline warnings with the new Yesod.
They should go away eventually anyway as Yesod moves past that transition.
|
| | | |
|
| |\| |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This actually does add a new repo, but it doesn't yet set up
remotes, or sync to it.
|
| | |
| |
| |
| |
| | |
had to use xdg-user-dir to query it, since it's in a shell format file.
Fall back to
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
git annex assistant --autostart will start separate daemons in each
listed autostart repo
running the webapp outside any git-annex repo will open it on the
first listed autostart repo
|
| | | |
|
| | |
| |
| |
| | |
Not hooked up to either Makefile or cabal yet
|
| | |
| |
| |
| | |
to the appropriate system or local user directory
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This prevents multiple runs of the assistant in the foreground, and lets
--stop stop foregrounded runs too.
The webapp firstrun case also now writes a pid file, once it's made the git
repo to put it in.
|
| | |
| |
| |
| |
| | |
Before pushing ran in its own process, so exitSuccess was the right thing
to do, but with the threaded code, that's caught as an exception.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
First use of it is to make the status checkpointer thread block until
there is really a change to the status.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a way to send a notification to a set of clients, any of which can be
blocked waiting for a new notification to arrive. A complication is that any
number of clients may be be dead, and we don't want stale notifications for
those clients to pile up and leak memory.
It took me 3 tries to find the solution, which turns out to be simple: An array
of SampleVars, one per client. Using SampleVars means that clients only see the
most recent notification, but when the notification is just "the assistant's
state changed somehow; display a refreshed rendering of it", that's sufficient.
|
| | |
| |
| |
| |
| |
| | |
This avoids forking another process, avoids polling, fixes a race,
and avoids a rare forkProcess thread hang that I saw once time
when starting the webapp.
|
| | |
| |
| |
| |
| | |
Not needed, and causes a segfault on OSX when it tries to dereference the
NULL servicename. (Linux handles this case better.)
|
| | | |
|
Joey Hess