<_whitenotifier-7>
[scopehal] azonenberg d6cd998 - Minor cosmetic cleanup to AC RMS measurement. Renamed AC RMS and Burst Width measurements to match overall project naming conventions.
<azonenberg>
mughees: ok, i just merged it. note that i did rename this and your previous filter
<azonenberg>
BurstWidth -> Burst Width, AC RMS Measurement -> AC RMS
<azonenberg>
This will break any existing .scopesession files you may have using the old filter names, but they're plain text so it's trivial to update them to use the new name
<d1b2>
<Mughees> Ok
<d1b2>
<Mughees> Do we have review process?
<d1b2>
<Mughees> Code review….
<azonenberg>
I reviewed your PRs before merging them but missed the missing space in the name when i reviewed the last one
<azonenberg>
only caught it when looking at the right click menu earlier today
<d1b2>
<Mughees> Ok
<azonenberg>
Longer term I'd like to have a couple of other core devs that I trust to do code reviews able to approve and merge PRs too, just to take the workload off me. Louis will probably end up in that role eventually if things continue to go the way they are
<azonenberg>
and/or you
<azonenberg>
But that's months out at minimum
<azonenberg>
Right now we're in that tricky stage where the number of contributors is growing, but we don't yet have the staffing to support a lot of new people because i have to hand-hold all of the new team members myself
<azonenberg>
so as soon as i can shift that responsibility off to others, we'll be able to pick up the pace
<_whitenotifier-7>
[starshipraider] azonenberg bddf47f - Updated AKL-PT5 design for v0.9
<_whitenotifier-7>
[starshipraider] azonenberg a708ceb - Added PT5 simulations for v0.9
<d1b2>
<louis> Awesome!
<azonenberg>
louis: btw how do you feel about helping out w/ GSoC some time in the future? assuming we can get approved / get things ready on our end in time
<azonenberg>
it's definitely on the list of things i want to work on, i hope summer 2023 will be viable
<d1b2>
<ehntoo> Finally getting back to my power supply driver refactor. Does anyone have strong thoughts on an "include what you use" approach to includes in headers? I notice that most header files in scopehal do not have any includes in them at present, so when looking at something like RohdeSchwarzHMC804xPowerSupply.h in isolation, classes like "SCPIDevice" "SCPIPowerSupply" aren't given any context - you need to also look at the .cpp file to see where
<d1b2>
those classes come from.
<azonenberg>
ehntoo: so, forward declarations are good wrt reducing compile times
<azonenberg>
but blindly including every single class in every file is not good either
<azonenberg>
we actually have a pending ticket for optimization on that front
<azonenberg>
having less stuff include e.g. scopeprotocols.h and pulling in only the files that they specifically need
<d1b2>
<ehntoo> yeah, for something like RohdeSchwarzHMC804xPowerSupply.h I'm thinking including the classes that RohdeSchwarzHMC804xPowerSupply directly inherits from (SCPIDevice, SCPIPowerSupply) and <string> would be about it
<d1b2>
<ehntoo> possibly not even SCPIDevice
<azonenberg>
yeah. in particular what i want to avoid is having every filter class .h included in every source file
<azonenberg>
we have a lot more of this than i want and i think its one of the contributor to slow compile times
<azonenberg>
Still a few little fixes to work on but i think its at the point that i can merge to get more eyes on it
<azonenberg>
i'm testing it locally and will review the diff then upstream later today
<azonenberg>
there's known issues around destroying vk objects in the wrong order at shutdown that have to be addressed
<azonenberg>
lain: btw, this is something i spent a whiel working on in ngscopeclient. the paradigm i usually used was vk::raii objects in std::unique_ptr instances
<azonenberg>
that i set to nullptr in the destructor
<azonenberg>
this lets you force destruction at a time of your choice
<lain>
azonenberg: aha, that sounds like a good pattern to stick to
<azonenberg>
yeah. so if you want to roll that in and update the fork i'll hold off on reviewing/merging until you fix that?
<azonenberg>
and yeah this is a pattern i plan to start using more in the scopehal backend
<azonenberg>
i'm thinking of replacing the factory objects to return std::shared_ptr objects too
<azonenberg>
it will simplify some of the explicit refcounting stuff i have at the moment
<azonenberg>
but that's something to do later on
<azonenberg>
Smart pointers were not a thing when i started this codebase
<azonenberg>
at least not without using boost or some external libs
<lain>
azonenberg: rgr, I'll update the branch with those changes
<d1b2>
<ehntoo> still need to knock out the docs additions, but I think I've addressed all the points you made re: code. C++ isn't my strongest language, let me know if any of the inheritance changes or method declarations I've made are objectionable
<azonenberg>
ok i'll look. lain's renderer work is ahead of you in the queue though
<azonenberg>
so might be a bit
<d1b2>
<ehntoo> no worries. gives me time to do the docs changes. 🙂
<azonenberg>
lain: btw, you will need to disable the check for GL 4.3 now moving forward when you test on mac
<azonenberg>
try setting 4.0 as minimum to start. i think you can go lower
<azonenberg>
we also of course will no longer need GL_ARB_compute_shader