suspect-devices/circuitpython/py/objgenerator.c, branch 4.0.0-alpha.3

Two fixes and translate more strings.

2018-08-09T20:29:30+00:00

* Fix finding translations with escaped characters. * Add back \r to translations since its needed by screen.

WIP: after merge; before testing

2018-07-11T20:45:30+00:00

py/objgenerator: Protect against reentering a generator.

2018-05-22T06:54:03+00:00

Generators that are already executing cannot be reexecuted. This patch puts in a check for such a case. Thanks to @jepler for finding the bug.

py/objgenerator: Save state in old_globals instead of local variable.

2018-05-22T06:39:19+00:00

The code_state.old_globals variable is there to save the globals state so should be used for this purpose, to avoid the need for additional local variables on the C stack.

py/objgenerator: Check stack before resuming a generator.

2018-04-10T04:06:26+00:00

This turns a hard crash in a recursive generator into a 'maximum recursion depth exceeded' exception.

py/objgenerator: Check stack before resuming a generator

2018-04-01T21:40:15+00:00

This turns a hard crash in a recursive generator into a 'maximum recursion depth exceeded' exception.

py/objgenerator: Allow to pend an exception for next execution.

2017-12-15T18:20:36+00:00

This implements .pend_throw(exc) method, which sets up an exception to be triggered on the next call to generator's .__next__() or .send() method. This is unlike .throw(), which immediately starts to execute the generator to process the exception. This effectively adds Future-like capabilities to generator protocol (exception will be raised in the future). The need for such a method arised to implement uasyncio wait_for() function efficiently (its behavior is clearly "Future" like, and normally would require to introduce an expensive Future wrapper around all native couroutines, like upstream asyncio does). py/objgenerator: pend_throw: Return previous pended value. This effectively allows to store an additional value (not necessary an exception) in a coroutine while it's not being executed. uasyncio has exactly this usecase: to mark a coro waiting in I/O queue (and thus not executed in the normal scheduling queue), for the purpose of implementing wait_for() function (cancellation of such waiting coro by a timeout).

py/objgenerator: Remove unreachable code for STOP_ITERATION case.

2017-11-30T01:06:41+00:00

This commit essentially reverts aa9dbb1b033a8163e07fcf5763fc20146354cc48 where this if-condition was added. It seems that even when that commit was made the code was never reached by any tests, nor reachable by analysis (see below). The same is true with the code as it currently stands: no test triggers this if-condition, nor any uasyncio examples. Analysing the flow of the program also shows that it's not reachable: ==START== -> to trigger this if condition mp_execute_bytecode() must return MP_VM_RETURN_YIELD with *sp==MP_OBJ_STOP_ITERATION -> mp_execute_bytecode() can only return MP_VM_RETURN_YIELD from the MP_BC_YIELD_VALUE bytecode, which can happen in 2 ways: -> 1) from a "yield " in bytecode, but must always be a proper object, never MP_OBJ_STOP_ITERATION; ==END1== -> 2) via yield from, via mp_resume() which must return MP_VM_RETURN_YIELD with ret_value==MP_OBJ_STOP_ITERATION, which can happen in 3 ways: -> 1) it delegates to mp_obj_gen_resume(); go back to ==START== -> 2) it returns MP_VM_RETURN_YIELD directly but with a guard that ret_val!=MP_OBJ_STOP_ITERATION; ==END2== -> 3) it returns MP_VM_RETURN_YIELD with ret_val set from mp_call_method_n_kw(), but mp_call_method_n_kw() must return a proper object, never MP_OBJ_STOP_ITERATION; ==END3== The above shows there is no way to trigger the if-condition and it can be removed.

Merge commit 'f869d6b2e339c04469c6c9ea3fb2fabd7bbb2d8c' into nrf2_merge

2017-10-25T05:31:16+00:00

This is prep for merging in the NRF5 pull request.

all: Remove inclusion of internal py header files.

2017-10-04T01:37:50+00:00

Header files that are considered internal to the py core and should not normally be included directly are: py/nlr.h - internal nlr configuration and declarations py/bc0.h - contains bytecode macro definitions py/runtime0.h - contains basic runtime enums Instead, the top-level header files to include are one of: py/obj.h - includes runtime0.h and defines everything to use the mp_obj_t type py/runtime.h - includes mpstate.h and hence nlr.h, obj.h, runtime0.h, and defines everything to use the general runtime support functions Additional, specific headers (eg py/objlist.h) can be included if needed.