compiling C modules into loadable shared objects

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: compiling C modules into loadable shared objects

Post by jimmo » Mon Sep 09, 2019 11:28 am

All true, but in this case (calling a MicroPython function like allocating a buffer) is already in the category of things that this feature handles well. In the QR example, the native module allocates the tuple to return the "pixel" data. There's a finite set of MicroPython internals that you need access to.

v923z
Posts: 168
Joined: Mon Dec 28, 2015 6:19 pm

Re: compiling C modules into loadable shared objects

Post by v923z » Mon Sep 09, 2019 1:46 pm

stijn wrote:
Mon Sep 09, 2019 10:14 am
Yes that's also possible, but then the calling code has to know exactly what the function is going to do and create a buffer of the correct size. Certainly doable, but more error prone and increases coupling of the code.
Beyond what @jimmo has already pointed out in his last post, the situation is really not worse then with pointers: if you pass a pointer to a function, it is the caller's responsibility to allocate the required amount of memory, otherwise, all hell might break loose. But no one would consider this error prone.

And, taking the original example of @OutoftheBOTS_, when you want someone to do your FFT, then you know in advance, how much data you are going to get back. And I think, the kind of computations we are talking about all fall into such a category.

stijn
Posts: 735
Joined: Thu Apr 24, 2014 9:13 am

Re: compiling C modules into loadable shared objects

Post by stijn » Mon Sep 09, 2019 2:34 pm

v923z wrote:
Mon Sep 09, 2019 1:46 pm
if you pass a pointer to a function, it is the caller's responsibility to allocate the required amount of memory, otherwise, all hell might break loose. But no one would consider this error prone.
Depends on whom you ask, one can always find (misinformed) people who consider C and raw pointer access the worst of all evils. Which likely stems from the amounts of bugs caused by it. But in any case my point was rather that it's more error prone than alternatives.
And, taking the original example of @OutoftheBOTS_, when you want someone to do your FFT, then you know in advance, how much data you are going to get back.
Well, you know that when you implement the function. Or else if you're targetting an experienced user than then he/she also can figure out. But someone new to FFT might have to read the documentation first and/or might make the mistake of passing something of an incorrect size. I can't even count the questions I saw on StackOverflow and similar caused by things like this. Now don't get me wrong, in code where it matters I use preallocation constantly but all in all it's more user-friendly to have less coupling..

pmp-p
Posts: 13
Joined: Mon Apr 24, 2017 12:45 am

Re: compiling C modules into loadable shared objects

Post by pmp-p » Mon Sep 23, 2019 8:07 pm

Sorry for not reading previous pages and watching video but just in case, you can load any module with FFI on unix port written in any compiled language and you can even import quite complex C++ classes as MicroPython objects proxies.

using stock micropython + pfalcon tools + c2ffi on C header only since forever :
https://github.com/pmp-p/micropython-ffigen

using stock micropython + a Panda3D tool called interrogate on C++ headers + *source* since recently:
https://github.com/pmp-p/panda3d-interrogator

also for tech help you could ask straight on https://kiwi.freenode.net/?nick=mp_foru ... icropython and wait for an answer or here https://gitter.im/micropython/Lobby

Post Reply