findET executable; Fix issues #50, #53, #55, and #56

[texadactyl]

Also, patched setup.py so that we can avoid the sqlite "database locked" failures when running pytest. Need to find a way to run the pytest coverage plugin without these failures.

[telegraphic]

50 - All GPU device to be chosen by ID ✅

53 - I like where this is going, but I think I'd prefer log level to be set by hyperseti.set_log_level() or similar ❓

55 - Good catch ⚾ ✅

56 - Ha! 👽 ✅ (We'll need to keep this updated though, still working on the pipeline so might need some API changes longer term)

[telegraphic]

Nice work @texadactyl , I'm happy with all but have a question on #53, as I'd prefer to see logger control kept separate to the main function calls

[texadactyl]

@telegraphic Regarding issue #53, are you saying that you'd prefer independent control in each main function? Then, how would those logger levels be controlled by the user?

I can see an advantage of different granularities of logging but how does one manage that in a practical sense?

[telegraphic]

@texadactyl , what I meant was that you'd do something like:

hyperseti.set_log_level('info')
hyperseti.do_something()

hyperseti.set_log_level('debug', loggers={'hyperseti.dedoppler'})
hyperseti.do_something()

i.e. keep the logger setup out of the signal processing function calls (I see how 'main function calls' was misleading).

[texadactyl]

@telegraphic

This is the state of the PR today w.r.t. issue #53.

E.g. findET xx.h5 -l warning -d "hyperseti.hitsearch" All of the functions except hitsearch will use logging level WARNING. For hitsearch, DEBUG and INFO messages will also appear.

E.g. findET xx.h5 -l warning -d "hyperseti.hitsearch" "hyperseti.normalize" In this example, 2 functions, hitsearch and normalize, will be debugged.

This is the code pattern in the signal processing functions:

from .log import get_logger
logger = get_logger("hyperseti.name")

def function(.....):
     logger.info(...)
     logger.debug(...)

High-level concept: Signal processing functions are either (a) logging with a command-line option specified level or (b) they are being debugged (level=logbook.DEBUG). And, they are oblivious to what level of logging is being used.

Module log has 2 new functions: (1) get_logger : Called when the signal processing functions are being loaded by Python. Each call returns a logger object whose level will be updated later. Successive calls build up 2 singleton lists: logger_list and logger_name_list. (2) update_levels : This is called after all the get_logger calls (loading) are done and while the program is being executed. For each element of the logger_name_list & logger_list (singletons), -- If the name matches an element of the debug list argument, then set DEBUG level for that logger; -- Else, set the specified group level.

In findET (or in the find_et function caller), call the update_levels function as soon as possible. Note that if update_levels is not called, subsequent logger calls still work but with level defaulting to WARNING.

[texadactyl]

@telegraphic I think that your logging concenrns have been addressed.