[GRID/ASYNC]: Create new modules in place of SoundMatrix

[martin-henz]

The module should just be called “grid” or maybe “grid”. It should be independent of sound. And the number of rows and columns should be configurable.

The current sound_matrix module also has the functions set_timeout and clear_all_timeout. That’s clearly wrong. We should have a separate module “asynchronous” for these:

• set_timeout
• clear_timeout
• clear_all_timeout
• set_interval
• clear_interval
• clear_all_interval

[Cloud7050]

Preliminary Findings

• Module is currently called sound_matrix. There is a lot of use of the word "matrix" throughout the module, as well as the word "sound". There appear to be unused constants left over
• Module's code appears independent of the sound module, in that the grid is simply a means for the user to decide what code they wish to execute based on currently active tiles
• The current row and column size appears to be a fixed 16x16 square grid. There appear to be many hardcoded values in the code that work with this, such as 15, 16
  • I picture the current user flow to be running their code, receiving an error telling them to activate the grid by clicking its tab, toggling the tiles as desired, then rerunning their code proper
  • Users would need a way to specify a custom size (within reasonable limits) prior to execution of grid-related functions, perhaps by using a new one-off initialisation function towards the start. But this would mean the user having to repeat the above flow, to first have the new size reflected and to toggle new tiles, before rerunning again
  • By nature of its purpose, the current grid should already have a way to persist the user's toggling of tile states between executions. This opens up the possibility of instead adding more intuitive UI elements to change sizes while having the grid update dynamically, with that new size then passed on to the next execution
• ToneMatrix is exposed to the user, but should probably be exported in a different way for internal use
• 4 functions are exposed to the user, of which clear_matrix appears as a reference in the documentation due to being a method of ToneMatrix. The generated documentation elaborates that it "Renames and re-exports __type", which links to verbose details of ToneMatrix. This distinction is probably unimportant/confusing to the user
• The functions do not have generated documentation explaining them
• 2 of the functions are set_timeout and clear_all_timeout. Indeed these could fit in their own new module instead, given how the grid is now more focused in purpose, having been converted into a proper module
• 4 more timeout/interval-related functions which do not currently exist have been mentioned in the issue. Currently, the user is only able to clear all timeouts and cannot use intervals. The user would need a way to specify or refer to the individual timeout or interval they wish to clear

[Cloud7050]

See also: #212 (comment)

source-academy/js-slang@8d3b2e3 appears to be live, but last bump was before that to V1.0.29. Live modules appear to still be using the reversed accumulate.

I am able to get the fixed behaviour when serving my own built modules locally.

[Cloud7050]

Bug:

The way in which ToneMatrix is exported appears to impact clear_matrix's usability not just in the documentation, making it unable to be imported and used.

'sound_matrix' does not contain a definition for 'clear_matrix'

[Cloud7050]

The module's tab can be spawned by entering "test"; into the REPL. There appears to be the lack of a crucial link between the tab and bundle, which would allow the bundle's timeout code to be aware of the changing grid state. I am unable to get matrix to populate in the existing implementation. I am experimenting with the newer module states feature.

I also notice there is a duplicated Source "list" library used by the module (list.ts). We may now be able to import js-slang's for use in the module.

[Cloud7050]

The existing Canvas appears to function by way of fluke. The ToneMatrix object available globally appears to be from the hardwired frontend library, as opposed to the module, but this is what the module ends up using. The module's own ToneMatrix functions do not fire when the canvas is clicked, nor are its custom colours etc used, rather, the hardwired library's are.