Tcl 9.0 출시

 (tcl-lang.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Tcl/Tk 9.0은 Tcl과 Tk의 최신 주요 릴리스로, 새 기능과 Tcl/Tk 8 대비 일부 비호환성을 함께 제공함
  • 최신 릴리스 표기는 Tcl/Tk 9.0.4이며 날짜는 2026년 6월 26일임
  • Tcl은 2GB를 넘는 데이터 값을 다루는 64-bit capacity를 제공하며, 문자열은 사용 가능한 메모리 범위에서 임의 길이를 가질 수 있고 리스트와 딕셔너리는 매우 많은 요소를 가질 수 있음
  • 텍스트 처리는 전체 Unicode 코드포인트 범위, utf-16·utf-32·ucs-2 계열과 CESU-8 등 새 인코딩, I/O 인코딩을 제어하는 encoding profiles, source의 기본 -encoding utf-8을 제공함
  • Tcl은 zipfs로 zip 파일을 파일시스템처럼 마운트할 수 있으며, 실행 파일이나 라이브러리에 붙인 파일시스템 아카이브로 starkit 방식의 애플리케이션 배포를 지원함
  • Unix 이벤트 처리 엔진은 사용 가능한 경우 epoll 또는 kqueue 기반으로 구성되며, 해당 시스템 호출이 없는 플랫폼에는 select 기반 구현이 남아 있음
  • Tcl 9.0의 주요 비호환성으로 한정되지 않은 변수 이름이 전역이 아니라 현재 namespace에서 해석됨, I/O malencoding의 기본 응답이 오류(-profile strict)로 바뀜, 경로의 ~가 홈 디렉터리로 해석되지 않음, $::tcl_precision이 double의 문자열 생성 제어에 더 이상 쓰이지 않음
  • 빌드와 플랫폼 변경으로 --disable-threads 빌드 옵션이 제거되어 항상 thread-enabled이며, Windows는 Windows 7 또는 Windows Server 2008 R2 이상이 필요함
  • Tcl C 확장은 Tcl 8.6 이하를 대상으로 빌드한 바이너리가 Tcl 9.0에서 동작하지 않으며, Tcl 9.0의 ABI 호환성은 목표가 아니었고 대부분의 경우 제거된 API 함수를 쓰지 않으면 Tcl 9.0 대상으로 재빌드 가능함
  • C 공개 인터페이스는 많은 인자가 int에서 Tcl_Size로 확장됐고, Tcl_ChannelTypeVersion 5 미만 지원 종료, Tcl_ObjType 구조체 버전 관리 도입, CONST* 매크로와 여러 API 함수 제거가 적용됨
  • Tk 9.0.0은 Tcl 8.6을 지원하지 않으며, Tk 9.0.0 사용에는 먼저 Tcl 9.0.0이 필요함
  • Tk는 OS 알림·출력·트레이 기능 접근을 위한 tk sysnotify, tk print, tk systray를 제공함
  • Tk 이미지는 부분적 SVG 지원, photo image metadata 읽기·쓰기, alpha channel 접근을 제공함
  • Tk의 내장 위젯과 테마는 scaling-aware로 바뀌었고, 사용 가능한 환경에서 두 손가락 제스처 지원이 개선됐으며, tk windowingsystem의 “aqua”는 macOS 10.10 이상이 필요함
  • Tcl 9 마이그레이션 자료로 Migrating C extensions to Tcl 9와 Migrating scripts to Tcl 9가 제공됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 27년 만의 첫 메이저 릴리스임. 내부 구조가 64비트라 데이터가 매우 커질 수 있고, 최신 이모지를 포함한 전체 유니코드, Zip 파일 시스템 등 새 기능이 많음
    오래된 찌꺼기도 일부 제거돼 몇몇 프로그램은 업데이트가 필요할 수 있지만, 여전히 호환성은 높은 편임. 위 페이지에서 포함/제외된 기능을 자세히 적은 릴리스 노트로 연결됨

    • Zip 파일 시스템 변화가 정말 반가움. 예전에는 독립 실행 애플리케이션을 만들 때 커뮤니티에서 특정 도구와 노하우로 쓰던 여러 기법을 표준 방식의 기본 도구 모음에 넣어준 셈이라 훌륭한 변화임
    • Home 디렉터리로 가는 편리한 단축 표기였던 물결표 ~ 를 왜 제거했는지 궁금함

  • 언어 순수주의자와 1990년대식 객체지향 순수주의자들은 Tcl을 정말 싫어하지만, 생태계에는 특별한 설계 철학이 있음
    모든 것이 문자열이거나 명령이고 객체지향 확장은 다소 덧댄 느낌이지만, tkinter처럼 Python으로 Tcl을 쓰는 대신 순수 Tcl/Tk로 GUI를 만들어보거나, SQLite 인터페이스를 써보거나, 작은 C 확장을 작성하거나 라이브러리를 감싸보면 많은 부분이 그냥 잘 동작함

    • antirez가 쓴 Tcl 글 [1]에서 흥미로운 관점을 봤음. 기억이 맞다면 Redis는 테스트 스크립트에 Tcl을 씀
      https://folk.computer 문서에서 링크를 타고 봤는데, 이 프로젝트도 Tcl을 스크립트 언어로 사용함. 그런 용도라면 Tcl을 딱히 싫어할 이유가 없을지도 모르겠음
      [1] http://antirez.com/articoli/tclmisunderstood.html
    • Tcl 덕분에 우리 스타트업이 가능했고, 그때 얻은 경험과 배움이 OutSystems의 출발점이 됐음
      그중 하나는, 완전한 웹 서버에는 다시는 JIT 컴파일러 없는 동적 언어를 쓰고 싶지 않다는 것이었음. 언어 자체는 훌륭하지만 성능 문제 때문에 Tcl 라이브러리를 정기적으로 C로 다시 쓰는 일은 별로였음
    • “모든 것이 문자열이거나 명령”이라는 말이 과장이 아님. 정말 모든 것이 명령이라, 여기 있는 주석 처리 방식은 “대체 왜 이러는 거야” 싶은 수준임: https://wiki.tcl-lang.org/page/comment
      주석을 쓰기 전에 ;로 명령을 끝내야 하고, 중괄호 짝이 안 맞으면 안 되니 잘못된 코드를 주석 처리하려 하면 안 되며, 주석 안에 백슬래시도 넣을 수 없음. 다만 이것도 기능이라고 설명하는데, wish를 실행할 때 아래처럼 쓰기 때문임
      #!/bin/sh
      # the next line restarts using wish \
      exec wish8.0 "$0" "$@"
      백슬래시는 셸에서는 무시되지만 wish에서는 파싱됨
    • Citus의 TPC 벤치마크 작업을 하면서 Tcl을 많이 다뤘음
      https://github.com/TPC-Council/HammerDB/blob/master/src/post...
      Tcl은 셸 스크립트 언어로는 괜찮은 편임

  • Tcl의 중앙 이벤트 처리 엔진이 사용 가능할 때 epoll 또는 kqueue 위에 구축되고, 그렇지 않은 플랫폼에는 select 기반 구현이 남는다는 점은 엄청난 변화임
    Tcl의 동시성이 낡았고 성능이 낮다고 여겨진 큰 이유가, epoll과 kqueue가 최소 10년은 가능했는데도 select에 의존했기 때문임. Tcl은 시작하기 쉽고 메타프로그래밍도 쉬워서 좋아하는 언어 중 하나임

    • Tcl이 성능이 낮다고 여겨지는 주된 이유는 기본 연산이 CPython보다 대략 두 배 느리기 때문임. CPython도 빠른 편은 아님: https://news.ycombinator.com/item?id=41637953
      또 다른 이유는 우리가 빠른 Tcl을 어떻게 작성해야 하는지 잘 모른다는 점이고, 그 스레드에서 내가 의도치 않게 그걸 보여줬음

  • NaviServer [0]를 추천하고 싶음. 예전 이름은 AOLServer [1]였고, 실전에서 오래 검증된 방탄급 웹 서버임
    예전에 AOL을 구동하던 데 쓰였던 물건이라면 더 말할 필요가 없음. OpenACS [2]가 주요 프로젝트이고 1997년부터 존재해왔으며, 특히 Tcl과 함께 쓰면 매우 강력함. 아직 유지보수 중이고 이제 Tcl 9도 지원함
    JavaScript, Tcl, NaviServer 조합에 DNS Server, LDAP, Mail 같은 자체 모듈까지 더하면 강력한 도구가 됨. Tcl과 웹 개발에 입문하고 싶다면 둘을 함께 써보면 재미있는 결과물을 쉽게 만들 수 있어 추천함
    [0] https://wiki.tcl-lang.org/page/NaviServer
    https://github.com/naviserver-project/naviserver
    [1] https://news.ycombinator.com/item?id=35648805
    https://www.linuxjournal.com/article/6164
    [2] https://openacs.org/about/history
    https://openacs.org/

    • 1990년대 중반에 Tcl과 SQL을 배웠던 추억의 스택임. 당시에는 OpenACS가 아니라 ArsDigita Community System 자체를 갖고 놀았고, 그때 ArsDigita가 실제로 존재하던 시절이었음
      Pasadena, CA였는지 Glendale이었는지에 있던 사무실에서 ArsDigita가 후원하고 직접 가르친 무료 수업도 들었던 기억이 남. 아주 깊거나 길지는 않았지만 입문용으로 좋았음

  • Tcl을 처음 접하는 사람에게는, JavaScript 대신 Tcl이 브라우저 언어가 된 대체 우주도 있었음
    “흥미로운 각주: Netscape 창업은 내가 1994년 Berkeley를 떠나 업계에서 어디로 갈지 결정하던 시기와 겹쳤다. Jim Clarke와 Marc Andreessen은 내가 Netscape 창업자로 합류할 가능성을 타진했지만, 나는 결국 거절했다. 그들과 이야기할 당시에는 아직 웹 관련 일을 하기로 정하지도 않았다. 이는 내 경력에서 가장 큰 ‘만약’ 중 하나다. 내가 Netscape에 갔다면 Tcl이 JavaScript 대신 브라우저 언어가 되었을 가능성이 꽤 있고, 세상은 달라졌을 것이다! 다만 돌이켜보면 Tcl이 실제로 JavaScript보다 웹에 더 나은 언어였을지는 확신이 없으니, 어쩌면 올바른 일이 일어난 것일 수도 있다.”
    출처: https://pldb.io/blog/JohnOusterhout.html

    • 그럴 수도 있음. JavaScript가 자리 잡은 주된 이유 중 하나는 큰 역사적 짐이 없어서 설계자들이 필요한 방향으로 가져갈 수 있었기 때문이라고 봄
      몇 명 이상이 쓰는 언어는 아무리 좋아도 어떤 짐이 생김. 그래서 그 대체 우주에서는 브라우저 스크립트 언어 생태계가 훨씬 더 파편화됐을 수도 있음
    • 웹용 Tcl 안전 부분집합 작업은 지금도 신뢰할 수 없는 스크립트를 관리하기 쉬운 샌드박스에서 실행하는 데 활용할 수 있음
      원하면 명령을 충분히 제거해서 언어가 튜링 완전하지 않게 만들 수도 있음
    • 재미있게도 Tcl 브라우저 플러그인은 적어도 1996년부터 있었음
      https://sunsite.icm.edu.pl/pub/programming/tcl/plugin/
      그보다 전에 동료 학생들이 전산실에 와서 “봐, 이제 Mosaic용 TK 플러그인도 있어!”라고 했던 기억도 있음. “마우스 달린 gopher 같네!” 하던 시절은 아니었지만, 그리 오래 지나지도 않았음
      다만 Tcl 플러그인은 쓰려면 뭔가를 직접 해야 했고, JavaScript는 일단 들어오고 나서는 기본으로 제공됐음
    • 그런 일이 있었다 해도 세상이 TCL에 계속 머물렀을 것 같지는 않음. JavaScript는 사람들이 감수할 만큼은 충분히 좋았지만, TCL은 확실히 그렇지 않음
      아마 TCL과 다른 무언가가 함께 있다가, TCL은 폐기 예정이 됐을 가능성이 더 큼
    • “어쩌면 올바른 일이 일어난 것일 수도 있다”는 말에 전적으로 동의함
      set x [ expr $y + $z ] 같은 코드가 곳곳에 있는 건 보고 싶지 않았음. 명령 언어로서는 그렇게 나쁘지 않지만

  • Tcl을 정말 좋아한다고 해도 과장이 아님. 1990년대 후반 XiRCON IRC 스크립트를 쓸 때 잠깐 써본 정도였지만, 인간을 위한 Lisp라고 부를 만큼 단순하고 배우기 쉽고 유연한 우아한 언어였음
    더 인기 있었으면 좋겠고, 아직도 살아 움직이는 걸 보니 반가움

    • Tcl을 접한 건 IRC 봇 스크립트를 쓴 정도뿐이지만, 그 경험에는 좋은 기억밖에 없음
    • 90년대에 IRC 클라이언트용 TCL 스크립트를 썼고 정말 좋았음. 그 용도에는 언어가 훌륭했음
      다만 당시 다른 주력 언어가 x86 어셈블리였으니, 감탄의 기준이 낮았을 수도 있음
    • “인간을 위한 Lisp”라고 하기엔 upvar가 있음

  • Tcl과 Tk의 저자는 John Ousterhout 교수이고, 그의 소프트웨어 설계 책은 2판까지 나왔음
    A Philosophy of Software Design:
    https://web.stanford.edu/~ouster/cgi-bin/book.php

    • 이 책은 정말 훌륭한 책이고 지금 읽고 있는 중임. 한 장씩 읽고 가능한 한 깊이 생각한 다음, 그 교훈을 적용해 현재 프로젝트를 다시 작성하고 있음
      지금은 11장 “Design it Twice”에 와 있으니, 아마 끝까지 읽은 뒤 위에서 아래까지 전면 재작성할 것 같음. 현재는 변수만 최소 Python 코어에 두고 나머지는 OpenSCAD에 있는 모델인데, 새 구현에서는 가능한 모든 것을 Python에 두고 OpenPythonSCAD https://pythonscad.org/를 통해 사용할 계획임

  • 언어는 정말 좋아하지만 요즘은 많이 쓰지 않음. Linux에서도 아직 1995년식 GUI를 만들어내는지 궁금함
    다른 플랫폼에서 오래전부터 가능했던 수준의, 그럭저럭 합리적인 Linux GUI 지원만 있었어도 지금도 쓰고 있었을 듯함

    • 테마 엔진은 이미 15년쯤 전에 들어갔음. 기본 테마는 꽤 낡아 보이지만 다른 테마도 많음: https://wiki.tcl-lang.org/page/List+of+ttk+Themes
      다만 핵심 테마 스크린샷은 8.5/8.6 기준이고, 특히 기본 테마는 Tk 9에서 조금 바뀌었음. 함정은 테마 엔진이 자체 새 위젯을 쓰기 때문에, 애플리케이션이 테마를 적용받으려면 새 API를 써야 한다는 점임. 1995년이나 2005년 코드라면 여전히 1995년식 GUI가 나옴
    • Python을 배울 때 Tkinter를 쓰던 기억이 남. 다른 GUI도 있지만 최신 GUI로 동작하는 예제를 찾는 건 더 번거로움
      문서가 너무 오랫동안 Tk(inter) 중심이어서 대부분이 기본값처럼 선택하는 것 같음. Python은 GUI 지원이 더 나아졌지만, 아마 머신러닝/AI 사용 인기가 영향을 줬을 것임. Tcl은 인기가 덜하니 최신 GUI 사용법 문서를 찾으려면 더 꼼꼼히 확인해야 함

  • 최근에 Tcl을 다뤄본 건 MacPorts portfile 작업 정도뿐임
    요즘 다른 용도로 쓰는 사람이 있다면 왜 쓰는지 궁금함. 언어를 싫어하진 않지만 좋아하게 되지도 않음

    • Tcl은 C 프로그래머를 위한 Lisp에 가깝다고 생각함. Lisp에서 얻는 메타프로그래밍 능력을 C처럼 보이고, C와 잘 어울리고, 일반적인 셸 언어보다 훨씬 직관적이며, 크로스플랫폼 GUI까지 있는 언어로 제공함
      숙련된 Tcl 프로그래머는 마법을 부릴 수 있음. 2005년부터 2015년까지 거의 전적으로 Tcl/Tk로 프로그래밍했고 정말 좋아했음. 그 뒤로는 앱 작성보다는 가벼운 스크립트에 주로 쓰지만, 운영체제 수준의 자동화 스크립트를 짜야 할 때 여전히 1순위 선택임
    • 표준적인 사용처는 F5 네트워크 장비와 A10 장비의 BigIP iRules[0], Argonne National Labs 슈퍼컴퓨터의 오케스트레이션[1], Tealeaf[2], Python Tkinter[3] 등임
      매일 쓰는 이유는 Lisp적인 면과 단순한 스크립트 언어스러움의 균형이 좋고, C 인터페이스가 훌륭하기 때문임. REPL도 괜찮고, C로 확장을 작성해 100% 일급 Tcl처럼 쌓아 올릴 수 있음. 이는 상당 부분, 어쩌면 전적으로, Tcl이 매우 단순한 언어[4]이고 동형성(homoiconicity)[5]을 갖기 때문임. 개발하고 쓰는 재미가 있음
      [0] https://community.f5.com/kb/technicalarticles/irules-concept...
      [1] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf
      [2] https://www.acoustic.com/pdf/Acoustic-Experience-Analytics-%...
      [3] https://docs.python.org/3/library/tkinter.html
      [4] https://www.tcl-lang.org/man/tcl/TclCmd/Tcl.htm
      [5] https://stackoverflow.com/questions/6492704/what-exactly-doe...
    • Tcl은 EDA 업계의 스크립트 언어임. 컴퓨터 칩을 설계한다면 TCL을 쓰고 있는 것임. Cadence와 Synopsys가 30년 넘게 TCL을 표준으로 삼아왔음
      장점은 EDA 도구를 run_my_task -option_a -option_B 같은 셸 스크립트 명령처럼 조작할 수 있다는 것임. 칩을 설계하지 않는다면 쓸 이유가 없고, 언어 자체는 끔찍함. EDA 업계가 TCL을 빨리 버릴수록 좋음
    • SQLite 창시자 Richard Hipp는 SQLite가 Tcl로 작성됐다고 말함. 데이터베이스 엔진 자체는 당연히 C로 작성됐지만, 훨씬 더 큰 테스트 스위트는 대부분 Tcl로 작성됐음
      그리고 SQLite를 지금처럼 신뢰할 수 있는 엔진으로 만드는 건 그 테스트 스위트임. 테스트 스위트는 계속 유지됐고, 엔진은 전체 또는 일부가 다시 작성돼 왔음
    • Freewrap 때문에 몇 번 Tcl을 썼음. 아주 적은 코드로 GUI가 있는 Windows 앱을 만들고 실행 파일로 쉽게 배포할 수 있었음
      온라인 판매 애플리케이션용 백업 앱, 대형 유통 체인의 버그 있는 POS 파일을 고치는 앱, Forms/Reports를 서버에 복사하고 컴파일을 실행한 뒤 새 파일을 git에 밀어 넣는 작은 앱, 미디어 부서가 여러 PDF를 하나로 합치기 쉽게 하는 gs 래퍼를 만들었음. 모두 코드가 한두 페이지 정도였음

  • Python 3.13보다 더 중요함
    Bravo !!!!
    Scilab과 Python이 Tcl/Tk 9.0을 포함해 배포하길 기다리고 있음. Next Scripting의 최신 릴리스는 9.0 준비가 된 것 같음. 공식 페이지의 Undroidwish와 Binary Releases 섹션을 지켜볼 만함

답변달기