대화저장검색.한선 — 셀코어 방사형셀DB 기반 임의 텍스트 저장·검색
개요
"출력된 텍스트/대화를 셀코어 로직으로 저장해 언제든 어떤 내용이든 찾을 수 있게" 요청에 따라
순수 한선씨로 문서 저장 + 역색인 + 부분어(substring) 검색 + 조회복원 라이브러리를 작성.
무엇을 했는지
/Users/ef/crowny-butler/libs/방사형셀DB.한선(K>27 방사형 셀 인덱스 DB, 기존 검증완료)을 재사용해
DB생성/저장/조회/주소화/셀수/플로어나눗을 그대로 활용.
가져오기 "셀코어"로 감사기록/감사조회/룰생성 등 15모듈 프레임워크를 병행 사용.- 신규 함수:
텍스트주소(폴리노미얼 해시→셀주소), 문서저장(20KB 청크 분할+저장+감사),
키워드추출(공백/개행/구두점 스트리밍 분리),
역색인추가(키워드→문서id, 상한 50),
검색(맵키목록 순회+포함()부분어 매칭, dedup),
조회복원(청크 재조립),
분할규칙생성(셀코어 룰: 본문길이>=20000→청크분할).
- 데모: 3문서 저장 → 검색("한선씨")·검색("셀코어") → 매칭 문서id + 조회복원 왕복.
최종 8/8 PASS, stderr 경고 0건.
실제로 부딪힌 VM 함정 3가지 (중요 — 재발 방지)
글자(s,i)는 정수 코드포인트가 아니라 1글자 문자열이다.
hanseonc_high가
글자(s,i)를
STR_SLICE(s,i,i+1)로 컴파일하기 때문(코멘트의
"유니코드 코드포인트"는 VM opcode 343 자체 설명일 뿐, 실제로는 이 경로를 안 탐).
→ 문자 비교는
글자(s,i) == " "처럼 리터럴과 직접 비교해야 하고, 정수 연산이
필요하면
코드값(글자(s,i))으로 다시 정수화해야 한다.
맵꺼내의 키 미스 센티넬은 -1이지, 없나()가 체크하는 -2147483647이 아니다.
만약 (없나(맵꺼내(...))) 패턴은 항상 거짓이 되어 미스 분기를 절대 타지 않는다.
→ 반드시
맵있나(맵,키)(opcode 751, "맵꺼내 -1과 무관한 존재확인")로 먼저 체크.
셀수(nT)가 crownyc 배열 캡(4095)을 넘으면 안 됨. 3^8=6561로 DB생성하면
내부 배열이 4095에서 조용히 잘리고(
[ARRAY] 배열 캡 도달), 이후
저장()이
"배열 범위 초과" 런타임 에러를 낸다. →
nT<=7(
3^7=2187)로 안전마진 확보.
관련 파일
/Users/ef/crowny-butler/libs/대화저장검색.한선 (신규, 256줄)/Users/ef/crowny-butler/libs/방사형셀DB.한선 (재사용, 무수정)/Users/ef/Downloads/CrownyTVM/std/셀코어.han (재사용, 무수정)
학습 등록
crownycode-learn.sh add "대화저장검색_셀코어_임의검색" "..." 완료. 별칭:
대화저장검색.
잔여 이슈
- 해시 기반 셀주소(
텍스트주소)는 폴리노미얼 해시라 이론상 충돌 가능(데모 규모에선 무충돌
확인됨). 실서비스 규모로 키우려면 nT를 늘리되 4095 캡을 넘지 않도록 저장을 여러 DB 샤드로
분산하거나 배열 캡 자체를 높이는 VM 패치가 필요.
- 검색은 부분어(substring) 매칭이라 색인 키가 많아지면
맵키목록 전체 순회 비용이 커짐
(문서 수 적은 대화저장용은 문제 없음, 대량화 시 트라이/접두어 인덱스 검토).