Skip to content
Snippets Groups Projects
  1. May 17, 2019
  2. Aug 14, 2018
    • Damien George's avatar
      py/stream: Adjust mp_stream_posix_XXX to take void*, not mp_obj_t. · 9ab816d6
      Damien George authored
      These POSIX wrappers are assumed to be passed a concrete stream object so
      it is more efficient (eg on nan-boxing builds) to pass in the pointer
      rather than mp_obj_t, because then the users of these functions only need
      to store a void* (and mp_obj_t may be wider than a pointer).  And things
      would be further improved if the stream protocol functions eventually took
      a pointer as their first argument (instead of an mp_obj_t).
      
      This patch is a step to getting ussl/axtls compiling on nan-boxing builds.
      
      See issue #3085.
      9ab816d6
  3. Jul 20, 2018
  4. Jun 18, 2018
    • Damien George's avatar
      py/stream: Introduce and use efficient mp_get_stream to access stream_p. · 6abede2c
      Damien George authored
      The existing mp_get_stream_raise() helper does explicit checks that the
      input object is a real pointer object, has a non-NULL stream protocol, and
      has the desired stream C method (read/write/ioctl).  In most cases it is
      not necessary to do these checks because it is guaranteed that the input
      object has the stream protocol and desired C methods.  For example, native
      objects that use the stream wrappers (eg mp_stream_readinto_obj) in their
      locals dict always have the stream protocol (or else they shouldn't have
      these wrappers in their locals dict).
      
      This patch introduces an efficient mp_get_stream() which doesn't do any
      checks and just extracts the stream protocol struct.  This should be used
      in all cases where the argument object is known to be a stream.  The
      existing mp_get_stream_raise() should be used primarily to verify that an
      object does have the correct stream protocol methods.
      
      All uses of mp_get_stream_raise() in py/stream.c have been converted to use
      mp_get_stream() because the argument is guaranteed to be a proper stream
      object.
      
      This patch improves efficiency of stream operations and reduces code size.
      6abede2c
  5. Jun 04, 2018
    • Damien George's avatar
      py/stream: Move definition of mp_stream_p_t from obj.h to stream.h. · 1427f8f5
      Damien George authored
      Since a long time now, mp_obj_type_t no longer refers explicitly to
      mp_stream_p_t but rather to an abstract "const void *protocol".  So there's
      no longer any need to define mp_stream_p_t in obj.h and it can go with all
      its associated definitions in stream.h.  Pretty much all users of this type
      will already include the stream header.
      1427f8f5
  6. May 01, 2018
    • Ayke van Laethem's avatar
      py/stream: Use uPy errno instead of system's for non-blocking check. · d43c7377
      Ayke van Laethem authored
      This is a more consistent use of errno codes.  For example, it may be that
      a stream returns MP_EAGAIN but the mp_is_nonblocking_error() macro doesn't
      catch this value because it checks for EAGAIN instead (which may have a
      different value than MP_EAGAIN when MICROPY_USE_INTERNAL_ERRNO is enabled).
      d43c7377
  7. Apr 10, 2018
    • Damien George's avatar
      py/stream: Switch stream close operation from method to ioctl. · cf31d384
      Damien George authored
      This patch moves the implementation of stream closure from a dedicated
      method to the ioctl of the stream protocol, for each type that implements
      closing.  The benefits of this are:
      
      1. Rounds out the stream ioctl function, which already includes flush,
         seek and poll (among other things).
      
      2. Makes calling mp_stream_close() on an object slightly more efficient
         because it now no longer needs to lookup the close method and call it,
         rather it just delegates straight to the ioctl function (if it exists).
      
      3. Reduces code size and allows future types that implement the stream
         protocol to be smaller because they don't need a dedicated close method.
      
      Code size reduction is around 200 bytes smaller for x86 archs and around
      30 bytes smaller for the bare-metal archs.
      cf31d384
  8. Aug 20, 2017
  9. Jul 31, 2017
  10. Jul 18, 2017
    • Alexander Steffen's avatar
      all: Unify header guard usage. · 299bc625
      Alexander Steffen authored
      The code conventions suggest using header guards, but do not define how
      those should look like and instead point to existing files. However, not
      all existing files follow the same scheme, sometimes omitting header guards
      altogether, sometimes using non-standard names, making it easy to
      accidentally pick a "wrong" example.
      
      This commit ensures that all header files of the MicroPython project (that
      were not simply copied from somewhere else) follow the same pattern, that
      was already present in the majority of files, especially in the py folder.
      
      The rules are as follows.
      
      Naming convention:
      * start with the words MICROPY_INCLUDED
      * contain the full path to the file
      * replace special characters with _
      
      In addition, there are no empty lines before #ifndef, between #ifndef and
      one empty line before #endif. #endif is followed by a comment containing
      the name of the guard macro.
      
      py/grammar.h cannot use header guards by design, since it has to be
      included multiple times in a single C file. Several other files also do not
      need header guards as they are only used internally and guaranteed to be
      included only once:
      * MICROPY_MPHALPORT_H
      * mpconfigboard.h
      * mpconfigport.h
      * mpthreadport.h
      * pin_defs_*.h
      * qstrdefs*.h
      299bc625
  11. Dec 02, 2016
  12. Nov 13, 2016
  13. Oct 21, 2016
    • Damien George's avatar
      py: Be more specific with MP_DECLARE_CONST_FUN_OBJ macros. · 4ebdb1f2
      Damien George authored
      In order to have more fine-grained control over how builtin functions are
      constructed, the MP_DECLARE_CONST_FUN_OBJ macros are made more specific,
      with suffix of _0, _1, _2, _3, _VAR, _VAR_BETEEN or _KW.  These names now
      match the MP_DEFINE_CONST_FUN_OBJ macros.
      4ebdb1f2
  14. Jul 30, 2016
  15. Jul 29, 2016
  16. Jul 26, 2016
  17. Jul 24, 2016
  18. May 20, 2016
  19. May 17, 2016
    • 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.
      7f7c84b1
  20. Apr 10, 2016
  21. Apr 05, 2016
  22. Mar 24, 2016
  23. Dec 09, 2015
  24. Nov 29, 2015
  25. Oct 18, 2015
  26. Aug 13, 2015
  27. Jan 01, 2015
  28. Nov 16, 2014
  29. Oct 18, 2014
  30. Jul 13, 2014
  31. May 03, 2014
  32. Jan 20, 2014
  33. Jan 15, 2014
  34. Jan 13, 2014
  35. Jan 08, 2014
Loading