<< 26-03-2025 >>

00:19:52*rockcavera quit (Remote host closed the connection)
03:41:14FromDiscord<heysokam> and and and
03:41:31FromDiscord<heysokam> too many ands, when its just 1 behavior 🤷‍♂️
04:47:03FromDiscord<Baboozo> $$↵\\int\_{0}^{\\infty} e^{-x^2} dx = \\frac{\\sqrt{\\pi}}{2}↵$$
05:10:36*ntat joined #nim
05:42:37FromDiscord<Robyn [She/Her]> In reply to @heysokam "too many ands, when": Eh, it's not really much considering it's probably 3 scripts in total for 2 lines of code each
06:49:19*coldfeet joined #nim
07:10:20FromDiscord<xtrayambak> Is there a way to make different binaries in a Nimble project be compiled with different backends? (E.g, using the C++ backend for `bin_a` and the C backend for `bin_b`)
07:12:53FromDiscord<nasuray> Have you tried using a custom .cfg or .nims for each module that set the backend?
07:13:37FromDiscord<xtrayambak> In reply to @nasuray "Have you tried using": Huh, I haven't. I'll try that. Thanks.
07:16:35Amun-Raxtrayambak: you can add a task to nimble file
07:18:42Amun-Rasomething like this: https://play.nim-lang.org/#pasty=LpmBBhhw
07:19:09FromDiscord<xtrayambak> yeah I just went with nasu's solution for now
07:20:50FromDiscord<xtrayambak> (edit) "now" => "now, thanks tho"
07:25:48*coldfeet quit (Quit: Lost terminal)
07:46:07Amun-Rano worries
08:00:03FromDiscord<.tokyovigilante> Is there any good documentation or best practice for forward declaration and cyclic dependencies? I have an object with procs that are called in a callback in another module, and really struggling to get the imports and so on done correctly.
08:04:21FromDiscord<.tokyovigilante> Or maybe I just need to start using `include` and just stuff everything in the same file
08:08:43FromDiscord<Zoom> That doesn't solve either of the problems.↵(@.tokyovigilante)
08:09:35FromDiscord<Zoom> Separate type decl into its own module first
08:10:27FromDiscord<.tokyovigilante> sent a code paste, see https://play.nim-lang.org/#pasty=QflamWDR
08:17:11*ntat quit (Quit: leaving)
08:22:01FromDiscord<.tokyovigilante> If I declare my type in its own module, then I need to export every member. Is that intended? Not ideal for encapsulation
08:47:28Amun-Ralet's set you store it all in mytypes.nim
08:47:41Amun-Raand in the other module you just write: import mytypes; export mytypes
08:47:51Amun-Ralet' say*
08:51:14FromDiscord<.tokyovigilante> sent a code paste, see https://play.nim-lang.org/#pasty=MyvOAeTF
08:52:41FromDiscord<.tokyovigilante> sent a code paste, see https://play.nim-lang.org/#pasty=TxhZgAgh
08:53:07FromDiscord<.tokyovigilante> (edit) "https://play.nim-lang.org/#pasty=jQcRTcpo" => "https://play.nim-lang.org/#pasty=ZIfbECtI"
08:56:00FromDiscord<.tokyovigilante> Obviously contrived but the actual `CallbackWrapper` type comes from the C API I'm integrating with and ideally I'm trying to encapsulate that all away from the rest of my app
08:59:15FromDiscord<.tokyovigilante> And I would have thought forward declaring `proc method()` was sufficient to make it visible to `callbackFunc`, reinforced by the fact that its not actually a crash but an error in the generated C. The Nim compiler seems to accept it
09:24:37FromDiscord<heysokam> In reply to @battery.acid.bubblegum "Eh, it's not really": that is 3x the code maintainment for something that can be done natively with a simple app
09:25:53FromDiscord<heysokam> imagine you change one... no, can't, you need to change all 3↵wait, but ps can't do that... oh F, just wasted 3h dealing with some nonsense...↵enter: binary app. All of the above never happens
09:26:39FromDiscord<heysokam> Talking from experience, already walked the talk and it was such a pain that I ended up never supporting windows to not deal with the nonsense 🤷‍♂️
09:27:56FromDiscord<heysokam> and this is for a simple `clone, patch, script.sh` task↵anything beyond that is just unfeasible to maintain on the long term
10:36:47*mal`` quit (Read error: Connection reset by peer)
10:46:34FromDiscord<gokr> Idiotic question: Didn't the compiler earlier report how many lines it processed? Can't seem to see that, even with verbosity 3
10:47:31FromDiscord<odexine> It did back in 1.x
10:47:40FromDiscord<odexine> Not sure whether you can set it now
10:48:21FromDiscord<gokr> Discussing the compilation times with the lead dev of ORX. I have always felt Nim compiles really fast - but... I realize different people have different views on that topic
11:05:10FromDiscord<heysokam> In reply to @gokr "Discussing the compilation times": depends heavily on the backend. that alone could explain the pov↵if you build/ffi with cpp libraries, it can be a slog. with c only its as fast as C almost
11:05:49FromDiscord<heysokam> the nim part itself is a fraction of the process. linking takes the biggest blame, i'm sure
11:05:50FromDiscord<gokr> I also guess how much (and complex?) macros you compile
11:05:58FromDiscord<heysokam> that also, true
11:06:35FromDiscord<gokr> Personally I feel Nim compiles really fast - especially since it doesn't recompile all dependencies
11:07:16FromDiscord<heysokam> i think so too myself
11:07:30FromDiscord<gokr> Oddly enough it did report how many lines it processed when I compiled my server part - but it did NOT do it when I compiled the game part. Super weird.
11:07:31FromDiscord<heysokam> but I never build an entire game engine or something similar, only portions of it
11:07:56FromDiscord<heysokam> built
11:09:30FromDiscord<heysokam> as a big project reference, the entire compiler bootstrap process takes about 2-3min on my old-ass machine
11:12:12*ntat joined #nim
11:33:34*mal`` joined #nim
12:28:11*ntat quit (Quit: leaving)
12:41:34*fvs joined #nim
13:12:14*ntat joined #nim
14:07:49FromDiscord<Robyn [She/Her]> In reply to @heysokam "and this is for": for those i understand, but for zigcc, not so much :p
14:17:00FromDiscord<heysokam> In reply to @battery.acid.bubblegum "for those i understand,": I don't follow what you mean
14:58:23FromDiscord<Robyn [She/Her]> as in, making three variants of a script for `zigcc` isn't a problem, for making scripts related to building code, then i get your point
15:04:00FromDiscord<heysokam> In reply to @battery.acid.bubblegum "as in, making three": wkat
15:04:07FromDiscord<heysokam> (edit) "wkat" => "whoops, editing"
15:05:06FromDiscord<heysokam> In reply to @battery.acid.bubblegum "as in, making three": what do you do if you have to then have to provide an installer for the tool that manages zigcc↵its duplicated now. you need to support two layers of complexity
15:06:57FromDiscord<heysokam> your solution is fine for experienced developers that just run a local tool be done with it↵it doesn't work beyond that at all. specially maintaining that is a PITA, even if its just 50 -100sloc. its still platform-dependent code, which is always brittle
15:08:10*coldfeet joined #nim
15:13:41FromDiscord<wertyu4566> hi how could i build a discord bot using nim is it even possible?
15:14:21madpropsit's possible
15:14:48madpropshttps://github.com/krisppurg/dimscord
15:15:32FromDiscord<lainlaylie> you can probably make a discord bot in any language that lets you do http requests
15:16:51FromDiscord<leorize> you're looking at one
15:17:47FromDiscord<krissh.wtf> In reply to @lainlaylie "you can probably make": real https://github.com/concurrentfutures/bashcord
15:23:18*one-star-chef joined #nim
15:28:03*one-star-chef left #nim (#nim)
15:58:58FromDiscord<Robyn [She/Her]> In reply to @heysokam "what do you do": Why would I need to do that exactly?
17:24:26FromDiscord<z1r343l2> For proper discord bots you also need a gateway connection tho
17:24:34FromDiscord<z1r343l2> But depends a lot on what you want to do ngl
17:26:05FromDiscord<z1r343l2> how bout bimscord
17:26:13FromDiscord<z1r343l2> \dimscord
17:27:46FromDiscord<Clonkk> Is there any docs on nimvm ?
17:30:32*coldfeet quit (Quit: Lost terminal)
18:06:44FromDiscord<Robyn [She/Her]> In reply to @z1r343l2 "For proper discord bots": netcat
18:11:25FromDiscord<.bobbbob> question, when using strformat, how come the compiler cant see object field access errors?
18:11:37FromDiscord<.bobbbob> ie it crashes at runtime that is
18:13:37FromDiscord<Elegantbeef> object field access errors?
18:13:53FromDiscord<Elegantbeef> The actual VM or the `nimvm` magic?↵(@Clonkk)
18:19:47FromDiscord<.bobbbob> In reply to @Elegantbeef "object field access errors?": hm well im trying to make an example but a simple example isnt doing it, hold on
18:20:06FromDiscord<Elegantbeef> Are you by any chance using an object variant?
18:20:14madpropshttps://github.com/farzher/fuzzysort
18:20:19Amun-Rayou beat me to it
18:20:25Amun-RaI mean the Beef
18:21:03madpropsyour beef was beaten
18:21:14madpropsbeaten by beef*
18:21:24Amun-Ra:P
18:21:33Amun-Rahe beef me to it
18:22:09Amun-Raeither it's wrong branch in tagged union or hmm… null dereference?
18:24:37FromDiscord<.bobbbob> In reply to @Elegantbeef "Are you by any": yes, I had though it was a field that didnt exist at all but I think I was misremembering
19:15:28FromDiscord<Clonkk> In reply to @Elegantbeef "The actual VM or": I'm essentially trying to get some AST manipulation done at runtime so I was thinking either I could accomplish that with an interpreter or through JIT compilation (I think NLVM has that?)
19:20:46FromDiscord<Elegantbeef> You can use the NimVM to use macros at runtime but it of course does not allow you to do a whole lot
19:21:28FromDiscord<Elegantbeef> https://github.com/beef331/nimscripter/tree/master/examples/macrorepl this little toy allows runtime outputting of macros using nimscripter
19:21:36FromDiscord<Clonkk> Well, that's what I'm trying to look into. What would the limitation of it
19:21:51FromDiscord<Elegantbeef> You cannot do anything the VM cannot do
19:22:00FromDiscord<Elegantbeef> So no low level logic, no ffi(unless you compile with libffi enabled)
19:22:38FromDiscord<Clonkk> But if I have native Nim code (no FFI, no impure stdlib usage), then it should be fine
19:22:43FromDiscord<Elegantbeef> The NimVM is like if someone moved your furniture ever so slightly around your house, you can get throw there but you're likely to stub your toe on every single corner
19:22:45FromDiscord<Clonkk> What's libffi?
19:23:17FromDiscord<Elegantbeef> libffi is a optional dependency of the NimVm which allows `importc` to work inside the VM
19:24:57FromDiscord<Clonkk> Interesting, is there compiler docs on that or do I have to go through the code directly
19:25:42FromDiscord<Clonkk> Have you tried nlvm JIT compilation thing
19:25:42FromDiscord<Elegantbeef> https://github.com/nim-lang/Nim/issues/9253 this is it really
19:25:49FromDiscord<Elegantbeef> Nope
19:26:00FromDiscord<Elegantbeef> I'd rather just use wasm and compile modules for that
19:28:24FromDiscord<Clonkk> Is there any preferred or Official wasm backend? I haven't followed development on this for a while
19:29:05FromDiscord<Elegantbeef> I just use emcc
19:41:38FromDiscord<threefour> Is there a way to define custom pragmas, or are they all compiler magic?
19:47:39FromDiscord<leorize> now you can use `{.custom.}`
19:47:39FromDiscord<leorize> create a `template custom() {.pragma.}`
20:26:08*ntat quit (Quit: leaving)
21:15:52*andreas_ quit (Read error: Connection reset by peer)
21:16:03*andreas_ joined #nim
21:33:41*rockcavera joined #nim
21:50:20FromDiscord<nasuray> In reply to @threefour "Is there a way": https://nim-lang.org/docs/manual.html#userminusdefined-pragmas
22:35:26FromDiscord<threefour> Ooo great, thanks