13:37 <EEVV> hey does pony support openssl? I can't find this anywhere

13:37 <EEVV> I know it has crypto std library but this does not have AES and RSA it seems

13:38 <EEVV> oh derp... https://stdlib.ponylang.io/net-ssl--index

13:38 <EEVV> why is that whenever I ask a question here I answer it myself in 20 mins max

13:39 <vaninwagen> it is the rubber-duck effect

13:42 <EEVV> oh

13:42 <vaninwagen> it is quite powerful

13:42 <EEVV> yes I agree

13:43 <vaninwagen> the pony openssl/libressl bindings do not expose any symmetric or asymmetic cyphers atm, only some hash functions afaik

13:44 <EEVV> vaninwagen: I do have a question because I'm not sure how to do this... I want my TCPListener to keep track of TCPConnections is this a problem?

13:44 <Candle> Heh. I wonder how many others actually have a rubber duck near their computer ¬_¬

13:44 <EEVV> oh but can I directly interface with OpenSSL from pony?

13:44 <vaninwagen> i have a small pony here

13:45 <vaninwagen> via ffi for sure

13:45 <EEVV> is ffi the `@function_goes_here()` thing

13:45 <vaninwagen> yep

13:45 <EEVV> this is ok also because I have written a prototype of my project in C so it shouldn't be too hard... not sure exactly how pony threads work but I hope openssl is thread safe

15:59 <beardhatcode> Why can I call a box method on an iso ?

16:00 <vaninwagen> Because iso is a subtype of box

16:01 <vaninwagen> That is you can safely use an iso as if it were a box

16:03 <SeanTAllen> EEVV: the area you will run into problems with Pony and C projects with threading are primarily with C libraries that either: 1) use globals 2) use thread local variables.

16:09 <beardhatcode> @vaninwagen is it because this "Automatic receiver recovery" ?

16:13 <beardhatcode> Because this would be aliases right, violating the iso

16:14 <vaninwagen> Right, yeah

16:14 <vaninwagen> Forgot the aliasing of the receiver

16:22 <beardhatcode> On the page of recovery in the tutorial. That it can be used " “Extract” a mutable field from an iso and return it as an iso.". doesn't that violate the iso principle? You can't send the initial iso anymore right? Because you have an iso alias to one of it's internals. (What is wrong with my train of tought here?)

17:12 <EEVV> how should I do `RSA_generate_key`?

17:13 <EEVV> is there some sort of pointer in pony

17:13 <EEVV> for C

17:14 <EEVV> (nvm lol)

17:14 <EEVV> now I see why tag is used, cool

17:28 <EEVV> I'm trying to use `RSA_generate_key` https://www.openssl.org/docs/man1.1.1/man3/RSA_generate_key.html but how do I pass null pointers?

17:28 <EEVV> and I am also supposed to receive a pointer

17:31 <EEVV> and I don't really care about representing that pointer since I will use C functions to interact with it

17:32 <EEVV> I hope I can treat it like a U64

18:23 <vaninwagen> EEVV you can create null pointers with: https://stdlib.ponylang.io/builtin-Pointer/#create

18:25 <vaninwagen> For representing C pointers you have Pointer and https://stdlib.ponylang.io/builtin-MaybePointer/

18:26 <EEVV> ok I will bookmark these for later

18:26 <EEVV> I used U64 not sure if that even works

18:27 <vaninwagen> EEVV i assume you had a look at: https://tutorial.ponylang.io/c-ffi/calling-c.html ?

18:29 <vaninwagen> Also the existing ssl binding might be good examples for handling pointers etc: https://stdlib.ponylang.io/src/net-ssl/ssl_context/#L59

18:36 <EEVV> vaninwagen I wanted to use SSL but I don't know if that one has the specific RSA I need

19:03 <vaninwagen> EEVV: you want to use the RSA key for an SSL connection or did you mean something else?

19:08 <SeanTAllen> beardhatcode: im not sure what that "extract" is referring to

20:43 <profetes> hi Sean, thanks for the comment. You were referring to the original code, or the new minimal case I created and inserted into the issue?

