| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
They're updated to show whether the activity succeeded or failed.
This adds several TODOs to the code to fix later.
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Makes it easier to edit for consistent voice etc.
|
| |
| |
| |
| | |
Nearly all long-running actions now display an alert.
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
http://git-annex.branchable.com/bugs/lsof__47__committer_thread_loops_occassionally/
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Putting the transfer on the currentTransfers atomically introduced a bug:
It checks to see if the transfer is in progress, and cancels it.
Fixed by moving that check inside the STM transaction.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
This has a bug -- it seems long polling can only wait on one page at a
time. Need to re-unify the notifiers.
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
| |
| |
| |
| | |
Needs to use a different NotificationBroadcaster, and not replace the
whole sidebar div, but instead add in new content. However, it's 3:30 am.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
This may be customised differently than the main page later on, but
for now the important thing is that this constantly refreshed page does not
allocate a new NotificationHandle each time it's loaded.
|
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| | |
Wow, what a nice productive day this was!
|
| |
| |
| |
| |
| |
| | |
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
|