#16 / 16
primary 언어인 Kotlin 의 LSP 가 콜드 스타트에 145초를 먹었다. 뻔해 보인 첫 수정이 거의 헛발이었고, 진짜 병목은 다른 자리에 있었다는 회고Tags
16 페이지
PAGE
#15 / 16
Atlas 의 의존성 그래프가 PAGE 자기 코드 앞에서조차 비어 있던 이유를 좇다 보니, import 를 해석한다는 건 결국 언어마다 다른 모듈 시스템을 한 조각씩 다시 구현하는 일이었다는 회고모든 import 가 import 는 아니다
#14 / 16
기능 하나를 추가할 때마다 콜백 사슬 넷을 엮어야 했던 PAGE 에디터 셸을, 불변 AppState 와 순수 reduce, 단일 onEvent 로 수렴시키되 단일 상태 객체와 타이핑 경로는 일부러 따르지 않은 재설계의 회고콜백이 흩어질 때, 상태를 onEvent 하나로 모으기
#13 / 16
`swift {file}` 한 줄로 끝날 줄 알았던 Swift 실행이 Windows 에서는 immediate 모드 부재부터 막혀, MSVC 헤더·링킹·tar long-name 까지 일곱 겹의 벽을 지난 회고`swift hello.swift` 한 줄이 Windows SDK 링킹까지 닿기까지
#12 / 16
한 줄짜리 설치 명령으로 끝날 줄 알았던 Ruby LSP 가 prebuilt 번들 다중 버전까지 늘어진 회고 — Windows 의 부재, MSYS2 의 무게, 마지막에 닿은 자리`gem install solargraph` 한 줄에서 prebuilt 번들 다중 버전까지
#11 / 16
'no version available' 한 줄에서 출발해 4계층 fallback 과 자동 갱신 파이프라인까지 도달한 회고rate limit 한 줄에서 4계층 fallback 까지
#10 / 16
본체 IDE 의 남은 기능과 code intelligence 재설계가 동시에 다음 차례라고 부를 때, 둘 사이의 공통 기반인 startup 측정 인프라부터 깐 결정의 회고다음 작업이 둘일 때, startup 측정기부터 깐 이유
#9 / 16
kotlin-language-server 의 textDocument/references 가 type-based 매칭으로 어긋난 위치를 돌려준다. fork 를 다시 안 뜨고 클라이언트 텍스트 스캔으로 우회한 회고references 가 잘못된 자리를 잡을 때, fork 가 답이 아니었던 이유
#8 / 16
kotlin-language-server 의 rename 이 top-level object 에서 NoTopLevelDescriptorProvider 로 죽는다. 한 줄 분기를 넓히기 위해 KLS 를 fork 해서 가져온 회고top-level object 이름을 바꾸려다 fork 까지 간 경위
#7 / 16
kotlin-language-server 의 signature help 는 어느 인자 자리에서 호출했는지 자주 빠뜨린다. 라인 텍스트만 보고 활성 파라미터를 다시 계산하는 fallback 의 회고