Board.KolibriOS.org

Mario_r4 wrote:

Kopa wrote:Какие варианты фиксации произошедшего могут быть задействованы в Kolibri в данной ситуации?

Сначала надо определить проблемную ревизию, условия повторения и не является ли это аппаратной проблемой (ну, там коннектор у памяти окислился или еще чего).

ХЗ. Может что и окислилось, но так явно встретил только в описанном случае.

P.S. Используя Web браузер Haiku OS замечаю разной степенью глюки в процедурах регистрации и захода на какие то ресурсы i-neta. Браузер (система) выдаёт сообщение о завершении и возможности записать баг репорт. Есть ли какая то корреляция и с вышеописанным случаем или это "внутренняя нестабильность" данной ОС тоже непонятно.
Можно было бы публиковать и эти репорты данной ОС в форуме проекта Kolibri OS если был бы какой то смысл в этом.
Новые сборки Haiku OS тоже периодически обновляю, но те или иные глюки в ней всплывают с "постоянной периодичностью".
Использую в основном из-за браузера т.к. поддержана сетевая карта, видекарта и разных SVN, CVS, GIT клиентов для обновления интересных мне репозитариев программных проектов.
Пробовал упаковывать/распаковывать репозитарий Kolibri проекта. в ней. Так вот архивирование по времени ещё терпимо, а разархивация лучше сразу "убиться" или уйти "гулять" как по времени так и по загрузке процессора (хотя вроде интенсивно используется для этого ОЗУ -1Гб)

SVN r.4631 viewtopic.php?f=44&t=1598&start=44 программа KFM более не использует ф.18.11, если нет других программ использующих эту функцию, то можно удалить ее из API. В ядре еще требуется проделать некоторый немалый объем работы, чтобы убрать зависимость от старой модели формирования списка устройств (например, допилить весь код работы с ATAPI).

SVN r.4641 - функцию 18.11.2 удалил из API ядра. Функция 18.11.1 пока остается на всякий случай. Также уменьшил размер области DRIVE_DATA до 10 байт, поскольку все что выше уже давно не используется. Итого экономия ОЗУ более 6 КБ.

EDIT by yogev_ezra: Обсуждение авто-сборки вынесено из приватной темы, так как оно касается всех участников.

В свете последних событий с желанием добавить в авто-сборку все ЯВУ программы (NetSurf, uPDF, ...) хотелось бы заметить, что... с точки зрения эффективности использования сервера тяжелые проекты должны бы собираться вручную, на машинах самих программистов.

Я вообще против автосборки тяжёлых проектов в нынешнем виде. Сейчас это пустая трата ресурсов.

Пожалуйста, не надо обращать внимание на "трату ресурсов". У меня есть куда более мощный сервер для автосборки если потребуется, так что я считаю, что в автосборке должно быть всё, что есть. Кроме того, всегда есть возможность собирать в рамдиске, а это быстро.

XVilka
Отлично.
Тогда моё предложение. Я соберу тулчайн gcc + binutils для линукс и для win32 msys, чтобы все использовали одинаковую версию компилятора и библиотек. Потому что сейчас кто в лес, кто по дрова, но мне нужен путь sysroot для конфигурирования.

Ок, вечером напишу всё в подробностях.

Serge wrote:Я вообще против автосборки тяжёлых проектов в нынешнем виде. Сейчас это пустая трата ресурсов.

Если авто-сборка программ на C--/C/C++ работает так же, как и авто-сборка программ на FASM, то пересобираться должны только те программы, у которых изменился какой-либо файл, что происходит далеко не в каждой ревизии (некоторые программы по 1,000-2,000 ревизий не изменяются вообще). Или я не прав?

yogev_ezra
В идеале да. А на практике у сишных файлов масса инклюдов, зависимость .o от Makefile в большинсте случаев и т.д. Всё HLL для Колибри в очень сыром и неустойчивом состоянии. Поэтому вариант "я тут изменил пару .h файлов, поэтому лучше всё перекомпилировать" будет не раз и не два.

Serge wrote:yogev_ezra
В идеале да. А на практике у сишных файлов масса инклюдов, зависимость .o от Makefile в большинсте случаев и т.д. Всё HLL для Колибри в очень сыром и неустойчивом состоянии. Поэтому вариант "я тут изменил пару .h файлов, поэтому лучше всё перекомпилировать" будет не раз и не два.

Тогда сборку программ на C/C++ можно сделать асинхронной и не зависящей от post-commit hook. Все проекты на C/C++ с CI-системами (Continuous Integration) должны так и делать в теории, иначе бы у них никто уже не коммитил (задолбались бы ждать ответа от post-commit hook).

yogev_ezra
Хорошо бы. По моим впечатлениям одна сборка 3D драйвера для AMD будет сложнее, чем сборка всего что сейчас есть на svn. Вообще всего, не только в автосборке.

Serge: /home/autobuild/tools/win32 - для mingw и /home/autobuild/tools/32 - для linux gcc

XVilka
Система 64 бита ?

Serge: да.