<azonenberg>
so i just realized the architecture i had in mind for serialization falls flat when presented with multi-type instruments
<azonenberg>
so that's fun
<azonenberg>
Going to need to think about this a bit
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
<azonenberg>
Hmmmm and the other challenge is going to be fixing this without breaking glscopeclient serialization
<azonenberg>
Since it will likely require libscopehal api changes
<azonenberg>
In particular, i think i'm gonna have to make serialization part of the instrument class
<azonenberg>
The challenge is that i cant just have one serialize method in e.g. multimeter and one in oscilloscope overriding a single pure virtual in the base
<azonenberg>
because it will break on multi type instruments
<azonenberg>
i might be able to redo the architecture a bit so that multi type drivers call each derived class's serialize method or something... still thinking
<azonenberg>
but the method signature will have to change since now i'm building one yaml node from multiple methods
<azonenberg>
e.g. a channel may have properties for both a scope and a meter under one node
<azonenberg>
And this needs to not break the v1 file format until we fully deprecate glscopeclient
<_whitenotifier-8>
[scopehal] azonenberg 468645d - Refactoring of serialization so multiple serialization methods can be called within a single instrument, allowing multi-function instruments.
bvern has joined #scopehal
bvern has quit [Remote host closed the connection]
bvernoux has joined #scopehal
bvernoux has quit [Quit: Leaving]
bvernoux has joined #scopehal
gurki has quit [Remote host closed the connection]