1990506460531601538, 1977570893309321268

2026-08-25 01:12:52 -04:00
1 parent da75d92244
commit 9e994c42e8
@@ -0,0 +1,39 @@
+---
+title: "@NOTimothyLottes no floats ever logged? or some \"agreement\" that it's always multiplied by 100000 or something like that? besides, interesting (low-level) ideas I really like :)"
+type: archive
+source: twitter
+source_url: "https://x.com/questorInter/status/1977736160072839316"
+author: "Questor/Inter"
+handle: questorInter
+post_id: "1977736160072839316"
+date: 2025-10-13
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "@NOTimothyLottes no floats ever logged? or some \"agreement\" that it's always multiplied by 100000 or something like that? besides, interesting (low-level) ideas I really like :)"
+in_reply_to: ""
+parent_post_id: "1977570893309321268"
+---
+
+## Source
+
+- URL: https://x.com/questorInter/status/1977736160072839316
+- Author: Questor/Inter (@questorInter)
+- Posted: 2025-10-13 14:00:19
+
+## Branch
+
+**1/**
+
+@NOTimothyLottes no floats ever logged? or some "agreement" that it's always multiplied by 100000 or something like that? besides, interesting (low-level) ideas I really like :)
+
+**2/**
+
+@questorInter If I need to see a float, I scale it, then convert to an interger and print that. If it is the exact value, I just bit alias as 32-bit int and print that. Problem solved :) Similar if I need to see a 64-bit pointer, I write the hi and lo as two lines, etc.
+
+## Related
+
+- Spine: [[archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without]]
@@ -0,0 +1,39 @@
+---
+title: "@NOTimothyLottes I watched the video and one thing that was not clear to me is why is half of the file wasted."
+type: archive
+source: twitter
+source_url: "https://x.com/Karyuutensei/status/1979085608040489019"
+author: "Nick Tasios"
+handle: Karyuutensei
+post_id: "1979085608040489019"
+date: 2025-10-17
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "@NOTimothyLottes I watched the video and one thing that was not clear to me is why is half of the file wasted."
+in_reply_to: ""
+parent_post_id: "1977570893309321268"
+---
+
+## Source
+
+- URL: https://x.com/Karyuutensei/status/1979085608040489019
+- Author: Nick Tasios (@Karyuutensei)
+- Posted: 2025-10-17 07:22:33
+
+## Branch
+
+**1/**
+
+@NOTimothyLottes I watched the video and one thing that was not clear to me is why is half of the file wasted. Aren’t you using all upper 16 bits of the counter for the lines? Also, what do you mean with “no retries”?
+
+**2/**
+
+@Karyuutensei Could have just used pow2 pages + 1 page for counter, but I got lazy. Yes could use more than 16-bits for line counter too. Reload counter could be 4-bits. Lock-free typically implies a retry-loop (non-wait-free). This however is wait-free (no retry-loop).
+
+## Related
+
+- Spine: [[archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without]]
@@ -0,0 +1,40 @@
+---
+title: "Short talk on how I do CPU-side debugging without a debugger using a simple memory mapped file message logging system with lock-free atomic and file-io-free message store: https://www.youtube.com/watch?v=EaUSAVcXwEc ..."
+type: archive
+source: twitter
+source_url: "https://x.com/NOTimothyLottes/status/1977570893309321268"
+author: "NOTimothyLottes"
+handle: NOTimothyLottes
+post_id: "1977570893309321268"
+date: 2025-10-13
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "Short talk on how I do CPU-side debugging without a debugger using a simple memory mapped file message logging system with lock-free atomic and file-io-free message store: https://www.youtube.com/watch?v=EaUSAVcXwEc ..."
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/NOTimothyLottes/status/1977570893309321268
+- Author: NOTimothyLottes (@NOTimothyLottes)
+- Posted: 2025-10-13 03:03:37
+
+## Thread
+
+**1/**
+
+Short talk on how I do CPU-side debugging without a debugger using a simple memory mapped file message logging system with lock-free atomic and file-io-free message store: https://www.youtube.com/watch?v=EaUSAVcXwEc ... contains the implementation as well
+
+Branches: [[archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/2025-10-13-questorInter-no-floats-ever-logged-or-some-agreement-that-its]], [[archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without/2025-10-17-Karyuutensei-i-watched-the-video-and-one-thing-that-was-not]]
+
+**2/**
+
+@NOTimothyLottes No retries - you should call it wait-free too.
+
+**3/**
+
+@AgileJebrim Good point, I'm going to adopt that 'wait-free' term moving forward :)
@@ -47,6 +47,7 @@ tags:
 - [[archive/threads/NOTimothyLottes/2025-07-31-people-claim-assembly-is-hard-a-good-counter-to]]
 - [[archive/threads/NOTimothyLottes/2025-08-01-also-run-from-gpu-side-editing-tools-for-shader]]
 - [[archive/threads/NOTimothyLottes/2025-08-02-so-far-the-plan-is-to-have-the-data-read-write]]
+- [[archive/threads/NOTimothyLottes/2025-10-13-short-talk-on-how-i-do-cpu-side-debugging-without]]
 - [[archive/threads/NOTimothyLottes/2025-11-17-i-wish-everyone-would-just-adopt-reversed-with]]
 - [[archive/threads/NOTimothyLottes/2026-01-14-can-do-that-but-at-least-these-kinds-of-systems]]
 - [[archive/threads/NOTimothyLottes/2026-03-08-ill-add-one-conspiracy-theory-for-everyone]]
@@ -0,0 +1,43 @@
+---
+title: "@valigo Wouldn't this make working with arrays more difficult? Array[1] would have to be Array[sizeof(data)] etc"
+type: archive
+source: twitter
+source_url: "https://x.com/Ron172892111531/status/1990816225815875661"
+author: "maple zero-op"
+handle: Ron172892111531
+post_id: "1990816225815875661"
+date: 2025-11-18
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - valigo
+description: "@valigo Wouldn't this make working with arrays more difficult? Array[1] would have to be Array[sizeof(data)] etc"
+in_reply_to: ""
+parent_post_id: "1990506460531601538"
+---
+
+## Source
+
+- URL: https://x.com/Ron172892111531/status/1990816225815875661
+- Author: maple zero-op (@Ron172892111531)
+- Posted: 2025-11-18 16:15:50
+
+## Branch
+
+**1/**
+
+@valigo Wouldn't this make working with arrays more difficult? Array[1] would have to be Array[sizeof(data)] etc
+
+**2/**
+
+@Ron172892111531 As I said somewhere else, it makes sense sizeof pointer math to be the default. I was just saying that it's confusing because "+1" is not actually "plus one"
+
+**3/**
+
+@valigo Ptr+1. It's not plus one byte (or int addition), it's plus one object. I think it's only confusing when people assume pointers are just fancy integers. They're meant to work with arrays, and they do flawlessly as long as one remembers that they are an extension of the array
+
+## Related
+
+- Spine: [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer]]
@@ -0,0 +1,37 @@
+---
+title: "It is confusing if you aren't used to it, that is true."
+type: archive
+source: twitter
+source_url: "https://x.com/TheBonkMaykr/status/1990800281248936078"
+author: "bonk 🇺🇸🐍"
+handle: TheBonkMaykr
+post_id: "1990800281248936078"
+date: 2025-11-18
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - valigo
+description: "It is confusing if you aren't used to it, that is true."
+in_reply_to: ""
+parent_post_id: "1990506460531601538"
+---
+
+## Source
+
+- URL: https://x.com/TheBonkMaykr/status/1990800281248936078
+- Author: bonk 🇺🇸🐍 (@TheBonkMaykr)
+- Posted: 2025-11-18 15:12:28
+
+## Branch
+
+**1/**
+
+It is confusing if you aren't used to it, that is true. But if you care about portability, letting the C compiler decide what the size of a pointer is, and how to handle pointer arithmetic, is better long-term.
+
+You could also use the [] array index operator instead, since arrays are technically pointers themselves they work under the same rules, so just think of pointers to raw data as heap arrays.
+
+## Related
+
+- Spine: [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer]]
@@ -0,0 +1,41 @@
+---
+title: "@valigo Pointer arithmetic based on type sizes makes sense when considering aligned load/store memory operations."
+type: archive
+source: twitter
+source_url: "https://x.com/attamayte1/status/1990701881744896485"
+author: "Alexander Bright"
+handle: attamayte1
+post_id: "1990701881744896485"
+date: 2025-11-18
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - valigo
+description: "@valigo Pointer arithmetic based on type sizes makes sense when considering aligned load/store memory operations."
+in_reply_to: ""
+parent_post_id: "1990506460531601538"
+---
+
+## Source
+
+- URL: https://x.com/attamayte1/status/1990701881744896485
+- Author: Alexander Bright (@attamayte1)
+- Posted: 2025-11-18 08:41:28
+
+## Branch
+
+**1/**
+
+@valigo Pointer arithmetic based on type sizes makes sense when considering aligned load/store memory operations.
+
+I’d argue that even today, with relaxed rules, we commonly use typed arrays and calculate offsets in bytes only when working with generic buffers, like binary data blobs.
+
+**2/**
+
+@attamayte1 Yeah it makes sense for it to be the default. It's still confusing :)
+
+## Related
+
+- Spine: [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer]]
@@ -0,0 +1,35 @@
+---
+title: "@valigo For real I'm parsing through a binary array and trying to say \"the next byte is a uint8_t, the next two bytes are a uint16_t\" and the most elegant way to do it is mind-numbingly ugly pointer bullshit."
+type: archive
+source: twitter
+source_url: "https://x.com/furiouswhopper/status/1990793698985324939"
+author: "Angurī Wappā"
+handle: furiouswhopper
+post_id: "1990793698985324939"
+date: 2025-11-18
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - valigo
+description: "@valigo For real I'm parsing through a binary array and trying to say \"the next byte is a uint8_t, the next two bytes are a uint16_t\" and the most elegant way to do it is mind-numbingly ugly pointer bullshit."
+in_reply_to: ""
+parent_post_id: "1990506460531601538"
+---
+
+## Source
+
+- URL: https://x.com/furiouswhopper/status/1990793698985324939
+- Author: Angurī Wappā (@furiouswhopper)
+- Posted: 2025-11-18 14:46:19
+
+## Branch
+
+**1/**
+
+@valigo For real I'm parsing through a binary array and trying to say "the next byte is a uint8_t, the next two bytes are a uint16_t" and the most elegant way to do it is mind-numbingly ugly pointer bullshit.
+
+## Related
+
+- Spine: [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer]]
@@ -0,0 +1,35 @@
+---
+title: "@valigo I had the displeasure of being exposed to Hex-Ray’s decompiler for years so I have gotten used to it, but it is annoying ye…"
+type: archive
+source: twitter
+source_url: "https://x.com/mrsteyk1/status/1990655861749133343"
+author: "mrsteyk"
+handle: mrsteyk1
+post_id: "1990655861749133343"
+date: 2025-11-18
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - valigo
+description: "@valigo I had the displeasure of being exposed to Hex-Ray’s decompiler for years so I have gotten used to it, but it is annoying ye…"
+in_reply_to: ""
+parent_post_id: "1990506460531601538"
+---
+
+## Source
+
+- URL: https://x.com/mrsteyk1/status/1990655861749133343
+- Author: mrsteyk (@mrsteyk1)
+- Posted: 2025-11-18 05:38:36
+
+## Branch
+
+**1/**
+
+@valigo I had the displeasure of being exposed to Hex-Ray’s decompiler for years so I have gotten used to it, but it is annoying ye…
+
+## Related
+
+- Spine: [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer]]
@@ -0,0 +1,35 @@
+---
+title: "@valigo Interestingly, if you try to write Rust in this way, pointer provenance will cause misoptimizations that break everything."
+type: archive
+source: twitter
+source_url: "https://x.com/levs57/status/1993312449379127742"
+author: "🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️"
+handle: levs57
+post_id: "1993312449379127742"
+date: 2025-11-25
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - valigo
+description: "@valigo Interestingly, if you try to write Rust in this way, pointer provenance will cause misoptimizations that break everything."
+in_reply_to: ""
+parent_post_id: "1990506460531601538"
+---
+
+## Source
+
+- URL: https://x.com/levs57/status/1993312449379127742
+- Author: 🏴 LevS (of ether) 🏴 💙💛🇮🇱☀️🦁🗡️ (@levs57)
+- Posted: 2025-11-25 13:34:56
+
+## Branch
+
+**1/**
+
+@valigo Interestingly, if you try to write Rust in this way, pointer provenance will cause misoptimizations that break everything.
+
+## Related
+
+- Spine: [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer]]
@@ -0,0 +1,46 @@
+---
+title: "When it comes to pointers, \"just use 64 bit integer\" is way more intuitive to me."
+type: archive
+source: twitter
+source_url: "https://x.com/valigo/status/1990506460531601538"
+author: "Valentin Ignatev"
+handle: valigo
+post_id: "1990506460531601538"
+date: 2025-11-17
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - valigo
+description: "When it comes to pointers, \"just use 64 bit integer\" is way more intuitive to me."
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/valigo/status/1990506460531601538
+- Author: Valentin Ignatev (@valigo)
+- Posted: 2025-11-17 19:44:56
+
+## Thread
+
+**1/**
+
+When it comes to pointers, "just use 64 bit integer" is way more intuitive to me. I still remember how confusing it was that "pointer + 1" actually means "+ size_of(type_we_point_to)" when I learned all this stuff. It still kinda messes me up not gonna lie.
+
+Branches: [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-mrsteyk1-i-had-the-displeasure-of-being-exposed-to-hex]], [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-attamayte1-pointer-arithmetic-based-on-type-sizes-makes]], [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-furiouswhopper-for-real-im-parsing-through-a-binary-array-and]], [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-TheBonkMaykr-it-is-confusing-if-you-arent-used-to-it-that-is]], [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-18-Ron172892111531-wouldnt-this-make-working-with-arrays-more]], [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer/2025-11-25-levs57-interestingly-if-you-try-to-write-rust-in-this]]
+
+**2/**
+
+@valigo Distinct syntax for pointer arithmetic would be good. i.e. 
+ptr += 1; // ptr = ptr + 1;
+ptr ++= 1; // ptr = ptr + 1 * size_of(type_of(ptr));
+
+**3/**
+
+@onelivesleft Not sure I agree with specific sign choice but I kinda dig the concept
+
+**4/**
+
+@valigo Well, you know, only applicable for languages that don't have a ++ :P
@@ -10,3 +10,4 @@ tags:
 ---

 - [[archive/threads/valigo/2025-11-17-people-who-say-c-is-modern-day-assembly-usually]]
+- [[archive/threads/valigo/2025-11-17-when-it-comes-to-pointers-just-use-64-bit-integer]]