unix port build broken: objringio.c uses stale ringbuf API

[trashhalo]

Bug

The unix port fails to build on tag 10.2.0 (and current main). py/objringio.c calls the old MicroPython ringbuf API, but CircuitPython reworked py/ringbuf.h — renamed functions, changed struct fields — and objringio.c was never updated.

Since objringio.c is gated behind MICROPY_PY_MICROPYTHON_RINGIO (only enabled by the unix port), this bug is invisible to all hardware board builds.

Error

py/objringio.c:54:46: error: no member named 'iput' in 'struct _ringbuf_t'
py/objringio.c:79:46: error: call to undeclared function 'ringbuf_avail'
py/objringio.c:82:46: error: call to undeclared function 'ringbuf_free'
py/objringio.c:61:5: error: call to undeclared function 'ringbuf_memcpy_get_internal'
py/objringio.c:69:5: error: call to undeclared function 'ringbuf_memcpy_put_internal'

Fix

In py/objringio.c:

// line 52-54: direct struct field access → ringbuf_init()
// OLD:
    self->ringbuffer.buf = bufinfo.buf;
    self->ringbuffer.size = bufinfo.len;
    self->ringbuffer.iget = self->ringbuffer.iput = 0;
// NEW:
    ringbuf_init(&self->ringbuffer, bufinfo.buf, bufinfo.len);

// line 60-61: ringbuf_avail → ringbuf_num_filled, ringbuf_memcpy_get_internal → ringbuf_get_n
// OLD:
    size = MIN(size, ringbuf_avail(&self->ringbuffer));
    ringbuf_memcpy_get_internal(&(self->ringbuffer), buf_in, size);
// NEW:
    size = MIN(size, ringbuf_num_filled(&self->ringbuffer));
    ringbuf_get_n(&(self->ringbuffer), buf_in, size);

// line 68-69: ringbuf_free → ringbuf_num_empty, ringbuf_memcpy_put_internal → ringbuf_put_n
// OLD:
    size = MIN(size, ringbuf_free(&self->ringbuffer));
    ringbuf_memcpy_put_internal(&(self->ringbuffer), buf_in, size);
// NEW:
    size = MIN(size, ringbuf_num_empty(&self->ringbuffer));
    ringbuf_put_n(&(self->ringbuffer), buf_in, size);

// line 79: ringbuf_avail → ringbuf_num_filled
// OLD:
    if ((arg & MP_STREAM_POLL_RD) && ringbuf_avail(&self->ringbuffer) > 0) {
// NEW:
    if ((arg & MP_STREAM_POLL_RD) && ringbuf_num_filled(&self->ringbuffer) > 0) {

// line 82: ringbuf_free → ringbuf_num_empty
// OLD:
    if ((arg & MP_STREAM_POLL_WR) && ringbuf_free(&self->ringbuffer) > 0) {
// NEW:
    if ((arg & MP_STREAM_POLL_WR) && ringbuf_num_empty(&self->ringbuffer) > 0) {

// line 96: ringbuf_avail → ringbuf_num_filled
// OLD:
    return MP_OBJ_NEW_SMALL_INT(ringbuf_avail(&self->ringbuffer));
// NEW:
    return MP_OBJ_NEW_SMALL_INT(ringbuf_num_filled(&self->ringbuffer));

Reproduce

cd circuitpython
make -C mpy-cross
cd ports/unix
make submodules
make VARIANT=standard

Environment

• macOS Sequoia (ARM64), Clang 17.0.0
• Tag 10.2.0 (also confirmed on 10.3.0-alpha.1)

[dhalbert]

We don't use the VARIANT=standard build; we only use VARIANT=coverage, so that we can run tests. So we haven't tried to maintain the standard variant at all, and never build it. (In fact just plain make in ports/unix defaults to coverage.)

There are a number of other things missing from the unix port, like supervisor, that make it not a very good CircuitPython port for actual use. What is your use case for building the standard variant?