Если, например, архитектура определяется кодом на питоне, но некоторые модули реализованы на C — можно сказать, что приложение на питоне. Если архитектура определяется ядром на C, которое можно скриптовать на питоне — можно сказать, что приложение на C.

Связывание компонентов - хорошая задача для скриптового языка. И если он связывает компоненты на С, то архитектура определяется скриптовым языком, и получается, приложение целиком на скриптовом языке написано?

Для меня граница такая: если код, написаный на скриптовом языке, нужно проектировать (то есть разбивать на компоненты с продуманным API), то я не буду использовать Tcl. Если компоненты и API уже предоставляются скрипту движком или протоколом, а на скриптовом языке нужно писать только «glue code», то тут Tcl хорош.

А под glue code понимается клепание формочек? Ибо сложно представить себе хороший GUI без API, особенно в стиле MVC.

Ну я спросил чего не хватает вам, а пример привел чего не хватает лично мне.

Я об этом писал: документация и компоненты, как качество, так и количество.

Связывание компонентов - хорошая задача для скриптового языка. И если он связывает компоненты на С, то архитектура определяется скриптовым языком, и получается, приложение целиком на скриптовом языке написано?

Под «glue code» я имел в виду простой код, который реализует конкретные сценарии использования общих механизмов, предоставляемых движком. Компоненты на C при этом определяют архитектуру.

У Реймонда хорошо написано:

The Art of Unix Programming

One of the lessons Unix programmers have learned over decades is that glue is nasty stuff and that it is vitally important to keep glue layers as thin as possible. Glue should stick things together, but should not be used to hide cracks and unevenness in the layers.

По-моему эту задачу Tcl решает отлично.

А под glue code понимается клепание формочек? Ибо сложно представить себе хороший GUI без API, особенно в стиле MVC.

Если gui простой, то с использованием Tk и код остается очень лаконичным и прозрачным. Если gui сам по себе сложный и его реализация требует грамотного проектирования, то это уже будет не «glue», а отдельная задача, которую нужно решать.

На Tcl/Tk у меня нет опыта создания сложных gui, так что ничего не могу сказать. Мне нраится использовать Tk для простых утилит, которые напрямую отображают примитивы, предоставляющиеся скрипту нижним уровнем.

Под «glue code» я имел в виду простой код, который реализует конкретные сценарии использования общих механизмов, предоставляемых движком.

Так это скриптование движка, а не glue code.

У Реймонда хорошо написано:

Зачем вы привели английский вариант, да ещё и вырвали его из контекста? Ибо сразу и не понятно, что Реймонд писал про glue layers, а не glue code.

Если gui сам по себе сложный и его реализация требует грамотного проектирования, то это уже будет не «glue»

Если сложный GUI писать как монолит, то да, не glue.

Мне нраится использовать Tk для простых утилит, которые напрямую отображают примитивы, предоставляющиеся скрипту нижним уровнем.

Ну то есть формочки клепать. Которые, по сути, много хуже хорошего текстового редактора и не являются gui.

надо «man 3tcl somefunc» (это если деб/убунта и иже с ними) или «man n tcl» (для прочих). незнаю, можно ли сравнивать с питоном, но маны tcl исчерпывающе полны.

нет такого..[skip/]

на самом деле

$ locate man | grep tcl | wc -l
1041

Все-таки добавлены try и throw.

Не прошло и ста лет.

Так это скриптование движка, а не glue code.

Да, извините, все в кучу свалил. Отдельно — скриптование движка, отдельно — клей между примитивами движка и примитивами Tk.

Зачем вы привели английский вариант, да ещё и вырвали его из контекста?

Непонятно объяснил. Хотел сказать о том, что здорово, если требования позволяют писать простой gui, и в таком случае Tcl хорош как тонкая прослойка между движком и Tk.

Реймонд писал про glue layers, а не glue code

В чем между ними разница?

