| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
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.)
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The webapp is now a constantly updating clock! I accomplished this amazing
feat using "long polling", with some jquery and a little custom java
script.
There are more modern techniques, but this one works everywhere.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Useful for testing..
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Broke hamlet out into standalone files.
I don't like the favicon display; it should be served from /favicon.ico,
but I could only get the static site to serve /static/favicon.ico, so
I had to use a <link rel=icon> to pull it in. I looked at
Yesod.Default.Handlers.getFaviconR, but it doesn't seem to embed
the favicon into the binary?
|
| | |
| |
| |
| | |
Also, starts the assistant if it wasn't already running.
|
| | | |
|
| | |
| |
| |
| |
| | |
Also broke out some helper functions around constructing remotes,
to be used later.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
There's a minor performance overhead to doing this, but this way I don't
have to worry about a situation where statfs might block for a long time.
For example, when it's on a network filesystem.
|
| | |
| |
| |
| |
| | |
This avoids blocking all threads when calling waitchange_kqueue,
which blocks.
|
| | |
| |
| |
| |
| | |
This way, if a mount point was already mounted, but something else
gets mounted there, it'll be seen as a new mount.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
While this seems to work fine when used in a simple program,
when I load it in ghci, it segfaults about half the time. Don't know why,
and seems ghci specific, but if I get reports of crashes, I'll need to look
into that.
|
Joey Hess