<<15-04-2021>>
00:01:56*njoseph quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
00:02:17*njoseph joined #nim
00:25:11*nekits07 joined #nim
00:26:55FromDiscord<Sabena Sema> https://github.com/nim-lang/fusion/blob/fb1655420a91c9ad0d0141c657b6d468ed276b4e/src/fusion/btreetables.nim#L851
00:27:04FromDiscord<Sabena Sema> what's that `<//>` syntax?
00:41:30FromDiscord<Yardanico> In reply to @Sabena Sema "what's that `<//>` syntax?": it does nothing right now, initially it was used as a way to specify owned refs in a backwards compatible way so that older nim versions could compile the same code
00:42:14FromDiscord<Sabena Sema> huh, but fusion's unique pointers don't seem to define `=sink`
00:42:26FromDiscord<Yardanico> ?
00:43:16FromDiscord<Yardanico> owned refs were a part of the newruntime, but it didn't go that far, instead arc/orc were developed
00:43:16FromDiscord<Yardanico> https://nim-lang.org/araq/ownedrefs.html
00:45:40FromDiscord<Yardanico> In reply to @Sabena Sema "huh, but fusion's unique": also smartptrs is going to be added to stdlib, so check code in https://github.com/nim-lang/Nim/pull/17333 instead of fusion for it
00:46:18FromDiscord<Yardanico> and =sink is compiler-provided by default - https://nim-lang.org/docs/destructors.html#lifetimeminustracking-hooks-eqsink-hook
00:46:41FromDiscord<Yardanico> http://nim-lang.github.io/Nim/destructors.html "When not provided the compiler is using a combination of =destroy and copyMem instead. "
00:56:18FromDiscord<Sabena Sema> Except you can't call destroy after moving from a unique ptr
00:56:32FromDiscord<Sabena Sema> Bagh Ill figure it out later
01:03:46*Tlangir joined #nim
01:23:06FromDiscord<Avatarfighter> What does the smartptrs package do/what is a use case ?
02:31:26*layers joined #nim
02:31:46*layers quit (Client Quit)
02:54:08*thomasross quit (Remote host closed the connection)
03:10:05*spiderstew joined #nim
03:11:25*spiderstew_ quit (Ping timeout: 250 seconds)
03:59:12*letto quit (Quit: Konversation terminated!)
04:01:10*rockcavera quit (Remote host closed the connection)
04:01:11*letto joined #nim
04:19:31*Gustavo6046 quit (Ping timeout: 260 seconds)
05:02:46*narimiran joined #nim
05:07:50saemHmm, so `--path:.` is not implied if you don't specify path. Huh
05:33:47*haxscramper joined #nim
05:45:17*inamannerofspeak joined #nim
05:47:53ForumUpdaterBotNew thread by Bpr: Interesting post from D forum, see https://forum.nim-lang.org/t/7791
06:00:57FromDiscord<TennisBowling> In reply to @haxscramper "You can show code": https://play.nim-lang.org/#ix=2W8D
06:05:38FromDiscord<haxscramper> https://wandbox.org/permlink/ExyAy7Fi9kPDIj0c
06:05:53FromDiscord<haxscramper> https://nim-lang.org/docs/manual.html#procedures <
06:06:07FromDiscord<haxscramper> I think someone linked that already, but manual has example on how to define procedure with return type
06:38:04*johnnynitwits quit (Quit: Bridge terminating on SIGTERM)
06:38:04*threenp quit (Quit: Bridge terminating on SIGTERM)
06:48:52*inamannerofspeak quit (Ping timeout: 252 seconds)
07:05:43*vicfred quit (Quit: Leaving)
07:08:37*skelett quit (Quit: WeeChat 2.9)
07:19:06FromDiscord<mattrb> Can someone explain what's going on here? https://play.nim-lang.org/#ix=2W8P
07:21:12*natrys joined #nim
07:23:50*johnnynitwits joined #nim
07:23:55*threenp joined #nim
07:30:05ForumUpdaterBotNew thread by Mikkom: Fastest method for writing and loading cached binary object data to file, see https://forum.nim-lang.org/t/7792
07:31:51FromDiscord<ElegantBeef> @mattrb based off this seems unsigned bit shift returns the value if it goes out of bit bounds https://play.nim-lang.org/#ix=2W8U
07:33:47FromDiscord<mattrb> Hmm but why? I don't see that documented anywhere, and it doesn't seem like that's what the compiler emits? https://github.com/nim-lang/Nim/blob/devel/compiler/ccgexprs.nim#L633
07:33:50FromDiscord<mattrb> I could also be misreading
07:36:09FromDiscord<ElegantBeef> Seems that's just what C does
07:36:35*haxscramper quit (Remote host closed the connection)
07:36:51FromDiscord<ElegantBeef> If you shift over the size of the type it returns the value it seems
07:37:02*haxscramper joined #nim
07:39:22FromDiscord<ElegantBeef> Since it's a direct wrap to C we get that odd behaviour
07:41:27FromDiscord<mattrb> It doesn't do it with 8-bit ints though? https://play.nim-lang.org/#ix=2W8Y
07:41:38FromDiscord<mattrb> (edit) "8-bit ints" => "uint8s"
07:45:33FromDiscord<ElegantBeef> Cause it doesnt happen in C either
07:46:13FromDiscord<ElegantBeef> https://onlinegdb.com/rJqrJuH8d
07:49:39*neceve joined #nim
07:51:57FromDiscord<ElegantBeef> Yea it's certainly odd C behaviour https://onlinegdb.com/SyZW9gOBUu
07:52:06*PMunch joined #nim
07:52:14FromDiscord<ElegantBeef> My suggestion is to do https://play.nim-lang.org/#ix=2W8Z
07:52:47FromDiscord<mattrb> Unless `b` is 0
07:52:52FromDiscord<mattrb> But yeah I think I'll have to do that
07:52:53FromDiscord<mattrb> Thanks
07:52:56FromDiscord<mattrb> C sucks lol
07:53:06FromDiscord<ElegantBeef> Indeed
07:53:25FromDiscord<ElegantBeef> But now for you to do your part and document that oddity 😄
07:54:20FromDiscord<ElegantBeef> Though i do agree that the shift ops should return 0 in this case
07:55:20FromDiscord<Rika> this behavior shouldnt carry into nim tho should it
07:55:49FromDiscord<ElegantBeef> Certainly not that's quite unintuitive
07:56:50FromDiscord<mattrb> Yeah if this was just a documentation change I'd happy add it to the docs, but I feel like Nim should override the C behavior here
07:57:08FromDiscord<ElegantBeef> Well time for an RFC i imagine
07:57:32FromDiscord<mattrb> I can likely get to it this weekend if it's not picked up prior to then
07:59:00FromDiscord<Rika> inb4 cant add, breaking change
07:59:05FromDiscord<ElegantBeef> lol
07:59:12FromDiscord<ElegantBeef> I mean it's not difficult to change
07:59:40FromDiscord<ElegantBeef> Dont even have to change the generated C, just make the `shr` a `shrImpl` and then `shr` calls it
08:00:01FromDiscord<ElegantBeef> > However, do note that a shift operand value which is either a negative number or is greater than or equal to the total number of bits in this value results in undefined behavior. For example, when shifting a 32 bit unsigned integer, a shift amount of 32 or higher would be undefined.
08:00:07FromDiscord<ElegantBeef> Ah so it is UB
08:00:13FromDiscord<ElegantBeef> Fuck i love C!
08:00:21FromDiscord<mattrb> Yeah I just found basically the same thing lol
08:00:29*haxscramper quit (Remote host closed the connection)
08:00:31FromDiscord<mattrb> https://en.cppreference.com/w/c/language/operator_arithmetic#Shift_operators↵> The behavior is undefined if rhs is negative or is greater or equal the number of bits in the promoted lhs.
08:00:48FromDiscord<Rika> nice
08:00:51FromDiscord<ElegantBeef> So yea certainly needs addressed, having UB is just silly
08:00:55*haxscramper joined #nim
08:01:00FromDiscord<Rika> just divide by 2 ez
08:01:07FromDiscord<ElegantBeef> lol
08:01:16FromDiscord<mattrb> I imagine this would also affect `shl`
08:01:24FromDiscord<Rika> i dont think it does actually lol
08:01:32FromDiscord<Rika> maybe check
08:01:43FromDiscord<ElegantBeef> If you shit more than 32 bits left it should be zero regardless what was there
08:01:49FromDiscord<ElegantBeef> inb4 it wraps around
08:01:57FromDiscord<Rika> shit lmao
08:02:08FromDiscord<ElegantBeef> !eval echo 0xffu32 shl 32
08:02:15NimBot0
08:02:19FromDiscord<ElegantBeef> Wehew
08:03:09FromDiscord<mattrb> Phew
08:03:14FromDiscord<Rika> lmao
08:03:23FromDiscord<Rika> yall i love c so much :DDDDDDDDDDDD
08:03:42FromDiscord<mattrb> The docs I linked above seem to imply that the behavior for both `<<` and `>>` out of range is undefined, so I think we just lucked into that one being 0 lol
08:03:49FromDiscord<ElegantBeef> Ah
08:03:56FromDiscord<mattrb> Nim should define implementations for both imo
08:04:17FromDiscord<ElegantBeef> Yea proper shifting that's done properly
08:04:42FromDiscord<Rika> inb4 it actually is just a for loop and dividing/multiplying
08:05:55FromDiscord<clyybber> Theres an open PR which addresses this
08:06:06FromDiscord<clyybber> AFAIRC
08:06:32FromDiscord<ElegantBeef> As far as internet relay chat?
08:07:34FromDiscord<clyybber> lol I meant as far as i remember correctly but i just realized that i mixed two things there
08:07:40FromDiscord<clyybber> <https://github.com/nim-lang/Nim/pull/11555>
08:08:22FromDiscord<Rika> lmao IIRC and AFAIR
08:08:49FromDiscord<Rika> AFAIIRC, as far as if i recall correctly
08:08:50FromDiscord<Rika> xd
08:14:13ForumUpdaterBotNew thread by Halloleo: How do I get the fields/attributes of an object type at run time?, see https://forum.nim-lang.org/t/7793
08:16:14FromDiscord<Rika> oh man here we go again
08:16:47FromDiscord<Rika> oh okay its more okay than i thought
08:16:51FromDiscord<spkinguy1> sent a long message, see http://ix.io/2W97
08:16:53FromDiscord<Rika> In reply to @spkinguy1 "guys which one of": low?
08:17:04FromDiscord<Rika> as in which i like least?
08:17:07FromDiscord<Rika> oh
08:17:09FromDiscord<spkinguy1> (edit) "http://ix.io/2W97" => "http://ix.io/2W98"
08:17:11FromDiscord<Rika> low level huh
08:17:18FromDiscord<Rika> id say zig
08:17:46FromDiscord<spkinguy1> In reply to @Rika "id say zig": u know most of them ?
08:17:51FromDiscord<mattrb> sent a code paste, see https://play.nim-lang.org/#ix=2W99
08:18:57FromDiscord<clyybber> In reply to @mattrb "Looks like this PR": Yeah, the PR will guarantee wrap around
08:19:44FromDiscord<Rika> In reply to @spkinguy1 "u know most of": to a small extent at least, from what ive seen
08:22:34FromDiscord<mattrb> I don't follow the logic for forcing the wraparound. If we're defining the undefined C behavior, I feel like we'd want to instead make all of those return 0?
08:23:20*inamannerofspeak joined #nim
08:25:48FromDiscord<Rika> maybe new operators if wrap is desired? wshl wshr?
08:26:06*PMunch quit (Ping timeout: 240 seconds)
08:26:38FromDiscord<mattrb> I'm having flashbacks to when Araq reviewed the `ashr` PR :cringeharold:
08:26:49FromDiscord<mattrb> (I wasn't around at the time, but read the discussion there :p)
08:29:16*PMunch joined #nim
08:29:38PMunchGoing to stream again today, around 5PM UTC as last time
08:29:40PMunchImplementing I²C to communicate between the two halves
08:29:46PMunchDid some preliminary testing to just blink an LED over the port expander with the libraries for Arduino, and it took a bit over 3000 bytes, a solid 33% larger than the entire keyboard firmware so far. So this might get interesting
08:37:29FromDiscord<mattrb> In reply to @mattrb "I don't follow the": Also, I feel like without a defined implementation, this is going to have different behavior on different architectures. (I'm just making an assumption, but I know that arm shifts out of range result in 0). Leaving this up to undefined behavior in C definitely isn't the way to go, and I'd argue that making shifts out of range return 0 is the way people would _expect_ this to work
08:40:09FromDiscord<ElegantBeef> Yea this `if toShift >= sizeOf(a)  4: 0 else: a shr toShift` seems like it'd be fine to my tired mind
08:41:12FromDiscord<ElegantBeef> i mean ` 8` ofc
08:53:25*arecaceae quit (Remote host closed the connection)
08:53:44*arecaceae joined #nim
08:56:41*Tlangir quit (Quit: Leaving)
09:10:01FromDiscord<clyybber> I'm worried about the performance impact
09:12:28FromDiscord<ElegantBeef> Yea i was worried aswell, only thing i could think of is make `shl/shr` the C versions and `<<`/`>>` the "safe" versions but that seems ugly considering the other ops
09:12:51PMunchAre you messing with shifting?
09:13:12FromDiscord<ElegantBeef> Nah just talking about how borked shifting is due to using C's directly
09:13:55FromDiscord<clyybber> I wonder how zig or crystal do it
09:14:37PMunchProbably the same, unless they get really poor performance on some architectures
09:15:15PMunchI mean the differences in shifting is just down to how the low level instructions work on different architectures isn't it?
09:15:17FromDiscord<ElegantBeef> Suppose we could have ah `-d:nimUseFastShifts` 😄
09:15:24FromDiscord<ElegantBeef> (edit) "ah" => "a"
09:15:27FromDiscord<clyybber> In reply to @PMunch "I mean the differences": yeah
09:16:04FromDiscord<mattrb> In reply to @Clyybber "I wonder how zig": Shifts out of range on crystal result in 0
09:16:26FromDiscord<mattrb> I know because I’m porting my Crystal gba emulator to Nim and this is a new bug for me 😆
09:16:30PMunchI guess it could be a compile-time thing so the behaviour we want isn't wrapped, but platforms that are wrapped could show an error with a hint to use -d:nimUseFastShifts
09:16:38PMunchOr -d:nimUseNativeShifts
09:16:56FromDiscord<clyybber> In reply to @mattrb "I know because I’m": ah, I suspected that :D
09:17:21PMunchWhat architecture are you on where that doesn't happen anyways?
09:19:13FromDiscord<clyybber> <https://github.com/crystal-lang/crystal/issues/305>
09:20:03FromDiscord<clyybber> seems like they split it into seperate ops
09:21:33FromDiscord<ElegantBeef> So seems my suggestion isnt terrible, just odd that the new ops would be the safe ones i guess
09:21:48FromDiscord<clyybber> I think a global switch is a bad idea
09:22:17FromDiscord<ElegantBeef> I mean the `shl` and `<<`
09:22:18saemLess switches plz. :)
09:22:28FromDiscord<ElegantBeef> I was joking with the global switch
09:22:31FromDiscord<clyybber> oh :D
09:22:32PMunchI don't think this is really needed..
09:22:55PMunchIf anyone actually needs to have a safe version of shl that sacrifices performance let them create a small template..
09:23:47FromDiscord<clyybber> I guess we could also just declare it illegal behaviour, instead of undefined; then debug mode could have an assertion there; and when you need the wraparound/zero-out behaviour, DIY
09:24:28FromDiscord<mattrb> In reply to @Clyybber "seems like they split": https://github.com/crystal-lang/crystal/blob/dd40a2442fa186add8a82b74edb14a90aa1dae05/src/int.cr#L203↵↵Haha amusing. I was literally just looking at this code earlier for another reason. I had a bug in my emulator because I assumed crystal shifts were logical even on signed numbers, but they’re arithmetic
09:24:53Clonkk[m]Is there an easy way to specify that ``Complex[Complex32]`` should return ``Complex32`` at compile-time (i.e. usable in generics) ?
09:24:58FromDiscord<ElegantBeef> Yea the worst part was there was no "there'll be dragons" message
09:25:10saemIt could be a check one turns off?
09:25:17*lritter joined #nim
09:25:28Clonkk[m]I have an input ``T: SomeFloat|Complex`` that should return ``Complex[T]`` basically.
09:28:01FromDiscord<Goel> sent a code paste, see https://play.nim-lang.org/#ix=2W9y
09:30:16FromDiscord<ElegantBeef> iterating ranges annoyingly requires `min, max`
09:30:44FromDiscord<clyybber> use countdown yeah, `..` is countup
09:37:26*clyybber joined #nim
09:41:54narimiranNim 1.4.6 and 1.2.12 are out!! https://nim-lang.org/blog/2021/04/15/versions-146-and-1212-released.html
09:43:35narimiranThere were no complaints during the release candidate phase. (But I'm sure somebody will find some issue 2 seconds after we announce the releases to the broader audience :D)
09:44:35giaco__to go from 4 chars long string to uint32, is mystr.toHex.parseHexInt.uint32 the way to go?
09:45:02giaco__it is a bytestring, obviously
09:46:47FromDiscord<ElegantBeef> `cast[uint32](myStr[0])`
09:48:06PMunchHmm, I'm trying to spit this out from a macro, but it throws an internal error: http://ix.io/2W9E
09:48:06liblq-devwell not really
09:48:15PMunchError: internal error: getTypeDescAux(tyAnything)
09:48:21liblq-dev@ElegantBeef this will only get the first byte of the string
09:48:35liblq-dev`cast[ptr uint32](myStr[0].unsafeAddr)[]`
09:48:38liblq-devis the right solution
09:49:34liblq-devgiaco__: ^
09:51:10PMunchSpotted one error, trying to use `auto` in the emit
09:51:31PMunchNow I have a different error :)
09:53:50*krux02 joined #nim
09:55:51giaco__liblq-dev: thanks. Will the result of that cast be refcounted as the string or will live on the stack?
09:56:12liblq-devit will get copied out of the string
09:56:32giaco__thanks
09:56:40liblq-devthat expression is equivalent to `*((uint32_t *)&myStr[0])` in C
09:57:32giaco__I wish I had more C experience before diving into nim, but I'm slowly catching up :P
10:00:18*haxscramper quit (Remote host closed the connection)
10:00:43*haxscramper joined #nim
10:01:20liblq-devso basically what this does is the following: 1. it takes the memory address of the first character in the string, 2. it reinterprets that address's type from a char pointer to a uint32 pointer, 3. it dereferences that pointer, which essentially means: it reads the memory at the address the pointer is pointing to
10:02:37*haxscramper quit (Read error: Connection reset by peer)
10:03:08*haxscramper joined #nim
10:03:48*haxscramper quit (Remote host closed the connection)
10:05:29FromDiscord<Clonkk> sent a code paste, see https://play.nim-lang.org/#ix=2W9M
10:08:08giaco__liblq-dev: and for the other way around, to go from uint32 to bytestring, is there something better than "myuint.toHex.parseHexStr" ?
10:08:30ForumUpdaterBotNew thread by Miran: Versions 1.4.6 and 1.2.12 released, see https://forum.nim-lang.org/t/7794
10:08:42liblq-devwell that ain't gonna do what you want anyways so
10:08:47liblq-devgoing the other way 'round is a bit harder
10:09:02liblq-devyou can turn your uint32 into a cstring
10:09:14giaco__no? I'm using it and it seems working so far
10:09:24liblq-devdefine "bytestring"
10:09:30PMunchCan I convert an object to an array of bytes on compile-time? I'm guessing no
10:09:50giaco__a string with same sizeof the original thing and with 1:1 bytes
10:10:53liblq-devPMunch: frosty?
10:11:12PMunchNo thanks I prefer regular corn flakes
10:11:16PMunchCould you pass the milk though?
10:11:55PMunchHmm, Frosty looks like it might be able to do it
10:16:58giaco__am I wrong?
10:21:12FromDiscord<sealmove> is there a way to expand a list to arguments similar to Python's `` prefix?
10:22:32ForumUpdaterBotNew thread by Pietroppeter: Lost thread? (Fastest method for writing and loading cached binary object data to file), see https://forum.nim-lang.org/t/7795
10:23:04liblq-devgiaco__: excuse my lack of response but i'm having a lesson right now so i can't really respond in real time
10:23:17liblq-devand nim playground seems to be down.
10:24:25giaco__absolutely no need to excuse, thanks for the feedback!
10:25:26PMunchHmm, rebooted the playground, let's see if that works
10:26:11*liblq-dev < https://matrix.org/_matrix/media/r0/download/matrix.org/EVAGOgwOAlqNfaLqGBBffMls/message.txt >
10:26:16liblq-devgiaco__: ^
10:27:12liblq-devresults in "DCBA" being written to stdout, because little endian
10:30:05giaco__thanks! but I wonder if toHex.parseHexStr is more or less conveniente. I should write some tests
10:31:48giaco__side question: doing "0x41424344u32" or doing "0x41424344.uint32" is the same thing, or the second one implies a conversion?
10:36:31liblq-devit's the same thing
10:36:45liblq-devtoHex.parseHexStr is slower
10:37:07liblq-devbecause you first convert the string to a hex representation, and then back to a normal string
10:37:14liblq-devhere you just directly operate on bytes
10:42:42giaco__I've run some -d:danger benchmarks over the two versions with benchy. You're right, the cast version is faster but not so much. Over 1_000_000 operations the cast version has an average time of 36ms, 40ms for the toHex.parseHexStr
10:43:52giaco__liblq-dev: this is the benchmark http://ix.io/2Wa3
10:45:12giaco__also the cast version lacks the endianess fix, that could slow it down
10:47:36liblq-devyou're discarding the result
10:47:50liblq-devso the compiler optimizes your computation away
10:48:01giaco__oh
10:48:04giaco__^^"
10:50:11liblq-devunfortunately i don't have a good solution to that as benchy's `keep` doesn't always work
10:51:13giaco__yeah I'm moving keep here and there but the benchmarks are not changing
10:51:52liblq-devi tried to writeFile the string but then that adds also the cost of reallocating the intermediary string, and syscalls and such
10:51:57liblq-devso it's not a fair benchmark
10:52:19liblq-devbut it gives me 51.830 ms for unsafe vs 70.025 for "safe"
10:54:19*Vladar joined #nim
10:55:27liblq-devjuggling bits with shl has a similar outcome
11:01:38giaco__how do you fix byte endianess with shl? Don't you need rotate for that?
11:02:15PMunchWell, with careful bitmasking you should be able to
11:03:19PMunch((myUint16 and 0xff00) shr 8) or ((myUint16 and 0xff) shl 8)
11:03:21PMunchSomething like that
11:04:00giaco__yeah, but with uint64 is like playing hanoi tower :D
11:04:33PMunchWell, it's just more of the same
11:06:30PMunch((myUint32 and 0xff000000) shr 26) or ((myUint32 and 0x00ff0000) shr 8) or ((myUint32 and 0x0000ff00) shl 8) or ((myUint32 and 0x000000ff) shl 26)
11:06:36PMunchThat's for 32 bit
11:07:19liblq-devwoah pmunch
11:07:26liblq-devdidn't you get your bits mixed up?
11:07:32PMunchDid I?
11:07:36liblq-devwhere'd you get 26 from?
11:07:45PMunch32 - 8?
11:08:03giaco__24 :P
11:08:11PMunchOh, woops :P
11:08:24PMunchI was looking at that thinking it looked wrong
11:08:32liblq-devthat's 24 bumbo
11:08:56PMunchI'm a computer scientist, not a mathematician :P
11:09:21FromDiscord<Rika> computer science is highly linked to mathematics
11:09:31giaco__btw I got the point. I also see there's a module for that https://nim-lang.org/docs/endians.html
11:09:48PMunchOh yeah, you shouldn't actually do it that way in real code :P
11:09:54liblq-devhere's how i (wouldn't) do it
11:09:55liblq-devreason: it's better to append bytes to an existing string buffer rather than allocate a new string each time you want to convert
11:10:14*liblq-dev < https://matrix.org/_matrix/media/r0/download/matrix.org/QxZfHIFXDQeesElBXmjldHxV/message.txt >
11:10:42liblq-devalso, isp is being unkind
11:10:56PMunch@Rika, I was just joking. But having been sat in front of a computer since I was a kid I haven't really had much use for doing math in my head
11:11:06giaco__I'm quite puzzled with your initial solution liblq-dev, what doas swap the endianess?
11:11:08PMunchIt's literally a big glorified calculator :P
11:11:40liblq-devgiaco__: in the first one? nothing
11:11:47liblq-devit stores the number in native endianness
11:12:06liblq-devon little endian that's reverse of how hex literals are written
11:12:27giaco__but it comes out swapped compared to what mystr.toHex.parseHexStr produces
11:12:42liblq-devthat's how it should be
11:12:50liblq-devtoHex converts the number to a string
11:12:56liblq-devrather than bytes
11:13:10liblq-dev0x41424344 is stored as 44 43 42 41 in memory on little endian architectures
11:13:48liblq-devand my first solution is literally just copying bytes around
11:13:49liblq-devthat's why it's endian dependent
11:14:16liblq-devtoHex will convert your int to a hex number, rather than bytes represented as hex
11:14:25liblq-devso the initial order of 41424344 is preserved
11:14:43PMunchHmm, I wonder what the performance of `let x = cast[array[4, uint8]](myUint32); return cast[uint32]([x[3], x[2], x[1], x[0]])` would be
11:15:04giaco__got it. Thanks for your patience. I'm just dealing for the first time with memcopy and endianess, and I'm quite scratching my head
11:15:27liblq-devyou'll understand it in due time
11:18:01giaco__back to the roots! https://developer.ibm.com/articles/au-endianc/#end
11:23:30giaco__ok I got the point! Article says that endianess doesn't matter with c-style strings, so is just the uint32 layed in little-endian in my x86 memory and the copyMem is just reading it as-is
11:29:15giaco__ok, so now I need to understand how to properly write the "toStringUsafe" in a endian independent way
11:30:15giaco__where I need to swap bytes for ints larger than 8 on little-endian machines before copyMem into the string
11:32:13liblq-devor just don't use copymem and use my solution above
11:32:34liblq-devwhich always orders the bytes in little endian order
11:32:37*narimiran quit (Quit: leaving)
11:36:24giaco__liblq-dev: but if I run your shr based solutions, would it work on big-endian architectures? There char(x and 0xff) would be the lsb so result[3]. I might be wrong, still wiring my head around this
11:38:22giaco__or nim ints are always little endian no matter the undelying memory when not dealing with casts and other unsafe stuff?
11:38:41liblq-devit will work no matter the architecture
11:38:47liblq-devbecause shl works the same no matter the endianness
11:41:27giaco__but "x and 0xff" would pick the LSB or MSB of the int depending on the arch endianess, or not?
11:49:34liblq-devno
11:49:42liblq-devbit operations don't care about endianness
11:49:52liblq-devbecause it wouldn't make much sense
11:50:19liblq-devthey operate on the int as a whole, not individual bytes
11:56:31giaco__that makes things easier. Thanks agains. I know I must look noob on this, but I've been working with high level languages all my life and now I have to unlearn to learn
11:56:59liblq-devthat's fine