<< 10-05-2024 >>
00:00:31FromDiscord<sOkam! 🫐> Its failing somewhere inside `std/sets incl`... about hashset not having an `items` iterator? 🧩
00:04:38FromDiscord<sOkam! 🫐> Oh, well, this might explain it... https://media.discordapp.net/attachments/371759389889003532/1238280499248758815/image.png?ex=663eb615&is=663d6495&hm=38e07ef0778dbca344a7211cca4016f385cb1e57a389cb262224e5abe5b66761&
00:04:55FromDiscord<sOkam! 🫐> It is declared -after- `incl`
00:06:50FromDiscord<sOkam! 🫐> nevermind, still doesn't work after moving it up
01:09:35*beholders_eye quit (Ping timeout: 264 seconds)
01:14:55*def- quit (Quit: -)
01:15:31*def- joined #nim
01:33:34FromDiscord<xkonti> Does Nim use the `?` prefix operator for something? As in `let one = ? something` . I'm so dering if it would be possible to make some kind of template/macro that translates type `?T` into `Option[T]` and then one that translates `?value` into `some value`
01:42:13*def- quit (Quit: -)
01:43:11*def- joined #nim
01:48:04FromDiscord<Elegantbeef> Nope that's a common overloaded procedure
01:48:58FromDiscord<demotomohiro> In reply to @xkonti "Does Nim use the": https://nim-lang.org/docs/system.html↵Open this page and search "`?`".
01:49:38FromDiscord<demotomohiro> It seems some stdlib module uses `?` operator.
01:54:36FromDiscord<demotomohiro> It seems this macro do what you want:↵https://nim-lang.org/docs/wrapnils.html#%3F%3F..m%2Ctyped
01:56:53FromDiscord<polylokh_39446> no, that's for intermediate nils, similar to the Kotlin experience with nullable types, without the inference.
02:46:03FromDiscord<xkonti> Than you guys!
02:46:20FromDiscord<xkonti> (edit) "Than" => "Thank" | "Thankyou guys! ... " added "This discord is AMAZING!"
02:47:04FromDiscord<Elegantbeef> Wait "discord"?
02:53:08*krux02_ quit (Quit: Leaving)
03:03:02FromDiscord<huantian> Has anyone mentioned that one package that does that for you
03:03:15FromDiscord<huantian> I can never remember the name tho
03:37:47FromDiscord<xkonti> In reply to @Elegantbeef "Wait "discord"?": By "discord" I mean all the people that hang out here and help out 🙂
03:38:05FromDiscord<Elegantbeef> Of course I was just joking
04:32:02*def- quit (Quit: -)
04:32:27*def- joined #nim
05:23:43FromDiscord<Phil> Wait, why can't a deep-copied ref-type be isolated
05:25:32FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=sVqrMqVT
05:26:38FromDiscord<Elegantbeef> Wait you're being serious
05:26:57FromDiscord<Elegantbeef> It's cause `deepCopy` is not marked as a place that is isolated manually
05:27:19FromDiscord<Phil> So this is a situation of me knowing more than the compiler so I need to use unsafeisolate?
05:27:45FromDiscord<Elegantbeef> Sure in this case cause `deepCopy` is not considered isolated
05:30:32FromDiscord<Phil> In reply to @Elegantbeef "Wait you're being serious": I am dense enough to always be serious when it comes to these things 😛
05:31:31FromDiscord<Elegantbeef> It was more of a "Does he not realise isolate is generally ill designed"
05:32:57FromDiscord<Phil> I keep hoping for the best
05:35:30FromDiscord<Phil> Out of curiosity, is there a way to "turn" a ref-type instance somehow into a ptr-type instance? By that I mean basically "disabling" the GC for it if it touches a given proc
05:36:16FromDiscord<Phil> The idea would be (as a potential follow up for later) to, instead of deep copying, "disable" the GC for a given instance if it gets pushed through a channel and manually deallocate on the other side (or enable it there)
05:36:24FromDiscord<Phil> (edit) "GC" => "GC/hooks"
05:37:55FromDiscord<Elegantbeef> `GcRef` it
05:37:55FromDiscord<Elegantbeef> Then you need to `GcUnref` it to destroy it
05:39:03FromDiscord<Phil> I'll keep that in mind as a potential strategy, basically providing some kind of "unsafe" mode or the like (since there's no guarantees you don't have a ref of anything anywhere else)
05:39:21*coldfeet joined #nim
05:39:50FromDiscord<Phil> Boy do I look forward to clang 18
05:40:01FromDiscord<Phil> The fact that tsan requires me to adjust my mmap value is grating over time
05:41:20FromDiscord<Phil> Okay, first: Minor victory dance!↵I could prove that a minimal example loses its data-races with the deep-copy strategy, given how slow as molasses progress with anything threading related can be I take that as a win
06:23:46*PMunch joined #nim
07:03:50*xet7 quit (Remote host closed the connection)
07:16:29FromDiscord<bung8954> when I run nimscript on m1 macbook whether `buildCPU` or `defined(amd64)` is valid, any thought ?
07:22:41Amun-RahostCPU? yes
07:28:02FromDiscord<arnetheduck> In reply to @xkonti "I used "raises" pragma": chronos supports `raises`
07:37:53NimEventerNew Nimble package! easter - Easter date calculation engine., see https://github.com/GeK2K/easter
07:47:04FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=faXBIWrD
07:47:35FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=xYmuVfTr
07:48:17FromDiscord<Elegantbeef> What?
07:48:17FromDiscord<Phil> `getTypeInfo` also does not work - the pointer it returns is identical for any A[T] and B[T] where T is the same
07:48:37FromDiscord<Elegantbeef> Oh this is the compiler bug where you need an empty field inside an object
07:48:44FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=ujVREpHO
07:48:56FromDiscord<Phil> ... >_> oh come on
07:49:09FromDiscord<Phil> I wasn't even trying that hard
07:49:32FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=uwRdSRKm
07:49:42FromDiscord<Elegantbeef> Hey it's a pretty shitty bug and I think it's a showstopper
07:49:59FromDiscord<Elegantbeef> This effects destructors, typematching and everything type related
07:50:37FromDiscord<Phil> Do you happen to know the github issue ?
07:50:49FromDiscord<Elegantbeef> There are a few
07:50:53FromDiscord<Elegantbeef> One second
07:51:13FromDiscord<Phil> Luckily it's not a show-stopper for me, it is "merely" annoying
07:51:42*xet7 joined #nim
07:52:11FromDiscord<Elegantbeef> https://github.com/nim-lang/Nim/issues/22445↵https://github.com/nim-lang/Nim/issues/23394↵https://github.com/nim-lang/Nim/issues/22479
07:52:18FromDiscord<Elegantbeef> Last one is the 'real' issue I think
07:55:38FromDiscord<Phil> In reply to @Elegantbeef "This effects destructors, typematching": Oh wait, the implications of this just clicked in my head... damn that is pretty bad
07:55:54FromDiscord<Phil> Luckily not too much of an issue since most of the time you don't write your own destructors
07:55:56FromDiscord<Elegantbeef> Yep all `A[T]` are the same
07:56:07FromDiscord<Phil> But still, it basically invalidates custom hooks
07:56:20FromDiscord<Phil> custom destroy-hooks
08:00:03FromDiscord<Elegantbeef> The funny thing is that your original code compiled but it should have inferred the `[T]` to be `int`
08:00:12FromDiscord<Elegantbeef> Generic conversions are not supposed to need the parameters iirc
08:01:03FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=nJJJPDdL
08:05:17*PMunch quit (Ping timeout: 240 seconds)
08:14:37FromDiscord<Phil> Can you not turn a closure into a pointer like a normal proc?
08:14:48FromDiscord<Elegantbeef> Nope cause it has an environment
08:15:01FromDiscord<Elegantbeef> you can do `rawProc` to get the raw proc but it still has a hidden parameter
08:22:04FromDiscord<Phil> Okay so storing closures associated with typestrings is out, better approach likely is what I did with threadbutler and store a ptr to the channel and given a T cast the ptr back
08:27:05FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=NvNxtsbY
08:31:20FromDiscord<Elegantbeef> That loses module safety
08:31:31FromDiscord<Phil> ?
08:31:33FromDiscord<Elegantbeef> In the case two symbols are identical it produces a bad value
08:31:47FromDiscord<Phil> Ahhhh shhhhhhhnuckums
08:32:21FromDiscord<Phil> Man I need some kind of hash bullshit, seriously.↵... maybe if I just append `default(T).getTypeInfo()` it's unique enough?
08:33:12FromDiscord<Elegantbeef> Then store that on the mailbox for type safety
08:33:12FromDiscord<Elegantbeef> Whoops
08:33:12FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=GllrTbSK
08:33:14FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=pIczaTzZ
08:33:26FromDiscord<Phil> I'm switching client, one sec
08:34:29FromDiscord<Elegantbeef> Might run in the same issue as before but hmmm
08:34:30FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=sKEcYVwf
08:35:16*beholders_eye joined #nim
08:35:31FromDiscord<Elegantbeef> Think I did that for some type information in my ECS
08:36:50FromDiscord<Phil (he/him)> So basically every invocation for a given type will create a new info global variable with a different pointer, thus essentially randomly generating an int per type?
08:36:52FromDiscord<Elegantbeef> Yea
08:36:53FromDiscord<Elegantbeef> Assuming the type information allows it
08:37:45FromDiscord<Phil (he/him)> why the big Int ?
08:37:51FromDiscord<Elegantbeef> Cause I'm not perfect
08:40:55FromDiscord<Phil (he/him)> sent a code paste, see https://play.nim-lang.org/#pasty=HjjbdIqe
08:41:18FromDiscord<Elegantbeef> Why even do `int` as the distinct when you can just do `pointer`? 😄
08:41:34FromDiscord<Phil (he/him)> Actually, fair
08:41:47FromDiscord<Phil (he/him)> I was just on the trip of wanting an explicit type since it has such a narrowly defined usecase that I wouldn't want to allow any misuse
08:43:00FromDiscord<Phil (he/him)> Huh, turns out for a pointer I'd need to define a hash proc ?
08:43:12FromDiscord<Phil (he/him)> one sec
08:43:12*xet7 quit (Ping timeout: 268 seconds)
08:43:47FromDiscord<Elegantbeef> There is a flag to enable ref/pointer hashes but it's off by default
08:44:06FromDiscord<Phil (he/him)> sent a code paste, see https://play.nim-lang.org/#pasty=WsACMFkN
08:45:23FromDiscord<Phil (he/him)> Hmmm you got a good name ready for this kind of "type-erasing table"?
08:45:44FromDiscord<Phil (he/him)> One sec I'll write the code to make it clearer what I want a name for
08:58:41FromDiscord<firasuke> What's the de facto (prefered) way of using imports? A lot of the modules I am importing share the same name for some procs, and I am starting to prefer "module.proc" vs "proc" alone. Is there a better way to do this?
09:00:26FromDiscord<odexine> the defacto way is to resolve the name conflict, but some people qualify the module name
09:06:14FromDiscord<firasuke> In reply to @odexine "the defacto way is": For example I have a "clean()" proc in two modules "moduleOne" and "moduleTwo". Would it be better to rename "clean()" in every module so that it becomes "cleanModuleOne()" and "cleanModuleTwo()"? Or instead have "moduleOne.clean()"/"moduleTwo.clean()?
09:06:58FromDiscord<odexine> resolve the name conflict not by having the module name in the proc name, but by further clarifying what these functions actually do
09:07:16FromDiscord<odexine> if that cant really be done, then module.proc() is better id say
09:07:34FromDiscord<firasuke> ok thanks
09:08:49FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=FJFlxDbZ
09:08:57FromDiscord<Phil> Better names for "TypeTable" welcome
09:09:25FromDiscord<Phil> I guess ErasureTable would be more apt but still a meh name
09:17:18FromDiscord<Clonkk> Is there a way to propagate a declaration in a `callSoon` state;emt ?
09:18:22FromDiscord<Clonkk> sent a code paste, see https://play.nim-lang.org/#pasty=PyawtvwZ
09:19:02FromDiscord<Clonkk> the value inside the `block blockScope` should be true (which works in a non-async context) even when called with callSoon
09:42:56*xet7 joined #nim
09:44:45*madprops joined #nim
09:45:28madpropswhen sending an argument to nim with quotes like "this thing" .. is it possible to detect it was sent as a string like that? i have an issue with my argument parser where i can't use "-asdf" as the main argument since it thinks it's a flag combo
09:49:25FromDiscord<Phil> Not automatically.↵You can do it manually of course with startsWith and endsWith after trimming that string, but that's about it
09:49:44FromDiscord<Phil> Ah wait, argument parser
09:50:01FromDiscord<Phil> Errrrr yeah no clue, you'll need someone that did more CLI stuff and thus experienced that
09:50:06FromDiscord<nnsee> you can do `--` to indicate the end of flags, if that heps
09:50:08FromDiscord<nnsee> (edit) "heps" => "helps"
09:50:09FromDiscord<Phil> (edit) "experienced that" => "has experience there"
09:50:31FromDiscord<nnsee> so `./myprog -f -d -- -D`
09:50:38FromDiscord<Clonkk> You can try https://github.com/c-blake/cligen/↵(<@709044657232936960_madprops=5b=49=52=43=5d>)
09:50:51*beholders_eye quit (Ping timeout: 255 seconds)
09:50:57FromDiscord<nnsee> in this example, -f and -d are interpreted as flags whereas -D is interpreted as an argument
09:51:21FromDiscord<nnsee> if you're writing an argument parser, you should probably adhere to this "standard", most programs do this
10:13:01FromDiscord<odexine> this isnt a library specific problem just an fyi
10:13:55madpropsyeah ended up checking --
10:15:04*beholders_eye joined #nim
10:19:52*xet7 quit (Remote host closed the connection)
10:29:10FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=AxJROTlI
10:34:01FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=Hdlwrkio
10:35:33FromDiscord<System64 ~ Flandre Scarlet> (edit) "https://play.nim-lang.org/#pasty=VnzAcWoQ" => "https://play.nim-lang.org/#pasty=oPmJumNV"
10:35:54*PMunch joined #nim
10:36:33NimEventerNew thread by basow53698: Error: await expects Future[T], see https://forum.nim-lang.org/t/11579
10:40:44FromDiscord<System64 ~ Flandre Scarlet> @treeform Is it me or the vmath library also has functions from the math stdlib?
11:01:03*PMunch_ joined #nim
11:01:14FromDiscord<Robyn [She/Her]> In reply to @isofruit "Better names for "TypeTable"": `TypePtrMapping`
11:01:53*PMunch quit (Ping timeout: 256 seconds)
11:13:36FromDiscord<Phil> All I need is a functional threadpool
11:13:38FromDiscord<Phil> That's all I need
11:16:16FromDiscord<Phil> Somehow taskpools DSL can't even cope with a proc being called from a field in an object.↵Weave I will be honest I do not understand and literally none of the examples compile.↵Which leaves me with malebolgia and I have the faint feelng it might not let me spawn tasks without blocking the current thread with awaiting them
11:19:13*dtomato quit (Quit: Ping timeout (120 seconds))
11:19:33*dtomato joined #nim
11:25:51FromDiscord<ieltan> @Phil you can try weave-io↵https://github.com/mratsim/weave-io
11:27:40*def- quit (Quit: -)
11:27:52*def- joined #nim
11:28:44FromDiscord<Phil> The "no docs and not published to packages.json" is rough, but at least the example appears to compile
11:29:09FromDiscord<ieltan> Yeah lmao
11:29:22FromDiscord<ieltan> It's basically the Constantine's threadpool
11:29:27FromDiscord<ieltan> But Standalone
11:29:29FromDiscord<nnsee> "tHe CoDe iS SeLf DoCuMeNtInG"
11:32:17FromDiscord<Phil> I'll see whether implementation with that works or if it has similar DSL issues or the like
11:38:31*PMunch joined #nim
11:38:58*PMunch_ quit (Read error: Connection reset by peer)
11:40:21FromDiscord<aberrant.alien> i want to build a simple hello world for a mips router using nim and musl. any guide ?
11:41:35FromDiscord<aberrant.alien> found this https://github.com/kaushalmodi/hello_musl but basically i want to cross compile
11:54:56FromDiscord<Phil> In reply to @ieltan "<@180601887916163073> you can try": It has the exact same DSL error
11:56:40FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=tGNPTTGe
11:57:52FromDiscord<Phil> destroy gets called upon assignment, that's normal.↵It guarantees that whatever was previously in the thing you're assigning to gets cleared
11:58:24*def- quit (Quit: -)
11:58:44FromDiscord<Phil> You can see that via compiling with --expandArc:main in your case.↵Should have a destroy call on var p at the start and the end of proc main()
11:59:19FromDiscord<System64 ~ Flandre Scarlet> In reply to @isofruit "You can see that": Oh alright↵But how to avoid the double free here? (data will be a pointer)
12:00:01FromDiscord<odexine> there's no double free there no?
12:00:05FromDiscord<Phil> You typically don't just free, you change the ref-count and do something if its zero
12:00:51FromDiscord<System64 ~ Flandre Scarlet> the pointer is managed by C
12:01:02FromDiscord<System64 ~ Flandre Scarlet> (edit) "the pointer is managed by ... Clibraru" added "a" | "aC ... " added "libraru"
12:01:04FromDiscord<System64 ~ Flandre Scarlet> (edit) "libraru" => "library"
12:01:45*def- joined #nim
12:01:50FromDiscord<odexine> sent a code paste, see https://play.nim-lang.org/#pasty=PjInTBKP
12:02:33FromDiscord<odexine> i assume
12:02:39FromDiscord<odexine> as mentioned, check expandarc
12:03:30FromDiscord<System64 ~ Flandre Scarlet> Oh alright, thanks↵And will check that
12:04:20FromDiscord<Phil> Actually, I wonder if you can use nim's ref-counting mechanism, but somehow substitute how exactly stuff gets deallocated
12:05:40FromDiscord<System64 ~ Flandre Scarlet> I think it would be pretty complex
12:06:51FromDiscord<Phil> Not necessarily. The act of how you destroy/free something doesn't necessarily have to be coupled with the act of figuring out when you destroy/free something
12:14:05*beholders_eye quit (Ping timeout: 240 seconds)
12:19:31FromDiscord<System64 ~ Flandre Scarlet> In reply to @isofruit "Not necessarily. The act": Oh alright↵But what if the pointer is owned by Tilengine?
12:20:30FromDiscord<Phil> Tilengine must provide a proc that allows you to either track ref-counts so it can decide whether to deallocate sth or provide a deallocation proc
12:21:06FromDiscord<Phil> In GTK for example these procs are g_object_ref and g_object_unref, which are used to update ref-counters internal to GTK which in the end it uses to free a given object if its rc hits 0
12:21:30FromDiscord<System64 ~ Flandre Scarlet> Tilengine doesn't have such a thing
12:22:09FromDiscord<Phil> It must have, otherwise it doesn't own the pointer
12:22:55*PMunch quit (Ping timeout: 256 seconds)
12:23:39FromDiscord<Phil> sent a long message, see https://pasty.ee/KdLMCAIt
12:23:52FromDiscord<Phil> (edit) "https://pasty.ee/xpJuvaEk" => "https://pasty.ee/DGFGGwAf"
12:24:37FromDiscord<Phil> (edit) "https://pasty.ee/QIIuKlrm" => "https://pasty.ee/YIgSArrm"
12:25:01FromDiscord<System64 ~ Flandre Scarlet> In reply to @isofruit "Like, there's 2 ways": I think it's more Case 1
12:25:13FromDiscord<Phil> That should be documented somewhere
12:26:17FromDiscord<Phil> sent a long message, see https://pasty.ee/loGqcnvD
12:26:45FromDiscord<Phil> This kind of memory juggling must be specified in the docs because otherwise people can't use it without blowing their foot off
12:27:02FromDiscord<Phil> It might be standing there in a very, very short form, but it must be there somewhere
12:29:02*PMunch joined #nim
12:32:18FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=QxGMCJxz
12:32:24FromDiscord<Phil> Now how to get there is an absolute mystery to me
12:32:50FromDiscord<Phil> because invoking a proc that stems from a field on an object breaks the threadpool/taskpool DSL
12:50:31*PMunch quit (Ping timeout: 246 seconds)
12:52:21*PMunch joined #nim
12:59:16*xet7 joined #nim
13:02:45NimEventerNew thread by Isofruit: Run a proc stored in an object in another thread with a threadpool, see https://forum.nim-lang.org/t/11580
13:19:20FromDiscord<ieltan> In reply to @isofruit "It has **the exact**": Rip
13:26:50FromDiscord<Phil> I mean, this doesn't make things impossible, but it makes it harder to grasp and the metaphor I'm using for coding less stringent
13:27:01FromDiscord<Phil> Basically it makes the lib worse
13:40:14FromDiscord<Phil> @mratsim ↵I've permutated through the code so much at this point that I've tried everything.↵It is nimcall, or rather, with an explicit nimcall pragma was one of 30 things I tried out.
13:40:26FromDiscord<Phil> I just fucked up in the example code in the forum
13:40:41FromDiscord<Phil> (edit) "@mratsim ↵I've permutated through the code so much at this point that ... I've" added "I think"
13:43:14*def- quit (Quit: -)
13:45:39*def- joined #nim
13:48:29FromDiscord<mratsim> In reply to @isofruit "<@570268431522201601> I've permutated": I can have a look, but my bandwidth is very limited until June.
13:49:21FromDiscord<mratsim> In reply to @isofruit "I just fucked up": is this similar to your need? https://github.com/mratsim/weave/issues/155#issue-640508248
13:49:41FromDiscord<Phil> All I need, and really all, is just some kind of way to have a proc in an object field (I'll take whatever shape, fundamentally I just need a proc with raises: [] and gcsafe) and be able to use that with `spawn` of any of the threadpool libs somehow
13:50:20FromDiscord<Phil> It's just to make the syntax cleaner so people can amass the mailboxes (aka channels) that should be passed into the side-effect free, exception free proc that is the actor before actually running that thing
13:50:38FromDiscord<mratsim> sent a long message, see https://pasty.ee/XuLftAYt
13:51:05FromDiscord<mratsim> well I'll have to test but that's what might be happening.
14:00:29*beholders_eye joined #nim
14:01:17*PMunch quit (Ping timeout: 272 seconds)
14:18:57FromDiscord<classid> Heyo guys
14:19:01*beholders_eye quit (Ping timeout: 272 seconds)
14:19:11FromDiscord<classid> What's the primary usecase of nim?
14:20:54FromDiscord<Robyn [She/Her]> In reply to @classid "What's the primary usecase": It's general purpose tbh
14:21:08FromDiscord<Robyn [She/Her]> Can be used in most places C and C++ can be used
14:24:10strogon14Write software?
14:35:36FromDiscord<Phil> In reply to @mratsim "> Then, when the": I surprisingly enough found a version that works like 50% of the time
14:35:57FromDiscord<Phil> Not with weave but with taskpools (which I assume means it'd also work with weave, the two codebases seem similar enough)
14:37:47FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=IpSNlkTy
14:44:36FromDiscord<mratsim> In reply to @isofruit "Not with weave but": Weave has a fundamental difference, if a thread is working, everything in its queue is stuck in its queue (work-requesting / cooperation). So long running task (say sleep()) will block. While taskpools and weave-io are work-stealing and a blocked thread will not block everyone
14:45:28FromDiscord<Phil> In reply to @mratsim "Weave has a fundamental": Hmm, in that case taskpools/weave-io seem like the projects more geared towards what I want
14:45:43FromDiscord<Phil> Fundamentally I just want to express in the roughest of terms "execute this shit everywhere but here, you can phone home if you need to"
14:46:13FromDiscord<Phil> Because the main thread is holy promised land that must never be blocked for long
14:46:58FromDiscord<Phil> (edit) "long" => "long, and thus all bigger computations get exiled"
14:47:09FromDiscord<mratsim> In reply to @isofruit "Because the main thread": that was the idea behind the background service experiment: https://github.com/mratsim/weave?tab=readme-ov-file#foreign-thread--background-service-experimental
14:47:49FromDiscord<Phil> In reply to @mratsim "that was the idea": I will be honest I didn't get that far because the examples don't compile 😄
14:48:01FromDiscord<mratsim> but the perf on latency is meh (as expected)
14:48:44FromDiscord<Phil> In reply to @mratsim "but the perf on": With my approach I've gone with "Screw performance and everything, this is for GUI land, if Webdev can live with 100+ms of latency then I can live with 10 if need be"
14:49:06FromDiscord<Phil> Because I can only be so patient while dealing with data-races before I want to tear my hair out
14:49:18FromDiscord<Phil> And thus I just deep-copy messages to send to another thread and stay sane
14:49:28FromDiscord<Phil> If Dart with its isolates can get away with that, then so can I
14:49:56FromDiscord<mratsim> sent a long message, see https://pasty.ee/AkISWrqJ
14:50:06FromDiscord<mratsim> A is waiting forever ....
14:50:28FromDiscord<mratsim> for IO you want to use FIFO to optimize for fairness and latency.
14:50:46FromDiscord<mratsim> the tradeoff is that you have more data movement and data is cold in cache.
14:50:56FromDiscord<Phil> Ah, check, that's the level of considerations that I don't think would matter thaaaaaaaat much in GUI land. At least I haven't seen that intense level of communication between threads that it would be notable
14:51:21FromDiscord<Phil> At least in the sense that you throw messages around that spawn that many tasks that you care about the latency in a notable manner
14:51:27FromDiscord<mratsim> well if compute is not running on UI thread it doesn't matter
14:51:35FromDiscord<Phil> Check
14:52:12FromDiscord<Phil> My abstraction may be taking shortcuts but I don't want the most performant abstraction, just one that is primarily as simple to use and understand as possible
14:52:13*beholders_eye joined #nim
14:52:40FromDiscord<Phil> Man, reading the Dart docs really gave me confidence with just taking shortcuts in concurrency
14:52:54FromDiscord<Phil> (edit) "concurrency" => "concurrency, even if it's at a hit in performance"
14:53:57FromDiscord<Phil> Sidenote, "capturing" a proc in another proc and not having it be a closure might be tricky, but not impossible in nim
14:54:00FromDiscord<Phil> templates to the rescue
14:55:33*lucasta joined #nim
15:04:49FromDiscord<Phil> ... wait a sec
15:04:57FromDiscord<Phil> Why is ma asan stacktrace such utter garbage?
15:05:02FromDiscord<Phil> (edit) "ma" => "my"
15:06:26FromDiscord<Phil> sent a long message, see https://pasty.ee/DktwTmOF
15:08:14FromDiscord<Phil> Okay, still confused as to why the stacktraces are garbage but turns out the leak was just (again) nim's ORC cycle collector that hadn't been destroyed due to an exception
15:14:06FromDiscord<threefour> Is the correct approach to threading in Nim to avoid ARC and ORC entirely?
15:14:24FromDiscord<threefour> At least for the time being
15:14:43FromDiscord<threefour> (edit) "correct" => "best"
15:14:59FromDiscord<Phil> Honestly there is not much of a best approach because there's pitfalls everywhere
15:15:13FromDiscord<Phil> At least imo
15:15:34FromDiscord<threefour> Right, and I'll deal with those when they arise. But does ORC have the most pitfalls?
15:16:53FromDiscord<Phil> sent a long message, see https://pasty.ee/gGOCgXzt
15:17:34FromDiscord<Phil> I think the easiest form of multithreading really is just system.Channels (which deep-copy messages for you) combined with manually handling threads or using a threadpool
15:18:38FromDiscord<Phil> I guess if you look at it from that angle, refc with system.Channels is the current sweet spot kinda?↵I haven't tried it out yet but I assume that should have the least issues
15:18:59FromDiscord<Phil> It's not the fastest but it should be the most correct I think
15:23:54FromDiscord<System64 ~ Flandre Scarlet> In reply to @threefour "Is the best approach": wait, ARC and ORC have problems?
15:24:21FromDiscord<Phil> In reply to @sys64 "wait, ARC and ORC": See the memory leak above? That's ORC
15:24:29FromDiscord<polylokh_39446> sent a long message, see https://pasty.ee/PkFAGzTB
15:25:00FromDiscord<Phil> Only occurs with threading because the cycle collector does not get cleared out when the thread ends, you need to do that manually.
15:26:00FromDiscord<Phil> Another problem that ARC/ORC have is the only half-working attempt at moving memory.↵Moving memory from Thread A to Thread B is way too difficult to get right and with the flexibility you want.
15:26:27FromDiscord<Phil> Mind you that does not work AT ALL with refc, but arc/orc were the first starting points of getting that to work
15:27:50FromDiscord<threefour> In reply to @isofruit "I guess if you": Yeah I'm gonna be using channels + manual threads. Figured it'd have the least problems. Was gonna use `std/threadpools` but apparently it's deprecated, and refers you to two packages which gave me loads of problems when I tried to use them on 2.0.4.
15:28:16FromDiscord<System64 ~ Flandre Scarlet> In reply to @isofruit "See the memory leak": And does ARC have this issue?
15:28:19FromDiscord<Phil> In reply to @threefour "Yeah I'm gonna be": I've got something working that does pretty well by now
15:28:34FromDiscord<Phil> You can check out the forum post and see if it speaks to you:↵https://forum.nim-lang.org/t/11580
15:29:16FromDiscord<Phil> That should be easier than manually handling threads and if you are in a GUI loop situation where you can just assume your other threads will finish eventually while your main thread still runs, then you can get away with it without problems
15:29:32FromDiscord<Phil> In reply to @sys64 "And does ARC have": That specific memory leak issue: no
15:29:57FromDiscord<polylokh_39446> In reply to @isofruit "Mind you that does": more than "does not work", it was contrary to opinionated design. Nim had a solution to concurrency and it included "don't share memory between threads"
15:30:02FromDiscord<Phil> ARC just shares the problem that moving memory from Thread A to Thread B is essentially a gigantic footgun, which is why you don't want to do that yourself and let somebody else do it for you
15:30:53FromDiscord<Phil> In reply to @polylokh_39446 "more than "does not": Fair, my wording was bad here. I was more intending to express "Was not possible with the implementation at the time" agnostic of the requirement, but the wording I chose was more negative than deserved, I apologize
15:31:37FromDiscord<Phil> (edit) "you" => "you. Or just don't do it and either deepcopy messages or use system.Channel"
15:33:28FromDiscord<polylokh_39446> I'm not complaining about the negativity. What I mean is that sharing memory wasn't a feature with defects in pre-arc Nim, but that it was contrary to the intended use of Nim. Just like it would be today to introduce a lot of inefficiencies because of some ideas (contrary to a focus on "hard real-time embedded") like "dev time is more important than computer time" and "computers are fast enough" and "if you want it to be fast you s
15:34:49FromDiscord<polylokh_39446> mainly I'm thinking about this stuff from the earlier question on Nim's primary usecase is. This stuff informs a more useful answer to that question.
15:38:52FromDiscord<polylokh_39446> of course, right now, sharing memory between threads is both defective and intended. But at least, because it's intended, it may get fixed.
15:41:14FromDiscord<System64 ~ Flandre Scarlet> In reply to @isofruit "ARC just shares the": Seems multithreading is quite messy
15:42:29FromDiscord<Phil> In reply to @sys64 "Seems multithreading is quite": Multithreading is difficult. The only implementation of "simple" multithreading I've seen are those that come with a major performance deteriment that is unbecoming if you want to compete with Rust/C.↵↵The thing for me is that I am fine with that performance degradation for my usecase, there just isn't a lib for folks like me that prefer easy usage over performance 😄
15:42:48FromDiscord<Phil> If you're mratsim and really know what you're doing the current model is more workable
15:43:01FromDiscord<Phil> (edit) "If you're ... mratsim" added "someone more experienced like"
15:43:43FromDiscord<Phil> Or rather: If you're an end-user your life is infinitely easier than one of a lib-author like myself, since I tend to want to keep usage scenarios as flexible as possible and that very quickly stumbles into syntax limitations that I'm doing my level best to plaster over
15:45:12FromDiscord<polylokh_39446> <https://web.archive.org/web/20201105145251/https://nim-lang.org/docs/manual.html>↵>Nim's memory model for threads is quite different than that of other common programming languages (C, Pascal, Java): Each thread has its own (garbage collected) heap and sharing of memory is restricted to global variables. This helps to prevent race conditions. GC efficiency is improved quite a lot, because the GC never has to stop other threads a
15:45:41FromDiscord<Phil> In reply to @polylokh_39446 "<https://web.archive.org/web/20201105145251/https:/": Yeh, this has many benefits in terms of correctness
15:46:06FromDiscord<Phil> Just also means message passing of massive objects becomes a non-starter
15:46:51FromDiscord<michaelb.eth> just curious (and googl'ing for myself now), what way/s of doing multithreading are common/blessed in Zig?
15:47:31FromDiscord<polylokh_39446> Zig's not in a pleasant state AIUI as it introduced async/await and then removed it with the nexxt version, and now still hasn't re-added it.
15:47:45FromDiscord<michaelb.eth> not that Zig and Nim are apples-to-apples, but wondering how people approach it in another lang with similar goals
15:47:46FromDiscord<Phil> No clue, didn't research Zig. My known ones are Webworkers (JS), Isolates (Dart), Virtual Threads (java) and.... that's sorta it
15:48:30FromDiscord<polylokh_39446> (edit) "nexxt" => "next"
15:49:44*disso_pch joined #nim
15:50:03FromDiscord<michaelb.eth> Node.js has worker threads now, right? i.e. not just "no shared" workers↵↵that was added after I had moved away from it, wondering too what tradeoffs they've chosen
15:50:04FromDiscord<polylokh_39446> Erlang and Ada(!) have very pleasant concurrency features. I hate this async/await stuff.
15:50:57FromDiscord<Phil> From what I understand the only reason it's so pleasant in Erlang though is because it's entirely centered around message passing, no?
15:51:05FromDiscord<odexine> pretty much sure yes
15:51:31*def- quit (Quit: -)
15:51:33FromDiscord<odexine> its mainly banking on message passing and fp strengths
15:51:49FromDiscord<odexine> i heard erlang so i had to join in
15:52:24*disso-peach quit (Ping timeout: 268 seconds)
15:52:24FromDiscord<Phil> Naturally
15:52:54FromDiscord<odexine> obviously when someone mentions erlang in a server i'm active in, my brain gets a notification
15:53:38FromDiscord<System64 ~ Flandre Scarlet> In reply to @isofruit "Multithreading is difficult. The": Rust gives me headaches
15:53:53*def- joined #nim
15:54:18FromDiscord<threefour> In reply to @isofruit "That should be easier": I'm building an HTTP framework
15:55:09FromDiscord<polylokh_39446> sent a long message, see https://pasty.ee/vadtToNa
15:55:21FromDiscord<Phil> In reply to @threefour "I'm building an HTTP": In that case you'll want to definitely take a look at weave and friends and get some kind of threadpool solution working
15:55:41FromDiscord<polylokh_39446> also, message-passing with C11 threads would really mean message-passing only. Erlang can cheat a bit.
15:55:45FromDiscord<odexine> oh yeah the focus on observability is insane
15:56:30FromDiscord<polylokh_39446> but of course Erlang wouldn't work for hard real-time embedded platforms. The inefficiency of stuff like it's string handling is the first thing people notice about it.
15:57:07FromDiscord<odexine> erlang or the BEAM wasnt really made for that application
15:58:56FromDiscord<threefour> In reply to @isofruit "In that case you'll": Weave is pissed me off with how dysfunctional it was when I tried it. I think my current approach will work fine. I've got multiple worker threads, each of which handle requests asynchronously, and a main thread which delegates the requests to the worker threads via channels.
15:59:01FromDiscord<threefour> (edit) removed "is"
15:59:07FromDiscord<polylokh_39446> well there's <https://github.com/atomvm/AtomVM/> that can do a 'hello world' more than 2000x faster than an escript, but the farther you get away from BEAM the farther you get away from the advantages I was just talking about, no?
15:59:55FromDiscord<Phil> In reply to @threefour "Weave pissed me off": Why not just a queue that the main thread fills and the worker threads chunk through it if they can find something?↵If need be put the worker threads to sleep if the queue is empty and let putting in a message into the queue trigger wake-up signals in the threads
15:59:57FromDiscord<odexine> Atom aint got the history and the use which is where most of the advantages of the beam lies no
16:00:11FromDiscord<odexine> rather, that's how the beam got to its state id say
16:00:49FromDiscord<Phil> In reply to @polylokh_39446 "well there's <https://github.com/atomvm/AtomVM/> th": By escript you mean ecma-script? or a shell command?
16:01:07FromDiscord<odexine> no
16:01:11FromDiscord<odexine> erlang's script thingy or w/e
16:01:14FromDiscord<polylokh_39446> In reply to @isofruit "By escript you mean": more like an executable .jar file for Erlang, in its most common use
16:01:16FromDiscord<odexine> i assume erlang bytecode
16:01:32Amun-Rabeam
16:01:42FromDiscord<odexine> pedantry ok
16:01:43FromDiscord<odexine> smh
16:01:48Amun-Ra;)
16:02:20FromDiscord<threefour> Because then the queue has to be shared, and sharing is apparently spooky stuff in Nim right now. So I tried to keep things as separate as possible. The only thing that gets "shared" is the request, which is deep copied through a channel anyways.
16:03:58FromDiscord<Phil> In reply to @threefour "Because then the queue": Put the queue behind a pointer, share the pointer and manually de-allocate the queue at the end of the program.↵It's what I do with my Table of channels 😄
16:04:36FromDiscord<Phil> To create an unmanaged pointer, use `createShared` and to destroy one use `freeShared`
16:04:58FromDiscord<Phil> Make sure the queue is locked so that only one thread at a time can access it
16:05:15FromDiscord<Phil> Actually, nevermind, juse use a channel instead of rolling your own queu
16:05:17FromDiscord<Phil> (edit) "queu" => "queue"
16:05:29FromDiscord<Phil> And have all threads read from the same channel while only the main thread pushes messages into it
16:05:31FromDiscord<polylokh_39446> if you're making an http server, a common feature is a way to see what it's currently doing, for administration and troubleshooting, and for that you could put all requests in some global state and message-pass keys into it.
16:06:36FromDiscord<threefour> I guess that's something I didn't know: multiple threads can read from the same channel, without several receiving the same message?
16:07:59FromDiscord<Phil> Aye, channels are thread-safe and thus only one thread will receive a given message even if 10 are waiting for one.
16:08:33FromDiscord<threefour> Sweet. I'll roll with that then. Less channels open the better.
16:08:47FromDiscord<Phil> The problem is more that the main-channel still has a ref of the HTTP request while the "worker"-thread also has one and both will eventually free it, leading to potential problems, but you circumvent that entire problemdomain by just deep-copying
16:09:36FromDiscord<threefour> Makes sense
16:09:49FromDiscord<threefour> Which channels do automatically
16:10:02FromDiscord<Phil> In reply to @threefour "Sweet. I'll roll with": system.Channels do that.↵Threading channels do not.
16:10:13FromDiscord<Phil> Threading is a separate package/lib
16:10:32FromDiscord<threefour> Oh, I was talking about system.Channels. Should I not be using those?
16:10:35FromDiscord<Phil> If your stuff is called `Channel`, you're using system.Channel.↵If it's `Chan` you're using threading Chan
16:10:50FromDiscord<Phil> In reply to @threefour "Oh, I was talking": Those are fine, they're just originally designed for usage with refc, thus they do deep-copying
16:11:20FromDiscord<threefour> Ah. The deep copying seemed good to me, so I rolled with it.
16:11:43FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=munqHnWG
16:12:08FromDiscord<Phil> (edit) "https://play.nim-lang.org/#pasty=RVlpGRtp" => "https://play.nim-lang.org/#pasty=FVTBxBUH"
16:12:34FromDiscord<Phil> The above is what I currently do in my thread abstraction lib I'm playing around with
16:13:22*disso_pch quit (Remote host closed the connection)
16:13:45*disso_pch joined #nim
16:29:49FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=JGIbpFMg
16:31:09FromDiscord<Phil> Oh god damn whitespaces
16:32:14FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=MHbyIcIF
16:36:11*ntat joined #nim
16:37:51FromDiscord<polylokh_39446> 'course there's no difference between `echo(1); echo (1)`
16:49:59*coldfeet quit (Remote host closed the connection)
16:57:10FromDiscord<mratsim> In reply to @isofruit "Multithreading is difficult. The": I have yet to see C or Rust multithreading compete for with Weave or Constantine for compute.↵↵For IO, I do agree but that's mostly a time invested issue, not a ARC or ORC issue.↵And if someone is willing, I can mentor them to make weave-io a competitive IO threadpool. Probably need 3~4 weekends.
16:58:00FromDiscord<Phil> In reply to @mratsim "I have yet to": Chances are I'll eventually be up for that. For now I'll be working on completing this actor thingy built on top of taskpools which should be easy enough
16:58:43FromDiscord<mratsim> In reply to @isofruit "Chances are I'll eventually": weave-io is taskpools refactored for perf. You can check the diff, it's the same structure.
16:59:08FromDiscord<mratsim> In reply to @threefour "Weave pissed me off": What happened?
16:59:33FromDiscord<Phil> Ah, based on your forum response I wasn't sure if you were of the opinion folks should already try it (given no docs and not published to packages.json 😄 )
16:59:53FromDiscord<Phil> In reply to @mratsim "What happened?": I would assume they ran as I did into "Let's try out those examples" and got compiler errors
17:00:14FromDiscord<mratsim> In reply to @isofruit "Ah, based on your": they can try it, it will work. But it's just a better taskpools, which is still a compute threadpool.
17:00:47FromDiscord<mratsim> In reply to @isofruit "I would assume they": Ah possibly, I didn't recheck for Nim 2.x
17:01:12FromDiscord<Phil> Opened an issue about that for you with an example and related error messages
17:01:17FromDiscord<Phil> However I also encountered those on 1.6.20
17:01:35FromDiscord<mratsim> but normally the test suite should catch it. There is an examples folder and those are tested
17:01:43FromDiscord<mratsim> I wrote Weave during 1.4
17:01:53FromDiscord<mratsim> 2020 or maybe 2019
17:02:05FromDiscord<odexine> 1.4 is about 2021 i believe
17:02:11FromDiscord<odexine> 1.0 is 2020 iirc
17:02:30FromDiscord<mratsim> yeah but when i wrote weave I was using devel until 1.4 was released iirc
17:02:39FromDiscord<Phil> In reply to @mratsim "but normally the test": Maybe you adjusted the tests but not the examples? The 1.6.20 compiler error looks like the kind of thing you fix in 1-2 seconds and forget to update elsewhere
17:02:58FromDiscord<Phil> Like, that looks like a pragma annotation / gcsafe casting is missing somewhere
17:03:23FromDiscord<Phil> (edit) "examples?" => "examples in the readme?"
17:04:07FromDiscord<Phil> And I will be honest I can't see an example folder within weave
17:04:17FromDiscord<Phil> I see a raytracing demo, but that looks far more complicated than a simple minimal example
17:05:23FromDiscord<mratsim> In reply to @isofruit "And I will be": Ah right, was thinking of something else.↵↵There are simple examples here: https://github.com/mratsim/weave/blob/master/weave/parallel_tasks.nim#L236-L399
17:06:13FromDiscord<Phil> In reply to @mratsim "Ah right, was thinking": Ohhhh
17:06:19FromDiscord<Phil> Yeah I would not have looked there, as in, ever
17:07:55FromDiscord<Phil> Huh, same compiler error
17:08:09FromDiscord<Phil> Yeah no clue
17:12:48FromDiscord<threefour> Ah, I didn't know you were the Weave guy. Yeah I couldn't get the examples working, and figured that if not even the examples weren't functional, I shouldn't bother with any actual use cases because it might be wasted effort until it was updated.
17:13:58FromDiscord<Phil> Looks like a case of nim occasional instability just biting you.
17:14:08FromDiscord<threefour> "Pissed me off" was hyperbolic, but it was unfortunate to learn that parallelism in Nim as a whole (stdlib _and_ community) is in a non-robust, and quite confusing state.
17:14:25FromDiscord<Phil> And by instability I do mean the lang itself.
17:18:00FromDiscord<threefour> The general lack of consensus and "foundation" as to parallelism makes Nim feel two decades out of date. I know it's _possible_, but even with everything else that Nim does right that makes it feel modern and advanced, this is a massive gaping hole.
17:19:17FromDiscord<threefour> And I know that's one of the biggest focuses right now, so my complaint is pointless. Still love Nim though. My favorite language now for sure.
17:21:15FromDiscord<fosster> what was the thing that you put inside {.raises.} to push all raised exceptions inside the proc?
17:21:51FromDiscord<fosster> like I remember there was some directive like push that automatically pushed errors on raises pragma, but can't remember its name
17:22:42FromDiscord<Phil> `raises: []`
17:22:54FromDiscord<Phil> raises defines the list of allowed exceptions that this proc may throw
17:23:15FromDiscord<Phil> if that list is empty, this proc may not throw any exception and you must try catch
17:23:22FromDiscord<Phil> At times that may mean try-catching BareException
17:23:32FromDiscord<Phil> (edit) "BareException" => "the bare Exception type"
17:24:24FromDiscord<polylokh_39446> that's a great feature, but what fosster is asking for is something like `raises: [whatever_I_raise_lmao]`
17:24:29FromDiscord<Phil> And you can push that similar to how this works in owlkettle `{.push importc, cdecl.}`
17:24:32FromDiscord<polylokh_39446> but in that case, why not just remove it?
17:25:22FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=fGvlkqHI
17:25:29FromDiscord<fosster> yes I know, but like if my proc actually raises errors, and I don't want to manually type them all out, is there some directive such as the compiler automatically detects uncatched erros and reports it
17:25:35FromDiscord<polylokh_39446> you don't need to have `{.raises.}` everywhere to make checked exceptions work or something. They're tracked regardless of the raise, and the raise is a point of enforcement on what's raised through it
17:25:46FromDiscord<fosster> yeah kind of↵(@polylokh_39446)
17:25:49FromDiscord<Phil> I can't say I'm familiar with anything in that regard
17:27:33FromDiscord<fosster> like if I want to make clear to the compiler which exceptions might be raised in my proc
17:28:06FromDiscord<polylokh_39446> the compiler tracks it already, you don't need to make it clear
17:28:15FromDiscord<fosster> now that I'm thinking about it, it wouldn't make much sense
17:28:37FromDiscord<fosster> because the compiler doesn't enforce you to catch all errors a proc may raise
17:29:39FromDiscord<fosster> I see, it's more like a tool for the progammer to be sure to handle all exceptions, when initialized to `{.raises: [].}`
17:30:04FromDiscord<fosster> I see, it's more like a helper for the progammer to be sure to handle all exceptions, when initialized to `{.raises: [].}`
17:30:30FromDiscord<polylokh_39446> what it does is assert, at compile-time, that no other exceptions than those listed can raise from the function
17:30:50FromDiscord<polylokh_39446> so the "can raise whatever, I don't want to list them" annotation is the default
17:31:28FromDiscord<fosster> alright, all clear thanks!
17:32:52FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=IMbtbkYQ
17:34:58FromDiscord<polylokh_39446> sent a code paste, see https://play.nim-lang.org/#pasty=OzusGODc
17:35:31*coldfeet joined #nim
17:39:29FromDiscord<Phil> Hmmm I just realized that my "type-erasure-table" that is a pretty neat abstraction has one fatal flaw
17:39:40FromDiscord<Phil> I can't iterate over it
17:39:49FromDiscord<Phil> Well, not fatal, but inconvenient
17:41:43FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=XVsJIIgE
17:41:54FromDiscord<Phil> (edit) "https://play.nim-lang.org/#pasty=eEMBLwFj" => "https://play.nim-lang.org/#pasty=cJPpwtRU"
17:42:23FromDiscord<Phil> I think the key problem I have here is that I need the type to be able to figure out what to type-cast, and I can't store the type itself
17:45:26FromDiscord<fosster> I didn't mean that, but thanks anyway for the concern!↵(@polylokh_39446)
18:00:18FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=puCBPZXk
18:18:11*krux02 joined #nim
18:31:05FromDiscord<ieltan> @System64 ~ Flandre Scarlet you can't override the destructor for a ref type
18:32:30FromDiscord<ieltan> You need to do it on a simple `object` (would be `ContextImpl`, override it's destructor and then use an alias like `type Context = ref ContextImpl`
18:32:54FromDiscord<ieltan> Hm
18:34:17FromDiscord<ieltan> sent a code paste, see https://play.nim-lang.org/#pasty=iuyhgNtM
18:35:08FromDiscord<System64 ~ Flandre Scarlet> In reply to @ieltan "Unless you do something": Not very clean
18:37:50FromDiscord<ieltan> In reply to @sys64 "Not very clean": Unfortunate I know
18:38:43FromDiscord<ieltan> I'm not aware of another solution tho
18:39:26FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=RWPcovWG
18:39:52FromDiscord<Phil> This blows up with:↵Error: attempting to call routine: 'nnkTupleConstr'↵ found 'nnkTupleConstr' [enumField declared in /home/isofruit/.choosenim/toolchains/nim-2.0.4/lib/core/macros.nim(94, 5)]
18:43:21FromDiscord<Phil> I can't even call nnkIntLit, wth
18:45:33FromDiscord<polylokh_39446> that's a NimNodeKind, an enum and not a function
18:46:03FromDiscord<polylokh_39446> `newNimNode(nnkTupleConstr)`
18:47:47FromDiscord<Phil> The heck are the docs doing then
18:47:58FromDiscord<Phil> Oh they're printing the ast, not how to create it
18:48:01FromDiscord<Phil> uuuuuuuugh
18:48:13FromDiscord<Phil> That's why dumpAstGen is the better choice always for everything
18:55:07*xet7 quit (Remote host closed the connection)
18:55:14*coldfeet quit (Remote host closed the connection)
19:05:43FromDiscord<Elegantbeef> No, just no↵(@Phil)
19:26:02NimEventerNew thread by Hobbyman: Any suggestions on how to use nimsuggest?, see https://forum.nim-lang.org/t/11581
19:33:20*ntat quit (Quit: Leaving)
19:51:19FromDiscord<Phil> Okay, this second approach is getting away with much less macro-code seemingly, seems like the better strategy
20:02:52*def- quit (Quit: -)
20:04:16*def- joined #nim
20:07:26*lucasta quit (Quit: Leaving)
20:33:08*beholders_eye quit (Ping timeout: 260 seconds)
20:38:06FromDiscord<Phil> Awwww, I can't do forward declarations that get caught by a generic
20:38:36FromDiscord<Elegantbeef> Use mixin
20:38:45FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=mdmouhXH
20:38:59FromDiscord<Elegantbeef> What's the point
20:40:53FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#pasty=tYFjLUFF
20:41:41FromDiscord<Elegantbeef> Why do you need the forward declare?
20:41:41FromDiscord<Phil> the forward declarations were an attempt at providing more freedom to the user.↵As it stand they must implement the `process` procs before the call to `initServerActor`.↵Would've been neat to squash that limitation for more freedom in structure
20:43:23FromDiscord<Elegantbeef> I mean it's just like a normal generic proc no?
20:43:42FromDiscord<Phil> What is? The `process[T]`?
20:44:10FromDiscord<Elegantbeef> No having to implement procs before `initServerActor`
20:45:17FromDiscord<Phil> Ah that, yeah kinda I guess, it's just not totally obvious that `initServerActor` requires you to have `process` implemented
20:45:29FromDiscord<Phil> Which is why I would have found it neat if I could have removed that requirement
20:46:01FromDiscord<Phil> Not a dealbreaker and puts it in line with e.g. jsony, just would've been neat 😄
21:14:44NimEventerNew thread by Nello41: Polymorphism in Nim, see https://forum.nim-lang.org/t/11582
21:15:33*jmdaemon joined #nim
21:18:48*KhazAkar joined #nim
21:26:59*jmdaemon quit (Ping timeout: 264 seconds)
21:27:54*krux02 quit (Remote host closed the connection)
22:09:02FromDiscord<Robyn [She/Her]> Does `when compiles: myFunction()` run the underlying function or no?
22:13:09FromDiscord<Elegantbeef> Nope
22:13:20FromDiscord<Robyn [She/Her]> Thanks :)
22:14:50FromDiscord<Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=iNQCWMvH
22:14:58FromDiscord<Robyn [She/Her]> I'd assume so but double checking
22:15:29FromDiscord<Elegantbeef> sure
22:15:52FromDiscord<Robyn [She/Her]> Sweet
22:16:26*jmdaemon joined #nim
22:22:47*jmdaemon quit (Ping timeout: 264 seconds)
22:33:22FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=jhplbNca
22:33:51FromDiscord<Elegantbeef> Use `=dup` or `=copy` to call the underlying `copy`
22:34:33*beholders_eye joined #nim
22:34:53FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "Use `=dup` or `=copy`": But is there another solution without requiring to copy?
22:35:21FromDiscord<Elegantbeef> making `=dup` and `=copy` error
22:36:18FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "making `=dup` and `=copy`": Why making thoses throwing an error?
22:36:59FromDiscord<Elegantbeef> To prevent dangling pointers?
22:39:16FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=BXMLkbhM
22:43:35FromDiscord<System64 ~ Flandre Scarlet> So yeah, seems I run into an issue
22:44:20FromDiscord<Elegantbeef> turn that into `sink TileMap` then you solved the issue
22:44:36FromDiscord<Elegantbeef> Use move semantics instead of loose programmer contracts
22:44:49FromDiscord<Elegantbeef> If something takes ownership use `=sink` if you need it and make it a `sink` parameter
22:44:59FromDiscord<Elegantbeef> If something needs to call code on a copy use `=copy` or `=dup`
22:45:12FromDiscord<Elegantbeef> If something should not be copied and only ever moved make those hooks error
22:45:27FromDiscord<System64 ~ Flandre Scarlet> 🤯
22:46:50FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=duEYvAUq
22:47:18FromDiscord<Elegantbeef> Also why are you taking ownership of a parameter's address
22:47:28FromDiscord<Elegantbeef> That has no lifetime assurances
22:49:42FromDiscord<Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=HqyWDkfj
22:51:01FromDiscord<Elegantbeef> `import std/strformat`
22:51:04FromDiscord<Elegantbeef> Rocket science I know
22:51:07FromDiscord<Robyn [She/Her]> `{.error: "`" & $T & "` doesn't implement `processEnum`.".}` works but its painful
22:51:17FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "Also why are you": The user shouldn't use the same address for multiple objects↵Also some things can depend of other things
22:51:27FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "Rocket science I know": Alright Einstein, why is it showing that error despite that being at the top of my file?
22:51:36FromDiscord<Elegantbeef> Sure but the address is a stack value that has no lifetime garuentee
22:51:42FromDiscord<Elegantbeef> `mixin &`
22:52:05FromDiscord<Elegantbeef> Hey robyn you give 0 context you get shitty answers
22:52:12FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "Sure but the address": The address points to heap
22:52:17FromDiscord<Elegantbeef> no
22:52:25FromDiscord<Elegantbeef> `tmp.addr` points to wherever `tmp` is
22:52:41FromDiscord<Elegantbeef> In this case it's a parameter so that can be on the stack or the heap
22:52:54FromDiscord<Elegantbeef> you want `cast[pointer](tmp)` if it's a `ref` or `ptr`
22:53:02FromDiscord<Robyn [She/Her]> Let me put it on the playground lol
22:53:35FromDiscord<System64 ~ Flandre Scarlet> wouldn't copy as needed be simpler?
22:53:43FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=fgTlAAhc
22:53:52FromDiscord<Elegantbeef> I mean regardless what you're doing is wrong
22:54:11FromDiscord<Elegantbeef> What is `TileMap`'s type definition?
22:54:20*lucasta joined #nim
22:56:12FromDiscord<Robyn [She/Her]> This is... Weird
22:56:16FromDiscord<Robyn [She/Her]> Playground runs it fine
23:00:01FromDiscord<Robyn [She/Her]> Maybe it was just `inim` being weird then? Makes no sense tho
23:01:39FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=ogrnmzth
23:05:40FromDiscord<System64 ~ Flandre Scarlet> it's probably filled with bad practices
23:06:14FromDiscord<Elegantbeef> Right
23:06:48FromDiscord<Elegantbeef> So you should just pass `TileMap`
23:07:01FromDiscord<Elegantbeef> `TLN_TAKE_OWNERSHIP` is an awful name
23:07:07FromDiscord<Elegantbeef> and it should take `var TileMap`
23:07:10FromDiscord<Elegantbeef> Not `ptr TileMap`
23:07:21FromDiscord<System64 ~ Flandre Scarlet> what if the user use let?
23:07:31FromDiscord<Elegantbeef> They wanted it to be immutable?
23:07:39FromDiscord<Elegantbeef> So it should not be mutated for no reason
23:09:04FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "So you should just": Would it solve the dangling pointer problem or memory leaks,
23:09:07FromDiscord<System64 ~ Flandre Scarlet> (edit) "leaks," => "leaks?"
23:09:38FromDiscord<Elegantbeef> Well you would no longer be using `addr` so you could not get dangling pointers
23:09:41FromDiscord<Elegantbeef> The entire benefit of `var` over `ptr` is that it's memory safe
23:10:28FromDiscord<Elegantbeef> The issue with your code is you're writing C in a trenchcoat which has gotten you to these problems
23:10:46FromDiscord<System64 ~ Flandre Scarlet> Well, I try to use a C library
23:11:07FromDiscord<Elegantbeef> Your destroy makes no sense
23:11:14FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=dSKonUml
23:11:32FromDiscord<Elegantbeef> Why this instead of `tmap.data = nil` also destroy is not supposed to nil data it's just supposed to destroy it now
23:11:52FromDiscord<Elegantbeef> You can use C libraries without writing C in a trenchcoat
23:12:00FromDiscord<System64 ~ Flandre Scarlet> trying to avoid dangling pointer
23:12:03FromDiscord<Elegantbeef> You just need to know what you're doing and learn to write Idiomatic Nim
23:12:10FromDiscord<Elegantbeef> There is no dangling pointer there
23:12:20FromDiscord<Elegantbeef> `=wasMoved` zeros data
23:12:25FromDiscord<Elegantbeef> `=destroy` destroys data
23:14:34FromDiscord<System64 ~ Flandre Scarlet> Oh alright
23:19:09FromDiscord<System64 ~ Flandre Scarlet> And wouldn't copy the thing when I pass it to Tilengine be simpler?
23:20:33FromDiscord<Elegantbeef> If you want to do that, sure but you're just walking around a problem from what I can tell
23:20:40FromDiscord<Elegantbeef> I could be wrong but I don't even know what you're doing
23:29:25FromDiscord<System64 ~ Flandre Scarlet> Or I can just use more manual memory management and be careful
23:30:48FromDiscord<Elegantbeef> You could, but then you're just writing C in a trenchcoat
23:30:54FromDiscord<Elegantbeef> There is no reason to do that really
23:33:04FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "You could, but then": https://github.com/system64MC/nim-tilengine/blob/master/src/tilengine.nim↵This is the binding I use (forked from Exelotl)
23:37:14FromDiscord<Elegantbeef> Respectfully, yes and?
23:38:25FromDiscord<Elegantbeef> Just because you depend on a C library does not mean your Nim code needs to do as unsafe or silly of things
23:39:30FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "You could, but then": Might as well do `--mm:none` for good measure! (Joke)
23:39:47FromDiscord<System64 ~ Flandre Scarlet> So how can I prevent dangling pointers beside of making a full copy of the object?
23:40:16FromDiscord<Elegantbeef> By writing safe Nim and not using `ptr T`
23:41:21FromDiscord<Elegantbeef> Nim does not have any method of having dangling pointers without unsafe mechanisms
23:42:15FromDiscord<ieltan> In reply to @sys64 "So how can I": By not worrying about it (unless you interact with C libraries or use unsafe features)
23:42:29FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "By writing safe Nim": At some point I have to use pointers for the C library↵And the C library requires you to manually manage the memory, there is no ref counting or stuff like this
23:43:13FromDiscord<Elegantbeef> So either use `ref object` `ref int` or use hooks so it's a single ownership model
23:44:30FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "So either use `ref": and would it cause problems when I send that to the C library? Will the ref counter keep track of this?
23:44:52FromDiscord<Elegantbeef> Why would it matter the C library does not extend the life time further than you
23:45:23FromDiscord<Elegantbeef> If you have a reference still the data stays alive
23:45:34FromDiscord<Elegantbeef> I do not know how the tilengine APIs are
23:46:43FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "I do not know": it requires you to delete tilemaps, bitmaps and all manually when you don't need it anymore
23:47:00FromDiscord<Elegantbeef> Sure then use destructors
23:48:03FromDiscord<ieltan> If the c library extends the lifetime you'll have to use `GC_ref/GC_unref` to manually control the reference counting I think
23:48:06FromDiscord<Elegantbeef> But that does not answer the lifetime model
23:48:20FromDiscord<Elegantbeef> All that matters is the tile engine lifetime model
23:48:35FromDiscord<ieltan> I don't remember to use those lol
23:48:41FromDiscord<Elegantbeef> I assume that all your tilengine objects life times are owned by the resource
23:48:44*coldfeet joined #nim
23:48:54FromDiscord<Elegantbeef> As such if you just use destructors and `ref` objects you're fine
23:49:49FromDiscord<Elegantbeef> Yea these objects are `ptr object`
23:50:15FromDiscord<Elegantbeef> Wrap them with either a `refCount: ref int` or a `=copy` disabled and there you go
23:51:26FromDiscord<Elegantbeef> there is even a `cloneImpl`
23:51:31FromDiscord<Elegantbeef> There is no reason to manually manage any resources here
23:51:43FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "Wrap them with either": and what happens when I pass it to the engine? It shouldn't be deleted when it goes out of scope
23:52:25FromDiscord<Robyn [She/Her]> Does the engine store it somewhere?
23:52:57FromDiscord<System64 ~ Flandre Scarlet> In reply to @chronos.vitaqua "Does the engine store": yeah, internally↵https://github.com/megamarc/Tilengine↵HEre is the code, sometimes quite complex to understand
23:54:11FromDiscord<Elegantbeef> How do you then delete it if you do not have the pointer anymore?↵(@System64 ~ Flandre Scarlet)
23:55:05FromDiscord<Elegantbeef> You can always `=wasMoved` to leak memory
23:55:12FromDiscord<Elegantbeef> Since that's what you seem to be after 😄
23:56:11FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "How do you then": the engine lets you to do stuff like↵TLN_GetLayerTilemap(myLayerIndex);↵And it sends you back a tilemap
23:58:23FromDiscord<Elegantbeef> So then whatever does the setting should take a `sink` and call `=wasMoved` to disarm the destructor