There will be a short amount of downtime, for git.ligo.org, docs.ligo.org, and chat.ligo.org, starting around approximately 10am CDT on Tuesday 18th June 2019. This is to enable access controls for GitLab Pages. More information can be found here.

  1. 27 Feb, 2019 2 commits
  2. 26 Feb, 2019 1 commit
  3. 09 Feb, 2019 4 commits
  4. 07 Feb, 2019 3 commits
  5. 06 Feb, 2019 7 commits
  6. 05 Feb, 2019 1 commit
  7. 04 Feb, 2019 2 commits
    • Jameson Rollins's avatar
      Release 1.3.0 · dde2d1fc
      Jameson Rollins authored
      dde2d1fc
    • Jameson Rollins's avatar
      improved guardctrl remote interface · 0832b98e
      Jameson Rollins authored
      All guardctrl handling moved into the python module (both local and remote).
      
      Use json encoding to pass arguments to SSH_ORIGINAL_COMMAND, which is a much
      more robust way of handling argument spaces, and unbreaks various option
      handling.
      
      The guardlog command is re-purposed to exclusively handle opening logs in
      an xterm.
      0832b98e
  8. 02 Feb, 2019 2 commits
  9. 01 Feb, 2019 9 commits
  10. 31 Jan, 2019 1 commit
  11. 03 Aug, 2018 2 commits
  12. 18 Jun, 2018 1 commit
  13. 08 May, 2018 1 commit
  14. 07 May, 2018 1 commit
  15. 26 Apr, 2018 3 commits
    • Jameson Rollins's avatar
    • Jameson Rollins's avatar
      daemon: tweak loop timing diagnostics · d31ed108
      Jameson Rollins authored
      clarify int microseconds.
      d31ed108
    • Jameson Rollins's avatar
      don't update cas driver PV values after every setitem · 0478c9e6
      Jameson Rollins authored
      Here we do batch updating of the driver PVs, rather than after every setitem.
      driver.updatePVs is a heavy operation, proving to be most of the CPU load
      during profiling.  Batch updating reduces the number of updatePVs calls by an order of magnitude, from
      roughly 100 per cycle (when coupled with cas.__setitem__) to roughly 10 in
      the current implementation.
      
      Unfortunately there's some way that updatePVs seems to affect client writes
      that is not yet understood.  We should only have to call updatePVs twice in
      the main loop to push out all updates.  But some weird behavior was observed,
      where client writes didn't seem to take affect.  This needs to be investigated
      more, but in the mean time calling updatePVs around process seems to behave
      ok.
      
      The ordering in the channel updates as seen by the tests changes slightly,
      since all updates happen as a batch rather than individually when they are
      set.
      0478c9e6