1868712285675671711

2026-08-25 09:52:44 -04:00
1 parent 63f840bff2
commit e7e0392e1d
@@ -1,32 +0,0 @@
---
-title: "@AgileJebrim @GustavSterbrant Also I wouldn't just modify an existing compiler, I'd just write an assembler specific for GCN/RDNA/whateversNext family."
-type: archive
-source: twitter
-source_url: "https://x.com/NOTimothyLottes/status/1868716773937414589"
-author: "NOTimothyLottes"
-handle: NOTimothyLottes
-post_id: "1868716773937414589"
-date: 2024-12-16
-archived: 2026-08-23
-draft: true
-tags:
-  - archive
-  - twitter
-  - NOTimothyLottes
-description: "@AgileJebrim @GustavSterbrant Also I wouldn't just modify an existing compiler, I'd just write an assembler specific for GCN/RDNA/whateversNext family."
-in_reply_to: ""
---
-
-## Source
-
- URL: https://x.com/NOTimothyLottes/status/1868716773937414589
- Author: NOTimothyLottes (@NOTimothyLottes)
- Posted: 2024-12-16 17:56:12
-
-## Thread
-
-**1/**
-
-@AgileJebrim @GustavSterbrant Also I wouldn't just modify an existing compiler, I'd just write an assembler specific for GCN/RDNA/whateversNext family.
-
-Branches: [[archive/threads/NOTimothyLottes/2024-12-16-also-i-wouldnt-just-modify-an-existing-compiler/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess]]
@@ -7,8 +7,8 @@ author: "Jebrim"
 handle: AgileJebrim
 post_id: "1868717227866046808"
 date: 2024-12-16
-archived: 2026-08-23
-draft: true
+archived: 2026-08-25
+draft: false
 tags:
  - archive
  - twitter
@@ -32,4 +32,4 @@ parent_post_id: "1868716773937414589"

 ## Related

- Spine: [[archive/threads/NOTimothyLottes/2024-12-16-also-i-wouldnt-just-modify-an-existing-compiler]]
+- Spine: [[archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24]]
@@ -0,0 +1,44 @@
+---
+title: "@GustavSterbrant So I don't know that SPIR-V vs OpTypeInt 24 question, but if someone didn't write tests for that it's likely never been setup to be pattern matched."
+type: archive
+source: twitter
+source_url: "https://x.com/NOTimothyLottes/status/1868712285675671711"
+author: "NOTimothyLottes"
+handle: NOTimothyLottes
+post_id: "1868712285675671711"
+date: 2024-12-16
+archived: 2026-08-25
+draft: false
+tags:
+  - archive
+  - twitter
+  - NOTimothyLottes
+description: "@GustavSterbrant So I don't know that SPIR-V vs OpTypeInt 24 question, but if someone didn't write tests for that it's likely never been setup to be pattern matched."
+in_reply_to: ""
+---
+
+## Source
+
+- URL: https://x.com/NOTimothyLottes/status/1868712285675671711
+- Author: NOTimothyLottes (@NOTimothyLottes)
+- Posted: 2024-12-16 17:38:22
+
+## Thread
+
+**1/**
+
+@GustavSterbrant So I don't know that SPIR-V vs OpTypeInt 24 question, but if someone didn't write tests for that it's likely never been setup to be pattern matched. Most of the problems I see cannot be fixed just by bypassing GLSL and doing SPIR-V directly. So not yet tempted to write a new SL
+
+**2/**
+
+@NOTimothyLottes @GustavSterbrant If you’re targeting a console with AMD hardware, why don’t you just rewrite the backend compiler? I assume you have the source for it too, so it’s more tweaking an existing compiler than anything else?
+
+**3/**
+
+@AgileJebrim @GustavSterbrant At-home stuff (aka non-employer) targets Vulkan Windows mostly (unfortunately). No interface in AMD's Windows driver to load binary shaders into Vulkan. If SteamOS ever fully took over PC gaming, then certainly I'd just go direct to the AMD kernel driver and bypass user-mode VK
+
+**4/**
+
+@AgileJebrim @GustavSterbrant Also I wouldn't just modify an existing compiler, I'd just write an assembler specific for GCN/RDNA/whateversNext family.
+
+Branches: [[archive/threads/NOTimothyLottes/2024-12-16-so-i-dont-know-that-spir-v-vs-optypeint-24/2024-12-16-AgileJebrim-fair-enough-current-compilers-are-a-bloated-mess]]
@@ -24,18 +24,17 @@ python C:\projects\Threadwell\scripts\twitter\tw.py reslug --all --apply

 `paths.py` sets vault = two parents above this file, dumps = `../manual_slop/docs/twitter`, scratch = `../Threadwell-ai/scratch`.

-`refresh` = refetch (cookies) + ingest + emit `--force` + media_merge. `--tip` treats `--id` as the tip and walks back to the OP regardless of handle. Repeatable `--branch <tip-id>` captures only those additional explicit tip paths and merges them into the same `thread_data.json`; it does not discover replies automatically. Captures run sequentially with gallery-dl retries disabled and five-second extractor/request pacing. Each thread emits exactly one archive directory owned by the OP (the post with `reply_to_id == None`); cross-author responders do not get a directory. Does not flip `draft`. Does not commit. Frozen ids abort.
+`refresh` = refetch (cookies) + ingest + emit `--force` + media_merge. `--tip` treats `--id` as the tip and walks back to the OP regardless of handle. Repeatable `--branch <tip-id>` captures only those additional explicit tip paths and merges them into the same `thread_data.json`; it does not discover replies automatically. Captures run sequentially with gallery-dl retries disabled and five-second extractor/request pacing. Each thread emits exactly one archive directory owned by the OP (the post with `reply_to_id == None`); cross-author responders do not get a directory. New notes default to `draft: false` (publish by default). Does not commit. Frozen ids abort.

 `emit --preserve-existing` is the safe completion step after inspecting a fresh scratch capture. Fresh records win for ids the provider returned; posts present only in the existing emitted `thread_data.json` are retained after the command verifies both captures share a conversation root. This prevents an incomplete gallery-dl refresh from deleting archived replies. The merged scratch dataset keeps the requested `--id` as its stored spine tip before normal emission and media-manifest reconciliation.

 `add-branch` incrementally extends an already emitted thread. `--id` must be the original stored spine tip; repeatable `--from <reply-node>` values are each captured once. The command locally retains each node's missing attachment path and entire visible descendant subtree, merges only previously absent posts into the existing `thread_data.json`, downloads media for the new posts, and re-emits with the original spine unchanged. It preserves existing origin/local/fallback/derived/OCR media records and adds provider-origin plus local-copy records for new branch media. A visible leaf is only the deepest reply returned by that capture; the command does not query descendants individually or claim provider-wide completeness. Gallery-dl may return only the ancestor chain when replies are behind nested show-more cursors; then the command adds nothing and known reply/stream-tip ids must be supplied explicitly. Fallback upload remains a separate explicit action after origin unavailability is confirmed.

-Usual publish path after you like the note:
+New emits publish by default. `tw.py publish --id <snowflake>` is only used to flip a thread that was captured with `draft: true` (rare after this change). The usual review path is:

 1. `tw.py graph --id …` — confirm tip vs root.
 2. `tw.py refresh --id … --tip` if the dump stored a tip as root.
 3. `tw.py audit-media --id …` — confirm origin URLs are selected.
-4. `tw.py publish --id …` sets `draft: false`. You commit.

 Site wikilinks must be `[[archive/threads/<handle>/<date-slug>]]`. Short `[[slug]]` 404s.