| 00:27:05 | FromDiscord | <heysokam> can enum values be negative and still behave like an int internally? |
| 00:27:50 | FromDiscord | <heysokam> I'm assuming they would map to `int` instead of `uint` in those cases? |
| 00:32:36 | FromDiscord | <Elegantbeef> Nim enums don't map to uints afaik |
| 00:34:55 | FromDiscord | <that_dude.> In reply to @crim4 "bu why is the": I'm pretty sure it's for c interop. Same reasons things from `system/ctypes` are easily accessable |
| 00:35:08 | FromDiscord | <Elegantbeef> No it's not jusut for cinterop |
| 00:35:19 | FromDiscord | <that_dude.> I mean, true, but I thought that's the main reason |
| 00:35:24 | FromDiscord | <Elegantbeef> It's cause low level operations should not be a pain to use just cause you can screw up |
| 00:35:40 | FromDiscord | <that_dude.> I've done really hacky stuff with it LOL |
| 00:38:50 | FromDiscord | <that_dude.> In reply to @crim4 "yes is a famous": As for the aliasing problem, if you're derefing anyways, why not just use normal index based dereference. No issues with it at all. If you care about renaming values for convenience, a solution I've used is templates. In my tetris game I used `template mshape: Mino_rotation = m.rotation_shapes[r.safe_mod(4)]` to shorten the code I had to write. |
| 00:39:46 | FromDiscord | <that_dude.> You can define them within the proc you're working in to avoid polluting your global scope |
| 01:08:15 | FromDiscord | <crim4> In reply to @that_dude. "I've done really hacky": aka unsafe stuff |
| 01:09:14 | FromDiscord | <heysokam> sent a code paste, see https://play.nim-lang.org/#pasty=LgwieSyd |
| 01:09:52 | FromDiscord | <crim4> In reply to @Elegantbeef "It's cause low level": i mean i don't want to raise a fuss, im not interested, but isn't this the perfect way to shot in your foot and realize you did only after a while? that reminds me of a c |
| 01:09:56 | FromDiscord | <Elegantbeef> As a single line? |
| 01:10:16 | FromDiscord | <Elegantbeef> Well not cause you should never reach for these parts of the language unless you need to |
| 01:10:20 | FromDiscord | <heysokam> basically, I have a seq[cstring], but dont know how to get a cstringArray from it |
| 01:10:39 | FromDiscord | <Elegantbeef> .add nil `cast[cstringarray](mySeq[0].addr)` |
| 01:11:09 | FromDiscord | <heysokam> oh, that works? kk |
| 01:11:13 | FromDiscord | <Elegantbeef> `ptr T` and `addr` are explicitly unsafe parts of the language and you are to use `ref T` and other safer methods unless you need them |
| 01:11:24 | FromDiscord | <Elegantbeef> Yes cause it's a sequential storage you just need a nil after the last |
| 01:11:44 | FromDiscord | <Elegantbeef> If the procedure operating on the cstringarray knows the length you do not even need to add a nil |
| 01:11:50 | FromDiscord | <Elegantbeef> you can just pass the first value and the length |
| 01:12:38 | FromDiscord | <crim4> In reply to @that_dude. "As for the aliasing": the aliasing problem represents in general a proof of how the language deals with non owning refs and owning refs, c# for example doesn't allow you to use a ref method on List but only on Array (generally you choose to implement the ref method in your class) you may take inspiration and introduce safe ref s |
| 01:13:24 | FromDiscord | <Elegantbeef> Nim actually does not have a save mechanism to hold onto a reference to a sequence element so you should use the index instead |
| 01:13:42 | FromDiscord | <Elegantbeef> Viewtypes are experimental and are supposed to add a borrow checker to allow holding onto references |
| 01:15:43 | FromDiscord | <crim4> about aliasing problem again, it's just a demonstration, not a real world example (but those for sure exist, for example arena allocators, or just dynamic arrays where elements are too big to be loaded so you reference them, or any other example of alias-and-realloc pattern, which inevitably results in ub code, thus cve, without even being aware, even thought nim is claimed to be as safe as Xyz) |
| 01:20:19 | FromDiscord | <crim4> In reply to @Elegantbeef "Nim actually does not": the gc may return handles instead of pointers |
| 01:20:21 | FromDiscord | <heysokam> @crim4 "look, I'm getting outside of the well limited and typesafe features of the language, this lang has issues"↵Nim compiler: 🤦♂️↵Not meant as an attack, just trying to point that your struggles are because of using unsafe features, not because of the way the lang works |
| 01:20:39 | FromDiscord | <Elegantbeef> > the gc may return handles instead of pointers↵> What? |
| 01:21:36 | FromDiscord | <michaelb.eth> In reply to @crim4 "about aliasing problem again,": Nim simply gives you the ability to easily do unsafe ops if you choose↵↵If you choose unsafe ops then there are no guarantees about anything |
| 01:22:13 | FromDiscord | <crim4> In reply to @heysokam "<@990694980567830588> "look, I'm getting": unsafe features that are among us like they were just a bunch super normal functions, so normal that i thought that was a keyword to get safe ref and unsafeAddr was the unsafe corrispetive |
| 01:22:26 | FromDiscord | <Elegantbeef> That's an education issue |
| 01:22:34 | FromDiscord | <Elegantbeef> Once you realise `addr` returns an unsafe pointer you stop using it |
| 01:23:16 | FromDiscord | <crim4> yes but why not masking it behind some more frictioned form, like unsafeAddr? |
| 01:23:28 | FromDiscord | <Elegantbeef> Cause all addrs are unsafe |
| 01:23:30 | FromDiscord | <michaelb.eth> why do that? |
| 01:23:31 | FromDiscord | <heysokam> In reply to @crim4 "unsafe features that are": the manual states the contrary. but I understand it was a knowledge gap. live and learn, I suppose |
| 01:25:08 | FromDiscord | <crim4> In reply to @Elegantbeef "> the gc may": handles are indices to a table of pointers, the gc when reallocs a pointer only has to replace it in the table and you will never experience use after free in your code, because the gc gives you handles, the actual pointers are inside a internal hidden table |
| 01:25:50 | FromDiscord | <crim4> In reply to @Elegantbeef "Cause all addrs are": why would they be considered unsafe? |
| 01:26:18 | FromDiscord | <crim4> they represent a perfectly good way of using data without copying |
| 01:27:25 | FromDiscord | <michaelb.eth> sent a long message, see https://pasty.ee/SDIbqOdV |
| 01:27:51 | FromDiscord | <crim4> In reply to @heysokam "the manual states the": not to be arrogant/presumptuous/rude, really, but "just design better" fits better the context than "live and learn" |
| 01:27:54 | FromDiscord | <michaelb.eth> whoops, last para was also suppose to be quoted |
| 01:30:29 | FromDiscord | <heysokam> In reply to @crim4 "not to be arrogant/presumptuous/rude,": "I didn't read the manual, you should design your lang better"↵I hope you see the issue in that logic |
| 01:32:09 | FromDiscord | <heysokam> I understand you are new and stumbled upon something that feels common usage↵but it is not common to land on unsafe issues early in Nim's learning... at all |
| 01:32:28 | FromDiscord | <crim4> someone of you claimed in the forum that the language was easier then rust and zig for beginners |
| 01:32:48 | FromDiscord | <crim4> because it was safe |
| 01:32:51 | FromDiscord | <heysokam> it is. but not if you try to do manual memory management |
| 01:33:06 | FromDiscord | <crim4> addr is not about manual memory management |
| 01:33:15 | FromDiscord | <heysokam> it is in nim |
| 01:34:30 | FromDiscord | <crim4> referencing is a super common technique in major system languages, so one is not thinking that using it in a claimed-to-be-safe language is gonna fuck up his program |
| 01:34:59 | FromDiscord | <heysokam> for which you use reference pointers, not unsafe features |
| 01:35:24 | FromDiscord | <heysokam> `ref` and `var T` are a thing for a reason |
| 01:36:03 | FromDiscord | <crim4> i would think it for sure if the compiler forced me to enclose it in a small unsace clause `unsafe arr[0].addr` |
| 01:36:25 | FromDiscord | <crim4> o just↵`arr[0].unsafeAddr` |
| 01:36:26 | FromDiscord | <michaelb.eth> yeah, Nim isn’t that way |
| 01:37:05 | FromDiscord | <crim4> In reply to @heysokam "`ref` and `var T`": could you show me how to reference an array slot? |
| 01:37:22 | FromDiscord | <crim4> safely |
| 01:37:51 | FromDiscord | <Elegantbeef> As I said you cannot |
| 01:38:03 | FromDiscord | <Elegantbeef> There is an experimental view type to enable it |
| 01:38:08 | FromDiscord | <Elegantbeef> But that's still experimental |
| 01:38:22 | FromDiscord | <crim4> can i see an example? |
| 01:38:28 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=ZJDmOQHB |
| 01:38:42 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=CSxlaVif |
| 01:38:45 | FromDiscord | <Elegantbeef> Is how you'd do it with views |
| 01:38:55 | FromDiscord | <crim4> In reply to @Elegantbeef "As I said you": then there was no readin to say that ref and var were the thing to use |
| 01:39:30 | FromDiscord | <Elegantbeef> Well are we talking about aliasing into a parameter or a variable |
| 01:39:35 | FromDiscord | <Elegantbeef> Cause you can have a `var T` parameter just fine |
| 01:39:54 | FromDiscord | <crim4> variable, it needs to pass the aliasing problem without cves |
| 01:39:55 | FromDiscord | <Elegantbeef> But holding onto a mutable reference is not possible presently as Nim does not have a borrow checker that is stable |
| 01:40:28 | FromDiscord | <crim4> a borrow checker is not needed to fix this |
| 01:40:55 | FromDiscord | <crim4> the views is what i was searching for |
| 01:40:59 | FromDiscord | <Elegantbeef> A borrow checker or some mechanism to block borrowing of memory that is not owned to you is required |
| 01:41:27 | FromDiscord | <Elegantbeef> If you do `var b = a[0].addr` you have to ensure `a`'s owned memory is not moved and and `b` does not outlive a |
| 01:41:35 | FromDiscord | <Elegantbeef> That requires having some borrowing checking |
| 01:41:39 | FromDiscord | <crim4> In reply to @Elegantbeef "A borrow checker or": it is not required to avoid ub on aliasing problem |
| 01:42:29 | FromDiscord | <crim4> In reply to @Elegantbeef "If you do `var": i mean can be simpler than that, in order to pass the aliasing problem on a reallocatable block |
| 01:43:05 | FromDiscord | <Elegantbeef> How can it be simpler? |
| 01:43:10 | FromDiscord | <crim4> you have multiple solutions, one is to have safe immutable references which can be damn easily implemented using handles |
| 01:43:59 | FromDiscord | <Elegantbeef> What do you mean by handle |
| 01:44:52 | FromDiscord | <crim4> In reply to @Elegantbeef "How can it be": workarounding the thing, you are not required to ban aliasing on a block that can be reallocated, you can also make a subsystem that keeps those aliases updates |
| 01:44:56 | FromDiscord | <crim4> (edit) "updates" => "updated" |
| 01:46:01 | FromDiscord | <Elegantbeef> Sure we could use generational pointers |
| 01:46:01 | FromDiscord | <Elegantbeef> But that's hardly solving the problem and to me is just working around it |
| 01:48:14 | FromDiscord | <crim4> sent a long message, see https://pasty.ee/lWihEDPy |
| 01:48:53 | FromDiscord | <Elegantbeef> Right what I thought |
| 01:49:05 | FromDiscord | <Elegantbeef> It's a fat pointer |
| 01:49:06 | FromDiscord | <crim4> an handle is an index that you make work like a pointer |
| 01:49:11 | FromDiscord | <crim4> In reply to @Elegantbeef "It's a fat pointer": no |
| 01:49:36 | FromDiscord | <crim4> a fat pointer is ptr+size which can be invalidated if ptr is reallocated |
| 01:49:59 | FromDiscord | <crim4> and to deref a fatptr you just need to do fatptr.ptr |
| 01:50:02 | FromDiscord | <Elegantbeef> I mean a fat pointer is not any single thing |
| 01:50:40 | FromDiscord | <crim4> while with an handle↵safe_refs[my_handle] |
| 01:50:42 | FromDiscord | <Elegantbeef> There is not much reason that a fat pointer cannot be a generational index into a memory structure |
| 01:51:10 | FromDiscord | <Elegantbeef> There is a point worth noting that Nim's seq and string are actually not collected by a GC but through RAII |
| 01:51:43 | FromDiscord | <crim4> well may still be the same |
| 01:52:18 | FromDiscord | <crim4> you just need to implement the update_safe_refs_table() logic in the realloc function |
| 01:53:18 | FromDiscord | <crim4> and in the generator when you see `ref expr` you generate/get an handle instead of a pointer |
| 01:53:34 | FromDiscord | <crim4> this for sure introduces overhead |
| 01:53:44 | FromDiscord | <Elegantbeef> It also does not statically solve the problem |
| 01:54:05 | FromDiscord | <crim4> yes it is, why do you think? |
| 01:54:29 | FromDiscord | <Elegantbeef> You have a runtime check, and runtime overhead to migrate pointers |
| 01:54:49 | FromDiscord | <Elegantbeef> You also have to keep data alive as long as a handle exists for the block or it's sub blocks |
| 01:55:05 | FromDiscord | <Elegantbeef> So you then need to have handle collector for even just string/seqs |
| 01:55:10 | FromDiscord | <crim4> In reply to @crim4 "this for sure introduces": introduces slight overhead,↵but you don't need to deal with rust's hated borrow checking and you are not banning aliases but actually making them work |
| 01:55:28 | FromDiscord | <Elegantbeef> I mean Nim's borrow checker does not imitate's Rust's |
| 01:55:32 | FromDiscord | <Elegantbeef> So... moot point |
| 01:55:42 | FromDiscord | <Elegantbeef> Nim's is a much simpler solution which is less intrusive |
| 01:56:26 | FromDiscord | <crim4> In reply to @Elegantbeef "You have a runtime": you always have at MAX a single pointer to replace |
| 01:56:32 | FromDiscord | <crim4> nothing else |
| 01:57:09 | FromDiscord | <crim4> it's cheap, you still have the gc by the way, that algorithm is the bottleneck my friend |
| 01:57:37 | FromDiscord | <crim4> you are trying to chase away a mosquito when you have a bumblebee in the room |
| 01:57:59 | FromDiscord | <crim4> In reply to @Elegantbeef "Nim's is a much": how does the nim's bck work? |
| 01:58:03 | FromDiscord | <Elegantbeef> What? |
| 01:58:17 | FromDiscord | <Elegantbeef> Right now `seq` and `string` do not use a GC |
| 01:58:23 | FromDiscord | <Elegantbeef> They are scope based management |
| 01:58:31 | FromDiscord | <crim4> okay, ... |
| 01:58:36 | FromDiscord | <crim4> you still have the gc |
| 01:58:40 | FromDiscord | <crim4> or arc |
| 01:58:46 | FromDiscord | <crim4> it doesn't really matter |
| 01:58:49 | FromDiscord | <Elegantbeef> Orc only runs on cyclical types |
| 01:58:55 | FromDiscord | <crim4> arc is probably worse then gc imo |
| 01:58:59 | FromDiscord | <Elegantbeef> It doesn't run on all allocations |
| 01:59:59 | FromDiscord | <Elegantbeef> When you free a type with a handle approach you have to walk down the tree and decrement a refcount for all open handles it has |
| 02:00:35 | FromDiscord | <Elegantbeef> This also means you have to have a handle per element in a sequence and decrement those and any other borrows |
| 02:00:45 | FromDiscord | <Elegantbeef> How does this handle even work with stack values? |
| 02:00:54 | FromDiscord | <crim4> but anyway, you have gc/arc/orc it is what it is, it is a bumblebee compared to an handle table holding safe refs, which looks like a mosquito |
| 02:01:53 | FromDiscord | <Elegantbeef> I mean bumblebees are fluffy and cute little bastards that benefit humanity. Mosquitos infect humans with malaria, West Nile and is disputed whether wiping them out would cause any detriment to the ecology of the world |
| 02:02:17 | FromDiscord | <jm_sts> Is it a male mosquito or a female, because I think only the females drink blood |
| 02:02:37 | FromDiscord | <Elegantbeef> Correct only female drink blood |
| 02:02:41 | FromDiscord | <crim4> In reply to @Elegantbeef "How does this handle": up to you, may be nil to keep simple, but honestly you should revolutionize the type system and switch to lifetimes |
| 02:03:32 | FromDiscord | <crim4> so my humble suggestion is to get back unsafeAddr and deprecate addr (with a big warning on the screen) |
| 02:03:44 | FromDiscord | <Elegantbeef> But how does the handle work for a stack allocated value? |
| 02:03:53 | FromDiscord | <crim4> and to go on with view types |
| 02:03:56 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=rGLXBiin |
| 02:04:08 | FromDiscord | <Elegantbeef> How can this be done with handles? |
| 02:06:18 | FromDiscord | <crim4> In reply to @Elegantbeef "But how does the": the same i guess, or you mat decide to rename safe refs to something like "view object type" and make it implementable and not something that is there by default |
| 02:06:47 | FromDiscord | <Elegantbeef> You add `a` to a handle table, then when you close the scope you remove it from the table and invalidate the handles |
| 02:06:47 | FromDiscord | <Elegantbeef> So now you have runtime errors that could be caught statically |
| 02:07:24 | FromDiscord | <crim4> no |
| 02:07:38 | FromDiscord | <crim4> In reply to @crim4 "up to you, may": ^ |
| 02:07:41 | FromDiscord | <crim4> read this |
| 02:07:45 | FromDiscord | <Elegantbeef> I did read it |
| 02:07:49 | FromDiscord | <Elegantbeef> It didn't answer the question |
| 02:07:54 | FromDiscord | <Elegantbeef> You just said "Make it nil" |
| 02:09:41 | FromDiscord | <jm_sts> https://tenor.com/view/zero-gun-dog-john-goodman-the-big-lebowski-gif-4984821 |
| 02:09:47 | FromDiscord | <crim4> yes man, the pointer inside the table can be made nil, and the handle is still valid but points to nil, or you may ref count the safe refs, or you may implement implicit lifetiming for every values, or you can do what i'm gonna write down here, it's really up to how you prefer it |
| 02:09:55 | FromDiscord | <crim4> every solution has its cons |
| 02:10:01 | FromDiscord | <crim4> and its pros |
| 02:14:01 | FromDiscord | <crim4> sent a code paste, see https://play.nim-lang.org/#pasty=RTktkBkP |
| 02:15:15 | FromDiscord | <crim4> you may want to arc the handle then |
| 02:15:20 | FromDiscord | <crim4> but anyways |
| 02:15:32 | FromDiscord | <crim4> porting the language to static lifetimes is better |
| 02:15:45 | FromDiscord | <crim4> you should really consider it |
| 02:15:59 | FromDiscord | <Elegantbeef> Why should I consider porting a language I'm not a core developer on? 😄 |
| 03:00:33 | * | GnuYawk quit (Quit: The Lounge - https://thelounge.chat) |
| 03:00:54 | * | GnuYawk joined #nim |
| 03:10:01 | * | rockcavera quit (Remote host closed the connection) |
| 03:49:44 | FromDiscord | <nervecenter> In reply to @crim4 "referencing is a super": It is astoundingly easy in Nim to write ref-free code in Nim with entirely stack-managed lifetimes for dynamically sized types |
| 03:50:31 | FromDiscord | <nervecenter> This of course depends on the runtime environment and ultimate final product, but for a big CLI tool? Downright simple |
| 03:50:45 | FromDiscord | <nervecenter> (edit) removed "in Nim" |
| 03:51:00 | FromDiscord | <nervecenter> (edit) "environment" => "requirements" |
| 04:31:56 | FromDiscord | <emanresu3> sent a code paste, see https://play.nim-lang.org/#pasty=XCarlOWO |
| 04:37:43 | * | SchweinDeBurg quit (Quit: WeeChat 4.5.0-dev) |
| 04:42:45 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=hptlAwxB |
| 05:02:56 | FromDiscord | <emanresu3> thank you beef! works great |
| 05:03:46 | FromDiscord | <Elegantbeef> Whoops that should be `let name = ...` |
| 05:03:47 | FromDiscord | <emanresu3> the name is always `it` tho, no problem, I think I can make it work with an extra macro |
| 05:04:31 | FromDiscord | <emanresu3> oh, no in a template is already fine |
| 05:04:35 | FromDiscord | <emanresu3> as you said |
| 05:18:36 | * | ntat joined #nim |
| 05:29:52 | * | SchweinDeBurg joined #nim |
| 06:34:07 | * | SchweinDeBurg quit (Quit: WeeChat 4.5.0-dev) |
| 06:38:29 | * | SchweinDeBurg joined #nim |
| 06:46:25 | FromDiscord | <Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=fTGKLZTE |
| 06:47:39 | FromDiscord | <Robyn [She/Her]> how is it even running the code in the body if it only accepts an option and a name? |
| 06:48:30 | FromDiscord | <Elegantbeef> Why wouldn't you |
| 06:48:56 | FromDiscord | <Robyn [She/Her]> In reply to @Elegantbeef "Why wouldn't you": just not the way that comes to mind |
| 06:49:31 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=zKXXvnav |
| 06:53:11 | FromDiscord | <Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=cliHKqhR |
| 06:54:02 | FromDiscord | <Robyn [She/Her]> haven't actually touched code in a bit now... |
| 07:54:03 | * | redj quit (Quit: No Ping reply in 180 seconds.) |
| 07:55:35 | * | redj joined #nim |
| 08:10:20 | * | ntat quit (Quit: Leaving) |
| 08:35:37 | * | def- quit (Quit: -) |
| 08:54:39 | * | def- joined #nim |
| 09:01:32 | * | PMunch joined #nim |
| 09:02:32 | FromDiscord | <crim4> In reply to @Elegantbeef "Why should I consider": "you" in english can refer to multiple person man |
| 09:05:18 | FromDiscord | <odexine> i'd recommend using smth closer to "yall" to be more explicit xd |
| 09:10:39 | FromDiscord | <pmunch> sent a code paste, see https://play.nim-lang.org/#pasty=pBeauTCC |
| 09:14:49 | FromDiscord | <Elegantbeef> That also can incur a costly copy |
| 09:17:51 | PMunch | Hmm, is there no middle ground? |
| 09:18:16 | PMunch | Can't the compiler figure out that a copy is not needed? |
| 09:18:19 | FromDiscord | <Robyn [She/Her]> i feel like there should be a way to do this in Nim |
| 09:18:25 | PMunch | Yeah.. |
| 09:19:20 | FromDiscord | <Robyn [She/Her]> i feel like if there was a way in Nim to do this, `lent Option[T]` could be nice |
| 09:19:29 | FromDiscord | <Robyn [She/Her]> Actually maybe not...? |
| 09:19:50 | FromDiscord | <Robyn [She/Her]> `lent` is an immutable view into an object, right? |
| 09:20:15 | FromDiscord | <Robyn [She/Her]> Actually no because this just adds a new meaning specific to templates |
| 09:20:53 | PMunch | I basically just want `opt` to only ever be an actual `Option[T]` and not "something which can return an `Option[T]`" making it safe to use multiple times |
| 09:21:06 | FromDiscord | <Robyn [She/Her]> With a macro you could detect whether `opt` is a function call or not |
| 09:21:18 | PMunch | True |
| 09:21:21 | FromDiscord | <Robyn [She/Her]> And then generate code based on that |
| 09:21:25 | FromDiscord | <Robyn [She/Her]> But that's just gross |
| 09:21:29 | PMunch | Mhm |
| 09:22:02 | PMunch | Maybe `Option[T]` could always be just an option, and `untyped[Option[T]]` could be any statement resulting in an `Option[T]` |
| 09:22:10 | FromDiscord | <Robyn [She/Her]> Oh a macro that could accept a parameter and then either generate a template or let decl could be useful? |
| 09:22:22 | PMunch | Or I guess `typed[Option[T]]` |
| 09:27:59 | FromDiscord | <Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=IEeDfYsk |
| 09:29:11 | PMunch | Why the template? |
| 09:29:34 | PMunch | Oh right, because you still want to make it available |
| 09:29:39 | PMunch | Nvm |
| 09:29:42 | FromDiscord | <Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#pasty=yjFAWgXg |
| 09:29:49 | FromDiscord | <Robyn [She/Her]> In reply to @PMunch "Oh right, because you": Yep |
| 09:30:04 | FromDiscord | <Robyn [She/Her]> You think something like that would work, though? |
| 09:30:13 | PMunch | I don't see why not |
| 09:30:32 | FromDiscord | <Robyn [She/Her]> radical |
| 09:30:51 | FromDiscord | <Robyn [She/Her]> could PR something like this into std/macros probably |
| 09:31:04 | FromDiscord | <Robyn [She/Her]> something more polished and robust for surr |
| 09:31:06 | FromDiscord | <Robyn [She/Her]> sure |
| 09:31:30 | PMunch | Yeah if not a better syntax then at least a macro in std/macros would be nice |
| 09:46:04 | FromDiscord | <TӨMΛ ☠> Out of curiosity, is there .ods parser lib for Nim? |
| 09:49:07 | * | def- quit (Quit: -) |
| 09:49:23 | * | def- joined #nim |
| 09:49:52 | FromDiscord | <Robyn [She/Her]> @TӨMΛ ☠ https://github.com/dariolah/odsreader |
| 09:49:58 | FromDiscord | <Robyn [She/Her]> 3 years old though |
| 09:50:33 | FromDiscord | <Robyn [She/Her]> also seems pretty minimal? |
| 09:56:11 | FromDiscord | <ieltan> In reply to @chronos.vitaqua "i feel like if": More like `Option[lent T] ` |
| 09:56:56 | FromDiscord | <TӨMΛ ☠> In reply to @chronos.vitaqua "also seems pretty minimal?": Honestly? It's absolutely dope, I needed exactly minimal tool, just to read the stuff to put it as HTML table 💙 |
| 10:54:28 | * | ryuukk quit (Remote host closed the connection) |
| 10:57:27 | * | ryuukk joined #nim |
| 12:06:14 | FromDiscord | <Robyn [She/Her]> rad :) |
| 12:06:25 | * | ryuukk quit (Remote host closed the connection) |
| 12:08:58 | * | ryuukk joined #nim |
| 12:38:41 | * | ntat joined #nim |
| 12:52:05 | * | def- quit (Quit: -) |
| 12:53:04 | * | def- joined #nim |
| 13:03:37 | FromDiscord | <heysokam> sent a code paste, see https://play.nim-lang.org/#pasty=DnfjIULs |
| 13:06:14 | strogon14 | the first arg has non-matching type. |
| 13:07:33 | FromDiscord | <heysokam> the error does not name it correctly. it is matching |
| 13:07:46 | FromDiscord | <heysokam> all three are matching |
| 13:08:07 | FromDiscord | <heysokam> I double/triple checked all three |
| 13:27:46 | FromDiscord | <solitudesf> sent a code paste, see https://play.nim-lang.org/#pasty=mYPzMokZ |
| 13:30:00 | FromDiscord | <heysokam> In reply to @solitudesf "are there two different": I've been checking, but I don't think so↵The Allocator type is only partially defined, so I'm wrapping the whole struct just in case↵Was just wondering if there is a way to get more data than "type mismatch" in the error message somehow |
| 13:37:35 | FromDiscord | <solitudesf> In reply to @heysokam "I've been checking, but": well, is there? it looks like one of them is in `vk` module and another one in `debug`. is the repo available somewhere? |
| 13:40:05 | FromDiscord | <gyatsoyt> If I have an executable compiled through nim but I no more have the codes for it I still have the executable so can I in any ways retrieve the code back through the executable cz I wanna make that better rn it's not too great but starting of on that project would take a lot of time ... |
| 13:41:11 | FromDiscord | <heysokam> In reply to @solitudesf "well, is there? it": the error names are misleading↵they are imported from different files, but coming from the same actual modules |
| 13:41:38 | FromDiscord | <solitudesf> are you sure they are imported and not included in every module? |
| 13:41:51 | FromDiscord | <heysokam> In reply to @gyatsoyt "If I have an": did you compile it in debug mode? |
| 13:41:59 | FromDiscord | <heysokam> In reply to @solitudesf "are you sure they": yes |
| 13:42:54 | FromDiscord | <heysokam> In reply to @gyatsoyt "If I have an": If you compiled it in debug mode (the default) symbols wont be stripped and the debugger will show you some, if not most, of the code |
| 13:46:24 | FromDiscord | <heysokam> @solitudesf I seem to be past the weird nonsense error↵All I did was wrap the entire C struct, instead of just the name 🤔 |
| 13:47:48 | strogon14 | the compiler usually doesn't lie |
| 13:50:47 | FromDiscord | <heysokam> what |
| 13:50:53 | FromDiscord | <heysokam> (edit) "what ... " added "does that mean?" |
| 13:54:02 | strogon14 | that you have two different types vk.Instance and instance.Instance. |
| 13:54:02 | strogon14 | Maybe the're based on the same definition, but imported in different ways. |
| 13:58:40 | * | beholders_eye joined #nim |
| 14:00:35 | FromDiscord | <gyatsoyt> In reply to @heysokam "If you compiled it": Well yes it was in debug mode how do I decompile it ? |
| 14:02:33 | FromDiscord | <heysokam> In reply to @strogon14 "Maybe the're based on": It wasn't failing on the instance |
| 14:03:12 | FromDiscord | <heysokam> In reply to @gyatsoyt "Well yes it was": you dont decompile it. you open it with the debugger and the code will be there in the debugger ui |
| 14:03:43 | FromDiscord | <heysokam> how to debug nim code depends wildly on your system |
| 14:16:08 | * | oisota quit (Quit: Ping timeout (120 seconds)) |
| 14:21:04 | FromDiscord | <heysokam> how do you represent `void val = NULL;` in Nim?↵Wasn't it `var val :pointer= nil`?↵Or can `nil` not be used for that? |
| 14:22:52 | * | oisota joined #nim |
| 14:23:19 | PMunch | `var val: pointer = nil` should be equivalent, yes |
| 14:27:29 | FromDiscord | <heysokam> I'm getting a `SIGSEGV: Illegal storage access. (Attempt to read from nil?)` and its pointing to a `nil` value I declared (expected NULL by C)↵Maybe I have something else invalid in the code 🤷♂️ |
| 14:53:14 | Amun-Ra | heysokam: show the code |
| 14:56:20 | FromDiscord | <heysokam> In reply to @Amun-Ra "heysokam: show the code": you dont know what you are asking 🙈 |
| 14:56:33 | * | beholders_eye quit (Ping timeout: 246 seconds) |
| 14:56:51 | Amun-Ra | :D |
| 14:56:58 | * | beholders_eye joined #nim |
| 14:57:48 | FromDiscord | <heysokam> I'll take a break from the nim side of the project and come back to ask with better/renewed energy |
| 14:58:16 | FromDiscord | <heysokam> debugging nim gets me on my nerves |
| 14:59:09 | Amun-Ra | do you have noinit object by any chance? |
| 14:59:27 | Amun-Ra | objects* |
| 15:19:00 | * | beholders_eye quit (Ping timeout: 260 seconds) |
| 15:29:43 | * | zgasma joined #nim |
| 15:30:12 | * | PMunch quit (Quit: Leaving) |
| 16:34:35 | * | def- quit (Quit: -) |
| 16:35:17 | * | def- joined #nim |
| 16:43:01 | * | def- quit (Quit: -) |
| 16:44:05 | * | def- joined #nim |
| 16:49:51 | * | coldfeet joined #nim |
| 17:03:07 | Amun-Ra | I'm iterating object fields with fieldPairs, is there a way to obtain type a distinct type is based on? |
| 17:03:55 | FromDiscord | <Robyn [She/Her]> In reply to @gyatsoyt "If I have an": nope |
| 17:04:25 | FromDiscord | <Robyn [She/Her]> In reply to @heysokam "you dont decompile it.": it'll be very mangled too, tho |
| 17:04:36 | FromDiscord | <Robyn [She/Her]> wait will it? |
| 17:04:42 | FromDiscord | <Robyn [She/Her]> ignore me idk what I'm on about |
| 17:05:46 | FromDiscord | <heysokam> In reply to @chronos.vitaqua "it'll be very mangled": `nim-gdb` does show the code |
| 17:06:27 | FromDiscord | <Robyn [She/Her]> In reply to @heysokam "`nim-gdb` does show the": isn't that removed in newer versions of Nim? |
| 17:06:28 | * | Amun-Ra found std/typetraits |
| 17:06:30 | FromDiscord | <Robyn [She/Her]> for a while now? |
| 17:08:35 | Amun-Ra | Robyn: nim-gdb still resides in my bin dir |
| 17:12:02 | FromDiscord | <heysokam> In reply to @chronos.vitaqua "isn't that removed in": i dont know why you say that. never heard of such a thing |
| 17:26:14 | FromDiscord | <Robyn [She/Her]> huh... |
| 17:26:49 | FromDiscord | <Robyn [She/Her]> ig i was just confused |
| 17:29:12 | * | beholders_eye joined #nim |
| 17:50:58 | * | coldfeet quit (Remote host closed the connection) |
| 19:50:43 | * | ntat quit (Quit: Leaving) |
| 20:11:30 | FromDiscord | <Robyn [She/Her]> question to y'all: What exactly is a query builder supposed to look like, and do? |
| 20:12:47 | FromDiscord | <Robyn [She/Her]> Is it database agnostic representation of queries in the implementing language which'll then generate a query? |
| 20:34:53 | * | def- quit (Quit: -) |
| 20:35:45 | * | def- joined #nim |
| 20:44:40 | FromDiscord | <bubbly_avocado_86424> hello world |
| 20:45:36 | FromDiscord | <bubbly_avocado_86424> Seeking where to ask to learn about how to compile NIM using openbuild service from SUSE |
| 20:58:28 | FromDiscord | <Elegantbeef> What is NIM? |
| 21:32:46 | FromDiscord | <spotlightkid> Nim In Majuscles |
| 21:36:18 | FromDiscord | <spotlightkid> @bubbly_avocado_86424\:↵Look at what the [build\_all.sh](https://github.com/nim-lang/Nim/blob/devel/build_all.sh) script in the Nim repo does. Look the Github Actions CI workflows for dependencies\: https://github.com/nim-lang/Nim/blob/devel/.github/workflows/ci_publish.yml |
| 21:38:44 | FromDiscord | <spotlightkid> Then look at the template for the `install.sh`, which is included in the release packages, on how to install things\: https://github.com/nim-lang/Nim/blob/2c56872b5c27b31284a036f77be2b78501b68df3/tools/niminst/install.nimf#L21↵Don't use the case with `/usr` as a prefix, though, because that produces broken Nim installations. |
| 21:38:54 | FromDiscord | <bubbly_avocado_86424> In reply to @spotlightkid "<@1263017119956729937>\: Look at what": I've started reading https://build.opensuse.org/projects/home:david.anes:nim/packages/nim/files/nim.spec?expand=1 which does make sense but leaves much to learn regardless |
| 21:40:01 | FromDiscord | <spotlightkid> It seems to basically do the same, but a few things more. |
| 21:42:24 | FromDiscord | <bubbly_avocado_86424> sent a long message, see https://pasty.ee/XRfkrMPm |
| 21:49:14 | FromDiscord | <spotlightkid> So? Three options\: 1) ignore the warnings 2) fix them 3) report them as issues on github or on the forum. |
| 21:51:18 | FromDiscord | <bubbly_avocado_86424> In reply to @spotlightkid "So? Three options\: 1)": that's the spirit 😄↵i'd rather try and understand them first |
| 21:53:57 | * | beholders_eye quit (Ping timeout: 248 seconds) |
| 23:04:03 | * | redj quit (Ping timeout: 276 seconds) |
| 23:22:29 | FromDiscord | <yottzumm> I'm trying to do pointer arithmetic, but it's not working ` |
| 23:22:32 | FromDiscord | <yottzumm> var data: array[6, int] = [ 0, 1, 2, 3, 4, 5 ]↵var p: pointer = addr(data[0])↵p += 1 |
| 23:23:54 | FromDiscord | <Elegantbeef> Nim doesn't have pointer arithmetic in the stdlib |
| 23:24:20 | FromDiscord | <Elegantbeef> You can do `var p = cast[ptr UncheckedArray[int]](data[0].addr)` or use ptr\_math from nimble |