>Дебиан на PPC занимает около 0,00000000000001% парка всех компьютеров

В мире сейчас что-то около миллиарда компов. Правильно ли я понимаю, что Debian/PPC стоит на одной стотысячной одного компа? :)

> У них немного сфера применения разная :)

Да ладно, и то, и то как для десктопных приложений, так и для веба используется. Ну, с Tk я загнул, эт да

> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed

Так это ж боян, для новых иксов надо патчить жабобинарник sed'ом.. А то и java-плагин для браузеров толком не пашет

>Так это ж боян, для новых иксов надо патчить жабобинарник sed'ом..

Eclipse/Sancho прекрасно работают.

Но погуглю на эту тему.

Гы. Помогло

sed -i 's/XINERAMA/FAKEEXTN/g' /usr/lib/jvm/sun-jdk-1.6/jre/lib/i386/xawt/libmawt.so

Но продукт не понравился. Да, GUI можно включить GTK-шный, но смотрится ужасно (метрика виджетов, кажется, не вписывается), интерфейс кривой какой-то... Это ни в малейшей степени не замена Tombo, скорее - худшая альтернатива Basket'у :)

Гик... Чудо... Тебе ПРЯМО говорят: нефиг юзать ЧИСТО сименсовские классы. Если пользоваться только стандартными возможностями, без привлечения всяческих сторонних девиаций от разработчиков данного конкретного железа - то и запускается, и графика рисуется и звуки звучат.

> ... и запускается, и графика рисуется и звуки звучат.

Но ме-е-едле-е-енно-о-о-о....

1. Не кто не спорит, что Жаба уже не есть труЪ. Это уже не популярно и очень даже тормознуто, кросплатформенность жабы ф топку (очень убогая имплементация).

2. МС больше не будет поддерживать Вынь32 и ОЛЕ в следующих версиях Вынь.(прошерстите свою полку по поводу растопки печки). Они настолько запутались в своем ядре, что лепет насчет толстопузости ядра линукса здесь можно даже не рассаматривать.

3. Из п.2 следует, что Вынь разработчики хотят защитить свои разработки, т.е. у них есть прямое желание о полной совместимости МОНО и НЕТ.

4. Каждый, кто не дурак выводы сделает сам.

>Всад, Java есть и хватит извращений.

Ф топку гадкое поделие САН.

Насколько на очнь люблю TCL, но у них есть загрузка функций либ через таблицу функций (т.е. даже версию либы под 8.1 можно подключить без перкомпиляции).

Насколько я ругаю Пайтон (мой любимый язык), за излишнюю свободу С++ до него уже никогда не достать в концепциях ООП (не смотри скорость, критика правиться через C-либы или через PyBindGen).

Почему этих прекрасных языков нет в НЕТ??? Тем более сущкствуют PyQt, PyWidgets,PyGtk, Tk в уонце концов?

МС не хчит фрии в НЕТе, а как в этом плане МОНО?

питон ООП-шнее плюсов

> Насколько я ругаю Пайтон (мой любимый язык), за излишнюю свободу С++ до него уже никогда не достать в концепциях ООП

Ну-ка примеры ООП на питоне, невозможное в плюсах? Не столько ради флейма -- а вдруг и правда в питоне че-то крутое могут, а я не знаю???

>>Дебиан на PPC занимает около 0,00000000000001% парка всех компьютеров

>В мире сейчас что-то около миллиарда компов. Правильно ли я понимаю, что Debian/PPC стоит на одной стотысячной одного компа? :)

Крон, ты ошибся :-) Если в мире около миллиарда компов, то наимудрейший сообщил нам, что Debian/PPC стоит на одной десятимиллионной доле одного компа :-)

>> Вот то, что в сишарпе, допустим, eval-а нет -- вот это уже хуже

>"А мужики-то и не знают!" :)

>Вы удавитесь, узнав, что их там ШЕСТЬ ТИПОВ! >http://www.rsdn.ru/article/dotnet/codegen.xml

В статье рассказывается о том, как покрасивее оформить код, подаваемый на вход компилятору С шарп. В качестве эталона красоты предлагается XML :-) Как на самом С шарп написать куски под-эвального выражения (делегаты например) -- не рассматривается.

Особенно восхитил следующий метод реализации eval -- пристегните ремни!!! -- поставить IIS и создавать HTTP-запрос к ASP.NET-странице!!!