Ну то есть формочки клепать. Которые, по сути, много хуже хорошего текстового редактора и не являются gui.

Если есть движок, который можно скриптовать, но для некоторых сценариев удобнее использовать интерактивный софт, а не скрипты, то почему бы для таких сценариев не написать отдельные утилиты? Например, git как движок и gitk как утилита для визуализации графа коммитов. Или визуализация какого-нибудь протокола. Или интерактивное управление объектами движка: выбрать объект, посмотреть на его свойства, послать команду.

Можно примеры формочек и примеры хорошего gui?

нет такого, есть только

root@localhost # locate man | grep tcl
/usr/lib/tcl8.5/encoding/macRomania.enc

«уж сколько раз твердили миру» (c) г-н Крылов

Хотя безполезно..root@localhost так и остаётся

Отдельно — скриптование движка, отдельно — клей между примитивами движка и примитивами Tk.

Во втором случае язык связывает компоненты на С, то архитектура определяется скриптовым языком, и получается, приложение целиком на скриптовом языке написано?

В чем между ними разница?

А почитайте книжку дальше. Там и пример, и не один, и объяснения. В рассмотренном там примере, кстати, скриптовые языки не применяются, AFAIK.

Например, git как движок и gitk как утилита для визуализации графа коммитов. Или визуализация какого-нибудь протокола.

Визуализация - это уже не формочки. Здесь canvas нужен. Если только нужна визуализация, а не попытки использовать tree или listbox, особенно не по назначению.

Можно примеры формочек

tkcon

примеры хорошего gui?

Компьютерные игры.

На моем недобуке циклик на 10000000 итераций Tcl кушает 8 метров памяти и выполняется за 3,2 секунды, тот же циклик на Python кушает 160 метров и 7 секунд. Так что ботов я буду писать на вкусном, экономном и быстром Tcl, а не на жирном и медленном Python.

Только упоротый аноним будет мериться своей малюсенькой писькой, используя для этого пустые циклы :D

А тикль сейчас вообще для чего используется? Какова его ниша?

Простые (в смысле, что их просто делать) графические интерфейсы, хотя одно время он активно вытеснялся из этой ниши всякими gtk.

Ты путаешь тикль (язык Tcl) и Tk - графический тулкит, который используют и в питоне, в частности.

elisp ?)

Во втором случае язык связывает компоненты на С, то архитектура определяется скриптовым языком, и получается, приложение целиком на скриптовом языке написано?

Не обязательно же говорить «целиком написано на xyz». И чем определяется архитектура бывает по-разному.

Один пример — git, движок, состоящий из компонентов на C, и gitk, который связывает эти компоненты. Gitk новых абстракций не вводит, архитектура определяется движком. Другой пример — deluge, который написан на python, но использует модули, написанные на C (libtorrent). Deluge не просто обертка над libtorrent, он вводит много своих абстракций, которыми определяется его архитектура.

А почитайте книжку дальше. Там и пример, и не один, и объяснения.

Я не вижу в книге, чтобы вводились различные термины «glue code» и «glue layer». Что вы имеете в виду? Я понимаю, что скриптование движка это не обязательно «glue code» — уже написал. Но может им быть, если скрипт является прослойкой.

В рассмотренном там примере, кстати, скриптовые языки не применяются, AFAIK.

Да, там про браузер, но тоже про прослойку между движком (парсер DOM) и GUI.

Визуализация - это уже не формочки. Здесь canvas нужен. Если только нужна визуализация, а не попытки использовать tree или listbox, особенно не по назначению.

Смотря какая, в wireshark, например, разве используется canvas?

Компьютерные игры.

Это думаю слишком далекая от ниши Tcl/Tk область, если вы имеете в виду графику на OpenGL или чем-то подобном.

Нет не путаю, потому что они неразрывно связаны. Вы видели как организован Tkinter?

В чем между ними разница?

А почитайте книжку дальше. Там и пример, и не один, и объяснения.

