Veröffentlichung von Tcl 9.0
(tcl-lang.org)- Tcl/Tk 9.0 ist das neueste große Release von Tcl und Tk und bringt neue Funktionen sowie einige Inkompatibilitäten gegenüber Tcl/Tk 8 mit sich
- Die aktuelle Release-Bezeichnung ist Tcl/Tk 9.0.4, datiert auf den 26. Juni 2026
- Tcl bietet 64-bit capacity für den Umgang mit Datenwerten über 2 GB; Strings können innerhalb des verfügbaren Speichers beliebige Länge haben, und Listen sowie Dictionaries können sehr viele Elemente enthalten
- Die Textverarbeitung unterstützt den gesamten Bereich der Unicode-Codepoints, neue Encodings wie
utf-16-,utf-32-,ucs-2-Familien undCESU-8,encodingprofiles zur Steuerung von I/O-Encodings sowie standardmäßig-encoding utf-8fürsource - Mit
zipfskann Tcl ZIP-Dateien wie ein Dateisystem mounten und unterstützt die Bereitstellung von Anwendungen im starkit-Stil mit Dateisystem-Archiven, die an ausführbare Dateien oder Bibliotheken angehängt sind - Die Unix-Engine zur Ereignisverarbeitung wird, wenn verfügbar, auf Basis von epoll oder kqueue aufgebaut; auf Plattformen ohne diese Systemaufrufe bleibt eine
select-basierte Implementierung bestehen - Zu den wichtigsten Inkompatibilitäten in Tcl 9.0 zählen: Nicht qualifizierte Variablennamen werden nicht mehr global, sondern im aktuellen Namespace aufgelöst; die Standardreaktion auf I/O-Malencoding wurde auf Fehler (
-profile strict) geändert;~in Pfaden wird nicht als Home-Verzeichnis interpretiert;$::tcl_precisionwird nicht mehr zur Steuerung der String-Erzeugung von Doubles verwendet - Bei Build- und Plattformänderungen wurde die Build-Option
--disable-threadsentfernt, sodass Threads immer aktiviert sind; unter Windows wird mindestens Windows 7 oder Windows Server 2008 R2 benötigt - Für Tcl-C-Erweiterungen gilt: Binärdateien, die für Tcl 8.6 oder älter gebaut wurden, funktionieren nicht unter Tcl 9.0; ABI-Kompatibilität war für Tcl 9.0 kein Ziel, und in den meisten Fällen ist ein Rebuild für Tcl 9.0 möglich, sofern keine entfernten API-Funktionen verwendet werden
- In der öffentlichen C-Schnittstelle wurden viele Argumente von
intaufTcl_Sizeerweitert; die Unterstützung fürTcl_ChannelTypeVersionkleiner 5 wurde beendet; Versionierung für dieTcl_ObjType-Struktur wurde eingeführt;CONST*-Makros und mehrere API-Funktionen wurden entfernt - Tk 9.0.0 unterstützt Tcl 8.6 nicht, und für die Nutzung von Tk 9.0.0 ist zunächst Tcl 9.0.0 erforderlich
- Tk bietet
tk sysnotify,tk printundtk systrayfür den Zugriff auf OS-Benachrichtigungen, Ausgabe- und Tray-Funktionen - Tk-Bilder bieten teilweise SVG-Unterstützung, Lese- und Schreibzugriff auf photo image
metadatasowie Zugriff auf den Alpha-Kanal - Die eingebauten Widgets und Themes von Tk sind nun scaling-aware; die Unterstützung für Zwei-Finger-Gesten wurde, wo verfügbar, verbessert; und „aqua“ von
tk windowingsystemerfordert macOS 10.10 oder neuer - Als Migrationsmaterial für Tcl 9 stehen Migrating C extensions to Tcl 9 und Migrating scripts to Tcl 9 zur Verfügung
1 Kommentare
Meinungen auf Hacker News
Es ist das erste Major-Release seit 27 Jahren. Da die interne Struktur 64-Bit ist, können Daten sehr groß werden, und es gibt viele neue Funktionen wie vollständiges Unicode einschließlich aktueller Emojis und ein Zip-Dateisystem.
Ein Teil des alten Ballasts wurde ebenfalls entfernt, sodass einige Programme möglicherweise aktualisiert werden müssen, aber die Kompatibilität ist weiterhin recht hoch. Die oben genannte Seite verlinkt auf Release Notes, die die aufgenommenen und ausgeschlossenen Funktionen im Detail beschreiben.
~, die eine praktische Kurzschreibweise für das Home-Verzeichnis war, entfernt wurde.Sprachpuristen und Objektorientierungs-Puristen im Stil der 1990er hassen Tcl wirklich, aber das Ökosystem hat eine besondere Designphilosophie.
Alles ist entweder ein String oder ein Befehl, und die objektorientierten Erweiterungen wirken etwas aufgesetzt. Aber wenn man statt Tcl über Python wie bei tkinter einmal GUIs in reinem Tcl/Tk baut, die SQLite-Schnittstelle nutzt, kleine C-Erweiterungen schreibt oder Libraries wrappt, funktioniert vieles einfach gut.
Ich bin über einen Link in der Dokumentation von https://folk.computer darauf gestoßen; auch dieses Projekt nutzt Tcl als Skriptsprache. Für solche Zwecke gibt es vielleicht keinen besonderen Grund, Tcl nicht zu mögen.
[1] http://antirez.com/articoli/tclmisunderstood.html
Eine davon war, dass ich für einen vollständigen Webserver nie wieder eine dynamische Sprache ohne JIT-Compiler verwenden wollte. Die Sprache selbst ist hervorragend, aber wegen Performance-Problemen regelmäßig Tcl-Libraries in C neu zu schreiben, war nicht besonders schön.
Vor einem Kommentar muss man den Befehl mit
;beenden, geschweifte Klammern dürfen nicht unausgewogen sein, man sollte also keinen fehlerhaften Code auskommentieren wollen, und Backslashes dürfen auch nicht in Kommentare. Allerdings wird auch das als Feature erklärt, weil man beim Ausführen vonwishetwa Folgendes schreibt:#!/bin/sh# the next line restarts using wish \exec wish8.0 "$0" "$@"Der Backslash wird von der Shell ignoriert, aber von
wishgeparst.https://github.com/TPC-Council/HammerDB/blob/master/src/post...
Als Shell-Skriptsprache ist Tcl recht brauchbar.
Dass die zentrale Event-Processing-Engine von Tcl, wenn verfügbar, auf
epolloderkqueueaufbaut und für andere Plattformen eineselect-basierte Implementierung bleibt, ist eine enorme Änderung.Ein wichtiger Grund dafür, dass Tcls Nebenläufigkeit als veraltet und wenig performant galt, war die Abhängigkeit von
select, obwohlepollundkqueueseit mindestens zehn Jahren verfügbar waren. Tcl gehört zu meinen Lieblingssprachen, weil der Einstieg leicht ist und auch Metaprogrammierung einfach funktioniert.Ein weiterer Grund ist, dass wir nicht genau wissen, wie man schnellen Tcl-Code schreibt, und in diesem Thread habe ich das unbeabsichtigt demonstriert.
Ich möchte NaviServer [0] empfehlen. Früher hieß er AOLServer [1], und er ist ein in der Praxis lange erprobter, kugelsicherer Webserver.
Wenn etwas früher AOL betrieben hat, muss man dazu wohl nicht mehr viel sagen. OpenACS [2] ist ein wichtiges Projekt, existiert seit 1997 und ist besonders in Kombination mit Tcl sehr mächtig. Es wird noch gepflegt und unterstützt inzwischen auch Tcl 9.
JavaScript, Tcl und NaviServer, dazu eigene Module wie DNS Server, LDAP und Mail, ergeben ein mächtiges Werkzeug. Wer in Tcl und Webentwicklung einsteigen möchte, dem empfehle ich, beides zusammen auszuprobieren; damit lassen sich leicht interessante Dinge bauen.
[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/
Ich erinnere mich auch daran, dass ich in ihrem Büro, ich glaube in Pasadena, CA, oder vielleicht Glendale, kostenlose Kurse besucht habe, die ArsDigita gesponsert und selbst unterrichtet hat. Sie waren nicht sehr tiefgehend oder lang, aber als Einstieg gut.
Für alle, die Tcl zum ersten Mal begegnen: Es gab auch ein alternatives Universum, in dem Tcl statt JavaScript zur Browser-Sprache wurde
„Interessante Fußnote: Die Gründung von Netscape fiel in die Zeit, als ich 1994 Berkeley verließ und entschied, wohin ich in der Industrie gehen würde. Jim Clarke und Marc Andreessen loteten aus, ob ich als Netscape-Gründer dazustoßen würde, aber ich lehnte schließlich ab. Als ich mit ihnen sprach, hatte ich mich noch nicht einmal entschieden, etwas im Web-Bereich zu machen. Das ist eines der größten ‚Was wäre, wenn‘ in meiner Karriere. Wenn ich zu Netscape gegangen wäre, wäre Tcl ziemlich wahrscheinlich statt JavaScript zur Browser-Sprache geworden, und die Welt wäre anders gewesen! Rückblickend bin ich mir allerdings nicht sicher, ob Tcl tatsächlich eine bessere Sprache fürs Web gewesen wäre als JavaScript; vielleicht ist also doch das Richtige passiert.“
Quelle: https://pldb.io/blog/JohnOusterhout.html
Jede Sprache, die mehr als ein paar Leute verwenden, sammelt irgendeine Art Ballast an, egal wie gut sie ist. In diesem alternativen Universum hätte das Ökosystem der Browser-Skriptsprachen also deutlich stärker fragmentiert sein können
Wenn man will, kann man genug Befehle entfernen, sodass die Sprache nicht mehr Turing-vollständig ist
https://sunsite.icm.edu.pl/pub/programming/tcl/plugin/
Ich erinnere mich auch, dass Kommilitonen davor in den Rechnerraum kamen und sagten: „Schau, jetzt gibt es sogar ein TK-Plugin für Mosaic!“ Das war nicht mehr ganz die Zeit von „Sieht aus wie Gopher mit Maus!“, aber auch noch nicht lange danach
Allerdings musste man beim Tcl-Plugin etwas selbst tun, um es zu verwenden, während JavaScript, nachdem es einmal da war, standardmäßig mitgeliefert wurde
Wahrscheinlicher wäre, dass TCL eine Zeit lang neben etwas anderem existiert hätte und dann als deprecated gegolten hätte
Ich hätte nicht überall Code wie
set x [ expr $y + $z ]sehen wollen. Als Befehlssprache ist es zwar nicht so schlechtEs ist keine Übertreibung zu sagen, dass ich Tcl wirklich mag. Ich habe es zwar nur kurz Ende der 1990er beim Schreiben von XiRCON-IRC-Skripten benutzt, aber es war eine elegante Sprache: einfach, leicht zu lernen und flexibel genug, um sie Lisp für Menschen zu nennen
Ich wünschte, sie wäre populärer gewesen, und freue mich, dass sie immer noch lebt und aktiv ist
Allerdings war meine andere Hauptsprache damals x86-Assembly, daher lag die Messlatte für Begeisterung vielleicht niedrig
Der Autor von Tcl und Tk ist Professor John Ousterhout, und sein Buch über Softwaredesign ist inzwischen in der 2. Auflage erschienen
A Philosophy of Software Design:
https://web.stanford.edu/~ouster/cgi-bin/book.php
Ich bin jetzt bei Kapitel 11, „Design it Twice“, also werde ich es nach dem Durchlesen vermutlich von oben bis unten komplett neu schreiben. Aktuell ist es ein Modell, bei dem nur die Variablen in einem minimalen Python-Kern liegen und der Rest in OpenSCAD ist; in der neuen Implementierung will ich alles, was möglich ist, in Python unterbringen und über OpenPythonSCAD https://pythonscad.org/ verwenden
Die Sprache mag ich wirklich, aber heutzutage nutze ich sie kaum noch. Ich frage mich, ob sie unter Linux immer noch GUIs im Stil von 1995 erzeugt
Wenn es nur halbwegs vernünftige Linux-GUI-Unterstützung auf dem Niveau gegeben hätte, das auf anderen Plattformen schon lange möglich war, würde ich sie wahrscheinlich heute noch verwenden
Die Screenshots der Kern-Themes beziehen sich allerdings auf 8.5/8.6, und besonders das Standard-Theme hat sich in Tk 9 etwas geändert. Der Haken ist, dass die Theme-Engine eigene neue Widgets verwendet; damit eine Anwendung ein Theme bekommt, muss sie also die neue API nutzen. Code von 1995 oder 2005 ergibt weiterhin eine GUI im Stil von 1995
Die Dokumentation war viel zu lange auf Tk(inter) zentriert, sodass die meisten es wohl wie den Standard wählen. Die GUI-Unterstützung in Python ist besser geworden, aber wahrscheinlich hat die Beliebtheit durch Machine Learning/AI dabei eine Rolle gespielt. Tcl ist weniger populär, daher muss man genauer suchen, um Dokumentation zur Nutzung moderner GUIs zu finden
In letzter Zeit hatte ich mit Tcl nur bei Arbeiten an MacPorts-Portfiles zu tun.
Falls es heutzutage jemand für andere Zwecke nutzt, würde mich interessieren, warum. Ich mag die Sprache nicht nicht, aber sie ist mir auch nicht ans Herz gewachsen.
Erfahrene Tcl-Programmierer können damit zaubern. Von 2005 bis 2015 habe ich fast ausschließlich in Tcl/Tk programmiert und es wirklich gemocht. Seitdem nutze ich es eher für kleine Skripte als zum Schreiben von Apps, aber wenn ich Automatisierungsskripte auf Betriebssystemebene schreiben muss, ist es immer noch meine erste Wahl.
Ich nutze es täglich, weil es eine gute Balance zwischen Lisp-artigen Eigenschaften und der Schlichtheit einer Skriptsprache bietet und weil das C-Interface hervorragend ist. Die REPL ist ebenfalls ordentlich, und man kann Erweiterungen in C schreiben und sie zu 100 % wie erstklassiges Tcl darauf aufbauen. Das liegt zu einem großen Teil, vielleicht sogar vollständig, daran, dass Tcl eine sehr einfache Sprache[4] ist und Homoikonizität[5] besitzt. Es macht Spaß, damit zu entwickeln und es zu verwenden.
[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...
Der Vorteil ist, dass man EDA-Tools wie Shell-Skript-Befehle der Form
run_my_task -option_a -option_Bsteuern kann. Wenn man keine Chips entwirft, gibt es keinen Grund, es zu verwenden, und die Sprache selbst ist schrecklich. Je schneller die EDA-Branche TCL aufgibt, desto besser.Und diese Testsuite macht SQLite zu der verlässlichen Engine, die es heute ist. Die Testsuite wurde kontinuierlich gepflegt, während die Engine ganz oder teilweise neu geschrieben wurde.
Ich habe eine Backup-App für eine Online-Verkaufsanwendung gebaut, eine App zum Reparieren fehlerhafter POS-Dateien einer großen Handelskette, eine kleine App, die Forms/Reports auf einen Server kopiert, die Kompilierung ausführt und die neuen Dateien in git schiebt, sowie einen
gs-Wrapper, mit dem die Medienabteilung mehrere PDFs leichter zu einer Datei zusammenführen konnte. Alle bestanden jeweils nur aus etwa ein bis zwei Seiten Code.Wichtiger als Python 3.13.
Bravo !!!!
Ich warte darauf, dass Scilab und Python mit Tcl/Tk 9.0 ausgeliefert werden. Das aktuelle Release von Next Scripting scheint für 9.0 bereit zu sein. Es lohnt sich, die Abschnitte Undroidwish und Binary Releases auf der offiziellen Seite im Auge zu behalten.