1. 18 Jun, 2016 1 commit
  2. 17 Jun, 2016 3 commits
  3. 16 Jun, 2016 4 commits
  4. 15 Jun, 2016 1 commit
  5. 14 Jun, 2016 1 commit
  6. 31 May, 2016 4 commits
  7. 29 May, 2016 4 commits
  8. 27 May, 2016 1 commit
  9. 26 May, 2016 2 commits
  10. 25 May, 2016 2 commits
  11. 20 May, 2016 4 commits
  12. 17 May, 2016 1 commit
    • Paul Sokolovsky's avatar
      py/stream: Support both "exact size" and "one underlying call" operations. · 7f7c84b1
      Paul Sokolovsky authored
      Both read and write operations support variants where either a) a single
      call is made to the undelying stream implementation and returned buffer
      length may be less than requested, or b) calls are repeated until requested
      amount of data is collected, shorter amount is returned only in case of
      EOF or error.
      These operations are available from the level of C support functions to be
      used by other C modules to implementations of Python methods to be used in
      user-facing objects.
      The rationale of these changes is to allow to write concise and robust
      code to work with *blocking* streams of types prone to short reads, like
      serial interfaces and sockets. Particular object types may select "exact"
      vs "once" types of methods depending on their needs. E.g., for sockets,
      revc() and send() methods continue to be "once", while read() and write()
      thus converted to "exactly" versions.
      These changes don't affect non-blocking handling, e.g. trying "exact"
      method on the non-blocking socket will return as much data as available
      without blocking. No data available is continued to be signaled as None
      return value to read() and write().
      From the point of view of CPython compatibility, this model is a cross
      between its io.RawIOBase and io.BufferedIOBase abstract classes. For
      blocking streams, it works as io.BufferedIOBase model (guaranteeing
      lack of short reads/writes), while for non-blocking - as io.RawIOBase,
      returning None in case of lack of data (instead of raising expensive
      exception, as required by io.BufferedIOBase). Such a cross-behavior
      should be optimal for MicroPython needs.
  13. 15 May, 2016 1 commit
    • Paul Sokolovsky's avatar
      extmod/modlwip: Rework how Python accept callback is called. · afce978a
      Paul Sokolovsky authored
      Calling it from lwIP accept callback will lead incorrect functioning
      and/or packet leaks if Python callback has any networking calls, due
      to lwIP non-reentrancy. So, instead schedule "poll" callback to do
      that, which will be called by lwIP when it does not perform networking
      activities. "Poll" callback is called infrequently though (docs say
      every 0.5s by default), so for better performance, lwIP needs to be
      patched to call poll callback soon after accept callback, but when
      current packet is already processed.
  14. 12 May, 2016 1 commit
  15. 03 May, 2016 1 commit
  16. 02 May, 2016 1 commit
  17. 30 Apr, 2016 1 commit
  18. 29 Apr, 2016 5 commits
  19. 28 Apr, 2016 2 commits