| 00:03:07 | * | _th3r00t quit (Quit: ZNC 1.10.1 - https://znc.in) |
| 00:03:21 | * | th3r00t joined #nim |
| 00:08:33 | * | th3r00t quit (Ping timeout: 272 seconds) |
| 00:10:48 | FromDiscord | <nervecenter> In reply to @_russianlifts "that seems like it": Nim uses value semantics for everything by default and that's actually way easier than Python's selective reference semantics |
| 00:11:05 | FromDiscord | <nervecenter> pointers are opt-in so most new users won't run into them |
| 00:11:25 | FromDiscord | <nervecenter> and metaprogramming is common but really a trap, most people are overusing the crap out of it |
| 00:11:46 | FromDiscord | <nervecenter> they use it as a tool for every problem instead of the last ditch necessary utility for their given problem |
| 00:13:43 | * | th3r00t joined #nim |
| 00:15:12 | * | gabreal joined #nim |
| 00:15:32 | * | gabreal quit (Remote host closed the connection) |
| 00:16:11 | * | gabreal joined #nim |
| 00:16:27 | * | gabreal quit (Remote host closed the connection) |
| 00:17:02 | FromDiscord | <_russianlifts> In reply to @nervecenter "Nim uses value semantics": easier if you don't care about performance maybe and just ignore references |
| 00:21:16 | * | gabreal joined #nim |
| 00:21:30 | * | gabreal quit (Remote host closed the connection) |
| 00:24:04 | FromDiscord | <nervecenter> In reply to @_russianlifts "easier if you don't": A few copies are still two full orders of magnitude faster than any Python program |
| 00:24:34 | FromDiscord | <nervecenter> If you write expression-oriented functional Nim relying mostly on value-semantics and immutability, the performance you get is still pretty outrageous |
| 00:24:52 | FromDiscord | <nervecenter> And comparable to "best-practices" C++ that makes clean use of the standard library and such |
| 00:25:11 | FromDiscord | <nervecenter> You're not losing a whole lot except the occasional inefficient copy |
| 00:25:41 | FromDiscord | <nervecenter> Whereas in Python, you pay a price at every single line |
| 00:26:53 | FromDiscord | <nervecenter> the problem with inrepreted languages is not garbage collection or their lack of explicit references, it's the interpreter |
| 00:26:59 | FromDiscord | <nervecenter> (edit) "inrepreted" => "interpreted" |
| 00:34:45 | FromDiscord | <_russianlifts> In reply to @nervecenter "A few copies are": I'm not comparing to Python |
| 00:34:48 | FromDiscord | <_russianlifts> im saying in general |
| 00:43:32 | * | derpydoo joined #nim |
| 01:02:44 | * | gabreal joined #nim |
| 01:03:00 | * | gabreal quit (Remote host closed the connection) |
| 01:09:07 | * | beholders_eye quit (Ping timeout: 276 seconds) |
| 01:13:43 | * | Mister_Magister quit (Quit: bye) |
| 01:16:15 | * | Mister_Magister joined #nim |
| 01:22:33 | * | gabreal joined #nim |
| 01:22:37 | * | gabreal quit (Remote host closed the connection) |
| 01:36:52 | FromDiscord | <_russianlifts> In reply to @lumi.ous ""Faster" should never be": you're right I shouldn't want my simulation to finish within my lifetime |
| 01:37:51 | FromDiscord | <_russianlifts> In reply to @_russianlifts "I'm not comparing to": they said "learned Nim" and I assume that to mean Nim in its majority, but yeh you don't need to know things much just to get started |
| 01:50:15 | * | gabreal joined #nim |
| 01:50:40 | * | gabreal quit (Remote host closed the connection) |
| 03:05:56 | * | gabreal joined #nim |
| 03:06:12 | * | gabreal quit (Client Quit) |
| 03:10:20 | * | gabreal joined #nim |
| 03:10:23 | * | gabreal quit (Client Quit) |
| 03:15:49 | * | gabreal joined #nim |
| 03:15:53 | * | gabreal quit (Client Quit) |
| 03:16:10 | * | gabreal joined #nim |
| 03:16:18 | * | gabreal quit (Client Quit) |
| 03:16:35 | * | gabreal joined #nim |
| 03:17:14 | * | gabreal quit (Client Quit) |
| 04:24:12 | * | gabreal joined #nim |
| 04:38:48 | * | gabreal quit (Quit: Cleanly disconnecting(pray for me)) |
| 04:45:57 | * | gabreal joined #nim |
| 04:46:00 | * | gabreal quit (Client Quit) |
| 04:48:08 | * | gabreal joined #nim |
| 04:48:24 | * | gabreal quit (Client Quit) |
| 04:48:38 | * | gabreal joined #nim |
| 04:50:48 | * | gabreal quit (Client Quit) |
| 04:52:14 | * | gabreal joined #nim |
| 04:52:34 | * | gabreal quit (Client Quit) |
| 04:52:50 | * | gabreal joined #nim |
| 04:53:23 | * | gabreal quit (Client Quit) |
| 04:53:47 | * | gabreal joined #nim |
| 04:54:01 | * | gabreal quit (Client Quit) |
| 04:54:37 | * | gabreal joined #nim |
| 04:56:35 | * | gabreal quit (Client Quit) |
| 04:57:24 | * | gabreal joined #nim |
| 04:59:01 | * | gabreal quit (Client Quit) |
| 05:00:25 | * | gabreal joined #nim |
| 05:02:13 | * | gabreal quit (Changing host) |
| 05:02:13 | * | gabreal joined #nim |
| 05:02:32 | * | gabreal quit (Client Quit) |
| 05:02:47 | * | gabreal joined #nim |
| 05:02:53 | * | gabreal quit (Client Quit) |
| 05:03:17 | * | gabreal joined #nim |
| 05:03:40 | * | gabreal quit (Client Quit) |
| 05:04:00 | * | gabreal joined #nim |
| 05:05:51 | * | gabreal quit (Client Quit) |
| 05:06:22 | * | gabreal joined #nim |
| 05:06:28 | * | gabreal quit (Client Quit) |
| 05:07:36 | * | gabreal joined #nim |
| 05:19:41 | FromDiscord | <[Next-System] systemblue> In reply to @uran1um1 "I learned Nim as": very nice decision speed must be your goal |
| 05:20:39 | FromDiscord | <[Next-System] systemblue> In reply to @lumi.ous ""Faster" should never be": no↵speed can be goal in programming↵software goes to slow because of programmer like you↵wirth's law |
| 05:21:37 | FromDiscord | <[Next-System] systemblue> In reply to @lumi.ous ""Faster" should never be": and that's why you use elixir↵stable >>>>> faster↵important to you |
| 05:23:04 | FromDiscord | <[Next-System] systemblue> and there's quite a few devs which use elixir and nim together↵korean nim bloger use elixir/gleam/nim |
| 05:23:50 | FromDiscord | <[Next-System] systemblue> https://findevlawyer.tistory.com/60↵↵someone write blog in korean blog platform↵she translate nim guide to korean |
| 05:24:07 | FromDiscord | <[Next-System] systemblue> (edit) "use" => "uses" |
| 05:24:25 | FromDiscord | <[Next-System] systemblue> and she uses nim and elixir (gleam) together |
| 05:25:10 | FromDiscord | <[Next-System] systemblue> and I have mind to learn gleam before I see it's benchmark↵don't see elixir(gleam)'s benchmark before you learn |
| 05:25:10 | FromDiscord | <[Next-System] systemblue> lol |
| 05:49:48 | * | mrinsane quit (Ping timeout: 268 seconds) |
| 07:01:45 | * | rockcavera is now known as Guest9725 |
| 07:01:45 | * | tiorock joined #nim |
| 07:01:45 | * | Guest9725 quit (Killed (copper.libera.chat (Nickname regained by services))) |
| 07:01:45 | * | tiorock is now known as rockcavera |
| 08:30:01 | FromDiscord | <nocturn9x> I need some help devising a macro |
| 08:30:28 | FromDiscord | <nocturn9x> I have [this](https://github.com/nocturn9x/heimdall/blob/master/src/heimdall/util/tunables.nim) object here |
| 08:30:45 | FromDiscord | <nocturn9x> currently I access its fields as you'd do normally |
| 08:31:15 | FromDiscord | <nocturn9x> I would like to change it such that if `isSpsaTuningEnabled` (a comptime define switch) is `false`, all of those values in `SPSA_OUTPUT` are parsed into constants |
| 08:31:46 | FromDiscord | <nocturn9x> so basically I'd like a getter that depending on that comptime switch either returns a constant integer or accesses a field |
| 08:32:03 | FromDiscord | <nocturn9x> the reason why I need the object at all is that those are tunable parameters and in tunable builds they can be changed at runtime |
| 08:32:10 | FromDiscord | <nocturn9x> but in release builds there's no reason to change them |
| 08:32:25 | FromDiscord | <nocturn9x> currently if tuning is disabled, modifying the parameters is not possible, but the access is still "slow" through the heap allocated object |
| 08:32:29 | FromDiscord | <nocturn9x> any ideas how to achieve that? |
| 09:24:21 | * | beholders_eye joined #nim |
| 10:59:33 | * | ehmry is now known as emery |
| 11:02:42 | * | gabreal quit (Read error: Connection reset by peer) |
| 11:04:14 | * | emery is now known as ehmry |
| 11:32:34 | * | derpydoo quit (Quit: derpydoo) |
| 11:56:59 | * | xutaxkamay quit (Quit: ZNC 1.9.1+deb2+b3 - https://znc.in) |
| 12:18:38 | FromDiscord | <tauruuuuuus> if i understood you correctly, you're using constants stored in a const table, can't you just make this a var instead of const when in need to tune these values at runtime? you would probably have to hide any mutable access behind a when statement too |
| 12:43:47 | FromDiscord | <Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=ilhtaLkE |
| 12:43:59 | FromDiscord | <nocturn9x> that is pretty much what claude did |
| 12:44:04 | FromDiscord | <nocturn9x> with some extra fluff in other spots |
| 12:44:10 | FromDiscord | <Robyn [She/Her]> ah lol |
| 12:44:15 | FromDiscord | <nocturn9x> :D |
| 12:44:29 | FromDiscord | <Robyn [She/Her]> am I a LLM now? |
| 12:44:45 | FromDiscord | <Robyn [She/Her]> look ma, I'm immortalised |
| 14:43:30 | * | beholders_eye quit (Ping timeout: 248 seconds) |
| 15:56:59 | * | gabreal joined #nim |
| 16:18:11 | * | beholders_eye joined #nim |
| 16:25:48 | * | pmp-p quit (Ping timeout: 246 seconds) |
| 17:02:44 | * | mrinsane joined #nim |
| 17:27:50 | * | pmp-p joined #nim |
| 17:55:12 | * | xutaxkamay joined #nim |
| 18:34:19 | FromDiscord | <gesee37> In reply to @asviest "Does anyone know if": Well I was working on this. Not really about vulkan but is made as a base to build game engines and provide the core architecture |
| 18:34:50 | FromDiscord | <gesee37> https://github.com/Gesee-y/Cruise |
| 18:40:37 | * | zodman joined #nim |
| 18:52:12 | * | beholders_eye quit (Quit: WeeChat 4.8.1) |
| 19:24:05 | FromDiscord | <asviest> In reply to @gesee37 "https://github.com/Gesee-y/Cruise": Looks too abstract. vmath already has all these operators anyway. I don't see much point in the windowing abstraction: why would I switch windowing libraries? I can just take siwin and contribute to it as needed. An ECS implementation seems like a genuinely useful thing, but it lacks benchmarks comparing it to polymorph, easyecs, and miniecs. The render abstraction is quite stran |
| 19:29:06 | FromDiscord | <gesee37> In reply to @asviest "Looks too abstract. vmath": Well for the math libs it's made for compatibility so it's compatible with vmath (because it's entirely concept based |
| 19:29:56 | FromDiscord | <gesee37> In reply to @asviest "Looks too abstract. vmath": For the windowing it's just so switching windowing API is easy, reducing dependency to a given library |
| 19:31:03 | FromDiscord | <gesee37> For the ECS I only benchmarked it against ECS in Julia. ↵And you might really want to use it ↵I just dod a basic bench pos-vel against mini ECS (and it was 3 times faster) |
| 19:31:18 | FromDiscord | <gesee37> Too lazy to bench against other ECS 😅 |
| 19:31:43 | FromDiscord | <gesee37> (edit) "3" => "2-3" |
| 19:32:31 | FromDiscord | <gesee37> For the rendering I kept it as minimal as my knowledge in rendering (and how limited they are) allowed me.↵I found command buffers a perfect abstraction for rendering backends |
| 19:34:27 | FromDiscord | <dhhbrzwn> will cyclic import module be available in nim 2.2.x ? |
| 19:35:05 | FromDiscord | <asviest> In reply to @gesee37 "For the rendering I": If there was a good library that implements render graph, that would be great because implementing it yourself is very painful |
| 19:36:36 | FromDiscord | <asviest> In reply to @dhhbrzwn "will cyclic import module": Probably not, unless someone implements them in Nim |
| 19:37:14 | FromDiscord | <gesee37> In reply to @dhhbrzwn "will cyclic import module": As fas as I know only nimony have it |
| 19:37:29 | FromDiscord | <gesee37> (edit) "fas" => "far" |
| 19:39:10 | FromDiscord | <cobaltdsc4102> What sorta improvements will nimony have over nim 2 again? Aside from parallel builds and incremental recompilation |
| 19:39:20 | FromDiscord | <cobaltdsc4102> Mainly in terms of compile and runtime performance |
| 19:40:58 | FromDiscord | <gesee37> In reply to @cobaltdsc4102 "Mainly in terms of": I don't think much, mainly fixing nim 2 quirks.↵Adding NIF intermediate representation↵Compiler's plugin↵Etc |
| 19:41:14 | FromDiscord | <cobaltdsc4102> In reply to @gesee37 "I don't think much,": So NIF IR is a new step between Nim and C codegen? |
| 19:41:29 | FromDiscord | <gesee37> In reply to @cobaltdsc4102 "So NIF IR is": Yeah |
| 19:42:19 | FromDiscord | <asviest> In reply to @cobaltdsc4102 "So NIF IR is": NIF has different dialects and nimonies, and has many compilation steps. |
| 19:42:31 | FromDiscord | <asviest> (edit) removed "nimonies, and" |
| 19:42:47 | FromDiscord | <asviest> (edit) "has" => "represent" |
| 19:42:51 | FromDiscord | <cobaltdsc4102> What benefits does it have over just translating straight to C |
| 19:43:04 | FromDiscord | <dhhbrzwn> In reply to @gesee37 "I don't think much,": will it have smoother ffi library usage ? i mean it would be awesome if nim would have automagically handle ffi library usage. i guess that is a bit similar way of steamos proton with windows relation. |
| 19:44:08 | FromDiscord | <asviest> In reply to @cobaltdsc4102 "What benefits does it": This is a solid architecture, and the compiler will probably become much smarter thanks to nj |
| 19:44:19 | FromDiscord | <cobaltdsc4102> So more opportunity for optimisation |
| 19:45:32 | FromDiscord | <gesee37> In reply to @dhhbrzwn "will it have smoother": Well nim FFI already seems super easy to me so I don't think they will simplify it more.↵Plus there is already futhark.that can handle that for you |
| 19:46:38 | FromDiscord | <gesee37> In reply to @cobaltdsc4102 "So more opportunity for": And also easier to make new backends since now they have only that simplified and structured NIF file to convert |
| 19:46:39 | FromDiscord | <dhhbrzwn> i didnt try it yet but if big c c++ libraries are so easy to import then i think that would make nim more powerful. |
| 19:47:04 | FromDiscord | <asviest> In reply to @cobaltdsc4102 "So more opportunity for": Yes, but it's not just about optimizations; it’s quite possible that nj will provide a better borrow checker that can reduce potential errors. |
| 19:48:14 | FromDiscord | <cobaltdsc4102> In reply to @gesee37 "And also easier to": Oh that's sound, I'd use NLVM but i can't seem to make it use zig for linking |
| 19:49:05 | FromDiscord | <ieltan> Ngl I just want to have `lent` as a objects field and function argument without the compiler going crazy on me |
| 19:49:13 | FromDiscord | <ieltan> That's all |
| 19:49:50 | FromDiscord | <kobewolfdev> sent a long message, see https://pasty.ee/oLwRIpbE |
| 19:51:41 | FromDiscord | <ieltan> Nah thanks |
| 19:51:42 | FromDiscord | <demotomohiro> <@&371760044473319454> |
| 19:51:59 | FromDiscord | <gesee37> In reply to @dhhbrzwn "i didnt try it": Here is an example↵` proc getRawChar(): int {.importc: "_getch", header: "<conio.h>".}` |
| 19:53:26 | FromDiscord | <dhhbrzwn> In reply to @gesee37 "Here is an example": cool but things get complicated if i want to import bigger libraries for example flecs ecs library 😔 i am a bit lazy and inexperienced probably automagical import feels attractive to me |
| 19:53:50 | FromDiscord | <gesee37> In reply to @kobewolfdev "Senior Full Stack /": Well that excalated quickly. There is the #jobs channel for this.↵And it would be better if your competence were nim related |
| 19:54:35 | FromDiscord | <gesee37> (edit) "excalated" => "escalated" |
| 19:55:54 | FromDiscord | <gesee37> In reply to @dhhbrzwn "cool but things get": Check this↵https://github.com/PMunch/futhark |
| 20:15:28 | FromDiscord | <dhhbrzwn> In reply to @gesee37 "Check this https://github.com/PMunch/futhark": if it really allows usage of big libraries (with almost zero user interference) then thats amazing 👏 |
| 20:20:48 | * | hygo joined #nim |
| 20:30:42 | * | gabreal quit (Ping timeout: 248 seconds) |
| 20:31:11 | * | gabreal joined #nim |