| 1.1, Аноним (-), 13:31, 27/08/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Ура! Особенно порадовало, как принимали [string cat]: предложили, убедились, что решает кучу проблем, проголосовали, смержили — и в продакшын :)
| | |
| 1.4, Аноним (-), 17:03, 27/08/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Немного оффтоп, но близко..
А есть кто пользует тикль под openwrt?
Никак не пойму, как его там полноценно применять...
| | |
| |
| 2.5, anonymous (??), 22:09, 27/08/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Немного оффтоп, но близко..
> А есть кто пользует тикль под openwrt?
> Никак не пойму, как его там полноценно применять...
А что интересует конкретно?
| | |
| |
| 3.8, Аноним (-), 07:58, 29/08/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
устанавливаю пакет. Вызываю интерпретатор. Выдает ошибку об отсутствии init.tcl. подсовывал папку со всеми файлами из архива tcl. Ругаться на отсутствие файлов перестает, но при работе с проектом пишет об отсутствии функций и некоторых команд.если есть возможность - разъясните что может быть не так делаю...
| | |
| |
| 4.10, anonymous (??), 12:09, 29/08/2014 [^] [^^] [^^^] [ответить]
| +/– |
> устанавливаю пакет. Вызываю интерпретатор. Выдает ошибку об отсутствии init.tcl. подсовывал
> папку со всеми файлами из архива tcl. Ругаться на отсутствие файлов
> перестает, но при работе с проектом пишет об отсутствии функций и
> некоторых команд.если есть возможность - разъясните что может быть не так
> делаю...
Используется что-то из tcllib? Надо смотреть на конкретные ошибки, так непонятно.
| | |
|
| 3.9, Аноним (-), 08:19, 29/08/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
А самое главное - не дает работать с ком-портом. Конкретно, есть много адаптеров usb-serial (все перепробовал, думал драйверы кривые). Ошибка при вызове fopen с fconfigure с параметрами ком-порта, как-будто считает /dev/ttyUSB0 не ком-порт. При этом подобный проект на пхп нормально получает данные из устройства с любыми адаптерами.
| | |
| |
| 4.11, anonymous (??), 12:14, 29/08/2014 [^] [^^] [^^^] [ответить]
| +/– |
> А самое главное - не дает работать с ком-портом. Конкретно, есть много
> адаптеров usb-serial (все перепробовал, думал драйверы кривые). Ошибка при вызове fopen
> с fconfigure с параметрами ком-порта, как-будто считает /dev/ttyUSB0 не ком-порт. При
> этом подобный проект на пхп нормально получает данные из устройства с
> любыми адаптерами.
Это тоже под openwrt? Только недавно работал с ttyUSB устройствами из тикля на обычном дистрибутиве, и все было ок. Может, порт настроен неправильно (скорость/parity и т.д.)? Ему можно изменить параметры через fconfigure.
Подробнее в man 3tcl open, секция SERIAL COMMUNICATIONS.
| | |
| |
| 5.12, Аноним (-), 13:10, 29/08/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> А самое главное - не дает работать с ком-портом. Конкретно, есть много
>> адаптеров usb-serial (все перепробовал, думал драйверы кривые). Ошибка при вызове fopen
>> с fconfigure с параметрами ком-порта, как-будто считает /dev/ttyUSB0 не ком-порт. При
>> этом подобный проект на пхп нормально получает данные из устройства с
>> любыми адаптерами.
> Это тоже под openwrt? Только недавно работал с ttyUSB устройствами из тикля
> на обычном дистрибутиве, и все было ок. Может, порт настроен неправильно
> (скорость/parity и т.д.)? Ему можно изменить параметры через fconfigure.
> Подробнее в man 3tcl open, секция SERIAL COMMUNICATIONS.
В дебиан под арм тоже все прекрасно. Именно из-под опенврт проблемы. FConfigure и выдает ошибку, не принимает параметры 9600,n,8,1...
Дабы не засорять топик новостей, перенесу вопрос на форум. Спасибо..
| | |
|
|
|
|
| 1.6, anonymous (??), 22:23, 27/08/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Объективно, версия 8.6 имеет массу недостатков. Части из них, к сожалению, не лишена и версия 8.5.
Самая большая моя претензия - к скорости: в 8.6 они отказались от использования стэка вообще и пихают все в кучу. Естественно, это никоим образом положительно на скорости не сказалось.
Встроенная команда [clock] еще с 8.5 написана наполовину на тикле, в 8.4 была на Си, естественно, это тоже отвратительно сказалось на производительности. В частности, было очень неприятно обнаружить одним прекрасным днем, что моя утилита разбора логов, активно использующая эту команду, стала работать примерно в 100(!) раз медленнее. Пришлось переписать все на обычную арифметику с unix timestamp и изменить формат логирования - т.е. они свой геморрой с портабельностью (позиционировалось это именно так), превратили в мой геморрой с оптимизацией.
В 8.6 [tailcall] не оптимизирует хвостовую рекурсию, код с ним работает медленнее, чем без. Тут я вообще с трудом понимаю, почему нельзя было сделать оптимизацию хвостовой рекурсии на уровне компиляции в байткод, зачем для этого отдельный вызов.
Что у них происходит с багзиллой - я уже запарился разбираться, каждый чертов год она какая-то новая и хрен поймешь, как туда завести баг (это касается в основном tcllib).
Язык - изумительный; концепции год от года все больше эволюционируют; однако, реализация ряда features "оставляет желать".
Коммьюнити небольшое, зато высокопрофессиональное - это плюс. Но то, что оно небольшое, отрицательно сказывается на количестве доступных библиотек. Часто приходится изобретать свою реализацию, и хорошо, если это что-то простое.
И все же, другого насколько же гибкого языка я не знаю.
| | |
| |
| |
| 3.14, Slava (??), 21:23, 01/09/2014 [^] [^^] [^^^] [ответить]
| +/– |
А Перл будет быстрее работать?
А памяти потреблять?
А многопоточность легче дается?
А обмен информацией между процессами легче у Перла или нет?
А интерфейс делать (уровня Tcl !!!) проще или сложнее?
| | |
| |
| 4.15, chinarulezzz (ok), 22:13, 01/09/2014 [^] [^^] [^^^] [ответить]
| +/– |
 > А Перл будет быстрее работать?
