<< 11-02-2025 >>
00:00:18FromDiscord<Elegantbeef> It works with ref objects
00:01:35FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=qqzftkHS
00:01:45FromDiscord<Elegantbeef> Hey you said ref objects
00:01:54FromDiscord<Elegantbeef> Not ref inheriting objects
00:02:01FromDiscord<System64 ~ Flandre Scarlet> Oh, sorry
00:02:23FromDiscord<System64 ~ Flandre Scarlet> Well I guess I'll have to make intermediate objects for serialization?
00:02:50FromDiscord<Elegantbeef> You can always add an `id: int` field and handle deserialization with a macro, but that's beyond the scope of vsbf
00:03:36FromDiscord<System64 ~ Flandre Scarlet> When I used flatty, I made a specific object with id + raw data
00:03:40FromDiscord<Elegantbeef> Nim's RTTI is lackluster in this department so I just do not support saving/loading inheritance objects
00:03:53FromDiscord<Elegantbeef> I did honestly try to do it, but yea
00:04:48FromDiscord<Elegantbeef> Actually I think you can do `encoder.serialize(Type(), "")`
00:05:12FromDiscord<System64 ~ Flandre Scarlet> Type(myType)?
00:05:33FromDiscord<Elegantbeef> Nah just `serialize(myType, "")`
00:05:42FromDiscord<Elegantbeef> It'll atleast save and load to that type fine
00:05:47FromDiscord<Elegantbeef> In theory
00:06:49FromDiscord<Elegantbeef> Heh it fails
00:07:25FromDiscord<System64 ~ Flandre Scarlet> Well, intermediate type then I guess
00:07:48FromDiscord<System64 ~ Flandre Scarlet> but it will require more work
00:15:12FromDiscord<Elegantbeef> Heh another bug found thanks to you
00:15:55FromDiscord<System64 ~ Flandre Scarlet> Oh, you're welcome
00:15:55FromDiscord<Elegantbeef> I apparently only tested a small amount of the serialization hooks and mostly worked on the format
00:16:29FromDiscord<Elegantbeef> Here I thought the tests I had mixed with the actual usage in my game project was a nice mix, but I apparently had no references, defaults, or inheritance
00:17:04FromDiscord<Elegantbeef> The reference one was funny cause I just accidentally inverted the boolean I read from the buffer
00:18:09FromDiscord<System64 ~ Flandre Scarlet> And the inheritance one?
00:18:33FromDiscord<Elegantbeef> Well inheritance works it just doesn't support runtime polymorphism
00:18:56FromDiscord<Elegantbeef> None of the issues you've shown exactly fail but that's cause you never upcast to a parent type and lose information
00:19:15FromDiscord<Elegantbeef> So if you do not use runtime polymorphism you're fine to use vsbf
00:19:16FromDiscord<System64 ~ Flandre Scarlet> So as long I don't use parent, I'll be fine?
00:19:23FromDiscord<Elegantbeef> But if you do you have to work around it
00:21:42FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=WkSfbjAq
00:22:18FromDiscord<Elegantbeef> Yea I'm not going to drop the `object or tuple` as it makes it slightly less error prone
00:22:31FromDiscord<Elegantbeef> Just do the `encoder.serialize(T, "")` if you really want to store a reference
00:23:17FromDiscord<Elegantbeef> That's all serialize root really does but it's more of a formality to say "Ok this is going to be my entire vsbf" as vsbf isn't exactly easy to walk around with
00:23:32FromDiscord<Elegantbeef> It's a ref type you cannot echo it
00:23:40FromDiscord<Elegantbeef> You need to dereference it
00:23:52FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=zoPKuyrd
00:24:20FromDiscord<System64 ~ Flandre Scarlet> Oooooh alright!
00:24:20FromDiscord<Elegantbeef> I don't exactly like the idea of having anything but struct being the root of vsbf due to the fact traversing is not incremental. You have to go to the start to find the next node practically
00:24:27FromDiscord<Elegantbeef> But I cannot stop you and it's not against my 'spec'
00:24:50FromDiscord<System64 ~ Flandre Scarlet> Oh, so it's less efficient?
00:25:46FromDiscord<Elegantbeef> It's not any less efficient but you cannot do like `serialize(10); serialize("hmm"); serialize(40f)` then easily get that in reversed order
00:26:20FromDiscord<Elegantbeef> The format is an always forward format so there is nothing encoded in it to backtrack easily
00:26:54FromDiscord<Elegantbeef> So if you have a top level field you want to skip the decoder actually walks through the entire tree much like the `bsbfdumper` tool does
00:26:59FromDiscord<Elegantbeef> `vsbfdumper`
00:27:21FromDiscord<Elegantbeef> Yes if you didnt see you should have `vsbfdumper` in your path which gives you a json like view of vsbf files
00:27:28FromDiscord<System64 ~ Flandre Scarlet> And like MsgPack right?
00:27:45FromDiscord<System64 ~ Flandre Scarlet> For the always fordward thing
00:27:50FromDiscord<Elegantbeef> I think messagepack is forward looking aswell, I don't recall
00:28:00FromDiscord<System64 ~ Flandre Scarlet> RIFF too I think
00:28:29FromDiscord<Elegantbeef> Hell if you notice I disliked the premise of backtracking so much I do not even encode a entry's length
00:28:57FromDiscord<Elegantbeef> Everything is encoded on the fly and requires the entire data type to be decoded to properly read due to the fact strings are encoded in line
00:29:07FromDiscord<System64 ~ Flandre Scarlet> In fact↵I have a better understanding on how to properly go through a WAV file now
00:29:43FromDiscord<System64 ~ Flandre Scarlet> There is no need to backtrack a wav file
00:30:05FromDiscord<Elegantbeef> On encoding or decoding?
00:30:14FromDiscord<System64 ~ Flandre Scarlet> Both
00:30:17FromDiscord<Elegantbeef> Cause the never backtrack holds for both ways in vsbf
00:30:22FromDiscord<Elegantbeef> Ah nice
00:30:57FromDiscord<System64 ~ Flandre Scarlet> So I don't need intermediate object! It will save me so much work and errors...
00:31:08FromDiscord<Elegantbeef> I hope so 😄
00:31:32FromDiscord<Elegantbeef> I made it primarily for myself for shits and giggles and cause I felt like "Why not reinvent a binary format"
00:32:17FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "I made it primarily": The good thing is it uses default value instead of just stopping and throwing an exception like MessagePack bindings
00:32:42FromDiscord<Elegantbeef> It also supports some pragmas I really wanted from other libraries
00:32:54FromDiscord<Elegantbeef> https://github.com/beef331/vsbf/blob/master/vsbf/shared.nim#L7-L8
00:33:17FromDiscord<System64 ~ Flandre Scarlet> skipSerialization just doesn't serialize?
00:33:25FromDiscord<Elegantbeef> Correct
00:33:38FromDiscord<System64 ~ Flandre Scarlet> this is↵# FCKING GOOD!
00:33:41FromDiscord<Elegantbeef> vsbfName gives the field a different name to save to and load from
00:33:57FromDiscord<System64 ~ Flandre Scarlet> The header?
00:34:03FromDiscord<Elegantbeef> Helpful if you want to change the name of a field in code but want to support older files
00:34:35FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=mpoeNqid
00:34:44FromDiscord<Elegantbeef> These are the same type in the eyes of the vsbf serde
00:35:00FromDiscord<System64 ~ Flandre Scarlet> Oh pretty nice!
00:35:15FromDiscord<System64 ~ Flandre Scarlet> and I guess it's also good for renaming fields?
00:35:42FromDiscord<Elegantbeef> Less of an issue in vsbf since there is not much human readability in it
00:35:45FromDiscord<Elegantbeef> But yes
00:36:11FromDiscord<System64 ~ Flandre Scarlet> In general, you don't prioritize human readability in binary formats
00:36:40FromDiscord<System64 ~ Flandre Scarlet> Tomorrow I'll battle-test your library against Kurumi XP
00:36:48FromDiscord<Elegantbeef> Right, which is why it's not exactly meant for field renaming in vsbf but more for code renaming and supporting past data
00:37:09FromDiscord<Elegantbeef> Nice
00:37:14FromDiscord<Elegantbeef> Hope it works out for you
00:37:19FromDiscord<System64 ~ Flandre Scarlet> I hope too
00:38:05FromDiscord<Elegantbeef> It's worked well for my world saves in my games, threw a little bit of compression on top and got the world down to like 2kb per level
00:38:21FromDiscord<Elegantbeef> Though the main thing I wanted was a binary format that was not protocol based so I could stop having to remake levels
00:38:36FromDiscord<Elegantbeef> This did achieve that so I was already chuffed, if someone else finds it useful I'll be even happier 😄
00:39:08FromDiscord<System64 ~ Flandre Scarlet> I liked Flatty, but the issue is it makes hard to update your structures
00:39:37FromDiscord<Elegantbeef> Yea I was using frosty with the same issue that the object format was a protocol so you have be very cautious
00:40:23FromDiscord<System64 ~ Flandre Scarlet> It's pretty nice for storing history in apps or sending over the network↵But not really for saving↵And so, Kurumi-X (not XP!) had to versionize the modules...
00:41:02FromDiscord<System64 ~ Flandre Scarlet> I think that I'll still keep the versionization in XP, but it is for safety
02:21:09FromDiscord<alarie25> whats the convention for file names
02:21:11FromDiscord<alarie25> snake case or camel case
02:22:21FromDiscord<alarie25> nvm i found snake case in the nim repo
02:23:07*tokyovigilante quit (Read error: Connection reset by peer)
02:23:22*tokyovigilante joined #nim
02:24:20FromDiscord<fl4shk> hey @solitudesf I got generics working!
02:25:52*sh4 joined #nim
02:25:53FromDiscord<System64 ~ Flandre Scarlet> In reply to @janakali "^ <@380360389377916939>": ``Error: Compiler 'tcc' doesn't support the requested target``↵Hi, I have this issue
02:26:08FromDiscord<fl4shk> https://github.com/fl4shk/nim-to-pipelinec
02:37:00FromDiscord<determiedmech1> update on the cross compiling https://media.discordapp.net/attachments/371759389889003532/1338700284939206656/image.png?ex=67ac094b&is=67aab7cb&hm=35d81ff0510d364ce993a28a77190bcc4eb80ef17041fc099bc384afc7da2cbb&
02:37:22FromDiscord<determiedmech1> `nim c -d:mingw main.nim`
02:41:08*rockcavera quit (Remote host closed the connection)
02:53:57*m5zs7k quit (Ping timeout: 268 seconds)
03:01:34FromDiscord<.tokyovigilante> If I'm interacting with C, is it better to pass references to memory allocated in C by using `nimProcThatCallsACFunctionToAllocateABuffer(var bufferToBeAllocated)` or `nimProcThatCallsACFunctionToAllocateABuffer(ptr bufferToBeAllocated)`
03:01:55FromDiscord<.tokyovigilante> Or, to ask the same question another way, does Nim pass-by-reference use pointers under the hood?
03:02:17FromDiscord<.tokyovigilante> (edit) "bufferToBeAllocated)`" => "bufferToBeAllocated: pointer)`" | "bufferToBeAllocated)`" => "bufferToBeAllocated: pointer)`"
03:02:52FromDiscord<Elegantbeef> If it's treated like a `var` use `var` otherwise `ptr`
03:05:36FromDiscord<.tokyovigilante> I guess like a var, if the input value of the pointer is nil, then the function will pass it by reference to the C function (ie &pointer), allocate some memory, then set the pointer to point to that memory.
03:06:14FromDiscord<.tokyovigilante> ie nimAllocateProc(buffer: nil) will want to set that buffer object to a pointer to memory allocated in the C library I'm using
03:06:23FromDiscord<.tokyovigilante> (edit) "nimAllocateProc(buffer: nil)" => "`nimAllocateProc(buffer: nil)`"
03:06:58FromDiscord<.tokyovigilante> (edit) "&pointer)," => "`&pointer`),"
03:33:36*m5zs7k joined #nim
03:36:24FromDiscord<janakali> In reply to @sys64 "``Error: Compiler 'tcc' doesn't": never seen this error
03:39:28FromDiscord<janakali> are you cross-compiling? Never tried cross-compilation.
03:39:39FromDiscord<janakali> (edit) "cross-compilation." => "cross-compilation with tcc."
04:54:09*m5zs7k quit (Ping timeout: 248 seconds)
04:58:54*m5zs7k joined #nim
05:17:35FromDiscord<lainlaylie> sent a code paste, see https://play.nim-lang.org/#pasty=XkxkWMkB
05:17:41FromDiscord<lainlaylie> trying to compile to cpp with tcc?
05:18:06FromDiscord<lainlaylie> (edit) "cpp" => "c++"
05:58:19FromDiscord<xtrayambak> sent a code paste, see https://play.nim-lang.org/#pasty=GlRSIxzn
06:00:05FromDiscord<Elegantbeef> It's a static value so allocating for it is a bit of a fun question
06:00:18FromDiscord<Elegantbeef> You `alloc(sizeof(MAtom))`
06:00:57FromDiscord<Elegantbeef> You are doing it completely wrong by allocating only for a specific field
06:01:23FromDiscord<xtrayambak> In reply to @Elegantbeef "You are doing it": Oh
06:01:59FromDiscord<Elegantbeef> Tagged unions are always the size of the largest branch so you do not need to do allocations per branch
06:02:53FromDiscord<xtrayambak> Huh, I still get the same segfault at the same line
06:05:56FromDiscord<Elegantbeef> https://play.nim-lang.org/#pasty=dbSoFnDi works just fine
06:11:55FromDiscord<xtrayambak> huh, it does on there but it doesn't when I run it on my system
06:12:10FromDiscord<Elegantbeef> `nim -v`?
06:12:32FromDiscord<xtrayambak> sent a code paste, see https://play.nim-lang.org/#pasty=xPLMRcbd
06:12:56FromDiscord<xtrayambak> here's what I changed my code to now https://media.discordapp.net/attachments/371759389889003532/1338754626115338240/bHSjR58.png?ex=67ac3be7&is=67aaea67&hm=ec062da2c5531e53a0d68e90410d2132fc8ebdde054a740d3b76ec32893e8aaf&
06:13:25FromDiscord<xtrayambak> I'm using mimalloc if that makes a difference
06:13:37FromDiscord<Elegantbeef> Not that it'll change anything but why are you moving memory?
06:13:49FromDiscord<Elegantbeef> I mean you can remove `-d:useMalloc` or remove the patch file
06:14:20FromDiscord<xtrayambak> In reply to @Elegantbeef "Not that it'll change": I just added that in to check something earlier, but I doubt it makes a difference since the function's supposed to return a `MAtom` anyways
06:14:48FromDiscord<Elegantbeef> Well it'll zero the struct
06:14:51FromDiscord<Elegantbeef> So of course it's wrong
06:15:32FromDiscord<xtrayambak> Switching over to the default allocator and removing the `move` still segfaults, but with no exception trace this time
06:15:58FromDiscord<Elegantbeef> Well your config is doing something odd, or your OS
06:16:10FromDiscord<xtrayambak> I'm using Linux on x86-64, so I doubt that's it
06:20:17FromDiscord<Elegantbeef> Did you try the example in a different file not using mimalloc and no config?
06:20:56FromDiscord<xtrayambak> In reply to @Elegantbeef "Did you try the": This is my entire config, and I've disabled mimalloc temporarily and also cleared the Nim cache before compilation just for good measure https://media.discordapp.net/attachments/371759389889003532/1338756640609931324/kLRZ5pd.png?ex=67ac3dc8&is=67aaec48&hm=c9c77b0cad52397fc98414c3e48bad4b59de5c5a0b20e30f1fc5c44ffdec3a11&
06:21:16FromDiscord<Elegantbeef> Did you try the example in a different file not using mimalloc and no config?
06:21:41FromDiscord<xtrayambak> In reply to @Elegantbeef "Did you try the": The example you gave me? Yes
06:21:49FromDiscord<Elegantbeef> It worked?
06:21:52FromDiscord<xtrayambak> Yes
06:21:58FromDiscord<Elegantbeef> Then it's your flags
06:22:26FromDiscord<xtrayambak> I'll try selectively applying all my flags to your example until it starts segfaulting too
06:24:33FromDiscord<xtrayambak> Nope, I applied all the flags for my project and also tried using mimalloc
06:24:38FromDiscord<xtrayambak> your example still works fine
06:25:02FromDiscord<Elegantbeef> What is the full context for this allocation and field access?
06:25:15FromDiscord<xtrayambak> In reply to @Elegantbeef "What is the full": I didn't quite get you, sorry
06:25:27FromDiscord<xtrayambak> Are you asking how long the MAtom lives on for?
06:25:39FromDiscord<Elegantbeef> What is the full procedure where this allocation is occuring
06:25:41FromDiscord<Elegantbeef> Not just a snippet
06:25:54FromDiscord<xtrayambak> Hold on
06:26:00FromDiscord<Elegantbeef> Oh.... wait
06:26:44FromDiscord<xtrayambak> sent a code paste, see https://play.nim-lang.org/#pasty=LobvKcef
06:28:20FromDiscord<Elegantbeef> does `baliMsAlloc` zero memory?
06:29:18FromDiscord<xtrayambak> In reply to @Elegantbeef "does `baliMsAlloc` zero memory?": Nope, it just calls `alloc` under the hood
06:29:24FromDiscord<Elegantbeef> You likely should do `zeroMem(mem, sizeof(MAtom))`
06:29:32FromDiscord<Elegantbeef> That will disarm destructors
06:30:11FromDiscord<xtrayambak> Yes, that works
06:30:26FromDiscord<Elegantbeef> Zero you memory kids
06:30:30FromDiscord<xtrayambak> Thanks :^)
06:39:11Amun-Rathat's why I always allocate memory in private window only
07:35:51*SchweinDeBurg quit (Quit: WeeChat 4.6.0-dev)
07:39:20FromDiscord<System64 ~ Flandre Scarlet> In reply to @janakali "never seen this error": No I'm compiling normally
07:48:31*SchweinDeBurg joined #nim
07:56:26*disso-peach joined #nim
08:08:48*alexdaguy joined #nim
08:54:50*PMunch joined #nim
09:06:33*tokyovigilante quit (Ping timeout: 246 seconds)
09:15:58*tokyovigilante joined #nim
09:22:52*ntat joined #nim
09:48:08*ntat quit (Quit: Leaving)
10:07:28FromDiscord<System64 ~ Flandre Scarlet> In reply to @Elegantbeef "Right, which is why": About vsbf↵Is there a version of vsbfdumper that I can use into my program?
10:21:59*robertmeta quit (Remote host closed the connection)
10:22:00*mronetwo quit (Remote host closed the connection)
10:22:01*adigitoleo quit (Remote host closed the connection)
10:22:02*tmpod quit (Remote host closed the connection)
10:22:02*Freneticks quit (Remote host closed the connection)
10:22:03*noeontheend quit (Write error: Broken pipe)
10:22:03*casaca quit (Write error: Broken pipe)
10:22:04*ursa-major quit (Remote host closed the connection)
10:22:04*johuck quit (Remote host closed the connection)
10:52:12FromDiscord<System64 ~ Flandre Scarlet> `
10:56:54FromDiscord<System64 ~ Flandre Scarlet> sent a code paste, see https://play.nim-lang.org/#pasty=pBiikMkQ
10:57:54FromDiscord<pmunch> Video from my FOSDEM talk is up! https://video.fosdem.org/2025/h1308/fosdem-2025-6229-nim-c-reaching-the-stars-by-standing-on-the-shoulders-of-giants.av1.webm
11:07:49FromDiscord<lainlaylie> sent a code paste, see https://play.nim-lang.org/#pasty=kOxAlDAL
11:16:41FromDiscord<System64 ~ Flandre Scarlet> In reply to @lainlaylie "are you calling your": I'm using vsbf and I try to get a seq of bytes
11:22:40FromDiscord<lainlaylie> does it compile if you pass a literal seq[byte] instead of module.serializeToBinary? i expect the type mismatch error to at least list your new proc and say which parameter doesnt match
11:35:07*Freneticks joined #nim
11:35:09*johuck joined #nim
11:35:09*mronetwo joined #nim
11:35:09*tmpod joined #nim
11:35:10*robertmeta joined #nim
11:35:11*ursa-major joined #nim
11:35:12*adigitoleo joined #nim
11:35:14*casaca joined #nim
11:35:14*noeontheend joined #nim
12:46:55FromDiscord<krissh.wtf> does anyone have any examples of websites using prologue?
12:48:23FromDiscord<krissh.wtf> im trying to make a file-based routing for my personal blog using markdown
12:48:48*beholders_eye joined #nim
13:37:30*ntat joined #nim
14:55:47*alexdaguy quit (Quit: w)
15:32:23FromDiscord<enthus1ast.> For mummy I could help, have not used prologue in ages
18:31:29FromDiscord<rakgew> thank you for posting the link. nice talk!↵I totally missed it - on which track or dev room was that?↵(@pmunch)
18:59:04FromDiscord<pmunch> Thanks! It was in the "Declarative and Minimalistic programming languages" room
19:06:29*xet7 joined #nim
19:15:00FromDiscord<spotlightkid> @pmunch\: I just commented on a small error in the readme documentation of the futhark rename/pragma callbacks. `Arg`should be `Argument`.
19:19:21FromDiscord<rakgew> ok I see - I had first assumed it was in llvm dev room due to futharks use of clang.
19:20:06FromDiscord<pmunch> In reply to @spotlightkid "<@392962235737047041>\: I just commented": Ah, good catch!
19:21:08FromDiscord<pmunch> In reply to @rakgew "ok I see -": Could've fit there as well. But these guys requested a talk and proposed Futhark as a topic 🙂
19:45:06FromDiscord<thomastjdev> sent a code paste, see https://play.nim-lang.org/#pasty=ExtfsCih
19:47:09*xet7 quit (Remote host closed the connection)
19:47:26FromDiscord<nnsee> In reply to @thomastjdev "I need a hint!": are you using orc or arc?
19:47:35FromDiscord<nnsee> iirc mummy requires it
19:48:17FromDiscord<nnsee> and json requires orc specifically if i'm remembering right
19:51:03FromDiscord<thomastjdev> orc
19:51:23*Guest65 joined #nim
19:51:26FromDiscord<thomastjdev> In reply to @nnsee "and json requires orc": Been compiling both arc and orc, both gives this parseJson with valgrind
19:54:26FromDiscord<Elegantbeef> Std json does not
19:55:21FromDiscord<thomastjdev> It's standard json I'm using. I haven't been testing with out nimble-packages; could do a test.
19:55:36*Guest65 quit (Client Quit)
20:03:27*xet7 joined #nim
20:53:36FromDiscord<michaelb.eth> In reply to @thomastjdev "orc": have you tried compiling with `-d:useMalloc` ?
20:55:10FromDiscord<thomastjdev> In reply to @michaelb.eth "have you tried compiling": I'm using `nim c -d:dev -d:useMalloc --debugger:native main` and then running `valgrind --leak-check=full --log-file=valgrind_details4.txt --track-origins=yes --num-callers=20 ./main`
20:57:39FromDiscord<Elegantbeef> The issue is from memory allocated in `newStringStream` so might it be as easy as a close on the buffer
20:57:47FromDiscord<Elegantbeef> Well close on the stream
20:57:56FromDiscord<Elegantbeef> https://github.com/nim-lang/Nim/blob/version-2-2/lib/pure/json.nim#L1050 cause it doesn't close now
21:06:22FromDiscord<thomastjdev> In reply to @Elegantbeef "The issue is from": That was elegant.. but.. then it's been there forever? I saw the reference to L1050 but it's been like that for 5 years.
21:07:09FromDiscord<thomastjdev> sent a code paste, see https://play.nim-lang.org/#pasty=ZRhjxHBN
21:08:04FromDiscord<Elegantbeef> we did it?!
21:10:59FromDiscord<thomastjdev> Haha yes! That calls for confetti 🎊🎊🎊 Thanks a lot !!!!!!!!!!
21:11:31FromDiscord<thomastjdev> Luckily I only used `parseJson` around 460 times...... 🙂
21:13:12FromDiscord<Elegantbeef> More confirmation that std/streams is bad mmmk 😄
21:36:13*rockcavera joined #nim
21:42:48*disso-peach quit (Quit: Leaving)
22:01:20FromDiscord<Elegantbeef> @thomastjdev you will be making a PR....right?
22:04:53FromDiscord<thomastjdev> In reply to @Elegantbeef "<@830305987998908426> you will be": Yes! Tomorrow!
22:05:42FromDiscord<System64 ~ Flandre Scarlet> Elegantbeef, do you know how I can get binary data after serialization please?↵``encoder.serialize(obj, "")``
22:10:19FromDiscord<Elegantbeef> If you use a sequence it'll be a sequence
22:10:19FromDiscord<Elegantbeef> `encoder.dataBuffer`
22:10:20FromDiscord<Elegantbeef> So you do not need to copy and just move the buffer
22:10:20FromDiscord<Elegantbeef> Really if you're done encoding you should do `encoder.close`
22:10:27FromDiscord<Elegantbeef> `buffer` will not copy and will not duplicate an allocation
22:10:27FromDiscord<Elegantbeef> But if you want to continue writing of course you cannot
22:10:28FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#pasty=iYOEZiIG
22:14:21FromDiscord<System64 ~ Flandre Scarlet> Oh, encoder.close() returns the buffer? Good to know!
22:24:18*tiorock joined #nim
22:24:18*rockcavera quit (Killed (iridium.libera.chat (Nickname regained by services)))
22:24:18*tiorock is now known as rockcavera
22:26:26*tiorock joined #nim
22:26:26*rockcavera is now known as Guest4800
22:26:26*Guest4800 quit (Killed (copper.libera.chat (Nickname regained by services)))
22:26:26*tiorock is now known as rockcavera
22:31:25*zgasma quit (Quit: leaving)
22:33:00*xutaxkamay quit (Ping timeout: 260 seconds)
22:57:26*ntat quit (Quit: Leaving)
23:21:36*xutaxkamay joined #nim