<< 09-05-2024 >>

00:13:23FromDiscord<gogolxdong666> What's the position of nimskull?
00:19:44FromDiscord<Elegantbeef> Join their matrix room and ask there
00:35:09FromDiscord<System64 ~ Flandre Scarlet> Does Nim supports int128?
00:36:56FromDiscord<Robyn [She/Her]> In reply to @sys64 "Does Nim supports int128?": Not natively in the stdlib, but you can look at `nint128`
00:37:36FromDiscord<Robyn [She/Her]> https://github.com/rockcavera/nim-nint128 @System64 ~ Flandre Scarlet
00:41:46FromDiscord<albassort> what EXACTLY does "hasdatabuffered" mean
00:42:19FromDiscord<LLM af0rg v2.0> means deez nuts.↵(@albassort)
00:42:26FromDiscord<albassort> >:(
00:44:09FromDiscord<LLM af0rg v2.0> wrong room. oops.
01:14:03FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=lVtnseqEzxmY
01:14:55FromDiscord<albassort> im going to bed
01:14:58FromDiscord<albassort> but before that
01:15:13FromDiscord<albassort> does anyone know why might the server send me a single H in response to a TLS handshake
01:17:23FromDiscord<albassort> https://media.discordapp.net/attachments/371759389889003532/1237936421147246603/Screenshot_2024-05-09_10-16-36.png?ex=663d75a2&is=663c2422&hm=e06ea774788abba762b44f52b00bcb84ad7ecbf902b69461497b12458a064609&
01:20:29FromDiscord<albassort> it sends me an infinite supply of nulls
01:30:08FromDiscord<polylokh_39446> maybe you're writing the server's response to a copied buffer again, and are printing the untouched buffer?
01:30:47FromDiscord<albassort> How would the H get there when
01:30:57FromDiscord<albassort> (edit) "when" => "then"
01:31:26FromDiscord<polylokh_39446> I don't see an H in that buffer
01:31:34FromDiscord<polylokh_39446> oh, highlighted, on the second line
01:31:35FromDiscord<albassort> It's highlighted
01:32:00FromDiscord<albassort> Maybe when I wake up I'll have fresh eyes
01:32:09FromDiscord<albassort> Or someone for some reason will know how TLS works and health
01:32:14FromDiscord<polylokh_39446> it can't be sending you a single H in that case, but a bunch of nulls followed by an H, at least that much
01:32:16FromDiscord<albassort> (edit) "health" => "help"
01:32:32FromDiscord<albassort> Yeah I don't even know how it would send me that or why
01:32:38FromDiscord<albassort> Something has to be wrong somewhere on my end
01:32:40FromDiscord<polylokh_39446> most likely, it's not.
01:33:08FromDiscord<polylokh_39446> best I can guess is that you're reading a single byte of the response into the middle of that array
01:33:11FromDiscord<albassort> Perhaps I'm not supposed to simply send the TLs handshake or maybe I collected it wrong because it sent it very fragmented
01:33:35FromDiscord<polylokh_39446> how/when you start TLS is defined by the protocol. For https it's the first thing you do.
01:33:54FromDiscord<albassort> Then this is the sel
01:33:55FromDiscord<albassort> Ssl
01:34:22FromDiscord<albassort> (edit) "sel" => "ssl"
01:34:34FromDiscord<polylokh_39446> (an example of starting it later is SMTP, where you connect and be a bit polite and then send STARTSSL)
01:35:18FromDiscord<albassort> I don't know why the http protocol is like this and I think it's very silly and I would not have designed it like this
01:35:28FromDiscord<albassort> It seems kind of chaotic
01:35:34FromDiscord<albassort> At least this side of it
01:35:55FromDiscord<polylokh_39446> but there shouldn't really be room for error with SSL if you've gotten past really easy mistakes or CA stuff.
01:36:32FromDiscord<albassort> All I've gotten to is that string there
01:36:52FromDiscord<polylokh_39446> also, doesn't it say HTTP/1.1 200 OK right there? That's not going to be cleartext with https, it's encrypted too.
01:37:25FromDiscord<albassort> I don't know I think I've seen that in some wireshark packets
01:37:26FromDiscord<polylokh_39446> maybe that's the entire response and you're reading garbage memory after it.
01:37:43FromDiscord<polylokh_39446> there's plenty of cleartext HTTP going around for you to see that
01:37:46FromDiscord<albassort> No the garbage memory one is the client sending something to the server
01:38:00FromDiscord<albassort> Server says OK
01:38:05FromDiscord<albassort> Firefox sends that
01:38:18FromDiscord<albassort> Sever responds with NULL.... H NULL
01:38:47FromDiscord<polylokh_39446> `$ strace -vtfff -s100 curl https://somedomain/ 2>&1 | grep HTTP`↵no HTTP on the wire apart from site content that curl prints out
01:39:04FromDiscord<polylokh_39446> (edit) "HTTP" => ""HTTP""
01:39:23FromDiscord<polylokh_39446> with https the entire communication is encrypted.
01:41:27FromDiscord<polylokh_39446> my new guess is that you're getting the length of the recv wrong.
01:41:29FromDiscord<albassort> it has to be something to do with the SSL handshake because firefox spits out this
01:41:37FromDiscord<albassort> sent a long message, see https://pasty.ee/oZhRpbivqnAq
01:42:17FromDiscord<albassort> In reply to @polylokh_39446 "my new guess is": its seems pretty tolerant to that so far because this is my procedure for that
01:42:37FromDiscord<albassort> sent a code paste, see https://play.nim-lang.org/#pasty=GplwCGJtVKiB
01:43:14FromDiscord<albassort> This is somewhat noisey but it doesn't care up to this step
01:43:28FromDiscord<albassort> however, me reading the response is especially noisey because its fragmented
01:43:51FromDiscord<polylokh_39446> why are you looping over the indices of data?
01:43:59FromDiscord<albassort> thats the buggert
01:44:01FromDiscord<albassort> (edit) "buggert" => "buffer"
01:44:11FromDiscord<albassort> its reading into the buffer
01:44:12FromDiscord<polylokh_39446> you're recv'ing single bytes? why?
01:44:27FromDiscord<albassort> temporary easiest way to break when its null
01:45:12FromDiscord<albassort> i could refine it when it works but making it do say 24 bytes would make it more complicated
01:45:31FromDiscord<polylokh_39446> what you do is pick a buffer size and let recv fill as much of it as it wants
01:46:04FromDiscord<polylokh_39446> recv tells you how much it wrote into the buffer. You can then consider that sub array.
01:46:41FromDiscord<albassort> In reply to @polylokh_39446 "what you do is": hmm i was afraid of data loss but you're right
01:46:58FromDiscord<albassort> sent a code paste, see https://play.nim-lang.org/#pasty=piquWeAhhBYn
01:47:08FromDiscord<albassort> (edit) "https://play.nim-lang.org/#pasty=LQTFuCKSnztX" => "https://play.nim-lang.org/#pasty=gNAEfWeNGOWR"
01:47:12FromDiscord<polylokh_39446> this is something that could technically work, but is also such a crazy thing to do from the perspective of the BSD socket API, that I think it's only natural for weird errors to crop up.
01:47:27FromDiscord<Elegantbeef> `$char(ord(0x0)` what the fuck over
01:47:33FromDiscord<albassort> YES
01:47:35FromDiscord<albassort> (edit) "YES" => "yes"
01:47:40FromDiscord<Elegantbeef> That's gotta be the most complicated way to write `"\0"`
01:47:41FromDiscord<leorize> why would you want to break on nul?
01:47:51FromDiscord<albassort> end of message usually
01:48:00FromDiscord<leorize> binary data contains 0 all the time
01:48:08FromDiscord<albassort> well its not binary
01:48:11FromDiscord<albassort> its http most of the time
01:48:13FromDiscord<albassort> not here, though
01:48:16FromDiscord<Elegantbeef> It's encrypted no?
01:48:21FromDiscord<albassort> errr
01:48:23FromDiscord<albassort> we're not sure
01:48:26FromDiscord<polylokh_39446> you don't need end of message with sockets in general, and HTTP gives you a content-length header, and HTTP responses can include NUL bytes naturally, for example if you download a big-file-of-nulls.bin
01:49:30FromDiscord<leorize> and encrypted stuff is supposed to be indistinguishable from random data
01:49:30FromDiscord<leorize> and last time I checked random includes 0
01:49:30FromDiscord<Elegantbeef> No then it wouldn't be random if you knew what it contained 😛
01:50:05FromDiscord<albassort> sent a code paste, see https://play.nim-lang.org/#pasty=EtJVNkKjqjPN
01:50:10FromDiscord<albassort> no content-length here
01:50:18FromDiscord<polylokh_39446> if you get to pulling out your hair, try just running through Beej's Guide with Nim. Write simple networking programs with std/selectors and non-async calls, and get comfortable with how that works. The SSL experience should be "you wrap a socket with a context and it just works"
01:50:33FromDiscord<albassort> I've been coding in nim for like
01:50:35FromDiscord<albassort> 4 years now
01:50:38FromDiscord<leorize> if you don't have content-length, then it's deliminated by connection termination
01:50:48FromDiscord<leorize> welcome to http/1.1
01:50:50FromDiscord<albassort> This is my first interaction with http
01:50:52FromDiscord<leorize> well, 1.0 tbf
01:50:53FromDiscord<albassort> not nim
01:51:00FromDiscord<polylokh_39446> Beej's Guide is a BSD socket guide, not a Nim guide. I'm not asking you to read a Nim tutorial
01:51:09FromDiscord<albassort> sorry i misunderstood
01:51:15FromDiscord<albassort> yes maybe that would be helpful lol
01:51:46FromDiscord<leorize> typically all networking protocol have the idea of a "frame"
01:51:54FromDiscord<albassort> In reply to @leorize "welcome to http/1.1": wait a second you motherfucker no connection terminates here!
01:52:00FromDiscord<leorize> which tells you how much data is in a "packet" or "message"
01:52:15FromDiscord<albassort> because its a CONNECT
01:52:18FromDiscord<albassort> its keep alive
01:52:24FromDiscord<albassort> it ends when it wants to end
01:53:31FromDiscord<leorize> same thing, how is your connection framed?
01:53:39FromDiscord<leorize> not by nul, certainly
01:53:49FromDiscord<albassort> \r\n\r\n
01:54:01FromDiscord<albassort> is the pattern i've seen
01:54:21FromDiscord<leorize> nope, once connect is established, it's just free form data both ways
01:54:30FromDiscord<polylokh_39446> the HTTP header and the payload are separated by a blank line. That's not the end of the connection.
01:54:38FromDiscord<albassort> oh
01:54:42FromDiscord<albassort> uhh
01:54:44FromDiscord<albassort> im not there yet
01:55:08FromDiscord<albassort> I haven't made it to the natural end of a CONNECT because of my silly socket programming it seems
01:55:28FromDiscord<leorize> the natural end is when one of the endpoint disconnect from my quick spec skim
01:55:39FromDiscord<albassort> yeah that was what i was going to program for
01:55:44FromDiscord<leorize> that's what I meant by "termination is delimination"
01:55:47FromDiscord<albassort> In reply to @leorize "the natural end is": send spec
01:56:26FromDiscord<albassort> I've just been going off reading bytes like im trying to decode a proprietary algorithm because I couldn't find a coherent low level spec
01:56:48FromDiscord<user2m> sent a code paste, see https://play.nim-lang.org/#pasty=sIhCaYgARhRF
01:56:49FromDiscord<leorize> https://httpwg.org/specs/rfc9110.html#CONNECT
01:56:57FromDiscord<leorize> https://httpwg.org/specs/
01:58:09FromDiscord<albassort> ok so it looks like i need to investigate http1/1 specifically
02:00:19FromDiscord<leorize> static seq typically doesn't make any sense↵(@user2m)
02:01:01FromDiscord<albassort> In reply to @leorize "static seq typically doesn't": usually it would be an array[char] if it was static
02:01:28FromDiscord<leorize> openArray is better if you want arbitrary length
02:01:41FromDiscord<albassort> static means compile defined, and that would mean you would have no need for most of the features of a SEQ and so you would use an array. If its static, it also cannot change its length
02:02:28FromDiscord<albassort> i cant wait to program the SOCKS5 proxy
02:02:29FromDiscord<leorize> `openArray[char]` is compatible with `array[I, char]`, `seq[char]` and `string`
02:02:34FromDiscord<albassort> (edit) "i cant wait to program the SOCKS5 ... proxy" added "and shadowsocks"
02:02:37FromDiscord<albassort> (edit) "proxy" => "proxy. I think it'll be easier"
02:02:39FromDiscord<leorize> basically an all-in-one solution
02:03:17FromDiscord<leorize> though for stuff like "allowed\_symbols", `set[char]` is very useful thanks to O(1) lookups
02:12:02FromDiscord<user2m> In reply to @leorize "though for stuff like": ahhh very clever indeed thank you!
02:22:23*def- quit (Quit: -)
02:22:46*def- joined #nim
03:04:35*pbsds3 quit (Quit: The Lounge - https://thelounge.chat)
04:13:35FromDiscord<planetis_m> sent a code paste, see https://play.nim-lang.org/#pasty=vwdDAjUFoxCZ
04:17:12FromDiscord<Elegantbeef> Could turn the operators into `codegendecl`
04:17:16FromDiscord<Elegantbeef> or rather `emit`
04:18:00FromDiscord<planetis_m> though so emit is my best option, thanks beef
04:18:53FromDiscord<Elegantbeef> Does `importcpp` work with `importC`?
04:19:39FromDiscord<planetis_m> I tried it early on and stoped since it forces compilation to C++
04:27:41FromDiscord<ringabout> Does variables of iterators leak into the current scope? It seems to disrupt enums
04:27:56FromDiscord<ringabout> (edit) "of" => "in the inline" | "enums" => "enums."
04:29:58FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=TSbcyHpLkSif
04:31:17FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=hEbJCosBgHrP
04:31:36FromDiscord<polylokh_39446> (edit) "https://play.nim-lang.org/#pasty=YSIdSFViQNEb" => "https://play.nim-lang.org/#pasty=PEHNJVjXuIQU"
04:53:46*rockcavera quit (Remote host closed the connection)
05:51:49*def- quit (Quit: -)
05:52:34*def- joined #nim
06:02:59*def- quit (Quit: -)
06:04:14*def- joined #nim
06:51:44FromDiscord<Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=evClOJfDpNLH
06:51:48FromDiscord<Robyn [She/Her]> (edit) "https://play.nim-lang.org/#pasty=GlAsjqwddGVI" => "https://play.nim-lang.org/#pasty=eLmaeVNJZbeY"
06:52:14FromDiscord<Robyn [She/Her]> This is fun... /s↵I'm trying to use Futhark's project to wrap Binaryen but failing
07:05:51FromDiscord<Elegantbeef> You do realise binaryen uses C++ right?
07:06:31FromDiscord<Elegantbeef> https://github.com/WebAssembly/binaryen/blob/main/src/binaryen-c.h exists
07:08:38FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "You do realise binaryen": It was C headers, that's why I'm using Futhark
07:09:09FromDiscord<Robyn [She/Her]> Oh wait
07:09:11FromDiscord<Elegantbeef> No they are not
07:09:19FromDiscord<Robyn [She/Her]> The `.h` files are C++ headers, aren't they?
07:09:24FromDiscord<Robyn [She/Her]> Besides the `-c` file
07:09:36FromDiscord<Robyn [She/Her]> In reply to @chronos.vitaqua "The `.h` files are": I hate that they're using the same file extension
07:09:43FromDiscord<Elegantbeef> Unless C added namespaces inbetween the last time that I looked and now
07:09:49FromDiscord<Elegantbeef> hpp really should be standard 😄
07:11:43FromDiscord<Robyn [She/Her]> Yeaah
07:16:24Amun-Rahpp looks ugly as, I'm for cc and hh
07:16:26Amun-Ra:)
07:16:41FromDiscord<Elegantbeef> Good thing it's a file extension so it does not matter if it's ugly
07:17:35Amun-RaI trolled my prof once - I had foo.c (C) and foo.C (C++) in my project and he used windows
07:17:42Amun-Rathat did not end well
07:22:45Amun-Ra(.C was quite popular in the old days)
08:14:17*beholders_eye joined #nim
08:28:37NimEventerNew thread by MauroG: Using threads with gui Nigui, see https://forum.nim-lang.org/t/11575
09:14:02*krux02 joined #nim
09:18:33*gst joined #nim
09:42:46*ntat joined #nim
09:50:05*coldfeet joined #nim
10:12:48*beholders_eye quit (Ping timeout: 252 seconds)
10:14:46*beholders_eye joined #nim
10:27:56FromDiscord<sOkam! 🫐> `proc thing(_: void): void= ... `↵Is this the way to make "no arguments" explicit in nim, as you would say `thing(void)` in C
10:28:01FromDiscord<sOkam! 🫐> (edit) "C" => "C?"
10:28:25Amun-Raproc ()
10:28:34FromDiscord<sOkam! 🫐> > "explicit"
10:29:19Amun-Rathis is explicit definition
10:30:13Amun-RaI don't think you can have C-like implicit definitions in nim
10:30:16FromDiscord<sOkam! 🫐> `thing()` is implicit, `thing(void)` is explicit. both work in C↵`proc () = ` is implicity void return, `proc () :void=` is explicit void return↵I'm trying to do the same in nim but for args
10:30:35Amun-Raah, sorry, I thought you wanted that in nim
10:31:15FromDiscord<sOkam! 🫐> yes, i want `thing(void)` in nim, and `proc thing()` is implicit void args in nim, even if it works its still implicit
10:31:24Amun-Raproc () is explicit in nim
10:32:02FromDiscord<sOkam! 🫐> i think that's not the definition of explicit, since you are omitting words
10:32:16Amun-Rathat does not follow
10:32:35FromDiscord<odexine> there is no explicit version. the only way to provide void arguments in nim is by "implicit"
10:32:52FromDiscord<odexine> the only reason there is an explicit and implicit way to define arguments in C is historical
10:33:09FromDiscord<sOkam! 🫐> that example with `(_: void)` does compile, btw, without passing any args. but it felt weird, so figure I should ask
10:33:30FromDiscord<odexine> then i'd say that is the way to define explicit 0 args
10:33:37Amun-Raodexine: it's the other way around
10:33:50FromDiscord<odexine> even though it is arguably less clear than the implicit way
10:33:59FromDiscord<odexine> In reply to @Amun-Ra "<@259277943275126785>: it's the other": which is?
10:34:08Amun-Raimplicit declaration is the one with arguments ommited
10:34:16FromDiscord<sOkam! 🫐> yeah, explicit was added to C because implicit could mean "variable number of args" before explicit void was added to C
10:34:43FromDiscord<odexine> In reply to @Amun-Ra "implicit declaration is the": yes, i dont see how that contradicts what i said
10:34:56Amun-Raodexine | there is no explicit version. the only way to provide void arguments in nim is by "implicit"
10:35:30FromDiscord<odexine> okay, where is the contradiction there
10:35:31Amun-RaI guess we differ what type () is… :P
10:35:48FromDiscord<odexine> i'm using sokam's terminology
10:35:59Amun-Rafor example, () in C++ is explicit
10:36:12FromDiscord<odexine> to me there is no agreed-upon definition for "explicit" "implicit"
10:39:11Amun-Ratbh implicit/explicit means something slightly different than what we've talked above; it's about calling function without previous prototype or declaration
10:42:12Amun-Rafor me nim's foo() has arguments declared explicitely because () in nim has different meaning than C89 style "any number of arguments"
10:50:24*madprops left #nim (Leaving)
11:27:58NimEventerNew thread by thedistantforest: Single parameter version of varargs, see https://forum.nim-lang.org/t/11576
11:28:37FromDiscord<odexine> what does that title even mean what
11:28:44FromDiscord<odexine> oh
11:42:58*coldfeet quit (Remote host closed the connection)
11:43:57FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=yCjgDhhU
11:44:03FromDiscord<Phil> Though the same should also work on gcc
11:44:16FromDiscord<Phil> (edit) "gcc" => "gcc, as in, it should similarly throw compiler errors"
11:49:43FromDiscord<sOkam! 🫐> In reply to @isofruit "Can somebody (on Linux!)": https://media.discordapp.net/attachments/371759389889003532/1238095550767693924/image.png?ex=663e09d6&is=663cb856&hm=6f66ecefd05a0eb7e598e3f0494624cb18c527483e8a91a4573c7afd2b2ddc6c&
11:50:08FromDiscord<Phil> Could you show the compilation commadn to make sure it includes the flags?
11:50:26FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=aJXZuLih
11:50:45FromDiscord<sOkam! 🫐> (edit) "https://play.nim-lang.org/#pasty=BXLhfDfK" => "https://play.nim-lang.org/#pasty=blskXpLy"
11:51:06FromDiscord<sOkam! 🫐> _(ignore my weird local-only setup, im just compiling with a bootstrapped nim)_
11:51:21FromDiscord<Phil> How long have you had threading installed? Mostly asking because your threading package has a different hash than mine
11:51:44FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=ovSBJUjC
11:51:53FromDiscord<sOkam! 🫐> In reply to @isofruit "How long have you": never used it before until you asked
11:52:37FromDiscord<sOkam! 🫐> everytime you install a library it adds a different hash to the folder
11:57:03FromDiscord<Phil> In reply to @heysokam "everytime you install a": Afaik it's only if there's actual changes in the lib that weren't expressed in the source folder, determined by hashing the lib after download
11:57:30FromDiscord<sOkam! 🫐> 🤷‍♂️ i never understood nimble anyway, so I have no clue
11:57:55FromDiscord<sOkam! 🫐> do you want me to manually clone a specific version or something?
11:58:24FromDiscord<Phil> No, it's fine. This confirms with me that it's a specific interim version of the threading package
11:58:38FromDiscord<Phil> And that sth was merged which didn't lead to a version bump afterwards
11:59:00FromDiscord<Phil> Leading to now different "versions" of threading 0.2.0 floating around, one of which is buggy, but thankfully that is the "older" one
11:59:45FromDiscord<sOkam! 🫐> are there two git tags of 0.2.0? afaik nimble works only off of tags, ignoring commits
12:00:08FromDiscord<sOkam! 🫐> _(unless `#head` is passed, ofc)_
12:00:36FromDiscord<Phil> Apparently not, the threading repo has 0 git tags
12:01:43FromDiscord<Phil> I assume it uses git tags as a first preference for determining "checkpoints" ala "0.2.0 is the lib at the commit tagged as 0.2.0" and has various fallback behaviors when there are not git tags
12:08:13NimEventerNew thread by ingo: Forward declare and extend object (I know it does not work), see https://forum.nim-lang.org/t/11577
12:24:18*beholders_eye quit (Ping timeout: 255 seconds)
12:33:18*Jhonny2x4 quit (Quit: Jhonny2x4)
12:33:40*Jhonny2x4 joined #nim
12:55:51*nyeaa49284230101 quit (Ping timeout: 272 seconds)
13:06:02FromDiscord<Robyn [She/Her]> In Nim, are loops expressions and can they return a value?
13:06:49FromDiscord<solitudesf> nope
13:07:35FromDiscord<Robyn [She/Her]> Thanks, how about named functions? `proc myName(): int = 6` and type definitions?
13:07:40FromDiscord<Robyn [She/Her]> Assuming no for both
13:07:43FromDiscord<solitudesf> In reply to @chronos.vitaqua "In Nim, are loops": you can emulate that, for example sugar/collect does it
13:08:18FromDiscord<nervecenter> In reply to @chronos.vitaqua "In Nim, are loops": Yeah `std/sugar.collect()` can do that
13:08:39FromDiscord<Robyn [She/Her]> I'm just wondering rn, since talk of expressions > statements came up in a server I'm in
13:09:17FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=JZUVjqhb
13:10:28FromDiscord<nervecenter> In reply to @chronos.vitaqua "I'm just wondering rn,": I definitely prefer expression-based programming having spent a lot of time with Lisp, and Nim seems to prefer it whenever possible, which is nice. Method-style stateful semantics are very uncommon in the standard library or any other library for that matter.
13:11:45FromDiscord<odexine> In reply to @chronos.vitaqua "Thanks, how about named": neither are expressions if i understand correctly
13:13:46FromDiscord<the_real_hypno> Kd
13:13:59FromDiscord<the_real_hypno> Woops, my mobile fell out of my hands
13:14:28FromDiscord<the_real_hypno> (edit) "hands" => "hands, ignore the "kd" 😛"
13:15:46FromDiscord<Robyn [She/Her]> In reply to @odexine "neither are expressions if": Thanks
13:16:14FromDiscord<Robyn [She/Her]> In reply to @nervecenter "I definitely prefer expression-based": Understandable, tbh I never was into functional programming before so I take these small features for granted when going back to other langs
13:16:50FromDiscord<odexine> i really like for loops as expressions (ehem the 6 letter name that starts with e)
13:18:08FromDiscord<Robyn [She/Her]> Elíxir lmao
13:20:07FromDiscord<odexine> dont say that wtf
13:20:09FromDiscord<odexine> shhh
13:23:10FromDiscord<Robyn [She/Her]> Lmao
13:30:22FromDiscord<System64 ~ Flandre Scarlet> Erlang?
13:34:49*rockcavera joined #nim
13:47:34FromDiscord<odexine> erlang also has for loop expressions iirc
14:04:11*beholders_eye joined #nim
14:24:33FromDiscord<System64 ~ Flandre Scarlet> https://github.com/treeform/vmath↵@treeform Does it support operations on CPU too?
14:25:47FromDiscord<Robyn [She/Her]> Random question: How does a BVec work exactly? :P
14:30:33FromDiscord<demotomohiro> for loop itself cannot be an expression in Nim but there is `forExpr` in grammer: https://nim-lang.org/docs/manual.html#syntax-grammar
14:31:37FromDiscord<treeform> In reply to @sys64 "https://github.com/treeform/vmath <@107140179025735": Vmath only supports the CPU? Your might be thinking of https://github.com/treeform/shady which does some GPU magic as well.
14:31:52FromDiscord<System64 ~ Flandre Scarlet> In reply to @treeform "Vmath only supports the": Oh alright, thanks,
14:31:56FromDiscord<System64 ~ Flandre Scarlet> !
14:42:50FromDiscord<the_real_hypno> Why the Elixir hate? Is it that bad?
14:44:00FromDiscord<the_real_hypno> Kinda feels like im reading a c++ channel, not a Nim one
14:47:07*beholders_eye quit (Ping timeout: 268 seconds)
14:49:31FromDiscord<System64 ~ Flandre Scarlet> In reply to @treeform "Vmath only supports the": Just a question, why making multiple vector types instead of generics?
14:53:37FromDiscord<treeform> Two big reasons:
14:53:51FromDiscord<treeform> Its what GLSL does, so if you have GLSL code laying around its easy to port.
14:54:20FromDiscord<treeform> Its way easier man. Typing [float32] everywhere gets really old!
14:54:52FromDiscord<treeform> It has generic `gvec3[float64]` versinos of everything if you want.
14:55:15FromDiscord<treeform> I think I have a text that create a fixed point type and uses that instead.
14:56:16FromDiscord<System64 ~ Flandre Scarlet> In reply to @treeform "I think I have": Oh alright↵And is there converters?
14:56:55*beholders_eye joined #nim
15:03:01FromDiscord<treeform> vec3 = gvec3[float32]
15:03:07FromDiscord<treeform> no need to convert its just a type alias
15:03:23FromDiscord<treeform> you mean about the fix point
15:03:29FromDiscord<treeform> yes I think I have converters
15:04:15FromDiscord<treeform> I think I did not commit the fix point stuff sorry I probalby did not like it
15:07:16*ntat quit (Ping timeout: 256 seconds)
15:08:08*ntat joined #nim
15:09:53FromDiscord<Robyn [She/Her]> In reply to @demotomohiro "for loop itself cannot": Oh? Is there a node for it though in the AST?
15:12:45FromDiscord<System64 ~ Flandre Scarlet> In reply to @treeform "vec3 = gvec3[float32]": Does it also work with 2d vectors?
15:14:41FromDiscord<treeform> Yes it has vec2, vec4, mat3 and mat4, and quats
15:17:06FromDiscord<System64 ~ Flandre Scarlet> In reply to @treeform "Yes it has vec2,": Oh alright so I can just do vec2[uint16] and use the functions? Nice!
15:17:35FromDiscord<treeform> yes that's right! `gvec2[uint16]` should work
15:18:35FromDiscord<treeform> sent a code paste, see https://play.nim-lang.org/#pasty=IhfnbGwG
15:18:44FromDiscord<treeform> (edit) "https://play.nim-lang.org/#pasty=dORVyBmd" => "https://play.nim-lang.org/#pasty=GpibVkdX"
15:18:55FromDiscord<treeform> that's how UVec2 is made
15:19:17FromDiscord<treeform> https://github.com/treeform/vmath/blob/master/src/vmath.nim#L378
15:19:34FromDiscord<treeform> If you follow that patter and define some helper methods you can have gvec2[uint16] type everywhere
15:19:41FromDiscord<treeform> (edit) "patter" => "pattern"
15:20:52FromDiscord<System64 ~ Flandre Scarlet> In reply to @treeform "If you follow that": Oh alright↵I guess it's the same for Matrices?
15:22:19FromDiscord<System64 ~ Flandre Scarlet> I wanted to make my own vector library, but seems this one fulfills my needs↵However no idea what happens if you try to normalize a vector of ints
15:23:21FromDiscord<treeform> you get unit vector in one direction?
15:23:31FromDiscord<treeform> only +1 and -1 in either x,y,z allowed
15:24:38FromDiscord<treeform> I think you will have a ton of problems using vec2[uint16] as most stuff with sin/cos will not work.
15:25:06FromDiscord<treeform> Nim would throws errors like sin(uint16) or sqrt(uint16) not defined...
15:25:52FromDiscord<System64 ~ Flandre Scarlet> Makes sense↵↵And fixed points are not supported?
15:30:23FromDiscord<albassort> In reply to @polylokh_39446 "recv tells you how": it doesn't seem to
15:32:15FromDiscord<albassort> recv, if there it reaches EOF will wait, and if its interrupted, it will return 0 even if it read data to the buffer
15:32:52FromDiscord<albassort> in effect, it either echos 0 or size
15:33:04FromDiscord<albassort> (edit) "echos" => "returns"
15:51:09FromDiscord<treeform> In reply to @sys64 "Makes sense And": yes, I had a brach with fixed point, but it did not work out.
15:51:45FromDiscord<System64 ~ Flandre Scarlet> In reply to @treeform "yes, I had a": Oh alright↵Fixed is tricky
15:51:49FromDiscord<treeform> (edit) "brach" => "branch"
15:52:24FromDiscord<treeform> Yes I think I tired 32 bit fixed point though 16bit before and 16 bit after decimal.
15:52:34FromDiscord<treeform> I think I also tried float16
15:52:42*gst quit (Quit: Client closed)
15:52:43FromDiscord<treeform> but did not finish
15:53:01FromDiscord<System64 ~ Flandre Scarlet> In reply to @treeform "I think I also": Float16?! Nim has that?!
15:53:06FromDiscord<treeform> no
15:53:13FromDiscord<treeform> I tired to make one for nim though
15:53:36FromDiscord<treeform> float16 computed mostly in software
15:53:44FromDiscord<System64 ~ Flandre Scarlet> In reply to @treeform "I tired to make": Oh alright↵But what are Float16 useful for?
15:53:46FromDiscord<treeform> but would call to float32 for sin/cos/sqrt etc..
15:54:02FromDiscord<treeform> Float16 are used for Machine Learning
15:54:11FromDiscord<System64 ~ Flandre Scarlet> Oh!
15:54:21FromDiscord<treeform> There is also bfloat16 varient
15:54:30FromDiscord<System64 ~ Flandre Scarlet> What is that?
15:54:39FromDiscord<treeform> a different kind of float in 16 bits
15:54:51FromDiscord<System64 ~ Flandre Scarlet> Oh↵And float8?
15:54:53FromDiscord<treeform> float16 matches float32 as much as it can
15:55:00FromDiscord<treeform> and bfloat16 does its own thing
15:55:30FromDiscord<treeform> I don't think there is a float8 standard
15:55:49FromDiscord<treeform> at 8 bit level you go for quantinization
15:55:57FromDiscord<treeform> were you have a row of floats
15:56:12FromDiscord<treeform> first byte is the scale and the next bytes are the integer parts of many floats
15:56:53FromDiscord<System64 ~ Flandre Scarlet> In reply to @treeform "first byte is the": So the integer are multiplied by the scale?
15:58:15FromDiscord<treeform> its a bit more complex: here is a decent explanation: https://towardsdatascience.com/quantize-llama-models-with-ggml-and-llama-cpp-3612dfbcc172
15:58:35FromDiscord<System64 ~ Flandre Scarlet> Gotta have a look asap
15:58:54FromDiscord<treeform> You have like Q2_K Q3_K Q4_K Q5_K ... types
15:58:55*beholders_eye quit (Ping timeout: 246 seconds)
15:59:03FromDiscord<treeform> And they are different per layer
16:09:27FromDiscord<odexine> In reply to @the_real_hypno "Why the Elixir hate?": more just that i mention it too much lol
16:10:17FromDiscord<the_real_hypno> In reply to @odexine "more just that i": Ah i see, so no c++ channel 😛
16:10:37FromDiscord<ieltan> @nocturn9x Hey sorry to ping you, have you resolved your threading issues with Nim ? asking for educational purposes
16:11:24FromDiscord<System64 ~ Flandre Scarlet> is doing something like MyType.doSomething(myArgument) Nim idiomatic?
16:11:33FromDiscord<System64 ~ Flandre Scarlet> (edit) "MyType.doSomething(myArgument)" => "``MyType.doSomething(myArgument)``"
16:13:38FromDiscord<nocturn9x> In reply to @ieltan "<@523555920265871380> Hey sorry to": yes
16:15:53FromDiscord<nocturn9x> sent a long message, see https://paste.rs/vDXvS
16:16:05FromDiscord<nocturn9x> (edit) "https://paste.rs/cLGj1" => "https://paste.rs/CylLC"
16:16:37FromDiscord<nocturn9x> (edit) "https://paste.rs/ETdK1" => "https://paste.rs/xTUEr"
16:17:06FromDiscord<nocturn9x> This was also probably just part of the problem. Switching away from references and using -d:useMalloc surely helped
16:18:19FromDiscord<ieltan> In reply to @nocturn9x "the issue was (I": I see, that's some pretty obscure bug wth lol
16:18:42FromDiscord<ieltan> i'll take note of that gotcha thanks 🙂
16:19:42FromDiscord<ieltan> In reply to @nocturn9x "This was also probably": so yeah i figured that `ref` is utterly useless when you need to share memory across thread
16:19:50FromDiscord<ieltan> you're using minalloc right
16:21:58FromDiscord<threefour> Didn't ARC/ORC change it so that refs can be shared between threads via shared heap? Or is that only ptrs?
16:25:28*wheatengineer joined #nim
16:30:24FromDiscord<ieltan> In reply to @threefour "Didn't ARC/ORC change it": afaik atomic ref only partially solves the issue of sharing memory between threads where you still need to ensure it's writing/reading protected
16:32:04FromDiscord<ieltan> nim approach to this is to try and ensure unique ownership using construct like `isolate` or `isUniqueRef` matt's issue is that he require shared ownership so it goes against nim's design this is why i was interested in how he managed to make it work anyways
16:32:12FromDiscord<ieltan> (edit) "construct" => "constructs"
16:37:06FromDiscord<System64 ~ Flandre Scarlet> Is it normal it shows error while the library is installed? https://media.discordapp.net/attachments/371759389889003532/1238167875152379904/image.png?ex=663e4d31&is=663cfbb1&hm=2fbd11e4ab229efda301e7764393ccf237113640b5f687c1ebacc1ff5cfd5f6c&
16:40:20FromDiscord<ieltan> In reply to @sys64 "Is it normal it": if you've just installed it then reload vscode, otherwise i aint got a clue
16:41:32FromDiscord<System64 ~ Flandre Scarlet> In reply to @ieltan "if you've just installed": Even that didn't worked
16:53:32*wheatengineer quit (Ping timeout: 268 seconds)
17:39:33*disso-peach joined #nim
17:48:27*wheatengineer joined #nim
18:21:32*wheatengineer quit (Quit: Leaving)
18:24:02FromDiscord<Phil> In reply to @threefour "Didn't ARC/ORC change it": Yes, they now technically can. At the same time, unless the kind of multithreading you want is threadpool where you're happy to wait until the threadpool has chunked through all the tasks in parallel and then continue, you're currently not in a happy place with nim
18:25:29FromDiscord<Phil> There is not yet anything that I'd call an easy-to-use actor implementation (which is typically what you'd want for a GUI application where the main thread is in a loop and should just outsource certain tasks to other threads that then eventually send a message back if necessary
18:25:46FromDiscord<Phil> (edit) "necessary" => "necessary)"
18:29:12FromDiscord<Phil> It's also very tricky because the only safe way to do so is by using "isolate", aka proving that your current thread does not hold a reference to whatever you're passing on to the next thread.↵Because nim will absolutely try to call =destroy on that ref when it goes out of scope in your current thread, which will lead to data-races with whenever the other thread calls =destroy on that ref, which may just randomly segfault your applic
18:32:52FromDiscord<Phil> In reply to @ieltan "nim approach to this": It's not just matt's issue. In my opinion the idea behind isolate just fundamentally doesn't work.↵You can't just assume that if you want to send a message from A to B that you can have all the data neatly instantiated within an isolate call. That assumption makes no sense.↵I don't necessarily have a better solution, but std/isolation is not it.
18:40:03*ntat quit (Quit: Leaving)
18:54:46FromDiscord<System64 ~ Flandre Scarlet> Is there an objet in Nim that allows you to have a pointer to data, and a length?↵Like a seq, but I can input the pointer and the length myself
18:55:57FromDiscord<Phil> I'm not aware of one specifically in nim. I mean, you can write your own, it's just an object afterall
18:56:40FromDiscord<System64 ~ Flandre Scarlet> In reply to @isofruit "I'm not aware of": Oh alright↵But is it possible to give it the OpenArray properties?↵So if a proc asks for an OpenArray, I can pass this object
18:56:50FromDiscord<Phil> Beyond me
18:57:10FromDiscord<Phil> Never tried it and openarray is one of those things I basically never use, my C interop is too lacking
19:00:31FromDiscord<System64 ~ Flandre Scarlet> thanks anyways
19:00:47FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://paste.rs/mbP9c
19:07:46*def- quit (Quit: -)
19:08:36*def- joined #nim
19:14:19FromDiscord<Robyn [She/Her]> In reply to @sys64 "Oh alright But is": Implement all the methods that a seq implements and you should be good
19:18:16FromDiscord<threefour> In reply to @isofruit "It's not just matt's": Is an "actor" model something that can be implemented outside of the core language? Not an expert on advanced parallel concepts, nor Nim, so I'm curious.
19:19:25FromDiscord<Phil> In reply to @threefour "Is an "actor" model": I'm not an expert either.↵The "Actor" model is just a "way" that you can do concurrency. It's all about having theads and queues and implementing their interaction correctly
19:19:26FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://paste.rs/KeVdb
19:19:49FromDiscord<Phil> It's just there to make interaction between threads and queues easier
19:20:19FromDiscord<threefour> In reply to @isofruit "I'm not an expert": Right, which sounds like it should be possible to make a library that makes this easier.
19:20:23FromDiscord<Phil> Or rather between threads, you typically abstract away the queues by claiming they're "Mailboxes" where you send messages to
19:20:35FromDiscord<Phil> Oh absolutely, the thing is that that is hard as fuck 😄
19:20:52FromDiscord<System64 ~ Flandre Scarlet> What exception is used for seq out of bounds?
19:21:56FromDiscord<threefour> `IndexDefect`?
19:22:13FromDiscord<Phil> Particularly to do correctly.↵I have an inkling on how it could work, but that is going to take various shortcuts because trying to do the perfect way (moving a ref from one thread to another) in a way that makes sense requires a level of expertise in nim's memory management and hooks that I do not have.
19:24:09FromDiscord<Phil> The shortcut-version is that you don't move messages - you deep copy them instead. Then you still have to deal with a queue that one thread pushes messages into while the other reads from it and you need to manage accessing it, but that is infinitely easier than trying to do that and on top of that deal with the problem "How do you guarantee that a message you receive absolutely definitely does not have a ref that is also accessed elsewh
19:24:11FromDiscord<System64 ~ Flandre Scarlet> In reply to @threefour "`IndexDefect`?": Oh thanks↵and to check if the build is a danger build?
19:24:37FromDiscord<Phil> Together with the problem of "How do you guarantee that the message does not get nim's `=destroy` hook called on it in Thread A after it was moved to Thread B
19:24:51FromDiscord<threefour> Makes sense. Wasn't sure if it was a language limitation.
19:24:53FromDiscord<Phil> I do not have decent answers for either of those problems and I've hit my head enough against the wall to say I no longer care to find them
19:25:08FromDiscord<Phil> Maybe it isn't, I'm just saying I can't figure it out
19:26:09FromDiscord<Phil> (edit) "The shortcut-version is that you don't move messages - you deep copy them instead. Then you still have to deal with" => "sent" | "queue that one thread pushes messages into while the other reads from it and you need to manage accessing it, but that is infinitely easier than trying to do that and on top of that deal with the problem "How do you guarantee that a message you receive absolutely definitely does not have a ref that is
19:27:02FromDiscord<Phil> The entire "How do I figure out that Thread A, after having passed on the message, has absolutely no way to access any of the data that is in the message" problem is in fact so hard that from what I can tell even Araq threw in the towerl
19:27:04FromDiscord<Phil> (edit) "towerl" => "towel"
19:27:21FromDiscord<Phil> std/isolate was his response which imo is not really a solution
19:28:34FromDiscord<Phil> To understand why it isn't a solution, play a bit around with it and see the limitations on what you can isolate and what you can't isolate.↵Note that a very common usecase would be that you instantiate/create a piece of data at one place in your code, e.g. when receiving a user-input, and then want to pass it on elsewhere.
19:29:02FromDiscord<Phil> (edit) "elsewhere." => "elsewhere (for which you must turn it into an "isolated" object)."
19:29:20FromDiscord<threefour> In reply to @sys64 "Oh thanks and to": `defined(danger)`
19:29:22FromDiscord<Phil> If you figure out how to use std/isolate in such a scenario without deep-copying the message you're further along than I am
19:30:48FromDiscord<System64 ~ Flandre Scarlet> In reply to @threefour "`defined(danger)`": Alright thanks!
19:31:52FromDiscord<threefour> So the problem is managing lifetimes when moving between threads?
19:32:29FromDiscord<Phil> sent a long message, see https://paste.rs/cWBxN
19:33:31FromDiscord<Phil> In reply to @threefour "So the problem is": It is one of the main problems and arguably the biggest.
19:35:21FromDiscord<threefour> Gotcha. I think C has the right approach. It's less safe by default, but more flexible. But that's a matter of opinion I guess.
19:36:22FromDiscord<Phil> Overall for an actor model you need to figure out:↵- How do I want to run tasks on another thread? (Spawn a new thread for the task? Have a threadpool ready and the task is just one in queue of tasks that the pool chews through?)↵- How do I move the memory ownership of a message entirely from A to B↵- How do I manage sending messages from A to B in a flexible manner and make sure tasks have access to that mechanism?
19:36:41FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://paste.rs/ELAxR
19:37:15FromDiscord<Phil> In reply to @threefour "Gotcha. I think C": I'm really not sure it is. Nim really only runs into these problems in multithreading space.↵Like, yeah, this problem is harder because of nim's automatic memory management, but also every other piece of code is easier because of that
19:37:33FromDiscord<Phil> You have people with python skills capable of picking nim up in a week or two and be semi-proficient, that's crazy
19:38:16FromDiscord<Phil> The automated memory management facilitates so much and reduces the learn curve and error-risk so much that it really shows its value.↵Threading is just where it sadly does get in the way (currently).
19:40:29FromDiscord<threefour> Fair. I like Nim's "high level by default, low-level when explicitly required" approach. Extending that dynamic to threading would be nice.
19:40:36FromDiscord<ieltan> In reply to @sys64 "Oh alright But is": you can create your own `toOpenArray` proc/template and then use that
19:41:01FromDiscord<ieltan> sent a code paste, see https://paste.rs/1yeNk
19:41:28FromDiscord<System64 ~ Flandre Scarlet> In reply to @ieltan "are you making a": Yeah↵So the user doesn't have to manipulate pointers directly
19:42:14FromDiscord<Phil> sent a long message, see https://paste.rs/tdF3m
19:42:38FromDiscord<Phil> But that assumes you can allow yourself to block until the threadpool churned through its ginormous batch of tasks
19:42:46FromDiscord<Phil> (edit) "But that assumes you can allow yourself to block ... until" added "the main-thread"
19:43:40FromDiscord<ieltan> sent a code paste, see https://paste.rs/OqWTu
19:44:14FromDiscord<zidsal> how would you handle a traditional game server architecture in nim where you have N threads for connections and 1 thread that runs the game loop that also needs to send game state back to the clients?
19:44:34FromDiscord<Phil> That's the scenario that I'd just give up on.
19:44:40FromDiscord<Phil> As in, I have no good answer for you
19:44:46FromDiscord<zidsal> I thought so
19:44:47FromDiscord<System64 ~ Flandre Scarlet> In reply to @ieltan "data field should be": Oh, thanks for the advice
19:44:56FromDiscord<Phil> If the game-state is small enough to deep copy I'd go with that
19:45:13FromDiscord<Phil> If it's large enough that you must move it, I have no strategy that is semi-easily doable
19:45:35FromDiscord<Phil> Maybe Araq has a better idea there, I certainly don't (note, I am not a multithreading expert by any means)
19:45:35FromDiscord<zidsal> it should be able to be small enouigh that copying is fine
19:45:39FromDiscord<zidsal> afterall it needs to go over the wire
19:45:56FromDiscord<ieltan> In reply to @ieltan "data field should be": this is cause iirc `system.toOpenArray()` only has a `ptr UncheckedArray[T]` overload for raw pointers and not `ptr T`
19:45:58FromDiscord<Phil> In reply to @zidsal "afterall it needs to": over the wire means what?
19:46:04FromDiscord<Phil> Like, internet?
19:46:27FromDiscord<zidsal> ya its a server client model
19:46:28FromDiscord<Phil> Are we in a scenario with multiple machines?
19:46:36FromDiscord<Phil> Or is this one machine?
19:46:43FromDiscord<zidsal> multiple
19:47:23FromDiscord<Phil> Oh lord, so you're doing rpc calls since its a game I assume or some stuff... yeah I know next to nothing about things happening in gamdev
19:47:26FromDiscord<Phil> (edit) "gamdev" => "gamedev"
19:47:46FromDiscord<Phil> Beef is a better sparring partner for you then 😄
19:48:07FromDiscord<zidsal> the problem with talking to beef is I instant get hungry
19:48:28FromDiscord<Phil> I mostly tackled multithreading from the perspective of wanting some level of actor model for GUI applications. Didn't have to be the most performant, just a possibility to move stuff to another thread
19:49:20FromDiscord<Phil> Nothing implemented yet, mind you.↵Or rather, I'm currently a bit in the mental planning stage where I'm solidifying my mental model and how I want to structure it all
19:49:34FromDiscord<Phil> Getting the metaphor straight after which I'll be modeling the lib etc.
19:49:41FromDiscord<Phil> (edit) "after" => "with"
19:50:26FromDiscord<Phil> I had a first implementation of a first approach but that has so many limitations and so much error-prone code that it's not worth finalizing that particular pursuit I don't think
19:56:30FromDiscord<Elegantbeef> @Phil I don't use multi threading 😛
20:03:18FromDiscord<System64 ~ Flandre Scarlet> You need a Doctoral degree to master multithreading
20:04:02FromDiscord<Elegantbeef> Nah just need helgrind and valgrind
20:07:54FromDiscord<Phil> and/or asan tsan with the ability to read stacktraces
20:08:07FromDiscord<Phil> And a lot of mental fortitude to deal with some next level bs
20:10:14*krux02_ joined #nim
20:13:20*krux02 quit (Ping timeout: 268 seconds)
20:30:32FromDiscord<xkonti> sent a code paste, see https://paste.rs/3jH7f
20:38:55FromDiscord<ElegantBeef> Bridge dropped a message yay!
20:39:05FromDiscord<ElegantBeef> To answer your question nope only `method` has dynamic dispatch
20:39:09FromDiscord<ElegantBeef> What's even the point of that iterator?
20:39:53FromDiscord<ElegantBeef> If you want to reuse a string buffer just make it `start: int64, str: var string` and use `str.len`'s starting size as the capacity
20:40:18FromDiscord<mratsim> In reply to @threefour "Gotcha. I think C": C has no approach. Anything you can do with C you can do in Nim.
20:40:19FromDiscord<ElegantBeef> then you can define a `readStr` with no `var string` and emit the var and iterate over the file in those chunks
20:40:39FromDiscord<mratsim> Multithreading in C is left as an exercise to the reader
20:40:58FromDiscord<ElegantBeef> Remember when you shoot yourself in the foot use a nailgun so you cannot move your feet to run away from consqueneces
20:43:01FromDiscord<Phil> ... But I really, really want to run away from the consequences!
20:44:54FromDiscord<.lisuwu_> In reply to @elegantbeef "Remember when you shoot": would a shotgun that shoots in opposite direction work
20:45:13FromDiscord<Elegantbeef> I mean it could work I'm not a gunologist
20:45:40FromDiscord<.lisuwu_> but beef i thought you knew everyting !!
20:45:45FromDiscord<.lisuwu_> (edit) "everyting" => "everything"
20:46:43FromDiscord<xkonti> Ok. I guess I'll have the iterator in the base class call a specific method that can be implemented by the subclasses.
20:47:24FromDiscord<Elegantbeef> If you don't stop calling them classes I'll bring out my terminology ticket book
20:47:30FromDiscord<mratsim> In reply to @xkonti "Ok. I guess I'll": but the appeal of such iterator is being inlined, now you add a method indirection?
20:48:05FromDiscord<Elegantbeef> They want to use dynamic dispatch for all their stuff cause they only want the user to use a `CommonFS` type
20:48:31FromDiscord<mratsim> https://tenor.com/view/we-dont-do-that-here-black-panther-tchalla-bruce-gif-16558003
20:48:57FromDiscord<Elegantbeef> I concur, but alas
20:49:00FromDiscord<ieltan> Embed fail
20:49:08FromDiscord<Elegantbeef> Embeds are disabled here
20:49:18FromDiscord<ieltan> lol
20:49:20FromDiscord<mratsim> images and gifd are blocked in the channel so a link is the next best thing
20:51:09*krux02_ quit (Quit: Leaving)
20:51:15FromDiscord<xkonti> @mratsim what @ElegantBeef said. You write your code using the CommonFs abstraction that defines all the things you can do with a "File system". And then you can pick whatever implementation of CommonFs you want. Your code stays 100% the same no matter if you use real file system, in-memory file system, SFTP, S3 buckets, etc. You could even have a case statement that chooses which impentation to instantiate and the rest of the code stays t
20:51:49FromDiscord<Elegantbeef> You could do the same with generics and not have any inheritance trees 😄
20:51:59FromDiscord<Elegantbeef> But there is no boxing with them, you'd have to manually box
20:53:34FromDiscord<xkonti> Hmm... I guess with generics I could define `FileSystem[TImplementation]`, with the TImplementation being a `concept`?
20:54:40FromDiscord<ieltan> If `TImplementation` is a concept then it would be a refinement
20:55:10FromDiscord<ieltan> `FileSystem[T: TImplementation]`
20:55:12FromDiscord<xkonti> But then I would end up with `FileSystem[T]`, `File[T]`, `Dir[T]` everywhere. Library usage would become painful.
20:55:32FromDiscord<Elegantbeef> Hey I dislike dynamic dispatch
20:55:35FromDiscord<Elegantbeef> Don't look at me 😄
20:56:14FromDiscord<xkonti> Hehe I know. My next step will be making EVERYTHING async... And I don't know if one can make the iterator async in Nim...
20:56:16FromDiscord<Elegantbeef> "Didn't you write a library that enables a nice trait-like dynamic dispatch ?!" We don't talk about that
20:56:53FromDiscord<Elegantbeef> Iterators cannot be async, but the code they use can
20:57:23FromDiscord<ieltan> You could just await every yield
20:57:27FromDiscord<xkonti> In reply to @Elegantbeef "Iterators cannot be async,": I guess I need to go back to C# 😦
20:57:47FromDiscord<Elegantbeef> Yea you just await the response
20:58:58FromDiscord<Elegantbeef> Or you yield a future
20:58:58FromDiscord<Elegantbeef> Then you do `await` or `waitfor` on the recieving side
20:59:08FromDiscord<ieltan> Nim has minimal support for dynamic dispatch so yeah if you really really really need it you'll be in a tough spot
20:59:35FromDiscord<ieltan> And oop I guess
20:59:44FromDiscord<System64 ~ Flandre Scarlet> Is it possible to convert a pointer to an UncheckedArray?
21:00:00FromDiscord<solitudesf> yeah, you cast it
21:00:00FromDiscord<Elegantbeef> I'd say it has support it's just not the most C#/Java like
21:00:03FromDiscord<ieltan> In reply to @sys64 "Is it possible to": yeah, so long you know the type of the pointer
21:00:51FromDiscord<System64 ~ Flandre Scarlet> In reply to @ieltan "yeah, so long you": so cast[UncheckedArray[MyType]](myPointer)?
21:02:54FromDiscord<Elegantbeef> `ptr UncheckedArray[T]`
21:06:12FromDiscord<ieltan> In reply to @sys64 "so cast[UncheckedArray[MyType]](myPointer)?": What beef said
21:07:05FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=YVGigWRf
21:09:15FromDiscord<Elegantbeef> I'd personally just do `span.data.toOpenArray(0, span.length)[idx]`
21:09:15FromDiscord<Elegantbeef> Removes all of the above
21:09:16FromDiscord<Elegantbeef> You do not need any of the checks I mean
21:11:04FromDiscord<ieltan> LGTM I guess
21:11:39FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "I'd personally just do": Oh, so can't I just use an OpenArray instead my own type?
21:11:48FromDiscord<Elegantbeef> No
21:12:02FromDiscord<Elegantbeef> `openArray` can only be used as a parameter
21:12:07FromDiscord<System64 ~ Flandre Scarlet> Oh alright
21:12:13*beholders_eye joined #nim
21:12:13FromDiscord<ieltan> does indexing UncheckedArray using `toOpenarray` even make a difference?
21:12:20FromDiscord<Elegantbeef> Yes
21:12:55FromDiscord<Elegantbeef> Cause now it uses `[]` for openArray instead of `Unchecked`
21:13:23FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=hVYKzwcm
21:14:15FromDiscord<ieltan> Ah
21:14:19FromDiscord<ieltan> Duh
21:15:28FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=nYLlmwbR
21:15:54FromDiscord<Elegantbeef> You could or you could juse use open array assignment
21:16:42FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "You could or you": so a = b?
21:16:43FromDiscord<Elegantbeef> Nevermind there is not one for open array
21:17:47FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=ZlnBEttH
21:17:56FromDiscord<Elegantbeef> Well I was thinking `data[0..len] = openArray`1
21:18:02FromDiscord<Elegantbeef> But that's not valid
21:18:33FromDiscord<Elegantbeef> It's only valid for seqs and arrays not openarrays
21:19:20FromDiscord<aintea> sent a code paste, see https://play.nim-lang.org/#pasty=CIQLnHWG
21:19:37FromDiscord<Elegantbeef> Copy the procedure header and call it internally
21:19:44FromDiscord<Elegantbeef> Or use a template for overloaded ones
21:19:48FromDiscord<aintea> how
21:20:00FromDiscord<threefour> In reply to @mratsim "Multithreading in C is": That's what I mean. Making it possible to do it from scratch like in C is good. But having higher-level functionality that takes care of the details is also good. Choosing one over the other is bad.
21:20:03FromDiscord<aintea> wym copy the procedure header
21:20:26FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "It's only valid for": So what can I do to accept seqs, arrays AND spans?
21:20:32FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=PIPyZOWA
21:20:57FromDiscord<Elegantbeef> Make a overloads for `openArray[T]` and `Span[T]`
21:22:44FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "Make a overloads for": Oh alright, thanks↵Is there also a way to do a memcpy? My auto-completion doens't work well :/
21:23:10FromDiscord<ieltan> system.copyMem
21:23:17FromDiscord<ieltan> I think
21:23:35FromDiscord<threefour> What's the equivalent of a void pointer in Nim?
21:23:40FromDiscord<Elegantbeef> Yes it's called `copyMem`
21:23:40FromDiscord<Elegantbeef> It works just the same as the C version
21:23:40FromDiscord<Elegantbeef> dest, src, amount
21:23:41FromDiscord<ieltan> I'm on phone I can't demonstrate how it works lol
21:23:43FromDiscord<Elegantbeef> `pointer`
21:25:45FromDiscord<nocturn9x> In reply to @ieltan "you're using minalloc right": yes
21:25:59FromDiscord<nocturn9x> In reply to @ieltan "so yeah i figured": any sort of shared memory in nim is a lie
21:26:06FromDiscord<nocturn9x> just use `ptr`
21:26:11FromDiscord<nocturn9x> less headaches
21:26:21FromDiscord<nocturn9x> wrap it in some abstractions maybe but yeah that's it
21:27:02FromDiscord<Elegantbeef> Well `SharedPtr` exists
21:27:26FromDiscord<Elegantbeef> No point making your own ref counted shared pointer
21:28:40FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=aqBcICbj
21:29:06FromDiscord<Elegantbeef> More usage of return for no reason
21:29:08FromDiscord<Elegantbeef> You hate to see it
21:30:04FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "You hate to see": Wdym?
21:30:19FromDiscord<Elegantbeef> Stop using `return` when it's an expression
21:30:38FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=CQXuMmfC
21:31:20FromDiscord<threefour> Do all heap allocations in ORC use a shared heap by default? Or do you need to specifically use a `SharedPtr`?
21:31:27FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=wKPraBNF
21:31:37FromDiscord<System64 ~ Flandre Scarlet> Oh, even better
21:31:43FromDiscord<ieltan> In reply to @threefour "Do all heap allocations": Arc/Orc is shared heap yeah
21:31:52FromDiscord<Elegantbeef> Nim uses shared heap by default, but the issue is that the ref counter is not atomic so it attempts to double free
21:32:30FromDiscord<Elegantbeef> Then to add on top of that Orc is not thread safe so it incorrectly frees cycles
21:32:39FromDiscord<threefour> Lol
21:32:45FromDiscord<Elegantbeef> `--mm:atomicArc` does exist which turns all `ref` into equal to `SharedPtr`
21:33:32FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=gbdGTZQK
21:34:03FromDiscord<Elegantbeef> Right
21:35:02*krux02 joined #nim
21:35:34FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=kVqqeOop
21:36:46FromDiscord<threefour> I'm not sure how I feel about implicit returns. When my function is a one-liner, I usually omit it. But if there are any early `returns`, I always make the final line have one too.
21:36:47FromDiscord<ieltan> In reply to @nocturn9x "yes": Aight, ty bro
21:37:00FromDiscord<nocturn9x> no problem
21:37:16FromDiscord<nocturn9x> if I can help someone avoid the madness I went through, that's good
21:37:31FromDiscord<nocturn9x> if anything this motivated me to design the threading model in my language extra carefully
21:37:38*krux02_ joined #nim
21:37:57FromDiscord<ieltan> You're making your own language? That's dedication
21:38:02FromDiscord<nocturn9x> I am
21:38:06FromDiscord<nocturn9x> have been at it for a while
21:38:08FromDiscord<nocturn9x> it's also in Nim
21:38:47FromDiscord<threefour> You must be @Robyn [She/Her]'s alt account
21:38:51FromDiscord<nocturn9x> currently the project is on pause cuz life gets in the way and I'm also working on a far more entertaining project (the chess engine that caused the threading nonsense)
21:39:04FromDiscord<nocturn9x> In reply to @threefour "You must be <@524288464422830095>'s": if I were you'd never know that's for sure
21:39:07FromDiscord<threefour> Jk
21:39:13FromDiscord<nocturn9x> or are you
21:39:18FromDiscord<threefour> 👀
21:39:39FromDiscord<nocturn9x> anyway considering I've ran several thousand games now I'm positive the issue was mostly what I described
21:39:48FromDiscord<nocturn9x> which isn't to say I might not face more in the future
21:39:59FromDiscord<nocturn9x> for my parallel search I'll probably use std/threadpools to avoid this issue
21:40:05*krux02 quit (Ping timeout: 240 seconds)
21:40:06FromDiscord<Elegantbeef> I mean issue is less of design and just unimplemented logic 😄↵(@nocturn9x)
21:40:19FromDiscord<nocturn9x> true, that's fair
21:40:41FromDiscord<nocturn9x> the fact joinThread doesn't clean up the thread vars is, like
21:40:47FromDiscord<nocturn9x> such a low hanging fruit
21:40:51FromDiscord<Elegantbeef> Threadvars do not clear, threads cannot be one shots, the allocator is bugged, ....
21:41:19FromDiscord<ieltan> Death by a thousand gunshots
21:41:35FromDiscord<nocturn9x> my projects usually tend to sacrifice performance for correctness
21:41:37FromDiscord<nocturn9x> always
21:41:49FromDiscord<nocturn9x> I prefer to do the right thing a bit slower than do the wrong thing really fast
21:42:09FromDiscord<nocturn9x> and there's always time for optimization later, when you have a solid base to build off of
21:42:13FromDiscord<threefour> I usually end up doing the wrong thing really slow
21:42:14FromDiscord<nocturn9x> clearly this was not the case here
21:42:29FromDiscord<nocturn9x> that's another issue, but you're not alone xD
21:42:34FromDiscord<nocturn9x> I just fixed an issue in my engine
21:42:39FromDiscord<nocturn9x> you wanna know the prolem
21:42:42FromDiscord<nocturn9x> (edit) "prolem" => "problem"
21:42:50FromDiscord<ieltan> Sounds interesting
21:42:55FromDiscord<nocturn9x> I was doing `self.search()` when I was supposed to do `-self.search()`
21:43:06FromDiscord<nocturn9x> a single byte fucked with the entire null move pruning impl.
21:43:08FromDiscord<nocturn9x> oof
21:43:24FromDiscord<nocturn9x> the reason being that you're looking for your opponent's score, so you have to flip the sign
21:43:31FromDiscord<ieltan> Ugh one off mistakes
21:43:31FromDiscord<nocturn9x> otherwise you get the wrong thing
21:43:57FromDiscord<nocturn9x> but hey, at least: `Elo difference: 37.6 +/- 28.8, LOS: 99.5 %, DrawRatio: 32.4 %`
21:44:04FromDiscord<nocturn9x> still not complete, but _very_ promising
21:44:29FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=THuCLjKE
21:44:42FromDiscord<Elegantbeef> Yes you can
21:44:46FromDiscord<Elegantbeef> Just as an export statement
21:44:50FromDiscord<nocturn9x> yeah
21:44:55FromDiscord<nocturn9x> `export a.b`
21:44:55FromDiscord<System64 ~ Flandre Scarlet> export Palette?
21:44:57FromDiscord<System64 ~ Flandre Scarlet> Oh
21:44:58FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=PETwxmRA
21:45:01FromDiscord<nocturn9x> or that
21:45:02FromDiscord<nocturn9x> yeah
21:45:07FromDiscord<System64 ~ Flandre Scarlet> neat!
21:45:20FromDiscord<nocturn9x> that is one of the features I stole from nim for my compiler
21:45:24FromDiscord<nocturn9x> among many
21:45:42FromDiscord<System64 ~ Flandre Scarlet> So this way I can completely obfuscate the Tilengine module behind my own functions
21:45:56FromDiscord<nocturn9x> isn't abstraction great?
21:46:13FromDiscord<System64 ~ Flandre Scarlet> In reply to @nocturn9x "isn't abstraction great?": There are some things I want to abstract
21:48:59FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=NCsmfzIl
21:49:31FromDiscord<Elegantbeef> I'd name it `init` or `new` depending if it was a value type or reference type
21:50:29FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "I'd name it `init`": seems new is reserved
21:50:53FromDiscord<System64 ~ Flandre Scarlet> proc create(_: typedesc Palette, numEntries: int): Palette =↵ createPalette(numEntries)↵↵let myPal = Palette.create(16)
21:51:08FromDiscord<System64 ~ Flandre Scarlet> https://media.discordapp.net/attachments/371759389889003532/1238246901183152239/image.png?ex=663e96ca&is=663d454a&hm=6fcc09da1388795af0d3bb495919fb3caca48beae6d5c440d7d2dffd9c669cf2&
21:51:12FromDiscord<Elegantbeef> It's not reserved
21:51:25FromDiscord<Elegantbeef> New can be overloaded just fine
21:52:16FromDiscord<System64 ~ Flandre Scarlet> So why do I have this error?
21:53:03FromDiscord<polylokh_39446> `_: static typedesc = Palette`
21:53:47FromDiscord<Elegantbeef> No you do not need static
21:53:56FromDiscord<Elegantbeef> `typedesc[Palette]` should suffice
21:55:03FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=qivBqfqH
21:55:14FromDiscord<Elegantbeef> The former is better
21:55:17FromDiscord<Elegantbeef> As it works with generics
21:55:23FromDiscord<Elegantbeef> Reusable composable code is good code
21:55:55FromDiscord<System64 ~ Flandre Scarlet> The former = First?
21:56:25FromDiscord<Elegantbeef> Yes
21:56:26FromDiscord<polylokh_39446> Yes. former/latter are first/second for pairs.
21:56:42FromDiscord<Elegantbeef> first and last
21:56:59FromDiscord<System64 ~ Flandre Scarlet> oh alright↵thanks for the advice!
21:57:23FromDiscord<Elegantbeef> Hmph does it work for 2 or more items....
21:57:47FromDiscord<polylokh_39446> in this context I don't think so. There are other uses of the words, like "Latter-day Saints"
21:58:19FromDiscord<polylokh_39446> 1. Later; more recent; coming or happening after something else; -- opposed to former.↵-> 2. Of two things, the one mentioned second.↵3. Recent; modern.
21:58:59FromDiscord<polylokh_39446> with 2 or more items, meaning 1 should still work, but I bet people will get confused
21:59:30FromDiscord<Elegantbeef> Clearly it should be formist and lattist
21:59:49FromDiscord<polylokh_39446> and I think it'd be "a latter", rather than "the latter"
22:00:20FromDiscord<polylokh_39446> if Lisp had won we could be saying cadr by now
22:02:41FromDiscord<Robyn [She/Her]> In reply to @threefour "You must be <@524288464422830095>'s": Nope?-
22:32:33FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=PWucrjGw
22:49:43*mal`` quit (Quit: Leaving)
22:51:12FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=YmXQxXYG
22:53:03FromDiscord<Elegantbeef> Speaking of silly returns
22:53:17FromDiscord<Elegantbeef> Why would it delete twice?
22:54:09FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "Why would it delete": Values in functions are passed by copy
22:54:27FromDiscord<Elegantbeef> Not always
22:54:31FromDiscord<Elegantbeef> Plus the copy is immutable
22:54:45FromDiscord<System64 ~ Flandre Scarlet> So in my case, it's not by copy?
22:54:51FromDiscord<Elegantbeef> Values are only passed by copy when they're smaller than sizeof(float) \ 3
22:54:54FromDiscord<Elegantbeef> So yes it's by copy
22:55:20FromDiscord<Elegantbeef> But the copy does not use destructors as that'd cause silly behaviour
22:55:27FromDiscord<System64 ~ Flandre Scarlet> Oh alright↵But why the destructor isn't called at the end of the doSomething()'s scope?
22:55:35FromDiscord<System64 ~ Flandre Scarlet> Oh alright!
22:55:38FromDiscord<Elegantbeef> It's a bitcopy it does not use `=dup` or `=copy`
22:56:26FromDiscord<polylokh_39446> parameters are immutable in Nim, so it's free to pass a pointer for large objects and blit smaller objects
22:56:30FromDiscord<System64 ~ Flandre Scarlet> So with those custom destructors, I can actually make the Tilengine binding safer
22:57:11FromDiscord<Elegantbeef> Yes you can either disable `=dup` or make it call the appropriate internal procs
22:57:52FromDiscord<polylokh_39446> you can also compile with --expandArc:module or --expandArc:proc to see the lifetime functions that get injected
22:58:16FromDiscord<System64 ~ Flandre Scarlet> Wow sounds quite complex
23:09:40*mal`` joined #nim
23:13:11*def- quit (Quit: -)
23:13:24*def- joined #nim
23:26:43*KhazAkar quit (Ping timeout: 255 seconds)
23:59:19FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=zbmCzKIr