azonenberg changed the topic of #scopehal to: ngscopeclient, libscopehal, and libscopeprotocols development and testing | https://github.com/ngscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
sgstair_ has quit [Ping timeout: 268 seconds]
sgstair has joined #scopehal
<_whitenotifier-6> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±8] https://github.com/ngscopeclient/scopehal/compare/07dcb46fa222...bde5d98cf669
<_whitenotifier-5> [scopehal] azonenberg bde5d98 - Initial shared_ptr refactoring for BERTs
<_whitenotifier-5> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±11] https://github.com/ngscopeclient/scopehal-apps/compare/82a24ac5f579...15dff33e8752
<_whitenotifier-6> [scopehal-apps] azonenberg 15dff33 - Initial shared_ptr refactoring for BERTs
<azonenberg> ok so this is the first test step in what will eventually be a broader refactoring moving away from manual refcounting and raw pointers
<azonenberg> non-scope instruments are coming first, scopes will be the end as that's going to be a far more invasive refactoring
<azonenberg> and once i've done all the instrument types there's a bunch more cleanup coming
<d1b2> <vipqualitypost> woohoo! excited to see it
<azonenberg> There's still a bunch of open architectural questions and i expect there to be some changes to how i do things as the design evolves
<azonenberg> but it needs to happen for sure
<azonenberg> this should improve stability but also just make the code cleaner
<azonenberg> as part of this i'm moving away from the concept of properties dialogs owning an instrument
<azonenberg> which was dumb to begin with
<azonenberg> they'll now be kept around as long as anything references them
<azonenberg> at some point we will need a way to remove an instrument from a session (which is to say, find everything using it and make them go away)
<azonenberg> But that's not trivial and may tie into the eventual plan of being able to swap out instruments with mocks if we want to take them offline or lose connectivity
<azonenberg> The other big refactoring planned is making the idea of separate dynamic creation tables and creation methods for each instrument class go away
<azonenberg> we need to have just one for creating an instrument
<azonenberg> because if an instrument is, say, both a scope and a function generator
<azonenberg> it might be obvious what our API calls it
<azonenberg> but if it's say a bert and a switch matrix? less obvious
<azonenberg> but yeah there is at least one segfault right now that is annoying me, but that the proper fix for is just to fix ownership rather than trying to hack on more refcounting :p
<_whitenotifier-5> [stm32-cpp] azonenberg 84c2d80 - Comment clarification
<_whitenotifier-6> [stm32-cpp] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/azonenberg/stm32-cpp/compare/cd2dc523b284...84c2d8035470
Stephie has quit [Quit: Fuck this shit, I'm out!]
Stephie has joined #scopehal