| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
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.)
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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?
|
Joey Hess