<< 10-08-2025 >>
00:29:25FromDiscord<Robyn [She/Her]> In reply to @albassort "there is this model": but can it run doom?
00:38:06FromDiscord<ollicron_53732> https://imgflip.com/i/a2o6me
00:38:35FromDiscord<ollicron_53732> How i feel right now I literally have no idea what I'm doing https://media.discordapp.net/attachments/371759389889003532/1403900299428757584/a2o6me.png?ex=68993b8a&is=6897ea0a&hm=322ee0c24a5bb342740da488129291b6ab44378980a3b853b0a0008a8f60989d&
00:49:33FromDiscord<Elegantbeef> Mine can run crisis, well existential crisis↵(@Robyn [She/Her])
01:37:33FromDiscord<Robyn [She/Her]> In reply to @Elegantbeef "Mine can run crisis,": damn, you must have a top of the line brain
01:38:00FromDiscord<Robyn [She/Her]> too bad it's occupied by generating witty remarks
01:41:55*oz quit (Quit: EOF)
01:47:07*ox joined #nim
01:47:07*ox is now known as oz
01:51:16FromDiscord<.tokyovigilante> hey team, I know its OOP but not really, but can I not pass a ChildObject that inherits from ParentObject to a function expecting ParentObject?
01:52:58FromDiscord<mr_rowboto> In reply to @.tokyovigilante "hey team, I know": yes
01:53:17FromDiscord<mr_rowboto> you should be able to
01:56:19FromDiscord<.tokyovigilante> sent a code paste, see https://play.nim-lang.org/#pasty=fUTWryLJ
01:57:15FromDiscord<.tokyovigilante> do I need something like `layoutAndRender[T: UIComponent](comp: T, ...)`?
01:57:34FromDiscord<mr_rowboto> can you show the full call?
01:58:07FromDiscord<.tokyovigilante> `layoutAndRender(modal, tui.terminalBox, modalRegion, emptyBindings, tui.themeManager)`
02:00:53FromDiscord<mr_rowboto> sent a code paste, see https://play.nim-lang.org/#pasty=pOzEPRgY
02:00:55FromDiscord<mr_rowboto> that compiles
02:00:57FromDiscord<mr_rowboto> and runs
02:02:01FromDiscord<mr_rowboto> oh, it's the var TerminalBuffer
02:02:04FromDiscord<.tokyovigilante> Thanks, that's exactly what I want to happen. I must be doing something dumb with my inheritance
02:02:04FromDiscord<mr_rowboto> (edit) "var TerminalBuffer" => "`var TerminalBuffer`"
02:02:12FromDiscord<mr_rowboto> no no, it's not that
02:02:17FromDiscord<mr_rowboto> your inheritance is perfect
02:02:32FromDiscord<mr_rowboto> `layoutAndRender` is expecting `buffer: var TerminalBuffer` on the second
02:02:43FromDiscord<mr_rowboto> and you're giving just ` [2] tui.terminalBox: TerminalBuffer`
02:02:55FromDiscord<mr_rowboto> could that be it?
02:03:33FromDiscord<.tokyovigilante> hmm, it should be the right type, but I am mid-refactor
02:03:48FromDiscord<mr_rowboto> [2] looks like it's not a `var` at all
02:03:50FromDiscord<.tokyovigilante> thanks for confirming it should work the way I want though
02:03:54FromDiscord<mr_rowboto> 😄
02:04:30FromDiscord<mr_rowboto> try↵var a = tui.terminalBox↵and pass a just to see if it compiles
02:04:47FromDiscord<.tokyovigilante> I've got a couple of working calls with base objects above, and the same terminalBox (which is actually a TerminalBuffer) but will change it to var yup
02:04:53FromDiscord<mr_rowboto> (edit) "try↵var" => "try↵`var" | "tui.terminalBox↵and" => "tui.terminalBox`↵and" | "a" => "`a`"
02:05:47FromDiscord<mr_rowboto> you're playing with Tui?
02:06:56FromDiscord<.tokyovigilante> If by Tui you mean Terminal ui, then yes. Building a custom renderer based on https://github.com/johnnovak/illwill
02:07:10FromDiscord<mr_rowboto> cool!
02:16:42FromDiscord<Elegantbeef> Row missed me making my own pretend terminal last year for a now backburned project
02:26:38FromDiscord<.tokyovigilante> Will keep you updated once I've built the One True TUI Framework (TM) 😉
02:27:51FromDiscord<.tokyovigilante> sent a code paste, see https://play.nim-lang.org/#pasty=AXoOyqip
02:29:18FromDiscord<mr_rowboto> I have a really stupid question.↵Is it such a bad practice to put the proc signatures on top so I can bury the private procs at the bottom 🫣
02:29:20FromDiscord<mr_rowboto> (edit) "🫣" => "🫣?"
02:30:05FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#pasty=uflzgjgH
02:31:03FromDiscord<mr_rowboto> ohh
02:31:09FromDiscord<mr_rowboto> kinded enum?
02:31:15FromDiscord<mr_rowboto> hmmm
02:31:46FromDiscord<heysokam> In reply to @mr_rowboto "I have a really": More like it will be a pain for you to manage↵I had to do that once, and the file became immutable at some point↵I couldn't change the structure at all
02:31:47FromDiscord<Elegantbeef> I dislike it yes
02:32:39FromDiscord<heysokam> In reply to @mr_rowboto "I have a really": `{.experimental: "codeReordering".}` is a thing, btw. you might prefer it
02:32:48FromDiscord<mr_rowboto> well, yeah, you have to modify stuff in two places
02:34:08FromDiscord<mr_rowboto> sent a code paste, see https://play.nim-lang.org/#pasty=TTyqLLwY
02:34:52FromDiscord<heysokam> I could always import it as two different types, now that I think about it 🤔
02:34:57FromDiscord<mr_rowboto> yeah
02:35:03FromDiscord<mr_rowboto> and just hard cast it
02:35:39FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=YXRsrOrj
02:35:54FromDiscord<mr_rowboto> god
02:35:55FromDiscord<Elegantbeef> Make it a `tuple[width, height: int32]` if you really want
02:36:00FromDiscord<mr_rowboto> theres a {.union.}
02:36:11FromDiscord<Elegantbeef> Mostly for interop, but yea
02:42:30FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#pasty=DzgobcVd
02:42:46FromDiscord<heysokam> width would just be `thing.width`
02:43:20FromDiscord<mr_rowboto> same memory layout tho
02:43:24FromDiscord<Elegantbeef> Then map it as a vec2 and have getters
02:44:02FromDiscord<heysokam> didn't think of the getters, good solution
02:44:24FromDiscord<heysokam> That's basically what they are for on the C side anyway
03:08:10FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#pasty=tbPnNoEh
03:09:20FromDiscord<Elegantbeef> It'd make a type so nope
03:09:35FromDiscord<Elegantbeef> just make a proc take in a `pointer` and be done with it
03:09:48FromDiscord<Elegantbeef> Or if you want it to be specific `ptr A | ptr B | .....`
03:10:02FromDiscord<Elegantbeef> `importC` on a generic doesn't do any symbol madness so it's the same proc
03:11:23FromDiscord<heysokam> kk ty
03:49:02FromDiscord<albassort> In reply to @battery.acid.bubblegum "but can it run": yes!
03:49:28FromDiscord<albassort> depends on your machine but your brain can run doom
03:49:30FromDiscord<albassort> just imagine it
03:59:58FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#pasty=aAMPZpFl
04:01:01FromDiscord<leorize> it happens because you're importc-ing it and using `header` at the same time
04:01:10FromDiscord<leorize> drop `header` unless you need some C macro that you can't replicate in nim or something
04:02:02FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#pasty=GKgAMjid
04:03:15FromDiscord<Elegantbeef> compile pragma?
04:03:44FromDiscord<heysokam> which `.c` file do you add to compile pragma? I don't want an extra file in the project if I can avoid it 🙁
04:06:00FromDiscord<leorize> make a `.c` with just those two lines and add it as `.compile`?
04:07:00FromDiscord<Elegantbeef> You also can probably do `{.passC:-Dtfb_Implementation.}` and use `{.header.}`
04:18:41FromDiscord<heysokam> I guess I'll have to live with the extra file, that did work 🙁
04:19:03FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#pasty=UBMCwLzq
04:20:36FromDiscord<leorize> start by not having `tinyfb.h` included in any nim module?
04:20:59FromDiscord<heysokam> wdym? I don't have it included 🤔
04:21:14FromDiscord<leorize> do you have any `{.header.}`?
04:21:39FromDiscord<heysokam> what alternative do I have? the symbols were missing if I don't add it
04:21:51FromDiscord<leorize> what symbols?
04:21:55FromDiscord<heysokam> the types
04:22:03FromDiscord<heysokam> and constants, and etc
04:22:05FromDiscord<leorize> you should never need `header` to begin with
04:22:18FromDiscord<heysokam> I'll paste the other error then, sec
04:23:15FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#pasty=fZGHSPGg
04:23:38FromDiscord<leorize> did you `{.importc.}` types?
04:23:45FromDiscord<heysokam> yea
04:23:48FromDiscord<leorize> don't do that
04:23:59FromDiscord<leorize> replicate the type exact structure, that's all you need
04:24:07FromDiscord<heysokam> why not? they don't map to the same type if I dont
04:24:18FromDiscord<heysokam> it happened with the wgpu bindings
04:24:47FromDiscord<leorize> wdym?
04:24:49FromDiscord<heysokam> and I get zigcc errors for strict type casting to incorrect types
04:25:09FromDiscord<leorize> that's what happens when you use `{.header.}`
04:25:22FromDiscord<leorize> because then you have to play ball with C source
04:26:07FromDiscord<leorize> if the C source use features that are semantically unreplicatable in Nim, then you are in for pain
04:27:38FromDiscord<heysokam> I see
04:28:22FromDiscord<heysokam> removing importc from types fixed the errors, ty leo
05:05:53FromDiscord<heysokam> hmm, this is really weird 🤔↵I'm getting a segfault on this line, but its coming from `free` internally↵And it does not happen on the C code natively, but only when the code is wrapped to Nim? 🧩 https://media.discordapp.net/attachments/371759389889003532/1403967568288415896/image.png?ex=68997a30&is=689828b0&hm=80df5a9f7f0f1c78d1e09c15f41578857d28e08d114dd1e87159b1784b350fba&
05:09:24FromDiscord<leorize> it meant your pointer is messed up
05:09:26FromDiscord<leorize> maybe because your object layout is different from the real object layout in C
05:10:11FromDiscord<leorize> if you have both the wrapper and the C header somewhere then I can proofread it real quick
05:13:20FromDiscord<heysokam> I do! This is the erroring line:↵https://github.com/heysokam/tinyfb/blob/3659fab06ec8c4a33e6f1edf089d9e49a4bb1ec1/src/tinyfb.h#L362↵And here are the nim bindings for that type:↵https://github.com/heysokam/tinyfb/blob/3659fab06ec8c4a33e6f1edf089d9e49a4bb1ec1/src/tinyfb.nim#L63
05:14:55FromDiscord<leorize> btw `{.importc.}` does nothing for `const`
05:16:08FromDiscord<leorize> for `Pixels`, use `csize_t` instead of `uint`
05:16:35FromDiscord<heysokam> In reply to @leorize "for `Pixels`, use `csize_t`": I wanted a Nim api, with no C types
05:16:57FromDiscord<heysokam> In reply to @leorize "btw `{.importc.}` does nothing": Doesn't it import the type, though?
05:17:29FromDiscord<leorize> it doesn't
05:17:40FromDiscord<leorize> you're not gonna change the fact the structure was made with C typpes↵(@heysokam)
05:17:42FromDiscord<leorize> types\
05:18:08FromDiscord<leorize> also, your `Fn_alloc` and `Fn_allocZ` are swapped
05:18:09FromDiscord<heysokam> In reply to @leorize "you're not gonna change": I guess I'll make the field private with getter/setter 🤷‍♂️
05:18:19FromDiscord<leorize> the two parameters variant is `allocZ`, not `alloc`
05:19:02FromDiscord<heysokam> In reply to @leorize "also, your `Fn_alloc` and": what, where? 🤔
05:19:06FromDiscord<heysokam> I can't see it
05:19:35FromDiscord<leorize> https://github.com/heysokam/tinyfb/blob/3659fab06ec8c4a33e6f1edf089d9e49a4bb1ec1/src/tinyfb.nim#L43-L44
05:19:38FromDiscord<leorize> compare to https://github.com/heysokam/tinyfb/blob/3659fab06ec8c4a33e6f1edf089d9e49a4bb1ec1/src/tinyfb.h#L82-L83
05:19:49FromDiscord<heysokam> ohhh I see now, in the typedef
05:21:51FromDiscord<heysokam> Fixed it. Doesn't seem to solve the issue though, but great catch! 🙏
05:23:21FromDiscord<leorize> your definition of `gl_Uint` is incorrect
05:23:40FromDiscord<leorize> according to [Khronos](https://www.khronos.org/opengl/wiki/OpenGL_Type), `GLuint` is 32bit
05:23:59FromDiscord<leorize> yours is a flip-flop between 32 and 64
05:24:50FromDiscord<heysokam> `typedef unsigned int GLuint;` I thought this `int` meant the same in C
05:25:30FromDiscord<leorize> no it's nominally 32bit
05:25:43FromDiscord<heysokam> didn't know, good to know
05:26:08FromDiscord<leorize> your `Screen.clear_disabled` is also wrong
05:26:13FromDiscord<leorize> C enums are mapped to `cint` by default
05:26:25FromDiscord<leorize> using `bool` makes it as small as a byte, which is very wrrong
05:26:29FromDiscord<leorize> wrong\
05:28:21FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#pasty=HapkcsBI
05:28:45FromDiscord<heysokam> wait, might be `3`, not `7`
05:28:52FromDiscord<leorize> nope
05:28:55FromDiscord<leorize> don't forget about endians
05:29:13FromDiscord<heysokam> I couldn't care less about big endian
05:29:39FromDiscord<heysokam> if it works on 95% of modern computers, I'm good
05:30:05FromDiscord<heysokam> otoh, I could make that field a getter/setter 🤔
05:30:37FromDiscord<leorize> I'm glad you're getting more reasonable
05:30:59FromDiscord<leorize> alternatively just create a new `bool` enum with `{.size: sizeof(cint).}` with converters to normal `bool`
05:33:03FromDiscord<heysokam> that overload sounds not fun, ngl
05:33:42FromDiscord<leorize> that's about all the issues I noticed
05:34:06FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#pasty=zcDXCIwL
05:34:10FromDiscord<heysokam> the last two
05:34:43FromDiscord<heysokam> wouldn't `{.alignas: .. .}` do the trick here?
05:34:44FromDiscord<leorize> it's more the ones in Screen and your faulty gl\_Uint
05:35:21FromDiscord<heysokam> In reply to @leorize "it's more the ones": its still not working though 🤷‍♂️
05:35:41FromDiscord<leorize> I didn't notice you only wanted your code to work /some/ of the time
05:36:32FromDiscord<heysokam> wdym?
05:36:36FromDiscord<leorize> if your structures are not a 1\:1 representation of the C side, you can forget about making anything work
05:38:34FromDiscord<leorize> seems to me that you wrote the code on the C side too
05:38:36FromDiscord<leorize> any reason to use your own fancy bool?
05:40:10FromDiscord<heysokam> simplicity on the C side. doesn't affect this project much, though
05:40:27FromDiscord<heysokam> I copy/pasted from another where it does matter more
05:40:46FromDiscord<leorize> C99 \_Bool exists and it's compatible with nim bool
05:41:57FromDiscord<leorize> I guess you could just add to your `ffi.c` `typedef _Bool tfb_bool;` and `#define tfb_false (0)` `#define tfb_true (1)`
05:42:48FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#pasty=llwhAsUI
05:43:29FromDiscord<leorize> that works
05:44:25FromDiscord<heysokam> how do I map it to nim, though?
05:44:39FromDiscord<leorize> I'm not a fan of what you do with the `union`, but it's valid C, so 🤷
05:44:46FromDiscord<leorize> not valid C++, though
05:44:48FromDiscord<leorize> C bool should be the same as Nim's
05:44:54FromDiscord<heysokam> `type tfb_bool = bool`?
05:45:11FromDiscord<leorize> pretty much
05:45:21FromDiscord<heysokam> ty
05:46:03FromDiscord<heysokam> In reply to @leorize "I'm not a fan": me neither, but haven't figured out a nice api for it yet
05:46:26FromDiscord<leorize> for `tfb_Color`, either fix your Nim to use `uint32` or add `{.align: 4.}` to the object
05:48:44FromDiscord<heysokam> In reply to @leorize "for `tfb_Color`, either fix": I don't follow
05:49:31FromDiscord<leorize> your union has a natural alignment of `4` because it has a variant that's `uint32`
05:49:35FromDiscord<leorize> your `Color` however have a natural alignment of `1` because it's only `bytes`
05:50:01FromDiscord<heysokam> oh
05:50:53FromDiscord<heysokam> `type Color {.align: sizeof(uint32).}= object` like so?
05:50:56FromDiscord<leorize> I'd say to not bother with the other variants and just use a `distinct uint32`
05:51:58FromDiscord<heysokam> In reply to @leorize "I'd say to not": That'd change the API in between langs, which I'd rather avoid
05:52:45FromDiscord<leorize> it'd be `alignof(uint32)`↵(@heysokam)
05:52:56FromDiscord<leorize> just add accessors for the other variants↵(@heysokam)
05:53:25FromDiscord<leorize> defining `[]` and `.rgba` is trivial in nim
05:54:17FromDiscord<heysokam> yep! the align on the color was the issue! tytyty 🙏↵There is no way in hell I would have guessed that, lol
05:55:05FromDiscord<leorize> np, FFI is quite a science
05:55:09FromDiscord<heysokam> In reply to @leorize "defining `[]` and `.rgba`": but its `color.arr[]` not `color[]`, right?
05:55:28FromDiscord<heysokam> I love the `.rgba` field, much better than `.hex`. useful!
05:55:49FromDiscord<leorize> I once had to deal with a library that only crashes in skull but not nim, and turns out it was `enum` sizing
05:56:22FromDiscord<heysokam> you do have a point that `.arr[]` vs `[]` in nim, the latter is way better
05:56:57FromDiscord<heysokam> In reply to @leorize "I once had to": oh shoot. well I'm glad I'm able to leverage your research then! that's epic
05:57:02FromDiscord<leorize> you have to pick and choose what you want to show in each language
05:57:39FromDiscord<heysokam> In reply to @leorize "you have to pick": true, but if you don't pay attention/effort to keeping the apis the same, then they don't even resemble each other in the end
05:57:47FromDiscord<leorize> matrix lags behind by one message lol
05:59:14FromDiscord<leorize> btw you might not want to use `attribute((const))`
05:59:18FromDiscord<leorize> it doesn't work the way you think it does
06:00:21FromDiscord<heysokam> In reply to @leorize "it doesn't work the": how do you think I think it works?
06:01:39FromDiscord<leorize> you think it works like `{.noSideEffects.}` given how you plastered it on `tfb_init` and `tfb_close`
06:02:39FromDiscord<leorize> it doesn't even work for the `tfb_pixels_size` case
06:04:51FromDiscord<heysokam> sent a long message, see https://pasty.ee/TCYTJvyR
06:04:59FromDiscord<leorize> sent a long message, see https://pasty.ee/iKgpBnJT
06:06:02FromDiscord<leorize> you're calling `glfw` APIs, which definitely change state so it wouldn't even qualify for `{.noSideEffects.}` in Nim proper
06:07:20FromDiscord<leorize> and it wouldn't work for `tfb_pixels_size` because between two calls you could've modified the pixels object, which is then a violation of the contract
06:08:09FromDiscord<heysokam> but the object is passed in at the time of calling
06:08:45FromDiscord<heysokam> In reply to @leorize "you're calling `glfw` APIs,": that's true. but its the best one can do in C
06:09:17FromDiscord<leorize> don't add attributes that you can't guarantee to the letter
06:09:37FromDiscord<heysokam> I'd rather have a language-wide semantic pass, like noSideEffects from nim, but const is the closest alternative 🙁
06:09:40FromDiscord<leorize> Nim does not care about `{.noSideEffects.}` other than as an advisory pragma
06:10:01FromDiscord<leorize> but C compilers can and will assume things the moment you slip
06:10:25FromDiscord<heysokam> I see
06:10:44FromDiscord<leorize> never put attributes you can't guarantee unless you are in for pain
06:11:08FromDiscord<leorize> for example `tfb_init` being `const` meant that if it's the only function called, the compiler is free to assume that it could just remove the call because it doesn't change state
06:11:37FromDiscord<leorize> I won't say that it will do that, but that attribute gives it a license to
06:17:44FromDiscord<leorize> sent a code paste, see https://play.nim-lang.org/#pasty=lvrYWzuN
06:21:02FromDiscord<heysokam> oh, I see what you mean
07:53:20*alexdaguy joined #nim
08:31:07FromDiscord<Robyn [She/Her]> In reply to @albassort "yes!": based
09:09:57*shwouchk quit (Quit: WeeChat 4.5.2)
09:12:41FromDiscord<janakali> In reply to @albassort "just imagine it": just write down all calculations by hand for 1 frame per month performance
09:26:48*alexdaguy quit (Quit: WeeChat 4.7.0)
09:30:53*tiorock joined #nim
09:30:53*rockcavera is now known as Guest2333
09:30:53*Guest2333 quit (Killed (copper.libera.chat (Nickname regained by services)))
09:30:53*tiorock is now known as rockcavera
09:33:00*tiorock joined #nim
09:33:00*tiorock quit (Changing host)
09:33:00*tiorock joined #nim
09:33:00*rockcavera quit (Killed (iridium.libera.chat (Nickname regained by services)))
09:33:00*tiorock is now known as rockcavera
09:54:28FromDiscord<Laylie> it is done↵(@nasuray)
10:24:10*tiorock joined #nim
10:24:10*tiorock quit (Changing host)
10:24:10*tiorock joined #nim
10:24:10*rockcavera quit (Killed (erbium.libera.chat (Nickname regained by services)))
10:24:10*tiorock is now known as rockcavera
10:26:15*tiorock joined #nim
10:26:15*tiorock quit (Changing host)
10:26:15*tiorock joined #nim
10:26:15*rockcavera is now known as Guest3155
10:26:15*tiorock is now known as rockcavera
10:29:10*Guest3155 quit (Ping timeout: 260 seconds)
10:40:31*beholders_eye joined #nim
10:50:05*beholders_eye quit (Ping timeout: 265 seconds)
10:51:45*beholders_eye joined #nim
11:18:40*przmk quit (Remote host closed the connection)
11:20:32*przmk joined #nim
11:23:38*skippy8 quit (Quit: WeeChat 4.6.3)
11:56:21*przmk quit (Remote host closed the connection)
12:13:37*przmk joined #nim
12:20:04FromDiscord<aintea> In reply to @janakali "just write down all": Just use your gut bacteria to run it, it takes roughly 9 hours for one frame
12:20:15FromDiscord<aintea> (it has been done, 48x32 resolution)
12:23:19*beholders_eye quit (Ping timeout: 260 seconds)
12:24:57*beholders_eye joined #nim
12:55:47*andy-turner joined #nim
14:01:48FromDiscord<ollicron_53732> I am somewhere on this curve learning how to use macros https://media.discordapp.net/attachments/371759389889003532/1404102434942488606/Screenshot_2025-07-28_at_8.png?ex=6899f7cb&is=6898a64b&hm=316d98be38ba37121b74ff2f80d44560d89efa411c1b93d0e1003a32323c70d1&
14:02:17FromDiscord<ollicron_53732> probably the slope of enlightenment
14:24:34*nils` quit (Ping timeout: 245 seconds)
14:35:54FromDiscord<heysokam> I'm definitely in the valley of despair about macros, and its so comfortable around here!↵Proceduralism and explicitness have their summer homes on this valley!
14:36:50FromDiscord<heysokam> (edit) "here!↵Proceduralism" => "here!↵Proceduralism, imperativeness" | "valley!" => "valley too! 🏖️"
14:54:01FromDiscord<0xfab_10> kid named typeclasses with macros:
15:23:50*nils` joined #nim
15:26:00FromDiscord<Robyn [She/Her]> In reply to @ollicron_53732 "I am somewhere on": macros aren't really that hard though?
15:26:08FromDiscord<Robyn [She/Her]> AST is just data
15:40:05FromDiscord<mr_rowboto> In reply to @heysokam "I'm definitely in the": I also sit in the comfort of not fucking up the AST.
15:40:35FromDiscord<mr_rowboto> I have more than enough with my stuff
16:01:08FromDiscord<heysokam> does the `a in B` operator call `B.items()` internally?
16:07:35FromDiscord<heysokam> ah, I just found the answer in the manual. never saw this section↵https://nim-lang.org/docs/manual.html#iterators-and-the-for-statement-implicit-itemsslashpairs-invocations
16:12:08*joast quit (Quit: Leaving.)
16:17:44*ehmry quit (Read error: Connection reset by peer)
16:18:46*ehmry joined #nim
16:47:26*joast joined #nim
17:06:09*skippy8 joined #nim
17:23:47FromDiscord<heysokam> sent a code paste, see https://play.nim-lang.org/#pasty=ptJkdYWv
17:36:32FromDiscord<Elegantbeef> @heysokam It's a union so use the union pragma
17:37:05FromDiscord<Elegantbeef> If you don't want it to be overlapping don't use the union keyword in C
17:37:20FromDiscord<Elegantbeef> `size_of(tfb_Color) == sizeof(uint8_T)`
17:37:47FromDiscord<heysokam> Its not a union?
17:38:02FromDiscord<leorize> union meant every entries share memory
17:38:11FromDiscord<heysokam> oh... wait I'm retarded. I forgot to remove my type to `struct`!!!
17:38:11FromDiscord<leorize> so that union of yours is 1 byte sized
17:38:30FromDiscord<heysokam> classic sokam misread 🐠
17:38:33FromDiscord<Elegantbeef> Leo always repeating what I say, it's unfair
17:42:16FromDiscord<leorize> if saying it once doesn't work saying it twice should, right?
17:42:39FromDiscord<Elegantbeef> You have a way with words
18:08:05FromDiscord<heysokam> I solved the gpu drivers segfault by removing `union`, but now I'm back to segfaulting on `free( the ptr )` from NIm, and not from regular C 🙁
18:10:21FromDiscord<leorize> send code and I can take a quick peek
18:17:38FromDiscord<heysokam> sent a long message, see https://pasty.ee/vhefxRcI
18:18:23FromDiscord<heysokam> the `ColorRGBX` type is the same I had before without the align:↵https://github.com/heysokam/tinyfb/blob/a40dec3079c8bbc8c4b7e66b9cbdc173930dbbc7/src/tinyfb.h#L378
18:18:37FromDiscord<heysokam> (edit) "align:↵https://github.com/heysokam/tinyfb/blob/a40dec3079c8bbc8c4b7e66b9cbdc173930dbbc7/src/tinyfb.h#L378" => "align:↵https://github.com/treeform/chroma/blob/master/src/chroma/colortypes.nim#L24-L29"
18:21:56FromDiscord<leorize> tfb\_init\_args definition of clear\_color doesn't match C side
18:23:42FromDiscord<heysokam> In reply to @leorize "tfb\_init\_args definition of clear\_color": why not?
18:24:18FromDiscord<leorize> one is pointer the other is struct
18:24:46FromDiscord<heysokam> `result = tfb_init(args.addr)` 🤔
18:25:23FromDiscord<heysokam> `proc tfb_init (args :ptr tfb_init_args) :Screen {.importc:"tfb_init", cdecl.}`
18:25:36FromDiscord<leorize> you're missing half of my statement
18:26:04FromDiscord<heysokam> I don't understand your statement at all if you say that
18:26:27FromDiscord<leorize> look at clear\_color
18:27:45FromDiscord<heysokam> I'm looking, and I don't see anything
18:28:04FromDiscord<heysokam> also, never trust me with "look at X". I'll 1000000000000000% miss it
18:28:21FromDiscord<leorize> this is a pointer\: https://github.com/heysokam/tinyfb/blob/a40dec3079c8bbc8c4b7e66b9cbdc173930dbbc7/src/tinyfb.h#L152this isn't\: https://github.com/heysokam/tinyfb/blob/a40dec3079c8bbc8c4b7e66b9cbdc173930dbbc7/src/tinyfb.nim#L77
18:28:27*ftajhii quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
18:29:44FromDiscord<leorize> thanks to that your struct is probably 4 bytes short of it's real size
18:30:09FromDiscord<heysokam> jezuz, that was it. insane catch
18:30:53FromDiscord<heysokam> 💐 tysm, once again. there is no way in hell I'd have solved these two issues on my own 🙏
18:31:49FromDiscord<leorize> your dream of having one impl multiple wrappers is definitely not scaling well lol
18:37:32*ftajhii joined #nim
18:43:52FromDiscord<0xfab_10> man do I miss some rust stuff in nim, like a `Box<[T]>` equivalent
18:44:25FromDiscord<0xfab_10> there's `seq[T]` but that's like `Vec<T>` and I don't think it properly communicates intention
18:44:49FromDiscord<0xfab_10> "make your own" yeah but ugh
18:45:16FromDiscord<0xfab_10> then I need to dig in the guts of `seq[T]` to have a `to_boxed_slice` equivalent
18:46:02FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=GDwqkTYQ
18:46:54FromDiscord<leorize> why RTTI
18:47:07FromDiscord<leorize> and also box is single owner
18:47:59FromDiscord<Elegantbeef> Sorry my mind was thinking box as in the C# variety
18:48:30FromDiscord<0xfab_10> fixed size heap array
18:48:47FromDiscord<0xfab_10> runtime sized
18:48:52FromDiscord<Elegantbeef> That's not what a box is though
18:48:59FromDiscord<Elegantbeef> A box is just a single owner heap allocation
18:49:18FromDiscord<Elegantbeef> If you want a fixed size heap array just do `ref array[10000000, int]`
18:50:24FromDiscord<0xfab_10> yes a box is a single owner heap allocator
18:50:41FromDiscord<0xfab_10> a `Box<[T]>` is a single owner, heap allocated, runtime sized array
18:50:46FromDiscord<leorize> you can just make your own with `ptr UncheckedArray`↵(@0xfab_10)
18:50:54FromDiscord<ieltan> In reply to @fabric.input_output "man do I miss": I'm working on exactly that atm
18:50:56FromDiscord<0xfab_10> In reply to @fabric.input_output "then I need to": .
18:51:16FromDiscord<Elegantbeef> Box is not an array though
18:51:35FromDiscord<ieltan> Best I could do is a BoxArray[T] which is backed by a `ptr UncheckArray[T] `
18:51:43FromDiscord<ieltan> (edit) "UncheckArray[T]" => "UncheckedArray[T]"
18:52:03FromDiscord<0xfab_10> In reply to @Elegantbeef "Box is not an": box isn't, `Box<[T]>` is
18:52:20FromDiscord<ieltan> In reply to @Elegantbeef "Box is not an": Well `BoxSeq` sounded less cool in my mind lol
18:52:40FromDiscord<ieltan> And I still think it get the point across anyways
18:53:11FromDiscord<ieltan> You cannot grow a `Box<[T]>` for instance
18:53:46FromDiscord<Elegantbeef> Oh god there is a `Box<T>` and `Box<[T]>`
18:53:54FromDiscord<ieltan>
18:53:57FromDiscord<ieltan> Yes
18:54:08FromDiscord<leorize> rust just happens to have a real slice type
18:54:08FromDiscord<ieltan> I was also kinda confused at first though
18:54:11FromDiscord<0xfab_10> `Box<[T]>` is just `Box<U>` for `U: [T]`
18:54:16FromDiscord<Elegantbeef> `std::vector<std::bool>` isn't looking too bad now
18:54:28FromDiscord<0xfab_10> In reply to @leorize "rust just happens to": slices are so good 😭
18:54:34FromDiscord<leorize> it'd be `Box[openArray[T]]` in Nim lingo
18:54:45FromDiscord<leorize> except that nim openarrays doesn't work that way
18:54:54FromDiscord<Elegantbeef> I don't like specializations that change the intent 😄
18:54:56FromDiscord<0xfab_10> lowkey hate openarrays
18:55:03FromDiscord<ieltan> I though rust was supposed to be very verbose so I was waiting to see `Box<Slice<T>>` or something, what's up with that hm?
18:55:03FromDiscord<Elegantbeef> Lowkey hate you
18:55:28FromDiscord<Elegantbeef> Anyway then yea just wrap it in a `ptr UncheckedArray[T]` and cry when you have memory issues
18:55:30FromDiscord<0xfab_10> In reply to @ieltan "I though rust was": `Slice<T>` is just `[T]` because it's so fundamental to the language
18:55:59FromDiscord<ieltan> Openarray are cool, they just view types to be in the language for real
18:56:10FromDiscord<ieltan> And maybe an actual usable name...
18:56:18FromDiscord<ieltan> (edit) "Openarray are cool, they just ... view" added "need"
18:57:57FromDiscord<ieltan> In reply to @fabric.input_output "`Slice<T>` is just `[T]`": Makes sense
19:07:55FromDiscord<leorize> rust has a rather clear separation between refs and concrete types, for better or worse
19:09:19FromDiscord<0xfab_10> I think it's better
19:09:46FromDiscord<0xfab_10> In reply to @Elegantbeef "`std::vector<std::bool>` isn't looking too": you scared of fat pointers?
19:12:56FromDiscord<Elegantbeef> Specializations changing behaviour is always fun, though I also do it, so perhaps I'm just annoying
19:12:57FromDiscord<Elegantbeef> No
19:14:43FromDiscord<0xfab_10> well it's not some random struct changing behavior through specialization, it's just a core language mechanic
19:15:16FromDiscord<Elegantbeef> I mean it is
19:15:46FromDiscord<Elegantbeef> `Box<[T]>` Behaves differently than `Box<T>` and that's 'some random struct changing behaviour through specialization'
19:15:53FromDiscord<0xfab_10> no it doesn't
19:16:03FromDiscord<leorize> it's the same beef
19:16:41FromDiscord<0xfab_10> `Box<U>` keeps a `U` and when `U: [T]` it holds a `[T]` which is a fat pointer
19:16:42FromDiscord<leorize> Rust openArray happens to be valid standalone
19:16:44FromDiscord<0xfab_10> that's a thing the language does
19:17:44FromDiscord<Elegantbeef> Ehhh
19:18:11FromDiscord<Elegantbeef> I'll agree only due to ignorance
19:18:46FromDiscord<0xfab_10> nothing crazy level as `std::vector<bool>` transforming into a bitset or the `std::string`s doing short string optimizations
19:21:23FromDiscord<leorize> it's powerful but you run into `&String` and `&str` real quick↵(@0xfab_10)
19:22:18FromDiscord<0xfab_10> I don't see an issue
19:22:27FromDiscord<0xfab_10> I like the distinction
19:23:23FromDiscord<0xfab_10> besides `&String` kindof a useless thing, you either `&mut String` or `&str`
19:23:51FromDiscord<0xfab_10> `Box<str>` 😎
19:24:07FromDiscord<leorize> yes but generics exist and it will mint `&String`, like it or not
19:24:54FromDiscord<leorize> I know how to avoid it, but it's a kind of splinter from having this sort of types
19:25:41FromDiscord<0xfab_10> I don't get it, just don't have `&String` happen?
19:28:08FromDiscord<leorize> it doesn't happen because you write it, it happens because generics specialize into it
19:28:33FromDiscord<0xfab_10> yes but what is a situation where you give it to a generic that turns it into `&String`
19:28:34FromDiscord<leorize> not that big of a deal, but it's annoying nevertheless
19:28:47FromDiscord<leorize> `Option<T>`
19:29:25FromDiscord<leorize> you get `&String` out from a simple `.as_ref`
19:29:28FromDiscord<0xfab_10> oh I forgot that could happen
19:29:35FromDiscord<leorize> but like I said, it's not really a big deal
19:29:54FromDiscord<0xfab_10> `Option<&T>` is just discarded or transformed immediately
19:29:57FromDiscord<0xfab_10> usually
19:30:07FromDiscord<leorize> but it's an extra thing to be aware of in Rust
19:30:16FromDiscord<leorize> I prefer not having that if possible
19:31:28FromDiscord<0xfab_10> `impl Option<String> { pub fn as_str(&self) -> Option<&str> { self.map(String::as_str) } }` :^)
19:32:13FromDiscord<0xfab_10> I'm usually completely unaware of things like this 90% of the time
19:32:26*skippy8 quit (Quit: WeeChat 4.6.3)
19:32:30FromDiscord<leorize> the fact you have to create a specialization is something I don't like to see
19:56:13FromDiscord<ieltan> sent a code paste, see https://play.nim-lang.org/#pasty=JRjzjKJI
19:56:56FromDiscord<leorize> false 0 true?
19:57:03FromDiscord<heysokam> 42, 42, 46&2
19:57:17FromDiscord<ieltan> In reply to @leorize "false 0 true?": yup
19:57:38FromDiscord<ieltan> it was kinda surprising to me but maybe i am just not knowledgeable about how closure iterators work
19:57:47FromDiscord<heysokam> > reference for the `46&2` one:↵> https://www.youtube.com/watch?v=GIuZUCpm9hc
19:58:00FromDiscord<ieltan> In reply to @heysokam "42, 42, 46&2": is that supposed to mean it's ud?
19:58:19FromDiscord<ieltan> In reply to @heysokam "> reference for the": oh lol
19:58:37FromDiscord<ieltan> (idontgetit)
19:58:44FromDiscord<heysokam> In reply to @ieltan "is that supposed to": it means you answered life two times, and then blasted some metal in celebration. who cares about the bug!
19:59:49FromDiscord<ieltan> I'll blast the metal after the "bug" is blasted too :p
20:00:01FromDiscord<ieltan> But i am not even sure if that's even a bug
20:00:04FromDiscord<ieltan> gotta ask araq
20:00:06FromDiscord<leorize> iterators stop at `yield` then pick back up from there, so I agree that it can be very confusing.The last iterations were just continuing from the last yield, because technically that's not where the iterator code stops (it still has to hit the `for` line to check and exit), and if you didn't yield (because you're exiting), you get the default value↵(@ieltan)
20:01:56FromDiscord<leorize> the representation of most closure iterators will always be off-by-one because of this
20:02:49FromDiscord<leorize> the best way to model it is actually to consider `finished` more like `not hasValue`, then only interpret the value according to it
20:03:53FromDiscord<ieltan> sent a code paste, see https://play.nim-lang.org/#pasty=yTdaPeyC
20:04:31FromDiscord<ieltan> I never really deal with `emit` so i don't understand anything
20:04:53FromDiscord<ieltan> `ClE_0` has to be the closure environment
20:05:04FromDiscord<ieltan> but it's totally type erased so i cannot just do stuff
20:05:58FromDiscord<ieltan> In reply to @leorize "iterators stop at `yield`": Hm yeah i get how i have the 0 now. But shouldn't `finished` take this into account ?
20:11:41FromDiscord<ieltan> sent a code paste, see https://play.nim-lang.org/#pasty=bgxEueOd
20:13:31FromDiscord<ieltan> sent a long message, see https://pasty.ee/FdGTGjrg
20:15:53FromDiscord<leorize> add an echo to the end of your iterator and you will see why finished doesn't just fire at the last yield
20:19:53FromDiscord<ieltan> sent a code paste, see https://play.nim-lang.org/#pasty=hgfwmmQM
20:21:00FromDiscord<ieltan> ok so at the fifth iteration it's still stuck at the last `yield`
20:21:24FromDiscord<ieltan> it's not until i call the iterator again that it's "unstuck" is that right ?
20:21:39FromDiscord<leorize> yep
20:22:25FromDiscord<ieltan> that's just great lol i wonder if it's possible to even work around that somehow but i don't think it is
20:37:56FromDiscord<leorize> it doesn't even make sense to, closure iterators are just built different
21:28:34*andy-turner quit (Quit: Leaving)
21:28:38FromDiscord<.tokyovigilante> Are there any best practices for custom [] operators, or custom operators in general? E.g. proc vs template.
21:29:33FromDiscord<leorize> operators are just callables, pick `proc`/`template`/etc. as you would with other callables
21:38:28FromDiscord<blashyrk> Nim + GCC15 = magic↵Nim + MSVC = poopoo↵↵Or I guess MSVC = poopoo in general
21:38:50FromDiscord<blashyrk> (edit) "Nim + GCC15 = magic↵Nim + MSVC = poopoo↵↵Or I guess MSVC = poopoo in general" => "sent a long message, see https://pasty.ee/uZwgWBlf"
21:40:20FromDiscord<leorize> just use clang if you must interact with other msvc stuff
21:41:39FromDiscord<blashyrk> I use it anyway since it seems to produce better machine code than anything else on Windows, but I still get better performance in WSL2 than a native Windows binary because GCC15 seems to knock heavy fp math out of the park with little extra guidance
21:42:20FromDiscord<leorize> you can also use gcc on windows
21:42:53FromDiscord<leorize> linux might just be better at fp math to start by not requiring register spilling for certain function signatures
21:43:05FromDiscord<blashyrk> Gcc as in not mingw? Because mingw also produces inferior binaries for whatever reason
21:43:21FromDiscord<leorize> mingw uses the same internal transformer
21:43:50FromDiscord<leorize> mind the objects you pass around, it could be the source of your bad code due to some annoying Win32 calling convention requirements
21:43:59FromDiscord<blashyrk> Hmm that's strange, one would think that ABI differences wouldn't result in 20-30% performance diff
21:44:31FromDiscord<leorize> in hot fp loops whether you get to keep your data in registers directly influence performance
21:44:41FromDiscord<blashyrk> I'll have to dig deeper to see what's really going on, just wish there was something like perf on windows
21:44:47FromDiscord<leorize> there is
21:45:25FromDiscord<blashyrk> WPT doesn't work for me I can generate a report with the xperf tool but can't open it in the viewer for whatever reason
21:45:55FromDiscord<leorize> you can also just use intel vtune
21:46:25FromDiscord<blashyrk> Probably the amd's thingy instead since I have a 7950x
21:51:55FromDiscord<blashyrk> Lol well the thing is useless unfortunately https://media.discordapp.net/attachments/371759389889003532/1404220742626705569/image.png?ex=689a65fa&is=6899147a&hm=fe385d87bda6c2de14c05bfbe13e0a865943ee9b4b9d3056afe590c6b33c202e&
21:52:31FromDiscord<leorize> maybe that's why WPT didn't work for you lol
21:52:59FromDiscord<blashyrk> Yeah but having to drop virtualization in uefi so you can profile your code is nuts
21:53:37FromDiscord<leorize> no you only have to drop windows virtualization-based separation
21:54:06FromDiscord<leorize> that feature runs the entire system in a hyper-v VM
21:54:16FromDiscord<blashyrk> https://media.discordapp.net/attachments/371759389889003532/1404221337333141605/image.png?ex=689a6687&is=68991507&hm=91259cb8a07b886c0f92ccae9c98395c1af87f2fc0a21918c96c563e5f81fb9d&
21:54:39FromDiscord<leorize> maybe don't bother with windows lol
21:54:49FromDiscord<blashyrk> In reply to @leorize "maybe don't bother with": I guess that's the best course of action hahah
21:54:53FromDiscord<leorize> use linux perfs to get the hotspot then just disassemble your windows code to look at them
22:52:58*ChanServ quit (shutting down)
23:17:05*beholders_eye quit (Ping timeout: 248 seconds)
23:19:10*beholders_eye joined #nim
23:23:34*adigitoleo quit (Server closed connection)
23:25:42*adigitoleo joined #nim