<< 24-06-2024 >>

00:00:07FromDiscord<albassort> or not, its gone
00:00:08FromDiscord<albassort> Β―\_(ツ)_/Β―
00:00:32FromDiscord<albassort> i had 1 job
00:01:18FromDiscord<Robyn [She/Her]> Everything works fine...until it doesn't...and then suddenly it does again xD
00:56:02FromDiscord<leorize> usually when it does that it's a sign of stack corruption
00:57:14FromDiscord<albassort> In reply to @leorize "usually when it does": i am furiously scrubbing all of the addresses!
00:59:51FromDiscord<demotomohiro> In reply to @albassort "everything is synced up": It is possible that you wrote a undefined behaiver code but it didn't affected your code and passed tests.↡But that UB code affected recently added code.
01:02:59FromDiscord<albassort> In reply to @demotomohiro "It is possible that": i would say so, if it wasn't for the fact that just recompiling the code fixed it (sometimes)
01:03:12FromDiscord<albassort> i think leorize is right though. I think it is stack corruption
01:03:34FromDiscord<albassort> my code is durable in terms of behavior, but flimsy in terms of memory
01:04:30FromDiscord<leorize> luckily stack corruption is simple
01:04:50FromDiscord<leorize> just make sure you give out the right memory size to FFI
01:05:27FromDiscord<albassort> it was more, i was reading an extra 15 bytes in 3 places, and freeing an extra 1sizeof
01:05:48FromDiscord<albassort> or maybe not. I don't know about the second one
01:06:23FromDiscord<albassort> but who knows if that actually fixed the issue, i will to keep testing
01:09:03FromDiscord<leorize> what's the signature of the troubling function?
01:09:12FromDiscord<leorize> and the nim signature, too
01:10:37FromDiscord<albassort> i pushed a fix to gitlab now
01:15:14FromDiscord<Elegantbeef> Thought I'd add multi threading to a fractal tree toy, and now the program runs 33% slower!
01:15:24FromDiscord<Elegantbeef> We did it we made it use more CPU at the cost of thrashing the cache!
01:24:32FromDiscord<leorize> btw albassort, check this out\: https://github.com/arnetheduck/nbindgen?tab=readme-ov-file
01:25:51FromDiscord<Robyn [She/Her]> In reply to @leorize "btw albassort, check this": Isn't that outdated and/or incomplete?
01:26:06FromDiscord<albassort> In reply to @chronos.vitaqua "Isn't that outdated and/or": I heard that too, thats why i didn't use it
01:26:39FromDiscord<Robyn [She/Her]> A lib that'd provide glue for Nim and Rust seems pretty useful though
01:27:38FromDiscord<leorize> last commit is 8mo ago so I think it could still work?
01:28:25FromDiscord<Robyn [She/Her]> Fair point
01:28:43FromDiscord<albassort> its better than manually changing the bindings every time i update the rust code, i'll say that
01:28:43FromDiscord<Robyn [She/Her]> Smh if only Rust had compile-time introspection
01:29:19FromDiscord<Robyn [She/Her]> Wait couldn't you make a dead simple macro in Rust that you could use as an annotation to generate the Nim glue?-
01:30:04FromDiscord<Robyn [She/Her]> Cbindgen (and Nimbindgen) probably do that
01:32:03FromDiscord<leorize> they don't use macross
01:32:39FromDiscord<leorize> oh wait it is a proc macro
01:32:53FromDiscord<Elegantbeef> Leo "the liar" rize
01:32:57FromDiscord<leorize> interesting, I guess rust macros can be compiled to binary?
01:33:16FromDiscord<Elegantbeef> I think that's how proc macros work
01:33:27FromDiscord<leorize> IC took so long Rust already got native macros done
01:33:47FromDiscord<Elegantbeef> Now if only Rust macros didn't require you to use a cargo to split them
01:39:03FromDiscord<graveflo> does the shared heap put the block size behind the allocated block like malloc does or am I tripping? I can't seem to find it
01:39:49FromDiscord<leorize> you can just `-d:useMalloc` and you won't have to worry about such frivolity
01:40:23FromDiscord<graveflo> true but I would like to know how it works.. I guess I could just read the source if I have to
01:41:50FromDiscord<albassort> i am unable to get nbindgen to have any output
01:41:52FromDiscord<albassort> πŸ”
01:42:42FromDiscord<leorize> then ig it's toasted
01:43:33FromDiscord<albassort> it parses the rust properly and warns me about the right partsd
01:43:34FromDiscord<albassort> (edit) "partsd" => "parts"
01:43:36FromDiscord<albassort> but no nim output
01:43:37FromDiscord<albassort> rip
02:01:21*SchweinDeBurg quit (Quit: WeeChat 4.4.0-dev)
02:35:56FromDiscord<planetis_m> In reply to @graveflo "does the shared heap": Ots the tlsf allocator and i think not
02:39:52FromDiscord<planetis_m> It's a few fields before the data https://github.com/nim-lang/Nim/blob/830153323af0fce9ca5c73030c2374f03367a412/lib/system/alloc.nim#L88
02:59:46FromDiscord<graveflo> nice one! thanks
03:45:38*SchweinDeBurg joined #nim
03:48:58FromDiscord<that_dude.> In reply to @tommyzjones_20 "Dear admin and fellow": <@&371760044473319454> This one snuck through
04:04:23*FromDiscord quit (Remote host closed the connection)
04:04:37*FromDiscord joined #nim
04:07:14*xet7 quit (Remote host closed the connection)
05:02:22*ntat joined #nim
05:39:47*disso-peach quit (Quit: Leaving)
05:44:46FromDiscord<sOkam! 🫐> I swear nim error messages trigger me badly sometimes 😭
05:46:04FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=qdHnDJfV
05:46:06FromDiscord<Elegantbeef> To shoot with the rude response "l4rn 2 rd"
05:46:18FromDiscord<sOkam! 🫐> (edit) "https://play.nim-lang.org/#pasty=EWcNJTyv" => "https://play.nim-lang.org/#pasty=WlngnJPt"
05:46:35FromDiscord<Elegantbeef> I assume `Logger` is not generic?
05:46:48FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=gJWVuxWq
05:48:33FromDiscord<Elegantbeef> Cannot say anything myself πŸ˜„
05:48:42FromDiscord<sOkam! 🫐> yeah, it makes no sense
05:48:53FromDiscord<Elegantbeef> I think it'd probably make sense with full context
05:49:11FromDiscord<sOkam! 🫐> I'm writing it in a PR. let me push my current stuff and send the link
05:52:41FromDiscord<sOkam! 🫐> @ElegantBeef This is the line that errors↡https://github.com/heysokam/nstd/blob/b00b88e8bf7f9204773835f5cce0820d11a1a7f5/src/nstd/logger/core.nim#L122
05:54:39FromDiscord<sOkam! 🫐> It is calling for `erase`, which is here:↡https://github.com/heysokam/nstd/blob/b00b88e8bf7f9204773835f5cce0820d11a1a7f5/src/nstd/paths/files.nim#L83
05:55:41FromDiscord<Elegantbeef> Oh you have circular deps
05:55:45FromDiscord<Elegantbeef> Fun
05:56:59FromDiscord<sOkam! 🫐> yeah, I just saw it when running the tests! wth
05:57:24FromDiscord<sOkam! 🫐> why does the compiler sometimes choke on itself and not print the circular deps error message
05:57:49FromDiscord<Elegantbeef> Probably cached files
05:57:51FromDiscord<Elegantbeef> Who knows
05:57:52FromDiscord<sOkam! 🫐> sent a code paste, see https://play.nim-lang.org/#pasty=wHHJFEUU
05:58:01FromDiscord<sOkam! 🫐> In reply to @Elegantbeef "Probably cached files": ah that could be
05:59:54FromDiscord<sOkam! 🫐> removed the logger from the `create` dir call... and solve it πŸ€·β€β™‚οΈ
06:00:50FromDiscord<Elegantbeef> Some delayed imports and everything might work
06:01:30*coldfeet joined #nim
06:02:58FromDiscord<Elegantbeef> Heh your `DefVerbose` is verbose
06:03:49FromDiscord<Elegantbeef> `const DefVerbose = not(defined(release) or defined(danger)) or defined(debug)`
06:05:01FromDiscord<Elegantbeef> Though I imagine that could just be `defined(debug)` since `-d:release -d:debug` works
06:08:41*coldfeet quit (Remote host closed the connection)
06:19:04FromDiscord<sOkam! 🫐> yeah its verbose by default, since nim compiles on `debug` mode by default
06:19:24FromDiscord<Elegantbeef> I mean the body was verbose
06:19:39FromDiscord<sOkam! 🫐> don't know what you mean
06:20:02FromDiscord<Elegantbeef> You have `when (...) elif ...: ... else: ...`
06:21:35FromDiscord<Elegantbeef> Which is just a overly complex boolean expression like I did above
06:22:53FromDiscord<sOkam! 🫐> where exactly? i dont follow
06:23:27FromDiscord<Elegantbeef> `const DefVerbose = not(defined(release) or defined(danger)) or defined(debug)`
06:26:24FromDiscord<sOkam! 🫐> yes, that means↡> fill in the `-d:debug` that is missing from official nim compiler↡> and do verbose things on debug by default when its -d:debug or when it should be
06:26:47FromDiscord<Elegantbeef> What?
06:27:04FromDiscord<Elegantbeef> Yours presently is this `const DefVerbose = when defined(release) or defined(danger): false elif defined(debug): true else: true`
06:27:14FromDiscord<Elegantbeef> Which is just a verbose version of the above
06:27:18FromDiscord<Elegantbeef> Which is what I found ironic
06:28:12FromDiscord<sOkam! 🫐> im really confused
06:29:02FromDiscord<thepuzzleddev> is there an interpreter for nim?
06:29:33FromDiscord<Elegantbeef> You have a when elf else chain when a boolean operation suffices sokam
06:29:45FromDiscord<Elegantbeef> I found it funny that it was `DefVerbose` that had a verbose body
06:29:55FromDiscord<Elegantbeef> Yes nimscript exists it's only a subset so it's not grand
06:30:06FromDiscord<sOkam! 🫐> In reply to @Elegantbeef "I found it funny": ah, i see
06:30:19FromDiscord<sOkam! 🫐> sorry, I absolutely didn't get the connection there
06:31:32FromDiscord<sOkam! 🫐> me, pretty much https://media.discordapp.net/attachments/371759389889003532/1254685323842293810/joke-joke-missed.gif?ex=667a6444&is=667912c4&hm=c1eecedabb83ae339799834e79243949cef42589ad1b4e7d23b8dc7ce6d8506b&
06:36:23FromDiscord<Elegantbeef> Damn data is your father
06:44:02*PMunch joined #nim
08:27:52FromDiscord<ieltan> i need something to replace choosenim
08:27:55FromDiscord<ieltan> any ideas ?
08:28:45FromDiscord<Marcus> Nix? πŸ™‚
08:30:28FromDiscord<ieltan> In reply to @Marcus "Nix? πŸ™‚": I've already used Nix/NixOS so I know how to install it using Nix but I just want to install it in another OS without it lol
08:31:20FromDiscord<ieltan> and choosenim interacts poorly with langserver or whatever and create zombie processes
08:32:50FromDiscord<ieltan> meh, i guess i'll check if good ole docker is up to date
08:34:01FromDiscord<ieltan> inb4 "compile it from source" yes but is there an alternative installer that doesn't require me to git pull the whole nim repo which takes storage on my disk ?
08:35:00FromDiscord<ieltan> and yup docker is up to date
08:42:32FromDiscord<ieltan> just needed to compile some code, i'll to do this proper later
08:42:38FromDiscord<ieltan> for now it's enough
08:44:40FromDiscord<Clonkk> In reply to @ieltan "i need something to": Download the latest 2.0.X version with atlas included and uses 'atlas env'
08:45:33FromDiscord<Clonkk> Then setup some bash alias that sources the correct env file and send you in the workspace directory
08:45:56FromDiscord<Clonkk> easiest way to swap between Nim version in a contained format
09:02:25FromDiscord<ieltan> In reply to @.sneakybaguette "Download the latest 2.0.X": totally forgot about atlas
09:02:29FromDiscord<ieltan> thanks πŸ™‚
09:29:02*beholders_eye joined #nim
09:30:22*smlckz joined #nim
09:31:49smlckz2.0.6 was released, yet channel topic have not changed..
09:35:56smlckzHow can I make this work? https://0x0.st/XAgI.txt
09:36:54*beholders_eye quit (Quit: WeeChat 4.1.2)
09:40:00*coldfeet joined #nim
09:41:16PMunchThanks for reminding me smlckz!
09:41:39PMunch@ieltan, why do you need to replace it?
09:42:06PMunchWe're working on fixing choosenim
09:42:18PMunchSo it might be worth just waiting for that
09:42:29PMunchOr you could try nimlsp which doesn't have the zombie process issue
09:53:10smlckzPMunch: no problem, how about my question?
09:54:49PMunchDepends on what you mean by "make it work"
09:55:27PMunchFor starters arrays are static size
09:55:37PMunchSo you need to pick a dynamically sized data structure
09:56:09FromDiscord<ieltan> In reply to @PMunch "<@256520101015060480>, why do you": cuz of the zombie processes... but if you say nimlsp doesnt have this issue then i'll give it a try.
09:56:39PMunch@ieltan, yeah nimlsp uses nimsuggest as a library, so you don't even need to have nimsuggest installed to use NimLSP :)
09:59:14PMunchsmlckz, something like this works: https://play.nim-lang.org/#pasty=jjDvrxCR
10:32:08smlckzPMunch: this ... also works: https://play.nim-lang.org/#pasty=KFaLbTES
10:33:44PMunchSure, but now you have to specify how many bits you need..
10:39:46*coldfeet quit (Remote host closed the connection)
10:41:14PMunchOf course for many usecases it is quite surperfluous to first convert to an array or a sequence: https://play.nim-lang.org/#pasty=LEBCiPrU
10:44:16smlckzhmm
11:06:19smlckzWhy does len returns int? Why isn't there any seperate type for size?
11:08:40FromDiscord<sOkam! 🫐> In reply to @smlckz "Why does len returns": if you need to interop with C, its `csize_t`
11:09:08FromDiscord<sOkam! 🫐> I believe there is also a `csize` type, but I don't remember the details of that one
11:10:21FromDiscord<sOkam! 🫐> but there is no need to `usize` or `size_t`, just use `uint`
11:13:19*xet7 joined #nim
11:13:45smlckzhmm https://github.com/nim-lang/Nim/blob/version-2-0/lib/system/ctypes.nim#L42
11:13:51PMunchsmlckz, why would you want `len` to not return an int?
11:13:51FromDiscord<sOkam! 🫐> @ElegantBeef I'm having an issue where a custom type that I made is not automatically converting to string with a custom `$` proc that I made πŸ€”β†΅It also ignores a converter I just wrote too↡Do you know what could trigger that misbehavior? Am I missing something?
11:14:22smlckzbtw what is nimPreviewSlimSystem?
11:14:22PMunchMissing exports? Or missing module imports?
11:17:44FromDiscord<sOkam! 🫐> @pmunch it is importing a `paths` module that I made, everywhere I can see πŸ€”
11:17:51smlckzPMunch: in reality, I welcome having sizes stored in signed integers, I wonder what was the rationale behind the choice. Is it the same as what I think it is?
11:17:59FromDiscord<sOkam! 🫐> that module imports all its subfiles, and exports them
11:19:44PMunchsmlckz, I think the rationale is pretty much that you're never going to use more than int64.high anyways, and unsigned integers can act in strange ways if you're not careful
11:19:48FromDiscord<sOkam! 🫐> Oh, I think I see what's happening. somewhere there is a fmt inside another fmt... and that might be the cause
11:24:02FromDiscord<sOkam! 🫐> nope, that wasn't it
11:24:26PMunchHard to tell without looking at code unfortunately
11:24:29FromDiscord<sOkam! 🫐> well, I will manually convert anyway. I don't want to keep hunting template issues. I found enough of them this week πŸ™ˆ
11:25:16FromDiscord<sOkam! 🫐> In reply to @PMunch "Hard to tell without": I'm not sure how the code would help, since its spread across multiple repos and deeply nested in function chains 😦
11:25:47FromDiscord<sOkam! 🫐> would need to create a min-repro. but I would rather explcitly convert than try to hunt another template bug this week
11:25:49FromDiscord<sOkam! 🫐> maybe some other time
11:33:09*SchweinDeBurg quit (Quit: WeeChat 4.4.0-dev)
11:38:59*SchweinDeBurg joined #nim
11:42:12FromDiscord<melmass> Oh PMunch is here πŸ™‚ I'm currently trying out Futhark
11:42:18FromDiscord<melmass> Why are you all APPS πŸ€” ?
11:43:26PMunchHuh?
11:46:58FromDiscord<demotomohiro> In reply to @melmass "Oh PMunch is here": There are bridges between different chat services and there are people using IRC or other chat services.
11:47:13PMunchOh right, on Discord we have "APP" next to our names :P
11:47:16PMunchForgot about that
11:47:26PMunchAt least it's better than "BOT" or whatever it used to say
11:47:51PMunchA surprising amount of people though we just had some really clever bots in this chat
11:48:32FromDiscord<melmass> Nice I thought it was some anonymization thing I wasn't aware of
11:48:42FromDiscord<zumi.dxy> I mean the IRC bridge avatar is still a bot
11:49:22FromDiscord<demotomohiro> Many new beginner thought beef is clever AI written in Nim.
11:50:06FromDiscord<melmass> In reply to @PMunch "Huh?": Is there a way to "debug" rename directives in futhark? I'd like to understand what the proc receives
11:50:19FromDiscord<zumi.dxy> ~~i wish~~
11:50:57FromDiscord<melmass> It worked suprinsingly well out of the box, but now I'm struggling a bit on the impl/manual part
11:54:08PMunchHmm, not exactly sure what you're looking for
11:54:14PMunchYou could always just echo out what you get
11:55:40FromDiscord<melmass> sent a code paste, see https://play.nim-lang.org/#pasty=NgQMpsYN
11:57:33PMunchYou might be running into cache stuff
11:58:00PMunchTry compiling with `-d:useFuthark -d:futharkRebuild`
11:58:07FromDiscord<melmass> And the actual end goal is that furthark seems to generate a lot of "aliased" structs for the same type, and they don't all expose the same fields
11:58:32PMunchThat sounds strange
11:58:42PMunchFuthark should just do the 1:1 from C
11:59:10PMunchOnly thing which should change is the names of identifiers to make sure they are unique
12:00:19FromDiscord<melmass> The source I'm trying to bridge handle A LOT of environments which I think might be the issue here
12:00:29FromDiscord<melmass> <https://github.com/ufbx/ufbx>
12:00:51FromDiscord<melmass> Ah cool, using rebuild revealed some errors
12:01:11FromDiscord<sOkam! 🫐> In reply to @melmass "And the actual end": the C names are respected verbatim though
12:01:28FromDiscord<sOkam! 🫐> the aliases are confusing, but thats just codegen noise. the C names is what matters
12:01:37FromDiscord<sOkam! 🫐> and those are preserved
12:03:02PMunchWhy would environments be an issue?
12:03:34FromDiscord<melmass> I see thanks! I did use the bare c names which resulted in "xxx field not found" so looking at the generated bindings I saw all those typed aliases and they don't seem to all define the same fields
12:05:10FromDiscord<melmass> In reply to @PMunch "Why would environments be": Just a guess that's probably not a big deal? I meant that it uses a lot of templates and comp time conditionals
12:05:37PMunchShouldn't bother Futhark at all :)
12:07:07FromDiscord<melmass> Cool so the rebuild did reveal I didn't need those custom define but I still get an error `Error: cannot 'importc' variable at compile time;` but now removing rebuild works fine
12:07:36PMunchWithout the rebuild it builds from cache
12:07:50PMunchSo if you at some point had a working version that's the one it grabs
12:08:22FromDiscord<melmass> Ah yes, that might explain some stuff, so I'm not "iterating" since quite some time I think fk me πŸ˜…
12:08:23PMunchThe importc at compile time thing is probably the OS module trying to write to a file in a non-compatible way with compile-time procs
12:08:37PMunchHaha, simple mistake
12:08:50PMunchGranted if you change anything in the importc block it should trigger a rebuild
12:08:57PMunchSame for changing the renameCallabck
12:09:20FromDiscord<melmass> YES!
12:09:48FromDiscord<melmass> Cool, so yes now echo works! Thanks a lot
12:09:57PMunchNo problem :)
12:13:33FromDiscord<melmass> sent a code paste, see https://play.nim-lang.org/#pasty=eMJsFgVB
12:15:21PMunchAh, that's because it's a distinct ptr
12:16:13PMunchTry doing the `object of X` thing the manual works instead
12:19:13FromDiscord<melmass> Great, I'll actually re-read the whole readme now that you helped solve a few blockers, not sure where I picked up this actually I had this missing line too.`converter toBase(c: FbxScene): ptr ufbxscene = cast[ptr ufbxscene](c)`
12:27:34PMunchIf you find anything in the README which is unclear I'd love PRs to fix it
12:27:37FromDiscord<planetis_m> FbxScene {.borrow: `.`.}
12:27:56FromDiscord<planetis_m> (edit) "{.borrow: `.`.}" => "`{.borrow: `.`.}`"
12:28:09FromDiscord<planetis_m> (edit) "FbxScene `{.borrow: `.`.}`" => "sent a code paste, see https://play.nim-lang.org/#pasty=sraJedDO"
12:28:54FromDiscord<planetis_m> Wait its ptr so it doesn't have any fields
12:30:29FromDiscord<melmass> hello planetis! I picked up nim back thanks to your naylib library πŸ™‚β†΅Ideally these bindings could allow loading fbx in it
12:30:31FromDiscord<planetis_m> sent a code paste, see https://play.nim-lang.org/#pasty=zQHkuGUr
12:30:39FromDiscord<planetis_m> (edit) "https://play.nim-lang.org/#pasty=spRZvCip" => "https://play.nim-lang.org/#pasty=qqTonLSt"
12:31:03FromDiscord<planetis_m> Hi, good to hear
12:33:30FromDiscord<planetis_m> That would be a great addition indeed. Though I m not familiar with anything 3d
12:34:53FromDiscord<melmass> It was a great way to get back to nim, I implemented hcamera.h and the first person sample
12:39:27FromDiscord<melmass> Cool so yes rebuild was my main issue :facepalmdouble: https://media.discordapp.net/attachments/371759389889003532/1254777911341486201/image.png?ex=667aba7e&is=667968fe&hm=78ef8a8444e5c91139f566b7918295303d0925a3f367ccd01a6db3d33027d5e7&
12:40:16FromDiscord<melmass> Thanks for the help πŸ––
12:42:01FromDiscord<melmass> In reply to @PMunch "If you find anything": I had to read it multiple times at different stage of "understanding" but it feels complete imo, I would probably point out the test folder that contain nice samples too
12:42:37FromDiscord<melmass> And yes that rebuild/cache thing!!
12:42:52FromDiscord<melmass> cc @pmunch ☝️
12:44:00FromDiscord<melmass> nvm it's there πŸ˜…
12:44:33FromDiscord<melmass> But maybe a table of futhark defines with what they do
12:45:07FromDiscord<sOkam! 🫐> @pmunch consider making the non-cached option the default. its very unintutive to compile the code and not get the lib recompiled πŸ€·β€β™‚οΈ
12:46:20FromDiscord<sOkam! 🫐> when you are confident you can always add the cached option back in, and stay pinned to that version until you trigger a rebuild. but it won't confuse beginners (it did trip me too, literally one of the first things I did was add the non-cached flag to my buildsystem)
12:46:53FromDiscord<melmass> What the way now? config.nims?
12:46:55PMunchI mean it should rebuild as long as you change something on the Nim side
12:47:08PMunchIf you change something on the C side however it won't trigger a rebuild
12:47:46FromDiscord<sOkam! 🫐> In reply to @melmass "What the way now?": yeah in whatever buildsystem config options you are using
12:47:48PMunchIf not then there is something wrong with the hashing logic..
12:47:58FromDiscord<sOkam! 🫐> if you are using nimble to build your test project, then yes it would work with config.nims
12:56:55FromDiscord<melmass> In reply to @heysokam "yeah in whatever buildsystem": I'm just using basic scripts for now or nimble tasks, but discovered nims that I feel fit better
13:04:09*smlckz left #nim (WeeChat 4.3.1)
13:13:15FromDiscord<melmass> sent a code paste, see https://play.nim-lang.org/#pasty=xQisDuzr
13:50:00FromDiscord<ieltan> In reply to @melmass "Not sure how idiomatic": unless `ufbx_free_scene` checks for nil, you risk a use-after-free there, so you gotta check for nil in the destructor
13:52:26FromDiscord<melmass> sent a code paste, see https://play.nim-lang.org/#pasty=VFTGQaRl
14:05:46FromDiscord<ieltan> In reply to @melmass "I'm doing the check": well you can keep the nil check and add one in the destructor too, because the object could be moved in another proc and it's now nil but i am not sure if Nim calls destructors for moved objects (i think it doesn't but again im not sure)
14:08:24FromDiscord<ieltan> sent a code paste, see https://play.nim-lang.org/#pasty=wzbhcvFH
14:08:32FromDiscord<ieltan> (edit) "https://play.nim-lang.org/#pasty=PSWiSJmM" => "https://play.nim-lang.org/#pasty=fxPszBzt"
14:11:47FromDiscord<ieltan> whoosp the sign was on the wrong side
14:13:08*PMunch quit (Quit: Leaving)
14:16:11FromDiscord<Robyn [She/Her]> In reply to @ieltan "also you need theses": You only need to define it for `=copy`, `=dup` uses `=copy`
14:28:13FromDiscord<planetis_m> In reply to @chronos.vitaqua "You only need to": dup is an optimization of copy. It defaults to cp if not found
14:30:19FromDiscord<planetis_m> In reply to @ieltan "well you can keep": That's exactly the reason why you need the nil check in the destructor
14:32:33FromDiscord<ieltan> In reply to @planetis_m "That's exactly the reason": ok, i wasnt sure that's why i said it doesn't but glad to know i havent gone totally senile
14:32:45FromDiscord<ieltan> (edit) "In reply to @planetis_m "That's exactly the reason": ok, i wasnt sure that's why i said it doesn't ... but" added "destroy it"
14:48:57FromDiscord<planetis_m> You can verify this easily with --expandarc:myproc
15:06:42FromDiscord<Robyn [She/Her]> In reply to @planetis_m "dup is an optimization": You still only need to define `=copy`, I know this because I did that in my code and when it tries using `=dup`, it said it couldn't since `=copy` errored :p
15:07:12FromDiscord<Robyn [She/Her]> Something something inferred `=dup` couldn't be used because `=copy` something something
15:09:55FromDiscord<ieltan> @Robyn [She/Her] I would still do the two hooks for completeness, I also don't like those implicit rules it's kind of confusing at first so..
15:10:05*lucasta joined #nim
15:10:09FromDiscord<ieltan> but it's nice to know
15:10:31FromDiscord<ieltan> In reply to @planetis_m "You can verify this": totally forgot about that, thanks pal
15:11:24FromDiscord<Robyn [She/Her]> In reply to @ieltan "<@524288464422830095> I would still": Fair point
15:12:49FromDiscord<mratsim> `=dup`? I must have been writing Nim code in a cave for a while. What does that do?
15:23:27FromDiscord<ieltan> In reply to @mratsim "`=dup`? I must have": its documented there: https://nim-lang.org/docs/destructors.html#lifetimeminustracking-hooks-nimeqdup-hook↡basically i think it's optimizing `wasMoved`
15:36:54*derpydoo joined #nim
15:42:44NimEventerNew thread by Mrokii: Error: cannot open file: x11, see https://forum.nim-lang.org/t/11836
15:55:45*derpydoo quit (Ping timeout: 268 seconds)
16:00:12*SEP_ quit (Ping timeout: 252 seconds)
16:02:14*SEP joined #nim
16:25:31*def- quit (Quit: -)
16:25:48*SEP_ joined #nim
16:26:25*def- joined #nim
16:28:44*SEP quit (Ping timeout: 268 seconds)
16:37:39*derpydoo joined #nim
16:48:50*lucasta quit (Quit: Leaving)
17:00:37*coldfeet joined #nim
17:03:08*SchweinDeBurg quit (Quit: WeeChat 4.4.0-dev)
17:05:38*disso-peach joined #nim
18:20:08*coldfeet quit (Remote host closed the connection)
18:36:26*PMunch joined #nim
18:38:05*derpydoo quit (Quit: derpydoo)
19:39:49*Lord_Nightmare quit (Quit: ZNC - http://znc.in)
19:42:12*Lord_Nightmare joined #nim
20:23:20*ntat quit (Quit: Leaving)
20:27:49*PMunch quit (Quit: leaving)
21:06:29FromDiscord<Elegantbeef> Wait I'm not, news to me↡(@demotomohiro)
21:34:17FromDiscord<Robyn [She/Her]> https://play.nim-lang.org/#pasty=BCcbZrAd I am so confused on why this is always returning 0
21:36:10FromDiscord<Robyn [She/Her]> It's a basic ratelimiter and it should be returning a positive number (the amount of time to wait before retrying) if the cooldown has been hit
21:39:23FromDiscord<Elegantbeef> Cause you return `0` in all branches except over hits
21:40:01FromDiscord<Elegantbeef> It's much cleaner if you write it like so https://play.nim-lang.org/#pasty=qGJceXyJ
21:51:24FromDiscord<Robyn [She/Her]> That's still returning 0 everywhere
21:51:36FromDiscord<Elegantbeef> Never said I fixed the logical error πŸ˜›
21:53:18FromDiscord<Robyn [She/Her]> Pain
21:53:44FromDiscord<Robyn [She/Her]> Even in the branch where the hits are over the max it returns 0 and I'm confuseddd
21:54:01FromDiscord<Elegantbeef> cache `now()`
21:54:23FromDiscord<Elegantbeef> Reduce variance inbetween logic
21:55:09FromDiscord<Robyn [She/Her]> I could use `limit.lastAccessed`
21:57:44FromDiscord<Robyn [She/Her]> I think I understand the issue now
21:58:58FromDiscord<Elegantbeef> Also you can remove the `ref object` if you just use one `addr`
21:59:34FromDiscord<Robyn [She/Her]> In line 26?
21:59:48FromDiscord<Elegantbeef> Yea
22:00:11FromDiscord<Elegantbeef> It also means you can do `discard limiter[endpoint].hasKeyOrPut(uid, Limit(...))`
22:00:16FromDiscord<Elegantbeef> Without heap allocating every call
22:00:44FromDiscord<Elegantbeef> Though the if's lazy evaluation is probably better
22:09:10FromDiscord<Robyn [She/Her]> God I am so fucking confused why this isn't working
22:19:53FromDiscord<Robyn [She/Her]> I'm just going to give up on this for now ._.
22:20:59FromDiscord<Elegantbeef> Breakpoint debugging is a wonderful thing
22:24:18FromDiscord<Robyn [She/Her]> I should use it yes yes, but also I'm tired-