Robot
/
lnav
mirror of https://github.com/tstack/lnav.git
2
0
Fork 0
Code Issues Releases Wiki Activity
2,694 Commits 3 Branches 36 Tags 26 MiB
Commit Graph

92 Commits

Author SHA1 Message Date
Tim Stack faeaf477ab [yajlpp] flesh things out a bit more 2022-10-04 21:17:01 -07:00
Tim Stack 7f513b2d1f [tidy] fixing some uninit issues 2022-09-21 21:06:04 -07:00
Tim Stack d940d9d5eb [logfile] plumb gzip header through file meta 2022-09-20 20:07:44 -07:00
Tim Stack e0ecbdff10 [logfile] improve handling of ansi escapes 
I think this covers the rest of the functionality
that needs to deal with ansi escapes.

Related to #1057
 2022-09-19 20:15:35 -07:00
Tim Stack 740b827901 [logfile] handle logs with ANSI escapes 
This is a partial fix for handling ANSI escapes in
parts of log messages that would prevent regexes
from matching.  Still more work to do.

Related to #1057
 2022-09-14 21:43:36 -07:00
Tim Stack 66ec8e553e [build] fix static var issue 2022-09-04 07:13:32 -07:00
Tim Stack 6ca01cd934 [line_buffer] fix some long-line handling 2022-09-04 06:38:39 -07:00
Tim Stack 3df07139b3 [line_buffer] fix long line issue 
Fixes #980
 2022-08-06 13:46:50 -07:00
Tim Stack 7077495389 [crash] missed expanding the alt buffer in line_buffer 2022-08-04 09:23:40 -07:00
Tim Stack 7b32ea9d39 [logfile] fix handling of partial lines 2022-08-02 16:03:39 -07:00
Tim Stack 1ae1600f7b [line_buffer] cache compressed files 2022-08-01 14:56:48 -07:00
Timothy Stack 8ef581177c [line_buffer] add some performance counters for tracking SQL perf 
Also, check for keyboard input during SQL execution
so we can cancel.

Fixes #894
 2022-07-27 21:49:14 -07:00
Timothy Stack b3ee092dc5 [cleanup] remove unused stuff and add a test 2022-07-22 15:31:08 -07:00
Timothy Stack 4c20b0039c [sql] some more error improvements 2022-07-13 15:43:41 -07:00
Timothy Stack 39763b2d31 [vtab] add indexes for text columns 2022-07-10 21:00:45 -07:00
Timothy Stack f3934c742d [error] leverage sqlite3_error_offset 2022-07-08 14:17:34 -07:00
Timothy Stack 8b3b8a6e3c [perf] fix some text file loading issues 2022-07-07 22:13:18 -07:00
Timothy Stack 01031a9fa3 [build] add missing include 2022-07-07 11:00:19 -07:00
Timothy Stack 36e9433891 [perf] try to overlap line buffer i/o 2022-07-07 10:05:06 -07:00
Timothy Stack f9f797fc9d [logfile_sub_source] add log message watch expressions 
Fixes #539
 2022-06-28 22:23:56 -07:00
Timothy Stack 9d590836f3 [perf] tweak initial line buffer request size 2022-06-13 22:09:52 -07:00
Timothy Stack a27198e8ca [regex101] add an integration with regex101 
... and a pile of other changes
 2022-04-30 13:06:01 -07:00
Timothy Stack 81e63784e7 [modernize] some more cleanups 2022-03-31 08:59:33 -07:00
Timothy Stack b856cd9657 [build] silence some warnings 2022-03-28 22:00:49 -07:00
Timothy Stack 66ef5fdae1 [clang-format] init 2022-03-16 15:38:08 -07:00
Timothy Stack f5e88b7158 [docs] add ARCHITECTURE.md and various other things 2021-02-13 12:41:48 -08:00
Timothy Stack 9a073e80e7 [result] fix Result.map() issue with copying the value when the result was in error 2020-12-26 23:00:44 -08:00
Phil Hord 7ad40f7263 Improved fix for multi-stream gz files 
Instead of throwing an error when we unexpectedly reach a stream EOS, treat it as regular
stream end. This allows for streams that might different encodings for different sections.
Even though we don't recognize the encoding and continue on with the data, at least we
don't fail when we reach this situation.  This allows us safely to try and continue
parsing the next catted gz stream, knowing that if it fails, we will handle it gracefully.
 2020-12-13 13:37:12 -08:00
Phil Hord f10a303f54 Revert "Don't try to read concatenated gzip streams" 
This reverts commit 1d127053e9.
 2020-12-13 13:17:21 -08:00
