1. 30 Oct, 2019 2 commits
  2. 10 Jul, 2019 1 commit
  3. 27 May, 2019 3 commits
  4. 21 May, 2019 1 commit
  5. 10 May, 2019 3 commits
  6. 08 May, 2019 6 commits
  7. 05 May, 2019 1 commit
    • Daniel Selifonov's avatar
      Breaking SWIG declarations into multiple pieces · e112258f
      Daniel Selifonov authored
      Was not able to actually compile mosh_wrap.cxx that was generated
      from mosh.i, due to both include path and linking challenges.
      
      Decided to break the SWIG declarations into three separate files,
      with one for each namespace, and added pseudo-Makefiles for each
      of these three implementations that produce nearly(?) working
      wrapper artifacts.
      
      The mosh project structure requires a complex set of extra
      include paths, which is captured by those Makefiles, and the three
      generated wrappers succeed in that phase.
      
      The manual expression of extra linking objects still needs some work.
      The main errors from the wrapper compilation processes now appear to
      be caused by issues with the Protobuf dependency of mosh.
      
      Once these issues are better understood, the goal would be to convert
      these Makefile encoded parameters to the C++ compiler into the format
      expected by cgo comments. If done correctly, the cgo documentation
      suggests that SWIG will be invoked automatically, and all of the
      required objects should also be automatically incorporated into the
      build process for the final consumption by Go.
      e112258f
  8. 24 Apr, 2019 1 commit
    • Daniel Selifonov's avatar
      Adjusted semantics of *Complete.GetFramebuffer() · 97bcca64
      Daniel Selifonov authored
      These seem to be const references in the C++ implementation. Likely, these will
      refer to wrapped internal Framebuffer instances that were explicitly created and
      passed to the Complete instance. As such, no finalizer is attached to these
      references.
      
      If this analysis is correct, it is possible to retain dangling pointer references
      to these Framebuffer instances if the parent reference is finalized. To correct
      this otherwise would require some kind of reference counting.
      97bcca64
  9. 22 Apr, 2019 2 commits
    • Daniel Selifonov's avatar
      Wrapped Parser::Resize and Parser::UserByte · 46ab76ad
      Daniel Selifonov authored
      These wrappings should be adequate for using the prediction engine.
      46ab76ad
    • Daniel Selifonov's avatar
      Wrapped Terminal::Complete · ed70d9b3
      Daniel Selifonov authored
      An open question remains about GetFramebuffer of Terminal::Complete:
      should the returned Framebuffer be owned by the caller of the function,
      or should it be attached to the associated Terminal::Complete instance?
      
      Also started to implement wrappers around the two relevant Parser::Action
      sub-classes.
      ed70d9b3
  10. 21 Apr, 2019 2 commits
  11. 25 Mar, 2019 2 commits
  12. 19 Mar, 2019 1 commit
  13. 05 Feb, 2019 1 commit
  14. 01 Feb, 2019 1 commit