20:44 <SeanTAllen> Original code

20:44 <SeanTAllen> I will update to clarify

20:45 <profetes> btw, I fixed my code we were discussing back then and I got it working correctly for Ss as well (periodical checking with Timer, instead of callbacks). It's on my github. But it still does not do GCing.

20:46 <SeanTAllen> I can't comment on that. I don't know what "fixed" means. The previous code, I don't think it should have been gcing. I can't comment on it not doing it now.

20:54 <profetes> Sure, that's fine. I also reviewed screenshots you sent - and if I'm reading them correctly - GCing did not happen, not for me, nor for you. But let's drop that program already :) The main thing i'm interested now is how to write programs that return values, but actors can be GCed. This new code in the issue addresses that. And it is much much simpler. I'll try to attend the PonySync this week to answer/ask questions faster,

20:54 <profetes> that typing them here :)

20:55 <SeanTAllen> i really dont understand that question

20:55 <SeanTAllen> "how to write programs that return values"

20:56 <SeanTAllen> what does that mean?

21:04 <profetes> I mean my typical cases, where Main spawns actors that do some work (map-reduce pattern), and then Main collects the results to process them further or write them to terminal/file. My approach so far does not allow GC apparently, I'm asking for proper architecture to let GC work.

21:08 <profetes> but nevermind, I think I'll understand more later, as I get more details on how GC work and when it works. Code provided in the issue can reproduce my issue of GC not running for cycles.

21:08 <profetes> I'll keep experimenting on my own.

21:12 <theodus> Last Week in Pony - January 14, 2019 - https://www.ponylang.io/blog/2019/01/last-week-in-pony---january-14-2019/

21:13 <SeanTAllen> Well here is one way profetes: https://playground.ponylang.io/?gist=ddac0ecd24629d6f280244da8304fb12

21:13 <SeanTAllen> an actor is eligible to be gc'd when:

21:13 <SeanTAllen> 1- it isn't referenced by anything

21:13 <SeanTAllen> 2- it can't receive any messages

21:13 <SeanTAllen> #2 is mostly covered by #1

21:13 <SeanTAllen> but also includes that actor not being registered with the async io system

21:20 <profetes> okay, that makes it more clear. Regarding code sample: in case I have many workers, I just call OtherActor(this) every time. And in be receive_result(result: U64) I implement a logic for getting all the results. So I need a counter of how many results I'm expecting. I got it. How does that approach differs from using Promise[U64] p, that p.next(recover this~receive_result() end) and passing that as a parameter for OtherActor?

21:24 <SeanTAllen> at minimum, less overhead

21:24 <SeanTAllen> my approach gets less overhead because its less flexible

21:25 <SeanTAllen> a Promise is itself an actor so there's additional overhead and message passing but you can chain promises together etc

21:26 <SeanTAllen> the problems i solve really dont ever need promises so I don't tend to use them

21:31 <profetes> okay, thank you for clarification. From GC point of view, after OtherActor reported results - is it ready do be GCed?

21:33 <SeanTAllen> well...

21:33 <SeanTAllen> 1: there are no references to it

21:33 <SeanTAllen> 2: it would be done doing work

21:33 <SeanTAllen> 3: it isn't registered for asio event

21:34 <SeanTAllen> 4: it can't receive any new messages because of #1, so yes, it could be gc'd.

21:34 <SeanTAllen> also note, there is no reason that Main has to be the actor that it is reporting back to, it could be any actor that is supposed to get results and then report them.

21:35 <SeanTAllen> i only ever use Main to get the program initialized and then let it die out. I never add any behaviors to Main.

21:39 <profetes> sure, using Main here is just a sample, that I get. And to me as well, OtherActor should be able to be GCed. So that answers my question about architecture, let me summary it if I get it correctly: for provided code, if I use that approach or Promises - upon finished work OtherActor should be able to be GCed independently from actor it reports to.

22:04 <profetes> SeanTAllen: Thanks for all the info so far, gotta go, 11pm local time.

22:07 <SeanTAllen> have a good night profetes