Timothy Stack 8e629b166a [build] some more compiler profiling 
Defect Number:
    Reviewed By:
   Testing Done:
 2020-11-19 21:36:51 -08:00
Timothy Stack db8a3c4d38 [debt] doing some cleanup 
Defect Number:
    Reviewed By:
   Testing Done:
 2020-11-09 22:17:17 -08:00
Phil Hord 1d127053e9 Don't try to read concatenated gzip streams 
Don't try to continue reading the next stream of a concatenated
gzip file.  The next stream may be CRC noise or other garbage.

Maybe in the future we should look for a gzip header in the
following bytes of the stream and try to decode from there.
But it's not clear that anyone ever uses this supposed gzip
feature anyway.

Let's just end the stream when we reach EOS. Also, if the
stream fails to init, let's leave it closed instead of throwing
an error no one is likely to catch.  Log the error msg from
zlib if one is provided.
 2020-10-19 20:49:36 -07:00
Suresh Sundriyal 0dedb3d455 [simd] Allow toggling of simd related functionality 2020-09-17 21:20:52 -07:00
Timothy Stack ce0383dee1 [build] fix some warnings 2020-09-11 23:10:11 -07:00
Timothy Stack 16c5fdccb4 [build] more win build 2020-09-10 22:15:02 -07:00
Timothy Stack ead1d3eb36 [build] fix some more warnings 2020-09-02 23:04:21 -07:00
Timothy Stack 138a506b1a [perf] a few performance tweaks 2020-04-23 06:42:48 -07:00
Phil Hord 5513deeade Add a gzip indexing class for faster gz navigation 
The gzread function is slow.  Every time you seek to a new location, the
whole file up to that position has to be decompressed again.  This causes
massive lags when trying to do simple things in lnav on a large .gz file.

Use the zlib inflate* functions instead and record the dictionary
periodically while processing the file the first time.  Then use
inflateSetDictionary to restore the dictionary to a convenient
location when trying to seek into the file again in the future.

Use a default period of 1MB of compressed data for syncpoints.
Each syncpoint uses 32KB. This is a ratio of 3.2%.  For example,
a 1GB .gz file (compressed size) will require us to keep 32MB
of index data in memory. A better method may be to use a fixed
number of syncpoints and divide the file appropriately. This
would keep the memory bounded at the cost of slower file
navigation on large .gz files.

Use pread to read the data for the stream decompressor and remove
the lock_hack previously employed.

NB. The documentation on these zlib functions is sparse. I followed
the example in zlib/examples/zran.c, but I used the z_stream total_in
and total_out variables instead of keeping my own separately as zran.c
does.  Maybe this is incompatible with some very old zlib versions.
I haven't looked.
 2019-08-17 18:40:55 -07:00
Timothy Stack 76edd2a9d1 [line_buffer] refactor left a bug with non-blocking files 
Fixes #662
 2019-06-27 10:19:54 -07:00
Timothy Stack 02c53976b4 Some refactoring for the line buffer and other cleanups 
Fixes #649
 2019-06-15 06:32:02 -07:00
Timothy Stack 84135c44e4 [build] disable simd stuff for now 2018-10-17 07:36:42 -07:00
Timothy Stack 2589345e5c [perf] improve initial indexing times 2018-10-17 07:03:33 -07:00
Timothy Stack 2e10ca09d0 [line_buffer] fix crlf handling in log files 2018-10-12 07:46:18 -07:00
Timothy Stack 3e457e30ca [json-format] fix json file recognition for crlf line-endings 
Fixes #528
 2018-08-13 05:30:47 -07:00
Timothy Stack d805dee15f [line_buffer] avoid a crash with binary files, but still not handled well 2018-07-22 07:59:49 -07:00
Phil Hord eee7d0ddfc Squash a bunch of signed/unsigned warnings 2018-03-29 10:49:38 -07:00
Phil Hord 5a20829ed4 dynamic exception specifications are deprecated in C++11 
Remove exception specifications to appease modern compilers and reduce
warning counts.

I sort of hate to remove all these exception-decls, but they are in fact
deprecated, and my compiler loves to complain.
 2018-03-29 10:43:44 -07:00
Timothy Stack 88a192aeeb [line_buffer] if the size of the file is known, reduce the requested buffer size and ignore attempts to shrink the buffer 2018-03-25 23:36:18 -07:00
Timothy Stack 352d16f4cf [line-buffer] fix resize to use the requested size 
When reading in a full message, we need to make sure the buffer
is large enough to accommodate the full thing.
 2018-03-02 09:17:49 -08:00
Timothy Stack 34d1422b76 [highlight] only highlight keywords in text files 
Fixes #408
 2017-02-18 22:35:18 -08:00