Skip to content

feat(B9.6e): delete dead hxtok.c BPE C library (.c 228β†’227) - #1820

Merged
dancinlife merged 2 commits into
mainfrom
b9.6e-hxtok-port
May 27, 2026
Merged

dancinlife merged 2 commits into
mainfrom
b9.6e-hxtok-port

Conversation

@dancinlife

Copy link
Copy Markdown
Contributor

Summary

Why it's a clean dead-file removal (investigated read-only first)

  • Zero build references: no tool/*, *.json, or *.sh builds or links hxtok / libhxtok; no .so/.dylib artifacts exist.
  • Zero FFI callers: repo-wide grep for HxTok / hxtok_load / hxtok_encode / hxtok_free / hxtok_special_id / hxtok_vocab_size / hxtok_merges_count / hxtok_version_v1 finds no code reference outside the lib itself. The single match (compiler/roadmaps_archive/embedded.gen.hexa) is an archived-roadmap text literal (libhxtok.so inside a frozen JSON string), not a code reference.
  • Pre-existing pure-hexa equivalent: self/ml/qwen_bpe.hexa ("Qwen2.5 BPE tokenizer (pure hexa)") + self/ml/tokenizer_bpe.hexa already implement byte-level BPE reading the same HuggingFace tokenizer.json. All 8 listed consumers use this hexa path; none extern/FFI the C lib.
  • Not #included by runtime.c (standalone) β†’ no wipe-prone runtime surface touched.

RUNEQ note (honest)

A live RUNEQ between hxtok.c and the hexa path is moot: the C lib has zero live callers, so it carried no behavior to break. The equivalence evidence is structural β€” after deletion all 8 consumers parse cleanly (hexa parse OK on qwen_bpe / tokenizer / tokenizer_bpe / tokenizer_test / tokenizer_trainer / self/test_tokenizer* / flame_bpe_corpus_lib / flame_bpe_corpus_test), proving they never depended on the deleted file.

Docs reconciled

  • RUNTIME.flip.md B9.5a flipped [β›”DUP] β†’ [x], new [x] B9.6e entry added.
  • docs/runtime_native_c_layer_audit.md β€” hxtok.c row + layer-β‘  list + priority list reclassified as DELETED.

Test plan

  • .c count: find . -name '*.c' = 227 (was 228)
  • All 8 BPE consumers hexa parse cleanly post-deletion
  • Repo-wide grep confirms zero HxTok/hxtok_* code callers

πŸ€– Generated with Claude Code

dancinlife and others added 2 commits May 28, 2026 06:11
self/native/hxtok.c (750L) + hxtok.h (49L) β€” a standalone Qwen2.5 BPE
tokenizer C lib β€” is a dead shim: zero build scripts reference it
(tool/*, *.json, *.sh), zero .so/.dylib artifacts exist, and zero code
FFI-calls HxTok/hxtok_* anywhere in the repo (the only repo-wide match
is an archived-roadmap text literal in compiler/roadmaps_archive, not a
code reference). All 8 listed consumers (self/ml/qwen_bpe, tokenizer,
tokenizer_bpe, tokenizer_test, tokenizer_trainer, self/test_tokenizer*,
stdlib/flame/flame_bpe_corpus_*) use the pre-existing pure-hexa BPE
path (qwen_bpe.hexa / tokenizer_bpe.hexa), never the C lib.

After deletion all 8 consumers parse cleanly, proving the C lib carried
no live behavior β€” RUNEQ is moot (zero live callers). Not in runtime.c
(standalone). This is the v565_grad_analysis.c (#1818) / crypto_blowfish
(#1816) dead-file git-rm pattern, NOT a from-scratch port. RUNTIME.flip
B9.5a flipped [β›”DUP]β†’[x]; audit doc reclassified.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@dancinlife
dancinlife merged commit 959dc07 into main May 27, 2026
2 of 4 checks passed
dancinlife added a commit that referenced this pull request May 27, 2026
#1821)

self/native/hxvocoder.c (455L) β€” a standalone HEXA-SPEAK neural-vocoder
C lib (additive synth sin/exp/clip hot-loop, libm-only) β€” is a dead
shim. Re-verified from scratch (the docs/runtime_native_c_layer_audit.md
"layer β‘  port candidate, neural_vocoder.hexa reference exists" verdict
was wrong on two counts): all 8 exported symbols (hxvocoder_decode_nv /
_decode_wave / _linear_proj / _synth_additive / _tanh_vec / _vec_zeros /
_version / _write_wav) have ZERO references in any .hexa/.c code file
(only repo-wide matches are archived text in roadmaps_archive). The sole
build reference is a file_exists()-guarded optional link in
tool/build_native.hexa that auto-skips once the file is gone β€” that dead
block is removed too. No .h/.so/.dylib/.o artifact, no build_toolchain
.json entry, no dlopen. Not #include'd by runtime.c (standalone). The
audit's claimed neural_vocoder.hexa does not exist in-tree; the "1,922x
vocoder" is the pure-hexa Griffin-Lim path in self/ml/speech_audio.hexa.

clang -fsyntax-only self/runtime.c EXIT=0 (untouched), zero remaining
hxvocoder_* symbol refs in code post-deletion. This is the hxtok (#1820)
/ v565 (#1818) / blowfish (#1816) dead-file git-rm pattern, NOT a port.

B9.6f re-verification ledger (the audit's 4 "primary suspects"): only
hxvocoder is DEAD. hxflash_linux / hxlayer_linux / hxvdsp_linux are LIVE
β€” each has real extern-fn FFI consumers + a dedicated build script
(self/ml/hxflash.hexa+gpu_train, self/ml/hxlayer.hexa+bench/test,
bench/hxblas_linux.hexa @link("hxvdsp")) β€” they need a multi-session
port, NOT a clean delete. All other standalone native .c (gpu_codegen
_stub, hxffi_slot, hxblas, hxccl, hxlmhead, hxqwen14b/32b, lora_cuda
_host, hexa_cc) re-scanned = all LIVE with callers/build-refs (PRESERVE).
RUNTIME.flip B9.6f [x]; audit doc reconciled (B9.6d table corrected).

Co-authored-by: dancinlife <search5599@proton.me>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@dancinlife
dancinlife deleted the b9.6e-hxtok-port branch June 13, 2026 20:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant