| 00:00:01 | * | marcus quit (Remote host closed the connection) |
| 00:00:43 | * | marcus joined #nim |
| 00:54:01 | * | rockcavera joined #nim |
| 01:17:31 | * | Jjp137 quit (Quit: Leaving) |
| 01:18:07 | FromDiscord | <nitely_> In reply to @albassort "(in sync and not": you could take a look at mummy, it's a non-async server↵in case you have not yet |
| 01:19:19 | * | Jjp137 joined #nim |
| 01:45:54 | FromDiscord | <threefour> In reply to @Elegantbeef "well Nimsuggest is a": I'd wondered how it's so good at understanding even complex macros. That also explains why it seems so slow compared to other languages' analyzers. |
| 01:54:00 | FromDiscord | <Elegantbeef> Well with most languages it's required to use a modified compiler practically |
| 01:55:15 | FromDiscord | <Elegantbeef> Like you could parse all of C then handle `#ifdef`s yourself, but then you have a C frontend with a backend that emits LSP data |
| 02:03:46 | * | rockcavera quit (Remote host closed the connection) |
| 02:48:45 | * | lucasta quit (Quit: Leaving) |
| 04:57:03 | FromDiscord | <Robyn [She/Her]> In reply to @albassort "i'd be better off": does Mummy not work? |
| 04:57:10 | FromDiscord | <Robyn [She/Her]> In reply to @nitely_ "you could take a": oh that was alr said |
| 05:47:00 | * | alexdaguy joined #nim |
| 06:43:30 | FromDiscord | <grumblygibson> In reply to @Elegantbeef "NIR and IC allows": This makes the new strategy make way more sense. Thanks for explaining that. |
| 07:14:05 | * | ntat joined #nim |
| 09:41:02 | * | coldfeet joined #nim |
| 10:16:41 | * | przmk joined #nim |
| 10:16:43 | * | przmk quit (Client Quit) |
| 10:52:35 | FromDiscord | <narimiran> For those who haven't switched yet to Nim 2.2, here's a new 2.0 patch release — Nim 2.0.12:↵https://nim-lang.org/blog/2024/11/01/nim-2012-released.html |
| 11:19:27 | FromDiscord | <zumi.dxy> damn we really on a roll huh |
| 11:45:50 | * | ntat quit (Quit: Leaving) |
| 12:10:04 | * | alexdaguy quit (Quit: WeeChat 4.4.3) |
| 12:41:22 | FromDiscord | <cb314> bobbym |
| 12:45:47 | FromDiscord | <TӨMΛ ☠> sent a long message, see https://pasty.ee/NZtStkEv |
| 12:45:57 | FromDiscord | <TӨMΛ ☠> (edit) "https://pasty.ee/kUhJukYh" => "https://pasty.ee/DaosdiMr" |
| 12:46:41 | FromDiscord | <TӨMΛ ☠> (edit) "https://pasty.ee/xpcEOHXZ" => "https://pasty.ee/eSzZoAEk" |
| 14:58:36 | FromDiscord | <victormaster_> # https://discord.gg/N8MFyX8Yfx @everyone |
| 15:12:47 | FromDiscord | <odexine> xd nice bot |
| 16:12:46 | * | ntat joined #nim |
| 17:00:47 | * | GnuYawk quit (Quit: The Lounge - https://thelounge.chat) |
| 17:01:07 | * | GnuYawk joined #nim |
| 18:01:52 | FromDiscord | <TFed> sent a code paste, see https://play.nim-lang.org/#pasty=fENtvgDg |
| 18:05:13 | FromDiscord | <TFed> i can't `nimble build`, probably because i'm trying to convert int to string (or something) |
| 18:09:06 | Amun-Ra | it's the cast not the conversion |
| 18:17:53 | FromDiscord | <TFed> what's cast 😅? |
| 18:17:53 | * | Deadm0th quit (Remote host closed the connection) |
| 18:18:45 | FromDiscord | <TFed> what cast 😅? |
| 18:18:53 | FromDiscord | <TFed> what is the cast 😅? |
| 18:25:43 | * | lucasta joined #nim |
| 18:38:42 | FromDiscord | <solitudesf> In reply to @TFed "i can't `nimble build`,": in this case it doesn't even matter, you can't use `re` at compiletime |
| 18:49:10 | * | coldfeet quit (Remote host closed the connection) |
| 19:04:05 | FromDiscord | <demotomohiro> @TFed https://nim-lang.org/docs/manual.html#statements-and-expressions-type-casts↵> Type casts are a crude mechanism to interpret the bit pattern of an expression as if it would be of another type. Type casts are only needed for low-level programming and are inherently unsafe. |
| 19:09:59 | FromDiscord | <graveflo> sent a code paste, see https://play.nim-lang.org/#pasty=dFEQAkdP |
| 19:16:55 | FromDiscord | <leorize> it's supposed to be empty, yes |
| 19:17:07 | FromDiscord | <leorize> move meant that you "stole" `s` memory |
| 19:17:31 | FromDiscord | <graveflo> sure but isn't it supposed to work like `sink` where it still retains a copy if you use it after you move it? |
| 19:17:44 | FromDiscord | <leorize> nope, it's an invalidating move |
| 19:18:14 | FromDiscord | <leorize> move is what you use to override that sink quirk |
| 19:18:58 | FromDiscord | <graveflo> interesting... I'm curious what the usefulness of it is. It would be better if it's a compile time error doing what I posted. uninitialized memory isn't usually desirable |
| 19:19:04 | FromDiscord | <guzba8> prevents copies |
| 19:19:07 | FromDiscord | <guzba8> its hugely useful |
| 19:19:37 | FromDiscord | <guzba8> why would what you posted be a compile time error? makes no sense |
| 19:20:01 | FromDiscord | <guzba8> you literally explicitly asked to move the memory to a discard |
| 19:20:20 | FromDiscord | <leorize> it depends™ |
| 19:20:31 | FromDiscord | <TFed> yup, turns out, that i broke another package by storing `re` in `const` instead of `var`↵(@solitudesf) |
| 19:20:34 | FromDiscord | <leorize> but for the most part nim does not host a linear type system |
| 19:20:35 | * | lucasta quit (Quit: Leaving) |
| 19:20:43 | FromDiscord | <graveflo> right... so using it afterwards is arguably invalid |
| 19:20:43 | FromDiscord | <leorize> so stuff like this are expected |
| 19:21:13 | FromDiscord | <leorize> this is more akin to Rust's `mem::take` than a traditional move |
| 19:22:13 | FromDiscord | <graveflo> sink seems to do this just fine in a more sane way. Why use `move` that just puts the "use after move" scenario in a state of uninitialize memory rather then it's current state |
| 19:22:35 | FromDiscord | <fabric.input_output> more like c++ `std::move` |
| 19:24:13 | FromDiscord | <graveflo> Just trying to get the rational of what to use this for. iirc `sink` will not make a copy as long as you do not mutate the object after it was sunk (barring situations where a copy is inevitable) |
| 19:25:05 | FromDiscord | <graveflo> and by that I mean mutate it in the calling context after giving it away. Not the context where is was given to |
| 19:26:11 | FromDiscord | <guzba8> sent a code paste, see https://play.nim-lang.org/#pasty=TQXOBBbT |
| 19:26:22 | FromDiscord | <guzba8> in this case `int` would be something huge like a big string |
| 19:28:00 | FromDiscord | <graveflo> sent a code paste, see https://play.nim-lang.org/#pasty=UhEHuseQ |
| 19:28:22 | FromDiscord | <guzba8> nope you need to explicitly steal it from the big seq |
| 19:28:33 | FromDiscord | <guzba8> i just did add(i) but it really is add(move bigseq[i]) |
| 19:28:51 | FromDiscord | <guzba8> it partially works |
| 19:30:10 | FromDiscord | <guzba8> sink is good to but its too flaky, move lets you be explicit |
| 19:30:31 | FromDiscord | <graveflo> I see what you are getting at with that |
| 19:31:14 | FromDiscord | <guzba8> sent a code paste, see https://play.nim-lang.org/#pasty=RJHTwPai |
| 19:31:21 | FromDiscord | <guzba8> it should be but ive not tested that |
| 19:31:27 | FromDiscord | <graveflo> there is the issue of bigseq having a hole in it after that happens, which does seem to be linked to this type of situation in general, but eh |
| 19:32:11 | FromDiscord | <graveflo> sent a code paste, see https://play.nim-lang.org/#pasty=AqXygjNi |
| 19:32:44 | FromDiscord | <graveflo> well it always sinks it.. question is, is nim smart enough to know that resetting the value ensures that it is not mutated after the sink |
| 19:35:19 | FromDiscord | <graveflo> sent a code paste, see https://play.nim-lang.org/#pasty=MAYzLGAA |
| 19:38:21 | FromDiscord | <guzba8> i look at this and still have no idea if it avoids a copy |
| 19:38:48 | FromDiscord | <guzba8> but this is the right thing to check ofc |
| 19:43:14 | FromDiscord | <graveflo> sent a code paste, see https://play.nim-lang.org/#pasty=riqrZlxd |
| 19:43:25 | FromDiscord | <graveflo> (edit) "https://play.nim-lang.org/#pasty=oAXXgyVI" => "https://play.nim-lang.org/#pasty=SmjoUVnb" |
| 20:18:14 | * | ntat quit (Quit: Leaving) |
| 20:28:12 | * | Deadm0th joined #nim |
| 22:03:42 | * | lucasta joined #nim |
| 22:46:45 | * | Jjp137 quit (Quit: Leaving) |
| 22:47:55 | * | Jjp137 joined #nim |
| 23:07:58 | FromDiscord | <Clonkk> Is there a way to automatically import from C header identifier that can either be an enum or a macro pointing to that enum, without having to re-calculate the enum value |
| 23:11:30 | FromDiscord | <Elegantbeef> Futhark? |
| 23:14:09 | FromDiscord | <Clonkk> Wouldn't that gives me all the symbol from the headers ? |
| 23:14:21 | FromDiscord | <Clonkk> I guess dead code will be eliminated on compilation |
| 23:21:59 | * | Jjp137 quit (Ping timeout: 260 seconds) |
| 23:22:19 | * | Jjp137 joined #nim |
| 23:38:50 | FromDiscord | <leorize> unless your header is gigantic (which would meant slower compile time), I'd say that the dead code wouldn't be too much of an issue |
| 23:47:02 | FromDiscord | <pmunch> In reply to @Clonkk "Wouldn't that gives me": Yes it would, but as you mention dead code elimination makes this a non issue, |