partially resolves #52 by rendering the current solution during the full search every time it changes
also for easier debugging of webworker panics, adds the console_error_panic_hook package
the current implementation adds a callback to the MacroSolver. the macro solver will only start calling this callback if it reaches the full search step. every time the solution local variable changes, it backtraces the actions in the solution and calls the callback.
for most test cases this callback can be a no-op. for the webworker, the callback copies the list of actions to main thread, along with a boolean flag to indicate if this is a tentative solution or the final result. this boolean value is copied directly into the solver_pending field on the App.
i'm not sure if this is idiomatic Rust code. I initially tried writing this as an Option because that made sense to me, but about every source I consulted said that this was a really bad idea and that it was much simpler to pass a no-op as the callback if the caller didn't want to use it. i'm pretty sure this is at worst a tiny slowdown though, since the solution doesn't change often
also, MacroResult is an Option<(Vec, bool)> now, which is a little awkward. It might be nicer to make MacroResult the inside tuple or its own struct and have the webworker output Option instead?
partially resolves #52 by rendering the current solution during the full search every time it changes also for easier debugging of webworker panics, adds the console_error_panic_hook package
the current implementation adds a callback to the MacroSolver. the macro solver will only start calling this callback if it reaches the full search step. every time the
solution
local variable changes, it backtraces the actions in the solution and calls the callback.for most test cases this callback can be a no-op. for the webworker, the callback copies the list of actions to main thread, along with a boolean flag to indicate if this is a tentative solution or the final result. this boolean value is copied directly into the
solver_pending
field on the App.i'm not sure if this is idiomatic Rust code. I initially tried writing this as an Option because that made sense to me, but about every source I consulted said that this was a really bad idea and that it was much simpler to pass a no-op as the callback if the caller didn't want to use it. i'm pretty sure this is at worst a tiny slowdown though, since the solution doesn't change often
also, MacroResult is an Option<(Vec, bool)> now, which is a little awkward. It might be nicer to make MacroResult the inside tuple or its own struct and have the webworker output Option instead?