Короче я сочувствую gaa... вместо того, чтобы прочитать чуток внимательнее и полчаса валяться под столом от смеха, он всего лишь увидел что предлагаемые в статье методы немного длиннее tcl/tk-шного eval-a :-)

А matumba надо беречь... где теперь найдешь такого пионера, чтобы он служил неиссякамым источником здорового юмора?

> Вот то, что в сишарпе, допустим, eval-а нет -- вот это уже хуже

Скорее всего то, для чего тебя тянет юзать ивал -- достигается через делегаты. Давай пример когда хочется ивал, объясню как. Кстати, если нароешь вдруг пример когда нужен чистый ивал -- мне будет интересно.

И еще. Хватить говорить "в С++ нет рефлексии" -- не надо обманывать других -- надо говорить "в С++ нет рефлексии, стандартизированной ISO", раз уж ты такой привередливый.

Ладно, уговорили, во втором приближении пусть будет 0,0000001% :)

> Ладно, уговорили, во втором приближении пусть будет 0,0000001% :)

Ты нолики считать умеешь?

0,0000001% * 1Г компьютеров = 1 (один) компьютер

> Почему же тогда у меня под вендой Mono проги не работают? Mono же кроссплатформенно!?

Mono - да. Программы - нет. Я кажется уже писал по этому поводу на счёт разницы между .Net и Java.

> 1. Не кто не спорит, что Жаба уже не есть труЪ. Это уже не популярно и очень даже тормознуто

Довод к публике.

> , кросплатформенность жабы ф топку (очень убогая имплементация).

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

> 3. Из п.2 следует, что Вынь разработчики хотят защитить свои разработки, т.е. у них есть прямое желание о полной совместимости МОНО и НЕТ.

O_o. Я где-то пропустил два десятка логических звеньев?

>> Вот то, что в сишарпе, допустим, eval-а нет -- вот это уже хуже

>"А мужики-то и не знают!" :)

>Вы удавитесь, узнав, что их там ШЕСТЬ ТИПОВ! >http://www.rsdn.ru/article/dotnet/codegen.xml

www_linux_org_ru> В статье рассказывается о том, как покрасивее оформить код, подаваемый на вход компилятору С шарп.

Слышь, трепло ленивое, ты хоть бы пару параграфов прочёл, да? Генерация есть вплоть до IL кода! Т.е. ваши eval'ы не дотягивают по гибкости с тем, что можно сгенерировать динамически под .NET (причём ИЗ ЛЮБОГО языка).

Вы чем дальше пишете, тем больше у меня складывается мнение, что дальше .NET 1.1 и студии 2003 вы не лазили. Причём обсираете с такой уверенностью, будто на Линукс есть хотя бы что-то сопоставимое! Смешно, да и только. Подожду лет 5, может на линуксе появится аналог хотя бы Дельфы...

>Подожду лет 5, может на линуксе появится аналог хотя бы Дельфы...

Искренне желаю, чтобы вы этого не дождались. Но, увы оно уже есть 8(.

Чтото на официальном сайте только RC1 лежит?

> может на линуксе появится аналог хотя бы Дельфы...

Ты про Kylix? xDDD

Правда, хвала всевышнему, _такое_ просто не востребовано, и, дай бох, и дальше не будет..

http://ru.wikipedia.org/wiki/Lazarus

> Понятие «тормозит» - сугубо субъективно

Наоборот, объективно. Гуй тормозит, по определению, если через 1/25 секунды после нажатия кнопки изображение на нём не поменялось.

> Насколько на очнь люблю TCL, но у них есть загрузка функций либ через таблицу функций (т.е. даже версию либы под 8.1 можно подключить без перкомпиляции).

А почему тогда не работает BLT, написанный под tcl8.4, под tcl8.5?

> Короче я сочувствую gaa... вместо того, чтобы прочитать чуток внимательнее и полчаса валяться под столом от смеха, он всего лишь увидел что предлагаемые в статье методы немного длиннее tcl/tk-шного eval-a :-)

Спасибо за указку, почитаю внимательнее :)

>> Вот то, что в сишарпе, допустим, eval-а нет -- вот это уже хуже

> Скорее всего то, для чего тебя тянет юзать ивал -- достигается через делегаты. Давай пример когда хочется ивал, объясню как. Кстати, если нароешь вдруг пример когда нужен чистый ивал -- мне будет интересно.

