Sometimes when terminating, an std::runtime_error is thrown from the a Python thread. This is because of commit ac409a9 where the threads are all detached - instead of having to wait on them.

Pybind11's Gitter chat confirmed that this is a known problem with multithreading.

I'll see if I can find a way to catch this exception.

For now, to keep things simple, this will be done with cURL.

After selecting all the items and pressing some new yet-to-be-bound key, we'll kill another screen and download the items. While this is happening, seeker threads will terminate. Some adjustments will be needed to not block the program until all seekers are dead.

For displaying downloads, I'll mimick how lgogdownloader does it (omitting the progress bar for now).

The TUI code is messy and in a dire need of a review. Now that we're using ncurses, WINDOWs should be used to modularize the screens, hopefully increasing drawing performance while we're at it.

So in a case where the user doesn't open the log, and an error occurs, they are still notified about it when the program terminates.

This can be done by simply logger_->flush_buffer_to_screen() in screen_butler::meta_action() just before return toggle_log().

This will require the screen butler to know about the logger as well, something a lot of other classes already know about. Perhaps we should make a simple butler base class that holds a shared pointer to the logger?

Instead of specifying a second argument for the file extension, we instead want scripts to:

exacts = bw.exacts_t({'year': year, 'pages': pages, 'extension': extension})

in differance to the current:

exacts = bw.exacts_t({'year': year, 'pages': pages}, extension)

Bookwyrm crashes with Fatal Python error: GC object already tracked when (I think) starting up a second thread that can read wanted_. Do we need to explicitly copy the object for each thread we want to run?

$ bookwyrm -a asd -y "aaaaaaaaaaaaaa1a"
error: unrecognised year modifier '; see --help

expected output:

$ bookwyrm -a asd -y "aaaaaaaaaaaaaa1a"
error: unrecognised year modifier 'aaaaaaaaaaaaaa'; see --help

A year modifier of >= 14 characters breaks the message for some reason.
Printing mod_str doesn't give the whole string.

Related code: https://github.com/Tmplt/bookwyrm/blob/master/src/item.cpp#L35-L77

As of dadbb4e, log entries made after TUI destruction are not written to stdout. The entry in question is the debug message about termination, which isn't printed.

Make sure that it works for libgen.io

When scrolling in a detached state, we will always on a move() unless we're in the beginning of the entries. To fix this with the current implementation, we would change at_first_entry in move() to be true when we're on the first entry + how many entries fit on the screen.

$ bookwyrm -atest
error: missing value for -atest; see --help

Expected:

$ bookwyrm -atest
error: unrecognized option -atest; see --help

I think bookwyrm only reads the first character on single-hyphen arguments, so -atest would thus be treated as the -a option. A check to see if there are more characters past the first would suffice.

Everything should be set up and ready to go after a nix-shell.

i.e.: screen::item_details should not be able to change cells that screen::multiselect_menu takes care of.

We should be able to implement this limit by use of the padding variables.

Probably useful if one wants to write a frontend by piping bookwyrm output.

Just a thought.
(Can pipes be used for streaming?)

Some sources require a specific referer to be set before the wanted item can be downloaded. the item.misc.uris std::vector<string> should thus be replaced with some std::vector<request> which holds a map of HTTP request settings.

A custom exception is much more documenting, and that would remove the odds of some not-manually-thrown GeneratorExit escaping but not being logged as an error.

According to pybind11's Gitter chat, using register_exception and throwing it in called Python code might make it suitable as an argument to pybind11::error_already_set::matches (or something else called match).

When quitting the menu, bookwyrm should terminate. Currently, as we rely on std::thread there is no way to interrupt the source scripts, so we must wait until they're done. Obviously, we want to interrupt the threads instead.

Topical reading:

• https://stackoverflow.com/questions/18868114/telling-an-stdthread-to-kill-stop-itself-when-a-condition-is-met
• https://stackoverflow.com/questions/13893060/i-want-to-kill-a-stdthread-using-its-thread-object

It's possible we'll eventually end up with duplicated items. Should we store them in a hashmap?

Within a properly defined environment, bookwyrm compiles without issues but segfaults upon runtime when Python modules are loaded. Aside from investigating this issue, a default.nix should be written.

One thread per CPU core, each thread taking care of an item, alá lgogdownloader.

When we terminate bookwyrm, we want the worker thread to immediately join. Currently we poll inside the source scripts whether we should return. This is slow. We'll want to create some interruptable_thread::interrupt() that throws some internal exception and stops everything instantly.

I'd like to keep boiler-plate a minimum in the actual scripts. We could check for interrupt in script_butler::add_item(), but we don't know how long it will take to get there, since the script needs to fetch the item in question first.

Perhaps we could spawn a nested thread that just waits until it's time to throw an interrupt exception. But that means we have two threads for each source. Ugly.

Or perhaps there is some hack we can exploit in pybind11. But if that is the case, the script butler will turn ugly if and when we decide to add support for other languages.

For now we'll just have to sprinkle checks in appropriate places in the source scripts.

E.g. if there are so many logs that they fill up more than the window height, the entries "above" and outside the screen will still be considered read when opening the log. Similarly, if we're detached, any logs "below" and outside the screen will also be considered read.

