>Как раз правильная. Сравнили языки в неподобающей им области.
зато во-первых, область у языков сильно похожа, во-вторых - тест синтетический, показывающий относительную производительность интерпретатора. Там не только деревья, кстати.
>Да, действительно. Но это его не ускорило :)
не знаю что там кого не ускорило, но пиджн не тормозит вообще.
>Но я помню, что ставил какой-то жаббер-клиент на питоне.
гажим наверное. Гажим местами тормозит, только гуй тут ни причем. Мучительный процесс переделывания изначально однотредового приложения в многотредовое только начался
>На наладоннике её вообще юзать нереально: гуй в одном потоке, обработка нажатий тормозит по полсекунды.
гуй в гтк по определению не может быть в одном потоке - на обработку каждого сигнала создается тред.
скорее всего там такая же проблема, как и в гажиме - кривые блокировки и мютексы в обработчиках expose
>> Как раз правильная. Сравнили языки в неподобающей им области.
> зато во-первых, область у языков сильно похожа, во-вторых - тест синтетический, показывающий относительную производительность интерпретатора.
Я тебе могу рассказать область применения tcl: "обвязки", обработка строковых данных, embedded-скрипты и event-driven системы. Не думаю, что у питона то же самое. он вроде как general purpose позиционируется.
> Там не только деревья, кстати.
Видел-видел.
>> Да, действительно. Но это его не ускорило :)
> не знаю что там кого не ускорило, но пиджн не тормозит вообще.
Ладно, попробуйю его ещё под icewm, а то под matchbox он был нетороплив. Как ни странно, но со сменой wm многие программы ускорились
>> Но я помню, что ставил какой-то жаббер-клиент на питоне.
> гажим наверное. Гажим местами тормозит, только гуй тут ни причем. Мучительный процесс переделывания изначально однотредового приложения в многотредовое только начался
Ну хорошо ежели так.
>> На наладоннике её вообще юзать нереально: гуй в одном потоке, обработка нажатий тормозит по полсекунды.
> гуй в гтк по определению не может быть в одном потоке - на обработку каждого сигнала создается тред.
8-(......) Ты уверен? Это ж просто π-здец получается...
> скорее всего там такая же проблема, как и в гажиме - кривые блокировки и мютексы в обработчиках expose
Высокоуровневый язык не спас от низкоуровневых проблем?
>> Я тебе могу рассказать область применения tcl: "обвязки",
> какие?
xmaxima та же. unit-тесты на нём очень удобно пишутся.
>> обработка строковых данных
> perl, python :)
и они в т.ч. Но tcl их порвал в тесте с регекспами :)
>> embedded-скрипты и event-driven системы.
> guile, python =)
Оба раза мимо.
> только вот ты tcl используешь как gp =)
Нифига: я там спектры матриц не считаю :) У меня там работа "скачать-распарсить-отобразить", всё со строками.
>> 8-(......) Ты уверен? Это ж просто π-здец получается...
> почему? X11 в принципе асинхронная система вообще-то =)
Потому что тред в линуксах как процесс стоит, т.е. недёшево.
И я не встречал гуи-библиотек, в которых бы на обработку сигнала создаётся отдельный поток. Обычно сигналы ставятся в очередь и обрабатываются в event loop. Верно как минимум для win32, qt, tk.
Ты точно не ошибся? А то мне попадалась на глаза фраза "gtk event loop".
>> Высокоуровневый язык не спас от низкоуровневых проблем?
> не серебряная пуля же
Ну вот я в tcl о примитивах синхронизации не думаю -- тут их тупо нет. Их всех заменяет event loop.
>xmaxima та же. unit-тесты на нём очень удобно пишутся.
lisp чем не угодил? =)
>Нифига: я там спектры матриц не считаю :)
ну так и на питоне не считают. Ты думаешь, только математика превращает яп в гп?
>Потому что тред в линуксах как процесс стоит, т.е. недёшево.
про NPTL не слышал?
>И я не встречал гуи-библиотек, в которых бы на обработку сигнала создаётся отдельный поток.
ну вот теперь встретил.
>А то мне попадалась на глаза фраза "gtk event loop".
евенты разбиты по контекстам, а контекстов может быть несколько. Это раз. У окон точно по своему контексту создается, у попап-виджетов тоже. Точнее надо доки (а точнее даже сырцы) курить
>Ну вот я в tcl о примитивах синхронизации не думаю -- тут их тупо нет. Их всех заменяет event loop.
точно, а ткаббер подвисал вместе с сетью из-за астральных наводок.
>А вот этот ляп Вам, коллега, будут припоминать до скончания веков.
посыпаю голову пеплом. Сейчас уже не вспомню, что меня на такую мысль натолкнуло - наверное таймауты вкупе с тем фактом, что мне пришлось в модуль блокировки соображать, потому что оригинальные обработчики сигналов приложений вызывались во время изменения структур и получалась корка.
>> /me не осилил tklor. потому что «X server insecure (must use xauth-style authorization); command ignored», а пересобирать tk с отключением этой ерунды - уже лениво.
> xhost -
ну вернее «xhost -local:», который мне как правило нужен. и в результате пришлось все равно передергивать X-сы, поскольку в Xauthority я тоже успел покопаться :-)
>> на _питоне_ не считают. А только дергают либы, написанные на сях
> Либо сидеть в си и не вылезать, либо юзать DSL, т.е. язык интерпретатора maxima-ы или scilab.
Счет матриц нужен не сам по себе, а обычно с гуем, сетью, обращением к другим программам, БД и прочеим. Для этого нужен нормальный язык программирования.
...в рамках более масштабной числодробилки. Видел недавно работу, в которой надо было перебрать миллион комбинаций и в каждой найти собственные числа у большой, хотя и разреженной матрицы. И всё ради получения одного числа.
> а обычно с гуем, сетью, обращением к другим программам, БД и прочеим.
Ну если у Вас программа, которой остро необходимо всё это держать вместе и тесно переплетённым, то я Вам искренне сочувствую.
> Для этого нужен нормальный язык программирования.
Нормальных языков нет, есть достаточно хорошие в каждой конкретной задаче.
почему не вылезать-то? Объясни? тылгунеры ты, видишь ли, претензии предьявляешь по поводу запихивания гуя и расчетов в одну прогу, а мне утверждаешь, что вылезать не надо. Определись уж =)
>Как зарезолвится -- $command поставится в очередь и выполнится, как дойдёт до неё время. Никаких мьютексов в явном виде.
> что-то у тебя хреново сходится. Если не тащить гуй в Си, то надо тащить молотилку в скриптовые яп? =)
Это что-то у тебя в черепушке бинарное засело, раз раз не в Ц, то в скриптах и наоборот.
Ну а про авторам программ, которым надо и ряд Фурье получить и в базу записать(наверно ещё через ORM, чего мелочиться-то!) и гуйню показать(с перделками), и всё в одном месте и на одном языке, я, как уже сказал, искренне сочувствую.
> Зачем сочувствовать? Жабка неплохой язык. Да и додиез можно при желании использовать.
Да, с БД, сетью и гуйком всё станет хорошо. Только вот расчётная часть в неудачном положении окажется.
Про жабку: Язык, в котором вместо == надо писать .equals из математики надо гнать ссаными тряпками.
Кстати, в до-диезе та самая перегрузка имеется. Но это не делает язык, перегруженный избыточными возможностями, применимым там, где нужна скорость. И не надо мне говорить про скорость разработки: почти любой матпакет сейчас умеет генерировать сишный/фортрановский код из своего внутреннего языка.
> почти любой матпакет сейчас умеет генерировать сишный/фортрановский код из своего внутреннего языка.
Но, конечно, этот код без напильника не запустишь. Мапл так и не смог перевести в си код, в котором использовалась функция, переданная в качестве аргумента :)
>> Про жабку: Язык, в котором вместо == надо писать .equals из математики надо гнать ссаными тряпками.
> Когда прикопаться больше не к чему прикапываются к синтаксису.
Этот синтаксис нарабатывался веками. И это подтверждает его удобство.
Но конечно, sun-техники самые умные и знают, что надо писать if (Matrix.add(Matrix.mul(a,b)).equals(e) вместо a*b = e. В энтерпрайзе-то оно удобно, но математика -- не энтерпрайз.