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.
Related
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!
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.
I'm integrating watchman via the socket/bser interface in a JVM program.
I'm seeing odd timing where:
A file is written to by the build system (a small text file)
I get a watchman notification on the bser interface
Thread A listening for bser subscription notifications puts the update onto a queue for a separate thread
Thread B reads the queue, reads the changed file, and then puts the file's data on the wire
However, somehow, Thread B is reading an empty file.
Which, I assume is validly empty at some point, e.g. the IO/syscalls might be:
Clear the file contents
Write chunk 1
Write chunk 2
Close the file
And I assume my Thread B is reading the file between steps 1 and 2. Or maybe 1 and 4, if 4 is when the result is flushed.
My confusion is two fold:
1) I thought watchman's default 20ms wait would account for things like this, and I'd only see an update on my thread A, let alone when my thread B does a read, after step 4, and the data is done being written to the file.
2) Even if watchman did tell me "too soon" about the 1st syscall (say step 1), and I read the results while it was an empty file, there should be another syscall/watchman notification that "btw, the file has some content now".
FWIW/oddly enough, I was seeing this very same behavior when using the Java WatchService API, where I would get an inotify event, but read a file "too soon", and so get either empty or partial results, and then no follow up inotify event when the rest of the data was available.
I assumed this was a fluke/nuance of the WatchService, so I solved it at the time by checking the file mod time before reading it, and just waiting to ensure mod time >2 seconds old before assuming the file is "done" being written.
(Note that this also handled ~100mb+ files being written, where the build process might write a chunk of data every 100ms+, but with WatchService I was seeing 100s of inotify notifications for what was essentially a single continuous write.)
When I ported my WatchService code to watchman, I dropped this "ensureSettled" hack, because I assumed watchman's 20ms settle period (which is way lower than the 2s I was using, but hey it's the default) + it's general robustness compared to the somewhat beta WatchService would mean it wouldn't be a problem.
But within ~a day of using the watchman-ported code, I'm seeing empty file reads, just like I was with the WatchService.
Any ideas about what I'm missing?
I can add back the ensureSettled hack, but at this point I'm curious about what is going on.
The docs aren't very clear on this, sorry!
Dispatching of subscription notifications is subject to the settle timeout, but since file updates are non-atomic it's likely that the default 20ms kicks in before the file contents are visible to you; under the covers, the kernel generates a series of notifications for the various mutations that you're doing, so if the truncate takes 20ms before you write (or perhaps flush) the data out, you'll likely get a notification "in the middle".
This stuff is also operating system dependent. Here's an example of a recently discovered and resolved issue: https://github.com/facebook/watchman/commit/bac383c751b248ae742a2a20df3e8272238c0ae2
it doesn't sound like it is quite the same thing as you're experiencing, it just adds some color to this discussion.
If you already have code to manage the settling in your client, then it may be easier for you to add that back; we do this in watchman-make for example.
You may also wish to try setting https://facebook.github.io/watchman/docs/config.html#settle in a .watchmanconfig file in the root of the directory tree that you're watching and leave that to the watchman server. If/when you change this setting, you will need to delete and restart the watch.
Which you choose depends on how you want to trade ease of configuration against volume of code you want to maintain and (perhaps) volume of support questions from your user base if the .watchmanconfig isn't correctly configured for them.
Note that you can use the command invocation from https://facebook.github.io/watchman/docs/cmd/log-level.html to see the debug logging for the kernel notifications as they come in in real time; this may be helpful for you in understanding exactly which notifications are coming in and when.
Just curious, are you using https://github.com/facebook/watchman/tree/master/java to talk to the watchman server?
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.
(reposted from here)
I'm trying to measure/log the running time of a task.
I've looked into "wrapping" a task by adding one task before and one task after but this would not work every time as sbt only guarantees a partial order.
A better wrapping would be something along these lines:
wrappedTask := {
startMeasuringTime()
somehowInvoke(myTaskKey in SomeContext)
endMeasuringTime()
}
What should this "somehowInvoke" be?
Measuring the time taken by a task needs support from the task executor.
As you imply, you cannot do this only by using task primitives.
I've pushed some sample code that I wrote a while back that shows the idea.
A complication that the sample code doesn't handle is that what the user conceptually thinks of as one task (compile, for example) may actually be implemented as several tasks and those timings would need to be combined. Also, a task like internalDependencyClasspath "calls" other tasks (flatMap) and so its execution time includes the execution time of the "called" tasks.
EDIT: This was implemented for 0.13.0 as an experimental feature in 602c1759a1885 and 1cc2f57e158389759. The ExecuteProgress interface provides sufficient information that the previously described issues are not a problem.