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.
- Refactor using common types that were once internal
- Removes ancient macro approaches to C++20 solutions
- Changes `Exception` message type to use std::string
* std::string_view isn't worthwhile in this context
- Factor out respective common from macro and apply to all scopes
* `dfi::common`
* `dfi::macro::common`
* `dfi::plugin::common`
- Add deprecation warnings in `dfi::macro::common`
* Common functionality (not macro specific) is now in `dfi::common`
- Add convenience wrappers to inner common impl, where appropriate
* Allows for backwards compatibility
- Add/update/clarify code docs and Doxygen definitions
- Related refactoring
NOTE: all changes are backward compatible (no need to bump major).
- This is possible now that `dfi`'s ROOT build supports C++20
- No internal `dfi` API or impl changes are necessary
* This includes any Botan signatures
*WARNING*: lightning support is a WIP due to an unresolved electrum
lightning history bug (see docker-finance #227).
This commit is needed for backwards compatibility, as the new electrum
format will break import - even if lightning is never used.
The spawned shell needs its sourced environment and aliases.
Resolves:
sh: line 1: dfi: command not found
Error in <TRint::HandleTermInput()>: std::runtime_error caught:
FILE = "/home/business/docker-finance/plugins/root/example.cc"
LINE = 125
WHAT = "command failed"
`xsv` is no longer maintained and the author recommends `xan` instead.
Fortunately, `xan` is very suitable for our use-case; is very efficient,
and produces no differences in our expected output.
- Clarify usage, add examples, note plugin support type
* finance's `plugins` only supports shell-based plugins
- To use `root` plugins, use `root` command (see `root help`)
- dfi's `root` now supports shell loading (and running) of
macros/plugins:
* An interactive ROOT.cern instance is no longer *always* needed:
- For macros (non-server); a 'one-off' instance will start, load the
given macro, run the macro and then the instance will exit.
* Server(s) will maintain an interactive instance.
- For plugins; an interactive instance will start, load the given
plugin, and then leave the user to make their calls manually.
* All repo macros and repo/custom plugins are available.
- By default, an interactive instance will start when no dfi `root`
arguments are given.
See `root help` for details.
- If expense description exists, add description as subaccount
* This is consistent with all other legacy finance rules
- Typically, legacy institutions provide a column for category type.
Since PayPal doesn't provide that data, using the description will
provide the needed information for granular (full view) reporting.
- Removes old TODO that is no longer applicable
* End-user will need to use custom rules, if needed
