<< 04-01-2024 >>
00:00:57*flouer joined #nim
00:01:44*flouer_ quit (Remote host closed the connection)
00:10:56*khazakar quit (Quit: Connection closed for inactivity)
00:12:42FromDiscord<luteva> if it really is threadsafe, use '{.gcsafe.}' otherwise use "--threads:off" if you would like to use only one thread. 🙂
00:18:19FromDiscord<Robyn [She/Her]> In reply to @isofruit "Note: This gets a": Wish we didn't have to do `{.gcsafe.}` tbh
00:24:29NimEventerNew thread by emg: #pragma pack(push, n) equivalent for Nim Objects, see https://forum.nim-lang.org/t/10845
00:26:42*khazakar joined #nim
00:27:38FromDiscord<Elegantbeef> You have to `{.cast(gcSafe).}:` around it, the compiler is not overly smart
00:41:51*jmdaemon joined #nim
01:08:06FromDiscord<Robyn [She/Her]> Is there a way to declare globals as gcsafe, somehow? :p
01:08:10FromDiscord<Robyn [She/Her]> Certain globals
01:08:41FromDiscord<Elegantbeef> Nope
01:15:46FromDiscord<Robyn [She/Her]> Damn
01:16:32FromDiscord<Robyn [She/Her]> I wonder if it's possible to overload `.` in a way that most field/method access code is unaffected unless there's a specific pragma on a variable
01:16:35FromDiscord<Robyn [She/Her]> It's probably possible
01:16:47FromDiscord<Robyn [She/Her]> In reply to @chronos.vitaqua "I wonder if it's": I'd imagine this would be a macro or template
01:17:16FromDiscord<Robyn [She/Her]> Probably macro because you need to check if a symbol has a pragma attached, right?
01:19:14FromDiscord<Elegantbeef> there is the experimental dot operators
01:19:17FromDiscord<Elegantbeef> you could use a concept
01:19:24FromDiscord<Elegantbeef> But remember they only are used if everything falls through
01:24:19FromDiscord<Robyn [She/Her]> How would I use a concept for this, exactly?
01:24:31FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "But remember they only": Fair
01:27:45FromDiscord<Elegantbeef> sent a code paste, see https://paste.rs/UmFlv
01:28:00FromDiscord<Robyn [She/Her]> Not sure about how I'd specifically implement the thing but I have an idea for it, thanks! Definitely interesting-
01:41:18FromDiscord<charlie_charlie6557> sent a long message, see <!doctype html>
01:41:25FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
01:41:26FromDiscord<charlie_charlie6557> (edit)
01:41:26FromDiscord<Phil> (edit)
01:42:07FromDiscord<scipio_nl> In reply to @chronos.vitaqua "Not sure about how": "_ I don't know what it means but it sounds provocative_"
01:45:26FromDiscord<Robyn [She/Her]> In reply to @scipio_nl ""_ I don't know": No I understand what's happening, I suggested using a pragma or something to indicate a variable is gcsafe, then you'd have to implement a dot operator overload so you can check if a var is declared as gcsafe and stuff
01:48:57FromDiscord<scipio_nl> In reply to @chronos.vitaqua "No I understand what's": I understood you understand.
01:53:39FromDiscord<Robyn [She/Her]> Oh
01:53:55FromDiscord<Robyn [She/Her]> I didn't understand that message you sent then :p
01:53:56FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=html>
01:54:26FromDiscord<Elegantbeef> `field: untyped`
01:54:29FromDiscord<Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#ix=html>
01:54:43FromDiscord<Robyn [She/Her]> Also that's actually pretty nice-
01:55:04FromDiscord<scipio_nl> In reply to @chronos.vitaqua "I didn't understand that": It's a meme 😁
01:55:23FromDiscord<Elegantbeef> There we go seeya is now a nimble package that libnimib now depends on, I'm making silliness somewhat consumable
01:55:47FromDiscord<albassort> i would like a mutable object
01:55:52FromDiscord<albassort> that i can copy
01:56:01FromDiscord<albassort> ref objects copy as refs
01:56:10FromDiscord<albassort> i just wanna preserve the state
01:56:54FromDiscord<Elegantbeef> https://github.com/beef331/libnimib/blob/master/include/nimib.h What a nicely generate header file
02:00:49FromDiscord<albassort> actually
02:00:55FromDiscord<albassort> no i want to copy a ref object
02:01:32FromDiscord<Elegantbeef> You used to be able to do `deepCopy` but that's now behind a flag
02:01:56FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=html>
02:02:41FromDiscord<albassort> yeah but thats nasty
02:02:54FromDiscord<albassort> In reply to @Elegantbeef "You used to be": why is deepcopy now banned
02:02:56FromDiscord<spacelucy> sent a code paste, see https://play.nim-lang.org/#ix=html>
02:03:35FromDiscord<Elegantbeef> `parseJson` does not take in a `Future[string]`
02:03:42FromDiscord<Elegantbeef> your await needs to be inside `parseJson` not outside it
02:03:56FromDiscord<spacelucy> oh I see
02:03:59FromDiscord<albassort> specifically the part of the stack
02:04:03FromDiscord<albassort> sent a code paste, see https://play.nim-lang.org/#ix=html>
02:04:06FromDiscord<albassort> you're looking for that
02:04:22FromDiscord<Elegantbeef> Well also `Future[system.string]`
02:04:40FromDiscord<Elegantbeef> Real shame that Araq did not like my idea of storing all macros pre-expansion
02:04:44FromDiscord<albassort> (edit)
02:04:47FromDiscord<Elegantbeef> Made error messages much more readable
02:05:14FromDiscord<albassort> yeah but you also don't get to see whats actually happening to your code
02:05:25FromDiscord<Elegantbeef> Only in error messages
02:05:31FromDiscord<Elegantbeef> `expandMacros` and the like would still work
02:05:40FromDiscord<albassort> i've never heard of expandMacros
02:05:48FromDiscord<albassort> i have heard and seen deepcopy tho
02:05:50FromDiscord<albassort> what happened with that
02:06:04FromDiscord<Elegantbeef> It's a macro in `std/macros` and a flag of `--expandMacro:...`
02:06:08FromDiscord<Elegantbeef> No clue deep copy is ugly
02:06:10FromDiscord<Robyn [She/Her]> In reply to @scipio_nl "It's a meme 😁": Ooh
02:06:31FromDiscord<albassort> sent a code paste, see https://play.nim-lang.org/#ix=html>
02:06:34FromDiscord<albassort> this is uglier
02:06:51FromDiscord<Elegantbeef> Imagine of Nim had procs
02:07:03FromDiscord<albassort> >:(
02:07:06FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "Real shame that Araq": Why was that denied? Redundancy?
02:07:23FromDiscord<spacelucy> why?
02:07:27FromDiscord<Robyn [She/Her]> I feel like not focusing on improving Nim's error messages is kinda counterintuitive to making people more willing to use Nim
02:07:28FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=html>
02:07:34FromDiscord<albassort> In reply to @spacelucy "why?": because thats the actual type error
02:07:45FromDiscord<albassort> the type error is that its not getting a Future[string]
02:07:53FromDiscord<spacelucy> whats the difference between string and system.string
02:08:00FromDiscord<Robyn [She/Her]> They're the same thing
02:08:02FromDiscord<albassort> none its just specific to where it came from
02:08:07FromDiscord<Robyn [She/Her]> system is just the module string comes from
02:08:09FromDiscord<albassort> system is the pacakge
02:08:13FromDiscord<albassort> (edit) "pacakge" => "module"
02:08:15FromDiscord<spacelucy> OH
02:08:17FromDiscord<spacelucy> misread
02:08:18FromDiscord<spacelucy> sorry
02:08:20FromDiscord<spacelucy> yeah
02:08:20FromDiscord<Robyn [She/Her]> And system is the built-in module
02:08:25FromDiscord<Robyn [She/Her]> You're good, no worries!
02:08:50FromDiscord<Elegantbeef> https://github.com/nim-lang/Nim/pull/20183 robyn
02:09:42FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=html>
02:10:32FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=html>
02:10:36FromDiscord<Elegantbeef> Atleast better than that
02:10:42*xet7 joined #nim
02:12:30FromDiscord<girvo> In reply to @luteva "if it really is": It's multi-threaded embedded code 🥲
02:12:37FromDiscord<albassort> In reply to @girvo "It's multi-threaded embedded code": hot
02:12:53FromDiscord<Robyn [She/Her]> sent a code paste, see https://play.nim-lang.org/#ix=html>
02:13:03FromDiscord<albassort> i mean
02:13:10FromDiscord<Robyn [She/Her]> In reply to @girvo "It's multi-threaded embedded code": Did you see the neat thing beef came up with? :p
02:13:12FromDiscord<albassort> my brain has pathways developed just to read nim errors
02:13:20FromDiscord<albassort> so idrc
02:13:23FromDiscord<Robyn [She/Her]> Async code is a pain bc of the errors :p
02:13:38FromDiscord<Robyn [She/Her]> In reply to @albassort "my brain has pathways": I'm also semi-used to it, tbf, but it'd be a nice improvement either way
02:13:59FromDiscord<albassort> it was a bit tongue in cheek
02:13:59FromDiscord<Elegantbeef> Right you have to learn to understand Nim errors, but there is no reason to have to sift through a macro expansion when the error is you added `discard`
02:14:47FromDiscord<Robyn [She/Her]> Yeah, exactly
02:15:20FromDiscord<Robyn [She/Her]> Why could that make the compiler more difficult to expand upon? Hm
02:15:32FromDiscord<Robyn [She/Her]> Assuming Araq hasn't changed his opinions on this either?
02:15:41FromDiscord<Elegantbeef> Don't ask me I hardly ever argue with Araq cause it's a fool's errand
02:15:58FromDiscord<Robyn [She/Her]> Fair
02:16:12FromDiscord<albassort> Araq is a man who makes up his mind
02:16:16FromDiscord<albassort> and then thats really it
02:16:22FromDiscord<girvo> In reply to @chronos.vitaqua "Did you see the": not yet, lemme scroll
02:16:25FromDiscord<albassort> until they stumble upon it themselves
02:17:03FromDiscord<girvo> sent a code paste, see https://play.nim-lang.org/#ix=html>
02:17:44FromDiscord<Robyn [She/Her]> Yeah!
02:17:52FromDiscord<Elegantbeef> It also still works with locks! 😄
02:17:58FromDiscord<Robyn [She/Her]> In reply to @albassort "until they stumble upon": Yeaaah- I'm here for the language tbf, sooo-
02:19:44FromDiscord<Elegantbeef> The non expanded macro change is relatively small so on the plus side it's likely not too hard to apply it as a patch 😛
02:19:45FromDiscord<Elegantbeef> Code rendering does not change much
02:20:27FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "The non expanded macro": It is, yeah, soooo I could do that hmmm
02:20:44FromDiscord<Robyn [She/Her]> I wonder if the code you've edited has changed upstream
02:24:02FromDiscord<Elegantbeef> One git merge away
02:24:53FromDiscord<nikhilsimha> Hello nim experts - I have been trying to get nim to top the charts in plb2 (programming language benchmarks). I ran into a weird compiler flag behavior. https://github.com/attractivechaos/plb2/pull/27.
02:26:03FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "One git merge away": https://patch-diff.githubusercontent.com/raw/nim-lang/Nim/pull/20183.patch oooor a patch file :)
02:26:53FromDiscord<Elegantbeef> Correct my ignorance isn't a patch file just a funnily named merge?
02:27:08FromDiscord<Elegantbeef> Nikhil I responded in the post if I understand your confusion properly 😄
02:27:11FromDiscord<Robyn [She/Her]> Aren't merged based on patch files? :p
02:27:35FromDiscord<Robyn [She/Her]> Merges
02:27:41FromDiscord<Elegantbeef> Do I look like someone that knows git vernacular
02:27:58FromDiscord<Robyn [She/Her]> Nope
02:28:34FromDiscord<leorize> a patch file here is just a text version of a commit
02:28:38FromDiscord<nikhilsimha> In reply to @Elegantbeef "Nikhil I responded in": Thanks 🙏 ! I am confused about why -d danger works to speed up the code but the current -d release actually slows down the code. : https://github.com/attractivechaos/plb2/pull/27#issuecomment-1876201746
02:28:49FromDiscord<Elegantbeef> cause `-d:release` has checks on still
02:28:53FromDiscord<Elegantbeef> `-d:danger` turns all checks off
02:28:55FromDiscord<graveflo> In reply to @nikhilsimha "Hello nim experts -": Nim tries to be safe unless checks are turned off. I wouldn't expect tight consistency and 1:1 comparisons when scrutinizing optimizations without building appropriately. Basically: use `danger` if you are actually trying to get peak performance
02:29:07FromDiscord<Elegantbeef> `-d:release` has range checks, overflow, nilchecks, ...
02:29:23FromDiscord<Elegantbeef> you also likely should use `--panics:on`
02:29:48FromDiscord<Elegantbeef> `--panics:off` is default and it impairs optimisation
02:29:57FromDiscord<Elegantbeef> Though with danger off that's unlikely to be a problem
02:30:00FromDiscord<Elegantbeef> danger on\
02:30:44FromDiscord<nikhilsimha> sent a code paste, see https://play.nim-lang.org/#ix=html>
02:30:56FromDiscord<graveflo> nim does all kind of stuff like double checking tons of unnecessary copies (which may or may not get "optimized away") with the safety features turned on
02:31:19FromDiscord<Elegantbeef> I highly suggest using `-d:lto`
02:31:24FromDiscord<Elegantbeef> or `--passL:"-flto"`
02:31:35FromDiscord<Elegantbeef> This eliminates a whole host of optimisation issues due to how Nim compiles
02:32:03FromDiscord<albassort> I've never done inheritance in nim, why cant this proc take in a child type of the root
02:32:23FromDiscord<albassort> sent a code paste, see https://play.nim-lang.org/#ix=html>
02:32:27FromDiscord<Elegantbeef> Are you using references?
02:32:34FromDiscord<Elegantbeef> `var Tile`
02:33:17FromDiscord<albassort> ??
02:33:21FromDiscord<graveflo> is that a `ref ref` or am I nuts
02:33:25FromDiscord<Elegantbeef> No
02:33:31FromDiscord<Elegantbeef> I mean it's a `var ref T`
02:33:31FromDiscord<nikhilsimha> In reply to @Elegantbeef "I highly suggest using": That did the trick!
02:33:34FromDiscord<Elegantbeef> So it's pretty ugh
02:33:53FromDiscord<albassort> no solution?
02:33:54FromDiscord<albassort> :(
02:34:04FromDiscord<Elegantbeef> Drop the `var`
02:34:08FromDiscord<albassort> i dont wanna
02:34:12FromDiscord<albassort> then i gotta do ref
02:34:16FromDiscord<nikhilsimha> In reply to @graveflo "nim does all kind": I am trying to understand preferential behavior towards seq with those specific compiler flags.
02:34:38FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=html>
02:35:21FromDiscord<albassort> n eat
02:35:35FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=html>
02:35:36FromDiscord<Elegantbeef> Also works
02:40:56rockcaveraWhy did this topic disappear? https://forum.nim-lang.org/t/10844
02:41:14rockcaveraI was waiting for an answer to also understand the reason...
02:41:42rockcavera20:42 #   NimEventer | New thread by nsimha: Seq2 vs Unchecked Array performance difference , see https://forum.nim-lang.org/t/10844
02:45:49FromDiscord<nikhilsimha> In reply to @rockcavera "Why did this topic": I wasn’t sure if I was doing something stupid
02:50:01FromDiscord<Elegantbeef> The seq and non seq versions should be fairly similar, I do imagine that it's something like Nim's `=destroy` causing deallocation slow downs making the program overall slower
02:50:25rockcaveranikhilsimha, no question is stupid
02:51:54rockcaveraElegantbeef at the time of refc I had already noticed such slowness when I tried to port wyhash...
02:52:50FromDiscord<Elegantbeef> I mean the code should be almost identical without checks on here
02:52:57FromDiscord<Elegantbeef> So I imagine it's very much destructors
02:53:18FromDiscord<Elegantbeef> inside `deallocMat` properly call `=destroy` on each float element @nikhilsimha
02:57:01FromDiscord<Elegantbeef> It's the only reason I can think that the UncheckedArray is so close to seqs but slightly faster
03:00:02FromDiscord<girvo> In reply to @Elegantbeef "This eliminates a whole": lto can't operate in compileOnly hey 😦
03:00:16FromDiscord<Elegantbeef> Of course not!
03:00:26FromDiscord<girvo> Gosh I wish I could take CMake out back and old yellar it
03:00:35FromDiscord<Elegantbeef> Don't we all
03:01:51FromDiscord<graveflo> I can hardly believe what syntax abominations they dreamed up when making cmake... it's not even old either. Not nearly enough to play that card
03:01:51FromDiscord<girvo> Does -d:lto do anything extra other than enabling -flto?
03:01:59FromDiscord<graveflo> they were smoking something really strong
03:02:01FromDiscord<girvo> In reply to @graveflo "I can hardly believe": Do _not_ get me started lol
03:02:05FromDiscord<Elegantbeef> Nope
03:02:28FromDiscord<Elegantbeef> It's supposed to be compiler agnostic `--passL: "-flto"` but it fails on mac's clang iirc
03:03:54FromDiscord<girvo> Okay sweet
03:04:07FromDiscord<girvo> I'll just bake it into our CMake then and see if it has much benefit
03:04:14FromDiscord<girvo> (for our stuff)
03:04:29FromDiscord<Elegantbeef> It helps a lot of compilers due to the fact Nim makes a module into a file
03:04:44FromDiscord<Elegantbeef> So being able to optimise all of those files together removes many issues
03:04:51FromDiscord<nikhilsimha> In reply to @Elegantbeef "inside `deallocMat` properly call": Good catch! will update
03:05:40FromDiscord<Robyn [She/Her]> Tbf can't you just, use the compile pragma in Nim on C files?
03:05:42FromDiscord<girvo> `idf_build_set_property(COMPILE_OPTIONS -flto APPEND)` man I despise CMake lmao. And ESP-IDF's usage of it, too
03:06:47FromDiscord<graveflo> sent a code paste, see https://play.nim-lang.org/#ix=html>
03:06:58FromDiscord<nikhilsimha> In reply to @Elegantbeef "The seq and non": So is the theory that in this particular setup (release + bounds off) seq gets the speed up but unchecked is 3x slower - because of the way =destroy works? But in matmul i don't call destroy - I call dealloc
03:07:08FromDiscord<Elegantbeef> No
03:07:10FromDiscord<girvo> In reply to @graveflo "I've been on a": #embedded 😄
03:07:18FromDiscord<Elegantbeef> I do not get why it's slower 😄
03:07:36FromDiscord<Elegantbeef> The idea is that with danger that seqs are slower due to not calling `=destroy` in your unchecked
03:07:48FromDiscord<Elegantbeef> The reason ptrs are slower I have 0 clue, you said it was on par with `-d:lto`
03:08:01FromDiscord<nikhilsimha> In reply to @Elegantbeef "The idea is that": gotcha
03:08:18FromDiscord<girvo> In reply to @graveflo "I've been on a": but that honestly looks like you're `logi`-ing a nim `string` -- its gotta be a `cstring` in logi's current definition
03:08:37FromDiscord<girvo> sent a code paste, see https://play.nim-lang.org/#ix=html>
03:09:01FromDiscord<girvo> tbh I'd remove the `string | cstring` and just make it `string` there
03:09:06FromDiscord<graveflo> still happens with that. Maybe I have to do the fancy `let x: cstring = ""` but idk. I think something else is messed up idk
03:09:18FromDiscord<michaelb.eth> sent a code paste, see https://play.nim-lang.org/#ix=html>
03:09:36FromDiscord<graveflo> In reply to @girvo "tbh I'd remove the": I'll try thx
03:09:40FromDiscord<girvo> In reply to @graveflo "still happens with that.": Possibly! Post it in embedded and I'd be happy to take a look?
03:10:14FromDiscord<girvo> But `logi` in general delegates out to `ESP_LOGI` which is a macro that takes N params, etc. etc. its gross lol (through no fault of elcritch, thats just how ESP's logging system operates)
03:10:54FromDiscord<graveflo> yea that's why I took a break. I saw that C macro def and thought.. damn it. Thats just gross
03:11:10FromDiscord<girvo> yeahhhhh haha. Welcome to embedded land 😄
03:12:18FromDiscord<Elegantbeef> The tinyusb macros are absurd
03:12:24FromDiscord<Elegantbeef> Entire DSLs
03:12:54FromDiscord<girvo> Hah yeah. esp_modem also builds a DSL in macros for it's C wrapper layer for it's C++ code...
03:13:15FromDiscord<nikhilsimha> In reply to @Elegantbeef "I do not get": who would know?
03:13:21FromDiscord<Elegantbeef> A profiler
03:13:28FromDiscord<girvo> sent a code paste, see https://play.nim-lang.org/#ix=html>
03:13:56FromDiscord<girvo> sent a code paste, see https://play.nim-lang.org/#ix=html>
03:14:31FromDiscord<girvo> In reply to @nikhilsimha "who would know?": yeah a profiler + examining the disassmbly when you work out where it's slowing down exactly via said profiling
03:14:31FromDiscord<Elegantbeef> I raise you https://github.com/hathach/tinyusb/blob/73896a3b71c525a3ee4cefa7e35ce3b3a93786ef/src/device/usbd.h
03:14:55FromDiscord<girvo> In reply to @Elegantbeef "I raise you https://github.com/hathach/tinyusb/blob": 🤮
03:14:58FromDiscord<graveflo> only an AI deserves to be subjected to reading that
03:15:16FromDiscord<nikhilsimha> In reply to @Elegantbeef "A profiler": fair enough - I am going to see whats happening under a profiler.
03:15:19*azimut_ quit (Ping timeout: 240 seconds)
03:15:34*nyeaa49284230101 quit (Quit: Ping timeout (120 seconds))
03:15:35FromDiscord<Elegantbeef> I lost so much motivation to attempt to wrap tinyusb when I seen the descriptor macros
03:16:32FromDiscord<Elegantbeef> @auxym is clearly a better person than I 😄
03:16:34FromDiscord<girvo> Yeah I feel that. Theres a gcc flag to basically "run" a header
03:16:49FromDiscord<girvo> But that honestly doesn't always make it much better lmao
03:17:09FromDiscord<Elegantbeef> You mean `gcc -e`?
03:17:10FromDiscord<girvo> gcc -E, I think?
03:17:57FromDiscord<Elegantbeef> Yea it runs the preprocessor
03:18:44FromDiscord<Elegantbeef> I was going to replicate their C preprocessor with a Nim macro, but I never did understand what it actually did
03:18:45FromDiscord<girvo> `-dM` does... something useful too, according to my bash history lmao
03:18:57FromDiscord<Elegantbeef> bash history shame on you good sir!
03:19:07FromDiscord<Elegantbeef> I put the `sh` in shaming
03:19:20FromDiscord<girvo> Look I'm forced to use Windows with default Ubuntu on WSL2 😭
03:19:37FromDiscord<graveflo> imagine not using fish
03:19:55FromDiscord<Elegantbeef> I'm with grave
03:20:00FromDiscord<graveflo> I only said that bc I figure it would be annoying
03:20:18FromDiscord<girvo> lmao
03:20:49FromDiscord<Elegantbeef> My friend recently installed linux to do some programming stuffs and one of the first things I did was get him on fish
03:20:58FromDiscord<Elegantbeef> Friends do not let friends use bad shells
03:21:32FromDiscord<graveflo> I tried using zsh for about 2 months. The time I wasted looking up config file bs
03:21:37FromDiscord<graveflo> I will never get it back
03:21:46FromDiscord<Elegantbeef> I use stock fish
03:21:54FromDiscord<Elegantbeef> I installed it and `chsh`
03:22:32FromDiscord<Elegantbeef> Wait no stockfish is a chess thing!
03:22:45FromDiscord<girvo> hahaha
03:22:46FromDiscord<graveflo> what a blunder
03:22:49FromDiscord<girvo> !!!
03:22:54FromDiscord<Elegantbeef> More of a flounder
03:22:59FromDiscord<girvo> daaaaaaad
03:23:02FromDiscord<girvo> we talked about this
03:23:10FromDiscord<Elegantbeef> You're older than me, shut up son
03:23:14FromDiscord<girvo> 😄
03:23:59FromDiscord<demotomohiro> In reply to @girvo "Does -d:lto do anything": `-d:lto` is implemented here: https://github.com/nim-lang/Nim/blob/devel/config/nim.cfg#L328
03:24:26FromDiscord<Elegantbeef> Demo being more helpful than me as always
03:24:47FromDiscord<girvo> yeah so flto=auto in the CMake will work, cheers!
03:25:29FromDiscord<Elegantbeef> Girvo you do not do Nim -\> C do you?
03:25:40FromDiscord<Elegantbeef> I mean using Nim code from C
03:26:41FromDiscord<girvo> Nah we don't
03:26:46FromDiscord<girvo> Nim controls and runs the lot
03:26:58FromDiscord<girvo> sent a code paste, see https://play.nim-lang.org/#ix=html>
03:27:07FromDiscord<girvo> with -flto=auto haha
03:27:29FromDiscord<girvo> I'm guessing because of the linker scripts and hard linker mappings that embedded does
03:27:45FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "I installed it and": Same :p
03:27:55FromDiscord<Elegantbeef> Ah shame I wanted a guinea pig for seeya 😄
03:28:46FromDiscord<Robyn [She/Her]> In reply to @girvo "Nah we don't": 'We', you say? 👀
03:28:47FromDiscord<girvo> hahaha well I'll have a look! It's probable we'll end up going down that path as we have an STM32 firmware now that's controlling our NB-IoT modems, that's in C. If it could call some our Nim code...
03:29:07FromDiscord<Elegantbeef> Girvo means we as a collective group of people working on a team
03:29:10FromDiscord<Elegantbeef> Not wea like you
03:29:12FromDiscord<Elegantbeef> we\
03:29:15FromDiscord<girvo> ^^
03:29:23FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "Not wea like you": Didn't think that
03:29:28FromDiscord<girvo> We have a team yeah 🙂
03:29:31FromDiscord<Elegantbeef> https://github.com/beef331/seeya/blob/master/tests/mylib.nim↵https://github.com/beef331/seeya/blob/master/tests/mylib.h
03:29:40FromDiscord<Robyn [She/Her]> Just thought 'we' was pretty unusual in this context so was curious
03:29:42FromDiscord<Robyn [She/Her]> But neat!
03:29:43FromDiscord<Elegantbeef> Look girvo generated C headers!
03:29:50FromDiscord<Elegantbeef> Ah sorry 😄
03:29:52FromDiscord<girvo> You see @charlie_charlie6557 in here every so often, and there's one other on the embedded team directly!
03:29:59FromDiscord<girvo> ooooooh!
03:30:28FromDiscord<Elegantbeef> And you can look at `test.c` for a raw usage
03:30:29FromDiscord<girvo> Okay that is awesome
03:31:19FromDiscord<Elegantbeef> I am dogfooding it with my libnimib experiment, but I did want to consider other things
03:31:21FromDiscord<girvo> Is it dependant on clang?
03:31:44FromDiscord<Elegantbeef> No I only use string concatenation
03:31:50FromDiscord<girvo> Oh neat 🙂
03:31:54FromDiscord<Elegantbeef> It happens all at CT in Nimscript cause I'm a fuckwit
03:32:04FromDiscord<girvo> hahaha
03:32:15FromDiscord<Elegantbeef> Also so you can easily plug things like `headers.incl "someheader.h"`
03:32:18FromDiscord<girvo> Okay I'll set it up and have a tinker! This would actually be useful now that we're moving some responsibilities to other code
03:32:21FromDiscord<Robyn [She/Her]> Aren't you supposed to use ropes for stuff like that? Or am I mistaken?
03:32:40FromDiscord<Elegantbeef> You can use ropes but they generally are not worth it
03:32:43FromDiscord<Robyn [She/Her]> I forgot how std/ropes work again
03:32:54FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "You *can* use ropes": Why aren't they? More of a pita to work with?
03:33:20FromDiscord<Elegantbeef> Pretty much
03:33:35FromDiscord<Elegantbeef> Also not much better performance wise
03:34:02FromDiscord<Robyn [She/Her]> Isn't it better for memory because less copying?
03:34:10FromDiscord<girvo> Depends on the use case
03:34:15FromDiscord<Robyn [She/Her]> Fair
03:34:17FromDiscord<Elegantbeef> If you have many duplicate leafs
03:34:37FromDiscord<Robyn [She/Her]> Fair enough
03:34:51FromDiscord<girvo> String algorithms in general are fascinating
03:35:43FromDiscord<Robyn [She/Her]> Fair, I don't know anything about them personally
03:35:43FromDiscord<girvo> Ropes, gap buffers, etc
03:35:50FromDiscord<girvo> piece tables
03:35:56FromDiscord<Robyn [She/Her]> Gap buffers? Piece tables?
03:35:58FromDiscord<Elegantbeef> This is also running on the VM so using ropes there seems a bit silly
03:36:18FromDiscord<Robyn [She/Her]> Fair
03:36:37FromDiscord<girvo> sent a long message, see <!doctype html>
03:36:45FromDiscord<Elegantbeef> I was thinking this could be plugged in a way to support multiple backends.... one day 😄
03:37:04FromDiscord<Elegantbeef> Export your code to Zig, Rust, Odin, .... all in one go! 😛
03:37:29FromDiscord<girvo> In reply to @Elegantbeef "Export your code to": Imagine! 😄
03:37:32FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "I was thinking this": For headers/bindings only, right?
03:37:39FromDiscord<Elegantbeef> Right
03:37:45FromDiscord<Robyn [She/Her]> In reply to @girvo "https://en.wikipedia.org/wiki/Gap_buffer https://e": Neat!
03:38:06FromDiscord<Robyn [She/Her]> I should see if I get the energy to yoink Seeya's code for use in a backend for another language again
03:38:39FromDiscord<Elegantbeef> I mean it only emits typedefs
03:38:51FromDiscord<Elegantbeef> It's not a transpiler
03:39:57*tiorock joined #nim
03:39:57*tiorock quit (Changing host)
03:39:57*tiorock joined #nim
03:39:57*rockcavera is now known as Guest786
03:39:57*Guest786 quit (Killed (erbium.libera.chat (Nickname regained by services)))
03:39:57*tiorock is now known as rockcavera
03:40:34FromDiscord<Robyn [She/Her]> Yeah but you have a code structure I can yank-
03:40:36FromDiscord<Elegantbeef> You annotate procedures or variables with expose it and it generates(most) types and the procedures
03:40:38FromDiscord<Elegantbeef> Inheritance is not presently handled though
03:40:38FromDiscord<Elegantbeef> Though it's just a `parent` iirc
03:41:25FromDiscord<Elegantbeef> Not for transpiling code
03:41:26FromDiscord<Elegantbeef> It's explicitly just procedures that return strings
03:41:52FromDiscord<Robyn [She/Her]> Fair enough
03:42:00FromDiscord<Robyn [She/Her]> I'll probably still yoink it :p
03:43:38FromDiscord<Elegantbeef> image.png https://media.discordapp.net/attachments/371759389889003532/1192312359709065326/image.png?ex=65a89e6a&is=6596296a&hm=a7f153596cc95f0887f155f34b6556163d40c21b27a54fbbc859857be63c7bfe&
03:43:41FromDiscord<Elegantbeef> Well I cannot stop you
03:43:47FromDiscord<Elegantbeef> But good luck doing anything useful there
03:44:44*edr quit (Quit: Leaving)
03:49:23*Batzy joined #nim
03:52:47*Batzy_ quit (Ping timeout: 264 seconds)
04:22:24FromDiscord<spacelucy> is it possible to view the compiled C code before it gets compiled to a binary?
04:22:57FromDiscord<Elegantbeef> You can always use `--nimCache` to set where the C is pooped out then use the json task iirc
04:23:05FromDiscord<Elegantbeef> I do not recall how to do that really though
04:24:22FromDiscord<spacelucy> oh its in .cache/nim
06:26:59FromDiscord<spacelucy> how can I get the username of the current user?
06:27:08FromDiscord<spacelucy> i'm not finding much information for this
06:29:50*rockcavera quit (Remote host closed the connection)
06:31:44FromDiscord<intellij_gamer> If you are on Linux then getting the `USER` env variable should do it iirc
06:32:49FromDiscord<huantian> std/posix also provides `getlogin` from unistd.h↵https://nim-lang.org/docs/posix.html#getlogin
06:33:32FromDiscord<huantian> (edit) "std/posix also provides `getlogin` ... from" added "and `getlogin_r`"
06:39:18FromDiscord<spacelucy> what is a cstring↵(@huantian)
06:41:18FromDiscord<spacelucy> actually, this works good, thanks↵(@intellij_gamer)
06:50:09FromDiscord<demotomohiro> `cstring` is a `char` in C.
06:50:27FromDiscord<demotomohiro> `char` is a `string` in C.
06:58:36FromDiscord<spacelucy> oh
07:18:38*PMunch joined #nim
07:19:21*advesperacit joined #nim
07:31:02*wheatengineer joined #nim
08:13:10Amun-RaI think * are filtered out in irc bridge
08:14:34PMunchNo they're not
08:14:44Amun-Rahmm
08:14:56PMunchOh wait, you're also an IRC :P
08:15:02FromDiscord<pmunch> Test star
08:15:10PMunchAh, yup
08:15:20Amun-Ra"pmunch | Test star"
08:15:22PMunchI think it's because it tries to parse Markdown
08:15:40Amun-Rathere was something wrong with "`cstring` is a `char` in C." ;)
08:16:14PMunchHaha, yeah that can get confusing fast
08:16:39FromDiscord<pmunch> Does it handle it in `inline code blocks`?
08:16:44PMunchHuh, not even there
08:17:03Amun-Raoh
08:17:25PMunchThat's strange
08:21:37FromDiscord<nnsee> how about \ this?
08:21:54FromDiscord<nnsee> or even \\ this
08:22:25PMunchNope, that got turned into one and two backslashes respectively
08:27:48Amun-Ra`foo` - what about backticks?
08:27:54FromDiscord<nnsee> that's messed up
08:29:58FromDiscord<nnsee> char ∗ foo
08:30:28Amun-Rahttps://ibb.co/tZKntt9
08:30:44Amun-Ra(§ marks nicks from proxy)
09:47:59NimEventerNew thread by aiac: How to get pragma of the field in macro?, see https://forum.nim-lang.org/t/10846
10:43:56Amun-Ranice: https://xuanwo.io/2023/04-rust-std-fs-slower-than-python/
10:56:32FromDiscord<gyatsoyt> hey there i am starting out in nim and i want to know that in python there are bitwise operater like bitwise or(|) and bitwise left shift(<<). what are the alternatives for these in nim
10:58:11PMunch`or` and `shl`
10:58:51Amun-Ranim uses and/or for binary and logical operations depending on context
11:00:26Amun-Raafter writing a lot of code in nim I wrote a few times "if x or 1:" in python… ;)
11:02:23*arkanoid joined #nim
11:02:27arkanoidhello
11:08:57PMunchHi :)
11:10:55FromDiscord<mratsim> In reply to @gyatsoyt "hey there i am": Nim prefers full names instead of symbols, because they are hard to grep.
11:14:21FromDiscord<ezquerra> How can you check at compile time that the memory management mode is arc or orc?
11:15:01FromDiscord<pmunch> `when defined(arc) or defined(orc)`
11:15:28FromDiscord<ezquerra> thank you!
11:16:50PMunchI think that'll work
11:21:25Amun-Raalso: compileOption
11:22:04FromDiscord<gyatsoyt> sent a code paste, see https://play.nim-lang.org/#ix=html>
11:23:34Amun-Rahttps://play.nim-lang.org/#ix=l%3E%3C
11:23:37Amun-Rahmm, weird
11:24:12Amun-Rait failed to create a share link
11:24:28Amun-Rawhen compileOption("mm", "arc") or compileOption("mm", "orc"): …
11:27:54FromDiscord<ezquerra> Thanks
11:28:12PMunchAmun-Ra, yeah ix.io is down so paste links don't work atm
11:28:53Amun-RaI see, thanks
11:29:01PMunch@gyatsoyt, add an export marker after `PIECES` and it should work
11:29:12FromDiscord<ezquerra> Another, unrelated question that I've been wondering lately. Sometimes I have a variable that I need to modify at the beginning of a procedure (e.g. I need to calculate it's value in some complex way or something like that) but which then I. Is there a way to "mark" a value as "let" at a certain point.
11:29:26FromDiscord<ezquerra> (edit) "I. Is there a way" => "I'd like" | ""mark" a value" => "mark" | ""let" at a certain point." => ""constant""
11:29:27PMunchKeep in mind though that this is a string array, you might be interested in using an enum instead
11:29:35FromDiscord<ezquerra> as if it had been defined "let"
11:29:38FromDiscord<ezquerra> Is there a way to do that?
11:30:07PMunchNot really, but you can use a block statement to assign it to a let
11:30:20FromDiscord<ezquerra> How so?
11:30:46FromDiscord<ezquerra> I
11:31:03FromDiscord<Phil> In reply to @ezquerra "Another, unrelated question that": use blocks
11:31:20FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
11:31:30FromDiscord<Phil> (edit)
11:31:34PMunchhttps://paste.rs/Gf2xt.txt
11:31:51PMunchAh, you beat it to me Phil :P
11:31:56FromDiscord<Phil> Too slow 😛
11:32:12FromDiscord<gyatsoyt> In reply to @PMunch "<@805119221091926027>, add an export": THIS RIGHT
11:32:15FromDiscord<Phil> But yeah, blocks are one of those insanely nice features for when you don't want to outsource into a new proc
11:32:25FromDiscord<Phil> But still want a type of complex assignment
11:32:28FromDiscord<gyatsoyt>
11:32:53FromDiscord<Phil> And yes
11:32:56FromDiscord<Phil> That is the export sign
11:33:28FromDiscord<Phil> Alternatively you can write `export PIECES` but typically nobody does that, it's more of a crutch for when you want to export a symbol but it gets generated
11:33:30FromDiscord<ezquerra> Thanks. That is pretty nice indeed
11:33:34FromDiscord<gyatsoyt> ty it works
11:33:54FromDiscord<Phil> (edit) "Alternatively you can write `export PIECES` but typically nobody does that, it's more of a crutch for when you want to export a symbol but it gets generated ... " added "and thus you can't directly modify it"
11:35:40FromDiscord<ezquerra> I guess what I want would be pretty hard to implement. I was thinking of having a way to tell the compiler that at some point I am done updating a certain variable, and any further updates should be a compilation error. That seems simple for "linear" code, but as soon as you have branches then it would not work...
11:36:36PMunchYeah, that's why these blocks come in so handy :)
11:36:38FromDiscord<gyatsoyt> well it doesnt
11:36:42FromDiscord<Phil> In reply to @ezquerra "I guess what I": That sounds mostly like you should have a proc for instantiation and figure out how to put all logic inside of it
11:37:02FromDiscord<ezquerra> I guess so
11:37:22FromDiscord<ezquerra> You can of course just do `let my_constant_value = value` but then it is your responsibility to never use `value` again
11:37:43FromDiscord<pmunch> Another way would be to flip it and make everything after the initialisation logic into a block and shadow the variable
11:38:50FromDiscord<ezquerra> sent a code paste, see https://play.nim-lang.org/#ix=html>
11:39:19FromDiscord<pmunch> Yes, pretty much
11:39:21*azimut joined #nim
11:39:27FromDiscord<pmunch> sent a code paste, see https://play.nim-lang.org/#ix=html>
11:39:38FromDiscord<ezquerra> That's pretty neat
11:39:52PMunchOf course you now have an extra level of indentation
11:40:02PMunchBut you could shadow more than one variable like this
11:40:29PMunchCould of course also be adapted to a template
11:40:32PMunchOr macor
11:41:05PMunchSo you could do `freeze(myVar):` and that would add these shadowing let statements for all the listed variables
11:41:34FromDiscord<ezquerra> Yes, overall it is a pretty nice solution, although it would be cool to be able to do something like: `let value {.shadow.} = value` at some point in a procedure but as I said then you have problems with branckes, etc (i.e. you could maybe only do that at the top level)
11:41:43FromDiscord<ezquerra> (edit) "branckes," => "branches,"
11:41:55FromDiscord<ezquerra> blocks are a really powerful feature indeed 🙂
12:01:03*casaca quit (Read error: Connection reset by peer)
12:01:04*mhcat quit (Write error: Connection reset by peer)
12:01:04*noeontheend quit (Write error: Connection reset by peer)
12:01:04*adigitoleo quit (Read error: Connection reset by peer)
12:01:05*mronetwo_ quit (Write error: Connection reset by peer)
12:01:17*adigitoleo joined #nim
12:01:21*mronetwo joined #nim
12:01:25*mhcat joined #nim
12:01:57*noeontheend joined #nim
12:29:05*casaca joined #nim
12:31:48*PMunch quit (Quit: Leaving)
12:36:52*PMunch joined #nim
12:43:25*azimut_ joined #nim
12:44:07*azimut quit (Ping timeout: 240 seconds)
12:46:26*lucasta joined #nim
12:53:49*edr joined #nim
13:14:04PMunchWe don't have a way to get the name of the current function do we?
13:14:12PMunchLike `__func__` in C
13:15:48Amun-Ratechnically yes, but not that simple
13:16:16NimEventerNew thread by ratchet: NewProc macro question, see https://forum.nim-lang.org/t/10848
13:17:23*jmdaemon quit (Ping timeout: 264 seconds)
13:17:37*rockcavera joined #nim
13:18:09PMunchAmun-Ra, technically yes?
13:18:48Amun-RaPMunch: this is a part of my custom logutils module: https://dpaste.com/5D9T2R55E
13:18:51Amun-Rasee callee_procname
13:19:12Amun-RaI use it in debug/info/… templates
13:19:57Amun-RaI need to rewrite this one, I wrote it in my early nim days
13:22:51PMunchAh right..
13:23:28PMunchI get the module name in a similar way in my logging module :P
13:23:36Amun-Ra:)
13:24:52Amun-RaI use it in my image browser to treat code reading specific format as a module
13:25:03Amun-Rahttps://dpaste.com/2Y3FH5JJK
13:25:31FromDiscord<Phil> In reply to @PMunch "We don't have a": My first trail of thought was "getStackTrace()" and extracting it from there. I'll be honest
13:26:01PMunchAmun-Ra, so that file is called something like png.nim?
13:26:06PMunchObviously not PNG though
13:26:26Amun-Rayes
13:28:15Amun-Raand every format is defined in a const object, I sort these objects in compile time starting with formats with well known magic string…
13:28:20Amun-Rahttps://dpaste.com/4NWZ72U75
13:28:45Amun-RaI'll release the code this year
13:30:21Amun-RaI autodect image formats, but one can try to turn off autodetection with -f "modulename"
13:32:08PMunchCool
13:32:18PMunchI should really try to release my logging library thing this year as well
13:34:27Amun-Rathe project already consists of over 430 nim files… ;)
13:36:37PMunchOh wowzer
13:36:54PMunchOnly counting number of files that would probably one of the biggest Nim projects
13:38:20Amun-Ra(not counting library wrappers)
13:48:21PMunchAmun-Ra, do you know what the `index` parameter to instantiationInfo does?
13:48:27PMunchIt's not documented..
13:52:06Amun-RaPMunch: it acts like a backindex to the call stack
13:52:44Amun-Raif you use it directly you have to use -1, if you call something that calls instantiationInfo use use -2 and so on
13:52:47Amun-RaIIRC
13:54:28PMunchHmm, I think I understand
14:04:07*flouer quit (Remote host closed the connection)
14:04:27*flouer joined #nim
14:05:46Amun-RaI guess you start with -1 because 0 is instantiationInfo itself
14:06:07Amun-RaI never looked at the source
14:33:53FromDiscord<gyatsoyt> hey there like integer in short form is int cant we use str rather than string
14:34:27PMunch`type str = string`
14:34:29PMunchThere you go
14:37:32FromDiscord<gyatsoyt> In reply to @PMunch "There you go": i mean its not pre built syntax i am just assigning it
14:37:43FromDiscord<odexine> Yeah, why should it be built in?
14:37:53FromDiscord<odexine> If you want it then it’s just an extra line
14:39:05PMunchgyatsoyt, sure. The reason why it isn't built in is probably for historic reasons
14:42:22PMunch`int` being short for integer i.e. counting numbers was introduced back in the era where you used short names for everything. Back then you'd also use `char *` to mean a pointer to a string of characters. This concept was later simply abbreviated to `string` and is now used in many languages to denote a piece of text. But by this point people didn't name everything with short names so it just got called `string`. If the concept was first derived in C# or Java
14:42:22PMunchit would probably be known as `PointerToCharacterString` and created by a `PointerToCharacterStringFactory`.
14:42:30PMunchThat's my best guess anyways
14:49:28*Ekho quit (Quit: CORE ERROR, SYSTEM HALTED.)
14:56:15*lucasta quit (Quit: Leaving)
15:01:22*Ekho joined #nim
15:09:43PMunchBiggest frustration with auto-wrapping C libraries is how poorly typed the originals are..
15:10:21PMunchThis one for example creates aliases for everything, but doesn't care to cast its constants to those aliased types..
15:10:50*PMunch quit (Quit: Leaving)
15:11:39arkanoidPMunch drops mic
15:14:30FromDiscord<odexine> Please don’t drop mics, they’re fragile
15:18:31*azimut_ quit (Ping timeout: 240 seconds)
15:19:21arkanoidodexine, not if wrapped in safe way. Ba-dum-tss
15:19:46FromDiscord<nnsee> ugh
15:20:36FromDiscord<odexine> I can’t even express how unimpressed I am
15:21:17FromDiscord<gyatsoyt> what are some alternatives for the sys module of pythonm in nim
15:21:29FromDiscord<gyatsoyt> (edit) "pythonm" => "python"
15:22:06*azimut joined #nim
15:23:10arkanoidgyatsoyt, your question should be more specific. A general answer would be https://nim-lang.org/docs/os.html
15:25:03arkanoidgyatsoyt, but if you are talking about using python interpreter inside your nim program, you have a plain wrapper of the original python sys module here https://github.com/juancarlospaco/cpython
15:39:28FromDiscord<auxym> In reply to @PMunch "Biggest frustration with auto-wrapping": Araq is right on this one, C's type system is crap. Also, it was created in the 70s, so, heh.
16:49:59FromDiscord<Phil> Another day, another attempt to fix my last remaining memory leak of 32 bytes
16:56:01FromDiscord<khazakar> Hello, I don't know if there was similar question or not, but I'd want to buy Araq's book, but not using amazon, since if it's possible to avoid giving even fracture of a cent to amazon, I'd do that. Is it possible?
16:59:08FromDiscord<kcvinker5420> How do you return Windows data types like `HWND`, `HDC` from nim to python and vice versa in nimpy ?
16:59:49FromDiscord<kcvinker5420> These are `pointer` in nim
17:06:56FromDiscord<leorize> you can convert them to uint
17:07:35FromDiscord<Phil> ~~That's it, I'm opening a fedora box just so I can have a gui~~
17:09:09FromDiscord<Phil> Okay so deleting the pointer entries from the channelhub table does not fix the leak.↵Still, the fact that 32 bytes is the same as 4 pointers and the channelhub stores 4 pointers (2 used as keys, 2 used as values) is not lost on me... but what exactly is not accessible anymore =/
17:11:49FromDiscord<kcvinker5420> In reply to @leorize "you can convert them": Thanks. Let me try that. 🙂
17:14:06*xet7 quit (Ping timeout: 260 seconds)
17:16:42FromDiscord<Phil> 🤦
17:17:08FromDiscord<Phil> The above x100. If my hunch is right I'm about to be somewhere between happy and disappointed in myself
17:17:32FromDiscord<jviega> LOL
17:21:30*wheatengineer quit (Quit: Leaving)
17:22:22FromDiscord<Phil> I have a fucking message still rotting in one of the channels on my channelhub, when the channels get closed and destroyed that one leaks I think
17:22:35FromDiscord<Phil> 🔫 💥
17:23:14FromDiscord<Phil> Why do I say that? Because the leak disappears when I read all the messages from the channel first before closing the thread
17:23:45FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
17:24:08FromDiscord<Phil> Not entirely sure why it's 32 bytes though
17:25:10FromDiscord<Phil> How do you get the size of an instance in bytes again?
17:25:46FromDiscord<jviega> Is it a ref type?
17:25:50FromDiscord<jviega> If not, sizeof() works fine
17:26:13FromDiscord<jviega> Otherwise, probably sizeof(r[]) but not sure
17:28:06FromDiscord<Phil> It's... the thing that gets stuck in my channel is the message that kills the thread that reads from that channel
17:28:37FromDiscord<Phil> I lack the ability to express the emotions going through me right now
17:31:29FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
17:32:16FromDiscord<jviega> I assume there's a cycle that isn't getting cleaned up then?
17:33:59FromDiscord<Phil> sent a long message, see <!doctype html>
17:34:22FromDiscord<Phil> And the exception probably blocks destruction of the `ServerMessage` that gets read in
17:34:30FromDiscord<Phil> (edit) "blocks" => "sidesteps"
17:34:40FromDiscord<Phil> That is messed up
17:35:34FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
17:40:06*nazgulsenpai joined #nim
17:44:00FromDiscord<Phil> I have to say, the asan stacktrace was one of the least helpful I've ever seen
17:44:09FromDiscord<Phil> (On arch linux)
17:44:48FromDiscord<Phil> It pointed me literally everywhere except for the channels, only vaguely at my main() proc which yes, so happens to spawn the while-loop above among a dozen other things
17:45:14FromDiscord<Phil> Which were all nested procs as well mind you! But those didn't show up in the stacktrace whatsoever
17:45:29FromDiscord<jviega> Good error messages are hard, and Nim's particularly bad at it.
17:46:20FromDiscord<Phil> In reply to @jviega "Good error messages are": That one was on address sanitizer in part as well imo, though I guess the indirection through nim since it was analyzing nim's C output didn't help I'd wager
17:47:08FromDiscord<Phil> (I assume asan is a common abbreviation of address sanitizer, I'm new at this and like 3 folks have abbreviated that feature this way so far)
17:48:29FromDiscord<Phil> But hey, my dummy example of my lib is now leak free!
17:48:41FromDiscord<Phil> And it wasn't even my channelhub that screwed up ElegantBeef 😛
17:48:49FromDiscord<Phil> (edit) "up" => "up,"
17:54:04FromDiscord<Phil> ~~In fact, making the hub containing all channels an object rather than a ref saves me from issues with std/isolate~~
17:57:26FromDiscord<Phil> And now to debug leaks with threading/channels and loonyqueuue
17:57:29FromDiscord<Phil> (edit) "loonyqueuue" => "loonyqueue"
17:59:04FromDiscord<Phil> ... which grants me 5 leaks all related to the allocation of the threading channels, gnaaaaa
18:20:14FromDiscord<Phil> Turns out I need to explicitly destroy the threading/channels
18:47:31FromDiscord<leorize> did you not?
18:47:47FromDiscord<leorize> I thought you did given the destroy proc you have in your example
18:48:15FromDiscord<Phil> In reply to @leorize "I thought you did": I deallocated the area in which I put the pointer
18:48:35FromDiscord<Phil> Apparently I still need to explicitly call `=destroy` on the Chan/LoonyQueue instances on top of that and forgot about it
18:49:52FromDiscord<Phil> I'll post the current iteration of the "destroy" proc for ChannelHub in a bit, cleaning up my examples to make sure they're all memory safe
18:50:24FromDiscord<leorize> have you tried tsan on them?
18:52:01FromDiscord<Phil> Not yet, one after the other was my motto so far
18:52:32FromDiscord<Phil> By first taking care of a dozen asan issues I was intending to solidify the way of searching for issues in my habits first
18:54:04FromDiscord<leorize> btw did you try the no omit frame pointer flags to see if they give you better traces?
18:54:45FromDiscord<Phil> I think I forgot those. No omit frame pointer flags were flags to apply directly to the compilation command?
18:54:55FromDiscord<Phil> Or was that requiring the fedora container/distrobox/whatnot?
18:55:56FromDiscord<leorize> yea↵(@Phil)
18:57:09FromDiscord<leorize> using fedora container gives you better traces outside of your code (ie. ffi traces)
18:57:28FromDiscord<leorize> but anything within your code is at compile time
19:07:34FromDiscord<Phil> What is the flag called?↵Do is this -fomit-frame-pointer and I add that to the passc flag?
19:07:37FromDiscord<jviega> In C if the last item in a struct is declared to be of an array type with `[]` it allows me to alloc a variable-sized struct, based on the number of elements in that last array (so you don't need an extra indirection) 1. Is there some way to get those semantics directly in Nim (assuming no; I've never seen it), and 2. how do I declare this if I'm wrapping such a data structure??
19:07:39FromDiscord<leorize> https://github.com/google/sanitizers/wiki/AddressSanitizerCallStack↵> AddressSanitizer uses a simple unwinder that relies on frame pointers.
19:07:46FromDiscord<leorize> looks like you do want them on
19:08:18FromDiscord<leorize> `-fno-omit-frame-pointer`↵(@Phil)
19:08:40FromDiscord<leorize> and `-mno-omit-leaf-frame-pointer`
19:08:52FromDiscord<leorize> those two are what fedora uses for it's packages
19:09:40FromDiscord<leorize> see seqs\_v2.nim in the stdlib, it uses that feature for the seq payload↵(@jviega)
19:09:52FromDiscord<jviega> Thanks
19:11:56FromDiscord<Phil> In reply to @leorize "`-fno-omit-frame-pointer` (<@180601887916163073>)": That significantly improved the data I get
19:12:48FromDiscord<Phil> See here https://media.discordapp.net/attachments/371759389889003532/1192546191435645008/message.txt?ex=65a97830&is=65970330&hm=14e22b1b82b4bfde5b7d8dca8b6cc5dfeb18a408b12d888881e0b73a8fe4000b&
19:13:28FromDiscord<Phil> The second one is the one compiled with `nim r --cc:clang --mm:arc -d:release -d:useMalloc -f --passc:"-fsanitize=address -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer" --debugger:native --passl:"-fsanitize=address -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer" --linedir:on -d:butlerThreadin examples/ex_stdinput_async.nim`
19:13:46FromDiscord<Phil> (edit) removed "-d:butlerThreadin"
19:14:26FromDiscord<leorize> now you have new tricks to add to your wiki \:p
19:14:55FromDiscord<Phil> Already on it
19:15:15FromDiscord<leorize> they really should've mandated frame pointers for x86\_64 abi
19:16:10FromDiscord<jviega> Most Linux distros have gotten the message; I think one of the big hold-outs (Fedora IIRC?) recently announced they're finally turning them on
19:16:57FromDiscord<leorize> it's the reverse, most of them are still holding out
19:17:13FromDiscord<leorize> only fedora and ubuntu have them afaik
19:17:15FromDiscord<Phil> In reply to @jviega "Most Linux distros have": I was under the impression it was inverse
19:17:26FromDiscord<Phil> > You can improve the accuracy of the stacktraces by a lot by not omitting "frame-pointers". This is done via the flags `-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer`. They provide a minor performance penalty, but majorly improved accuracy. Fedora compiles all their packages with these flags, this is why that distro is specifically better for stacktaces and debugging.↵↵There we go
19:17:33FromDiscord<leorize> fedora shipped it already but ubuntu is still planned for next release
19:17:35FromDiscord<jviega> Hmm, I guess I don't pay attention to most of the smaller distros
19:19:12FromDiscord<leorize> it's such a bad optimization carried over from i386 days
19:19:13FromDiscord<Phil> For reference: arch: https://gitlab.archlinux.org/daandemeyer/rfcs/-/blob/fp/rfcs/0026-fno-omit-frame-pointer.rst
19:19:22FromDiscord<Phil> That proposal was made 3 weeks ago
19:19:51FromDiscord<leorize> arm64 mandated them so you'll get good traces if you dev on an m1/2/3 by default \:p
19:20:04FromDiscord<jviega> I mean, frame pointer omission hasn't provided any significant performance boost in like 15 years or more
19:22:16FromDiscord<Phil> Actually, never mind, this is the MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/26
19:22:24FromDiscord<Phil> (edit) removed "never mind,"
19:22:32FromDiscord<Phil> The above was just the branch of the RFC
19:22:33FromDiscord<leorize> b-but muh optimizations↵↵-- some gentoo users
19:24:40FromDiscord<leorize> soon you'll get good traces on arch too \:p
19:25:08FromDiscord<Phil> I mean, the discussion looks pretty positive so far, reading through it right now
19:25:27FromDiscord<Phil> sent a long message, see <!doctype html>
19:25:36FromDiscord<Phil> (edit)
19:26:43FromDiscord<jviega> Oh, there are all sorts of things that become a lot more difficult w/o frame pointers, including security monitoring
19:26:51FromDiscord<Phil> > Is the advantage of enabling development without recompilation worth the cost? Does anyone developing software run Arch packages for that software and thus benefit from this, or do they dogfood their work? I guess I tend to work on lower level software so would see no benefit for my work.↵Silent screams from my laptop running arch
19:27:39FromDiscord<Phil> Aaaaand ↵> As a user who's not doing distro development, I don't find that I have a need for frame pointers in official packages. When I'm profiling an application, it's almost always for something that hasn't been officially released yet, so I'm building from source anyway and I can enable the frame pointer myself. Since there is going to be a performance penalty, I'd prefer for Arch to leave it disabled.
19:28:11FromDiscord<leorize> right now I use a fedora dev distro box so I don't have to care about this \:p
19:31:08FromDiscord<Phil> hmmmm leorize, I think I have a leak when there's work in the async-queue but I'm killing the thread.↵What would be the propper way for "emptying" the async-queue before the thread dies?
19:31:25FromDiscord<jviega> I OT
19:31:27FromDiscord<Phil> I currently have a proc that clears out the channel of the thread as well of any message still in there
19:31:29FromDiscord<leorize> get rid of the dispatcher
19:31:38FromDiscord<Phil> Already am doing that by doing setGlobalDispatcher(nil)
19:31:50FromDiscord<Phil> But given that I'm still seeing a leak I assume that doesn't suffice
19:32:07FromDiscord<leorize> if the dispatcher is gone then any queued futures should be too
19:32:53FromDiscord<leorize> unless there's an arc/orc bug, that is
19:34:11FromDiscord<Phil> Hmmm yeah that appears to not be it
19:35:23FromDiscord<leorize> is that one you sent the last leak?
19:35:53FromDiscord<Phil> Currently I'm debugging this example: https://github.com/PhilippMDoerner/ThreadButler/blob/add-loonyqueue-support/examples/ex_stdinput_async.nim↵↵The message.txt contains the last of the 820 leaks it records https://media.discordapp.net/attachments/371759389889003532/1192551998617288715/message.txt?ex=65a97d99&is=65970899&hm=63d7635ba8191161531ebfb3a89a12b80d762316b4e75ec77087a7dfbd0dfbb9&
19:36:43FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
19:36:52FromDiscord<Phil> (edit)
19:37:24FromDiscord<Phil> (edit)
19:37:47FromDiscord<leorize> could be a leak from closure iterator
19:38:09FromDiscord<Phil> closure iterators are one of those things I always hear of and was never forced to understand
19:38:16FromDiscord<Phil> I know what each are individually, never thought about them together
19:38:20FromDiscord<leorize> looks like a string was allocated and never released
19:38:55FromDiscord<Phil> Pretty likely actually.↵This example is about thread A sending a string ot thread B which makes an async-HTTP request to google with that string
19:38:59FromDiscord<leorize> in a way it's budget cps
19:39:01FromDiscord<Phil> I kill the server in the middle of it
19:39:09FromDiscord<leorize> you're using `recvLine`, I pity you
19:39:22FromDiscord<leorize> or well, the stdlib
19:39:45FromDiscord<Phil> In reply to @leorize "in a way it's": Okay that actually sounds funny as hell xD
19:39:51FromDiscord<Phil> I mean, isn't async kinda generally budget cps?
19:39:59FromDiscord<Phil> With really bad stacktraces?
19:40:11FromDiscord<leorize> anyhow, looks like the string allocated during async `recvLine` is not destroyed
19:40:15FromDiscord<leorize> your leak said nothing about the closure itself
19:40:33FromDiscord<leorize> cps is lower level than async \:p you can make the same async API with cps
19:40:54FromDiscord<leorize> but it is specifically the string that leaks
19:41:11FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
19:41:20FromDiscord<Phil> I think the string in question might just be the return of the HTTP request or sth
19:42:03FromDiscord<leorize> yea, your trace said `recvLine`
19:42:03FromDiscord<leorize> which is the most horrendous thing to ever exist in the stdlib
19:42:59FromDiscord<Phil> Ah, is that the kind of thing that made Dom so infamous?
19:43:07FromDiscord<Phil> Or rather his code
19:44:54FromDiscord<leorize> nah, dom is infamous for his attitude
19:45:06FromDiscord<leorize> bad code is fixable, bad attitude less so
19:48:15FromDiscord<leorize> @Phil\: do you only have the indirect leak and not any direct ones?
19:49:46FromDiscord<Phil> as far back as my stacktrace goes, I can't seem to pipe the asan output into a file
19:50:04FromDiscord<Phil> When I do it just prints to stdin anyway
19:50:40FromDiscord<Phil> Looking for flags in the google docs
19:51:10FromDiscord<Phil> as far back as my terminal goes
19:51:17FromDiscord<leorize> `2>&1` then you can pipe
19:51:23FromDiscord<leorize> asan prints to stderr
19:51:40FromDiscord<leorize> so route it back to stdout and you get to pipe
19:51:49FromDiscord<leorize> some shells can do `2|` which pipes only stderr
19:52:33FromDiscord<leorize> looks like bash can do `|&` which pipes both stderr and stdout
19:54:37FromDiscord<Phil> There we go, alright, looking for direct leaks
19:55:56FromDiscord<Phil> In reply to @leorize "<@180601887916163073>\: do you only": Nope, all indirect leaks
19:57:25FromDiscord<Phil> 57 indirect leaks in fact, most 10-20 bytes
19:57:48FromDiscord<Phil> If you want to check yourself https://media.discordapp.net/attachments/371759389889003532/1192557510205378670/message.txt?ex=65a982bb&is=65970dbb&hm=cab4d4132debc893602037f7bc04210d34f01f13c6262c48d3fcaba731702e28&
19:58:24FromDiscord<leorize> smells like cycles to me
19:59:16FromDiscord<mratsim> In reply to @jviega "I mean, frame pointer": I'm really counting every single register available on x86 for cryptography: https://github.com/mratsim/constantine/blob/master/constantine%2Fmath%2Farithmetic%2Fassembly%2Flimbs_asm_mul_mont_x86_adx_bmi2.nim#L29
19:59:58FromDiscord<leorize> you can annotate your proc to have rbp/asan off you know
20:00:11FromDiscord<Phil> ... you can what now?
20:00:22FromDiscord<Phil> Or is that directed at mratsim?
20:00:25FromDiscord<mratsim> details: https://github.com/mratsim/constantine/blob/master/constantine%2Fmath%2Farithmetic%2Fassembly%2Flimbs_asm_mul_mont_x86_adx_bmi2.nim#L210
20:00:51FromDiscord<mratsim> In reply to @leorize "you can annotate your": there is a single proc in the file so localpassC is fine
20:01:10FromDiscord<leorize> and like, if you are working with bare assembly at this point, does it even matter if rbp is available? you can just push it out of the way (I mean, you have to per x86\_64 ABI anyways)
20:02:27FromDiscord<mratsim> In reply to @leorize "and like, if you": you cannot push/pop the stack with inline ASM, it messes up the C compiler
20:02:59FromDiscord<mratsim> otherwise you need asm-no-stackframe but then you need to do all bookkeeping ypurself
20:05:41FromDiscord<jviega> Exactly. And I call shenanigans on one register making a significant difference on anything crypto related anyway. Slow-path for most important primitives is pushed down into the hardware like PCLMULQDQ or is SO slow in a relative sense (elliptic curve math) that it's hardly important. Nor that I can think of any algorithm not pushed to hardware where I couldn't make due easily with the remaining general purpose registers
20:13:02FromDiscord<leorize> isn't that what you should be using in this case?
20:13:02FromDiscord<leorize> you're dependent on the exact x86\_64 ABI and while all of them should handle those registers for you, it's probably better to take the reign and enforce an ABI
20:13:04FromDiscord<leorize> although I think you could just mess with rbp directly even without `-fno-omit-frame-pointer`, but I don't know if gcc/clang would generate code dependent on rbp then
20:13:06FromDiscord<leorize> my impression atm is that it'd just make `rbp` set to the frame but not use it directly for math
20:20:02FromDiscord<jviega> People continually pursue "as fast as possible" without a lot of data, and when they're likely way past "much faster than it needs to be", at the expense of a lot of other important considerations. I've been guilty too. But there were software implementations of GCM-AES 20 years ago easily doing 1gb/sec back when it was 40 cycles per byte and all in software. Now it's hardware and close to 1 cycle per byte.
20:21:24FromDiscord<mratsim> In reply to @jviega "People continually pursue "as": The cryptographic code I'm looking at at my day job needs 100+ GPU to reliably generate proofs in the time budget, 1h.
20:22:03FromDiscord<mratsim> We're inventing new curves and protocols, we're looking into FPGA and investing into ASICs
20:22:34FromDiscord<mratsim> if we can use clusters of CPUs with 300+ cores it would be cheaper.
20:22:57FromDiscord<jviega> Great, then you have far more levers that will provide far more value than a frame pointer.
20:23:00FromDiscord<leorize> @Phil\: have you tried orc?
20:23:07FromDiscord<Phil> In reply to @leorize "<@180601887916163073>\: have you tried": Not yet
20:23:31FromDiscord<dedraiaken> @mratsim do you have an intuition on what’s achievable speed-wise with asics versus implementation on a cpu or gpu?
20:24:12FromDiscord<mratsim> In reply to @jviega "Great, then you have": The algorithm needs 15 registers, otherwise you needs to switch to another modmul algo which is anywhere from 20% to 70% slower (if you just let the compiler do its things)
20:24:22FromDiscord<leorize> give it a go. I don't know how nim's async works wrt chaining but in cps we do have cycles from function calls (that's solved manually, but won't be if you drop the continuation)↵(@Phil)
20:24:30FromDiscord<Phil> arc leaks 25017 bytes↵orc leaks 8393 bytes↵I leak understanding
20:24:46FromDiscord<Phil> (edit) "arc" => "orc" | "bytes↵orc" => "bytes↵arc"
20:25:19FromDiscord<Phil> orc almost exactly triples the leak
20:25:25FromDiscord<mratsim> In reply to @dedraiaken "<@570268431522201601> do you have": you can get 1x but 10x less power usage, or you can get say 50x. My bottleneck at the moment is memory. Some stuff requires 1TB of memory >_>
20:25:57FromDiscord<mratsim> another axis is renting cost
20:26:15FromDiscord<albassort> In reply to @isofruit "orc leaks 25017 bytes": hmmmmmm
20:26:17FromDiscord<mratsim> with AIs monopolizing GPUs, having CPU algorithms is nice.
20:26:23FromDiscord<dedraiaken> Yeah those gpu rental are pricey
20:26:37FromDiscord<albassort> but gpus are cool
20:26:52FromDiscord<leorize> any traces?↵(@Phil)
20:27:05FromDiscord<albassort> would you rather be a cpu or a gpu
20:27:10FromDiscord<albassort> i'd rather be a gpu personally
20:28:00FromDiscord<mratsim> In reply to @leorize "although I think you": iirc I tried but after losing a day on it, I decided not to use push/pop and not deal with asm-no-stackframe.
20:28:39FromDiscord<Phil> In reply to @leorize "any traces? (<@180601887916163073>)": Here ya go https://media.discordapp.net/attachments/371759389889003532/1192565276663881868/message.txt?ex=65a989f6&is=659714f6&hm=9b3e2c112641aa372cf98f4d7018461f07feb4bd185de812db3873b69111be22&
20:29:15FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
20:29:27FromDiscord<Phil> Complains about the same spots
20:29:43FromDiscord<leorize> you got a single direct leak
20:29:44FromDiscord<Phil> from what I can see by skimming
20:30:07FromDiscord<Phil> Ohhh the first thing is a direct leak
20:30:14FromDiscord<albassort> phil are you still making that thing that you needed to wrap into a macro and thread
20:30:35FromDiscord<leorize> you got a leak from... destroying the queue? what
20:31:00FromDiscord<Phil> Is it complaining in this very specific circumstances about me nilling the global dispatcher?
20:31:21FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
20:31:48FromDiscord<Phil> In reply to @albassort "phil are you still": If you mean the threadServer thing - yes.↵I'm at the point where it's electric boogaloo, with insanity and memory debugging
20:32:14FromDiscord<leorize> what is the impl of this `runServerLoop`?
20:32:15FromDiscord<Phil> Thanks to leorize and mratsim I'm slowly coming around to the "easier" of the leaks I made, though this async one stumps me
20:32:20FromDiscord<leorize> looks like it's not from destroying the dispatcher
20:32:30FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
20:32:31FromDiscord<Phil> Should it?
20:32:33FromDiscord<leorize> but from hasPendingOperations?
20:33:12FromDiscord<Phil> hasPendingOperations is an asyncdispatch thing which checks if there are any procs timers or the like registered
20:33:29FromDiscord<Phil> So if that one's busted, I wash my hands in innocence and not the red blood of memory leakage
20:33:36FromDiscord<leorize> I think you didn't even get to the setGlobalDispatcher line
20:35:32FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
20:35:44FromDiscord<Phil> (handleRequestOnServer is a proc defined by the user)
20:35:49FromDiscord<Phil> (edit) "user)" => "user, I just emit it here)"
20:36:12FromDiscord<leorize> can you put the entire file inside `expandMacros` then post it here?
20:36:13FromDiscord<Phil> So it should create a globaldispatcher (?)
20:37:55FromDiscord<albassort> In reply to @isofruit "If you mean the": The psychwards in germany are well staffed i ear
20:37:58FromDiscord<albassort> (edit) "ear" => "hear"
20:38:25FromDiscord<Phil> In reply to @albassort "The psychwards in germany": You heard wrong, half of them are on the verge of collapse and the other half left the sector because of terrible wages
20:38:36FromDiscord<Phil> In reply to @leorize "can you put the": That may take a bit, I'm getting compiler errors when I do that
20:38:47FromDiscord<albassort> In reply to @isofruit "You heard wrong, half": in comparison to New York
20:39:08FromDiscord<Elegantbeef> Yes I mentioned this prior!↵(@Phil)
20:40:24NimEventerNew thread by arnetheduck: `nph` opinionated formatter v0.3, see https://forum.nim-lang.org/t/10850
20:41:40FromDiscord<khazakar> Looks nice 🙂 Will definitely use it for my language learning journey :P)
20:41:41FromDiscord<khazakar> (edit) ":P)" => "😛"
20:42:00FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
20:42:19FromDiscord<Phil> In reply to @khazakar "Looks nice 🙂 Will": It's pretty nphty
20:43:06FromDiscord<kcvinker5420> @leorize Passing HWND to python as uint is okay. But how do we get an HDC from python ?
20:43:42FromDiscord<leorize> all of them are just `HANDLE` variants, right? then `uint` works for all
20:44:03FromDiscord<Elegantbeef> Expand the macro phil
20:44:14FromDiscord<Elegantbeef> It's likely using silly line info
20:44:27FromDiscord<Elegantbeef> Copy your line info kids!
20:45:35FromDiscord<Phil> I mean, this is what it currently outputs (with the error I posted before) https://media.discordapp.net/attachments/371759389889003532/1192569535069425675/message.txt?ex=65a98dee&is=659718ee&hm=ffe9429c02b8d01e8fa1e5ab55f33d6d66ff9eefa4a2fa21be1db8b5afaf2636&
20:46:18FromDiscord<Phil> Though I guess that appears to be the entire file
20:46:32FromDiscord<leorize> just typed macros shenanigans, don't worry about it
20:46:53FromDiscord<Phil> Given that it ends on destroy(hub) which seems accurate as that is the last line on the file and I insert nothing after it
20:47:51FromDiscord<Elegantbeef> Also the `pure` is practically pointless with modern Nim
20:48:05FromDiscord<Elegantbeef> I do not see any reason for that error to appear
20:48:18FromDiscord<Elegantbeef> Oh wait
20:48:52FromDiscord<Elegantbeef> I wonder if you accidently reuse the same symbol for `ServerKinds` and `MainKinds`
20:49:32FromDiscord<leorize> it works without `expandMacros`, beef
20:49:37FromDiscord<Elegantbeef> Oh
20:49:45FromDiscord<kcvinker5420> In reply to @leorize "all of them are": Yes they are
20:49:46FromDiscord<Phil> Also I explicitly made that impossible
20:50:04FromDiscord<Elegantbeef> Then I assume that expandmacros somehow nukes the symbols somehow 😄
20:50:19FromDiscord<Phil> Basically the kinds are generated from message types you pass in.↵I force those to be unique based on symbol name.↵So if one message type contains a type called "Bla", another can not or I won't compile.
20:50:29FromDiscord<leorize> expandMacros is like repr + return
20:50:32FromDiscord<leorize> just nim being nim
20:51:07FromDiscord<Phil> The one enum-kind that isn't is Kill<ThreadName>Kind and thread names are also forced to be unique IIRC
20:51:23FromDiscord<leorize> you know you could `gensym` enum names, right?
20:51:33FromDiscord<kcvinker5420> @leorize Python says↵`TypeError: Cannot convert python object to uint`
20:52:00FromDiscord<leorize> you meant you got an HDC in python?↵(@kcvinker5420)
20:52:14FromDiscord<kcvinker5420> In reply to @leorize "you meant you got": Yes, I am using ctypes
20:52:16FromDiscord<Phil> In reply to @leorize "you know you could": Sure that was I can of worms I didn't want to deal with yet.↵That's a possible generalization I'm willing to deal with if somebody actually cares about it
20:52:19FromDiscord<leorize> what libraries are you using for those?
20:52:22FromDiscord<Phil> Not like the workaround for it is difficult.
20:52:23FromDiscord<leorize> oh ctypes
20:52:29FromDiscord<kcvinker5420> Yeah'
20:52:37FromDiscord<Phil> Perfect is the enemy of good and all that.
20:54:10FromDiscord<leorize> if you can use ctypes then high chance you can just pass the pointer straight back
20:55:43FromDiscord<kcvinker5420> nimpy is not accepting the HDC
20:57:10FromDiscord<kcvinker5420> sent a code paste, see https://play.nim-lang.org/#ix=html>
20:57:38FromDiscord<kcvinker5420> This is when I use plain HDC in nim
20:58:50FromDiscord<Phil> Okay I'm not seeing anything, I'm doing lunch
20:59:06FromDiscord<Phil> Or rather, dinner... which I actually forgot if I had, dang
21:00:26FromDiscord<Elegantbeef> Hey in some dialects lunch is dinner
21:00:40FromDiscord<leorize> @Phil\: from what I can tell, the leak is probably nim's fault
21:00:53FromDiscord<Elegantbeef> Trick statement, when is it not?!
21:02:21FromDiscord<Phil> Easy, whenever I write more than 5 lines of code
21:02:33FromDiscord<Elegantbeef> Leo do you remember the Nim ABI for inheritance off hand, is it a prefixed pointer to the parent type or the type info?
21:02:49FromDiscord<leorize> the typeinfo is in RootObj
21:03:22FromDiscord<leorize> inheritance is just `struct X { super_t super; <your fields here> }`
21:03:50FromDiscord<Elegantbeef> Thought it was `super_t`
21:03:53FromDiscord<leorize> note that the type information data is not populated if you just create a zero-ed memory location, you'd have to run the constructor
21:04:09FromDiscord<Elegantbeef> Oh I know all of this, it's for the header generator
21:04:22FromDiscord<Elegantbeef> I do not have inheritance support at the moment 😄
21:04:43FromDiscord<leorize> you can just look at `sizeof()` to see what it is \:p
21:04:52FromDiscord<Elegantbeef> Yea I can just look at the generated code
21:05:16FromDiscord<leorize> it's probably better to just make inherited types opaque
21:05:16FromDiscord<Elegantbeef> image.png https://media.discordapp.net/attachments/371759389889003532/1192574490757042216/image.png?ex=65a9928b&is=65971d8b&hm=8aab9c7088ae2330c43c6c3c5c64fd108193edcf822452988eed985a9f8f8bf5&
21:05:17FromDiscord<Elegantbeef> This seems like a fine example though
21:05:32FromDiscord<Elegantbeef> Well the benefit in exposing the structs is you can access the fields
21:05:53FromDiscord<Elegantbeef> Like it's much safer to expose all your ref types/sequences as opaque
21:06:00FromDiscord<leorize> do you want to handle the gymnastic required to access overridden fields?
21:06:42FromDiscord<leorize> and like, you're at the mercy of nim abi when you generate the object fields
21:06:43FromDiscord<Elegantbeef> What?
21:07:33FromDiscord<Elegantbeef> Do you mean inherited fields?
21:07:55FromDiscord<leorize> yea
21:08:14FromDiscord<Elegantbeef> I mean if you want to expose inheritance to the C-api why not 😄
21:08:47FromDiscord<Elegantbeef> Probably best to just not support inheritance objects
21:08:54FromDiscord<Elegantbeef> Too easy to fuck things up there
21:09:06FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=html>
21:09:30FromDiscord<leorize> that sounds dangerous \:p
21:09:45FromDiscord<Elegantbeef> Indeed
21:09:50FromDiscord<leorize> you can have like a nim-c stdlib where you define helpers to access those data
21:10:18FromDiscord<Elegantbeef> Nah I do not want to expose any procedures the user does not define
21:11:00FromDiscord<leorize> no, like providing an auxiliary header with utilities for those
21:11:26FromDiscord<leorize> so make seq and stuff opaque and tell them to include this header to get tools to mess with those \:p
21:12:07FromDiscord<Elegantbeef> Well those cannot really be opaque as they need `intptr_t, data`
21:12:34FromDiscord<leorize> why not?
21:13:39FromDiscord<Elegantbeef> Well I can make them `struct seq {len, data}`
21:14:02FromDiscord<Elegantbeef> But that loses type info
21:16:49FromDiscord<leorize> I think for safety you can make them `struct seq_int { char[N] opaque; }` and add a bunch of `int seq_int_at(struct seq_int x, intptr_t offset);`
21:16:57FromDiscord<leorize> but you're still at the mercy of nim abi that way...
21:17:02FromDiscord<leorize> well I guess there's no easy route
21:17:16FromDiscord<Elegantbeef> I mean yea this depends on Nim's string/seq impl
21:17:24FromDiscord<Elegantbeef> Which is why I error if you do not use arc/orc 😄
21:17:39FromDiscord<leorize> and then one day newnewruntime lands \:p
21:17:51FromDiscord<Elegantbeef> Oh noes I have to change some procedures!
21:18:09FromDiscord<leorize> it'll be horrendous if nim ever gets SSO
21:18:45FromDiscord<Elegantbeef> Luckily Araq presently says the best way to use those is a library so... give it a few years
21:20:06FromDiscord<Elegantbeef> I guess I do need a proc to get the actual len from the sequences
21:20:20FromDiscord<Elegantbeef> Since it's actually len shr 1 iirc
21:20:47FromDiscord<Elegantbeef> Or is it the first 63 bit
21:21:59FromDiscord<Phil> SSO?
21:22:11FromDiscord<Elegantbeef> Short string optimisation
21:22:24FromDiscord<Elegantbeef> You store small strings on the stack but large ones with a pointer indirection
21:22:38FromDiscord<Elegantbeef> So any equal to or smaller than the size of a pointer
21:22:44FromDiscord<Elegantbeef> I kid
21:22:55FromDiscord<Elegantbeef> It's any string of a fixed size usually like 32 bytes
21:23:16FromDiscord<Elegantbeef> https://github.com/planetis-m/ssostrings
21:23:22FromDiscord<Elegantbeef> For a Nim impl
21:25:18FromDiscord<leorize> I think you just have to mask the static bit out
21:25:36FromDiscord<Elegantbeef> Yea I think it's the 64th bit
21:25:52FromDiscord<leorize> might as well make the string opaque \:p
21:26:18FromDiscord<Elegantbeef> Oh wait it's the capacity
21:26:32FromDiscord<Elegantbeef> The strlit is inside the capacity!
21:26:40FromDiscord<Elegantbeef> We do not need to mask anything 😄
21:26:45FromDiscord<kcvinker5420> @leorize It compiled when I use `PyObject`
21:26:45FromDiscord<leorize> nice
21:27:07FromDiscord<kcvinker5420> Do I need to convert it back to an HDC ?
21:27:32FromDiscord<kcvinker5420> Or is there any in-build conversion methods in PyObject from Nim
21:27:42FromDiscord<kcvinker5420> (edit) "Nim" => "NimPy"
21:28:00FromDiscord<Elegantbeef> A nice macro of `seq_get_at(a, ind)` might be worthwhile though in an header
21:28:00FromDiscord<leorize> In reply to @kcvinker5420 "Or is there any": no idea, I'm not a nimpy user
21:28:13FromDiscord<kcvinker5420> Okay]
21:29:40FromDiscord<Elegantbeef> To be the devils advocate leo if one wants them to be opaque they can always make a `type Opaque[T] = distinct T` and make their own `toTypeDefs` and `toCType` procs 😛
21:31:00FromDiscord<leorize> why not opaque then transparent on request? xd
21:31:17FromDiscord<Elegantbeef> Uhh
21:31:28FromDiscord<leorize> if you're working with C you can't destroy seqs over there anyways
21:33:31FromDiscord<leorize> there's so little that could be done in C without routing back to Nim that it might be better to figure out a way to take the raw pointers and send a `len + data` pair to C
21:33:37FromDiscord<leorize> basically normalizing the repr
21:34:12FromDiscord<Elegantbeef> Well i can just emit a `intptr_t, void` and a `seq_T_get_data` and `seq_T_index`
21:34:35FromDiscord<leorize> technically you could emit `intptr_t, T` with some magic \:p
21:36:01FromDiscord<leorize> something like `proc toC(sink seq[T]): Cseq[T]`
21:36:02FromDiscord<leorize> then you can support both refc and arc/orc
21:36:02FromDiscord<leorize> but it'd be trouble for the ones in structures, hmm
21:37:50FromDiscord<Elegantbeef> Yea using a void\ is likely the sanest
21:37:50FromDiscord<Elegantbeef> I do not care about supporting refc myself
21:39:44FromDiscord<Elegantbeef> If one really wanted to use refc fork it to emit `struct string{ void}` 😄
21:39:44FromDiscord<leorize> lol
21:39:45FromDiscord<Elegantbeef> Atleast iirc a refc string/seq was a pointer indirect struct
21:40:23FromDiscord<Elegantbeef> The one annoying thing though is that if I emit procs for getting data/len it pollutes the header so I need an utils header that includes the other header
21:41:24FromDiscord<leorize> the joys of FFI
21:41:48FromDiscord<Elegantbeef> And then on C the utils header becomes the important header 😄
21:42:15FromDiscord<Elegantbeef> Oh wait I'm dumb
21:42:33FromDiscord<Elegantbeef> I can just emit both typedefs
21:42:55FromDiscord<Elegantbeef> Well all three
21:44:13FromDiscord<Elegantbeef> Though that makes it like `(struct string_transparent)(myString).data->data`
21:45:20FromDiscord<leorize> you can just tell the user that they should really output a proper C type if they want to make a C lib \:p
21:46:18FromDiscord<leorize> nim seq/strings should just be used during development
21:46:19FromDiscord<leorize> that would let you get away with generating all kind of helpers in a single header
21:50:07FromDiscord<Elegantbeef> I need to look at other libraries
21:50:08FromDiscord<Elegantbeef> GLib for instance exposes their details
21:53:23FromDiscord<leorize> glib is also stable as hell
21:53:25FromDiscord<Elegantbeef> You underestimate my willingness to write a new string/seq impl 😄
21:53:27FromDiscord<leorize> technically anything using C++ STL also have their innards exposed
21:53:29FromDiscord<leorize> just that they are also pretty damn stable
21:53:29FromDiscord<Elegantbeef> The way I see it if the Nim runtime changes enough that's why you version your libraries
21:53:30FromDiscord<leorize> until you use boost and it breaks every point release
21:53:31FromDiscord<Elegantbeef> You can target libname.so.1 only
21:55:21FromDiscord<Elegantbeef> I do hate this problem as there is no straightforward correct answer
21:58:32FromDiscord<Elegantbeef> Wait C has `const` does that prevent changing where pointer fields point?
21:58:32FromDiscord<leorize> my view is that if you use stdlib stuff, you're at risk of stdlib pulling the rug under you
21:58:32FromDiscord<leorize> no, const apply to what the pointer points to
21:58:33FromDiscord<leorize> kinda stupid like that
21:58:33FromDiscord<Elegantbeef> Ugh
22:32:44FromDiscord<Elegantbeef> Well leorize I've decided to go for
22:32:44FromDiscord<Elegantbeef> image.png https://media.discordapp.net/attachments/371759389889003532/1192596504079245332/image.png?ex=65a9a70b&is=6597320b&hm=68de72ac67cb99f1682fc0a6c6eea553c82aa2d8cb68f6e6404c9a757a65d5c6&
22:32:57FromDiscord<Elegantbeef> Users can either use `string` or the opaque variation to make it safer
22:33:07FromDiscord<Elegantbeef> Though it still exposes the `void data` it's still slightly safer
22:33:54FromDiscord<Elegantbeef> Users still also have to define their own procs to operator on the `OpaqueSeq[T]` but bleh
22:39:58FromDiscord<leorize> hmm why not the other way around?
22:40:33FromDiscord<Elegantbeef> Making it harder to wrap the code seems like an opt-in thing to me
22:40:57FromDiscord<Elegantbeef> Atleast as is you can use tool wrapping on the generated header for `string` and have the basis to implement `[]` in any language
22:41:13FromDiscord<Elegantbeef> With fully opaque types `[]` cannot be implemented in any consuming language
22:41:55FromDiscord<Elegantbeef> Well it can be but only if you know the `void` points to `(int, ptr T)`
22:43:25FromDiscord<leorize> shouldn't there be helpers for `[]`?
22:43:46FromDiscord<leorize> if you can reach it in C then you should be able to do it in any language, no?
22:44:11FromDiscord<Elegantbeef> I do not like utils header idea and I do not want to expose more procedures than the user defined in Nim
22:44:16FromDiscord<Elegantbeef> So there is no pretty way to me
22:45:50FromDiscord<leorize> then what is the use case for opaque seqs/strings/refs? to pass to another nim thing?
22:48:43FromDiscord<Elegantbeef> `Opaque`s are meant to be only ever passed to Nim procedures and never interacted with from the FFI side
22:48:44FromDiscord<Elegantbeef> The way I see it if you want safety you should use opaque types and write any accessing code inside Nim
22:48:44FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=html>
22:48:44FromDiscord<Elegantbeef> `mylib_opaque_seq_int_data` is a proc I wrote specifically for querying the data ptr
22:48:53FromDiscord<leorize> I guess that sounds about right
22:49:00FromDiscord<leorize> wait how are you gonna destroy those things?
22:49:10FromDiscord<Elegantbeef> You manually make a `destroy` proc and expose that
22:49:23FromDiscord<leorize> no, like, for the non-opaque one
22:49:28FromDiscord<Elegantbeef> The same way
22:49:42FromDiscord<leorize> lol so you have to write something either way
22:49:55FromDiscord<Elegantbeef> For now atleast
22:50:01FromDiscord<Elegantbeef> I do not want to have hidden exposed symbols
22:50:17FromDiscord<leorize> I guess you can write helpers for the user to generate those symbols
22:50:35FromDiscord<leorize> like `genSeqProc(seq[int], "myprefix_")`
22:50:42FromDiscord<Elegantbeef> Yea
22:51:03FromDiscord<Elegantbeef> I do also have to check if `exportc` uses that `--nimMainPrefix`
22:51:15FromDiscord<Elegantbeef> If so that's a much nicer approach to the str formatter 😄
22:51:48FromDiscord<Elegantbeef> Oh and now I have that TS issue that one person had
22:52:06FromDiscord<Elegantbeef> I dumbly ran `TSUpdate` and it broke!
22:52:20FromDiscord<leorize> do a `TSInstall! nim` and see if that fixes it
22:53:04FromDiscord<Elegantbeef> Nope
22:53:11FromDiscord<leorize> make sure all of your TS plugins are up-to-date
22:53:56FromDiscord<Elegantbeef> Aww it does not use nimMainPrefix
22:54:04FromDiscord<leorize> what commits are you on for the TS stuff?
22:54:16FromDiscord<leorize> I wonder if there's an easy way to get a list...
22:55:51FromDiscord<leorize> and do you have a nvim config that you can share?
22:56:33FromDiscord<Elegantbeef> my init.lua is pretty stock from astronvim
22:56:45FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=html>
22:56:57FromDiscord<leorize> hmm both users with issues use astronvim
22:57:01FromDiscord<Elegantbeef> Infact I do not think I added anything
22:59:52FromDiscord<leorize> I'm loading a container with astronvim and it doesn't seem to like me
23:01:06FromDiscord<leorize> managed to repro it
23:02:59FromDiscord<leorize> yea it's an astronvim bug beef
23:03:28FromDiscord<leorize> they're pinning an older version of nvim-treesitter-textobjects for some reason
23:08:18FromDiscord<Phil> Seeing chronicles pop up every now and again in the asan records is so weird
23:08:40FromDiscord<leorize> they happened to pin the exact commit before the this one lol\: https://github.com/nvim-treesitter/nvim-treesitter-textobjects/commit/381c7326a5e8fff4e29b7ddc4ae486c0d6c07021
23:09:29FromDiscord<leorize> I think you can update the config to pin the newer version so TS works
23:09:38FromDiscord<Phil> Still trying to wrap my head around what the hell is happening here that could possibly be leaking.↵I mean, it's just 112 bytes, but it annoys me that I can't get all my examples squeaky perfect https://media.discordapp.net/attachments/371759389889003532/1192605791933431828/message.txt?ex=65a9afb2&is=65973ab2&hm=a42435255372b940db3947d61e4c6f619d5271d453e36ad9013b524f8ff2e4ce&
23:10:41FromDiscord<Phil> From what I'm understanding they have a ref object somewhere that tracks time and that never gets freed... but that's within the domain of chronicles to deal with, I think
23:12:08FromDiscord<leorize> https://github.com/nim-lang/Nim/blob/c4f98b7696ce74c9952c973b0f09e59234f84917/lib/pure/times.nim#L1372
23:12:19FromDiscord<leorize> threadvar strikes again
23:12:42FromDiscord<leorize> seems like nim threads are a leaky mess \:p
23:13:00FromDiscord<Phil> How the hell do you find these so fast
23:13:15FromDiscord<leorize> I followed the stack trace
23:13:27FromDiscord<Phil> Do you just go in with the notion that it'll be a treadvar somewhere?
23:13:50FromDiscord<leorize> it just happened to be a threadvar
23:14:24FromDiscord<leorize> the traces said `local -> newTimezone`, so I looked at those two and found that one
23:14:27FromDiscord<Phil> But localInstance is mentioned nowhere explicitly, the closest line is times.nim 1389
23:14:42FromDiscord<Phil> Whiiiiich is an assignment to it... why does that look different for me locally
23:15:16FromDiscord<Phil> Because I was looking at the wrong line, uuuuugh
23:15:42FromDiscord<leorize> remember kids, turn on line numbers in your editor
23:15:45FromDiscord<Phil> by "looking at those two" you mean "Jump into file, ctrl+f the words?"
23:15:53*advesperacit quit ()
23:16:44FromDiscord<leorize> the line numbers are in the trace
23:16:53FromDiscord<leorize> but for this instance, yes, I did ctrl+f
23:17:22FromDiscord<Phil> ... dang, localInstance actually is a problem
23:17:32FromDiscord<Phil> I can't nil them the way I did the dispatcher because they're private
23:18:13FromDiscord<Phil> And I don't think there's a setter for them
23:18:44FromDiscord<leorize> you might have to accept that your threads will leak simply because you're using nim
23:19:44FromDiscord<Phil> https://theuselessweb.site/nooooooooooooooo/↵Press the button
23:20:18FromDiscord<leorize> lol
23:21:40FromDiscord<leorize> here's a funny thing\: onThreadDestruction exists for registering thread cleanup handlers
23:21:56FromDiscord<leorize> but onThreadDestruction keeps its data in a threadvar seq
23:22:04FromDiscord<leorize> that is not destroyed on thread exit
23:22:29FromDiscord<Phil> The more I learn about this the more I want to bang my head against the wall
23:23:13FromDiscord<leorize> so it doesn't matter what you do, it will always leak
23:24:48FromDiscord<Elegantbeef> They're ran in reverse order so you could make the first proc be `=destroy(nimThreadDestructionHandlers)`
23:25:33FromDiscord<Elegantbeef> Which makes me wonder whether that's the intention
23:26:00FromDiscord<Elegantbeef> Atleast if I made it I'd have done first in first called
23:26:30FromDiscord<Elegantbeef> It being first in last called makes me imagine the reason is to register the first as the deallocator of all threadvars
23:28:20FromDiscord<leorize> or you could just... add `reset(nimThreadDestructionHandlers)` to the end of the threadProcWrapper
23:30:50FromDiscord<Phil> In reply to @Elegantbeef "They're ran in reverse": As in I could do that and it would do sth? What is nimDestructionHandlers?
23:31:03FromDiscord<leorize> we are talking about the stdlib impl
23:31:09FromDiscord<leorize> you can't do anything about this problem
23:31:27FromDiscord<Phil> 🔫 💥
23:31:30FromDiscord<Elegantbeef> I mean the variable is exposed
23:31:42FromDiscord<Elegantbeef> Can he not just add the proc call or reset call
23:32:42FromDiscord<leorize> yea but it only solve that particular variable
23:32:58FromDiscord<leorize> they still have to add one for every threadvar that might exist in the program
23:33:58FromDiscord<Elegantbeef> Ah right
23:34:15FromDiscord<Elegantbeef> Time to make a `{.realThreadVar.}` macro that does that 😄
23:34:22FromDiscord<leorize> lol
23:35:00FromDiscord<Phil> I mean, at least for chronicles that is a general problem I have, I use chronicles internally as well, though I don't get why this leak only sometimes pops up
23:35:28FromDiscord<leorize> if you log anything that uses timezone and happens to be on an another thread, then it will pops up
23:36:22FromDiscord<Phil> I never specify timezones anywhere and logs do occur anywhere... I guess the log-level for chronicles just might've been too high and have compiled out the log occurrences that trigger it right now
23:36:54FromDiscord<leorize> chronicles just pull TZ whenever it logs the time it seems
23:38:27FromDiscord<Phil> I'm already setting up a `clearThreadVariables`to call at the end of the proc.↵Time to figure out how to do what beef mentioned
23:38:47FromDiscord<leorize> you modify the stdlib to add it \:p
23:38:51FromDiscord<Phil> I'd at least reset the 2 timezone variables
23:38:59FromDiscord<Phil> Wait that requires a stdlib change?
23:38:59FromDiscord<Phil> Shit
23:39:19FromDiscord<leorize> unless you can reach those private variables
23:39:39FromDiscord<Phil> In which case I could just nil'em directly
23:39:40FromDiscord<Elegantbeef> `import module {.all.}` enters the chat
23:39:52FromDiscord<Phil> Time to fuck up times day
23:40:09FromDiscord<leorize> this stuff is for modules to add support themselves
23:41:37FromDiscord<Phil> sent a code paste, see https://play.nim-lang.org/#ix=html>
23:42:02FromDiscord<leorize> that should solve it for your examples at least
23:42:04FromDiscord<Phil> (edit)
23:42:31FromDiscord<Phil> And everyone using the lib. These instances will be spawned even through code used by me internally
23:43:03FromDiscord<Phil> It at least covers all threadvariables I use and fixes things to the best of my ability.↵Threadvariables that are introduced by others are impossible for me to deal with, but I can at least do the best I can in my domain
23:43:11FromDiscord<leorize> well rip\: https://github.com/nim-lang/Nim/blob/c4f98b7696ce74c9952c973b0f09e59234f84917/lib/system/orc.nim#L138
23:43:48*Lord_Nightmare quit (Quit: ZNC - http://znc.in)
23:43:49FromDiscord<Phil> ... the hell?
23:44:33FromDiscord<Phil> Time to nil roots I guess
23:44:42FromDiscord<Phil> Assuming that won't segfault
23:44:52FromDiscord<Phil> Which it likely will, but time to try!
23:44:59FromDiscord<leorize> https://github.com/nim-lang/Nim/blob/c4f98b7696ce74c9952c973b0f09e59234f84917/lib/pure/httpclient.nim#L378
23:45:03FromDiscord<Elegantbeef> I do not know if `import system {.all.}` works
23:45:11FromDiscord<leorize> https://github.com/nim-lang/Nim/blob/c4f98b7696ce74c9952c973b0f09e59234f84917/lib/pure/logging.nim#L285
23:45:37FromDiscord<Elegantbeef> You're probably just better off making threadvars automatically clean up 😄
23:46:15FromDiscord<Phil> First I clean them up in my project, then I even remotely contemplate whether I start fixing this for the stdlib
23:46:34FromDiscord<Phil> Or at least I assume that's what you mean by "automatically clean up", that would be essentially providing a fix for the issue I raised, no?
23:46:34*Lord_Nightmare joined #nim
23:46:38FromDiscord<leorize> it's a compiler problem \:p
23:46:39FromDiscord<Elegantbeef> Well I imagine to do this properly it requires a bit of compiler work
23:46:47FromDiscord<Phil> Fuck
23:47:03FromDiscord<Elegantbeef> All global thread vars should be iterated over and have `=destroy` called on them
23:47:12FromDiscord<Phil> Err.... how do you even get to orc.nim
23:47:16FromDiscord<leorize> the tech to do this already exists
23:47:19FromDiscord<leorize> in nimskull at least \:p
23:47:27FromDiscord<Elegantbeef> `import system {.all.}`
23:47:29FromDiscord<Elegantbeef> If that even works
23:48:30FromDiscord<Phil> `type mismatch: got 'typeof(nil)' for 'nil' but expected 'CellSeq[system.Cell]'` snag dangit
23:48:41FromDiscord<leorize> just reset it lol
23:49:39FromDiscord<Phil> ... how? `roots = default(Cellseq[Cell])` ?
23:50:02FromDiscord<leorize> there's a proc called `reset`
23:50:10FromDiscord<leorize> that you call like this\: `reset(x)`
23:50:14FromDiscord<leorize> which destroys the variable
23:50:33FromDiscord<Elegantbeef> Bold of you to assume that `CellSeq[T]` has `=destroy`
23:50:52FromDiscord<Phil> ... shhhhhhhhhhhhhorts
23:50:53FromDiscord<leorize> lol it doesn't
23:50:54FromDiscord<Elegantbeef> You need to do `deinit(root)`
23:51:10FromDiscord<Phil> Yep, that did it
23:51:45FromDiscord<Phil> That is so many levels of messed up
23:52:25FromDiscord<Phil> However, now literally nothing leaks, not even flipping orc
23:52:31FromDiscord<leorize> I mean, you're doing threads in nim
23:53:19FromDiscord<Elegantbeef> In the end all top level `threadvars` need a `=destroy` implemented and called at the end of thread destruction
23:53:36FromDiscord<Elegantbeef> Which means that you need a closure per threadvar that is stored in a list
23:54:23FromDiscord<Phil> In reply to @leorize "I mean, you're doing": So?
23:54:29FromDiscord<leorize> ssl context will leak atm if you ever touch httpclient btw
23:55:57FromDiscord<Phil> Yeah but touching httpclient is user choice
23:56:11FromDiscord<leorize> didn't one of your example uses it?
23:56:20FromDiscord<Phil> Yeah but only the user-code of the example
23:56:33FromDiscord<Phil> times etc. are also used internally because I use chronicles internally
23:56:38FromDiscord<leorize> and you have a weird leak with that one, right?
23:56:53FromDiscord<leorize> although that one is full of futures so it could be just cycles
23:57:09FromDiscord<leorize> or closures not getting destroyed properly
23:57:15FromDiscord<leorize> I haven't check how closures functions
23:57:42FromDiscord<Phil> TFW loony doesn't implement peek so now I have to check whether I can
23:58:28FromDiscord<leorize> peek is pretty dangerous
23:59:02FromDiscord<Phil> I use it solely for logging so I guess I can live without it
23:59:06FromDiscord<Phil> Because turns out that no, no peek proc