а в каких задачах?
> А памяти потреблять?
а в каких задачах?
> А многопоточность легче дается?
Когда в перле потоки уже много лет были - в тикле их еще не было. И по моему опыту - да. Но опять же - смотря что под этим подразумевается. Если как можно быстрее взять и написать приложения с потоками, то в перле для этого есть все: несколько версий с отличной документацией и обширными примерами. Тогда как в тикле до 8.6 треды нужно было искать где-то (cpan'a то нет), и документации там кот наплакал, мало что понятно, а уж примеров и того меньше.
> А обмен информацией между процессами легче у Перла или нет?
что подразумевается под "легче"? Серьёзно. А то для меня «легче» - это когда я пишу код как можно быстрее и с минимум неожиданностей.
> А интерфейс делать (уровня Tcl !!!) проще или сложнее?
Когда нужно сделать интерфейс на ncurses, например, то в тикле начинается жуткий трэшак. Просто обёртка над ncurses на Си. Тогда как в перле идут какие хош модули с хорошей документацией и примерами. Т.е. менее сложно. И так для gtk2, gtk3, Tk, qt, X11. Т.е. просто: пиши на чём хочешь. В тикле проще? Или нужно больше телодвижений? А то в перле например: cpan <module>; perldoc <module> и вперёд с песней.
P.S. А тикль мне нравится. Простенькие скрипты иногда пишу на нём, когда нужен больше чем шелл, но все еще не язык общего назначения, вроде perl/objpascal.
| | |
| |
| 5.16, Slava (??), 22:43, 01/09/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> А Перл будет быстрее работать?
> а в каких задачах?
>> А памяти потреблять?
> а в каких задачах?
Я это понимаю так, что - в каких-то задачах быстрее а в каких-то нет, т.е. Перл не всегда быстрее, а вы как специалист возможно сможете сказать точнее ! ))
>[оверквотинг удален]
> еще не было. И по моему опыту - да. Но опять
> же - смотря что под этим подразумевается. Если как можно быстрее
> взять и написать приложения с потоками, то в перле для этого
> есть все: несколько версий с отличной документацией и обширными примерами. Тогда
> как в тикле до 8.6 треды нужно было искать где-то (cpan'a
> то нет), и документации там кот наплакал, мало что понятно, а
> уж примеров и того меньше.
>> А обмен информацией между процессами легче у Перла или нет?
> что подразумевается под "легче"? Серьёзно. А то для меня «легче» - это
> когда я пишу код как можно быстрее и с минимум неожиданностей.
Я под легче понимаю - для новичка, в каком языке из этих двух меньше придется учить и
быстрее потом писать?
>> А интерфейс делать (уровня Tcl !!!) проще или сложнее?
> Когда нужно сделать интерфейс на ncurses, например, то в тикле начинается жуткий
> трэшак. Просто обёртка над ncurses на Си. Тогда как в перле
> идут какие хош модули с хорошей документацией и примерами. Т.е. менее
> сложно. И так для gtk2, gtk3, Tk, qt, X11. Т.е. просто:
> пиши на чём хочешь. В тикле проще? Или нужно больше телодвижений?
> А то в перле например: cpan <module>; perldoc <module> и вперёд
> с песней.
Интересует построение интерфейса с наименьшими усилиями, ведь если к интерфейсу высокие требования,
то ясно что нужны мощные библиотеки, хотя бы wxWidgets например.
> P.S. А тикль мне нравится. Простенькие скрипты иногда пишу на нём, когда
> нужен больше чем шелл, но все еще не язык общего назначения,
> вроде perl/objpascal.
Спасибо, интересно было прочитать )
| | |
| |
| 6.17, chinarulezzz (ok), 00:49, 02/09/2014 [^] [^^] [^^^] [ответить]
| +/– | |
>Я это понимаю так, что - в каких-то задачах быстрее а в каких-то нет, т.е. Перл не всегда быстрее, а вы как специалист возможно сможете сказать точнее ! ))
Конечно. В мелких скриптах у меня тикль быстрее работает. В крупных - не сравнивал, т.к. пустая трата времени ради бенчмарка. Ведь многие библиотеки, отсутствующие в тикле пришлось бы писать самому. Так что не могу сказать об этом что-то наверняка. И да, я не специалист. Так, быдлокодер средней руки. Ничего не пишу по вдохновению. Только когда встаёт необходимость перенести рутину на плечи компа. Вот тогда и начинается попутное изучение программирования.
>Я под легче понимаю - для новичка, в каком языке из этих двух меньше придется учить и быстрее потом писать?
Зависит от того "что писать", наверное. По себе заметил (а я новичёк), что чем сложнее конечная идея - тем выше абстракции, и тем лучше использовать для этих абстракций библиотеки, позволяющие не отвлекаться на несущественные детали и быстрее реализовать задуманное. Здесь perl обогнал (для меня) простоту тикля cpan'ом и тем что позволяет не разбираться сразу во всём языке, и иметь возможность сразу писать рабочие программы разного уровня сложности.
| | |
|
|
|
|
|
|
