You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 3, 2018. It is now read-only.
Right now, the solving tracer operates by writing directly to a log.Logger. This is suboptimal for implementors, as it means they can really do very little except pass the data through directly. It would be far better to instead optionally return a channel (probably from Prepare()) over which traceable events are sent, then abstract the current visualization into a standalone component that can consume those events and produce the same viz.
This would allow implementations to create their own visualizations, meta-analyses, or log the information in whatever other ways they see fit.
Unfortunately, this is may be blocked by #20, as the viz is quite tightly coupled with the traceError interface for now, and that's unlikely to evolve until we systematically attack errors.
The text was updated successfully, but these errors were encountered:
Right now, the solving tracer operates by writing directly to a
log.Logger
. This is suboptimal for implementors, as it means they can really do very little except pass the data through directly. It would be far better to instead optionally return a channel (probably fromPrepare()
) over which traceable events are sent, then abstract the current visualization into a standalone component that can consume those events and produce the same viz.This would allow implementations to create their own visualizations, meta-analyses, or log the information in whatever other ways they see fit.
Unfortunately, this is may be blocked by #20, as the viz is quite tightly coupled with the
traceError
interface for now, and that's unlikely to evolve until we systematically attack errors.The text was updated successfully, but these errors were encountered: