13:40 <kempe> Hello! I've been interested in pony for a while and was thinking of trying it out for a project I have in mind. One quirk is that I have to pass binary data to and from functions written in C (I'm hooking some custom networking related kernel things) and I'm wondering if there is a best practice for doing this. I saw the the Array type has a function called from_cpointer, but I assume that memory management

13:40 <kempe> would have to be done on the C side of things since it states it doesn't copy the data?

14:09 <SeanTAllen> if the memory is allocated by c, then yes, by default you would need to free it yourself

14:11 <kempe> Is there some way to copy the data returned to pony so that I can use a local stack variable in C and let that one fall out of scope and let pony's GC handle the memory management on the pony side? I'd rather avoid manual memory management as much as possible

14:12 <SeanTAllen> yes but you will still need to free the original memory

14:13 <kempe> Although that would be done automatically if I don't use malloc, but a stack variable local to the function in C I'm calling, right?

14:13 <kempe> When the function ends and the variable goes out of scope

14:14 <SeanTAllen> if you wanted an array for example, i would suggest checking out the "from_cpointer" constructor that is part of Array

14:17 <kempe> I did have a look at that one, but since it states that the data is not copied I assume I can't use a local variable C side since the variable the pointer is reffering too can't go out of scope until the pony code is done with it? That is I'd have to use malloc when getting the data and make sure to have a C function calling free on the memory when pony's GC reclaims the Array. Or does pony automatically

14:17 <kempe> free the memory of the pointer used in from_cpointer when the Array is GC'ed?

14:18 <SeanTAllen> right in the case of from_cpointer then you wouldnt be freeing that memory, it would be handled for you

14:18 <SeanTAllen> actually im not sure of that

14:18 <kempe> Nice! Then that works perfectly. Thank you!

14:19 <SeanTAllen> don't trust me on that. i'm under the weather today.

14:19 <kempe> No worries, at least I have a starting point. I'll play around a bit and see how it works out

14:20 <kempe> I must say I am crushing a bit on pony at the moment :P

14:20 <SeanTAllen> we have a product that has a C++ API and memory is allocated in C++ but we need to free at some point from pony

14:20 <SeanTAllen> we create a CPPData object to wrap that memory and when it is freed, we have a finalizer on CPPData that will free the underlying memory

14:22 <kempe> Okay, I see. I guess I might have to wrap the array in another object that calls a free function in C from its final member function

14:23 <SeanTAllen> it's what we do so the person using the C++ API doesn't have to worry about when the memory needs to be freed

14:24 <kempe> Okay, sounds reasonable

14:24 <SeanTAllen> One of our requirements for our C++ API was "end developer shouldnt have to manually manage memory"

14:25 <kempe> A wise requirement as most crashes, in my experience, are caused by memory handling errors

14:27 <SeanTAllen> another option, kempe, if you have control of the c code is to use pony_alloc to allocate the memory.

14:28 <SeanTAllen> if you want to use "from_cpointer", you can use that then clone the array, the free the C pointer using FFI

14:30 <kempe> I'm not familiar with pony_alloc. Should I read the source for pony or is it documented somewhere?

14:32 <SeanTAllen> its part of the c runtime

14:33 <SeanTAllen> https://github.com/ponylang/ponyc/blob/3af64e8c1fb9f2f08d7321d10e00cb47011fd2f4/src/libponyrt/pony.h#L192

14:36 <kempe> Looks interesting. If I call an FFI-function can I simply use the pony_ctx()-call to get the correct context for allocating GC'ed memory?

15:21 <SeanTAllen> i believe so yes

15:25 <kempe> Thank you for you help. I know where to start now and I'll do some experimenting

15:29 <SeanTAllen> you're welcome kempe

19:47 <omarkj> Had no idea stable existed. Great work jemc. Has come in really handy compared to manually managing these.

20:33 <SeanTAllen> its a great impediment to a full package manager ;)

20:33 <SeanTAllen> its met all our needs at Sendence so far (we had a couple small changes we PR'd in but otherwise, so simple, so good)

20:34 <SeanTAllen> from time to time, i think "I should open an RFC to make stable the official package manager"

20:34 <omarkj> I saw the long github thread since 2015 about a package manager.

20:34 <SeanTAllen> lol

20:34 <SeanTAllen> yes

20:34 <omarkj> Wondering where that was at, if anywhere, with the core team.

20:34 <SeanTAllen> i think the problem is... that most of the folks we are using Pony all the time, are fine with stable

20:34 <SeanTAllen> no one has an itch to scratch on that front

20:35 <SeanTAllen> if there were many libraries and discovery was hard, i think something like cargo would have more uptake

20:35 <omarkj> Right, maybe it's just too early to look into a cargo-like software?

20:35 <omarkj> Cargo has some nice features like compile flags for dependencies, etc.

20:36 <omarkj> But I haven't used Pony enough to say if something like that is really useful when you're in it full time :)

20:42 <SeanTAllen> So far, we haven't needed. But that is just for our Sendence use case.