<< 23-06-2025 >>
03:26:13*rockcavera quit (Remote host closed the connection)
03:27:10*SchweinDeBurg quit (Quit: WeeChat 4.7.0-dev)
04:31:26*SchweinDeBurg joined #nim
04:33:55FromDiscord<devlop_gaming> sent a code paste, see https://play.nim-lang.org/#pasty=ubJKLrQo
04:38:39FromDiscord<leorize> you can start by posting what error did you get
04:40:34FromDiscord<devlop_gaming> sent a code paste, see https://play.nim-lang.org/#pasty=DRiAkTlr
04:40:37FromDiscord<.tokyovigilante> and checking your window and renderer pointers are valid, ie did you call `SDL_CreateWindow()` etc?
04:40:51FromDiscord<devlop_gaming> sent a code paste, see https://play.nim-lang.org/#pasty=zlkIYUlf
04:40:59FromDiscord<devlop_gaming> In reply to @.tokyovigilante "and checking your window": Yes
04:41:12FromDiscord<devlop_gaming> sent a code paste, see https://play.nim-lang.org/#pasty=kGvUSkxr
04:43:12FromDiscord<.tokyovigilante> To be fair I have found a new times passing C struct pointers around, needing to cast them to a raw pointer and having a shim, very hard not to import a forward declaration twice when importing multiple C headers that have forward/extern declarations, Nim seems to internally define these as different pointer types
04:44:20FromDiscord<devlop_gaming> Meaning?
04:44:24FromDiscord<.tokyovigilante> e.g. `proc ImGui_ImplSDL3_InitForOpenGL (window: pointer, context: pointer): bool {.header: "../../../ext/imgui/cimgui/cimgui_backend_shims.h", importc: " ImGui_Shim_ImplSDL3_InitForOpenGL".}`, rather than using the `SDLWindow` type directly, for example
04:44:26FromDiscord<leorize> looks like a rendering issue to me tbh
04:45:00FromDiscord<devlop_gaming> In reply to @leorize "looks like a rendering": It's not a rendering issue
04:45:43FromDiscord<leorize> SDL\_CreateWindow should already be returning a pointer
04:46:08FromDiscord<leorize> there should be no need to `addr` the variable containing the result of that operation
04:46:24FromDiscord<devlop_gaming> In reply to @leorize "SDL\_CreateWindow should already be": It doesn't return one in the nim wrapper
04:46:26FromDiscord<leorize> similar story for SDL\_Renderer
04:46:56FromDiscord<leorize> it does, it's just inlined into the typedef
04:47:26FromDiscord<devlop_gaming> Then it woud say ptr SDL_Window but it doesn't now does it
04:47:36FromDiscord<leorize> the issue here seems to be that your SDL wrapper version of types are not the same as imgui
04:47:59FromDiscord<devlop_gaming> How do i fix this?
04:48:37FromDiscord<.tokyovigilante> It does depend on how he's wrapped it to be fair. Futhark gives me: `proc SDL_CreateWindow(title: cstring; w: cint; h: cint; flags: SDL_WindowFlags): ptr SDL_Window {.↵ cdecl, importc: "SDL_CreateWindow".}`
04:48:54FromDiscord<devlop_gaming> In reply to @.tokyovigilante "It does depend on": I didn't wrap these
04:48:58FromDiscord<.tokyovigilante> ie you should be able to pass the results of SDL_CreateWindow straight to Imgui
04:49:06FromDiscord<.tokyovigilante> How have you imported SDL from C?
04:49:15FromDiscord<devlop_gaming> I didn't
04:49:23FromDiscord<.tokyovigilante> Erm, you did
04:49:25FromDiscord<devlop_gaming> It's a nim package already wrapped
04:49:44FromDiscord<.tokyovigilante> ok, how does your nim package wrap SDL? I would strongly recommend using Futhark
04:49:54FromDiscord<leorize> I'm assuming that you're using this\: https://github.com/transmutrix/nim-sdl3/blob/915ff59eb4250c5f5b9eed80841cc9a98c19b266/src/sdl3.nim#L1215↵(@devlop_gaming)
04:50:31FromDiscord<devlop_gaming> In reply to @.tokyovigilante "ok, how does your": No it's a huge waste of time bc i don't know how to use it and figuring it out would take years which i don't have time for
04:51:18FromDiscord<devlop_gaming> In reply to @leorize "I'm assuming that you're": I think so
04:51:24FromDiscord<leorize> switch to this wrapper and it will work\:https://github.com/dinau/sdl3_nim
04:53:08FromDiscord<devlop_gaming> Uhm this says only available for windows.. I need it to work for both windows and linux.
04:53:34FromDiscord<leorize> then you're out of luck, imguin uses this wrapper
04:54:05FromDiscord<devlop_gaming> There's gotta be some way to cast it to the correct type right?
04:54:20FromDiscord<.tokyovigilante> sent a code paste, see https://play.nim-lang.org/#pasty=BOEaUHOs
04:54:25FromDiscord<.tokyovigilante> YEARS
04:54:33FromDiscord<.tokyovigilante> 😉
04:55:05FromDiscord<leorize> stop using addr and it might just work↵(@devlop_gaming)
04:55:05FromDiscord<devlop_gaming> In reply to @.tokyovigilante "YEARS": Bru we are two different people with different levels of understanding what do you not get
04:55:29FromDiscord<devlop_gaming> In reply to @leorize "stop using addr and": That still generates an error..
04:55:57FromDiscord<leorize> yea you gotta cast the raw pointer to the typed one
04:56:25FromDiscord<leorize> the other wrapper already defined SDL\_\ types as raw pointers
04:56:29FromDiscord<devlop_gaming> How do i do that?
04:59:29FromDiscord<.tokyovigilante> sent a long message, see https://pasty.ee/GATjfiTs
04:59:44FromDiscord<.tokyovigilante> (edit) "https://pasty.ee/QAnSWGaQ" => "https://pasty.ee/ZLblACpR"
05:01:21FromDiscord<devlop_gaming> In reply to @.tokyovigilante "No drama, its up": I'm not gonna mess with that. How do i cast?
05:02:11FromDiscord<.tokyovigilante> `cast[pointer](yourTypedPointer)`
05:02:46FromDiscord<.tokyovigilante> or `cast[anotherTypedPointer](yourTypedPointer)`
05:04:42FromDiscord<devlop_gaming> Soo cast[pointer](window)?
05:04:50FromDiscord<.tokyovigilante> In fairness I think this is a legitimate bug/consequence of the Nim FFI, I've had to change to raw pointers to get around what look like spurious type errors with C libs that reference each other (by forward declaring pointers to struct types)
05:05:14FromDiscord<.tokyovigilante> Yup but that won't work for you because your Imgui function is expecting a `ptr SDL_Window` not a `pointer`
05:05:40FromDiscord<devlop_gaming> so cast[ptr] then?
05:05:43FromDiscord<.tokyovigilante> this is what I'm getting at, you need to change the FFI function signature and have a C or C++ wrapper that casts it to the correct type.
05:05:54FromDiscord<.tokyovigilante> no, `ptr` isn't a type by itself I don't think
05:06:34FromDiscord<devlop_gaming> In reply to @.tokyovigilante "this is what I'm": I have no clue how to do that
05:08:27FromDiscord<.tokyovigilante> sent a code paste, see https://play.nim-lang.org/#pasty=PXGoBoZG
05:08:55FromDiscord<.tokyovigilante> See how I cast a `void ` (ie `pointer` in Nim) back to the real type (`ImDrawData `)
05:09:58FromDiscord<.tokyovigilante> sent a code paste, see https://play.nim-lang.org/#pasty=PJkknCZO
05:10:02FromDiscord<devlop_gaming> So i'd be creating a new function definition?
05:10:16FromDiscord<.tokyovigilante> to call that shim. It is annoying, and I think represents a Nim FFI or type system bug, but it does work
05:10:21FromDiscord<.tokyovigilante> yeah
05:12:08FromDiscord<.tokyovigilante> https://discord.com/channels/371759389889003530/371759389889003532/1339700952218730529 - I was once like you
05:17:17FromDiscord<.tokyovigilante> There are only a few Imgui backend functions for each backend, so not too onerous when set up.
05:33:37FromDiscord<devlop_gaming> I don't see a header file anywhere with these definitions so now what?
05:52:42FromDiscord<morgan (ping with reply)> so im trying to use nimpng and copy the iCCP block to a separate output, but the docs don't say anything on doing anything with other blocks it doesn't work with, anyone done similar? i don't see jangko on here to ask, tho maybe they're connected thru a bridge bot
05:58:58FromDiscord<.tokyovigilante> In reply to @devlop_gaming "I don't see a": you need to write the header for the backend public API
05:59:29FromDiscord<.tokyovigilante> sent a code paste, see https://play.nim-lang.org/#pasty=yWCoDGiX
06:00:05FromDiscord<.tokyovigilante> and in your nim wrapper file: `{.compile: "imgui_shims.cpp"}`
06:00:20FromDiscord<.tokyovigilante> Like I said, not ideal, but the only way I've found to deal with this.
06:00:34FromDiscord<.tokyovigilante> you could always ask in #gamedev, I assume most are using SDL, Imgui etc
06:10:01FromDiscord<devlop_gaming> In reply to @.tokyovigilante "you need to write": Can't someone just make a whole new sdl3 wrapper for me?
06:14:47FromDiscord<devlop_gaming> In reply to @.tokyovigilante "you need to write": Would changing the return type in the wrapper change anything?
06:15:25Amun-Rait looks like ImGui_Shim_ImplSDL3_InitForOpenGL works just like SDL's CreateWindowAndRenderer, it needs pointers to window and renderer (which are pointers already)
06:15:41FromDiscord<.tokyovigilante> You could try it, would probably accomplish the same thing, annoying to maintain someone else's wrapper though
06:17:16FromDiscord<devlop_gaming> In reply to @Amun-Ra "it looks like ImGui_Shim_ImplSDL3_InitForOpenGL": What's shim
06:18:09Amun-Rathe name of the function from your own paste ;)
06:21:29FromDiscord<devlop_gaming> Are you sure it's the types?
06:22:36Amun-RaI suspect whatever type that binding uses for Window and Renderer, you've to pass ptr to those types; what's the module name?
06:22:53FromDiscord<devlop_gaming> sdl3
06:23:06Amun-RaI mean the wrapper name
06:23:20FromDiscord<devlop_gaming> The gui lib?
06:23:49Amun-Rathe lib/module/… that declares ImGui_Shim_ImplSDL3_InitForOpenGL
06:24:34FromDiscord<devlop_gaming> If you mean the backend for sdl3 then imguin
06:28:32Amun-Raproc ImGui_ImplSDL3_InitForSDLRenderer*(window: ptr SDL_Window; renderer: ptr SDL_Renderer): bool
06:29:07Amun-Rayou have to pass just a window and renderer type, w/o an additional addr
06:29:42FromDiscord<devlop_gaming> Example?
06:31:16Amun-RaI just skimmed over the code
06:31:55FromDiscord<devlop_gaming> Show me what you mean please
06:32:49Amun-Rahave you initialized window and renderer?
06:34:51FromDiscord<devlop_gaming> Yes
06:35:39FromDiscord<devlop_gaming> https://media.discordapp.net/attachments/371759389889003532/1386595540673761351/image.png?ex=685a473a&is=6858f5ba&hm=7e7a600cb46aff6687ea6dd9438037339eb7cb60013546080c65f565c7c00dd6&
06:36:48Amun-Radevlop_gaming: remove all the addr-s
06:39:33FromDiscord<devlop_gaming> What do I do after that? I still get the error either way
06:40:59Amun-RaI don't see any imgui initialization in the code; you're mixing SDL3 bindings with imguin ones and I don't think that's going to work
06:41:14Amun-Rahttps://github.com/dinau/imguin_examples/tree/main/sdl3_opengl3
06:41:28Amun-RaI think that's the example you need
06:45:28FromDiscord<devlop_gaming> In reply to @Amun-Ra "I don't see any": Ohh I thought that was for imgui
06:50:44FromDiscord<devlop_gaming> Now im confused
06:51:44FromDiscord<morgan (ping with reply)> if you don't need an existing included ui library, i've found sokol pleasant to work with
06:52:21FromDiscord<devlop_gaming> Does it have dock support?
06:53:55FromDiscord<devlop_gaming> Wait is this a separate graphic library?
06:56:03*skippy8 joined #nim
06:57:16*kenran joined #nim
07:01:02*kenran quit (Remote host closed the connection)
07:01:32Amun-Raimgui can use several gui libs for the display; you don't use sdl3 directly
07:02:40FromDiscord<devlop_gaming> I rather stick to using sdl3 directly. It's the only thing I know how to do.
07:11:58Amun-RaI'd do the same
07:13:07FromDiscord<devlop_gaming> Im not even sure what the problem is
07:13:37Amun-Rain that case - no imgui initialization
07:13:58FromDiscord<devlop_gaming> How?
07:14:10Amun-Rasee that example
07:14:26FromDiscord<devlop_gaming> I did but in confused on how what I did is wrong?
07:14:50Amun-Rahttps://github.com/dinau/imguin_examples/blob/main/sdl3_opengl3/sdl3_opengl3.nim#L17
07:15:17Amun-Raif you want to use sdl3 directly, don't use imguin
07:16:09FromDiscord<devlop_gaming> I need imgui tho..
07:20:15FromDiscord<devlop_gaming> In reply to @Amun-Ra "if you want to": Can you just tell me what's wrong with my set upm
07:20:19FromDiscord<devlop_gaming> (edit) "upm" => "up?"
07:20:42Amun-Rasure, no call to createImGui
07:21:39FromDiscord<devlop_gaming> I don't even see a definition for it. Unless I am importing the wrong file?
07:21:53Amun-Rasee the example
07:25:47FromDiscord<devlop_gaming> Im so confused on what im looking for
07:27:42Amun-Raah, createImGui is another function imguin author(s) wrote in a dedicated utils/appImGuiSdl3.nim; I've never used imgui[n]
07:28:11Amun-Rait's not as high level as I thought it was
07:28:24FromDiscord<devlop_gaming> What file is it in?
07:28:50Amun-Rahttps://github.com/dinau/imguin_examples/blob/main/utils/appImGuiSdl3.nim
07:30:02FromDiscord<devlop_gaming> Just tell me bru. Linking isn't helping and I don't see what I am supposed to be looking for i looked everywhere twice and am still lost.
07:31:08Amun-Rathis is a file from the imguin examples, not the library itself; it looks like imguin is a mess to work with
07:31:40Amun-Rayou have to call whatever they call in that proc
07:35:15FromDiscord<devlop_gaming> I swear working with graphics in nim is near impossible
07:36:11FromDiscord<devlop_gaming> In reply to @Amun-Ra "you have to call": How am I supposed to do that if it's not inside the library
07:39:09Amun-Raare you asking how can you copy that file with all the files it depends on into your project?
07:39:38FromDiscord<devlop_gaming> No im asking how am I supposed to use that function if it only rxist in examples?
07:39:44FromDiscord<devlop_gaming> (edit) "rxist" => "exist"
07:39:51Amun-Racopy utils/
07:41:02FromDiscord<devlop_gaming> Where do I put it?
07:41:47Amun-Rawherever you want inside the project; I've never used imgui, can't help you with it
07:42:04Amun-RaI've to get back to work ;)
08:24:42*beholders_eye joined #nim
08:52:19*beholders_eye quit (Ping timeout: 268 seconds)
12:19:33FromDiscord<Zoom> @arnetheduck\: could you please tell me what's your specific issue with my PR is? I think I'm getting confused as to what's the point of all the discussion of all those implementation details is.
12:21:50FromDiscord<arnetheduck> I can see that 🙂 it boils down to this: in nim, `int` is tied to the pointer size - in C, it is not - so you cannot guarantee that a `clong` will always be a (nim) `int`, because this is not a guarantee supported by the C standard, and `clong` exists to match the C standard _as faithfully as possible_.
12:22:16FromDiscord<Zoom> All I wanted to fix is that the docs just say `clong = int` when in reality it's `when defined(windows): clong = int32 else: clong = int` so the rendered published docs lie for \~ half the users.
12:24:11FromDiscord<arnetheduck> In reply to @Zoom "All I wanted to": yes, so what you should say is that `clong = <an undefined integer type whose size and alignment matches a C long>` - this is a guarantee that we can maintain for all future nim versions
12:24:19FromDiscord<Zoom> The guarantees is not something that could be fixed with docs, it's just the issue with C types being defined in an interesting way. The code not compiling (on the Nim side) and docs saying it should is easily fixable.
12:25:05FromDiscord<Zoom> `<an undefined integer type whose size and alignment matches a C long>` Isn't it exactly what Nim's `int` is?
12:26:14FromDiscord<Zoom> Well, not exactly, I bet Nim `int` is not defined as `long`...
12:28:27FromDiscord<Zoom> Looks like we're disagreeing about the level of scrutiny the definition in the docs should be at. At this moment I'm fine with `clong` being defined in the docs the same way it's defined in the code (equal to nim's `int`/`int32`) without going deeper and explaining how `int`/`int32` are implementation dependent.
12:28:28FromDiscord<arnetheduck> Nim `int` is _approximately_ an `intptr_t` (an `intptr_t` can be both larger and smaller though, but they match in intent at least) but in reality, there exists no type in C which exactly matches `int` in nim
12:29:09FromDiscord<Zoom> I get that, but that's an issue with the docstring of the `int` type, not `clong`.
12:29:52FromDiscord<arnetheduck> it's indeed a problem of the doc string, but we can't fix it by making another statement about it that is _also_ wrong, just in a different way
12:30:25FromDiscord<Zoom> Depends on how you look at it. It's not wrong if the Nim compiler says it's ok and compiles.
12:35:12FromDiscord<Zoom> Now the docs don't even reflect the code being erroneous. I was trying to fix that.
12:35:13FromDiscord<Zoom> Now the docs don't even reflect the code, being erroneous in not reflecting OS-dependent discrepancies. I was trying to fix that.
12:36:46FromDiscord<random_user1999> chat what does nvidia modeset do
12:37:31*andy-turner joined #nim
12:37:48FromDiscord<arnetheduck> sure, again: a correct documentation string will say that the exact Nim type is _undefined_ - one of the things that documentation is good for is capturing intent that the compiler cannot reason about, like the possible types that we might want to use in the future for defining `clong`
12:39:16FromDiscord<Zoom> So you're saying this line is wrong? `clong {.importc: "long", nodecl.} = int32` (windows branch). It's a definition that determines if the code will compile or not. How is it not defined?↵(@arnetheduck)
12:40:59FromDiscord<arnetheduck> `int32` is an implementation detail - the existing documentation _implies_ this but doesn't state it (it assumes you derive this point by reading the corresponding C standard)
12:42:30*andy-turner quit (Quit: Leaving)
12:43:19FromDiscord<arnetheduck> we could use an `object` there instead and this would likely lead to less confusion / fewer footguns.. _that_ would be an interesting PR to make because then the compiler could be more helpful in letting Nim users write correct code without having to read the C standard
12:49:52FromDiscord<Zoom> Well, you're dodging my question but It follows you think the answer is `yes it is`, this means that there's an issue with the code that should be fixed, and your suggestions seem as the way to go. The PR was about fixing the docs issue in relation to the code in its current form.
12:50:57FromDiscord<Zoom> `int32` is `int32` in Nim. What it really is, is indeed an implementation detail. And that should be, as I said before, fixed in docstrings of the `int32`, `int` and friends, not just `clong`
12:54:59FromDiscord<Zoom> The problem I'm trying to solve is the fact that the current documentation system can't reflect the CT conditionals and don't reflect how Nim compiler works. You can work around it if you define the types in a smarter way, like you propose, but this approach has real implications to the code so is a solution to another problem entirely.
12:57:42FromDiscord<Zoom> I'm not sure what should I do if I don't want to mess with type definitions. Will repeating the stuff from the manual about `int`s implementation satisfactory?
12:58:22FromDiscord<Zoom> If we're going this way, I'm afraid it won't be satisfactory, because it shouldn't be just a warning to the specific type, but a huge explanation on top of the ctypes module.
13:00:26FromDiscord<Zoom> And I'm not confident in my knowledge to satisfactory explain all the relations of C ABI, specific compilers implementations, Nim implementation and differences in data models common to different architectures.
13:02:24FromDiscord<arnetheduck> sent a long message, see https://pasty.ee/jqWvrBCh
13:06:25FromDiscord<Zoom> sent a long message, see https://pasty.ee/bMGWUnww
13:07:52FromDiscord<Zoom> The bug you're talking about is already there, in the definition line reflected in the docs\: `clong {.importc: "long", nodecl.} = int`
13:08:29FromDiscord<arnetheduck> ok, so let's turn it around: why would you not write that it's an implementation detail? this seems to be the thing that caught you off guard
13:10:19FromDiscord<Zoom> Well, nothing caught me off guard, I didn't write the code that didn't compile, I just noticed that the docs don't reflect the code as it is.
13:12:15FromDiscord<Zoom> I wouldn't write that because this won't change the fact that `clong` is defined as `int` or `int32`, and being cautious while converting between C and Nim types demands a more torough explanation, otherwise a simple warning will be as "between correct and not" as the code itself and so of not much help
13:16:01FromDiscord<arnetheduck> the docs already reflect the code though - the additional information they provide allows you to deduce that `int32` is an implemenation detail and is not to be taken literally on _any_ platform
13:17:06FromDiscord<Zoom> Well, the code literally didn't compile while the docs say it should \:D
13:19:55FromDiscord<Zoom> Well, the code literally didn't compile while the docs say it should have \:D
13:22:15FromDiscord<arnetheduck> sent a long message, see https://pasty.ee/tQwRwENW
13:22:26FromDiscord<arnetheduck> (edit) "https://pasty.ee/pNBwwlna" => "https://pasty.ee/yNIdGeyr"
13:24:58FromDiscord<arnetheduck> sent a code paste, see https://play.nim-lang.org/#pasty=qTvAtMzt
13:26:37FromDiscord<arnetheduck> in the unlikely event that a user reads the docs, they will at least not make assumptions based on them - we'll still get code that doesn't compile on some platforms but at least "we told you so"
13:27:02FromDiscord<Zoom> The docs don't guarantee nothing, it's not a spec. They should, however, follow the code and when another branch is introduced in this module, the docs should reflect that.↵> your PR contradicts the existing documentation↵This is probably the crux. Perhaps I don't understand something, but to my eyes my PR describes the code satisfactory. Is the problem rooted in the fact that the code defines the `clong` type with the `importc` pragma a
13:27:59FromDiscord<arnetheduck> > defines the clong type with the importc pragma and Nim type equality at the same time?↵yes, this
13:28:27FromDiscord<Zoom> > yes, well, this is because the author of said code likely didn't read the docs or do their due diligence of the relevant standards↵No, the author didn't intend to write a portable code. The code is fine, the docs weren't reflecting the reality of compiling the code under different OS
13:29:06FromDiscord<arnetheduck> you could say that `importc` in this overrides nim semantics with c semantics, and it gets muddy
13:35:04*jjido joined #nim
13:36:14FromDiscord<arnetheduck> here's an example of another type with a similar issue: https://github.com/nim-lang/Nim/blob/devel/lib/std/time_t.nim
13:38:41FromDiscord<arnetheduck> In reply to @Zoom "The docs don't guarantee": > The docs don't guarantee nothing, it's not a spec. ↵the docs are there to capture intents that cannot be expressed in the programming language, to guide developers to make better decisions for the future - if we were to accept your PR, users would be mislead into thinking that `clong = int` on any future platform _as well_, the way you phrased it - they would then be (rightly) upset
13:39:03FromDiscord<arnetheduck> (edit) "In reply to @Zoom "The docs don't guarantee": > The docs don't guarantee nothing, it's not a spec. ↵the docs are there to capture intents that cannot be expressed in the programming language, to guide developers to make better decisions for the future - if we were to accept your PR, users would be mislead into thinking that `clong = int` on any future ... platform" added "non-windows"
13:39:57FromDiscord<Zoom> Yeah, I'm trying wording this in different ways and I can't see a satisfactory way to explain both barrels of the footgun (the implementation-defined nature and doc rendering deficiency) without changing the definition.
13:40:28FromDiscord<arnetheduck> more on this topic: https://github.com/nim-lang/Nim/issues/24613
13:41:00FromDiscord<Zoom> That's where I sthink you're still wrong. The users will be mislead by the definition as rendered by the docs, not by the docstrings.↵(@arnetheduck)
13:41:53FromDiscord<arnetheduck> In reply to @Zoom "That's where I sthink": that's why I'm suggesting that you write a `when defined(nimdoc)` condition so that the rendered doc displays "undefined" as well
13:42:09FromDiscord<arnetheduck> see the time_t example
13:42:40FromDiscord<Zoom> I agree, see above.↵(@arnetheduck)
13:43:38FromDiscord<Zoom> That's why I asked about the C standard in my PR comments...↵(@arnetheduck)
13:48:34*beholders_eye joined #nim
13:50:23FromDiscord<arnetheduck> indeed, and the C standard says that it's all very loosely defined - ie not even `intptr_t` provides guarantees strong enough for Nim, much less so for types like `clong` whose raison d'etre is to avoid the argument entirely and just delegate this responsibility to the C compiler - there's little point using these types unless you're trying to write portable code - portable in the sense of being interoperable with C and using its way
13:53:11*jjido quit (Quit: My laptop has gone to sleep. ZZZzzz…)
14:10:54*beholders_eye quit (Ping timeout: 260 seconds)
14:50:15*beholders_eye joined #nim
15:27:58FromDiscord<Zoom> @arnetheduck\: the hack didn't work \:( https://github.com/nim-lang/Nim/actions/runs/15828215385
15:43:04*beholders_eye quit (Ping timeout: 260 seconds)
15:57:35FromDiscord<Zoom> Exactly as I expected, now this PR will hang there unmerged forever because I don't understand how to fix all those errors that arise from complicated CT branchings everywhere and some code trying to compile itself with `nim doc`.
16:06:41*beholders_eye joined #nim
16:13:37*jjido joined #nim
16:24:36*jjido quit (Quit: My laptop has gone to sleep. ZZZzzz…)
17:18:52*jjido joined #nim
17:49:12FromDiscord<noctis0x1> sent a code paste, see https://play.nim-lang.org/#pasty=ilTbIVtQ
17:49:47FromDiscord<noctis0x1> sent a code paste, see https://play.nim-lang.org/#pasty=jyClYoGv
17:50:41FromDiscord<noctis0x1> (edit) "https://play.nim-lang.org/#pasty=TNNihtka" => "https://play.nim-lang.org/#pasty=LTETKCSi"
17:58:52FromDiscord<solitudesf> In reply to @noctis0x1 "nim lsp features not": whats your nim version?
18:14:44*jjido quit (Quit: My laptop has gone to sleep. ZZZzzz…)
18:33:35*pbsds356 joined #nim
18:34:36*m5zs7k_ joined #nim
18:41:56*m5zs7k quit (*.net *.split)
18:41:56*redj quit (*.net *.split)
18:41:56*fallback quit (*.net *.split)
18:41:56*FromDiscord quit (*.net *.split)
18:41:56*pbsds35 quit (*.net *.split)
18:41:59*pbsds356 is now known as pbsds35
18:42:02*FromDiscord joined #nim
18:43:41*m5zs7k_ is now known as m5zs7k
18:53:43*jjido joined #nim
18:56:05*beholders_eye quit (Ping timeout: 252 seconds)
19:18:28*redj joined #nim
19:18:29*fallback joined #nim
19:18:34*redj quit (Max SendQ exceeded)
19:18:57*redj joined #nim
19:35:49Amun-RaZoom: long, culong etc are not OS-dependent, they are more architecture dependent
19:35:59*FromDiscord quit (Remote host closed the connection)
19:36:12*FromDiscord joined #nim
19:37:07Amun-Raor, as C standard states, implementation-defined
19:37:43*fallback quit (*.net *.split)
19:51:38*fallback joined #nim
19:58:37*jjido quit (Quit: My laptop has gone to sleep. ZZZzzz…)
20:02:09*beholders_eye joined #nim
20:23:19*beholders_eye quit (Ping timeout: 244 seconds)
20:27:21*jjido joined #nim
20:28:55*jjido quit (Client Quit)