Программизм

> Что то на нём маловато программ, да и выглядит оно не особо. Так что пока - конь ::))

И лисп - тоже конь? А то на нём программ тоже маловато: emacs и maxima, больше с ходу не припомню :)

>> Не-быдлокодер знает, как, хотя бы в общих чертах, устроен используемый механизм.

> Я знаю, что процессоры сделаны с использованием кремния. Значит я уже не быдлокодер?

Даже на право нажатия кнопки включения не хватит, так как там надо по правилам сдать 'electrostatic Discharge' :)

>> На уровне кода знать и не надо. Достаточно знать hign-level. Напоминаю Ваши слова про то, что "мне этого знать не надо".

> Что бы _написать_ гуй мне необходимо и достаточно достаточно знать QObject::connect(). Это не highlevel? Или нужно что то ещё?

Нужно как минимум понимание event-driven структуры гуйков(пускай в qt/window$::forms/gtk он и однопоточен), и понимание того, что кроется за signal-slot взаимодействием, коли уж взялись писать на qt.

>> Так он их через queued получает или нет? Я уже в течении нескольких сообщений пытаюсь у Вас это выяснить.

> queued connection используется по дефолту, хотя можно включить direct connection и получить все прелести работы с мутексами ::))

А чтобы эту прелесть не получить, надо прочитать-таки одну страничку из qt assistant и подумать, а не навернётся ли чего-нибудь при многопоточном обращении.

>> И если через queued - то там используются mutexes. И об этом знать _надо_.

> Они может быть и используются внутри qt. Bот только под словом "знать" я понимаю учёт их в _своём_ коде.

Вполне подходит такое определение. Надо знать, что при использовании queued connection проблем с синхронизацией сигнал-слотового взаимодействия не будет.

>> Ну и что? Раз в гуепрограмме нельзя ошибиться, то почему авторы амарока допустили ненулевое количество багов?

> Да это не просто тупая гуепрограмма, а нечто более сложное. Я говорил про простое на 200 строчках.

Ну это, наверно, тоже сферический конь...

> Напутал пару слов, признаю. Это я к тому, что с библиотеками, оказывается, можно переборщить. Прям вындовз-вэй какой-то.

Ну я тоже члегка перегнул... Хотя много библиотек могут вызвать конфликт, который сразу и не приметишь.

Ну это уже другое. Файлы *.emacs расширяют функциональность бинарной программы. Только с этим тоже можно переборщить. Пример тому firefox. С одной стороны удобно, но памяти жрёт немеряно. Спасает только то, что он - один.

> Даже на право нажатия кнопки включения не хватит, так как там надо по правилам сдать 'electrostatic Discharge' :)

У меня стол железный. Разряд происходит автоматически ::))

> А чтобы эту прелесть не получить, надо прочитать-таки одну страничку из qt assistant и подумать, а не навернётся ли чего-нибудь при многопоточном обращении.

Для этого достаточно знать, как передаются переменные. Если обмен односторонний, то проблем не должно быть, в принципе. Вот только надо воздержаться от передачи указателя, который может измениться за время ожидания в очереди. Это единственные грабли, которые можно встретить.

> Ну это, наверно, тоже сферический конь...

Почему конь? Морда к femon занимает примерно столько (не считая *.ui файлы).

> Ну я тоже члегка перегнул... Хотя много библиотек могут вызвать конфликт, который сразу и не приметишь.

Проблемы в основном возникают от частой смены интерфейсов используемых библиотек. Например, недавно, поломали ffmpeg. Изменения вроде незначительные, но большая часть программ перестала собираться.

> Ну это уже другое. Файлы *.emacs расширяют функциональность бинарной программы.

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

> Только с этим тоже можно переборщить. Пример тому firefox. С одной стороны удобно, но памяти жрёт немеряно. Спасает только то, что он - один.

XUL вообще из разряда технологий, опередивших время, т.е. нет ещё таких мощностей, на которых бы он приемлимо работал :)

>> Даже на право нажатия кнопки включения не хватит, так как там надо по правилам сдать 'electrostatic Discharge' :)

