<< 20-05-2024 >>
00:00:07FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=GkWIqIrY
00:00:17*lucasta quit (Remote host closed the connection)
00:01:13FromDiscord<fenilli> but wouldn't that defeat the idea of have to redeclare twice the same enums?
00:01:32FromDiscord<Elegantbeef> I don't believe in non ordinal enums so you're asking the wrong person 😄
00:01:47FromDiscord<fenilli> well not that I like it either, just checking on a solution for it.
00:02:17FromDiscord<Elegantbeef> `const sizeToInt = [Small: 12, 20, 32]`↔`const sizeToInt array[AsteroidSize, int] = [12, 20, 32]`↔Also work
00:03:06FromDiscord<fenilli> well tbf I changed how it works so it doesn't really need to be a enum so well might as well use a single array of values at that point.
00:03:06FromDiscord<Elegantbeef> You can even do `[AsteroidSize.low: 12, ....]` 😄
00:05:31FromDiscord<fenilli> but tbf what I would expect from an non ord enum is to have a index and value, so when you iterate over it, you always iterate over index so you can do `ord(Enum[i])` to get value.
00:05:50FromDiscord<Elegantbeef> You can always implement that
00:06:07FromDiscord<fenilli> yeh i'm quite new to the language, so not sure how would I do that yet, probably will play around with macros later.
00:20:05*lucasta joined #nim
00:26:30FromDiscord<albassort> the most annoying thing about profiling thjis
00:26:33FromDiscord<albassort> (edit) "thjis" => "is"
00:26:52FromDiscord<albassort> getting it to quit properly
00:26:53FromDiscord<albassort> like i bound quit() to ctrlc and it wont exit because
00:27:28FromDiscord<albassort> (edit) removed "because"
00:27:33FromDiscord<albassort> it has and theres no prof
00:27:34FromDiscord<albassort> >:(
00:35:04FromDiscord<albassort> https://media.discordapp.net/attachments/371759389889003532/1241912037580214372/profile_results.txt?ex=664bec37&is=664a9ab7&hm=74ce9a2c8e3b06fef22a3195001e3f5ed12a7f4bad8e64e7e848c0afff5992bd&
00:35:06FromDiscord<albassort> here you go beef
00:35:50FromDiscord<Elegantbeef> What a shitty profiler
00:36:00FromDiscord<albassort> are you mad at me?
00:36:20FromDiscord<Elegantbeef> What profiler did you use?
00:36:22FromDiscord<albassort> i simply ran it for a while in real world situtations
00:36:27FromDiscord<albassort> nimprof
00:36:45FromDiscord<albassort> nim c -d:danger --stacktrace:on --profiler:on
00:36:49FromDiscord<Elegantbeef> Right use `--debugger:native -d:release` with hotspot
00:37:01FromDiscord<Elegantbeef> https://github.com/KDAB/hotspot
00:37:03FromDiscord<Elegantbeef> Or use valgrind
00:37:22FromDiscord<albassort> i dont like valgrind
00:37:24FromDiscord<albassort> i will try hotspot
00:37:41FromDiscord<Elegantbeef> hotspot a perf frontend
00:38:11FromDiscord<albassort> but beef, you didn't have any optimization ideas for the code i posted?
00:38:29FromDiscord<Elegantbeef> Don't know what valgrind did to you, but it's fantastic tooling
00:39:27FromDiscord<Elegantbeef> Stop reading 1 byte at a time removes means less IO waiting
00:39:37FromDiscord<Elegantbeef> Stop reading 1 byte at a time means less IO waiting
00:39:45FromDiscord<albassort> yes, that was the solution i was asking for...
00:39:53FromDiscord<albassort> i wanna read 1 mb at a time, and cut off if it runs out of data
00:39:58FromDiscord<Elegantbeef> But you said for certainty it was CPU time
00:40:12FromDiscord<Elegantbeef> > its cpu bound by around 15%
00:40:15FromDiscord<albassort> it is... yes, but they can go hand in hand if it takes cpu time to open it
00:49:57FromDiscord<albassort> ok beef so
00:50:05FromDiscord<albassort> it seems that asynccontinue takes up the most amount of time
00:50:27FromDiscord<albassort> which lines up with my theory that its cpu bound by being io bound and spamming the recv
00:50:36FromDiscord<albassort> so, do you have a better design for that?
00:51:20FromDiscord<Elegantbeef> Read the data to a buffer
00:51:38FromDiscord<albassort> but the buffer will halt if it runs out data
00:51:44FromDiscord<albassort> (edit) "buffer" => "operation"
00:52:01FromDiscord<albassort> and i also cannot know how much data was read
00:52:17FromDiscord<Elegantbeef> `recvInto` returns an int
00:52:56FromDiscord<albassort> not if interrupted
00:52:59FromDiscord<albassort> it returns 0
00:59:43FromDiscord<albassort> sent a code paste, see https://play.nim-lang.org/#pasty=HuCSYGwM
00:59:47FromDiscord<albassort> like this just doesn't work
01:12:48*def- quit (Quit: -)
01:13:27*def- joined #nim
01:15:03FromDiscord<albassort> really the best way to implement this is for recv into to take in a pointer
01:15:03FromDiscord<albassort> and it is updated as data is read
01:18:19FromDiscord<fenilli> If I had a for loop where I check if any of the items in that are "primed" for deletion, how would I delete it, deleting directly there doesn't work as its mutating a seq.
01:18:29FromDiscord<fenilli> (edit) "If I had ... a" added "seq of items in"
01:18:44FromDiscord<Elegantbeef> Iterate the length backwards and delete
01:20:33FromDiscord<fenilli> after the first iteration or create another one?
01:20:44FromDiscord<fenilli> (edit) "create another" => "use the same"
01:25:38FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=cjctVODz
01:25:41FromDiscord<fenilli> sent a code paste, see https://play.nim-lang.org/#pasty=wpkFZDPU
01:25:53FromDiscord<fenilli> yeh I got to this point too
01:26:03FromDiscord<fenilli> thanks
01:26:33FromDiscord<Elegantbeef> Important distinction that using `del` can result in double `updateAsteroid`
01:27:10FromDiscord<fenilli> because it will mutate the asteroidSeq to that specific position correct?
01:27:27FromDiscord<fenilli> the head I mean
01:27:37FromDiscord<Elegantbeef> Actually it won't
01:27:40FromDiscord<Elegantbeef> I'm daft
01:27:54FromDiscord<fenilli> yeh it will just change the head and run the seq again so it should be fine no?
01:28:20FromDiscord<fenilli> because it is countdown so the head will always be the first to check
01:28:36FromDiscord<fenilli> or i'm drunk and not explaining but I get that it won't I think.
01:40:31*def- quit (Quit: -)
01:40:42*def- joined #nim
01:40:56FromDiscord<albassort> sent a code paste, see https://play.nim-lang.org/#pasty=lzHVrEfo
01:41:15FromDiscord<albassort> this design seems to be about as fast as using recvInto and the difference between connecting directly is minable
01:41:22FromDiscord<albassort> threading now shall begin
01:41:50FromDiscord<albassort> (edit) "https://play.nim-lang.org/#pasty=oFaWQPlz" => "https://play.nim-lang.org/#pasty=CHzPLqjF"
01:43:59FromDiscord<m4ul3r> What would be the work flow of compiling nim from the generated cache?↔I am putting cache in the local dir, in the dir of `cache`, then wanting to make manual changes to the C file before recompiling
01:44:56*SchweinDeBurg quit (Quit: WeeChat 4.3.0-dev)
01:45:18FromDiscord<m4ul3r> (edit) "recompiling" => "recompiling↔Obviously the first step is `nim c -c`"
01:51:27FromDiscord<albassort> i would really just fork the compiler or use the native C interop functions
01:51:28FromDiscord<albassort> like
01:51:51FromDiscord<albassort> i would sooner write a C function and call it in nim before adhoc modifying the generated c
01:51:56FromDiscord<albassort> sounds like a better use of my time
01:52:05FromDiscord<albassort> that is to say, this isn't a workflow I've heard of
01:54:45FromDiscord<grumblygibson> It can be informative for certain tasks to modify and compiles like that. You'll need `nimbase.h` from the compiler directory, or to reference it using include flags. Other than that the compilation should be straightforward.
01:54:56FromDiscord<grumblygibson> (edit) "compiles" => "compile"
01:56:34FromDiscord<albassort> its informative for debugging
01:56:36FromDiscord<albassort> but not for working
01:56:40FromDiscord<albassort> because its not meant to be human readable
01:56:47FromDiscord<albassort> (edit) "readable" => "readable, or mutatablle"
01:56:51FromDiscord<m4ul3r> My current solution is a python script that compiles and parses the json for the commands it used to compile and link. Then modify and run that - it works, but I'm really wondering if there's a compiler flag that compiles c the c from cache
01:58:36FromDiscord<Elegantbeef> `--genscript`
01:58:56FromDiscord<Elegantbeef> But the real question is .... why
02:02:22FromDiscord<grumblygibson> As beef is saying, there's probably a better way to accomplish what you want using other mechanisms. Maybe emit C code within your nim file?
02:02:38FromDiscord<m4ul3r> Thanks beef, probably what I’m looking for
02:03:08FromDiscord<albassort> In reply to @grumblygibson "As beef is saying,": thats what i would recommend as well
02:03:20FromDiscord<albassort> using emit you can manipulate GCC and expose things to your C code
02:03:53FromDiscord<m4ul3r> I’m trying to create a PE file that doesn’t include NimMain
02:04:45FromDiscord<Elegantbeef> Sounds like someone is hoping that bypasses malware
02:04:52FromDiscord<Elegantbeef> checks\
02:05:02FromDiscord<Elegantbeef> You can just do `--nimMainPrefix`
02:06:03FromDiscord<m4ul3r> That will still include the call to <Prefix>NimMain and i'm wanting to avoid NimMain entirely. I linked a talk in #security for what this is used for
02:16:46FromDiscord<grumblygibson> `--noMain` doesn't work for you? You can write your own modeled after nim main to set up stuff nim needs, if any for your code.
02:18:12FromDiscord<Elegantbeef> It still generates `NimMain` as that's required
02:18:45FromDiscord<Elegantbeef> A PR to the compiler is all this would take really
02:20:22FromDiscord<m4ul3r> Yeah, for exes I use --noMain and specify a different function as the entrypoint for the linker. gc-collecting the unused symbols will strip NimMain for those, but wasn't for a dll
02:23:58*lucasta quit (Quit: Leaving)
02:36:51FromDiscord<Elegantbeef> In what way does this benefit offensive software?
02:55:47FromDiscord<m4ul3r> I guess what a red teamer would try to accomplish, bypassing defenses. Allows a red teamer to write tools in nim rather than c
03:00:51FromDiscord<Elegantbeef> So the assumption is all Nim software is malware?
03:03:45*krux02 quit (Remote host closed the connection)
03:43:48*SchweinDeBurg joined #nim
03:45:57*def- quit (Quit: -)
03:48:42*def- joined #nim
04:14:59FromDiscord<that_dude.> sent a code paste, see https://play.nim-lang.org/#pasty=ouTQvNTF
04:19:49FromDiscord<Elegantbeef> Stack variables
04:20:53FromDiscord<that_dude.> I assumed that's fine as long as the variable still exists in some scope
04:21:06FromDiscord<Elegantbeef> No cause you write over them before you await
04:22:30FromDiscord<Elegantbeef> those variables only live as long as `creator`
04:22:37FromDiscord<Elegantbeef> Since you exit creator they're written over probably
04:23:08FromDiscord<that_dude.> Fuck you're right. I forgot to put a sleep in there as I was testing it
04:23:37FromDiscord<that_dude.> What I was testing works now. Thanks
04:26:24*def- quit (Quit: -)
04:27:13*def- joined #nim
04:48:15FromDiscord<aryzen> Just for my personal education, is there a way to compile a dynamic library to be used only by Nim? Like, not using ExportC, ImportC?
04:55:17FromDiscord<Elegantbeef> You use exportc and importc
04:55:59FromDiscord<huantian> What if they don’t want to tho
04:56:05FromDiscord<huantian> What if the c key on their keyboard broke
04:56:19FromDiscord<Elegantbeef> Well then I guess fart in the wind
04:57:54FromDiscord<that_dude.> In reply to @aryzen "Just for my personal": If I had to guess, it's because nim complies to C so you'd need to find a way to connect the c code. At that point you have no choice
04:59:12FromDiscord<aryzen> But nim can link the .o files that it produces without any of that
04:59:16FromDiscord<Elegantbeef> Nim does not really have a stable ABI for procedure names
04:59:32FromDiscord<aryzen> Ok I see
05:00:20FromDiscord<that_dude.> Afaik nim can tell the c compiler to link with the produced c code. Not with the nim code directly
05:01:51FromDiscord<Elegantbeef> Yea you just importc and then manually link the static lib
05:02:17*def- quit (Quit: -)
05:03:06*def- joined #nim
06:02:40*def- quit (Quit: -)
06:04:33*def- joined #nim
06:18:57*def- quit (Quit: -)
06:36:51*def- joined #nim
06:45:49*ntat joined #nim
06:46:45*rockcavera quit (Remote host closed the connection)
06:49:24*xet7 quit (Ping timeout: 260 seconds)
06:53:30*def- quit (Quit: -)
06:56:18*def- joined #nim
07:01:09*xet7 joined #nim
07:04:54*def- quit (Quit: -)
07:05:53*def- joined #nim
07:10:10FromDiscord<morgan> is there a way to get docgen to separate out the doc comments for each member var of an object? i have a ton of objects with proc vars, and i;d like to be better about copying in the comment docs from the original c. in some cases it's a lot of documentation
07:10:35*def- quit (Client Quit)
07:10:43FromDiscord<Elegantbeef> Multi line doc comments don't work?
07:11:02*def- joined #nim
07:11:46FromDiscord<morgan> they do, just not as nice looking as normal text outside of a code block
07:12:24FromDiscord<morgan> in some cases it's like 10-20 lines of text, although most are one to a few
07:12:33FromDiscord<sOkam! đŸ«> I don't remember the parser having that feature
07:12:48FromDiscord<Elegantbeef> It does not
07:12:57FromDiscord<morgan> darn ok
07:13:06FromDiscord<sOkam! đŸ«> so docgen would not have it either as a consequence, since its based on the default lang parser
07:13:31FromDiscord<Elegantbeef> You could maybe use a macro but nnkComments are odd ducks
07:14:14FromDiscord<morgan> maybe i could put that it the doc comment that gets put outside it with references to the relevant proc
07:14:14*def- quit (Client Quit)
07:14:27*def- joined #nim
07:21:28*xet7 quit (Ping timeout: 256 seconds)
07:26:21FromDiscord<morgan> hm i can't seem to reference a member var
07:29:08*coldfeet joined #nim
07:34:14*xet7 joined #nim
07:41:56*xet7 quit (Ping timeout: 268 seconds)
07:50:51FromDiscord<morgan> well i just did it with bold text
07:53:32*xet7 joined #nim
08:16:23*def- quit (Quit: -)
08:18:12*def- joined #nim
08:23:09*def- quit (Quit: -)
08:23:27*def- joined #nim
09:20:30*def- quit (Quit: -)
09:21:42*def- joined #nim
09:27:59*def- quit (Quit: -)
09:47:34*def- joined #nim
10:18:38*def- quit (Quit: -)
10:19:56*def- joined #nim
10:27:34*ntat quit (Quit: Leaving)
10:58:37*beholders_eye joined #nim
10:59:00*PMunch joined #nim
11:38:32FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=LJDgBryQ
11:39:10FromDiscord<Phil> One sec, I'll provide a minimal compile command and the stacktraces in a second
11:40:26FromDiscord<Phil> stacktrace in the file.↔Compilation command:↔`nim r -f --debugger:native --cc:clang --threads:on -d:useMalloc --passc:"-fsanitize=address -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer" --passl:"-fsanitize=address -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer" -d:release src/playground.nim` https://media.discordapp.net/attachments/371759389889003532/1242079481796231168/message.txt?ex=664c8829&is=664b36a9&hm=8d89f8f183ad7bce8
11:41:11FromDiscord<Phil> The stacktraces of the memory leak keep pointing in the direction of ThreadDispatcher, but I don't understand why/how
11:58:51*def- quit (Quit: -)
12:16:22*def- joined #nim
12:28:05*beholders_eye quit (Read error: Connection reset by peer)
12:34:04*beholders_eye joined #nim
13:02:07FromDiscord<griffith1deadly> In reply to @isofruit "Does somebody understand where": most leaks of the selector of `Thread Dispatcher`
13:05:54FromDiscord<Phil> In reply to @griffith1deadly "most leaks of the": I mean, yeah, but nilling that one or calling destroy on it doesn't remove the leaks 😄
13:08:42FromDiscord<griffith1deadly> gc issue
13:08:45*rockcavera joined #nim
13:12:55FromDiscord<Phil> I'd say it's not that either since I do a full collect on the thread right before it finishes
13:13:03*def- quit (Quit: -)
13:14:03*def- joined #nim
13:20:55FromDiscord<griffith1deadly> In reply to @isofruit "I'd say it's not": as far as I know, other languages automatically clean memory with gc when a thread is stopped, but in nim we still have to clean it ourselves
13:22:30FromDiscord<Phil> I'm aware, for normal stuff you're fine as well, it's just thread variables, which I already clean up. The only thread variable here is the dispatcher, for which destroying it does not really fix the leak issue, it appears to just leak even more references that were linked to the dispatcher before
13:23:17FromDiscord<Phil> You can try it out, take the example, add `setThreadDispatcher(nil)`, compile it with the asan flag and run - it'll increase the leaked memory from 20kb to 36kb
13:26:25*def- quit (Quit: -)
13:27:09*def- joined #nim
13:30:04*def- quit (Client Quit)
13:30:50*def- joined #nim
13:34:07*def- quit (Client Quit)
13:34:32*def- joined #nim
13:40:41*def- quit (Quit: -)
13:41:24*def- joined #nim
13:56:00*ntat joined #nim
13:56:03*coldfeet quit (Remote host closed the connection)
14:18:06*Mister_Magister quit (Ping timeout: 252 seconds)
14:21:54FromDiscord<threefour> I think I already know the answer to this, but maybe there's a new library I don't know about: is there an equivalent to Go's goroutines for Nim? I know we have async, but it's not gonna work for my case. There's `std/coro` but that doesn't fully fit the bill either.
14:22:20FromDiscord<threefour> Threadpools also aren't quite the same.
14:23:45*def- quit (Quit: -)
14:24:34*def- joined #nim
14:30:32FromDiscord<jviega> I guess it helps if you state your requirements... what are you worried about, etc
14:31:14*def- quit (Quit: -)
14:32:12*def- joined #nim
14:35:08*def- quit (Client Quit)
14:36:36*def- joined #nim
14:37:32FromDiscord<threefour> Multi-threaded coroutines essentially. Spawn as many as you want, and it gets divvied over multiple threads. As far as I can tell, `std/coro` is single-threaded (and "experimental"). Threadpools don't multiplex tasks, they just block on one task. And async/await requires decorating the crap out of your code, and if something blocks somewhere down the line, it apparently screws you over.
14:39:05FromDiscord<threefour> Seems like we have established options for every avenue except the one I'm trying to go down. I must be the problem, but I find it hard to beat Go's approach, especially for networking tasks.
14:39:58FromDiscord<threefour> Would be killer to replicate Go's easy parallel concurrency without the ugly overly-verbose syntax.
14:40:50FromDiscord<nnsee> In reply to @threefour "Multi-threaded coroutines essentially. Spawn": malebolgia?
14:42:41FromDiscord<threefour> Ooo I was under the impression that Weave and Malebolgia were only for parallelism alone. Looks like it might be what I need. Thanks.
14:43:38*def- quit (Quit: -)
14:46:10*def- joined #nim
14:48:09*krux02 joined #nim
14:49:48*krux02 quit (Client Quit)
15:27:09FromDiscord<nnsee> lol @ malebolgia language distribution https://media.discordapp.net/attachments/371759389889003532/1242136540805595276/image.png?ex=664cbd4d&is=664b6bcd&hm=306eaba2c1616a6ac12d649478c48e514b1b2890fbada7cd351f4667cf51f101&
15:29:37*ntat quit (Quit: Leaving)
15:33:51*def- quit (Quit: -)
15:35:27*def- joined #nim
15:36:22FromDiscord<demotomohiro> That "Languages" bar should exclude data files for benchmarking or testing.
15:42:16NimEventerNew thread by Isofruit: Spot the memory leak when using Chronos and Chronos/threadsync.ThreadSignalPtr, see https://forum.nim-lang.org/t/11623
15:48:23FromDiscord<threefour> Yeah ~300 lines of code is a wonderful dependency.
16:08:09FromDiscord<saint.___.> In reply to @demotomohiro "That "Languages" bar should": Ya
16:27:35NimEventerNew thread by ingo: Find field value object in seq and declared object in seq, see https://forum.nim-lang.org/t/11624
16:56:32*def- quit (Quit: -)
16:57:17*SchweinDeBurg quit (Quit: WeeChat 4.3.0-dev)
16:57:48*def- joined #nim
17:02:24FromDiscord<threefour> Okay Malebolgia is exactly what I needed. My project is finally past its major block.
17:04:13FromDiscord<Phil> In reply to @threefour "Okay Malebolgia is exactly": How do you use it for your purposes?
17:04:19FromDiscord<Phil> Do you have to call in a blocking manner?
17:04:39FromDiscord<Phil> As in, spawn thread to do thing and then block mainthread eventually for it to respond?
17:07:05FromDiscord<threefour> No, main thread runs in infinite loop. When I receive a connection, I dispatch the new client's `Socket` to a request parser with `spawn`, which then hands off to a router, which then hands off to middleware, which then hands off to a responder, which finishes off the connection itself. So nothing ever touches the main thread again once it leaves.
17:10:13FromDiscord<threefour> My issue before was finding something that let me `spawn` in a way that used multiple threads, while being fair to other tasks while IO-intensive tasks run, without using async/await, without having to know all the tasks that will be spawned from the beginning, and without being required to await all of them.
17:10:42FromDiscord<threefour> All boxes which Malebolgia thankfully checks.
17:12:38FromDiscord<threefour> (Impressively in ~300 lines)
17:18:18*ntat joined #nim
17:22:56FromDiscord<Phil> Mind showing me a small code example?↔Mostly asking because I couldn't wrap my head around using malebolgia to shoot off one-off tasks
17:23:41FromDiscord<Phil> I always just saw a ton of master.awaitAll which looked like blocking code
17:24:36FromDiscord<threefour> As soon as I push the last bit of refactor I'll send you the link to my repo.
17:25:16FromDiscord<threefour> In reply to @isofruit "I always just saw": Yeah in its README:↔> Detach the notion of "wait for all tasks" from the notion of a "thread pool".
17:26:17FromDiscord<threefour> Downsides: Nimble package version was never updated from 0.1.0, and thread count must be set at compile time for some reason.
17:55:47FromDiscord<albassort> just to confirm
17:55:58FromDiscord<albassort> UDP sockets are completely unbuffered in nim
17:56:08FromDiscord<albassort> (edit) "UDP sockets are completely unbuffered in nim ... " added "stdlib"
17:56:33FromDiscord<albassort> (edit) "stdlib" => "stdlib?"
17:56:48FromDiscord<albassort> if i do a recv but there is more to the message, its burned?
18:00:48*PMunch quit (Quit: leaving)
18:02:16FromDiscord<polylokh_39446> if there's more to the message, you can recv again and get it. That's how sockets work.
18:03:20FromDiscord<polylokh_39446> if you're using a selector, you'll know there's more to get. If you're asking this question I think you're not using selectors properly.
18:03:54FromDiscord<polylokh_39446> this stuff: <https://nim-lang.org/docs/selectors.html>
18:05:11FromDiscord<polylokh_39446> Nim doesn't have its own kind of networking. It uses the same APIs as every other language.
18:09:42FromDiscord<albassort> @polylokh_39446 well I was talking more specifically because of the recvfrom function
18:09:47FromDiscord<albassort> It has a note that says it's unbuffered
18:10:01FromDiscord<albassort> (edit) "unbuffered" => "unbuffered, it's buffered implementation does not exist"
18:11:12FromDiscord<albassort> Also I didn't know what a selector was so I will read up on this
18:11:16FromDiscord<albassort> :)
18:11:43FromDiscord<albassort> And no, I know that sockets are universal but to and no, I know that sockets are universal in the concept but their implementations are individual and can have bugs or nuances
18:12:15FromDiscord<albassort> (edit) removed "but to and no, I know that sockets are universal in the concept"
18:12:29FromDiscord<polylokh_39446> that means it ignores Socket's buffer, the Nim type. "buffered sockets" are something the library does, that the underlying API doesn't care about.
18:13:45FromDiscord<polylokh_39446> The warning there is to not mix buffered and unbuffered calls on the same Socket.
18:14:31FromDiscord<polylokh_39446> but you're not going to lose data or anything from using recvFrom.
18:19:44FromDiscord<albassort> sent a code paste, see https://play.nim-lang.org/#pasty=EaXPsSeQ
18:19:48FromDiscord<albassort> (edit) "https://play.nim-lang.org/#pasty=WycoIcQl" => "https://play.nim-lang.org/#pasty=oDzLKRqz"
18:19:52FromDiscord<albassort> @polylokh_39446 this is what i mean
18:20:14FromDiscord<albassort> (edit) "https://play.nim-lang.org/#pasty=GoEVSZXW" => "https://play.nim-lang.org/#pasty=uUXtirGG"
18:20:45FromDiscord<albassort> after recvFrom, it burns the data and the "1" is irretrievable
18:22:12FromDiscord<_.elias._> sent a code paste, see https://play.nim-lang.org/#pasty=PtEvsHOL
18:24:21FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=GGGdNpyW
18:25:41*coldfeet joined #nim
18:25:54FromDiscord<albassort> I understand but this means I cannot read arbitrary data from udp
18:26:50FromDiscord<albassort> I would rather it be buffered, when recvd where it would read into a large buffer, but I only read the size I request, so I don't lose any data
18:27:16FromDiscord<albassort> Is this not what a buffered socket is in a TCP context
18:28:41FromDiscord<polylokh_39446> asyncnet: proc recvFrom(socket: AsyncSocket; data: FutureVar[string]; size: int; address: FutureVar[string]; port: FutureVar[Port]; flags = {SafeDisconn}): owned(Future[int])
18:28:49FromDiscord<polylokh_39446> the 'data' there is the buffer you should be recv'ing into.
18:29:06FromDiscord<polylokh_39446> the warning about buffering/unbuffering has nothing to do with that.
18:34:49FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=yrmDsVJS
18:35:07*coldfeet quit (Remote host closed the connection)
18:35:07FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=lCKVdbYu
18:36:01FromDiscord<polylokh_39446> epoll's the selector there. '3' is the UDP socket. '4' is the epoll fd.
18:36:50FromDiscord<polylokh_39446> on the line prior to the recvfrom, epoll says: hey, '3' has some data↔so asyncnet calls recvfrom to get 10 bytes of it.
18:37:14FromDiscord<polylokh_39446> then asyncnet removes 3 from epoll and re-adds it, asking for any further input events.
18:39:22FromDiscord<polylokh_39446> I think either the removal prevents epoll from reporting on the input that's still available, since it's not a new event, or that epoll expects reads to continue until failure.
18:40:09FromDiscord<polylokh_39446> so, the data is still there, you could read it, but asyncnet won't read it because asyncnet is waiting for epoll to say that there's something to read.
18:42:39FromDiscord<polylokh_39446> what I'd do at this point is forgo async entirely. Any easy workarounds like always trying to read larger-than-necessary packets could burn you in practice.
18:53:21FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=agKNPJCX
18:54:20*sadome joined #nim
18:54:20*sadome quit (Changing host)
18:54:20*sadome joined #nim
18:54:21*sadome quit (Excess Flood)
18:57:01FromDiscord<polylokh_39446> https://media.discordapp.net/attachments/371759389889003532/1242189353996783649/Screenshot_from_2024-05-20_13-56-24.png?ex=664cee7c&is=664b9cfc&hm=162efe3e2d9632d843a72703b95330318ff0091d0a08f342eb8a106f9d528825&
18:58:51FromDiscord<polylokh_39446> That ChatGPT message explains this in a way that applies equally well to TCP, where the second recvfrom would definitely succeed, so meh.
18:59:47FromDiscord<albassort> You can just run the code
18:59:52FromDiscord<albassort> The code I wrote compiles fine
19:00:11FromDiscord<albassort> If it works on your machine then somethings weird
19:02:29FromDiscord<polylokh_39446> tldr: you're right that reading 10 bytes makes the 11th byte unavailable. Stick with known packet sizes for UDP or use TCP, or experiment with reading 'large-enough' amounts of data at a time.
19:03:39FromDiscord<albassort> The entire principal of my project requires that I accept arbitrary data in UDP form
19:04:01FromDiscord<albassort> I think that this is a Nim STDLIb and netty has my back here
19:05:53FromDiscord<polylokh_39446> OK, I think this is how UDP works and that your project's misguided.
19:11:45FromDiscord<albassort> In reply to @polylokh_39446 "tldr: you're right that": seems like the solution is to make a buffer 2^32 big then fill the udp into the buffer, truncate it, then return it
19:12:07FromDiscord<albassort> (edit) "it," => "it when the stream ends,"
19:12:27FromDiscord<albassort> but that might have to be on the OS Level?
19:12:29FromDiscord<albassort> (edit) "Level?" => "level?"
19:12:30FromDiscord<albassort> o.o
19:14:44FromDiscord<polylokh_39446> no, just recvfrom with a large buffer.
19:14:57FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=qSvdRciW
19:15:07FromDiscord<polylokh_39446> long modified C server example from beej's guide
19:16:05FromDiscord<polylokh_39446> you can run that with strace, and then talk to it with netcat↔`echo google.com1 | nc -u localhost 12346` results in a single recvfrom that reads "google.com", and then the next one blocks
19:16:51FromDiscord<polylokh_39446> the OS throws away unread portions of UDP packets.
19:17:04FromDiscord<albassort> In reply to @polylokh_39446 "no, just recvfrom with": yes but in nim at least, recvLine terminate when the connection terminates... wait i didn't test this with udp
19:17:32FromDiscord<albassort> it does lol
19:17:38FromDiscord<albassort> oh so this whole conversation was pointless
19:17:40FromDiscord<albassort> lol
19:17:50FromDiscord<albassort> 😆
19:17:52FromDiscord<albassort> thats a good one
19:17:53FromDiscord<polylokh_39446> yeah, sorry. I was wrong in the very beginning.
19:18:31FromDiscord<polylokh_39446> I always think of UDP as "unreliable TCP", but it has more differences like this
19:18:54FromDiscord<albassort> you got it backwards actually, funnily enough
19:19:12FromDiscord<albassort> a few days ago you told me to use recvInto in TCP with a large buffer, that doesn't work
19:19:25FromDiscord<albassort> (edit) "work" => "work, it doesn't stop when the recv stops"
19:19:31FromDiscord<albassort> you need to do that C server
19:19:38FromDiscord<albassort> where you recv 1 then continue recving
19:19:45FromDiscord<albassort> but for UDP you need to do a large recvInto
19:20:11FromDiscord<albassort> its fine though. This is a general programming language and discord so networking mastery shouldn't be expected from people here...
19:24:20FromDiscord<Phil> Oh hey, fixed my leak problem.↔Now I found a different leak problem
19:42:30*def- quit (Quit: -)
19:43:05*def- joined #nim
19:53:14*ntat quit (Quit: Leaving)
19:55:05*coldfeet joined #nim
20:02:00FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=QbiARRDo
20:04:09FromDiscord<rakgew> would the channel not be first opened before send and then closed afterwards?
20:04:54FromDiscord<Phil> you're thinking system.channels, threading channels work different
20:13:18*xet7 quit (Remote host closed the connection)
20:17:28FromDiscord<Phil> Okay, that leaks because a channel with stuff in it just generally leaks
20:17:40FromDiscord<Phil> Now to figure out the hell is going on with why I have leaks
20:23:37FromDiscord<albassort> Phil doing the Lord's work
20:23:42FromDiscord<albassort> Fixing our leaky pipes
20:23:53FromDiscord<albassort> Channels have been leaky for a while and this has been known about
20:23:59FromDiscord<albassort> I remember seeing them be leaky two or three years ago
20:24:07FromDiscord<Phil> I don't think they are
20:24:17FromDiscord<Phil> It's more a usage thing that isn't obvious
20:24:50FromDiscord<albassort> I remember running an application that would gradually accrue memory even though the I/o was of fixed length
20:25:03FromDiscord<Phil> Sure, can still be usage error
20:25:18FromDiscord<Phil> This shit just isn't easy
20:26:09FromDiscord<albassort> sent a code paste, see https://play.nim-lang.org/#pasty=IJNeWArH
20:26:14FromDiscord<albassort> (edit) "https://play.nim-lang.org/#pasty=pvrVGvKh" => "https://play.nim-lang.org/#pasty=KcQuzgSQ"
20:26:55FromDiscord<albassort> creating the channel on shared heap
20:26:57FromDiscord<albassort> (edit) "creating the channel on ... shared" added "the"
20:28:24FromDiscord<Phil> Nope
20:29:02FromDiscord<albassort> hmm
20:29:12FromDiscord<albassort> is newChan[T]() new?
20:29:17FromDiscord<albassort> and does that work between threads?
20:29:44FromDiscord<Phil> It's been that way ever since I encountered threading more generally which is by now around 8 months ago or so
20:30:13FromDiscord<albassort> haha i've been threading longer than phil
20:30:16FromDiscord<albassort> lalala
20:30:39FromDiscord<albassort> although hes older and more experienced than me so he probably knows more than me
20:30:44FromDiscord<albassort> (edit) "although hes older and more experienced than me so he probably knows more than me ... " added ":p"
20:30:48FromDiscord<Phil> Not that crazy an accomplishment given that I prefer to not want to deal with that stuff
20:31:09FromDiscord<albassort> I like threading, I solving race conditions is one of my favorite problem types
20:31:12FromDiscord<Phil> Particularly given the last 8 months proving me correctly with a brutality that is frankly unnecessary but eh
20:31:15FromDiscord<albassort> (edit) removed "I"
20:31:28FromDiscord<albassort> you get used to it
20:31:29FromDiscord<Phil> I hate the stacktaces
20:31:30FromDiscord<Phil> So bad
20:31:33FromDiscord<albassort> oh yeah
20:31:35FromDiscord<Phil> They're such cryptic garbage
20:31:39FromDiscord<albassort> you never get used to that
20:31:46FromDiscord<albassort> because there aren't stacktraces
20:31:48FromDiscord<Phil> I'd not mind if the problem made any fucking sense
20:31:49FromDiscord<albassort> it just segfaults
20:31:53FromDiscord<albassort> and you go
20:31:54FromDiscord<albassort> o.o
20:32:00FromDiscord<Phil> Oh no, I do have stacktraces
20:32:03FromDiscord<Phil> asan
20:32:11FromDiscord<Phil> They just make no fucking sense 80% of the time
20:32:34FromDiscord<Phil> It's never a simple looking and understanding you were dumb, it's always basically a PHD adventure
20:33:15FromDiscord<albassort> nimphd when
20:34:52*khazakar_ joined #nim
20:34:52FromDiscord<albassort> another reason I don't wanna get a degree in compsci or software engineering is the potential of having to write code in Java
20:54:11*coldfeet quit (Remote host closed the connection)
21:04:02*def- quit (Quit: -)
21:22:23*def- joined #nim
21:34:55FromDiscord<ario.ab> I had staked some NIM a few weeks ago. Now, when I connect my wallet, the tokens in my wallet are showing, but the amount I staked isn't displaying. What's the reason for this?
21:35:52FromDiscord<griffith1deadly> lol
22:08:36FromDiscord<grumblygibson> In reply to @albassort "nimphd when": right behind cppphd, pronounced "seffffft" which coincidentally is the same sound someone makes when they have become so overwhelmed that they can't talk anymore.
22:09:36FromDiscord<albassort> the noise i make when im on acid and can no longer communicate is "uuuuuuuuuuuuuuuuuuuuhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh"
22:09:52FromDiscord<albassort> while sober the sound i make is ""
22:10:10FromDiscord<albassort> doAssert(soundIMake.high == -1)
22:35:35*rockcavera quit (Remote host closed the connection)
23:04:18*khazakar_ quit (Quit: Connection closed for inactivity)
23:14:33*rockcavera joined #nim
23:22:28*def- quit (Quit: -)
23:23:14*def- joined #nim
23:32:23*beholders_eye quit (Ping timeout: 264 seconds)
23:42:55*pmp-p quit (Ping timeout: 256 seconds)
23:44:03*jkl quit (Ping timeout: 252 seconds)
23:44:28*jkl joined #nim
23:46:36*pmp-p joined #nim
23:59:12*def- quit (Quit: -)
23:59:33*def- joined #nim