Tcl/Tk 9.1, 스크린 리더 접근성과 RTL 텍스트 지원 추가

Tcl/Tk 9.1 Released

Tcl/Tk 9.1.0이 2026년 9월 29일 공개됐다. Tcl 9.0 기반 위에 유니코드 정규화 명령과 마이크로초 해상도의 모노토닉 타이머, lfilter, interp set 등이 추가됐고, Tk에는 스크린 리더 접근성과 양방향 텍스트(RTL) 초기 지원, ttk::toggleswitch 위젯이 새로 들어갔다. macOS 대소문자 비구분 경로, 64비트 크기 확장, 리스트 내부 구조 개선도 포함됐다.

Tcl/Tk 9.1.0 is the current development work on Tcl and Tk, aiming toward stable releases in September 2026.
  1. srean

    나는 TCL에 대해 약간의 애정을 가지고 있다. 그 특이함과 별난 동적 문자열 유희 때문이다. 전문적으로 사용하는 것은 꺼려지겠지만, 재미로 가지고 노는 건... 너무 재미있다. Upvar와 uplevels는 정말 미쳤다.

    Python은 마치 처음으로 예비 배우자의 부모님을 방문했을 때 예의 바르게 행동하는 그런 멋진 언어다. 반면 Tcl은 학교 단짝 친구와 비밀스럽고 다소 위험한 게임을 하는 것과 같다.

    Tcl/Tk는 스크립팅 언어를 라이브러리로 사용하는 개념을 개척했다. 스레딩을 제대로 구현했다. 프로세스 주소 공간에서 여러 개의 독립적인 Tcl 인터프리터를 실행할 수 있고, 이들끼리 메시지를 교환할 수 있다. 인터프리터 상태 전체가 인터프리터 객체 안에 캡슐화되어 있고, 전역 변수가 없다. 사용자 입장에서는 그저 객체에 대한 포인터일 뿐이다.

    GIL도 필요 없고, 직렬화/역직렬화(pickle/unpickle)도 필요 없다... 그냥 프로세스 메모리 내 복사만 하면 된다(또는 데이터가 불변인 경우 복사조차 필요 없다).

  2. ripe

    Tcl은 확실히 좀 이상하고 익숙해지는 데 시간이 걸리지만, 그 특이함을 배울 가치가 있다고 생각한다. 특히 내 애플리케이션이 sqlite를 사용하는데, 이는 Tcl과 매우 자연스럽게 어울리기 때문이다.

    D. Richard Hipp의 말 [1]:

    "SQLite는 야생으로 탈출한 TCL 확장이다.

    "SQLite의 설계는 데이터 타입을 다루는 방식과 소스 코드 형식 모두에서 TCL의 설계에서 영감을 받았다. SQLite의 주요 사용 사례는 한 산업 회사의 Tcl/Tk 애플리케이션이었다. 처음부터 SQLite는 항상 TCL에 크게 의존해 왔다. 요즘 SQLite는 내부적으로 TCL을 더 이상 사용하지 않고 어떤 TCL 인터프리터와도 별도로 실행될 수 있지만, SQLite 개발 과정은 여전히 TCL에 크게 의존하고 있다."

    [1] https://www.tcl-lang.org/community/tcl2017/assets/talk93/Pap...

  3. neilv

    Tcl의 초기 최대 셀링 포인트는 Tk였다. Unixen과 X Window System에서 오픈 소스로 충분히 괜찮은 GUI 프로그램을 비교적 쉽게 만들 수 있는 방법이었다. C로 XView 같은 더 사용하기 쉬운 X 툴킷보다도 훨씬 쉬웠고, 다른 대안들은 거기서부터 더 어려워지기만 했다. 웹 프론트엔드는 없었다.

    Tcl 자체는 내가 실제로 문자열 기반 스크립팅 언어라고 부르는 것 중에서는 꽤 영리했다(Unix에서 앞서 나온 Bourne/C-shell 등과 대조된다).

    원래 Tcl은 기성 확장 언어 몇 가지 중 하나였다. 큰 애플리케이션을 C나 C++로 작성한 다음, 사용자나 원래 개발자가 기능을 추가할 수 있도록 고수준 확장 언어의 인터프리터를 내장하는 방식이다. 당시 선택지는 보통 작은 Lisp/Scheme, Tcl, Python, 또는 완전히 맞춤 제작된, 아마도 기이하고 어설픈 무언가였다.

    초기 닷컴 시절에는 백엔드 작업에 Tcl에 대한 상당한 관심이 있었고, 브라우저에 넣어도 최악의 선택은 아니었을 것이다. Python처럼 Tcl은 JavaScript보다 더 접근하기 쉽고 웹을 민주화했을 것이다. 그리고 이미 견고한 기성 설계와 구현이 있었다. (Scheme은 Python이나 Tcl보다 약간 더 위협적으로 보였을 것이고 더 강력했는데, 그래서 팀 버너스리가 여러 웹 용도를 위한 대중의 프로그래밍 언어로 Scheme보다 Python을 선호했다고 생각한다. 우리가 갖게 된 JavaScript의 의미론은 서둘러 만든 장난감 Scheme에 가장 단순한 객체 모델을 더한 것에 가까웠다 […]

  4. trebligdivad

    Tcl/Tk는 현존하는 가장 쉬운 GUI 시스템임에 틀림없다. 아무 노력 없이 간단한 것들을 만들 수 있다. 그 단순함에 근접한 것을 본 적이 없다.

    현대적인 지원을 받게 되어 반갑다.

  5. qalmakka

    Tcl은 자기 자신을 위해 너무 똑똑한 언어다. 모든 것이 문자열이거나 문자열로 해킹될 수 있어서, 기본적으로 전례 없는 수준의 메타프로그래밍을 할 수 있다는 점이 정말 좋다.

  6. neofytos

    커뮤니티와 핵심 팀에게 축하를 전한다. Tcl/Tk를 안정성, 실용성, 경량 크로스 플랫폼 개발의 금본위로 유지하려는 그들의 헌신은 고무적이다.

  7. Aldipower

    예전에 'Perl/Tk'라는 O'Reilly 책을 가지고 있었다. 아니, 아직 어딘가에 있을 거다... 언젠가 그 책을 읽는 것이 내 AI 회복 치료가 될지도 모른다는 느낌이 든다?

  8. rtpg

    tcl/tk로 만든 것에 대한 재미있는 이야기 가진 사람 있나? 이론적으로는 아직 작은 앱을 만들 여지가 있다고 생각하지만, 내 물건에 '임의의 리치 텍스트'를 집어넣고 싶어 하는 문제가 자주 생긴다(-> 그러면 갑자기 웹 기술이 꽤 잘 작동한다).

이 날의 다른 글

2026-09-29