Generate the core register interface - #135
Merged
Merged
Conversation
Metadata that names no device now generates an interface to the core register set: the register classes, their payload types and an address map, without the device operators. The seven device-scoped types are omitted, and five of them would otherwise collide with the hand-written operators of the same name in Bonsai.Harp. No asynchronous interface is generated, and the implementation no longer enumerates a file for it, so a consumer writing the generated files produces only one. DeviceMetadata gains IsApplicationDevice, which both targets now share rather than the Python target computing its own. The core register metadata can now drop its device name.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Metadata without a device name now generates an interface to the core register set rather than failing to compile. The register classes, their payload types, the
Timestampedvariants, the per-register payload operators and the address map are all generated as before; the operators that describe a device are not.What is omitted
Seven types:
GetDeviceMetadata,GroupByRegister,DeviceDataWriter,FilterRegister,Parse,FormatandCreateMessage.Five of them collide by name with hand-written general-purpose operators in
Bonsai.Harp, atCreateMessage.cs,FilterRegister.cs,Format.cs,GroupByRegister.csandParse.cs. Generating them for the core register schema would be duplicate type definitions in the same namespace. The remaining two are device-scoped by nature, one writing a device-named storage folder and the other returning a device metadata file.The
Deviceclass is reshaped into its common form as a plainpartial class Deviceholding just a standaloneRegisterMap, without theBonsai.Harp.Devicebase, theWhoAmIconstant,INamedElementor the attributes that make it a source operator. No asynchronous interface is generated.How the two cases are told apart
DeviceMetadata.IsApplicationDevicereports whether the metadata names a device, mirroring the schema layering directly: a document carryingdeviceis adevice.jsondocument, one without is aregisters.jsondocument. Both targets now read it, where the Python target previously computed its own equivalent from register addresses.A device declaring no registers stays on the device path and generates exactly what it did before, which the register-count guards around the four operators that index the first register continue to protect.
Evidence
The generated common interface now matches the hand-maintained
Bonsai.Harpreference exactly on types, 66 against 66, having previously carried seven extras. It contains nonameofat all, which is what allowed the core register metadata to drop its device name; doing so changed no generated output, confirming the name was already unreferenced.Closes #134