А, вы может быть под «glue code» понимаете код, который реализует логику поверх готовых компонентов, а под «glue layer» прослойку между уровнями абстракции?

Если так, то в этой терминологии я говорил о Tcl как об инструменте, который позволяет «glue layer» между движком и gui быть простым и тонким. Ну а код, который управляет кучей компонентов и реализует логику — вот его я бы не стал писать на тикле, если эта логика развесистая.

Gitk новых абстракций не вводит, архитектура определяется движком.

Это просто GUI.

Deluge не просто обертка над libtorrent, он вводит много своих абстракций, которыми определяется его архитектура.

Вопрос в том, являются ли эти абстракции логикой или алгоритмами. Скажем, в ctext реализован алгоритм анализа текста с помощью регекспов вместо использования чего-то на С. Вот я и спрашиваю: можно ли считать громоздкую логику на tcl реализацией на скриптовом языке?

Я не вижу в книге, чтобы вводились различные термины «glue code» и «glue layer»

Вы почитайте, что имеется ввиду под glue layer и изучите пример с веб-браузером.

Я понимаю, что скриптование движка это не обязательно «glue code» — уже написал.

Скриптование движка - это не glue code. Ибо склеивать там нечего - чистая логика. Glue code - это связывание как минимум двух компонентов из библиотек или консольных утилит.

Да, там про браузер, но тоже про прослойку между движком (парсер DOM) и GUI.

Читайте внимательнее. Работа с синтаксисом включено в прослойку. Парсер не пишут на скриптовых языках.

Смотря какая, в wireshark, например, разве используется canvas?

А разве там есть визуализация? Уберите текст и что останется?

Это думаю слишком далекая от ниши Tcl/Tk область, если вы имеете в виду графику на OpenGL или чем-то подобном.

Игры - это не OpenGL. Игры - это представление информации в графическом виде. Уберите текст из игр, и интерфейс почти ничего не потеряет, особенно для опытного пользователя. Уберите текст из формочек, и ничего не будет понятно.

А, вы может быть под «glue code» понимаете код, который реализует логику поверх готовых компонентов, а под «glue layer» прослойку между уровнями абстракции?

Да это не я понимаю, а Реймонд. :)

Если так, то в этой терминологии я говорил о Tcl как об инструменте, который позволяет «glue layer» между движком и gui быть простым и тонким.

Скриптовые языки не для этого предназначены. Они как раз-таки для верхнего уровня, для создания интерфейса, а не для прослойки между GUI и движком.

Ну а код, который управляет кучей компонентов и реализует логику — вот его я бы не стал писать на тикле, если эта логика развесистая.

А тикль как раз для этого и создавался. И скриптовые языки вообще. :)

Нет не путаю, потому что

Именно путаешь, т.к. под тикль можно использовать тот же wxTcl, а не Tk. И вопрос был про тикль, а не про Tk.

Как у этой поделки с уникодом?

ИРЛ тоже можно ходить на руках, но если меня спросят для какой физической деятельности предназначен человек, я в первую очередь скажу, что он умеет ходить ногами.

Вы почитайте, что имеется ввиду под glue layer и изучите пример с веб-браузером.

Работа с синтаксисом включено в прослойку. Парсер не пишут на скриптовых языках.

В том примере прослойкой является отображение DOM (который был до этого получен из HTML) в набор примитивов GUI, разве не так?

Вопрос в том, являются ли эти абстракции логикой или алгоритмами. Скажем, в ctext реализован алгоритм анализа текста с помощью регекспов вместо использования чего-то на С. Вот я и спрашиваю: можно ли считать громоздкую логику на tcl реализацией на скриптовом языке?

Думаю ctext на грани сложности того, что стоит писать на tcl, по крайней мере без ООП. Более продвинутый stext написан уже на C. Если скриптовая часть такая громоздкая, это признак того, что примитивы движка не достаточно высокоуровневые для решаемой задачи.

