1. 11 Oct, 2021 1 commit
  2. 08 Oct, 2021 1 commit
  3. 05 Oct, 2021 4 commits
  4. 03 Oct, 2021 1 commit
  5. 30 Sep, 2021 2 commits
  6. 17 Sep, 2021 2 commits
  7. 16 Sep, 2021 2 commits
  8. 06 Sep, 2021 1 commit
    • David Edmundson's avatar
      [plugins/gpu] Initialise properties · 207b8960
      David Edmundson authored
      Properties are created in the relevant subclass via makeSensors. If an
      implementation fails to create an object we don't want dangling
      pointers.
      
      BUG: 442023
      207b8960
  9. 03 Sep, 2021 5 commits
  10. 30 Aug, 2021 3 commits
  11. 25 Aug, 2021 5 commits
    • Adriaan de Groot's avatar
      bbfce439
    • Adriaan de Groot's avatar
      viewer: drop the "rolling" display, expand diagnostics · f09dfae9
      Adriaan de Groot authored
      When viewing stats, the application waits for updates -- this
      is usually convenient to see how things change over time, but
      for scripting purposes or testing, it can be useful to get just
      one round of output. Do that by default, and introduce `--remain`
      as a flag to get the rolling displays of sensor updates the
      tool produced previously. (Suggested by Arjen)
      
      Since we now want to wait until all the requested values have
      been printed, keep track of which sensors have reported values
      and exit once they all have; this also means we need to check
      for non-existent sensors when running in just-once mode (to
      avoid hanging on typo's). In remain-mode, don't check for typo's:
      let's pretend there might be a way to dynamically add
      sensors and so an initial "typo" could be a way to refer to
      a future sensor.
      
      Additional bits:
      
      - show explicitly when there are no sensors
      - If the user mis-types a sensor name, or data is not
        available for the sensor, then tell the user that
        instead of silently not-reporting-anything.
      - use parser.addOption consistently
      f09dfae9
    • Adriaan de Groot's avatar
      ad4b8346
    • Adriaan de Groot's avatar
      freebsd-cpu: fix CPU load data retrieval · 3fea9709
      Adriaan de Groot authored
      - Calculate the sysctl prefix -- dev.cpu.<n> -- just once at creation,
        and while we're here allow CPU numbers greater than 1 digit.
      - m_container->objects() contains all the CPU objects, but also others,
        loading to out-of-bounds accesses in the loop that assumes there are
        only CPU objects.  Fix that and factor it out so that the update-cpu-
        from-sysctl-data can be called from the constructor -- this means that
        there is "initial data" for the CPU load.
      - If we've already called sysctl() to get the CPU data, we may
        as well update the CPU information because we have it, even
        if nobody is subscribed to it. So move the check for subscriptions
        to later in the update method.
      - There are (now) only the two freq and temperature sensors
        that use sysctl; there's not much point in having an additional list.
      - Add internal dox
      3fea9709
    • Adriaan de Groot's avatar
      b2031533
  12. 24 Aug, 2021 1 commit
  13. 20 Aug, 2021 1 commit
  14. 23 Jul, 2021 1 commit
  15. 16 Jul, 2021 1 commit
  16. 09 Jul, 2021 1 commit
  17. 03 Jun, 2021 2 commits
  18. 02 Jun, 2021 2 commits
  19. 30 May, 2021 1 commit
  20. 27 May, 2021 2 commits
  21. 25 May, 2021 1 commit