| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
One can instead lookup __name__ in the modules dict to get the value.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
In the sense that while GET_FILE transfers its data, REPL still works.
This is done by requiring client to send 1-byte block before WebREPL
server transfers next block of data.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
It's now used for more than just stream protocol (e.g. pin protocol), so
don't use false names.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Request for password then becomes mandatory part of the protocol.
|
| |
|
|
|
| |
That's production setting. Also, extra UART output may affect behavior of
(subpar) network drivers.
|
| |
|
|
| |
Like ESP8266 has.
|
| |
|
|
|
|
| |
The smaller chunks we send (and receive), the more packets there to
receive, and higher chance to git internal packet buffer overflow in
WiFi driver.
|
| |
|
|
| |
So detailed that even commented by default.
|
| |
|
|
| |
A bit of optimization.
|
| |
|
|
|
| |
EAGAIN should be returned only if underlying socket returned it. Wrap
existing read function into external loop to process all data available.
|
| | |
|
|
|
While just a websocket is enough for handling terminal part of WebREPL,
handling file transfer operations requires demultiplexing and acting
upon, which is encapsulated in _webrepl class provided by this module,
which wraps a websocket object.
|
