1 puan yazan GN⁺ 2024-09-27 | 1 yorum | WhatsApp'ta paylaş
  • Tcl/Tk 9.0, Tcl ve Tk’nin en yeni büyük sürümü; yeni özelliklerin yanı sıra Tcl/Tk 8’e göre bazı uyumsuzluklar da getiriyor
  • En güncel sürüm gösterimi Tcl/Tk 9.0.4 ve tarihi 26 Haziran 2026
  • Tcl, 2 GB’ı aşan veri değerlerini işleyebilen 64-bit capacity sunuyor; dizeler kullanılabilir bellek sınırları içinde keyfi uzunlukta olabiliyor, listeler ve sözlükler çok sayıda öğe içerebiliyor
  • Metin işleme; tüm Unicode kod noktası aralığını, utf-16·utf-32·ucs-2 aileleri ve CESU-8 gibi yeni kodlamaları, I/O kodlamasını denetleyen encoding profiles özelliğini ve source için varsayılan -encoding utf-8 seçeneğini sunuyor
  • Tcl, zipfs ile zip dosyalarını dosya sistemi gibi bağlayabiliyor; çalıştırılabilir dosyalara veya kütüphanelere eklenen dosya sistemi arşivleriyle starkit tarzı uygulama dağıtımını destekliyor
  • Unix olay işleme motoru, kullanılabiliyorsa epoll veya kqueue tabanlı yapılandırılıyor; bu sistem çağrılarının bulunmadığı platformlarda select tabanlı uygulama korunuyor
  • Tcl 9.0’daki başlıca uyumsuzluklar arasında nitelendirilmemiş değişken adlarının global yerine mevcut namespace içinde çözümlenmesi, I/O malencoding için varsayılan yanıtın hata (-profile strict) olarak değişmesi, yollardaki ~ karakterinin ana dizin olarak yorumlanmaması ve $::tcl_precision değerinin double türünden dize üretimini denetlemek için artık kullanılmaması yer alıyor
  • Derleme ve platform değişiklikleri kapsamında --disable-threads derleme seçeneği kaldırıldı; artık her zaman thread-enabled durumda. Windows için Windows 7 veya Windows Server 2008 R2 ve üzeri gerekiyor
  • Tcl C uzantılarında Tcl 8.6 veya altını hedefleyerek derlenmiş ikili dosyalar Tcl 9.0’da çalışmıyor; Tcl 9.0 için ABI uyumluluğu bir hedef değildi ve çoğu durumda kaldırılmış API işlevleri kullanılmıyorsa Tcl 9.0 hedeflenerek yeniden derleme yapılabiliyor
  • C açık arayüzünde birçok argüman int’ten Tcl_Size’a genişletildi; Tcl_ChannelTypeVersion 5 altı desteği sonlandırıldı, Tcl_ObjType yapısı için sürüm yönetimi getirildi, CONST* makroları ve çeşitli API işlevleri kaldırıldı
  • Tk 9.0.0 Tcl 8.6’yı desteklemiyor; Tk 9.0.0 kullanmak için önce Tcl 9.0.0 gerekiyor
  • Tk, işletim sistemi bildirim, çıktı ve tepsi özelliklerine erişim için tk sysnotify, tk print, tk systray sunuyor
  • Tk görüntüleri kısmi SVG desteği, photo image metadata okuma-yazma ve alpha channel erişimi sağlıyor
  • Tk’nin yerleşik widget’ları ve temaları scaling-aware hale geldi; uygun ortamlarda iki parmak hareketi desteği iyileştirildi ve tk windowingsystem içindeki “aqua” için macOS 10.10 veya üzeri gerekiyor
  • Tcl 9 geçiş belgeleri olarak Migrating C extensions to Tcl 9 ve Migrating scripts to Tcl 9 sunuluyor