А разве там есть визуализация? Уберите текст и что останется?

Понятно, я просто не имел в виду чисто графическое представление.

А, вы может быть под «glue code» понимаете код, который реализует логику поверх готовых компонентов, а под «glue layer» прослойку между уровнями абстракции?

Да это не я понимаю, а Реймонд. :)

Да где у Реймонда «glue code» вообще?!

Скриптовые языки не для этого предназначены. Они как раз-таки для верхнего уровня, для создания интерфейса, а не для прослойки между GUI и движком.

Пример

Есть библиотека, которая работает с неким устройством. Она позволяет записать в устройство настройки, прочитать настройки обратно и после записи настроек запустить на устройстве одну из нескольких возможных операций. Нужно сделать gui для редактирования этих настроек и запуска операций, которым сможет пользоваться инженер для тестирования устройства.

Библиотека предоставляет набор примитивов для работы с устройством. Тулкит предоставляет набор графических примитивов. Дополнительной логики между ними почти нет, но нужна прослойка, преобразующая настройки и операции в поля и кнопки, а нажатия кнопок в посылку настроек и запуск операций.

Если тулкит — Tk, то такая прослойка очень хорошо пишется на Tcl :) Это тот «glue layer» между движком и gui, который я имел в виду. Может быть, не к месту этот термин употребил, но суть я описал.

Другой пример

Есть библиотека, которая работает с кучей устройств: сервоприводами и датчиками. Она предоставляет набор примитивов для посылки команды в какое-нибудь устройство. На скриптовом языке можно реализовывать различные комбинации использования этих устройств: позиционировать сервоприводы и снимать данные с датчиков в разном порядке.

Это уже ни фига не «glue», а логика приложения, согласен. Если все сценарии будут простые, например:

for {set lpos 0} {$lpos < 10} {incr lpos} {
  linear_module move-to $lpos
  for {set rpos 0} {$rpos < 10} {incr rpos} {
    rotator move-to $rpos
    if {[detector detect-something]} {
       puts "something detected!"
    }
  }
}

то тикль крут. А если логика навороченная, или еще есть сложный gui, в котором свои абстракции, куча окон и т.п., тогда уж лучше питон.

Более продвинутый stext написан уже на C.

IIRC, даже так: низкоуровневая часть stext на C, высокоуровневая на Tcl.

В квотезы!

Как у этой поделки с уникодом?

Издеваешься? Один из первых языков с поддержкой юникода. Все строки внутри хранятся в юникоде.

В том примере прослойкой является отображение DOM (который был до этого получен из HTML) в набор примитивов GUI, разве не так?

Реймонд пишет, что нет.

Более продвинутый stext написан уже на C.

Мельком взглянул на него. Там у него данные по языкам в C зашиты. И вроде как все компоненты, из которых он состоит, на С также писаны. То есть логика в С. Плохо.

Понятно, я просто не имел в виду чисто графическое представление.

Визуализация не обязана быть чисто графической. Но и стандартными виджетами её не сделаешь - нужен холст. А у Tk-холста возможностей очень мало, да и слишком он, general, что ли. То есть, частные возможности нужно вручную делать.

Да где у Реймонда «glue code» вообще?!

У Реймонда есть glue logic в 14.3

Библиотека предоставляет набор примитивов для работы с устройством. Тулкит предоставляет набор графических примитивов. Дополнительной логики между ними почти нет, но нужна прослойка, преобразующая настройки и операции в поля и кнопки, а нажатия кнопок в посылку настроек и запуск операций.

Если протокол превращается в GUI и обратно, то это MVC, и придётся на тикле писать парсер, а это уже логика. А если форма GUI прибита гвоздями в скрипте без разбора протокола, то есть гарантированно заданы структура формочки без содержания, то это просто GUI-надстройка.

Яне встречал первого варианта, а вторых куча.

