Re: stderr

[Alexander Danilov <alexander.a.danilov@gmail.com>]

Victor Wagner пишет:
> On 2008.11.25 at 01:22:27 +0900, Alexander Danilov wrote:
>
> > Artem Chuprina пишет:
> >
> > >  ПК> Кстати с чем мы сравниваем?
> > >
> > > С ленью.  Среднее количество телодвижений на единицу функциональности.
> > > Ну, факторизованное по языку программирования.  Хотя, скажем, Tk в tcl
> > > встроен гораздо компактнее и удобнее, чем в другие языки, что делает
> > > именно этот комплект предпочтительным перед любым другим комплектом из
> > > языка и тулкита для простых гуевин.  Но расширяется он тяжело, и,
> > > вероятно, в сложном случае будет проигрывать тому же
> > > объектно-ориентированному питону с тем же самым Tk.
> > Интересно бы увидеть пример, когда Tcl/Tk будет проигрывать, не флейма для, а опыта
>
> С точки зрения количества телодвижений Tcl проигрывает shell-у.
> Я тут как-то недавно переписывал билдсервер с (cygwinовского) bash на 
> (activestate) tcl, так объем кода вырос в раз несколько, а
> функциональность возросла не то чтобы сильно.
>
> На некоторых классах задач он проигрывает perl (в частности за счет
> -wc и -T у последнего).


Но есть подозрение, что читабельность по сравнению и с bash и perl возросла, так?
Да, лаконичным Tcl на назовёшь.

> > ради. Просто мне до сих пор встречались "сложные" случаи, но они были из разряда
> > "лобовая атака", то есть если попытаться загнать в listbox несколько тысяч строк,
>
> Был тут у меня пару лет назад случай, когда 6-мегабайтный массив данных
> несколько десятков тысяч раз не по делу конвертировался между двумя
> внутренними представлениями. Все-таки прозрачные для программиста 
> dual-representation объекты - не всегда rules. 
>
> Отловил только полезши в tclsh с дебаггером. А исправил - переставив
> местами две строчки (правда, в своем C-шном расширении, реализовывавшем
> мой собственный тип объектов).

Здесь тоже соглашусь, Сишный API простым не назовёшь, хотя dual-representation объекты чаще всего rules.

> > то тормоза конечно будут, но виноват разработчик, а если переделать форму, то и миллионы можно
>
> Листбоксы там прямо скажем неудачные. Если что посложнее, так надо
> Tktable брать. Вот там как раз и миллионы можно.

Нет, Tktable тоже большие объёмы переваривает на важно, хотя лучше того же listbox'a, значительно 
лучше. Для очень больших объёмов данных, лучше всё таки изменить алгоритм работы пользователя, ну а 
если это невозможно, то проще сделать frame с накиданными в него виджетами и scrollbar сбоку, чтобы
с помощью оного scrollbar'а подменять или значения -textvariable для виджетов из frame, или 
переменных, на которые -textvariable ссылается, это уж как удобней будет. Я такое 10 лет назад 
делал, только на perl/tk, так как с тиклем плохо ещё был знаком. Так вот в таком варианте прокрутка 
получается очень быстрая, если данные загрузить в массив. Если ещё немного времени потратить, можно 
сделать добавление/удаление строк в frame при изменении его размера.