"Beyond finishing" ideas

[pfalcon]

Things to consider beyond #15.

• Implement "marshal" module marshall module ideas #8
• Add += (as a synonym for .write()) and [] operations for uio.StringIO, effectively implementing "string buffer" class with operations close to str.
• Add +=, etc. operations to array.array as means for users to perform alloc-free arithmetics on values "larger" than native smallint (e.g. on int32, int64, float, double values).
• Make dictionary C implementation overridable (e.g. allow to switch in more efficient, but more memory-hungry implementation).
• Implement efficient uselect.poll() support for bare-metal ports (ready-queue instead of busy-polling).

[pmp-p]

Hi, is there also any plans for :

• removing setjmp & nlr
• moving (slowly) vm loop away from C stack
• contextvars support in uasyncio.

My questions are relative to a possible support of wasi/wasm unthreaded platform that does not seem to get any echo elsewhere.

[pfalcon]

removing setjmp & nlr

That's what I'd like to do, yes. But given that the work started in MicroPython, it's only logical to wait when then need for it will dawn (well, set) on its maintainer and he will merge the pending patch. Doing concurrent work means doing potentially useless work, to be overthrown by merge conflicts later.

moving (slowly) vm loop away from C stack

There's implementation of "stackless" mode, implemented by me years ago, which would be just that, depending on what exactly you mean.

contextvars support in uasyncio.

I personally didn't have need for that so far, and the idea of uasyncio to be minimal. I would conjecture that per-coroutine data storage can be already implement, as a separate module.

[pmp-p]

Doing concurrent work means doing potentially useless work, to be overthrown by merge conflicts later.

if keeping the current VM design it makes perfect sense. But i'm really not sure the current design fits
all possible pycopy applications. As demonstrated by the weakness of MicroPython in javascript port.

depending on what exactly you mean

i mean extending :
"" "same sense as http://www.stackless.com/ , and they mean "not using C stack" by it.""" (your words)

Your stackless implementation for loop iteration and removing the dependency on c-stack for recursives calls starting from this point https://github.com/pfalcon/pycopy/blob/master/py/vm.c#L201 to allow some level of pre-emption when micropython loop is called from a host program.

ie using a seperate C static context for each level of recursive calls to mp_execute_bytecode and iterators. i know It's a lot of work cause i tested that already ( and it can work ) but the struct to hold the callpath and data for what is usefull to preempt is small.

contextvars

i guess contextvars could be linked to the C context + callpath + pystack , maybe to facilitate multi core exchanges later. Making it one of the best Python implementations instead of a better something.

[pfalcon]

"" "same sense as http://www.stackless.com/ , and they mean "not using C stack" by it.""" (your words)

That's exactly what I implemented in 2015: 2039757. Of course, C stack is not used only when Python bytecode is executed. As soon as native (C) function is called, it uses C stack, then if it calls back into Python code, that opens another (big) stack frame for mp_execute_bytecode().

i guess contextvars could be linked to the C context + callpath + pystack

They can be implemented in pure Python. In a distant imaginary future they might be optimized beyond that.

[pmp-p]

C stack is not used only when Python bytecode is executed.

yes, by extending the concept i mean not using c-stack when python bytecode execution is paused
pause points would be before and after(ret) (big) stack frame opening and in generator loop next(). Because returning to host erases the wasm/c stack ( in my experiment extending PYSTACK, python is a coroutine for javascript host, i'm not running the vm loop i'm stepping it along the callpath )

[pmp-p]

That's exactly what I implemented in 2015

no sorry, it did not work "as is" on clang/wasm targets because it was probably not complete enough up to top level vm entry, the working way was for me PYSTACK + handling cstack from the first module fun_0 call. That's why i'm asking your position regarding finishing no_nlr/c-stackless and your current codebase.

They can be implemented in pure Python. In a distant imaginary future they might be optimized beyond that.

sub interpreters are not in a distant imaginary future. they are seeded in since 3.7.0

[pfalcon]

no sorry, it did not work "as is" on clang/wasm targets because it was probably

But clang/wasm is your personal fixation, for everyone else it's just another feature among myriad of others. (It's definitely buzzwordy feature, thanks to marketing departments of big media corporations, but to give it fairness, marketing campaign for Java applets in browsers was much more cooler. (Or I was younger and grass was greener.)). You would need to convert your "probably" into "proven with a reproduction testcases applied to a general case, not just 'clang/wasm' ".

That's why i'm asking your position regarding finishing no_nlr/c-stackless and your current codebase.

No news here beyond recent comments above. Stackless is complete, unless proven otherwise. NLR removal is handled in upstream, and I have gazillion of other things to do, so don't compete. When I run out of things to do (~several years), and upstream is still not there, I'll do it myself. (Unless I'll switch to finishing ;-) ).

[pmp-p]

But clang/wasm is your personal fixation

clang/wasm was as an example you can easily check with public tools at no cost on the poor broken "javascript port" you host yourself. My others "week-end coder" fixations are maybe none of your concern or for public display.

Sidenote the number of wasm devices actually vastly outrank any other toy mcu you can/want/try to support.

i'm done here thank you for your time.

[pfalcon]

Sidenote the number of wasm devices actually vastly outrank any other toy mcu you can/want/try to support.

The reason I quit micropython - I'm not interested to spend my life on toy mcus. I'm interested in a minimalist language, which includes protecting its minimalism from all the parties who want to bloat it up on their whims.

Good news re:"vast rank of wasm devices" is that those devices can also run something else besides wasm, at least so far. But in distant imaginary future, when they lock us out to only wasm, your work will be of utter importance. So, please keep it up, and make it great.