На скриптовом языке можно реализовывать различные комбинации использования этих устройств: позиционировать сервоприводы и снимать данные с датчиков в разном порядке.

Это уже ни фига не «glue», а логика приложения, согласен.

Вот это, как раз-таки, glue+logic. Просто logic - это когда по одной формочке на одну либку или устройство, но вид формочки гвоздями не прибит. Glue - это когда всё парсится и работается с единой структурой в скриптовом языке, но не разбирается на уровне семантики.

А если логика навороченная, или еще есть сложный gui, в котором свои абстракции, куча окон и т.п., тогда уж лучше питон.

Развитие тикля идёт как раз по пути, когда и для сложной гуйни он будет подходить.

Только свою функцию запилить. Лучше всего функцию которая склиет соответсвующую команду используя lindex и lrange, а потом выполнит ее.

Во имя справедливости:

regexp -inline {[а-я]+} {моё}

мо

regexp -inline {[а-я]+} {мое}

мое

Это думаю слишком далекая от ниши Tcl/Tk область

# 15
package require Tk
foreach {p} {7 2 10 11 5 4 9 12 13 8 3 14 15 1 6} {i} {0 1 2 3 4 5 6 7 8 9 10 11 12 13 14} {
	button .$p -relief solid -bd 1 -width 8 -height 4 -text $p -command "move $p"
	grid   .$p -row [expr {$i/4}] -column [expr {$i%4}] -padx 1 -pady 1}
proc move {b} {
	lassign [list [dict get [grid info .$b] -column] [dict get [grid info .$b] -row]] x y
	foreach {ix iy} {0 -1 0 1 -1 0 1 0} {
		lassign [list [expr {$x+$ix}] [expr {$y+$iy}]] i j
		if {$i>=0 && $i<=3 && $j>=0 && $j<=3 && ![llength [grid slaves . -col $i -row $j]]} {
			grid configure .$b -column $i -row $j}}}

# reversi
package require Tk
for {set i 0} {$i<64} {incr i} {lappend icells [expr {$i/8}] [expr {$i%8}]}
array set vs [list 1 2 2 1 cl,1 black cl,2 white pn,1 черные pn,2 белые]
ttk::button .b1 -text "Новая игра" -command {newgame 1 2}
ttk::button .b2 -text "Выход" -command {exit}
ttk::label  .l1 -text "Добро пожаловать в игру Реверси"
canvas .cv -width 479 -height 479
grid rowconfigure . 1 -weight 1
grid columnconfigure . 2 -weight 1
grid .b1 .b2 .l1 -padx 4 -pady 4 -sticky e
grid .cv -padx 4 -pady 4 -columnspan 3
foreach {x y} $icells {
  set cr1 [list [expr {$x*60+2}] [expr {$y*60+2}] [expr {$x*60+60}] [expr {$y*60+60}]]
  set cr2 [list [expr {$x*60+4}] [expr {$y*60+4}] [expr {$x*60+58}] [expr {$y*60+58}]]
  .cv create rectangle $cr1 -fill gray -tag "cell,$x,$y"
  .cv create oval $cr2 -state hidden -tag "piece $x,$y"
  .cv bind cell,$x,$y <1> [list evuser $x $y]}
proc pieceset {x y p}  {
  .cv itemconfigure $x,$y -state normal -fill $::vs(cl,$p)
  incr ::score($p)        [expr {+($::board($x,$y) != $p)}]
  incr ::score($::vs($p)) [expr {-($::board($x,$y) == $::vs($p))}]
  set  ::board($x,$y)     [list $p]}
proc newgame {p1 p2} {
  .cv itemconfigure piece -state hidden
  array set ::score  [list 0 0 1 0 2 0]
  array set ::player [list 1 $p1 2 $p2]
  foreach {x y} $::icells {set ::board($x,$y) 0}
  foreach {x y s} {3 3 2 4 4 2 3 4 1 4 3 1} {pieceset $x $y $s}
  set ::cur 1; waitturn}
