Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider: Adding a detailed and ubiquitous "event" logging system #200

Open
christianechevarria opened this issue Dec 24, 2019 · 4 comments
Labels
🙌 community By or for the library's community 💬 discussion Open for Socratic debate ✨ enhancement Something could be better

Comments

@christianechevarria
Copy link
Member

christianechevarria commented Dec 24, 2019

Is your feature request related to a problem? Please describe.
Unit tests are great, stack traces are great, but they only give you a snapshot of a behavior that is unexpected and a function call, respectively. During testing, the question: "what series of steps caused this error?" often arises. There's great value in being able to understand the conditions under which problems arise and test to see if the same conditions always lead to the same problems.

Describe the solution you'd like
The full-neat rewrite is introducing a network.mutations array that logs the series of mutations that have been applied to an individual network, this is very useful given the evolutionary nature of the library but ideally we could devise a way to track all operations on a per-network / per-neuron / per-unit level and inspect them later in a convenient centralized way or maybe even attaching one standard top level data-structure to each unit that we could be conditioned to check in cases of failure or questions of performance. Although we have more work to do to get the hard metrics of testing down, tools to develop quick heuristics about improving the library are also necessary.

Describe alternatives you've considered
The quick and dirty version of this is just to keep adding specialized tracking arrays to each unit, nodes, connections, networks, populations and modify the relevant functions to track changes so that we can then access those tracking arrays later. This seems inelegant, but at least for now it would help debugging and developing tremendously.

@christianechevarria christianechevarria added 💬 discussion Open for Socratic debate 🙌 community By or for the library's community ✨ enhancement Something could be better labels Dec 24, 2019
@GavinRay97
Copy link

GavinRay97 commented Dec 25, 2019

A really solid reference implementation for this would be the walkthrough and tiny amount of code needed to implement undo/redo mutations and time-travel debugging in Redux:

https://github.com/reduxjs/redux/blob/master/website/docs/recipes/ImplementingUndoHistory.md

You can apply the same sort of logic here, since Redux is just a paradigm for managing mutating stateful data.

Something that will be REALLY helpful here is the new Firefox Replay that should be released shortly (it is currently available only on Firefox Nightly for OSX):

https://firefox-replay.com/
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/WebReplay

Mozilla is constantly putting its efforts into improving Firefox’s devtools. One such effort is Firefox Replay, an experimental tool that allows Firefox content processes to record their behavior so that it can be replayed and rewound later.

The main highlight of Firefox Replay is the “code timeline” that enables you to scan through every code execution at a glance. Along with execution points, the timeline also shows exceptions, events, and network requests in real-time. It also allows you to save your recordings and pick up where you left afterward.

How Firefox Replay works:

The record and replay behavior is achieved by “controlling the non-determinism in the browser.” Initially, it records non-deterministic behaviors (intra-thread and inter-thread) and then replays it later to “force the browser to behave deterministically.”

Firefox Replay includes IPC integration to enable communication between a recording or replaying process and the chrome process. Its rewind infrastructure allows a replaying process to restore a previous state. Its debugger integration enables the JS debugger to read the required information from a replaying process and control the process’s execution.

@christianechevarria
Copy link
Member Author

christianechevarria commented Dec 25, 2019

Love the Redux undo-history, hot-linked the demo gif below just because it was so impressive

demo of todos-with-undo

Same concept but with mutation methods, disconnections, node removals, and crossovers / network merges to start. Will work excellently as part of testing / debugging suite @luiscarbonell is working on. I'd love to see the visualization implemented with @teh-mICON code for network visualizations so we can track network changes backwards and forwards in time.

Edit adding the awesome visualization by @teh-mICON for reference

@teh-mICON's network visualization demo

@micon4sure
Copy link

Could easily add mutation history, maybe even ancestry to the visualization.
Would even be possible to visually step through forward and/or backward passes.

@christianechevarria
Copy link
Member Author

christianechevarria commented Dec 25, 2019

Could easily add mutation history, maybe even ancestry to the visualization.
Would even be possible to visually step through forward and/or backward passes.

💯 Imagine having left and right arrows where you could just click through the forward / back passes and the mutations and have smooth animations of the changes that happened along with seeing a step id + general metadata on each step. This would be killer as a teaching tool

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🙌 community By or for the library's community 💬 discussion Open for Socratic debate ✨ enhancement Something could be better
Projects
None yet
Development

No branches or pull requests

3 participants