Скачай tkLOR или tkpaint и посмотри как там проходит, соответственно, сохранение/загрузка настроек и файлов .pic. Копипастить неохота.

> И еще. Хватить говорить "в С++ нет рефлексии" -- не надо обманывать других -- надо говорить "в С++ нет рефлексии, стандартизированной ISO", раз уж ты такой привередливый.

Да. Но зачем разводить демагогию? На C++ можно сделать что угодно, поэтому весь вопрос _только_ в удобстве использования.

> Генерация есть вплоть до IL кода! Т.е. ваши eval'ы не дотягивают по гибкости с тем, что можно сгенерировать динамически под .NET (причём ИЗ ЛЮБОГО языка).

Ты смешон. Ты даже не потрудился узнать, что ж делает eval.

Кстати, как мне из tcl сгенерировать IL-код? Оправдывай слова "из любого языка" :)

>Гуй тормозит, по определению, если через 1/25 секунды после нажатия кнопки изображение на нём не поменялось.

Я и говорю - субъективно. Ибо для тебя - так. Для меня - через 1/10 секунды. Для многих тут - и 1/2 секунды - ещё не тормозит :D

>> Гуй тормозит, по определению, если через 1/25 секунды после нажатия кнопки изображение на нём не поменялось.

> Я и говорю - субъективно. Ибо для тебя - так. Для меня - через 1/10 секунды. Для многих тут - и 1/2 секунды - ещё не тормозит :D

Вспоминаем, сколько кадров в секунду считается нормальным даже для самых динамичных фильмов и видим, что 1/24(а не 1/25, как я раньше описАлся) -- не с потолка взятое число :)

Про это чудо я начисто позабыл.

> Причём обсираете с такой уверенностью, будто на Линукс есть хотя бы что-то сопоставимое! Смешно, да и только. Подожду лет 5, может на линуксе появится аналог хотя бы Дельфы...

Кто тут насчет "морей" языков и 20% продуктивности распинался ?

Никому тут не нужна "Дельфа", от которой даже Борланд и тот собирается отказываться. Так что не дождешься :-)

Если тебе нужно "сказочно" рисовать формочки и кнопочки, то инструментария навалом (GTK+/Qt). Если не удосужился найти и ознакомиться, нефиг волны в лужах поднимать.

> Вспоминаем, сколько кадров в секунду считается нормальным даже для самых динамичных фильмов

Не "нормальным", а минимально необходимым, чтобы глаз не замечал рывков. А потом еще вспоминаем, сколько фпс должна выдавать игра для комфортной игры, и правим цифры на правильные.

>> Вспоминаем, сколько кадров в секунду считается нормальным даже для самых динамичных фильмов

> Не "нормальным", а минимально необходимым, чтобы глаз не замечал рывков.

Слушай, одолжи глаза, которые воспринимают 100 кадров в секунду. Мне ненадолго :)

> А потом еще вспоминаем, сколько фпс должна выдавать игра для комфортной игры, и правим цифры на правильные.

Геймер детектед. Разговор можно не продолжать.

Во всяких учебниках по юзабилити отталкиваются от цифры 0.1 c. Это результат статистических исследований на обычных пользователях. Если больше, то они жалуются, что тормозит.

Естественно, что если время отклика меньше, то это хорошо, но ниже 0.1 с неприемлемо.

>Вспоминаем, сколько кадров в секунду считается нормальным даже для самых динамичных фильмов

- Скорость реакции человеческого глаза несопоставимо выше, чем 1/24 сек. Ты, между прочим, способен видеть электрическую искру, длительность которой составляет от микросекунд до миллисекунд.

- 24 кадра в кино - это минимальная частота, с которой человек перестаёт раздельно различать мгновенно сменяющиеся картинки, получая иллюзию непрерывного изменения процесса.

- Наконец, время человеческой реакции на изменение - это ~0.1сек. Всё, что _полностью_ отрисовывается за это время - объективно не тормозит. Ты нажал кнопку, пока осознал произошедшее изменение - процесс завершился. Если больше - ты уже успеваешь заметить изменение и осознать процесс. Считать ли наблюдение процесса изменения тормозами или нет - это уже субъективное :)

...

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

