<< 30-07-2025 >>
00:25:38*mronetwo quit (Server closed connection)
00:25:46*mronetwo joined #nim
00:45:14*beholders_eye quit (Ping timeout: 260 seconds)
00:52:16*amadaluzia joined #nim
01:18:31FromDiscord<nasuray> In reply to @aintea "what is the "Scanning..."": You won't see this anymore if you install the latest version
01:21:36FromDiscord<Elegantbeef> The scanning was a `sleep(10000)` that was left in the code. I joke, but it sure feels like it
01:32:33FromDiscord<Trayambak> It does.
02:38:01*rockcavera quit (Remote host closed the connection)
03:22:18*casaca quit (Server closed connection)
03:22:26*casaca joined #nim
03:53:50FromDiscord<nasuray> Genuinely though I think there is some networking/caching shenanigans with nimble separate from the sat solver that may be leading to at times slow dependency resolution. But I haven't profiled the code
03:54:25FromDiscord<Elegantbeef> I've seen that packages with 0 dependencies take forever to install so I don't know if it's related to SAT much
04:00:00FromDiscord<nasuray> There is a weirdly high number of git operations that could probably be paired down to 1 or 2
04:00:39FromDiscord<nasuray> But that might separate from the install slow downs
04:01:26*amadaluzia quit (Quit: ZNC 1.10.1 - https://znc.in)
04:50:00*skippy8 joined #nim
05:13:27*nils` quit (Ping timeout: 276 seconds)
06:28:20*skippy8 quit (Quit: WeeChat 4.6.3)
06:33:34FromDiscord<aintea> In reply to @nasuray "You won't see this": I don't but it still feels like a `sleep(10000)` was left in the code
06:35:43FromDiscord<Elegantbeef> But now you don't see the scanning 😛
08:15:14*nils` joined #nim
08:19:32*xet7 quit (Remote host closed the connection)
08:20:01*nils` quit (Ping timeout: 248 seconds)
08:21:04*ntat joined #nim
08:26:03FromDiscord<blashyrk> Why is value-equality not implemented for ref objects? Seems like a weird decision
08:44:09*nils` joined #nim
08:52:07FromDiscord<lainlaylie> because most people don't expect calling the default `==` to send them into an infinite loop
08:53:50FromDiscord<lainlaylie> and more importantly ref types are characterised by their identity, not their value, so two different refs with the same value should not be considered equal
09:07:40FromDiscord<blashyrk> On the other hand writing value equality by hand is soul crushing and extremely unergonomic. There could there at least be a pragma for opt in value equality semantics
09:10:28FromDiscord<blashyrk> Plus there isn't even a === or similar operator to distinguish between the two, you have to write some weird 'isEqual' func because if you override the equality operator you lose the ability to test reference equality altogether...
09:11:36FromDiscord<nnsee> sent a code paste, see https://play.nim-lang.org/#pasty=ayzcsEYD
09:12:31FromDiscord<blashyrk> True I guess
09:16:48FromDiscord<heysokam> note that `ref T` are basically pointers with comfort↵it does make sense that if you compare a pointer to a pointer with `==`,↵you'd get comparison of the pointer and not the dereferenced data↵its only confusing if you think about them as data, but they aren't truly data
09:17:14FromDiscord<intellij_gamer> sent a code paste, see https://play.nim-lang.org/#pasty=hoJIPDYB
09:17:25FromDiscord<heysokam> You can pass a `ref T` to a C function taking `ptr T`, and it would work fine
09:19:57FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#pasty=PgrzkDRH
09:20:32FromDiscord<lainlaylie> might want to check for nil
09:23:57FromDiscord<blashyrk> sent a code paste, see https://play.nim-lang.org/#pasty=waNzUJnR
09:25:16FromDiscord<nnsee> sent a code paste, see https://play.nim-lang.org/#pasty=NIrkWYlI
09:25:17FromDiscord<nnsee> https://play.nim-lang.org/#pasty=CSTRFXiw
09:26:10FromDiscord<lainlaylie> really think we should for nil instead of crashing
09:26:16FromDiscord<lainlaylie> (edit) "really think we should ... for" added "check"
09:26:33FromDiscord<nnsee> live fast crash young
09:47:32FromDiscord<cy83rn0153> complete nim newbie here with not much coding experience outside of python, what are some examples where let would work better than const or var?
09:49:54FromDiscord<cy83rn0153> cuz const seems better optimization-wise and var seems way more useful for most stuff, i cant think of a lot of stuff that would only need to be set once during a program's runtime
09:50:04FromDiscord<cy83rn0153> (edit) "during" => "DURING"
09:50:33FromDiscord<0xfab_10> const is compile time constant (evaluated at compile time, can't be mutated, the places where the variable is used you just get the value), let is runtime constant and var is just a variable
09:50:47FromDiscord<cy83rn0153> yea i know that much
09:51:01FromDiscord<cy83rn0153> but let just seems a bit... outclassed by both of them
09:51:21FromDiscord<cy83rn0153> like... maybe temp files ig
09:51:25FromDiscord<0xfab_10> plenty of times where I create things that I don't mutate
09:52:56FromDiscord<cy83rn0153> but why create them at runtime rather than at compile time? faster startup times?
09:53:20FromDiscord<cy83rn0153> im probably missing something like super obvious
09:53:37FromDiscord<0xfab_10> at runtime because you're doing things at runtime
09:53:44FromDiscord<0xfab_10> when the program runs
09:53:51FromDiscord<0xfab_10> you specify that the thing will not be mutated
09:54:58FromDiscord<cy83rn0153> so what would be an example of that
09:55:06FromDiscord<0xfab_10> sent a code paste, see https://play.nim-lang.org/#pasty=tRLUgzRF
09:55:36*SchweinDeBurg quit (Ping timeout: 252 seconds)
09:56:17FromDiscord<0xfab_10> sent a code paste, see https://play.nim-lang.org/#pasty=IWVwVlzK
09:58:35FromDiscord<cy83rn0153> i am using 100% of my brain rn
09:59:28*SchweinDeBurg joined #nim
10:00:42FromDiscord<cy83rn0153> i have zero clue what this code is for, i feel so dumb
10:00:44FromDiscord<0xfab_10> also the value of a const gets substituted in the places where the variable is used, with let you're referencing the same thing every time
10:02:06FromDiscord<0xfab_10> In reply to @cy83rn0153 "i have zero clue": it's just doing some math but the point is that:↵1. var isn't needed because we're just storing values in variables to use them later, no mutation↵2. not const because we're doing things while the program is running, const is strictly for compile time values
10:03:36FromDiscord<cy83rn0153> so these values that are stored at runtime require user input but will never be changed during runtime
10:03:52FromDiscord<0xfab_10> yes
10:04:33FromDiscord<cy83rn0153> can you give me a very abstract example like not in code but in what action would the user do that would set something in stone for the rest of the runtime
10:04:41FromDiscord<cy83rn0153> cuz i was thinking like
10:04:58FromDiscord<cy83rn0153> setting a canvas size in like gimp
10:05:00FromDiscord<0xfab_10> well perhaps not the rest of time
10:05:11FromDiscord<0xfab_10> maybe just intermediate values during some calculation
10:05:11FromDiscord<cy83rn0153> but that can change too by resizing the canvas
10:05:43FromDiscord<0xfab_10> for example just within a function
10:05:58FromDiscord<0xfab_10> which is what usually happens
10:06:22FromDiscord<lainlaylie> command line arguments, user directories, http response data...
10:06:41FromDiscord<lainlaylie> all things that you dont know at compile time but wont need to mutate
10:08:21FromDiscord<nnsee> In reply to @cy83rn0153 "can you give me": it's not the rest of runtime, just the rest of that specific scope, e.g. a function body
10:08:37FromDiscord<nnsee> function arguments, for example, are `let` by default
10:09:04FromDiscord<blashyrk> One caveat is that with ref objects you get interior mutability even if they're behind 'let' bindings but don't worry about that yet
10:09:56FromDiscord<cy83rn0153> oh yea cuz like command line arguments would just be read and executed once and then they would be cleared from ram after the command is done running right? and so the let assignment would be... unloaded?
10:10:10FromDiscord<cy83rn0153> i'm trynna understand this at a low level
10:11:02FromDiscord<blashyrk> It depends on the scope, if you use a let variable in some proc/func it will only live until the end of the function scope
10:11:11FromDiscord<cy83rn0153> cuz im kinda new at coding and i'm just now trynna figure out what happens with these after being used
10:12:13FromDiscord<lainlaylie> In reply to @cy83rn0153 "oh yea cuz like": well yes they're unloaded once the program quits but that's a different story. if your program takes a `-v` flag to control output verbosity there's no reason to put that in a var, the verbosity setting will not change
10:12:30FromDiscord<cy83rn0153> oh yea wait im dumb why would u even unload that
10:13:04FromDiscord<blashyrk> If you want to learn how these things operate under the hood, you need to read about stack VS heap allocation, how functions operate on variables and how they return values, how bags of values (objects) are allocated and passed around etc
10:13:18FromDiscord<blashyrk> These things are not specific to just Nim
10:13:35FromDiscord<lainlaylie> i actually think the question is upside down, instead you should ask in what cases do i actually have to mutate data? i find most of the time you don't
10:15:11FromDiscord<cy83rn0153> In reply to @lainlaylie "i actually think the": yea but if you dont needa mutate data wouldnt the most common assignment be const
10:15:26FromDiscord<nnsee> if you're going to be reading up on the stack vs the heap (which i also highly recommend to get a better low-level understanding), this is a pretty good article: https://zevv.nl/nim-memory/
10:15:37FromDiscord<lainlaylie> no, because there are things you dont know at compile time, such as the examples given above
10:15:39FromDiscord<nnsee> In reply to @cy83rn0153 "yea but if you": you can't assign const at runtime
10:16:34FromDiscord<0xfab_10> in python there is no notion of compile time but in compiled languages, compilation happens once before you can run anything to get the executable that you can run
10:16:46FromDiscord<cy83rn0153> In reply to @nnsee "you can't assign const": i know, but shouldnt most assignments happen either at compile time or multiple times during runtime
10:17:23FromDiscord<nnsee> "multiple times during runtime" - you don't achieve this by using a var and mutating it, you achieve this by using scopes
10:17:54FromDiscord<cy83rn0153> OH WAIT
10:19:41FromDiscord<cy83rn0153> so you usually only declare a let assignment inside a scope and then you get rid of it or something when it's unused? i feel like im saying something rly dumb at the end there my brain rly isnt braining rn
10:19:47FromDiscord<nnsee> sent a code paste, see https://play.nim-lang.org/#pasty=DWstsqRL
10:22:32FromDiscord<cy83rn0153> so lets are used inside procs
10:22:47FromDiscord<cy83rn0153> at least mostly
10:22:50FromDiscord<0xfab_10> everything is used inside procs
10:22:53FromDiscord<nnsee> In reply to @cy83rn0153 "so lets are used": generally, a program consists of procs
10:23:29FromDiscord<cy83rn0153> not constants tho right
10:24:08FromDiscord<nnsee> In reply to @cy83rn0153 "so lets are used": a proc defines a scope. a proc is a single scope, but you can also define arbitrary scopes using `block` and the same rules apply there
10:24:28FromDiscord<cy83rn0153> In reply to @cy83rn0153 "so lets are used": created
10:24:40FromDiscord<cy83rn0153> like ofc they are used inside procs duhhh
10:25:33FromDiscord<cy83rn0153> im a bit slow ok
10:25:53FromDiscord<nnsee> In reply to @cy83rn0153 "not constants tho right": no, constants too
10:26:04FromDiscord<nnsee> sent a code paste, see https://play.nim-lang.org/#pasty=TVGVKtXR
10:26:10FromDiscord<nnsee> (edit) "https://play.nim-lang.org/#pasty=twacNYao" => "https://play.nim-lang.org/#pasty=NOWDzbel"
10:26:54FromDiscord<nnsee> (edit) "https://play.nim-lang.org/#pasty=TajFFllD" => "https://play.nim-lang.org/#pasty=mEhXvQor"
10:27:20FromDiscord<lainlaylie> in almost evey respect vars and lets are the same apart from that the compiler will not allow you to modify a let
10:28:13FromDiscord<lainlaylie> almost everything else, including what happens to them when they exit scope, is the same
10:29:29FromDiscord<cy83rn0153> im having the biggest brainfart ever rn
10:30:39FromDiscord<cy83rn0153> if procedures are called during runtime
10:30:54FromDiscord<cy83rn0153> how can they define a constant
10:31:20FromDiscord<lainlaylie> that's just a syntactic thing, the const is still global
10:31:35FromDiscord<lainlaylie> just not accessible outside its scope
10:33:27FromDiscord<cy83rn0153> so constants inside procedures are created at compile time but can only be called by whatever procedure they're defined in, which would mean... you could have 2 constants with the same name inside different procedures and have different values?
10:33:51FromDiscord<cy83rn0153> like im assumming thats a thing but a god awful practice?
10:34:00FromDiscord<lainlaylie> it's a great practice
10:34:04FromDiscord<cy83rn0153> oh
10:34:48FromDiscord<cy83rn0153> so when would it be useful to have 2 constants with the same name and different values in different procs
10:36:07FromDiscord<nnsee> sent a long message, see https://pasty.ee/jjnyQIgR
10:36:31FromDiscord<cy83rn0153> (im so new to nim i havent even gotten to procs yet to begin with btw so please bear with me lmao)
10:36:39FromDiscord<nnsee> this is not nim-specific
10:37:53*amadaluzia joined #nim
10:38:03FromDiscord<cy83rn0153> In reply to @nnsee "if you use a": ok that clarified it
10:38:48FromDiscord<cy83rn0153> so consts are usually defined in the global scope and lets are pretty much always defined inside scopes
10:39:16FromDiscord<cy83rn0153> In reply to @nnsee "this is not nim-specific": i didnt get too far in python either tbh
10:39:23FromDiscord<lainlaylie> In reply to @cy83rn0153 "so consts are *usually*": not in my codebases 😤
10:39:40FromDiscord<nnsee> In reply to @cy83rn0153 "so consts are *usually*": it depends on the programmer and what you're writing tbh
10:40:25FromDiscord<nnsee> if you know you're never going to be changing the value of that const, it's better to keep it inside the scope you're using it in, unless it's something you imagine you'll be using in other places as well (example: value of pi)
10:41:02FromDiscord<cy83rn0153> wait yea that makes sense
10:41:06FromDiscord<cy83rn0153> more organized
10:41:08FromDiscord<cy83rn0153> yea
10:41:08FromDiscord<nnsee> if it's, like, configuration options that you want to bake into the binary at compile time, i like to define it in a `consts.nim` so i can find it easily later if i need to change it
10:41:18FromDiscord<nnsee> but this is really up to personal preference
10:43:20FromDiscord<lainlaylie> there are cases where you have a const that you know will only be used by the current proc, so you put it in the proc to have one less random const polluting the parent scope
10:43:47FromDiscord<cy83rn0153> yea that's what i just realized
10:44:24FromDiscord<cy83rn0153> ty all for helping me wrap my head around ts btw
10:45:00FromDiscord<cy83rn0153> went from "dont seem to understand" to "i am ballin i am faded" @lainlaylie
10:45:22FromDiscord<lainlaylie> you are welcome
10:45:47FromDiscord<nnsee> Don't give up, skeleton!
10:46:31FromDiscord<cy83rn0153> lain fan and dark souls fan
10:46:46FromDiscord<cy83rn0153> W
10:47:02FromDiscord<cy83rn0153> yall real asf
11:03:04*nils` quit (Ping timeout: 276 seconds)
11:45:00*SchweinDeBurg quit (Read error: Connection reset by peer)
11:53:26*SchweinDeBurg joined #nim
12:15:54*tokyovigilante quit (Ping timeout: 260 seconds)
12:20:27*nils` joined #nim
12:20:37*tokyovigilante joined #nim
12:43:54*nils` quit (Ping timeout: 260 seconds)
13:07:15*xet7 joined #nim
13:09:02*skippy8 joined #nim
13:12:13*skippy8 quit (Client Quit)
13:19:48*beholders_eye joined #nim
13:26:33*nils` joined #nim
13:34:58*SchweinDeBurg quit (Ping timeout: 245 seconds)
13:37:05*SchweinDeBurg joined #nim
13:41:34*SchweinDeBurg quit (Ping timeout: 244 seconds)
13:43:19*SchweinDeBurg joined #nim
13:49:58*beholders_eye quit (Ping timeout: 240 seconds)
13:58:45*nils` quit (Ping timeout: 248 seconds)
14:35:54*SchweinDeBurg quit (Ping timeout: 260 seconds)
14:39:31*SchweinDeBurg joined #nim
15:01:18*nils` joined #nim
15:28:14FromDiscord<theloserscandy> Had anyone had any luck cross-compiling in Windows to MacOS? I tried nimxc, no luck there. I've got mingw64 installed and working. Any ideas?
15:31:35FromDiscord<spotlightkid> if it#s public code, it's probably easier if you set up a GH actions workflow. Example\: https://github.com/SpotlightKid/nim-sndfile/blob/master/.github/workflows/build.yml
15:31:46FromDiscord<spotlightkid> if it's public code, it's probably easier if you set up a GH actions workflow. Example\: https://github.com/SpotlightKid/nim-sndfile/blob/master/.github/workflows/build.yml
15:33:17*xet7 quit (Ping timeout: 252 seconds)
16:02:24FromDiscord<blashyrk> sent a long message, see https://pasty.ee/LdPUZhva
16:19:17*zeropoint joined #nim
16:38:11FromDiscord<theloserscandy> In reply to @blashyrk "I just managed to": @blashyrk Thanks, I'll give it a shot!
16:50:39*nils` quit (Ping timeout: 260 seconds)
16:53:19FromDiscord<nasuray> In reply to @blashyrk "I just managed to": Why are you installing clang and zig in this case?
16:57:54*SchweinDeBurg quit (Ping timeout: 248 seconds)
16:59:45*SchweinDeBurg joined #nim
17:00:34FromDiscord<blashyrk> In reply to @nasuray "Why are you installing": Simply because I'm used to the llvm toolchain and I never tried gcc (let alone mingw) for cross compilation... And zigc because it comes bundled with cross compilation sdks by default (for example you need some headers that simply don't exist in mingw as they are Unix only etc)
17:01:05FromDiscord<blashyrk> I'm sure you could to the same with mingw but it's probably a lot more fiddly
17:09:44*xet7 joined #nim
17:19:40*skippy8 joined #nim
17:21:26FromDiscord<janakali> In reply to @blashyrk "Simply because I'm used": zig has clang built-in, you don't need an extra C compiler
17:24:38FromDiscord<blashyrk> Even better then
17:25:45*beholders_eye joined #nim
17:46:47*xet7 quit (Remote host closed the connection)
17:50:41*nils` joined #nim
18:40:29FromDiscord<nieznanymagnat> sent a code paste, see https://play.nim-lang.org/#pasty=uKHoURKr
18:46:05FromDiscord<nieznanymagnat> ofc it's not the whole file, just the minimal code to reproduce the error. After I figure out what went wrong there, I should be fine to fix it in the rest of the file (since it follows similar pattern). Thanks in advance
18:56:25*SchweinDeBurg quit (Ping timeout: 252 seconds)
19:56:19*ntat quit (Ping timeout: 260 seconds)
20:03:42*amadaluzia quit (Quit: ZNC 1.10.1 - https://znc.in)
20:07:20*amadaluzia joined #nim
20:17:40FromDiscord<cy83rn0153> i genuinely dont understand how this lang isnt more popular
20:18:04FromDiscord<cy83rn0153> do people code in bad languages on purpose
20:18:26FromDiscord<cy83rn0153> do they actively seek out pain and suffering
20:18:55FromDiscord<leorize> you just have to use it more to get your answers
20:20:05FromDiscord<cy83rn0153> oh god
20:22:12FromDiscord<cy83rn0153> whatever it cant possibly be worse than rust
20:29:50FromDiscord<blashyrk> In reply to @cy83rn0153 "whatever it cant possibly": Worse how? Rust is pretty great imo
20:33:38FromDiscord<0xfab_10> rust is great
20:33:42FromDiscord<0xfab_10> you could've said js
20:33:44FromDiscord<0xfab_10> or c++
20:49:18FromDiscord<jfaz> In reply to @cy83rn0153 "i genuinely dont understand": From what I can tell it's just small ecosystem + lack of corpo backing
20:50:14FromDiscord<jfaz> Both fine with me 😆
20:56:54FromDiscord<cy83rn0153> In reply to @fabric.input_output "you could've said js": i woulda said js
20:56:58FromDiscord<cy83rn0153> however
20:57:04FromDiscord<cy83rn0153> i have never even tried js cuz it scares me
20:57:14FromDiscord<cy83rn0153> like i've seen some TERRIFYING shit
20:57:33FromDiscord<cy83rn0153> idk i tried rust like half a year ago
20:57:48FromDiscord<0xfab_10> rust is not kind to newcomers
20:58:04FromDiscord<cy83rn0153> i remember finding it way more complicated than the first lang i tried learning (python)
20:58:05FromDiscord<0xfab_10> you need some c and c++ experience to get it
20:58:13FromDiscord<cy83rn0153> and my silly ass decided to try c after that
20:58:20FromDiscord<cy83rn0153> and honestly i shoulda kept going with c
20:58:22FromDiscord<cy83rn0153> idk why i stopped
20:58:31FromDiscord<cy83rn0153> fear of failure ig
20:58:43FromDiscord<cy83rn0153> cuz pointers and memory leaks scared me
20:59:16*amadaluzia quit (Quit: ZNC 1.10.1 - https://znc.in)
20:59:18FromDiscord<cy83rn0153> like i think i prefered c over rust
21:00:22*amadaluzia joined #nim
21:00:39FromDiscord<cy83rn0153> idk if i ever get tired of nim im 100% giving c another shot
21:02:58FromDiscord<0xfab_10> I tried webassembly before C
21:03:03FromDiscord<0xfab_10> with assemblyscript
21:03:13FromDiscord<0xfab_10> to get rid of my fear of low level
21:04:18FromDiscord<cy83rn0153> i honestly dont have that big of a fear of low level like
21:04:28FromDiscord<cy83rn0153> c is like mid level
21:04:49*SchweinDeBurg joined #nim
21:04:54FromDiscord<cy83rn0153> anything lower level than c seems pretty scary tho
21:05:13FromDiscord<Elegantbeef> No C is high level
21:05:16FromDiscord<cy83rn0153> like id rather sand my eyes down than learn assembly
21:05:23FromDiscord<DetermiedNim1> "fear of low level" dont be shy set every byte in memory to 0
21:05:31FromDiscord<cy83rn0153> true...
21:06:01FromDiscord<DetermiedNim1> That server pfp is amazing
21:06:29FromDiscord<cy83rn0153> mine?
21:07:50FromDiscord<DetermiedNim1> the one your tag is from
21:08:03FromDiscord<DetermiedNim1> "kittens"
21:08:05FromDiscord<cy83rn0153> oh yeah it's absolutely peak
21:08:17FromDiscord<cy83rn0153> bro looks like he's about to swallow EVERYTHING
21:08:17FromDiscord<DetermiedNim1> indeed 🔥🔥🔥
21:25:15*rockcavera joined #nim
21:37:06*skippy8 quit (Quit: WeeChat 4.6.3)
22:03:19*tiorock joined #nim
22:03:19*rockcavera is now known as Guest6787
22:03:19*Guest6787 quit (Killed (calcium.libera.chat (Nickname regained by services)))
22:03:19*tiorock is now known as rockcavera
22:05:40*tiorock joined #nim
22:05:41*rockcavera quit (Killed (zirconium.libera.chat (Nickname regained by services)))
22:05:41*tiorock is now known as rockcavera
22:07:45*tiorock joined #nim
22:07:45*tiorock quit (Changing host)
22:07:45*tiorock joined #nim
22:07:45*rockcavera is now known as Guest367
22:07:45*Guest367 quit (Killed (silver.libera.chat (Nickname regained by services)))
22:07:45*tiorock is now known as rockcavera
22:17:12FromDiscord<nieznanymagnat> In reply to @nieznanymagnat "Hi, I'm in the": If anyone has an idea what I did wrong, I'd be grateful for help
22:23:03*zgasma joined #nim
22:27:21*zgasma quit (Client Quit)
22:27:43*zgasma joined #nim
22:36:32*beholders_eye quit (Ping timeout: 272 seconds)
22:56:06FromDiscord<demotomohiro> In reply to @nieznanymagnat "If anyone has an": https://play.nim-lang.org/#pasty=OOMerciZ↵Changed uint to int as https://internet-of-tomohiro.pages.dev/nim/faq.en#language-design-why-are-unsigned-types-discouragedqmark↵You use `new(T)` that returns `ref T` type value but `List` in your code is not ref type.
22:59:59FromDiscord<demotomohiro> In reply to @nieznanymagnat "If anyone has an": When you got compile errors that is hard to fix, removing a part of code (object fields, parameters or etc) might help to find what causing the error.
23:29:23*tiorock joined #nim
23:29:24*tiorock quit (Changing host)
23:29:24*tiorock joined #nim
23:29:24*rockcavera is now known as Guest8202
23:29:24*Guest8202 quit (Killed (molybdenum.libera.chat (Nickname regained by services)))
23:29:24*tiorock is now known as rockcavera
23:44:28FromDiscord<zumi.dxy> i find `--errorMax:1` helps often