1. 13 Mar, 2018 1 commit
  2. 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
  3. 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
  4. 29 Jan, 2018 1 commit
  5. 22 Jan, 2018 4 commits
  6. 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
  7. 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
  8. 28 Oct, 2017 9 commits
  9. 17 Oct, 2017 19 commits
  10. 16 Oct, 2017 1 commit