-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement sections using MultiValueProvider #43
base: dev
Are you sure you want to change the base?
Conversation
FYI: Will push current status and let you know when it is "done done". Very close to completing this one with "minimal invasive" approach, but requires a bit of "nasty" debugging in the details ("section_move" test throws with MVP enabled)… |
Helps with "MultiValueProvider" integration. While this slightly changes the logic (see "Machine::addSection -> emplace_back") I could not detect any negative effects (all tests run)…
Values are always serialized to/from MVP (currently "uncached" -> copied).
Some tests throw -> needs debugging
Using transitional class "SectionInitializer" to setup sections from "::parsArgs".
As promised -> "Done Done"! (:partying_face:) The "magic" happens in this line where actually the section start is "synchronized" (copied from FYI: |
This way MVP is populated in parallel to the SymbolTable with slight difference in value representation. (ValueSerializer is not needed anymore -> use get-/setValue to read/store values in MVP).
(moved from PR #42)
The Problem:
All bass symbols (global and local) have to be defined in a section ("default" when no section is explicitly defined).
Currently SymbolTable is unaware of this dependency and cannot always differentiate the state of a symbol.
In some cases this leads to either of
negative
or0
)The basic idea of MultiValueProvider is to define an "owner" (namely a
Section
instance) who keeps track of all its symbols while at the same time it is ensured that symbol identifiers are unique and not "already registered" by another MultiValueProvider.Values can be
None
values (e.g. a "yet to be defined" section start address)(variables are not implemented into bass at this point - ACME implements a
!set
meta command and also explains where this can be used)MVP can also be used in 2 ways:
class Section : public MultyValueProvider { … };
class Section { MultyValueProvider mvp_0; … };
Currently I don't see a use case for the second approach. Starting with the first one and see if it reveals any restrictions…Decided for variant
#2
because it better integrates with current code (and also - theoretically - allows for more complex features such as multiple MVP's in the same class context…)💡 To enable the implementation set USE_BASS_VALUEPROVIDER in
CMakeLists.txt
.Have fun experimenting! 🔬