Поэтому субъективно Nautilus в Gnome в каталог заходит быстрее, чем Konqueror. Первый сперва проводит все отрисовки в бэкграунде и потом только мгновенно меняет картинку, а второй - рисует изменения по ходу, папочка за папочкой, файл за файлом. Поэтому субъективно он кажется медленнее. Если бы Nautilus ещё не очищал поле каталога перед входом, а только перед отрисовкой - субъективно он бы был вообще реактивным :D

В смысле больше 0.1 с :-)

>Не "нормальным", а минимально необходимым, чтобы глаз не замечал рывков. А потом еще вспоминаем, сколько фпс должна выдавать игра для комфортной игры, и правим цифры на правильные.

Тут фишка ещё в том, что в кино мы имеем естественный «блюр». Во время экспозиции кадра, движущийся объект «размазывается» по плёнке. Реальный объект оставляет на сетчатке размазанное остаточное возбуждение. «Заблюренный» кадр плёнки создаёт аналогичный эффект. А вот в игре каждый кадр - статичный, объекты не размазаны. Поэтому, чтобы создать иллюзию непрерывного движения, число кадров в секунду должно быть заметно выше. Комфорт начинается от 50..60 к/с.

>Слушай, одолжи глаза, которые воспринимают 100 кадров в секунду. Мне ненадолго :)

Любой человек с нормальным зрением отличает 75Гц развёртку ЭЛТ-монитора от 100Гц :) Не в герцах, конечно, а в том, что при 75Гц присутствует ещё едва заметное мерцание :)

...

А вот одиночный кадр длительность 1/100 сек мы способны воспринять легко. См. тот же пример электрической искры :)

...

Кстати, фотовспышка даёт импульс обычно ~1/1000 сек. Ты видишь вспышку? :D

>Во всяких учебниках по юзабилити отталкиваются от цифры 0.1 c. Это результат статистических исследований на обычных пользователях. Если больше, то они жалуются, что тормозит.

Тут и без пользователей, это цифры из физиологии позапрошлого ещё века. Время осознания процесса - от 0.1 сек. Время реакции (т.е. нажать кнопку по сигналу) в алертном состоянии - 0.2 .. 0.3 сек.

> - Скорость реакции человеческого глаза несопоставимо выше, чем 1/24 сек. Ты, между прочим, способен видеть электрическую искру, длительность которой составляет от микросекунд до миллисекунд.

А вот две вспышки я не различу.

> - 24 кадра в кино - это минимальная частота, с которой человек перестаёт раздельно различать мгновенно сменяющиеся картинки, получая иллюзию непрерывного изменения процесса.

Угумс.

> - Наконец, время человеческой реакции на изменение - это ~0.1сек. Всё, что _полностью_ отрисовывается за это время - объективно не тормозит. Ты нажал кнопку, пока осознал произошедшее изменение - процесс завершился. Если больше - ты уже успеваешь заметить изменение и осознать процесс. Считать ли наблюдение процесса изменения тормозами или нет - это уже субъективное :)

"наблюдение процесса изменения" можно считать тормозами программы, а не ей графического интерфейса. Вот когда функционально _тормозной_ эклипс сохраняет настройки полминуты, но при этом _мгновенно_ показывает окошко "подожди, думаю" -- гуй у него тормозным назвать нельзя.

> Поэтому субъективно Nautilus в Gnome в каталог заходит быстрее, чем Konqueror. Первый сперва проводит все отрисовки в бэкграунде и потом только мгновенно меняет картинку, а второй - рисует изменения по ходу, папочка за папочкой, файл за файлом. Поэтому субъективно он кажется медленнее. Если бы Nautilus ещё не очищал поле каталога перед входом, а только перед отрисовкой - субъективно он бы был вообще реактивным :D

Да, вот в чём вся фишка! Хотя, если после нажатия Enter и до появления картинки пройдёт много времени, то никакая быстрая отрисовка с двойной буферизацией не спасёт :)

>> Слушай, одолжи глаза, которые воспринимают 100 кадров в секунду. Мне ненадолго :)

> Любой человек с нормальным зрением отличает 75Гц развёртку ЭЛТ-монитора от 100Гц :) Не в герцах, конечно, а в том, что при 75Гц присутствует ещё едва заметное мерцание :)

Тут дело не в количестве кадров, а в способе отрисовки. Если б кадры менялись _мгновенно_, то никто б не различил.

> А вот одиночный кадр длительность 1/100 сек мы способны воспринять легко. См. тот же пример электрической искры :)

См. ответ про две последовательных искры за один промежуток.

