Вышел (http://sourceforge.net/projects/tcl/files/Tcl/8.6.2/tcltk-re...) релиз Tcl/Tk 8.6.2 (http://tcl.tk/), динамического языка программирования, распространяемого совместно с кроссплатформенной библиотекой базовых элементов графического интерфейса. Несмотря на то, что основное распространение Tcl получил для создания интерфейсов пользователя и как встраиваемый язык, Tcl также прекрасно подходит для других задач, таких как web-разработка, создание сетевых приложений, решение задач по администрированию систем и тестированию.
Из изменений (http://wiki.tcl.tk/40547) можно отметить:
- Реализована новая команда "[string cat]";
- Команды [lsearch -integer] и [lsort -integer] переведены на использование типа "wide integer";
- Команды замены и удаления словарей ([dict replace], [dict remove]) теперь возвращают канонические словари;
- Добавлена поддержка операций [file attributes -readonly -archive -hidden -system] для платформы Cygwin;
- Для платформы Windows добавлена поддержка расширенных файловых путей;
- В Tk размер выводимых файлов PPM увеличен до 65535;
- Обеспечена компиляция байткода для команд [concat], [linsert], [namespace origin], [next],
[nextto], [string is], [string replace], [string tolower],
[string totitle], [string toupper], [string trim], [string trimleft],
[string trimright] и [yieldto];- Обновлены версии пакетов TclOO 1.0.2,
http 2.8.8,
msgcat 1.5.2,
platform 1.0.13,
tcltest 2.3.7,
itcl 4.0.1,
Thread 2.7.1,
tdbc 1.0.1;
- Устранено несколько утечек памяти, проведена оптимизация производительности.
URL: http://sourceforge.net/projects/tcl/files/Tcl/8.6.2/tcltk-re...
Новость: https://www.opennet.ru/opennews/art.shtml?num=40464
Ура! Особенно порадовало, как принимали [string cat]: предложили, убедились, что решает кучу проблем, проголосовали, смержили — и в продакшын :)
Отвратительный язык и ещё более отвратительный тулкит.
Не осилил, так и скажи. А инструмент не виноват.
Немного оффтоп, но близко..
А есть кто пользует тикль под openwrt?
Никак не пойму, как его там полноценно применять...
> Немного оффтоп, но близко..
> А есть кто пользует тикль под openwrt?
> Никак не пойму, как его там полноценно применять...А что интересует конкретно?
устанавливаю пакет. Вызываю интерпретатор. Выдает ошибку об отсутствии init.tcl. подсовывал папку со всеми файлами из архива tcl. Ругаться на отсутствие файлов перестает, но при работе с проектом пишет об отсутствии функций и некоторых команд.если есть возможность - разъясните что может быть не так делаю...
> устанавливаю пакет. Вызываю интерпретатор. Выдает ошибку об отсутствии init.tcl. подсовывал
> папку со всеми файлами из архива tcl. Ругаться на отсутствие файлов
> перестает, но при работе с проектом пишет об отсутствии функций и
> некоторых команд.если есть возможность - разъясните что может быть не так
> делаю...Используется что-то из tcllib? Надо смотреть на конкретные ошибки, так непонятно.
А самое главное - не дает работать с ком-портом. Конкретно, есть много адаптеров usb-serial (все перепробовал, думал драйверы кривые). Ошибка при вызове fopen с fconfigure с параметрами ком-порта, как-будто считает /dev/ttyUSB0 не ком-порт. При этом подобный проект на пхп нормально получает данные из устройства с любыми адаптерами.
> А самое главное - не дает работать с ком-портом. Конкретно, есть много
> адаптеров usb-serial (все перепробовал, думал драйверы кривые). Ошибка при вызове fopen
> с fconfigure с параметрами ком-порта, как-будто считает /dev/ttyUSB0 не ком-порт. При
> этом подобный проект на пхп нормально получает данные из устройства с
> любыми адаптерами.Это тоже под openwrt? Только недавно работал с ttyUSB устройствами из тикля на обычном дистрибутиве, и все было ок. Может, порт настроен неправильно (скорость/parity и т.д.)? Ему можно изменить параметры через fconfigure.
Подробнее в man 3tcl open, секция SERIAL COMMUNICATIONS.
>> А самое главное - не дает работать с ком-портом. Конкретно, есть много
>> адаптеров usb-serial (все перепробовал, думал драйверы кривые). Ошибка при вызове fopen
>> с fconfigure с параметрами ком-порта, как-будто считает /dev/ttyUSB0 не ком-порт. При
>> этом подобный проект на пхп нормально получает данные из устройства с
>> любыми адаптерами.
> Это тоже под openwrt? Только недавно работал с ttyUSB устройствами из тикля
> на обычном дистрибутиве, и все было ок. Может, порт настроен неправильно
> (скорость/parity и т.д.)? Ему можно изменить параметры через fconfigure.
> Подробнее в man 3tcl open, секция SERIAL COMMUNICATIONS.В дебиан под арм тоже все прекрасно. Именно из-под опенврт проблемы. FConfigure и выдает ошибку, не принимает параметры 9600,n,8,1...
Дабы не засорять топик новостей, перенесу вопрос на форум. Спасибо..
Объективно, версия 8.6 имеет массу недостатков. Части из них, к сожалению, не лишена и версия 8.5.
Самая большая моя претензия - к скорости: в 8.6 они отказались от использования стэка вообще и пихают все в кучу. Естественно, это никоим образом положительно на скорости не сказалось.
Встроенная команда [clock] еще с 8.5 написана наполовину на тикле, в 8.4 была на Си, естественно, это тоже отвратительно сказалось на производительности. В частности, было очень неприятно обнаружить одним прекрасным днем, что моя утилита разбора логов, активно использующая эту команду, стала работать примерно в 100(!) раз медленнее. Пришлось переписать все на обычную арифметику с unix timestamp и изменить формат логирования - т.е. они свой геморрой с портабельностью (позиционировалось это именно так), превратили в мой геморрой с оптимизацией.
В 8.6 [tailcall] не оптимизирует хвостовую рекурсию, код с ним работает медленнее, чем без. Тут я вообще с трудом понимаю, почему нельзя было сделать оптимизацию хвостовой рекурсии на уровне компиляции в байткод, зачем для этого отдельный вызов.
Что у них происходит с багзиллой - я уже запарился разбираться, каждый чертов год она какая-то новая и хрен поймешь, как туда завести баг (это касается в основном tcllib).
Язык - изумительный; концепции год от года все больше эволюционируют; однако, реализация ряда features "оставляет желать".
Коммьюнити небольшое, зато высокопрофессиональное - это плюс. Но то, что оно небольшое, отрицательно сказывается на количестве доступных библиотек. Часто приходится изобретать свою реализацию, и хорошо, если это что-то простое.
И все же, другого насколько же гибкого языка я не знаю.
я знаю: perl.
А Перл будет быстрее работать?
А памяти потреблять?
А многопоточность легче дается?
А обмен информацией между процессами легче у Перла или нет?
А интерфейс делать (уровня Tcl !!!) проще или сложнее?
> А Перл будет быстрее работать?а в каких задачах?
> А памяти потреблять?
а в каких задачах?
> А многопоточность легче дается?
Когда в перле потоки уже много лет были - в тикле их еще не было. И по моему опыту - да. Но опять же - смотря что под этим подразумевается. Если как можно быстрее взять и написать приложения с потоками, то в перле для этого есть все: несколько версий с отличной документацией и обширными примерами. Тогда как в тикле до 8.6 треды нужно было искать где-то (cpan'a то нет), и документации там кот наплакал, мало что понятно, а уж примеров и того меньше.
> А обмен информацией между процессами легче у Перла или нет?
что подразумевается под "легче"? Серьёзно. А то для меня «легче» - это когда я пишу код как можно быстрее и с минимум неожиданностей.
> А интерфейс делать (уровня Tcl !!!) проще или сложнее?
Когда нужно сделать интерфейс на ncurses, например, то в тикле начинается жуткий трэшак. Просто обёртка над ncurses на Си. Тогда как в перле идут какие хош модули с хорошей документацией и примерами. Т.е. менее сложно. И так для gtk2, gtk3, Tk, qt, X11. Т.е. просто: пиши на чём хочешь. В тикле проще? Или нужно больше телодвижений? А то в перле например: cpan <module>; perldoc <module> и вперёд с песней.
P.S. А тикль мне нравится. Простенькие скрипты иногда пишу на нём, когда нужен больше чем шелл, но все еще не язык общего назначения, вроде perl/objpascal.
>> А Перл будет быстрее работать?
> а в каких задачах?
>> А памяти потреблять?
> а в каких задачах?Я это понимаю так, что - в каких-то задачах быстрее а в каких-то нет, т.е. Перл не всегда быстрее, а вы как специалист возможно сможете сказать точнее ! ))
>[оверквотинг удален]
> еще не было. И по моему опыту - да. Но опять
> же - смотря что под этим подразумевается. Если как можно быстрее
> взять и написать приложения с потоками, то в перле для этого
> есть все: несколько версий с отличной документацией и обширными примерами. Тогда
> как в тикле до 8.6 треды нужно было искать где-то (cpan'a
> то нет), и документации там кот наплакал, мало что понятно, а
> уж примеров и того меньше.
>> А обмен информацией между процессами легче у Перла или нет?
> что подразумевается под "легче"? Серьёзно. А то для меня «легче» - это
> когда я пишу код как можно быстрее и с минимум неожиданностей.Я под легче понимаю - для новичка, в каком языке из этих двух меньше придется учить и
быстрее потом писать?>> А интерфейс делать (уровня Tcl !!!) проще или сложнее?
> Когда нужно сделать интерфейс на ncurses, например, то в тикле начинается жуткий
> трэшак. Просто обёртка над ncurses на Си. Тогда как в перле
> идут какие хош модули с хорошей документацией и примерами. Т.е. менее
> сложно. И так для gtk2, gtk3, Tk, qt, X11. Т.е. просто:
> пиши на чём хочешь. В тикле проще? Или нужно больше телодвижений?
> А то в перле например: cpan <module>; perldoc <module> и вперёд
> с песней.Интересует построение интерфейса с наименьшими усилиями, ведь если к интерфейсу высокие требования,
то ясно что нужны мощные библиотеки, хотя бы wxWidgets например.> P.S. А тикль мне нравится. Простенькие скрипты иногда пишу на нём, когда
> нужен больше чем шелл, но все еще не язык общего назначения,
> вроде perl/objpascal.Спасибо, интересно было прочитать )
>Я это понимаю так, что - в каких-то задачах быстрее а в каких-то нет, т.е. Перл не всегда быстрее, а вы как специалист возможно сможете сказать точнее ! ))Конечно. В мелких скриптах у меня тикль быстрее работает. В крупных - не сравнивал, т.к. пустая трата времени ради бенчмарка. Ведь многие библиотеки, отсутствующие в тикле пришлось бы писать самому. Так что не могу сказать об этом что-то наверняка. И да, я не специалист. Так, быдлокодер средней руки. Ничего не пишу по вдохновению. Только когда встаёт необходимость перенести рутину на плечи компа. Вот тогда и начинается попутное изучение программирования.
>Я под легче понимаю - для новичка, в каком языке из этих двух меньше придется учить и быстрее потом писать?
Зависит от того "что писать", наверное. По себе заметил (а я новичёк), что чем сложнее конечная идея - тем выше абстракции, и тем лучше использовать для этих абстракций библиотеки, позволяющие не отвлекаться на несущественные детали и быстрее реализовать задуманное. Здесь perl обогнал (для меня) простоту тикля cpan'ом и тем что позволяет не разбираться сразу во всём языке, и иметь возможность сразу писать рабочие программы разного уровня сложности.