diff options
Diffstat (limited to 'docs/research/025-native-authoring-shell.md')
| -rw-r--r-- | docs/research/025-native-authoring-shell.md | 103 |
1 files changed, 103 insertions, 0 deletions
diff --git a/docs/research/025-native-authoring-shell.md b/docs/research/025-native-authoring-shell.md new file mode 100644 index 0000000..960ae7a --- /dev/null +++ b/docs/research/025-native-authoring-shell.md @@ -0,0 +1,103 @@ +# 025 — 네이티브 작성 창을 실행 코어에 연결하고 비용을 분리 + +2026-09-24. Linux AArch64, GCC 14.2.0, GTK 4.18.6, Zig 0.15.2. +첫 공개 체크포인트의 중간 결과다. **네이티브 창을 만들었다는 사실만으로 마이크로 앱 런타임이나 +네이티브 UI 모델이 완성된 것은 아니다.** 이번에 확인한 경계는 편집 도구를 붙이면서도 실행 전용 +구성을 이전 크기로 유지할 수 있는지다. + +## 실제 작업 경로 + +`manage.py native --desktop`은 기존 `.pure` 정의와 같은 C 실행 코어·독립 scalar 인스턴스를 +링크한 Linux GTK4 작성 창을 만든다. 왼쪽은 GTK의 `GtkTextView`, 오른쪽은 현재 제한된 +box/circle/text 출력과 입력을 보여 주는 화면이다. 작성자는 소스를 고치고 **Apply source**를 +누른다. 기존 JS 컴파일러는 편집 호스트의 자식 프로세스에서 준비 정의를 만들고, C 컴파일러는 +그 읽기 전용 데이터만 공유 라이브러리로 만든다. 편집 호스트가 이를 열어 후보를 제출한다. + +```text +GTK 입력·편집 → 선택한 C 호스트 → 실행 코어의 작업 접수·완료 → scalar 앱 인스턴스 + ↓ + SQL 없는 상태 저장·복원 +``` + +새 정의 설치도 코어의 `plan` 입력으로 보낸다. 진행 중인 입력·작업이 있으면 거절하고, 같은 이름의 +상태는 이어받는다. 컴파일·정의 검증에 실패하면 이전 실행 정의와 상태가 남는다. 성공해야 소스 +파일을 기록하며, 상태 스냅샷은 별도 **Save state**로 조건부 저장한다. 정의가 달라진 스냅샷은 +자동 호환시키지 않는다. 재시작 때 편집 호스트가 소스를 준비·적용한 뒤 **Load state**를 +요청할 수 있다. 준비된 `.pure`를 실행하는 CLI에는 GTK·Node·컴파일러·동적 모듈 로더가 없다. + +실시간 적용은 **선택한 개발 호스트**의 기능이다. 작성된 실행물의 앱 연산 전체를 AOT 기계어로 +컴파일한 것은 아니다. 로컬에서 신뢰하는 `.pure`와 도구체인을 전제로 하며, 공유 라이브러리 +적재를 격리나 원격 코드 실행 경계로 제시하지 않는다. 소스 문자열은 기존 `prepare.mjs`에서 +바이트 escape로 생성하므로 작성한 문자열을 C 문장으로 삽입하지 않는다. + +소스 입력은 GTK의 일반 텍스트 위젯을 써서 선택·편집·실행 취소를 제공한다. 이 구성은 +[GTK의 텍스트 위젯](https://docs.gtk.org/gtk4/class.TextView.html)과 +[입력 컨트롤러](https://docs.gtk.org/gtk4/input-handling.html)에 의존한다. 별도의 macOS IME· +접근성 실사용 검증을 했다는 뜻은 아니다. 표시는 GTK `DrawingArea`의 콜백이며 그 안에서 +앱 상태를 바꾸지 않는다. 이는 [GTK의 DrawingArea 계약](https://docs.gtk.org/gtk4/method.DrawingArea.set_draw_func.html)을 따른다. + +## 실제 창에서 확인한 동작 + +[근거 폴더](../../prototypes/workbench/results/2026-09-24-native-desktop/)에 Xvfb의 실제 GTK 창을 +조작한 화면과 검사 결과를 보관했다. + +- 세 도형 예제의 녹색 도형을 드래그해 놓고 상태를 저장했다. 새 CLI 프로세스가 같은 스냅샷을 + 복원했으며 `green.x=167.07482993197277`, `green.y=154.82993197278913`, `held=0`이었다. +- 창의 소스 끝에 `text live(20,20,selected,"LIVE: ")`를 추가해 적용했다. 기존 선택·도형 위치가 + 유지됐고 출력 `LIVE: 1`이 나타났다. +- `invalid source line`을 추가하면 `Unknown declaration invalid (73:1)`을 한 줄로 보여 주고, + 직전 화면·상태·저장된 소스를 유지했다. 잘못된 줄을 지우고 다시 적용한 뒤 새 정의의 상태를 + 저장했다. 새 CLI 프로세스는 저장 버전 2에서 기존 도형 위치와 새 `live` 표시 값을 복원했다. +- 창을 1320×720에서 900×600으로 줄인 뒤 같은 내용을 확인했다. 별도 시나리오에서 축소한 + 창에서 드래그·방향키 입력 후 저장한 값을 CLI가 복원했다. +- `document.pure`의 숫자 입력에 99를 넣자 작성한 `clamp` 규칙에 따라 저장 값 `ratio=80`을 + CLI에서 확인했다. 실제 한국어 IME 입력 시나리오는 아직 수행하지 않았다. + +기존 작성물 9개·입력 156단계의 네이티브/Wasm 상태·표시 일치, 독립 인스턴스, 실패·저장 충돌· +정의 재설치 검사는 일반 C 호스트와 ASan/UBSan C 호스트에서 통과했다. Zig 모듈은 ReleaseSafe로 +빌드했으며 ASan 대상이었다고 주장하지 않는다. 기존 Node 회귀 검사 87개도 통과했다. + +## 마이크로 비용: 범위를 섞지 않음 + +GNU `size`의 `text/data/bss`는 ELF 섹션의 합이며 RSS가 아니다. 아래 RSS·PSS는 이 호스트에서 +한 번 관찰한 프로세스 수치다. 컴파일러 자식 프로세스와 Xvfb 자체는 편집 창 프로세스 수치에 +포함하지 않는다. + +| 선택한 범위 | Linux AArch64에서 관찰한 비용 | +|---|---:| +| 공통 실행 코어 아카이브 `text/data/bss` | 5,932 / 0 / 0 B, 기존 6 KiB 예산 통과 | +| 선택 scalar 라이브러리 `text` | 33,020 B (기존 결과) | +| scalar 인스턴스 / 앱 컨트롤러 | 20,064 / 928 B | +| 실행 전용 CLI `text/data/bss` | 62,827 / 2,040 / 16 B | +| 실행 전용 CLI stripped ELF | 68,000 B; 직접 동적 의존성 `libc.so.6` | +| 실행 전용 CLI 유휴 VmRSS | 1,552 KiB | +| GTK 작성 창 `text/data/bss` | 78,964 / 2,824 / 16 B | +| GTK 작성 창 stripped ELF | 134,224 B; GTK/Pango/Cairo/GLib 동적 의존성 추가 | +| GTK 작성 창 유휴 VmRSS / PSS | 36,512 / 23,618 KiB, `GSK_RENDERER=cairo GDK_DISABLE=gl,vulkan` | +| 같은 창의 기본 렌더러 유휴 VmRSS / PSS | 173,808 / 139,710 KiB, 별도 한 번의 관찰 | + +Xvfb에서는 GPU 가속이 없으므로 마지막 두 값은 렌더러 설정에 민감했다. GTK가 문서화한 +[`GSK_RENDERER`와 `GDK_DISABLE`](https://docs.gtk.org/gtk4/running.html) 설정으로 비교했으며, +실제 GPU 환경이나 macOS 수치로 확대하지 않는다. 36 MiB조차 1.5 MiB 실행 전용 앱과 같지 +않다. 편집기 전체를 마이크로라고 주장하지 않는다. + +작성 전용 정의 교체를 공통 `app.c`에 무조건 링크했을 때 CLI `text`가 63,507 B로 늘고, +AArch64 ELF 세그먼트 정렬 경계를 넘으면서 stripped 파일이 133,536 B가 됐다. +`PURE_NATIVE_AUTHORING` 선택 빌드로 분리한 뒤 CLI는 이전의 `text=62,827 B`, stripped +68,000 B로 돌아왔다. 단순히 함수 바이트 수만 보면 놓치는 **최종 실행물의 계단식 비용**이다. +코어 자체의 코드나 외부 의존성은 증가하지 않았다. + +## 아직 성립하지 않은 주장 + +현재 보기는 기존 `.pure`의 고정된 640×360 논리 좌표를 창 크기에 맞춰 확대·축소한다. 실제 +제약 기반 레이아웃, 터치·멀티 포인터의 네이티브 검증, UI 요소의 컨테이너 이동이나 완전한 +접근성은 아직 없다. GTK 편집 호스트는 소스 적용 동안 동기적으로 컴파일하므로 긴 컴파일은 +화면 응답을 막을 수 있다. 정의 설치 후 소스 파일 쓰기가 실패하면 새 정의는 메모리에만 남고 +오류를 표시한다. 재시도는 가능하지만 정의·파일을 하나의 트랜잭션으로 확정하지 않는다. +소스 파일 저장에는 다른 편집자의 변경에 대한 조건부 갱신도 아직 없다. macOS Apple Silicon의 +AppKit/Metal 경로는 구현·검증하지 않았다. + +더 중요한 전체 체크포인트 요구인 일반 앱 표현·비동기 I/O·Pure 간 인증된 RPC·큰 실서비스· +동등 조건 성능 비교도 남았다. UI 작성 창은 런타임 전체가 아니다. 다음 판단은 실행 전용 +구성을 작은 상태로 유지하면서 **실제 앱 작업**에서 네트워크·저장·UI를 연결할 수 있는지에 +달려 있다. |