<< 13-10-2025 >>
00:06:58*Mister_Magister quit (Quit: bye)
00:09:33*Mister_Magister joined #nim
00:24:46*radicalned quit (Ping timeout: 256 seconds)
00:28:47*radicalned joined #nim
01:02:38*syl quit (Quit: C-x C-c)
01:02:43*Mister_Magister quit (Quit: bye)
01:03:05*Mister_Magister joined #nim
01:04:28*void09 quit (Ping timeout: 260 seconds)
01:05:09*Guest15 joined #nim
01:05:30*Guest15 quit (Client Quit)
01:05:34*radicalned quit (Ping timeout: 256 seconds)
01:05:40*syl joined #nim
01:08:40*void09 joined #nim
01:10:33*radicalned joined #nim
01:12:30*void09_ joined #nim
01:14:01*gshumway quit (Ping timeout: 256 seconds)
01:16:15*gshumway joined #nim
01:17:36*void09 quit (Ping timeout: 246 seconds)
01:17:36*syl quit (Ping timeout: 246 seconds)
01:17:37*Ekho quit (Ping timeout: 246 seconds)
01:17:37*bgupta quit (Ping timeout: 246 seconds)
01:17:44*syl joined #nim
01:20:18*bgupta joined #nim
01:30:42*radicalned quit (Ping timeout: 260 seconds)
01:32:17*Ekho joined #nim
01:37:28*radicalned joined #nim
03:12:55*ainema joined #nim
04:35:51FromDiscord<kapendev> Imo wrapping a C library because it does not feel like Nim is not a good reason. You don't really gain anything from it, except that now things feel safer and look nicer. The better idea is to just use it as is. It's easier to think about stuff, to follow tutorials online, and the wrapper part will naturally form and be actually useful.
04:55:24FromDiscord<ieltan> In reply to @kapendev "Imo wrapping a C": > wrapping a C library because it does not feel like Nim is not a good reason↵Wrapping a C library and making it idiomatic is two completely different things
04:55:56FromDiscord<ieltan> You usually wrap because the library is too massive and it's easier to just write bindings to it than rewrite it in Nim
04:56:42FromDiscord<ieltan> Now, I'm sure that you know python have a tons of libraries that are just bindings to c code because otherwise it would be too slow
04:57:19FromDiscord<ieltan> Yet you don't see anything c-like on the python side because that the c way is inherently unsafe
04:57:50FromDiscord<Elegantbeef> Their statement is a void statement
04:58:17FromDiscord<ieltan> Rust is the same, nobody binds a library and just tell people to use it bare with `mut ` and `const `... WELL GUESS WHAT this applies to Nim too lol
04:58:56FromDiscord<Elegantbeef> "You don't wrap a C library a C library in Nim idiomatic code, you use the code and naturally wrap the C library in Nim idiomatic code"
04:59:03FromDiscord<Elegantbeef> "You don't wrap a C library in Nim idiomatic code, you use the code and naturally wrap the C library in Nim idiomatic code"
04:59:05FromDiscord<kapendev> It makes sense for Python because Python is not a "systems lang", and what I mean by this is doing pointer stuff.
04:59:12FromDiscord<ieltan> In reply to @Elegantbeef ""You don't wrap a": Lmao
04:59:35FromDiscord<kapendev> In reply to @Elegantbeef ""You don't wrap a": Yes. That is how it works. Everything else is kinda wasting time.
04:59:47FromDiscord<ieltan> In reply to @kapendev "It makes sense for": No that's not why oh my god
05:00:49FromDiscord<ieltan> Do you know why people wrap c libraries?
05:00:59FromDiscord<ieltan> Why do people bother instead of just writing Nim code
05:01:04FromDiscord<ieltan> Or python code
05:01:06FromDiscord<ieltan> Or rust code
05:01:27FromDiscord<ieltan> Or another language that I don't use lol 🙃
05:01:34FromDiscord<kapendev> I know that people like to spend time on things that don't matter like idiomatic code
05:02:14FromDiscord<ieltan> Is that so? :thinkjoy:
05:03:20FromDiscord<kapendev> Tell me what you gain from an idiomatic nim wrapper binding thingy?
05:03:47FromDiscord<Elegantbeef> If it's built from sensible principles, a usable library
05:04:08FromDiscord<Elegantbeef> An idiomatic Nim binding is indistinguishable from what you're implying
05:04:24FromDiscord<Elegantbeef> Why expose a `ptr T, size` when you can expose `openArray[T]`
05:04:25FromDiscord<kapendev> C is already usable.
05:04:55FromDiscord<Elegantbeef> The abstractions you're describing are the abstractions people make when they use the library
05:05:12FromDiscord<Elegantbeef> So it's pretty silly to act like idiomatic bindings
05:05:19FromDiscord<Elegantbeef> So it's pretty silly to act like idiomatic bindings are bad
05:05:42FromDiscord<kapendev> In reply to @Elegantbeef "Why expose a `ptr": Is it silly to just pass the values instead of making a wrapper?
05:05:50FromDiscord<Elegantbeef> Yes
05:05:50*radicalned quit (Ping timeout: 256 seconds)
05:05:52FromDiscord<kapendev> No
05:06:00FromDiscord<Elegantbeef> Yes cause you're going to make the wrapper
05:06:23FromDiscord<kapendev> No because you just wrote code for something really simple
05:06:24FromDiscord<Elegantbeef> You're going to go "Oh boy it's dumb that I have to manually conver collections to a ptr I should write a procedure that is an overload to this operation"
05:06:50FromDiscord<Elegantbeef> Good bindings come from actual usage and not from just guessing how things are used
05:07:02FromDiscord<ieltan> In reply to @kapendev "C is already usable.": Yeah, it's ""usable"" I guess lol. Might has well wonder why any other language than C exists and why do i bother writting C code in Nim when I can just write it in actual real C amarite
05:07:05FromDiscord<Elegantbeef> Exposing the C is good and all, but if you're going to use a library you're going to abstract it
05:07:21FromDiscord<ieltan> (edit) "has" => "as"
05:07:48FromDiscord<Elegantbeef> Who the hell is using opengl without making material, shader, texture, framebuffer, and other GL object abstractions
05:08:26FromDiscord<kapendev> Good bindings are the ones that are 1-1. People can actually use the C docs then to write stuff instead of searching for the docs that don't exist in Nim land.
05:09:53FromDiscord<Elegantbeef> I'm more than happy to use the C api to build a good library in Nim, I do want the C exposed, but I much prefer if there is an existent API that does not make me pretend that I'm writing a language written in 1903
05:10:07FromDiscord<ieltan> In reply to @kapendev "Good bindings are the": This is not a problem in practice, bindings can be 1-1 and idiomatic, libmdbx-rs for example. I just use the c docs
05:10:46FromDiscord<Elegantbeef> `set[T]` and `openArray[T]` are the single greatest counter example to naive C bindings in my view
05:10:58FromDiscord<ieltan> And nothing prevents you from exposing the low level API alongside the high level, idiomatic one
05:11:14FromDiscord<Elegantbeef> `set[T]` directly relates an enum to the bitset meaning you can do logic on it. It also is type safe so prevents passing any random int32
05:11:18FromDiscord<ieltan> All your complaints so far haven't been grounded to reality...
05:12:02FromDiscord<kapendev> Guys, you are making it harder to use a library. As u user, if I want to use a C lib, then that means I want the C api. Not a nim api.
05:12:18FromDiscord<Elegantbeef> Nope
05:12:40FromDiscord<kapendev> I never said to myself that I want to use naylib. I want to use raylib.
05:12:58FromDiscord<Elegantbeef> I want to write code I do not particularly care whether someone wrote the code in Nim or if the code wraps C. I want a working project
05:13:11FromDiscord<kapendev> C code works.
05:13:20FromDiscord<Elegantbeef> Totally if you hate yourself
05:14:06FromDiscord<kapendev> Sure, if you don't like it then make a wrapper and call it nimybob instead of just bob.
05:14:08FromDiscord<ieltan> In reply to @kapendev "C code works.": That's totally cool with me, you can write c code all day long if that's your cup of tea 😅
05:14:34FromDiscord<Elegantbeef> Nah I think I'll include `cbob.nim` and `bob.nim`↵(@kapendev)
05:14:53FromDiscord<Elegantbeef> `cbob.nim` is going to be c2nim or futhark'd `bob.h`
05:15:08FromDiscord<ieltan> For some reason you really think you can't have one or the other when you can...
05:15:14FromDiscord<Elegantbeef> But I'm only going to sugget using `bob.nim` cause the point is to not cause myself or others pain
05:16:29FromDiscord<kapendev> Now you make things confusing. I have seen people here ask about why things work in X ways instead of Y ways when using naylib for example because they expect raylib.
05:16:39FromDiscord<Elegantbeef> Cool
05:17:09FromDiscord<Elegantbeef> People are confused about naylib's use of Nim features to make it easier to write code that does not leak
05:17:27FromDiscord<kapendev> Making things confusing is an easy way to make people drop the language.
05:17:28FromDiscord<Elegantbeef> I fail to see how that's a bad thing
05:17:39FromDiscord<Elegantbeef> "Oh no I have to learn the language I'm using!"
05:18:00FromDiscord<Elegantbeef> Personally I don't learn any language semantics and solely write Rust with `unsafe{}`
05:18:19FromDiscord<Elegantbeef> I do not get why people do not make more bindings that are fully unsafe rust!
05:18:24FromDiscord<kapendev> That's not what I'm saying. We ate talking about interacting with C code.
05:18:35FromDiscord<kapendev> (edit) "ate" => "are"
05:19:20FromDiscord<Elegantbeef> And rust interacts with C inside unsafe blocks
05:19:28FromDiscord<Elegantbeef> So it's the same thing!
05:20:28FromDiscord<Elegantbeef> Common patterns and logic that will be written by users should be abstracted by the library imo, if you disagree that's cool. We'll never agree
05:22:04FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=BquPPWbl
05:23:48FromDiscord<Elegantbeef> As a nice counter point you might do `while(pollEvent(&evt)){}` in C. If you are learning Nim, but not C that's confusing
05:23:53FromDiscord<Elegantbeef> Wait `while pollEvent(evt.addr)` complains that `bool` expected but found `int`
05:25:24FromDiscord<ieltan> Well yeah, bool doesn't exist in C99. Just be a good person and keep using int right
05:25:43FromDiscord<ieltan> 🥲
05:26:39FromDiscord<Elegantbeef> Should've just returned `Event` like a good program
05:27:04FromDiscord<Elegantbeef> "This function returns the given struct if it has a value, otherwise it returns 0"
05:46:34FromDiscord<kiloneie> In reply to @ieltan "Well yeah, bool doesn't": That explains the numerical returns in c++ and similar...
05:47:06FromDiscord<kiloneie> The simplest c++ program, end with `return 0`...
06:32:13*cm_ joined #nim
06:33:22*cm quit (Ping timeout: 256 seconds)
06:33:23*cm_ is now known as cm
07:29:41FromDiscord<Robyn [She/Her]> In reply to @kiloneie "The simplest c++ program,": Well that's the exit code
07:29:47FromDiscord<Robyn [She/Her]> I'd say that's different
07:31:23FromDiscord<kiloneie> In reply to @battery.acid.bubblegum "Well that's the exit": Bad example, but i've seen it other places that i can't remember.
07:32:12FromDiscord<Robyn [She/Her]> Yeah most APIs with boolean return values will return 1 rather than 'true', I know what ya mean
07:36:47Amun-Raieltan: what do you mean bool doesn't exist in c99?
07:37:38Amun-Raboth, _Bool and stdbool.h were introducend in c99 specifically
07:37:51FromDiscord<Robyn [She/Her]> I just realised that oops
07:42:34*SchweinDeBurg quit (Quit: WeeChat 4.8.0-dev)
07:43:22*SchweinDeBurg joined #nim
07:53:02FromDiscord<ieltan> In reply to @Amun-Ra "both, _Bool and stdbool.h": Oh oops, i was thinking of C89/C90 😭
07:53:16FromDiscord<ieltan> ansi c
08:06:34*beholders_eye joined #nim
08:25:53FromDiscord<nnsee> In reply to @kapendev "That's not what I'm": I don't understand. You want to use Nim with C libraries but don't want any of the benefits that Nim offers (which is what _idiomatic_ implies). So it just sounds like you want to write C? Why use Nim at all at that point?
08:52:33Amun-Raieltan: I'm not trying to be too picky byt contrary to popular "ansi c" being c89, "ansi c" is the latest standard revision ;)
08:53:07FromDiscord<kapendev> No. I want to use a C library as is with the help of its docs. Nothing to do with Nim. You can apply what I say to almost every language. Me having to look at the "idiomatic bindings" code to find how I can use X function is bad UX. Me not being able to use some stuff of a C library because the "idiomatic bindings" decided that it should make some fields or functions private is bad UX.
08:53:59FromDiscord<kapendev> In reply to @ieltan "Well yeah, bool doesn't": Changing a byte to a bool in the bindings in not an abstraction or a wrapper thing.
08:57:10FromDiscord<ieltan> In reply to @Amun-Ra "<@256520101015060480>: I'm not trying": As you can see, I hardly keep track of C's many iterations :p
08:57:16FromDiscord<ieltan> (edit) "In reply to @Amun-Ra "<@256520101015060480>: I'm not trying": As you can see, I hardly keep track of C's many ... iterations" added "standard"
08:57:33Amun-Raieltan: you don't miss much, C hardly even changes… ;)
08:58:10FromDiscord<ieltan> sent a code paste, see https://play.nim-lang.org/#pasty=lQqnoAsM
08:59:00FromDiscord<nnsee> In reply to @kapendev "No. I want to": I don't see how one thing implies the other. Beef mentioned two times that you can have the raw C API exposed. That can coexist with the sane API for people who actually want to use the language they're writing. Most Nim libraries that declare themselves to be wrappers do it this way. I haven't used naylib, but the naylib documentation itself points to the C API.
08:59:20FromDiscord<ieltan> Should be a valid type since it's passed as the "nothing" argument
08:59:33FromDiscord<nnsee> If you feel like a library is providing "bad UX" for your specific use case, wrapping a library yourself using something like Futhark is easy as pie
08:59:39FromDiscord<nnsee> I don't really see the issue here
09:00:11FromDiscord<kapendev> In reply to @nnsee "I don't see how": You can do that, but making the Nim wrapper the default just creates confusion. You should explicitly opt-int to it.
09:00:16FromDiscord<ieltan> just drop it ras, this man just wants to eat his Cs raw
09:00:26FromDiscord<kapendev> (edit) "opt-int" => "opt-in"
09:00:48FromDiscord<kapendev> Sure, I like to use C libraries instead of writing wrappers all day.
09:00:56FromDiscord<nnsee> In reply to @kapendev "You can do that,": Making Nim the default for a Nim library creates confusion? I'll have to disagree on that one
09:01:16FromDiscord<nnsee> You know what _is_ confusing and "bad UX"? Having C ergonomics on a Nim library
09:01:17FromDiscord<kapendev> Don't know if the Discord comments agree with you.
09:02:05FromDiscord<ieltan> In reply to @kapendev "Sure, I like to": You can write C all day long in Nim while other people enjoy real Nim. The language is just that good, it's a win-win situation 😛
09:02:17FromDiscord<kapendev> Guys, you also assume you will write good wrappers. 99% of the time people don't know what they are doing.
09:02:59FromDiscord<ieltan> Well that's a different situation, I assume people writing wrappers are at least familiar with both languages and the library in question
09:03:06FromDiscord<kapendev> In reply to @ieltan "You can write C": The wrapper is still C code... You are interacting with it...
09:03:09FromDiscord<ieltan> moving the goal posts a little bit there
09:03:19FromDiscord<kapendev> Nothing is Nimy about it.
09:03:49FromDiscord<ieltan> In reply to @kapendev "The wrapper is still": In Araq's words "oh god not this again"
09:04:59FromDiscord<ieltan> C basically abstract assembly, you're litteraly interacting with assembly, might has well use it
09:05:22FromDiscord<kapendev> In reply to @ieltan "C basically abstract assembly,": Have you written anything useful?
09:05:28FromDiscord<ieltan> 🥀
09:05:55FromDiscord<ieltan> Just write your C bro its not that deep
09:06:09FromDiscord<nnsee> I still don't understand if you want to use the C API with the C ergonomics referring to the C API documentation why you're not using C? What is the point of writing Nim if you don't want to use Nim?
09:06:19FromDiscord<kapendev> In reply to @ieltan "Just write your C": But I am not writting C code. I am using it.
09:06:24FromDiscord<kapendev> (edit) "writting" => "writing"
09:06:46FromDiscord<tauruuuuuus> I feel like the main channel has been degrading lately into a mess of strange and derailed takes on programming lol
09:07:24FromDiscord<kapendev> In reply to @nnsee "I still don't understand": Ergonomics is a marketing and user thing. The point of writing Nim is to write Nim code and not to write wrappers.
09:07:43FromDiscord<nnsee> I literally have no clue what you mean by this, sorry
09:07:52FromDiscord<kapendev> My point is to just use the library.
09:08:12FromDiscord<nnsee> I don't understand how that statement is related to what I asked
09:08:28FromDiscord<kapendev> What did you ask? I have no idea.
09:08:59FromDiscord<nnsee> ... huh?
09:09:19FromDiscord<nnsee> Not sure if you're trolling or something but I give up
09:10:07FromDiscord<ieltan> I'm as confused
09:10:36FromDiscord<kapendev> I am trolling when I say that I want to use a C library from Nim without any opinions attached to it.
09:12:09FromDiscord<kapendev> I don't need docs. I like having to ask on Discord how things work.
09:12:09FromDiscord<albassort> what does that mean
09:12:19FromDiscord<albassort> what
09:13:00FromDiscord<kapendev> I'm saying that I like good code.
09:13:10FromDiscord<albassort> You're sying nothing, you're babblign incoherently
09:13:15FromDiscord<albassort> (edit) "sying" => "saying"
09:13:18FromDiscord<albassort> (edit) "babblign" => "babbling"
09:13:24FromDiscord<kapendev> You just said what.
09:13:26FromDiscord<ieltan> Oh my motte and Bailey
09:13:28FromDiscord<nnsee> I think they're trying to be sarcastic. But this is getting a bit personal so let's drop this, please
09:13:57FromDiscord<nnsee> The conversation seems to be leading nowhere
09:14:05FromDiscord<ieltan> I agree lol
09:14:29FromDiscord<albassort> In reply to @nnsee "I think they're trying": sarcastic about what, they're being cryptic and imprecise and oddly demeaning
09:14:41FromDiscord<kapendev> Sorry to make you feel bad.
09:15:03FromDiscord<ieltan> fuggetabuddit
09:15:06FromDiscord<ieltan> anyways
09:15:09FromDiscord<ieltan> https://discord.com/channels/371759389889003530/371759389889003532/1427218846267478091
09:15:59FromDiscord<ieltan> Do you think a PR patch to the compiler would be the solution ? I really want the `GlobalAllocator` to be a distinct void
09:16:29FromDiscord<albassort> distinct void? I've never seen that.
09:16:58FromDiscord<0xfab_10> what if object with no fields
09:17:10FromDiscord<albassort> im not sure like, what you t hink a distinct void would be, it has to exist in memory somehow
09:17:14FromDiscord<albassort> (edit) "t hink" => "think"
09:17:26FromDiscord<ieltan> In reply to @albassort "distinct void? I've never": thanks beef
09:17:26FromDiscord<0xfab_10> zero sized type
09:17:32FromDiscord<ieltan> In reply to @albassort "im not sure like,": no it's zero sized
09:17:49FromDiscord<ieltan> the goal is that i have a smart pointer that support custom allocators
09:17:55FromDiscord<0xfab_10> you'll have to get nim to support ZSTs
09:18:16FromDiscord<albassort> In reply to @ieltan "thanks beef": im not beef-kun ;-;
09:18:25FromDiscord<0xfab_10> c/c++ don't have those and that's what nim usually follows
09:18:43FromDiscord<ieltan> the smart pointer is like 8 bytes alone without any allocator attached
09:18:56FromDiscord<albassort> distinct uint8
09:19:01FromDiscord<albassort> :p
09:19:55FromDiscord<ieltan> so if `GlobalAllocator` is an `object`that will take 1 more byte so you'll think it's nothing just a 9 byte smart pointer except that accounting for padding it actually jumps to 16 bytes lol
09:20:18FromDiscord<ieltan> "but it's nothing" shush, this frustrates me to NO END.
09:20:31FromDiscord<0xfab_10> nim silliness. where are the unit types
09:21:40FromDiscord<0xfab_10> can't have zero sized empty structs/classes in c/c++ either :p
09:21:49FromDiscord<ieltan> so this lil trick called `distinct void` elides the field supposed to store the allocator so i can just use `GlobalAllocator.allocate()`
09:21:55FromDiscord<albassort> In reply to @fabric.input_output "can't have zero sized": this is why the concept is very foreign to me
09:22:15FromDiscord<ieltan> except GlobalAllocator in this context is a `typedesc` that doesn't fit my `Allocator` concept
09:22:51FromDiscord<ieltan> so i have to do this silly thing using the "nothing" argument idk whats the real term for it↵`proc allocate(_: GlobalAllocator, size: Natural): pointer`
09:23:16FromDiscord<ieltan> this should in theory go along with void since it's an argument that's never instanciated and void must never be instanciated
09:23:47FromDiscord<ieltan> but the damn thing does not work...
09:24:29FromDiscord<albassort> im not seeing the theory line up from the compilers perspective lol
09:24:46FromDiscord<ieltan> why not ?
09:24:50FromDiscord<0xfab_10> In reply to @albassort "im not seeing the": what's the compiler's perspective?
09:27:03FromDiscord<albassort> there is no ZST
09:27:42FromDiscord<0xfab_10> so just don't emit anything about them :]
09:28:05FromDiscord<ieltan> sent a code paste, see https://play.nim-lang.org/#pasty=uepDTZdJ
09:28:35FromDiscord<ieltan> sent a code paste, see https://play.nim-lang.org/#pasty=GzpAuHuV
09:29:40FromDiscord<0xfab_10> wait I thought void args didn't work
09:30:18FromDiscord<ieltan> In reply to @fabric.input_output "wait I thought void": notice how im not using the argument
09:30:35FromDiscord<ieltan> now im curious what the c-gen looks like, i bet you there is actually no argument at all
09:31:06FromDiscord<0xfab_10> hm so it breaks only when you use it? checks out
09:31:10FromDiscord<0xfab_10> still silly
09:31:29FromDiscord<0xfab_10> not sure if anything else got ZSTs besides rust. maybe zig
09:32:37FromDiscord<albassort> In reply to @fabric.input_output "not sure if anything": ....rust
09:33:40FromDiscord<ieltan> sent a code paste, see https://play.nim-lang.org/#pasty=eukzwZDV
09:34:31FromDiscord<ieltan> sorry this is actually ineligible
09:35:02FromDiscord<ieltan> anyways
09:35:31FromDiscord<ieltan> what i mean to say is that it already works for `void` just let me pass a `distinct void `
09:36:14FromDiscord<ieltan> though there's the whole thing aboit it being replaced by `tuple[]` but im not patient to wait until then and im not even sure what that replacement would look like
09:39:43FromDiscord<0xfab_10> wonder why they can't just do it tbh
10:03:01FromDiscord<pmunch> Do we have any libraries in Nim for doing Server-Sent Events? I'm having a look at Datastar ATM
10:08:04FromDiscord<pmunch> sent a code paste, see https://play.nim-lang.org/#pasty=dOmwZJLp
10:08:37FromDiscord<pmunch> That turns into a `N_LIB_PRIVATE N_NIMCALL(void, thingtesttaticarg_u5)(void)`
10:10:31FromDiscord<ieltan> sent a code paste, see https://play.nim-lang.org/#pasty=AOolHMQk
10:11:21FromDiscord<ieltan> supporting either `T` OR `typedesc` is 🌬️
10:12:44FromDiscord<pmunch> What kind of pattern is it you're trying to support though?
10:12:55FromDiscord<ieltan> In reply to @pmunch "Do we have any": I'm not familiar with the concept but from the quick google ive done this sounds awfully familiar with websockets
10:14:45FromDiscord<ieltan> sent a code paste, see https://play.nim-lang.org/#pasty=vOglbEyy
10:15:06FromDiscord<ieltan> (edit) "https://play.nim-lang.org/#pasty=tHiREfkv" => "https://play.nim-lang.org/#pasty=vxFsMCRR"
10:15:23FromDiscord<pmunch> In reply to @ieltan "I'm not familiar with": It seems like some sort of open connection HTTP under the hood
10:16:34FromDiscord<pmunch> But do you want to store the allocator information at all?
10:16:39FromDiscord<pmunch> In every object I mean
10:16:40FromDiscord<ieltan> In reply to @pmunch "It seems like some": this sounds like it's basically websockets except unidirectional
10:18:15FromDiscord<ieltan> In reply to @pmunch "In every object I": If Allocator is 1 sized, i assume there is no reason to story information store it except that i need to know which of my 1 sized allocator to allocate and destroy with
10:18:45FromDiscord<ieltan> Box[T, A] in rust does this by special casing `Global`
10:19:05FromDiscord<ieltan> and any ZST dont take space anyways
10:20:25FromDiscord<ieltan> this would legit be done and all if `distinct void`worked on underscore arguments
10:20:34FromDiscord<ieltan> just like `void` does
10:28:32FromDiscord<pmunch> sent a code paste, see https://play.nim-lang.org/#pasty=dVfvUNRk
10:29:02FromDiscord<pmunch> The code code generated for the call to thing is still `N_LIB_PRIVATE N_NIMCALL(void, thingtesttaticarg_u98)(void)`
10:29:40FromDiscord<pmunch> Or rather it creates two separate calls, both with void/void, and then calls one or the other statically
10:30:13FromDiscord<pmunch> sent a code paste, see https://play.nim-lang.org/#pasty=CVepAfns
10:31:58FromDiscord<ieltan> well yeah that would work if i only wanted to support `GlobalAllocator.thing()`
10:32:51FromDiscord<ieltan> what if my CustomAllocator did have information such as when made from an arena allocator ?
10:33:20FromDiscord<ieltan> https://docs.rs/bumpalo/latest/bumpalo/index.html#bumpaloboxedbox
10:34:34FromDiscord<ieltan> cant just get away with just a `typedesc[ArenaAllocator]`...
11:18:18*radicalned joined #nim
11:20:40*beholders_eye quit (Ping timeout: 246 seconds)
11:22:40*radicalned quit (Ping timeout: 256 seconds)
11:39:04*ainema left #nim (#nim)
12:04:50*fallback quit (Quit: IRCNow and Forever!)
12:14:43*fallback joined #nim
13:58:54FromDiscord<pmunch> With multiple instances of the same allocator running in the same program?
13:59:19FromDiscord<pmunch> Or rather, with a dynamic number of instances
14:51:59*beholders_eye joined #nim
15:58:42*beholders_eye quit (Ping timeout: 260 seconds)
16:06:56*radicalned joined #nim
16:12:48*radicalned quit (Ping timeout: 256 seconds)
16:24:33*radicalned joined #nim
16:45:40*radicalned quit (Ping timeout: 256 seconds)
17:05:40*radicalned joined #nim
18:25:24*radicalned quit (Ping timeout: 256 seconds)
18:33:38*radicalned joined #nim
18:42:58*radicalned quit (Ping timeout: 256 seconds)
18:55:24*radicalned joined #nim
21:02:22*radicalned quit (Ping timeout: 256 seconds)
21:02:42*hygo joined #nim
21:13:28*rockcavera joined #nim
21:19:29*tiorock joined #nim
21:19:29*rockcavera quit (Killed (copper.libera.chat (Nickname regained by services)))
21:19:29*tiorock is now known as rockcavera
21:21:33*tiorock joined #nim
21:21:33*tiorock quit (Changing host)
21:21:33*tiorock joined #nim
21:21:33*rockcavera is now known as Guest2020
21:21:34*Guest2020 quit (Killed (calcium.libera.chat (Nickname regained by services)))
21:21:34*tiorock is now known as rockcavera
21:30:42*beholders_eye joined #nim
21:51:30*radicalned joined #nim
21:56:12*radicalned quit (Ping timeout: 256 seconds)
22:18:17*beholders_eye quit (Ping timeout: 256 seconds)
22:30:30*tiorock joined #nim
22:30:30*rockcavera quit (Killed (copper.libera.chat (Nickname regained by services)))
22:30:30*tiorock is now known as rockcavera
22:32:22FromDiscord<lan_maneiro> where is the best place to learn nim? (i'm not good with documentation lol)
22:47:32FromDiscord<aethrvmn> In reply to @lan_maneiro "where is the best": Here asking questions tbh
22:48:27FromDiscord<lan_maneiro> In reply to @aethrvmn "Here asking questions tbh": fair enough
23:00:39FromDiscord<demotomohiro> In reply to @lan_maneiro "where is the best": https://nim-lang.org/docs/tut1.html↵https://nim-lang.org/docs/tut2.html↵https://nim-lang.org/docs/manual.html
23:02:36FromDiscord<lan_maneiro> In reply to @demotomohiro "https://nim-lang.org/docs/tut1.html https://nim-lan": thank you! for some reason, i didn't notice the tutorial section
23:08:00FromDiscord<demotomohiro> You can find other documents here: https://nim-lang.org/documentation.html