remove qemu-arm build; fix docs build bugs
This commit is contained in:
parent
bfbb5cde5a
commit
c76a4d477f
@ -26,7 +26,6 @@ env:
|
||||
- TRAVIS_BOARD=gemma_m0
|
||||
- TRAVIS_BOARD=feather52832
|
||||
- TRAVIS_BOARD=pca10056
|
||||
- TRAVIS_TEST=qemu
|
||||
- TRAVIS_TEST=unix
|
||||
- TRAVIS_TEST=docs
|
||||
|
||||
@ -49,9 +48,8 @@ notifications:
|
||||
before_script:
|
||||
- sudo dpkg --add-architecture i386
|
||||
|
||||
- ([[ -z "$TRAVIS_TEST" ]] || sudo apt-get install -y qemu-system)
|
||||
- ([[ -z "$TRAVIS_BOARD" ]] || (wget https://s3.amazonaws.com/adafruit-circuit-python/gcc-arm-embedded_7-2018q2-1~trusty1_amd64.deb && sudo dpkg -i gcc-arm-embedded*_amd64.deb))
|
||||
- ([[ $TRAVIS_TEST != "qemu" ]] || (wget https://s3.amazonaws.com/adafruit-circuit-python/gcc-arm-embedded_7-2018q2-1~trusty1_amd64.deb && sudo dpkg -i gcc-arm-embedded*_amd64.deb))
|
||||
- wget https://s3.amazonaws.com/adafruit-circuit-python/gcc-arm-embedded_7-2018q2-1~trusty1_amd64.deb && sudo dpkg -i gcc-arm-embedded*_amd64.deb
|
||||
|
||||
# For nrf builds
|
||||
- ([[ $TRAVIS_BOARD != "feather52832" && $TRAVIS_BOARD != "pca10056" ]] || sudo ports/nrf/drivers/bluetooth/download_ble_stack.sh)
|
||||
@ -80,10 +78,6 @@ script:
|
||||
- ([[ $TRAVIS_TEST != "unix" ]] || make -C ports/unix coverage -j2)
|
||||
- echo -en 'travis_fold:end:unix\\r'
|
||||
|
||||
- echo 'Building qemu' && echo -en 'travis_fold:start:qemu\\r'
|
||||
- ([[ $TRAVIS_TEST != "qemu" ]] || make -C ports/qemu-arm test -j2)
|
||||
- echo -en 'travis_fold:end:qemu\\r'
|
||||
|
||||
# run tests without coverage info
|
||||
#- (cd tests && MICROPY_CPYTHON3=python3.4 ./run-tests -j1)
|
||||
#- (cd tests && MICROPY_CPYTHON3=python3.4 ./run-tests -j1 --emit native)
|
||||
@ -115,4 +109,3 @@ script:
|
||||
|
||||
after_failure:
|
||||
- (cd tests && for exp in *.exp; do testbase=$(basename $exp .exp); echo -e "\nFAILURE $testbase"; diff -u $testbase.exp $testbase.out; done)
|
||||
- (grep "FAIL" ports/qemu-arm/build/console.out)
|
||||
|
1
conf.py
1
conf.py
@ -108,6 +108,7 @@ exclude_patterns = ["**/build*",
|
||||
"ports/cc3200",
|
||||
"ports/cc3200/FreeRTOS",
|
||||
"ports/cc3200/hal",
|
||||
"ports/esp32",
|
||||
"ports/esp8266/boards",
|
||||
"ports/esp8266/common-hal",
|
||||
"ports/esp8266/modules",
|
||||
|
@ -1,12 +0,0 @@
|
||||
:mod:`_thread` -- multithreading support
|
||||
========================================
|
||||
|
||||
.. module:: _thread
|
||||
:synopsis: multithreading support
|
||||
|
||||
|see_cpython_module| :mod:`python:_thread`.
|
||||
|
||||
This module implements multithreading support.
|
||||
|
||||
This module is highly experimental and its API is not yet fully settled
|
||||
and not yet described in this documentation.
|
@ -7,7 +7,7 @@
|
||||
:synopsis: simple BTree database
|
||||
|
||||
The ``btree`` module implements a simple key-value database using external
|
||||
storage (disk files, or in general case, a random-access `stream`). Keys are
|
||||
storage (disk files, or in general case, a random-access ``stream``). Keys are
|
||||
stored sorted in the database, and besides efficient retrieval by a key
|
||||
value, a database also supports efficient ordered range scans (retrieval
|
||||
of values with the keys in a given range). On the application interface
|
||||
|
@ -47,17 +47,6 @@ Functions
|
||||
|
||||
The default optimisation level is usually level 0.
|
||||
|
||||
.. function:: alloc_emergency_exception_buf(size)
|
||||
|
||||
Allocate *size* bytes of RAM for the emergency exception buffer (a good
|
||||
size is around 100 bytes). The buffer is used to create exceptions in cases
|
||||
when normal RAM allocation would fail (eg within an interrupt handler) and
|
||||
therefore give useful traceback information in these situations.
|
||||
|
||||
A good way to use this function is to put it at the start of your main script
|
||||
(eg ``boot.py`` or ``main.py``) and then the emergency exception buffer will be active
|
||||
for all the code following it.
|
||||
|
||||
.. function:: mem_info([verbose])
|
||||
|
||||
Print information about currently used memory. If the *verbose* argument
|
||||
@ -102,38 +91,3 @@ Functions
|
||||
This function can be used to prevent the capturing of Ctrl-C on the
|
||||
incoming stream of characters that is usually used for the REPL, in case
|
||||
that stream is used for other purposes.
|
||||
|
||||
.. function:: schedule(func, arg)
|
||||
|
||||
Schedule the function *func* to be executed "very soon". The function
|
||||
is passed the value *arg* as its single argument. "Very soon" means that
|
||||
the MicroPython runtime will do its best to execute the function at the
|
||||
earliest possible time, given that it is also trying to be efficient, and
|
||||
that the following conditions hold:
|
||||
|
||||
- A scheduled function will never preempt another scheduled function.
|
||||
- Scheduled functions are always executed "between opcodes" which means
|
||||
that all fundamental Python operations (such as appending to a list)
|
||||
are guaranteed to be atomic.
|
||||
- A given port may define "critical regions" within which scheduled
|
||||
functions will never be executed. Functions may be scheduled within
|
||||
a critical region but they will not be executed until that region
|
||||
is exited. An example of a critical region is a preempting interrupt
|
||||
handler (an IRQ).
|
||||
|
||||
A use for this function is to schedule a callback from a preempting IRQ.
|
||||
Such an IRQ puts restrictions on the code that runs in the IRQ (for example
|
||||
the heap may be locked) and scheduling a function to call later will lift
|
||||
those restrictions.
|
||||
|
||||
Note: If `schedule()` is called from a preempting IRQ, when memory
|
||||
allocation is not allowed and the callback to be passed to `schedule()` is
|
||||
a bound method, passing this directly will fail. This is because creating a
|
||||
reference to a bound method causes memory allocation. A solution is to
|
||||
create a reference to the method in the class constructor and to pass that
|
||||
reference to `schedule()`. This is discussed in detail here
|
||||
:ref:`reference documentation <isr_rules>` under "Creation of Python
|
||||
objects".
|
||||
|
||||
There is a finite stack to hold the scheduled functions and `schedule()`
|
||||
will raise a `RuntimeError` if the stack is full.
|
||||
|
@ -105,15 +105,15 @@ Constants
|
||||
|
||||
.. data:: stderr
|
||||
|
||||
Standard error `stream`.
|
||||
Standard error ``stream``.
|
||||
|
||||
.. data:: stdin
|
||||
|
||||
Standard input `stream`.
|
||||
Standard input ``stream``.
|
||||
|
||||
.. data:: stdout
|
||||
|
||||
Standard output `stream`.
|
||||
Standard output ``stream``.
|
||||
|
||||
.. data:: version
|
||||
|
||||
|
@ -9,7 +9,7 @@
|
||||
|see_cpython_module| :mod:`cpython:select`.
|
||||
|
||||
This module provides functions to efficiently wait for events on multiple
|
||||
`streams <stream>` (select streams which are ready for operations).
|
||||
``stream`` objects (select streams which are ready for operations).
|
||||
|
||||
Functions
|
||||
---------
|
||||
@ -35,7 +35,7 @@ Methods
|
||||
|
||||
.. method:: poll.register(obj[, eventmask])
|
||||
|
||||
Register `stream` *obj* for polling. *eventmask* is logical OR of:
|
||||
Register ``stream`` *obj* for polling. *eventmask* is logical OR of:
|
||||
|
||||
* ``uselect.POLLIN`` - data available for reading
|
||||
* ``uselect.POLLOUT`` - more data can be written
|
||||
|
@ -14,7 +14,7 @@ This module provides access to the BSD socket interface.
|
||||
.. admonition:: Difference to CPython
|
||||
:class: attention
|
||||
|
||||
For efficiency and consistency, socket objects in MicroPython implement a `stream`
|
||||
For efficiency and consistency, socket objects in MicroPython implement a ``stream``
|
||||
(file-like) interface directly. In CPython, you need to convert a socket to
|
||||
a file-like object using `makefile()` method. This method is still supported
|
||||
by MicroPython (but is a no-op), so where compatibility with CPython matters,
|
||||
@ -245,7 +245,7 @@ Methods
|
||||
Not every ``MicroPython port`` supports this method. A more portable and
|
||||
generic solution is to use `uselect.poll` object. This allows to wait on
|
||||
multiple objects at the same time (and not just on sockets, but on generic
|
||||
`stream` objects which support polling). Example::
|
||||
``stream`` objects which support polling). Example::
|
||||
|
||||
# Instead of:
|
||||
s.settimeout(1.0) # time in seconds
|
||||
|
@ -17,9 +17,9 @@ Functions
|
||||
|
||||
.. function:: ussl.wrap_socket(sock, server_side=False, keyfile=None, certfile=None, cert_reqs=CERT_NONE, ca_certs=None)
|
||||
|
||||
Takes a `stream` *sock* (usually usocket.socket instance of ``SOCK_STREAM`` type),
|
||||
Takes a ``stream`` *sock* (usually usocket.socket instance of ``SOCK_STREAM`` type),
|
||||
and returns an instance of ssl.SSLSocket, which wraps the underlying stream in
|
||||
an SSL context. Returned object has the usual `stream` interface methods like
|
||||
an SSL context. Returned object has the usual ``stream`` interface methods like
|
||||
``read()``, ``write()``, etc. In MicroPython, the returned object does not expose
|
||||
socket interface and methods like ``recv()``, ``send()``. In particular, a
|
||||
server-side SSL socket should be created from a normal socket returned from
|
||||
|
@ -27,7 +27,7 @@ Functions
|
||||
|
||||
.. class:: DecompIO(stream, wbits=0)
|
||||
|
||||
Create a `stream` wrapper which allows transparent decompression of
|
||||
Create a ``stream`` wrapper which allows transparent decompression of
|
||||
compressed data in another *stream*. This allows to process compressed
|
||||
streams with data larger than available heap size. In addition to
|
||||
values described in :func:`decompress`, *wbits* may take values
|
||||
|
Loading…
Reference in New Issue
Block a user