if a template (built-in, downloaded or otherwise) doesn't supply its own
dot.gitignore file then templates/dot.gitignore will be used
also, update dot.gitignore to ignore chains.json by default
The API endpoint listening for a dump of process logs was not returning logs properly for two reasons:
1. The `id` field was being appended to each log. This had been moved to the `handleLog` function of the `LogHandler`.
2. The slice needed to grab logs from the end, so the `limit` was made negative on the `.slice()`.
Default behavior of logging to file is no longer needed now that Embark log history can be properly served using the `ProcessLogsApi` and `LogHandler` classes.
# Conflicts:
# lib/core/logger.js
# lib/modules/blockchain_process/blockchain.js
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
When running `embark blockchain` followed by `embark run` previously, logs generated in the standalone `embark blockchain` process were black boxed and not accessible to the main Embark process.
This is fixed by creating a client IPC connection in the `embark blockchain` process that connects to the IPC server connection running in `embark run`. The connection is made by way of polling `ipc.connect` and continues polling even after a connection is made in case `embark run` is killed and restarted without restarting `embark blockchain`.
`LogHandler` was introduced to extrapolate functionality used in `ProcessLauncher` that needed to also be used in the standalone blockchain process. It also caps the number of logs that are stored in memory per process by a constant value defined in `constants.json`.
A `blockchain_listener` was module was created (and run inside of `embark run`) that listens for logs emitted by the `embark blockchain` client IPC and runs them through the `LogHandler`. Additionally, this module registers the API endpoints needed to handle requests for blockchain process logs in the cockpit (which were 404’ing before).
# Conflicts:
# lib/modules/blockchain_process/blockchain.js
display last line on tx
fix debugger call
listen to source event only after jumping to the end
keep track of last tx; add minimal debug feature; fix ast issue
initial debugger apis & ui integration
prevent crash when step is out of bounds; send all all available data in websocket
add debugger commands
fix line number tracking in editor; toggle breakpoints
replace timeouts with callbacks
add debugger manager & refactor
refactor debugger api
refactor cmd line debugger
reduce debugger decoupling
reduce debugger decoupling
fix debug buttons
trigger source update so api triggers ws event to update source location
move locals and contracts vars to a json view
improve debugger icons
simplify debugger data
update debug package
add command handler to get a contract given a tx; update debugger so it can get a contract by its tx instead of tracking latest txs only
update debugger package
Iuri Matias
Jonathan Rainville
andrea zuccarini
Anthony Laibe
Eric Mastro
Michael Bradley, Jr
André Medeiros