- This also handles the case when it is called with the `:all` hint
- When called with a range, the `track` command is recommended
- There is no forwarding to `track`
Signed-off-by: Thomas Lauf <thomas.lauf@tngtech.com>
Move the adjustment of a new open interval that is enclosed by the
current open interval into the validation processing, where the other
overlap resolution takes place.
This will allow the start command to honor the :adjust flag when
starting a new interval that predates the current open interval.
Closes#326
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Signed-off-by: Thomas Lauf <thomas.lauf@tngtech.com>
It was possible previously to start an interval with a filter earlier
than the current filter, and if the tags matched, the command would
report success without actually moving the start time.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Since the Intervals are all in order, we can use getTracked directly to
get overlapping intervals without the need to copy the Intervals into
another vector.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
- Add tests for JSON output
- Separate different test scenarios
- Optimize JSON output in `TagInfoDatabase::toJson ()`
- Closes#325
Signed-off-by: Thomas Lauf <thomas.lauf@tngtech.com>
- This adds the last bits to the PR started by Christian Roesch:
- Some code formatting
- Specifying both id(s) and tag(s) is an error
- Clear range for tag filter: The range is meant to set the new interval's range, not the filter's
- Added tests
- Overhauled test using relative times and testing exported intervals instead of command line output
- Closes#241
Signed-off-by: Thomas Lauf <thomas.lauf@tngtech.com>
- Only an open interval can truncate another open interval.
Otherwise the `:adjust` hint has to be applied
Signed-off-by: Thomas Lauf <thomas.lauf@tngtech.com>
- Filter shall be taken as is, not changed
- If there is a problem, the functions consuming the filter have to be adapted, not the filter
Signed-off-by: Thomas Lauf <thomas.lauf@tngtech.com>
- Add DatetimeParser::parse_range: If a date contains no time, it is assumed to be a fixed range, else an open range starting at given datetime
- Add tests for summary with named dates 'yesterday' and 'today'
- Remove closing of filter in CmdSummary.cpp
- Closes#333
Signed-off-by: Thomas Lauf <thomas.lauf@tngtech.com>
In order to keep the database consistent, we really want all the
AtomicFiles to be finalized as a group. This will prevent an inopportune
signal from interrupting this process.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
The json::object pointer was allocated in the parse function but never
freed.
The way timwarrior is used currently, this leak does not cause any
problems, but...
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
When the Lexer breaks a line into tokens, it also wants to return the
type of the token. This information isn't used by the IntervalFactory
and it slows down the operation since dates end up being parsed at least
twice, once by the Lexer to determine that the string is a date, then
again in the IntervalFactory to actually construct the Date.
Before are the before and after results when exporting a database with
100 lines. The number of instructions executed went from roughly 31,552,467 to
12,952,372 on debug builds. Release builds saw a change from around 14K
to 7K instructions.
Before:
$ rm -fr ~/.timewarrior; src/timew :yes >/dev/null; for x in {100..1}; do src/timew start ${x}sec ago proj_${x} >/dev/null; done;
$ sudo chrt -f 99 valgrind --tool=callgrind --callgrind-out-file=callgrind.out src/timew export >/dev/null
==20888== Callgrind, a call-graph generating cache profiler
==20888== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al.
==20888== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==20888== Command: src/timew export
==20888==
==20888== For interactive control, run 'callgrind_control -h'.
==20888==
==20888== Events : Ir
==20888== Collected : 31552467
==20888==
==20888== I refs: 31,552,467
After:
$ sudo chrt -f 99 valgrind --tool=callgrind --callgrind-out-file=callgrind.out src/timew export >/dev/null
==24088== Callgrind, a call-graph generating cache profiler
==24088== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al.
==24088== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==24088== Command: src/timew export
==24088==
==24088== For interactive control, run 'callgrind_control -h'.
==24088==
==24088== Events : Ir
==24088== Collected : 12952372
==24088==
==24088== I refs: 12,952,372
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
This fixes the bug where, when filtering by tags, the interval IDs are not
preserved when not using any tags in the filter. Notice below how when
filtering with tag1, the two intervals are @4 and @5 instead of @1 and @5 like
they should be:
$ timew summ :ids
Wk Date Day ID Tags Start End Time Total
W9 2020-02-29 Sat @5 tag1 15:28:31 15:28:33 0:00:02
@4 tag2 15:28:33 15:28:35 0:00:02
@3 tag3 15:28:35 15:28:36 0:00:01
@2 tag4 15:28:36 15:28:48 0:00:12
@1 tag1 15:28:48 - 0:02:25 0:02:42
0:02:42
$ timew summ tag1 :ids
Wk Date Day ID Tags Start End Time Total
W9 2020-02-29 Sat @5 tag1 15:28:31 15:28:33 0:00:02
@4 tag1 15:28:48 - 0:02:28 0:02:30
0:02:30
This fixes a bug introduced in 86bb1465e8.
Closes issue #293 (thanks sskras)
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Interval is already marked as a constant object here and we can eliminate
creating unnecessary copies when filtering large databases.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Ensure that the IntervalFactory can parse the string returned by
Interval::serialize before writing to database.
If a user attempts to add a non-parseable date, you will get an error like:
$ TZ="GMT" timew track 7h before 1970-01-01T00:00:00 test
Note: 'test' is a new tag.
Internal error. Failed encode / decode check.
Or if the user attempts to add a tag that is not supported:
$ timew start 1970-01-01T00:00:00 '\"TEST\"'
Note: '"\\"TEST\\""' is a new tag.
Internal error. Failed encode / decode check.
On #159, the serializer / deserializer should be able to handle the escaped
quotes, but it is another example where we do not want any entry written into
the database that cannot be properly parsed. This change will also add more
verbose debugging information if the :debug flag is passed, like:
$ timew start 1970-01-01T00:00:00 '\"TEST\"' :debug
CLI Parser
_original_args
timew start 1970-01-01T00:00:00 \"TEST\" :debug
_args
word basename='timew' raw='timew' BINARY
word canonical='start' raw='start' ORIGINAL CMD
date raw='1970-01-01T00:00:00' ORIGINAL FILTER
word raw='\"TEST\"' ORIGINAL FILTER TAG
word canonical=':debug' raw=':debug' ORIGINAL HINT FILTER
>> 2020-02.data: 0 intervals
>> 1970-01.data: 0 intervals
>> 1969-12.data: 0 intervals
>> Loaded 0 tracked intervals
Note: '"\\"TEST\\""' is a new tag.
>> Datafile::addInterval() failed.
>> Encode / decode check failed:
>> inc 19700101T060000Z # "\\"TEST\\""
>> is not equal to:
>> inc 19700101T060000Z # "TEST\\\"\"" \
Internal error. Failed encode / decode check.
>> Timer timew 0.002137 sec
Closes#290
Related to #159
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
With this change, if there are debug messages that are multiple lines, each line
will be prefaced with the '>>' marker.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
I feel this is expected behavior, but also eliminates the following compile time
warning on one of my systems:
warning: ignoring return value of ‘int system(const char*)’, declared with
attribute warn_unused_result [-Wunused-result]
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
I tried placing my timewarrior database in Dropbox and noticed that everytime
I ran a command, Dropbox would indicate that it was syncing. Running fswatch
on macOS I saw that there was an event for timewarrior.cfg on every run. This
change eliminates the file system events when not writing to the database.
Related to #284
