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
The core hexapipes system assumes that a grid will be valid after construction.
This is a reasonable assumption for static grids, but works less well for the Penrose grid, which will be selected and generated randomly from an infinite space of possible grids.
To get it working, I split this grid into construction and initialization phases. This allows the grid to be replaced after construction of the grid object, but there is still an extra grid generated and then thrown away – actually two, because both the puzzle instance and the worker construct and then initialize their own grid objects!
This isn't too much of an efficiency concern, but it's messy, and it makes Penrose grids confusing to troubleshoot.
Compounding the problem, gridInfo in grids.js is initialized by constructing an example grid, and is instantiated on both the puzzle and the worker. So that means that a total of four Penrose grids get calculated and then thrown away on the Penrose pages, and two get thrown away on the other pages. An easy solution for this part is to make example grid construction lazy, and I've implemented this successfully in 86e8227, but it's a partial solution.
The correct solution would involve one of:
Always construct and initialize grids separately - a constructed grid would not immediately be valid.
Always wait to construct grids until we know if we have data to initialize them. Cleaner but perhaps requires deeper thought.
The text was updated successfully, but these errors were encountered:
The core hexapipes system assumes that a grid will be valid after construction.
This is a reasonable assumption for static grids, but works less well for the Penrose grid, which will be selected and generated randomly from an infinite space of possible grids.
To get it working, I split this grid into construction and initialization phases. This allows the grid to be replaced after construction of the grid object, but there is still an extra grid generated and then thrown away – actually two, because both the puzzle instance and the worker construct and then initialize their own grid objects!
This isn't too much of an efficiency concern, but it's messy, and it makes Penrose grids confusing to troubleshoot.
Compounding the problem,
gridInfo
ingrids.js
is initialized by constructing an example grid, and is instantiated on both the puzzle and the worker. So that means that a total of four Penrose grids get calculated and then thrown away on the Penrose pages, and two get thrown away on the other pages. An easy solution for this part is to make example grid construction lazy, and I've implemented this successfully in 86e8227, but it's a partial solution.The correct solution would involve one of:
The text was updated successfully, but these errors were encountered: