"Ночные" сборки KolibriOS

Tue Sep 27, 2011 11:49 pm

Да, есть такое - наблюдал на Qemu. Перерисовывание множества окошек не такая быстрая вещь.
На реальной машине задержка практически незаметна - только что проверил на eBox.

Wed Sep 28, 2011 9:45 am

Mario, текущее решение... неплохо. Оно есть. Но, может быть, не активировать окно вообще?

Wed Sep 28, 2011 10:32 am

По опыту Фантома, могу посоветовать:

- пересобирать систему на сервере автоматом после любой модификации кода, но не чаще раза в час (иначе задолбает)
- после пересбора прогонять регресс-тесты. в фантоме тесты покрывают работу ключевых подсистем ядра (таких, как базовые аллокаторы, контейнеры, примитивы синхронизации и тайминга), части системных вызовов posix, инструкций виртуальной машины и ещё кой-чего по мелочи.
- рассылать на список рассылки итоги сборки и теста

собственно, процедуру автотеста (он, конечно, делается под юниксом на qemu) можно дёрнуть из Фантома, модифицировав под специфику Колибри

Wed Sep 28, 2011 11:35 am

При каждом коммите, который затрагивает программы, входящие в дистрибутив, собирается новый дистр. Логи сборки лежат вместе с дистрибутивом.
Информация о сборке отображается в чате на форуме - самом оперативном средстве общения в проекте.

Fri Sep 30, 2011 1:30 am

Прошу переписать на check_box2 следующие программы: cpu (я пробовал и у меня не вышло), kpack, fasm и другие, если есть. Я поправил только scrnshoot.

Fri Sep 30, 2011 8:12 am

Что угодно, но не CPU. Такая программа должна работать без библиотек.

Fri Sep 30, 2011 11:44 am

Сpu использует старую версию чекбокса check_box, я прошу переписать на новую.

Fri Sep 30, 2011 1:51 pm

Leency wrote:Прошу переписать на check_box2 следующие программы: cpu (я пробовал и у меня не вышло), kpack, fasm и другие, если есть. Я поправил только scrnshoot.

Ничего не надо переписывать. Box_Lib поправлена в ревизии 2249
Однако если еще какое-то приложение использует "checkbox 2", то в таких приложениях нужно исправить флаг.

Fri Sep 30, 2011 1:55 pm

SoUrcerer wrote:Что угодно, но не CPU. Такая программа должна работать без библиотек.

Box_Lib де-факто одна из стандартных библиотек. Ее отсутствие в образе является дурным тоном.
CPU кстати давно уже работает с Box_Lib.

Fri Sep 30, 2011 10:48 pm

Уже не помню с какой ревизии VRR поломан, не хочется быть голословным, но человек это сделавший (Serge? или кто еще видео занимался) должен прояснить зачем так, можно ли починить или нужно убрать из дистрибутива программу и все ссылки на нее.

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

Fri Sep 30, 2011 11:27 pm

Без понятия. Я этот код с 2007 года не трогал.
Imho надо давно выкинуть. Метод потенциально небезопасный для мониторов.

Fri Sep 30, 2011 11:32 pm

Он небезопасный если менять частоту, а если ее сохранять, то вполне себе нормальный.

Fri Sep 30, 2011 11:44 pm

А там по другому не получается. Программировать PLL vmode не умеет. Поэтому если в загрузке было 1024*768 60Гц pixelclock будет 47.2 Мгц(47 185 920). При переходе к 800*600 получим частоту кадров 98Гц. Уже нестандартная частота. Более точно значение считается через VESA GTF, потому что разрешение считается в знакоместах текстового режима (8*16 пикселей). 1024*768 это текстовый режим 128*48.

Sat Oct 01, 2011 6:43 am

Mario wrote:Уже не помню с какой ревизии VRR поломан, не хочется быть голословным, но человек это сделавший (Serge? или кто еще видео занимался) должен прояснить зачем так, можно ли починить или нужно убрать из дистрибутива программу и все ссылки на нее.

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

Скорее всего этот человек я

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

Sat Oct 01, 2011 9:43 am

Может быть запуск программы сломал ты, но вот сам драйвер VRR, который в ядре, не работает в дистрибутиве 0770, а в дистрибутиве 0700 еще работает.

"Ночные" сборки KolibriOS

Who is online