> Причём обсираете с такой уверенностью, будто на Линукс есть хотя бы что-то сопоставимое!

Ну ты ж линукс обсираешь, ни хрена в нём не разбираясь. Чем мы хуже?

> Тут и без пользователей, это цифры из физиологии позапрошлого ещё века. Время осознания процесса - от 0.1 сек. Время реакции (т.е. нажать кнопку по сигналу) в алертном состоянии - 0.2 .. 0.3 сек.

Проводил опыты над собой с помощью секундомера: нажать кнопку "старт", а потом сразу же её же для остановки. Минимальное время -- 0.12 секунды. Хотя иногда успевал заметить мелькание цифры 0.09

>> Причём обсираете с такой уверенностью, будто на Линукс есть хотя бы что-то сопоставимое!

> Ну ты ж линукс обсираешь, ни хрена в нём не разбираясь. Чем мы хуже?

Мы -- лучше. Среди нас есть те, кто той самой студией, пусть и бородатой 2005 версией пользовались :)

> Геймер детектед. Разговор можно не продолжать.

Argumentum ad personam. Слив засчитан.

>А вот две вспышки я не различу.

А речь не о различении двух вспышек с интервалом в 1/1000-ю :)

>"наблюдение процесса изменения" можно считать тормозами программы, а не ей графического интерфейса. Вот когда функционально _тормозной_ эклипс сохраняет настройки полминуты, но при этом _мгновенно_ показывает окошко "подожди, думаю" -- гуй у него тормозным назвать нельзя.

Ладно, вопрос тормозов GUI в Eclipse с повестки дня снят :D Справедливости ради я не работал в нём с прошлой весны. Сейчас запустил - GUI работает шустро. В апреле снова предстоит много в нём работать, увижу тормоза - снова подниму тему. Нет - значит в отношении Eclipse был не прав :D

>Хотя, если после нажатия Enter и до появления картинки пройдёт много времени, то никакая быстрая отрисовка с двойной буферизацией не спасёт :)

Да, безусловно речь идёт о пресловутых 0,1 - 0,3 сек. Если рисоваться будет дольше - то тормоза не скроешь уже ничем :D

>Если б кадры менялись _мгновенно_, то никто б не различил.

100 от 75 - да. А вот 30 от 60 в движении отличаются ещё уверенно :) А вот, скажем, 40 от 60 - я бы уже не взялся уверенно отличить, тут начинаются субъективные тонкости восприятия. Естественно, это я в контексте «неблюренных» картинок.

>Проводил опыты над собой с помощью секундомера: нажать кнопку "старт", а потом сразу же её же для остановки. Минимальное время -- 0.12 секунды.

Это не тот опыт :) Ты из мозга шлёшь два сигнала, второй не является реакцией на первый. Тут ты фактически измеряешь скорость работы мышцы пальца :) Кстати, 0.12 - это много, человек легко и меньше 1/10 выдаст.

А вот получить сигнал, проанализировать его и отдать команду пальцу - это совсем другое дело. Время реакции тут колеблется от ~0.25 сек (алертное состояние, известная мозгу и ожидаемая ситуация) до бесконечности :) (см. пример буриданова осла)

Минимальное время полной активной реакции нетренированного человека вообще до 0.6 сек, ЕМНИП, доходит.

> Ладно, вопрос тормозов GUI в Eclipse с повестки дня снят :D Справедливости ради я не работал в нём с прошлой весны.

А я вот прям сейчас работаю. В том месте, в котором я описал он не тормозит. Зато тормозит мног где ещё(хотя можёт всё из-за того,что я переключаюсь на файрфокс и винда его вгоняет в своп).

> Сейчас запустил - GUI работает шустро.

По сравнению с 3.3, 3.2 кажется просто реактивным :)

> В апреле снова предстоит много в нём работать, увижу тормоза - снова подниму тему. Нет - значит в отношении Eclipse был не прав :D

Увидишь, гарантирую :)

> Кстати, 0.12 - это много, человек легко и меньше 1/10 выдаст.

> Время реакции тут колеблется от ~0.25 сек (алертное состояние, известная мозгу и ожидаемая ситуация) до бесконечности :)

> Минимальное время полной активной реакции нетренированного человека вообще до 0.6 сек, ЕМНИП, доходит.

Ну вот, всё же моя 1/24 тут вполне укладывается :)