| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
Also fixed a bug; the ident for the div was regnerated each time
/status was called. This only was the same as the original ident due to
luck.
|
|
|
|
|
|
| |
WebApp now shows changes with no delay. Comparing a running git-annex get
and the webapp side-by-side, they both show each new transfer at the same
time.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The fun part was making it move things from TransferQueue to currentTransfers
entirely atomically. Which will avoid inconsistent display if the WebApp
renders the current status at just the wrong time. STM to the rescue!
|
|
|
|
|
|
| |
I've convinced myself that nothing in DaemonStatus can deadlock,
as it always keepts the TMVar full. That was the only reason it was in the
Annex monad.
|
|
|
|
|
| |
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.
|
|\ |
|
| |
| |
| |
| | |
config is valid.
|
| | |
|
| |
| |
| |
| | |
use julius's nice #id and .class things
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| |
| |
| |
| | |
This does fix some UI issues I was having.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Not needed, and causes a segfault on OSX when it tries to dereference the
NULL servicename. (Linux handles this case better.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
another dependency cabal works without here, oddly
|
| |
| |
| |
| |
| | |
Or rather, for yesterday evening up until 6 am last night, and 3 hours this
morning. I need to fix my sleep schedule.
|
| |\ |
|
| | | |
|
| | |
| | |
| | |
| | | |
yowza!!!
|
| | | |
|
|\| | |
|
| | | |
|
| | |
| | |
| | |
| | | |
mocked up the main screen, and am actually pretty happy with it!
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
It's unlikely an error would occur unless the server is stopped. But
retrying a few times seems like a good idea anyway.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Had to switch to toWaiAppPlain to avoid a seeming bug in toWaiApp;
chromium only received a partial copy of jquery. Always the same length
each time, which makes me think it's a bug in the compression, although
a bug in the autohead middleware is also a possibility.
Anyway, there's little need for compression for a local webapp. Not wasting
time compressing things is probably a net gain.
Similarly, I've not worried about minifying this yet. Although that would
avoid bloating the git-annex binary quite so much.
|
| |
| |
| |
| | |
when things they include change
|
| | |
|
| | |
|
| | |
|