proc getflips {x y p} {
  if {$::board($x,$y) != 0} return;
  set result {}
  foreach {ix iy} {0 -1 0 1 -1 0 1 0 -1 -1 1 1 1 -1 -1 1} {
    set temp {}
    for {set i [expr {$x+$ix}]; set j [expr {$y+$iy}]} \
        {[info exists ::board($i,$j)]} {incr i $ix; incr j $iy} {
        switch -- $::board($i,$j) \
          $::vs($p) {lappend temp $i $j} \
          $p        {foreach {m n} $temp {lappend result $m $n}; break} \
          0         {break}
  }}
  return $result}
proc waitturn {} {
  .l1 configure -text "Ходят $::vs(pn,$::cur) ($::score(1):$::score(2))"
  array set v [list $::cur {} $::vs($::cur) {}]  
  foreach {x y} $::icells {
    set l [getflips $x $y $::cur]; if {[llength $l]} {lappend v($::cur) [list $x $y]}
    set l [getflips $x $y $::vs($::cur)]; if {[llength $l]} {lappend v($::vs($::cur)) [list $x $y]}}
  if {[llength $v($::cur)] == 0 && [llength $v($::vs($::cur))] == 0} {
    tk_messageBox -title "Reversi" -message "Игра окончена"; return}
  if {$::player($::cur) == 1 && [llength $v($::cur)]} {
    set ::waituser 1; return}
  if {$::player($::cur) == 2 && [llength $v($::cur)]} {
    set ::waituser 0
    set ::flip [lindex $v($::cur) [expr {int([llength $v($::cur)]*rand())}]]
    turn [lindex $::flip 0] [lindex $::flip 1] $::cur}
  set ::cur $::vs($::cur); after idle waitturn}
proc evuser {x y} {
  if {[info exists ::waituser] && $::waituser && [turn $x $y $::cur]} {
    set ::cur $::vs($::cur); after idle waitturn}}
proc turn {x y p} {
  set flips [getflips $x $y $p]
  foreach {i j} $flips  {pieceset $i $j $p}
  if {[llength $flips]} {pieceset $x $y $p; return 1} else {return 0}}

«уж сколько раз твердили миру» (c) г-н Крылов
Хотя безполезно..root@localhost так и остаётся

что не так? рут? ты ж не думаешь что ... а ладно... :)

вы очевидно чего-то там недоставили в somedistr :)

странно. Стандартный тикль в стандартной поставке. без tcllib и подобного.

Каждый дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям. Мартин Фаулер.

root@localhost

Puppy? :)

Тебе что-то непонятно в десятке строчек пятнашек и ты так изысканно признаёшь себя дураком?

root@localhost # su
root@localhost # slapt-get install tcl
root@localhost # updatedb 
root@localhost # locate ...  

Надо было открыть другую консоль для locate :-D

Если протокол превращается в GUI и обратно, то это MVC, и придётся на тикле писать парсер, а это уже логика. А если форма GUI прибита гвоздями в скрипте без разбора протокола, то есть гарантированно заданы структура формочки без содержания, то это просто GUI-надстройка.

Второй вариант. Протокол реализован в библиотеке, GUI фиксирован. Писать что-то сложнее смысла нет, а реализовывать эту прослойку на Tcl куда лучше, чем на C/C++.

Яне встречал первого варианта, а вторых куча.

Первый вариант я кстати на днях реализовывал :) Есть девайс с сенсорным экраном и ARM, и задача реализовать на нем wizard с кучей диалоговых окон. Wizard реализован на ПК, он посылает девайсу по usb текстовые команды, которые отображают диалог с заданным типом и заданным содержимым. Для отладки на ПК еще есть скрипт на tcl, который эмулирует этот девайс: парсит протокол (он очень простой) и генерирует нужные виджеты.

