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>
- Avoid possible clash with lib atomic on macOS, e.g. in /Library/Developer/CommandLineTools/usr/include/c++/v1/memory:668
Signed-off-by: Thomas Lauf <thomas.lauf@tngtech.com>
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>
- Removes RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used
Signed-off-by: Thomas Lauf <thomas.lauf@tngtech.com>
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
This test uses libfiu to create random failures in fputs and the write system
calls to verify out-of-space errors on the filesystem do not corrupt the
database.
Related to #155
Database objects were unconditionally writing out the tags database
file. For commands that are not modifying any tags, this is unnecessary.
We will now track if there have been modifications so we can use it to
determine if we need to save the tags to a file.
Closes#284
