These chains have been supported and provided by the default generated
`fetch` config for coinomi but they were not included during default
coinomi template generation.
- The expected `hledger` output format appears to have changed, likely
from a recent `hledger` release (confirmed to be unrelated to `xan`).
- This bug does *not* affect individual year tax report generation, when
given a specific (or default) year.
- Adds requirements to support auto-(un)load'ing, refactors
- Adds loader argument to unit tests and benchmarks
* Filters can now be passed as a loader argument
- Adds loader argument to Hash macro
* Factored out from shell caller
- Adds Pluggable auto-(un)load support
- Adds plugin dispatcher for interpreter
- Refactors to support new Pluggable system
- Updates usage help and improves documentation
Utilizes `libbitcoinkernel` for symbols and headers but also pulls from
non-kernel headers as needed (since current kernel design is a WIP).
See the code documentation in this commit for details.
Because of the nature of the interpreter, these headers should be
loaded/unloaded on an as-needed basis.
This commit is particularly useful for pluggables in that, if the
pluggable requires that the `dfi` API (or API-related implementations)
have certain preprocessor requisites fulfilled for the pluggable, the
API can now be compiled *after* the pluggable has been loaded but also
*before* the pluggable *requires* the use of the API (or API-related).
In other words, without this commit, a pluggable's `#define`s will be
useless *after* the API (or API-related implementations) is loaded and
compiled (at least not without an API reload, but that is not needed).
NOTE: this change does not affect `dfi`'s pluggable auto-(un|re)loading,
as the pluggable will have already been loaded prior to any other `dfi`
API compiling.
- Factors out (and deprecates) `Command`
- Deprecates certain free functions
- Adds better error handling
- Adds more free functions
- Refactors file handling
- Improves documentation
Notes on file loading (and general file handlers):
The interpreter command `.L` will load files but appears to not fail if
the file isn't source code or a library.
Calling `gSystem->Load()` will load a given library but not source file,
and appears to not accept paths (which will be needed for pluggables).
Because `gInterpreter->LoadFile("path")` will load either a source file
or library by given "path", and is consistent with `dfi`'s approach to
path handling, this function appears to be the winner (for now).
ROOT 6.38.00 brings LLVM 20 which errors (or ROOT's Cling errors) when
calling certain base CRTP template functions without a `this` pointer.
Resolves:
"error: call to non-static member function without an object argument"
NOTE: RandomImpl is not currently affected but is refactored for consistency.
The base path is now *outside* of the macro directory; allowing for a
more integrated view of `dfi`'s entire `root` system. This is more
apparent once running an interactive session where the expectation is
(more intuitively) that any path should be relative to 'src/root' and
not 'src/root/macro'.
The rationale for why this was in 'src/root/macro' to begin with stems
from how `root` (by default) will automatically load rootlogon.C in the
directory that `root` is started. This is causing more confusion than
not because `dfi`'s usage of `root` is not limited to macros.
These changes skirt the line between needing a major API bump and not
but, so far, appears to be on the side of *not*. However, the TODOs
noted for macro loading should be addressed prior to any API changes.
The old macros should *not* have been used in any example; as they
were intended for internal use only.
This was noted in Doxygen ...by not noting them as publicly consumable.
