search

simondotm / beeb-vsc

Visual Studio Code Extension to support code development for BBC Micro
https://marketplace.visualstudio.com/items?itemName=simondotm.beeb-vsc
MIT License
13 stars 3 forks source link

Maintain global data for each compile target #102

Open tommy9 opened 5 months ago

tommy9 commented 5 months ago

As we build on BeebASM, there are single static instances for the symbol table and other internal data stores. These get reset each time we make edits. So it is possible with multiple files open to edit a file belonging to one compile target, then switch to view a file belonging to a different compile target and have lost the symbol data. Making an edit re-parses the code and brings back all functionality but it would be much nicer to maintain all data once we have created it.

Option 1) Change the static Instance methods to take the compile target as an argument, so we can keep separate track. Probably very nasty given the amount of code locations where we refer to the Instance methods. Option 2) Make workspace level data stores and transfer data after each parse to those. Will always be available with the most up to date information.

Currently thinking to implement option 2 but still not convinced.

simondotm commented 5 months ago

It's quite common for tools to make themselves a local workspace folder for caching internal data. Like .angular or .beebvsc or something like that. In my experience, such tools usually take the liberty of adding these to .gitignore as well for user convenience.

To be honest, I would say keep it as simple as possible for now. If re-parsing works asynchronously, and maybe it takes a second or two when switching files to see any updates to the editor - problems/symbol info etc. - then that will probably do just fine for our user base.

Another possibility perhaps would be to just cache this stuff in memory. Wrap each 'beebasm' context in an outer class, register statics within that, and hold references to the top level contexts (mapped by filename perhaps) in the extension top level scope, so it has the same lifecycle as the extension.

Sure if folks close vscode and re-open it will have rebuild the in-memory data structures it needs, but it wont take a terrible amount of time to do that, right?

Eslint for example takes a few seconds in some of my bigger typescript projects to get itself acquainted with my code on first load.

tommy9 commented 5 months ago

Great suggestions, thanks. It does seem to finish all the parsing in just a second or two even with large multi-file projects. Subsequent parses seem faster too, maybe due to the JIT. The idea of wrapping the 'beebasm' context sound like it might be a fairly clean way of building the target-specific statics.