1 yorum

 
GN⁺ 2024-09-27
Hacker News yorumları
  • 27 yılın ardından gelen ilk major sürüm. İç yapısı 64 bit olduğu için veriler çok büyüyebiliyor; güncel emojiler dahil tüm Unicode, Zip dosya sistemi gibi pek çok yeni özellik var.
    Eski kalıntıların bir kısmı da kaldırılmış, bu yüzden bazı programların güncellenmesi gerekebilir; yine de uyumluluğu hâlâ yüksek sayılır. Yukarıdaki sayfada, dahil edilen/çıkarılan özelliklerin ayrıntılandırıldığı sürüm notlarına bağlantı veriliyor.

    • Zip dosya sistemi değişikliği gerçekten sevindirici. Eskiden bağımsız çalıştırılabilir uygulamalar oluştururken topluluğun belirli araçlar ve püf noktalarıyla kullandığı çeşitli teknikleri, standart yöntemin temel araç setine eklemişler gibi; harika bir değişiklik.
    • Home dizinine gitmek için kullanışlı bir kısayol gösterimi olan tilde ~ neden kaldırıldı, merak ediyorum.
  • Dil saflığı savunucuları ve 1990’lar tarzı nesne yönelimli saflık savunucuları Tcl’den gerçekten nefret eder, ama ekosistemde kendine özgü bir tasarım felsefesi var.
    Her şey ya string ya da komut; nesne yönelimli eklentiler biraz sonradan eklenmiş gibi duruyor. Ama tkinter gibi Python üzerinden Tcl kullanmak yerine saf Tcl/Tk ile GUI yapmayı denerseniz, SQLite arayüzünü kullanırsanız, küçük bir C eklentisi yazarsanız ya da bir kütüphaneyi sarmalarsanız birçok şeyin sorunsuzca çalıştığını görürsünüz.

    • antirez’in Tcl yazısında [1] ilginç bir bakış açısı görmüştüm. Yanlış hatırlamıyorsam Redis test betikleri için Tcl kullanıyor.
      https://folk.computer belgelerinden bağlantıyı takip ederek bakmıştım; bu proje de betik dili olarak Tcl kullanıyor. Böyle bir kullanım için Tcl’den özellikle nefret etmeye pek neden olmayabilir.
      [1] http://antirez.com/articoli/tclmisunderstood.html
    • Tcl sayesinde startup’ımız mümkün oldu ve o dönemde edindiğimiz deneyim ile öğrendiklerimiz OutSystems’in çıkış noktası haline geldi.
      Bunlardan biri, eksiksiz bir web sunucusunda JIT derleyicisi olmayan dinamik bir dili bir daha asla kullanmak istemediğimdi. Dilin kendisi harika, ama performans sorunları yüzünden Tcl kütüphanelerini düzenli olarak C ile yeniden yazmak pek hoş değildi.
    • “Her şey ya string ya da komut” sözü abartı değil. Gerçekten her şey komut; buradaki yorum satırı yazma biçimi “bunu neden böyle yapmışlar ki” dedirtecek düzeyde: https://wiki.tcl-lang.org/page/comment
      Yorum yazmadan önce komutu ; ile bitirmeniz gerekiyor; süslü parantezlerin eşleşmemesi kabul edilmiyor, yani hatalı kodu yorum satırına almaya çalışmamalısınız; ayrıca yorumun içine ters eğik çizgi de koyamazsınız. Gerçi bunu da bir özellik olarak açıklıyorlar, çünkü wish çalıştırılırken aşağıdaki gibi yazılıyor:
      #!/bin/sh
      # the next line restarts using wish \
      exec wish8.0 "$0" "$@"
      Ters eğik çizgi shell tarafından yok sayılıyor, ama wish içinde parse ediliyor.
    • Citus’un TPC benchmark çalışmaları sırasında Tcl ile epey uğraştım.
      https://github.com/TPC-Council/HammerDB/blob/master/src/post...
      Tcl, shell betik dili olarak fena sayılmaz.
  • Tcl’in merkezi olay işleme motorunun, mümkün olduğunda epoll veya kqueue üzerine kurulması ve desteklenmeyen platformlarda select tabanlı uygulamanın kalması devasa bir değişiklik.
    Tcl’in eşzamanlılığının eski ve düşük performanslı görülmesinin büyük nedeni, epoll ve kqueue en az 10 yıldır mümkün olmasına rağmen selecte bağımlı olmasıydı. Tcl, başlaması kolay ve metaprogramlama yapması da kolay olduğu için sevdiğim dillerden biri.

    • Tcl’in düşük performanslı görülmesinin başlıca nedeni, temel işlemlerinin CPython’dan kabaca iki kat yavaş olması. CPython da hızlı sayılmaz: https://news.ycombinator.com/item?id=41637953
      Bir başka neden de hızlı Tcl’i nasıl yazacağımızı pek bilmememiz; o thread’de ben bunu istemeden göstermiş oldum.
  • NaviServer’ı [0] tavsiye etmek isterim. Eski adı AOLServer [1] idi; sahada uzun süre sınanmış, kurşun geçirmez denebilecek bir web sunucusu.
    Bir zamanlar AOL’u çalıştırmak için kullanılmış bir şeyse daha fazla söze gerek yok. OpenACS [2] ana projelerden biri ve 1997’den beri var; özellikle Tcl ile birlikte kullanıldığında çok güçlü. Hâlâ bakımı yapılıyor ve artık Tcl 9’u da destekliyor.
    JavaScript, Tcl, NaviServer kombinasyonuna DNS Server, LDAP, Mail gibi kendi modüllerini de ekleyince güçlü bir araç ortaya çıkıyor. Tcl ve web geliştirmeye başlamak istiyorsanız, ikisini birlikte denemenizi öneririm; kolayca eğlenceli sonuçlar çıkarabilirsiniz.
    [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’ların ortasında Tcl ve SQL öğrendiğim nostaljik stack. O zaman OpenACS değil, ArsDigita Community System’in kendisiyle oynuyordum; ArsDigita’nın gerçekten var olduğu dönemdi.
      Pasadena, CA’da mı yoksa Glendale’de mi olduğunu hatırlamadığım ofislerinde, ArsDigita’nın sponsor olduğu ve bizzat ders verdiği ücretsiz derslere katıldığımı da hatırlıyorum. Çok derin ya da uzun değildi ama giriş için iyiydi.
  • Tcl ile ilk kez tanışanlar için, JavaScript yerine tarayıcı dili olarak Tcl’in kullanıldığı alternatif bir evren de olabilirdi
    “İlginç bir dipnot: Netscape’in kuruluşu, 1994’te Berkeley’den ayrılıp sektörde nereye gideceğime karar verdiğim dönemle çakıştı. Jim Clarke ve Marc Andreessen, Netscape kurucularından biri olarak katılma olasılığımı yokladılar, ama sonunda reddettim. Onlarla konuştuğum sırada web ile ilgili işler yapmaya karar vermiş bile değildim. Bu, kariyerimdeki en büyük ‘ya öyle olsaydı’lardan biri. Netscape’e gitseydim, Tcl’in JavaScript yerine tarayıcı dili olma ihtimali oldukça yüksekti ve dünya farklı olurdu! Ancak geriye dönüp bakınca Tcl’in web için gerçekten JavaScript’ten daha iyi bir dil olup olmayacağından emin değilim; dolayısıyla belki de doğru olan yaşanmıştır.”
    Kaynak: https://pldb.io/blog/JohnOusterhout.html

    • Öyle de olabilir. JavaScript’in yerleşmesinin başlıca nedenlerinden birinin, büyük bir tarihsel yükü olmaması sayesinde tasarımcıların onu ihtiyaç duydukları yöne götürebilmesi olduğunu düşünüyorum
      Birkaç kişiden fazla kullanılan her dil, ne kadar iyi olursa olsun bir tür yük edinir. Bu yüzden o alternatif evrende tarayıcı betik dili ekosistemi çok daha parçalı hale gelmiş olabilirdi
    • Web için Tcl’in güvenli alt kümesi üzerinde yapılan çalışmalar, bugün bile güvenilmeyen betikleri yönetmesi kolay bir sandbox içinde çalıştırmak için kullanılabilir
      İstenirse, yeterince komut kaldırılarak dil Turing-tam olmayacak hale bile getirilebilir
    • İlginçtir, Tcl tarayıcı eklentisi en azından 1996’dan beri vardı
      https://sunsite.icm.edu.pl/pub/programming/tcl/plugin/
      Hatta daha önce, öğrenci arkadaşlarımın bilgisayar laboratuvarına gelip “Bak, artık Mosaic için TK eklentisi de var!” dediklerini hatırlıyorum. “Fareli gopher gibi!” denilen dönem değildi, ama üzerinden de çok zaman geçmemişti
      Ancak Tcl eklentisini kullanmak için bir şeyleri kendiniz yapmanız gerekiyordu; JavaScript ise bir kez geldikten sonra varsayılan olarak sunuldu
    • Böyle bir şey olmuş olsaydı bile dünyanın TCL’de kalmaya devam edeceğini sanmıyorum. JavaScript, insanların katlanabileceği kadar iyiydi; TCL ise kesinlikle öyle değil
      Muhtemelen TCL ile başka bir şey bir süre birlikte olurdu ve TCL’in kullanım dışı bırakılması daha olasıydı
    • “Belki de doğru olan yaşanmıştır” sözüne tamamen katılıyorum
      Her yerde set x [ expr $y + $z ] gibi kodlar görmek istemezdim. Komut dili olarak o kadar da kötü değil gerçi
  • Tcl’i gerçekten sevdiğimi söylemek abartı olmaz. 1990’ların sonlarında XiRCON IRC betikleri yazarken kısa süreliğine kullanmıştım; ama insanlar için Lisp denebilecek kadar basit, öğrenmesi kolay ve esnek, zarif bir dildi
    Daha popüler olmasını isterdim; hâlâ canlı kaldığını görmek sevindirici

    • Tcl ile temasım IRC bot betikleri yazmaktan ibaretti, ama o deneyime dair yalnızca iyi anılarım var
    • 90’larda IRC istemcisi için TCL betikleri yazmıştım ve gerçekten harikaydı. O kullanım için dil mükemmeldi
      Gerçi o dönemdeki diğer ana dilim x86 assembly olduğu için, etkilenme çıtam düşük olmuş olabilir
    • “İnsanlar için Lisp” demek için ortada upvar var
  • Tcl ve Tk’nin yazarı Prof. John Ousterhout; yazılım tasarımı kitabının da 2. baskısı çıktı
    A Philosophy of Software Design:
    https://web.stanford.edu/~ouster/cgi-bin/book.php

    • Bu gerçekten harika bir kitap ve şu anda okuyorum. Her bölümü okuyup mümkün olduğunca derin düşünüyor, sonra da derslerini uygulayarak mevcut projemi yeniden yazıyorum
      Şu anda 11. bölüm “Design it Twice”tayım; muhtemelen bitirdikten sonra baştan sona tamamen yeniden yazacağım. Mevcut modelde yalnızca değişkenler minimal Python çekirdeğinde, geri kalanı OpenSCAD’de; yeni uygulamada ise mümkün olan her şeyi Python’da tutup OpenPythonSCAD https://pythonscad.org/ üzerinden kullanmayı planlıyorum
  • Dili gerçekten seviyorum ama bugünlerde pek kullanmıyorum. Linux’ta hâlâ 1995 tarzı GUI üretip üretmediğini merak ediyorum
    Diğer platformlarda uzun zamandır mümkün olan düzeyde, şöyle böyle makul Linux GUI desteği olsaydı muhtemelen hâlâ kullanıyor olurdum

    • Tema motoru yaklaşık 15 yıl önce zaten eklenmişti. Varsayılan tema epey eski görünüyor ama başka birçok tema da var: https://wiki.tcl-lang.org/page/List+of+ttk+Themes
      Ancak çekirdek tema ekran görüntüleri 8.5/8.6’ya ait; özellikle varsayılan tema Tk 9’da biraz değişti. İşin püf noktası, tema motorunun kendi yeni widget’larını kullanması; bu yüzden uygulamanın temadan yararlanabilmesi için yeni API’yi kullanması gerekiyor. 1995 ya da 2005 koduysa hâlâ 1995 tarzı GUI üretir
    • Python öğrenirken Tkinter kullandığımı hatırlıyorum. Başka GUI’ler de var ama modern GUI gibi çalışan örnekler bulmak daha zahmetli
      Dokümantasyon çok uzun süre Tk(inter) merkezli kaldığı için çoğu kişi bunu varsayılan seçenek gibi seçiyor sanırım. Python’un GUI desteği iyileşti, ama bunda muhtemelen makine öğrenmesi/yapay zeka kullanımındaki popülerliğin etkisi oldu. Tcl daha az popüler olduğu için modern GUI kullanımına dair doküman bulmak istiyorsanız daha dikkatli araştırmanız gerekiyor
  • Son zamanlarda Tcl ile uğraştığım tek şey MacPorts portfile çalışması kadardı
    Bugünlerde başka amaçlarla kullanan biri varsa neden kullandığını merak ediyorum. Dilden nefret etmiyorum ama sevmeye de başlamadım

    • Tcl’in C programcıları için Lisp’e daha yakın olduğunu düşünüyorum. Lisp’ten gelen metaprogramlama gücünü; C gibi görünen, C ile iyi anlaşan, genel kabuk dillerinden çok daha sezgisel olan ve çapraz platform GUI’si de bulunan bir dil olarak sunuyor
      Deneyimli bir Tcl programcısı sihir yapabilir. 2005’ten 2015’e kadar neredeyse tamamen Tcl/Tk ile programlama yaptım ve gerçekten sevdim. Ondan sonra uygulama yazmaktan çok hafif betikler için kullandım, ama işletim sistemi düzeyinde otomasyon betikleri yazmam gerektiğinde hâlâ ilk tercihim
    • Standart kullanım alanları F5 ağ cihazları ve A10 cihazlarındaki BigIP iRules[0], Argonne National Labs süper bilgisayarlarının orkestrasyonu[1], Tealeaf[2], Python Tkinter[3] vb.
      Her gün kullanmamın nedeni, Lisp benzeri yönleriyle basit bir betik dili oluşu arasında iyi bir denge kurması ve C arayüzünün harika olması. REPL’i de fena değil; C ile uzantılar yazıp bunları %100 birinci sınıf Tcl gibi üst üste inşa edebiliyorsunuz. Bu, büyük ölçüde, hatta belki tamamen, Tcl’in çok basit bir dil[4] olmasından ve homoiconicity[5] özelliğine sahip olmasından kaynaklanıyor. Geliştirmesi ve kullanması keyifli
      [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 sektörünün betik dilidir. Bilgisayar çipi tasarlıyorsanız TCL kullanıyorsunuz demektir. Cadence ve Synopsys 30 yılı aşkın süredir TCL’i standart olarak benimsiyor
      Avantajı, EDA araçlarını run_my_task -option_a -option_B gibi kabuk betiği komutlarıymış gibi yönetebilmeniz. Çip tasarlamıyorsanız kullanmanız için bir neden yok; dilin kendisi ise berbat. EDA sektörü TCL’i ne kadar çabuk terk ederse o kadar iyi
    • SQLite’ın yaratıcısı Richard Hipp, SQLite’ın Tcl ile yazıldığını söylüyor. Veritabanı motorunun kendisi elbette C ile yazılmış, ama çok daha büyük olan test paketi çoğunlukla Tcl ile yazılmış
      Ve SQLite’ı bugün olduğu kadar güvenilir bir motor yapan da bu test paketi. Test paketi sürekli korundu; motor ise tamamen ya da kısmen yeniden yazılageldi
    • Freewrap yüzünden birkaç kez Tcl kullandım. Çok az kodla GUI’li Windows uygulamaları yapıp bunları çalıştırılabilir dosya olarak kolayca dağıtabiliyordum
      Bir çevrimiçi satış uygulaması için yedekleme uygulaması, büyük bir perakende zincirinin hatalı POS dosyalarını düzelten bir uygulama, Forms/Reports’u sunucuya kopyalayıp derlemeyi çalıştıran ve ardından yeni dosyaları git’e iten küçük bir uygulama, medya departmanının birden çok PDF’i tek dosyada birleştirmesini kolaylaştıran bir gs sarmalayıcısı yaptım. Hepsi de bir iki sayfalık koddu
  • Python 3.13’ten daha önemli
    Bravo !!!!
    Scilab ve Python’ın Tcl/Tk 9.0’ı içerecek şekilde dağıtılmasını bekliyorum. Next Scripting’in son sürümü 9.0’a hazır gibi görünüyor. Resmî sayfadaki Undroidwish ve Binary Releases bölümlerini takip etmeye değer