> У меня стол железный. Разряд происходит автоматически ::))

Ладно, включать разрешаю :)

>> А чтобы эту прелесть не получить, надо прочитать-таки одну страничку из qt assistant и подумать, а не навернётся ли чего-нибудь при многопоточном обращении.

> Для этого достаточно знать, как передаются переменные. Если обмен односторонний, то проблем не должно быть, в принципе.

Если присваивание значения переменной атомарно - то да, этого хватит. А если нет, то получите race condition.

> Вот только надо воздержаться от передачи указателя, который может измениться за время ожидания в очереди. Это единственные грабли, которые можно встретить.

Не только. См. выше.

>> Ну это, наверно, тоже сферический конь...

> Почему конь? Морда к femon занимает примерно столько (не считая *.ui файлы).

Ладно.

Другой аргумент в пользу tk: зачем для написания простого гуя использовать тулкит, у которого коммерческая лицензия на одного человека стоит 2 штукобакса?

>> Ну я тоже члегка перегнул... Хотя много библиотек могут вызвать конфликт, который сразу и не приметишь.

> Проблемы в основном возникают от частой смены интерфейсов используемых библиотек. Например, недавно, поломали ffmpeg. Изменения вроде незначительные, но большая часть программ перестала собираться.

Не всегда. Например, не пробовали использовать в одном проекте facelets и tomahawk? Интересные варнинги в логи сыпятся. Хотя по отдельности работает без проблем, да и разработчики томагавка клянутся, что он с facelets совместим.

Я о том, что в Ваших примерах лисп используется для расширения функциональности. А сам проект как был на си, так на нём и остался. Таким же макаром можно написать qt приложение на ECMAScript ::))

> XUL вообще из разряда технологий, опередивших время, т.е. нет ещё таких мощностей, на которых бы он приемлимо работал :)

Проблема только в том, что всё это есть вложение матрёшек. Когда мощности будет более чем достатчно для исполнения XUL - придумают ещё какой-нибудь фрэймоврк поверх и будем опять огребать торомоза.

> Если присваивание значения переменной атомарно - то да, этого хватит. А если нет, то получите race condition.

А очерель на что?

>Не всегда. Например, не пробовали использовать в одном проекте facelets и tomahawk? Интересные варнинги в логи сыпятся. Хотя по отдельности работает без проблем, да и разработчики томагавка клянутся, что он с facelets совместим.

Ну это что то из явы....

>Другой аргумент в пользу tk: зачем для написания простого гуя использовать тулкит, у которого коммерческая лицензия на одного человека стоит 2 штукобакса?

qt - он не один, есть ещё gtk ::))

> Я о том, что в Ваших примерах лисп используется для расширения функциональности. А сам проект как был на си, так на нём и остался.

maxima - полностью на lisp

>> XUL вообще из разряда технологий, опередивших время, т.е. нет ещё таких мощностей, на которых бы он приемлимо работал :)

> Проблема только в том, что всё это есть вложение матрёшек. Когда мощности будет более чем достатчно для исполнения XUL - придумают ещё какой-нибудь фрэймоврк поверх и будем опять огребать торомоза.

Угу.

>> Если присваивание значения переменной атомарно - то да, этого хватит. А если нет, то получите race condition.

> А очерель на что?

Очередь спасает. А что будет без неё, я описал.

>> Не всегда. Например, не пробовали использовать в одном проекте facelets и tomahawk? Интересные варнинги в логи сыпятся. Хотя по отдельности работает без проблем, да и разработчики томагавка клянутся, что он с facelets совместим.

> Ну это что то из явы....

Да. Даже в яве, учитывая, что там нельзя "накакать" в память другой либы. Следовательно, в c конфликт либ может быть опаснее.

>>Другой аргумент в пользу tk: зачем для написания простого гуя использовать тулкит, у которого коммерческая лицензия на одного человека стоит 2 штукобакса?

> qt - он не один, есть ещё gtk ::))

И что, gtk_удобен_в_быстрой_разработке_гуйков() ? Интересно_зачем_тогда_гном_переписывают_на(Lava) ?