So that eventual (if any) contributors don't have to breadth-first search the code to understand how everything is interconnected.

Having the colours be customizable would be a cool feature to have. This could be achieved through using the terminal's own colours: https://stackoverflow.com/questions/18551558/how-to-use-terminal-color-palette-with-curses#22166613

It's defenitely something wrong with the reallocation of the array holding att ITEM*s. If less than 99 items (but more than 49) items are fed, we instead segfault when the item_array is destructed.

I blame ncurses for me having to write my own C.

Other than the horrible state of logger.{cpp,hpp}, we use but a smidge of spdlog's abilities, so we should remove this dependency and roll our own.

Install the plugins in the right place and whatnot.

Currently the program does not assume a default path if none is given. It makes sense to have it default to the current directory or . as that would be the msot common use case.

The logger broke with commit aa3805e; unread logs are no longer dumped to std{out,err} and the user is no longer notified about new logs. This will hopefully be fixed now when the TUI code will be modulerized.

The Python script libgen.py requires the following external libraries to work (for me at least):

• furl
• requests
• isbnlib

These are not listed in the README.md and should probably just be automagically downloaded if possible when building the project, otherwise they should be stated as requirements for certain 'seekers' to work.

Reproducable via

$ src/bookwyrm -t 'some title' <<< q

Within a properly defined environment, bookwyrm compiles without issues but segfaults upon runtime when Python modules are loaded. Aside from investigating this issue, a default.nix should be written.

Instead of calling a function in the found modules, we should instead call something in a class. The finally create book may be a few functions down; it would be much handier if one could just feed the books there instead of having to return them through a few levels.

This can be observed by diffing the log screen before and after omitting the "I've been summoned" log entry in main().

Currently, screen::base::refresh() is only called in screen::multiselect_menu. What we want to do is to make all screens work independently from each other, so we'll want to move screen updating to the screen butler, logically. The problem is that then the screen is only refreshed when screen_butler::update_screens() is called, e.g., only from scripts.

Should we manage this with some observer pattern? Are there better ways?

Instead of waiting until program termination to dump all logs, we could instead have a screen for this. Better yet if we can have this in a screen tab of some sort. When in the main view, we could signal to the user that a new log has been made by making the log tab bold or something.

We should be able to write a sink for spdlog for this.

With 049df29, abi::__forced_unwind is now caught to "safely" terminate the Python threads. This exception is an implementation detail only available in GCC.

As of this commit, bookwyrm is not portable and may only work on Linux.

Confirmed platforms and compilers:

• Linux
  • GCC
  • Clang
• FreeBSD
  • GCC
  • Clang
• OpenBSD
  • GCC
  • Clang

Next up in line of stuff to implement is the menu. The get it off the ground we'll just make it list the contents of a vector<item>, with each line being an item and what data it holds.

When it comes to receiving the items, the menu class will have some .append() member function that we bind to python as feed(). The menu class itself we'll bind as bookwyrm. When the instance is then passed onto Python as find(wanted, bookwyrm), we can then write bookwyrm.feed((nonexacts, exacts)) for each item the script constructs.

For the actual (graphical) implementation, I'll see if I can find something modern-C++-ish. Above just the menu, I'll want to implement submenus (alike how when you open an email in mutt) and some status bar (which scripts are still running? Total items found, script errors, etc).

Candidates are:

• AnsiGL
• ncurses (netbsd-curses)?

Just alike multiselect_menu::on_resize(). This way the user does not have to reopen an item_details screen after a resize event.

The crash is caused by the x-assert in screen::base::change_cell(), so we obviously start looking there.

With adbe829, the drawing of the menu is now blocked until the user enters 'q', the key bound to exit the menu and thus the program.

Termbox is currently an external dependency, a count of which I want to be 0 before first release.

Termbox build with waf which required Python, so that isn't a problem (we require it to build bookwyrm in the first place). Either we submit some CMakeLists.txts upstream, or we do the simple task of executing waf from our own.

This is easily done with a check in script_butler::add_item().

We currently compile tests and whatnot in libraries in lib/, which is rather useless. CMake also prints some warnings when configuring files for fmt/. That should be fixed/suppressed.

It might be a good idea to rewrite base::change_cell() to add/subtract the padding values accordingly. Not being worried about these values in the real screens would be nice. Investigate if this is possible.

For some odd reason, command_line::parser::get_many(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&&) const is depended upon. Remove this dependency.

Ncurses was initially the plan when I started working on the TUI. Since most other programs used it, I saw no reason not to use it. Unfortunately I stumbled upon some issues getting the most simple of functionality to work, so instead I wrote everything from scratch with termbox. While this allowed me to make the TUI just the way I wanted it, it has without questions given me some headaches too — in the form of self-inflicted bugs that is.

Thinking back, I believe the issue I had related to pointer invalidation on vector resize, a solution to which I figured out not very long ago. So perhaps I should give it another chance?

Perhaps a good idea is to just get v1.0.0 out and then focus on improving the machinery?

Instead of letting the terminal emulator handle the wrapping, we should make long descriptions wrap with the same indention. Makes --help a bit easier to read.

Scrolling behavior is bad when a log entry takes up multiple lines.

-1 is used when a year cannot be found. This should be replaced with "N/A".