Вот это, как раз-таки, glue+logic. Просто logic - это когда по одной формочке на одну либку или устройство, но вид формочки гвоздями не прибит. Glue - это когда всё парсится и работается с единой структурой в скриптовом языке, но не разбирается на уровне семантики.

А, все, я понял, о чем вы говорите.

У Реймонда есть glue logic в 14.3

Спасибо, теперь разобрался с терминологией :)

Развитие тикля идёт как раз по пути, когда и для сложной гуйни он будет подходить.

Это радует. Хотелось бы вливания в Tk фич из сторонних пакетов, чтобы не нужно было использовать всякие Tix. Вроде это тоже постепенно происходит.

In the Web-browser example, the glue would include the rendering code that maps a document object parsed from incoming HTML into a flattened visual representation as a bitmap in a display buffer, using GUI domain primitives to do the painting.

Русский перевод не читал.

Это думаю слишком далекая от ниши Tcl/Tk область

#15
# reversi

Код выглядит слегка обфусцированным но результат шикарный :)

Я имел в виду real-time графику, особенно 3d (в курсе, что пакеты для opengl есть, но смысла их использовать не вижу).

И далее...

This rendering code is notoriously the most bug-prone part of a browser. It attracts into itself kluges to address problems that originate both in the HTML parsing (because there is a lot of ill-formed markup out there) and the GUI toolkit (which may not have quite the primitives that are really needed).

Так что непонятно, что тогда document object на входе ( ибо его дополнительно glue layer на ошибки проверяет), если только не список лексем. Так что парсеру в glue layer быть.

stext

Мельком взглянул на него. Там у него данные по языкам в C зашиты. И вроде как все компоненты, из которых он состоит, на С также писаны. То есть логика в С. Плохо.

В Си там 2 компонента:

• Набор графических примитивов.
• Набор лексических анализаторов для разных языков.

В Tcl реализован виджет, который парсит текст с помощью анализаторов и отображает его с помощью графических примитивов. Снаружи этот виджет можно настраивать цветовой схемой, опциями и т.д.

Мне такой подход нравится, это лучше регекспов. Только анализаторы лучше бы на (f)lex были.

This rendering code is notoriously the most bug-prone part of a browser. It attracts into itself kluges to address problems that originate both in the HTML parsing (because there is a lot of ill-formed markup out there) and the GUI toolkit (which may not have quite the primitives that are really needed).

Так что непонятно, что тогда document object на входе ( ибо его дополнительно glue layer на ошибки проверяет), если только не список лексем. Так что парсеру в glue layer быть.

А вот вы о чем. Я-то это понял так, что из-за кривого HTML в DOM тоже хаки добавляются, которые должны в рендерере быть учтены.

Ну да не важно, главное мы друг друга поняли.

Там виджет уж более комплексный на C написан, не только собственно текстовой, а все эти номера строк, отметины и т. д. , плюс парсеры специфичные, а не один универсальный. То есть нельзя свою грамматику из тикля передать. ctext универсальнее.

Дока говорит, они text переделали. Что не очень, ибо две реализации одного компонента. Хорошо бы доработать text в Tk.

Я-то это понял так, что из-за кривого HTML в DOM тоже хаки добавляются

Реймонд об этом не пишет, но глупо кривой html превращать в кривое syntax tree и затем работать с ним.

Это да. Грамматику можно было бы на fickle/taccle сделать.

Я имел в виду real-time графику

http://wiki.tcl.tk/10287

http://wiki.tcl.tk/8825

http://wiki.tcl.tk/8607

Чем не real-time? :-) [ http://wiki.tcl.tk/13404 ]

cat 1.txt |egrep -o [а-я]+

А как это работает? Даже в википедии написано, что ё не входит в а-я.

Чем не real-time? :-)

Не поспоришь :) Спасибо за ссылку.

Даже в википедии написано,

)))

Вообще, именно такая работа ожидается от регекспов.