1. 22 Mar, 2019 1 commit
  2. 18 Mar, 2019 1 commit
  3. 15 Mar, 2019 1 commit
  4. 14 Mar, 2019 1 commit
  5. 06 Mar, 2019 2 commits
  6. 04 Mar, 2019 1 commit
  7. 22 Feb, 2019 2 commits
  8. 08 Feb, 2019 2 commits
  9. 07 Feb, 2019 1 commit
  10. 06 Feb, 2019 2 commits
  11. 02 Oct, 2018 1 commit
  12. 31 Aug, 2018 1 commit
  13. 14 Aug, 2018 1 commit
  14. 18 Jul, 2018 2 commits
  15. 24 May, 2018 1 commit
    • Kevin's avatar
      Refinement (#19) · 7370f1c5
      Kevin authored
      * Simplify uuid.Reverse method
      
      * Add uuid test
      
      * Fix linting issues
      7370f1c5
  16. 04 Apr, 2018 2 commits
  17. 16 Mar, 2018 2 commits
  18. 13 Mar, 2018 1 commit
  19. 08 Mar, 2018 1 commit
    • Naoki Takano's avatar
      Fix deadlock (#9) · 4f0cfa41
      Naoki Takano authored
      * Bump up the number of command channels and changed not to exit
      
      * Clean up
      
      * revert smiple ' to fancy '
      
      * Changed the error handling
      4f0cfa41
  20. 01 Feb, 2018 2 commits
    • Jacob Rosenthal's avatar
      More Highsierra work (#7) · cb19fdfd
      Jacob Rosenthal authored
      * perhaps notify flag used to be set in yosemite? this blocks on sierra now
      
      * few more xpcids for sierra
      cb19fdfd
    • ccollins476ad's avatar
      linux - Don't log "can't accept" error on close. (#8) · 8725f322
      ccollins476ad authored
      This is a hack which silences an extraneous log message.  The message
      gets reported due to an apparent race condition involving the
      `sktLoop()` function in `linux/hci/hci.go`.  This function implements a
      socket-read loop that only returns on error.  It is called as a
      Goroutine, and typically continues to run until the process terminates.
      
      If client code closes the owning `Device` at an inopportune time
      (presumably during the socket read), the `Read()` call returns an
      `io.EOF` error, which causes `NewDevice()` to log the following message:
      
          can't accept: skt: EOF
      
      Since the API permits the user to close the device at any time, this
      error message is extraneous.
      
      This commit simply inhibits the logging of the error message in case of
      EOF.  This is not a long-term solution, but it does fix the visible
      issue.
      8725f322
  21. 29 Jan, 2018 1 commit
  22. 22 Jan, 2018 4 commits
  23. 16 Dec, 2017 1 commit
    • ccollins476ad's avatar
      Interpret missing kCBMsgArgResult as success. (#5) · 07787027
      ccollins476ad authored
      This commit addresses a panic that occurs in older versions of MacOS
      (tested with 10.11.5).  The problem occurs because, on this machine, the
      DiscoverDescriptors response lacks a `kCBMsgArgResult` field.  This
      missing field must have gotten fixed in a subsequent version of MacOS.
      Here are the contents of the DiscoverDescriptors response:
      
      ```
      map[kCBMsgArgCharacteristicHandle:17 kCBMsgArgDeviceUUID:3e8e65b72da94f70bbbe2d8f1a2524ee kCBMsgArgDescriptors:[]]
      ```
      
      The fix is to treat a response that lacks the `kCBMsgArgResult` field as
      indicating success.  That is, pretend `kCBMsgArgResult` is 0.
      07787027
  24. 27 Nov, 2017 1 commit
    • Kevin's avatar
      Cleanup XPC and add some errors (#4) · c88cfeb1
      Kevin authored
      * XPC cleanup
      
      * Go Meta Linter
      
      * Update travis with linux
      
      * Fix unintroduced interface
      
      * Fix travis.yml
      
      * Fix travis.yml
      
      * Fix travis.yml
      
      * Add GOOS to Travis
      
      * Damn travis
      
      * Finally?
      
      * Goddamn travis
      c88cfeb1
  25. 28 Oct, 2017 5 commits