04:10 <FromGitter> <naqvis> > *<ngp>* I don't think that gives me exactly what I'm looking for. What I'm trying to implement is similar to a pipe-filter pattern, but using Procs ⏎ ⏎ with some little hacking, you can achieve something like pipe-filter pattern. ⏎ https://carc.in/#/r/cfon [https://gitter.im/crystal-lang/crystal?at=61b6c7a576e379175535edcd]

04:14 <FromGitter> <naqvis> for sure this is just a hack and it won't work properly in MT mode. Intention here is to show there are whole lot possibilities via which you can design your own solution

08:02 <Elouin> Hi, i wrote a small irc bot and it works over unencrypted connections, but with tls its not really connecting.

08:03 <Elouin> https://codeberg.org/Elouin/Botocryn/src/branch/main/src/IRC/conn.cr thats my IRC Connection code.

08:06 <FromGitter> <naqvis> when you say not connecting, what error are you receiving?

08:12 <Elouin> its connecting, but seem to lose the connection very quickly. When i try to connect to libera for example: https://bin.disroot.org/?fadd71c0e46ac1aa#FCjccgvdb7y7zwpaJe4kjrq5wS7XVHMMji6NYM42aDYe

08:35 <FromGitter> <naqvis> not able to see any messages

08:36 <FromGitter> <naqvis> try to pass `context` with `verifymode` set to `None`

08:38 <FromGitter> <naqvis> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=61b7067dc2cc0e5343fd04f1]

08:47 <Elouin> added the context code. still the same result. :/

08:50 <FromGitter> <naqvis> you better do some debugging to understand if remote host is rejecting the connection with some details

08:50 <FromGitter> <naqvis> might worth trying with `openssl s_client`

09:01 <Elouin> With openssl s_client and writing the raw irc messages by hand it works.

09:09 <FromGitter> <naqvis> try to increase timeout settings for connection. as looking at your shared screenshot, its showing connection timeout

09:22 <Elouin> When i do `socket << message << "\r\n"` instead of `socket.puts message` it seems to work.

09:26 <Elouin> But why though. 🤔

09:29 <Elouin> Thanks for the help @naqvis . 🙂

09:30 <FromGitter> <naqvis> i'm not aware of IRC protocol, but that might require a linefeed to mark the end of the message

09:30 <FromGitter> <naqvis> 👍

09:48 <Elouin> just out of curiosity: if i do `socket.puts message + "\r\n"` that also doesnt work. but shouldnt `socket.puts message + "\r\n"` == `socket << message << "\r\n"` as of https://github.com/crystal-lang/crystal/blob/6529d725a/src/io.cr#L216 🤔

10:05 <FromGitter> <naqvis> i believe if you do `socket.puts message + "\n\r\n"` should work

10:06 <FromGitter> <naqvis> reason is `puts` appends new line `\n` if string passed doesn't end with that, and IRC requires the `\r\n` as the marker to mark the end of message

10:11 <Elouin> Doesn't seem to work with "\n\r\n". Also it works without ssl, so i dont think its an IRC specific problem.

10:22 <Elouin> socket.flush is what makes the difference.

10:23 <Elouin> (had that in the `<<` version of my code but not the `puts` version.)

10:24 <Elouin> but now the question is, why do i have to flush with openssl but not without.

15:28 <raz> may be related to buffer sizes

15:32 <raz> or buffering in general (i'm no familiar with ossl, but perhaps it generally only sends on flush or close?)

21:17 <SamantazFox> How is the stack trace generated in cas of an exception?

21:17 <SamantazFox> There seem to be some inconsistencies

21:18 <SamantazFox> For instance, the stack trace provided in this issue: https://github.com/iv-org/invidious/issues/2713 looks weird starting from the line `from src/invidious/trending.cr:19:14 in 'trending' (and upwards)`

21:19 <SamantazFox> I don't see where the `in 'trending'` comes from (it's not the function's name, like on other lines)

21:19 <SamantazFox> https://github.com/iv-org/invidious/blob/f236a6872bbc8b664d37e8c085e168141643cc0f/src/invidious/trending.cr

23:33 <FromGitter> <oprypin:matrix.org> SamantazFox, that is quite weird indeed

23:39 <SamantazFox> oprypin And the weirdest past comes later on in the trace (almost at the top) where you can clearly see one of our function (`decode_length_seconds`) being mapped to the stdlib `pointer.cr`