GEMMonitor used to be more widespread in the gem code base since the monitoring was more diffuse. Now that most of it is concentrated to the
gemmonitor area, the logic of the class is overwrought for its current use. To put this in perspective, the only class that seems to actively use it's functionality if the
GEMSupervisorMonitor class, and this may not be in use considering the monitoring tab for the XDAQ page has nothing in it currently
Currently, the class has two layers for specifying a monitorable, first the infoSpace it is a part of and also the MonitorableSet it is a part of. In
GEMSupervisorMonitor, there is only on MonitorableSet making the need for this distinction unnecessary. This can also mean the ~4 data containers used to disambiguate information about the infoSpaces and monitorableSets and get the information from both now only require 1 datacontainer. The data container was also changed to avoid confusing instances of pairs so there aren't lines of code that look like
monitem->second.first.regName or something similar. The code should be much more readable.
Personally, I am of the mind that GEMMonitor should be delete (see #148 (closed)) or at the very least refactored to the point it would be a useful parent class for objects such as
AMCMonitor. But this MR is to take a more middle road approach and refactor the current code to be better adapted for future use if wanted.
refers to #148 (closed)
GEMSupervisor was initialized without any hitch (this calls the startMonitor command) and the timerEvent trips
Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
My code follows the code style of this project.
My change requires a change to the documentation.
I have updated the documentation accordingly.
I have read the CONTRIBUTING document.
I have added tests to cover my changes.
All new and existing tests passed.