I am looking to define stuck projects as those that either have no TODOs, or, maybe they have TODO entries but none of them is scheduled. My thinking on this is: I may build up a set of TODOs against a project, but if none of them is scheduled, it will never make it onto my agenda and get acted upon. So from that standpoint just having a 'TODO' item doesn't do me any good unless something is scheduled (even if in the future).
I was originally using '*' to match any TODO state but then I tried replacing it with a regexp match on 'SCHEDULED: <.+>'. At first this looked like it would suit my needs; however when I mark a task as Completed, the SCHEDULED property is still there so the project still appears 'unstuck' even if I have no other tasks defined yet, or tasks that aren't scheduled.
I came across this discussion: Defining unscheduled todos as stuck projects in Emacs Org-Mode - but it looks to me like that setup would have the same problem.
I suppose I could keep removing the scheduled date as I complete things, but this seems cumbersome. There also doesn't seem to be a way to do any kind of multi-line regexp on individual tasks. Any ideas whether it's possible somehow?
Thanks!
Related
kube-controller-manager has the following property
-deployment-controller-sync-period duration Default: 30s
Period for syncing the deployments.
What does this actually control and what does period for syncing the deployments mean?
Haha most curious thing. You'd expect it does something like controlling how often the controller checks whether the status of Deployment objects are compatible with spec or if there is a change needed.
However currently the controller-manager is notified on changes by the apiserver so it always inherently knows this information already.
There is Issue #71510 where someone points out that parameter seems to be unused. I've done my own search for the parameter and a related search for the variable. As far as I can tell all of these uses are for copying this value around, conversions, declarations, etc, and none of them actually use it for anything at all.
A good test would be setting it to a year and see what happens. I haven't done that though.
We're using Quartz 1.8.6 in our app. We are using CronTriggers for hourly and nightly jobs. We would like to set things up such that if there is a misfire, we want to skip the job until the next cron time rolls around.
For simple jobs, it appears you can do a
nightlyTrigger.setMisfireInstruction(SimpleTrigger.MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT);
However, it appears that this does not work with CronTrigger. What is the Misfire instruction to use in this case?
You want to use CronTrigger.MISFIRE_INSTRUCTION_DO_NOTHING.
SimpleTrigger.MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT is telling Quartz that, upon one or more misfires, it must:
reschedule the trigger to fire upon the next scheduled date (not firing, i.e. ignoring, missed executions).
Also, set the "repetitions left" counter as if all missed executions had run correctly (not accounting for missed runs either).
So basically this misfire instruction tells Quartz to do nothing at all, smile and keep going like nothing ever happened. The KEEP CALM of misfire instructions.
The equivalent instruction for Cron triggers is much more aptly named: CronTrigger.MISFIRE_INSTRUCTION_DO_NOTHING.
Here's the situation that I'm trying to describe, and would like to reflect in the org file:
Suppose you started a task, but while working on it you realized that the description of the task must be amended in a way that it justifies that task to be extended. Still you don't want to lose the original estimate, just for historical purposes, so, roughly, what I would like to have would be:
* STARTED Do something seemingly easy
DEADLINE: <2013-06-09>
This should be a breezy
AMENDED: <2013-06-10>
Looks like this will require more effort
The agenda buffer would use the latest date in the task, but it would be still "interesting" to know the original estimate after the task was finished.
There are many options in org-mode for logging or adding notes whenever a task properties change.
Check for example lognotereschedule, which will ask you for a note when rescheduling a task.
You can choose to store all notes and status changes in a special drawer called LOGBOOK in order to avoid clutter.
I am writing a custom plugin for TinyMCE. One of the new buttons makes a number of DOM manipulations in the document. The default undo behavior creates a few undo levels in the middle of the changes. If the user hits the undo button after using the plugin, he/she then sees a document with the operation partially reversed and really not in a proper state.
It looks like there used to be a pair of instance commands called mceBeginUndoLevel / mceEndUnoLevel (removed in version 3.3) that let a developer start/end a large undo batch that would be undone in a single operation....but I don't see anything in the docs that replaces that feature.
Some forum postings suggest using editor.undoManager.add() as a replacement, and that works for cases where you want more levels of undo during an operation, but I actually want less.
There is also a undoManager.onBeforeAdd event that you can hook into, but looking at the source for the undoManager, I don't think that hooking there will let you abort an undo snapshot.
So, is there a proper way to batch undo operations that I'm not seeing using the existing API? If not, my only other option seems to be patching the undoManager to allow the onBeforeAdd hook to abort a snapshot.
I suggest overwriting the current UndoManager. It is just a rather small file.
That's what we needed to do in order to suppress the creation of some unwanted undosteps.
I have a fairly good idea of what the Subject class does and when to use it, but I've just been looking through the language reference on msdn and see there are various other ISubject implementations such as:
AsyncSubject
BehaviorSubject
ReplaySubject
As the documentation is pretty thin on the ground, whats the point of each of these types and under what situations would you use them?
These subjects all share a common property - they take some (or all) of what gets posted to them via OnNext and record it and play it back to you - i.e. they take a Hot Observable and make it Cold. This means, that if you Subscribe to any of these more than once (i.e. Subscribe => Unsubscribe => Subscribe again), you'll see at least one of the same value again.
ReplaySubject: Every time you subscribe to the Subject, you get the entire history of what has been posted replayed back to you, as fast as possible (or a subset, like the last n items)
AsyncSubject: Always plays back the last item posted and completes, but only after the source has completed. This Subject is awesome for async functions, since you can write them without worrying about race conditions: even if someone Subscribes after the async method completes, they get the result.
BehaviorSubject: Kind of like ReplaySubject but with a buffer of one, so you always get the last thing that was posted. You also can provide an initial value. Always provides one item instantly on Subscribe.
In light of the latest version (v1.0.2856.0) and to keep this question up to date, there has been a new set of subject classes:
FastSubject, FastBehaviorSubject, FastAsyncSubject and FastReplaySubject
As per the release notes they
are much faster than regular subjects
but:
don’t decouple producer and consumer by an IScheduler
(effectively limiting them to
ImmediateScheduler);
don’t protect against stack overflow;
don’t synchronize input messages.
Fast subjects are used by Publish and
Prune operators if no scheduler is
specified.
In regards to AsyncSubject
This code:
var s = new AsyncSubject<int>();
s.OnNext(1);
s.Subscribe(Console.WriteLine);
s.OnNext(2);
s.OnNext(3);
s.OnCompleted();
prints a single value 3. And it prints same if subscription is moved to after completion. So it plays back not the first, but the last item, plays it after completion (until complete, it does not produce values), and it does not work like Subject before completion.
See this Prune discussion for more info (AsyncSubject is basically the same as Prune)
Paul's answer pretty much nails it. There's a few things worth adding, though:
AsyncSubject works as Paul says, but only after the source completes. Before that, it works like Subject (where "live" values are received by subscribers)
AsyncSubject has changed since I last ran tests against it. It no longer acts as a live subject before completion, but waits for completion before it emits a value. And, as Sergey mentions, it returns the last value, not the first (though I should have caught that as that's always been the case)
AsyncSubject is used by Prune, FromAsyncPattern, ToAsync and probably a few others
BehaviorSubject is used by overloads of Publish that accept an initial value
ReplaySubject is used by Replay
NOTE: All operator references above refer to the publishing set of operators as they were before they were replaced with generalised publish operators in rev 2838 (Christmas '10) as it has been mentioned that the original operators will be re-added