OberonCore

Немного недопонял, когда это мы успели сделать "BlackBox", чтобы его распространять?

Представляю себе следующее:
1) Публикуется отдельно: платформонезависимый пакет с исходниками --- набор компонентов, обеспечивающих работу каркаса в консоли (суть подсистема Cons). Плюс особые примеры, которые не Obx (этим в базовом пакете место только в виде списка --- какие работают). Функционировать консольный каркас должен параллельно гуйному, из того же каталога. Поэтому пересечений в именах компонентов, реализующих затычки, быть не должно. Всё собирается по инструкции Quick-Start, компиляция, пускач консольного каркаса, например ConsBlackBox.exe --- последний собирается под конкретную ОС, но из одноимённых модулей (крайне желательно обеспечить).

2) Реализуются ОС-зависимые части каркаса, для чего получится:
* Linux
* OpenBSD
...
* Win (уже есть)
Штука консольного каркаса в том, что он требует много меньше ОС-зависимых модулей. Тут получается по набору на каждую ОС, объединив (копированием) любой из пакетов с (1) получаем консольный вариант ББ под нужную ОС.

Нужно ли распространять такие наборы отдельно --- вопрос (как их собирать из исходников).

3) Публикуются консольные пакеты ББ под разные ОС в собранном (1)+(2*) и готовом для работы виде. Как простые архивы (с инструкцией по разворачиванию, если там будет что-то сложнее "распаковал и запустил из той же папки" --- чего надо всеми силами постараться избежать).

Это главное --- обеспечивает среду выполнения для любого компонента.

Прочее:
1) Реализации всяких компонентов под Linux и пр., если реализации ОС-зависимые. Пример: CommStreams, Sql. Каждая реализация --- суть отдельный проект --- публикуем в коллекции компонентов отдельно, народ выбирает. К данному проекту отношение имеет только в том, что среди уже имеющихся наработок есть что опубликовать для линуха.
2) Всякие более специфические сборки --- это уже у кого на что фантазии хватит. Например, Иван может сделать сборку-HTTP-сервер для линуха. К данному проекту отношения не имеют.
3) "Инсталляторы" --- для линуха --- .deb, .rmp --- это суть архив (3) + некоторая стандартная схема размещения стандартного пускача и компонентов. К проекту имеет отношение как дополнительный, удобный для пользователей, способ распространения. Сделать нужно, но задача второстепенная.

С .deb Борис разбирался, на сколько подробно --- не знаю. Знаю, что их делал чтобы облегчить себе настройку аудитории для лабораторных.

Всё, теперь понял.

Докладываю:
* Почти все материалы из ert-dev оформил. Остались только LinDatedLog и правки к LinTCP и LinSockets.
* Описание схемы сборки дополнил описанием сборки с дин. загрузкой модулей. Не думаю, что вышло идеально, но на крайний случай сойдёт как есть.

В принципе, можно готовиться к публикации первого пакета (аналог LinSimpleConsole --- содержащего только ядро, Log и допускающего только кросс-разработку из винББ, т.к. консольные средства разработки могут появиться только на втором этапе с затычками, etc.).

Для начала нужно синхронизироваться с правками Александра для Kernel. Тут мне уже известны два расхождения:
1) LinErrno. Данный модуль получился в результате формального перевода заголовка (подробности см. дельту). Математик я. Если имеются убедительные доказательства, что замена errno на функцию есть будущее, а переменная --- отживший век, то без сомнения, лучше от этого лишнего модуля избавиться.
2) Реализация ЕИЕ Kernel.IsReadable. Александр говорил, что там дескать что-то некорректно, не работает. Где и как? На Ubuntu тест и на Си и на ББ работал как в 2009, так и сейчас. Разница в том, что в 2009 помню (а надо было копии выдачи делать) что были несколько (единицы или десятки) страниц с результатами ~readable & readed/readable & ~readed.
3) Про обработку переполнения стэка Александр недавно сказал, что выявились проблемы. Включать с проблемами или лучше не включать вовсе?

Linux Fedora Core 4 ("старый" Linux):

Linux Fedora Core 17 ("новый" Linux):

Кроме того, errno не всегда работает (даже ести он есть в libc.so.6), а __errno_location всегда (см. здесь и OpenBUGS).



Fedora Core 17:

=> Ok

OpenBSD:

=> не работает


Лучше не включать.

Надо полагать, эта функция в OpenBSD не поддерживается. Где герои, найти и прочитать документацию? Мне пока не охота.

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

Добавил инструкцию по разворачиванию работы методом временной подмены файлов.

Добавил инструкцию по сборке blackbox первым методом. Настаиваю, чтобы этот метод был включен в публикацию наряду со вторым (.so) методом.

Довил Init как пример использования сборки и файлы для его коректной работы (Math и т.п.).

Добавил tcp модуль от Trurl.

(модератор) перенесено: viewtopic.php?p=75514#p75514

Большая просьба убрать везде из документации по развертке "ert0devCommanders", где без него можно обойтись.

Не уверен, что нужен модуль LinErrno, посмотрите LinLibc_elf и Kernel_elf — функции LinErrno встроены в них. Чем меньше модулей, тем лучше.

Перенес свою инструкцию в Lin/Docu/Console-Quick-Start.odc

Что хочу сейчас сделать, слить LinLibc LinLog избавиться от LinErrno.

По ядрам быстро не получится утрясти, поэтому предлагаю все версии опубликовать. Сейчас два штатных
- одно документированное Евгением для второго метода с (.so);
- одно из OpenBUGS322 с управлением памятью от Александра Ширяева для первого метода запуска без (.so).

Запуск будет только в одном варианте: пустышка + .so. Уже обсуждалось и зафиксировано.
--
Нда. Свалка ещё та вышла. Теперь вместо работы, придётся чистить.

Прошу ничего не удалять лишнего, чтобы не помешало работе первого метода с моим примером в Init. Я тоже работал сейчас и потратил 5 часов времени, не включая сколько потратил времени до этого и Александр на доработку ядра. Прошу такие колкости оставлять при себе впредь.

Всё, что выходит за пределы разработки, типа ОС-независимых модулей каркаса, будет удалено. Учитесь работать в серверной конфигурации. Или копируйте на месте. В хранилище не должно храниться файлов только ради удобства.

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

Это уже вопрос к тому, кто Вам дал материалы.

На собрании же принято конкретное решение. И к Вашим действиям оно отношения не имеет.

Документация там тоже для удобства. Мне важно, чтобы работали примеры. Почему удобство надо все время задвигать на последнее место. Потом кроме нескольких человек вообще никто не сможет развернуть среду.

ок, обсудим.

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

В общем, мне это обсуждать надоело.

Вместо того, чтобы выложить результаты анализа в виде дельт, сделана свалка в виде кучи разных версий ядра. Сравнивать мне? Так я бы и так сравнил, без того, чтобы они валялись в хранилище, в папках из которых формируется пакет.

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

Как и план по этапам публикации пакета.

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

Устал я. Итак на работе свалилось куча всего, теперь ещё и тут разгребать. Извиняйте, пойду в более спокойное место.

Не вижу никакой связи между внезапно устроенной, безсистемной, вопреки всем обсуждениям, свалкой и работой Александра.

P.S. На формулирование предложений по этим обсуждениям потратил, боюсь, более 5 часов.

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

Приношу извинения, Иван Андреевич, Вам и всем, кого задел резкими и недопустимыми словами.

Итого, на данный момент:
1) 14.09.2012 озвучен общий план подготовки пакета, с которым суть все согласились (возражений не было; исключение: возражения тов. Денисова, появившиеся 18.10).
2) На форуме обсуждаются технические вопросы, возникающие в процессе формирования пакета.
3) Тов. Темиргалеев предложил определённую схему коллективной работы. Без сомнения, схема не претендует на объективность подхода; её обоснованность, понятность и мотивированность для других товарищей спорна. Суть же в том, что никто явно не высказался ни против схемы, ни против коллективной работы, ни внёс альтернативных предложений по организации, ни задал вопросов по непонятным моментам предложенной схемы.
4) С 20.09 по 18.10 шла "коллективная" работа в отдельно оговорённом коллективном репозитории:
(соответствия плану и проч. ниже суть субъективная оценка тов. Темиргалеева)
- 20.09 тов. Денисов сформировал ветку master, наполнив её материалами, которые не вязались ни с планом, ни с предложенной схемой коллективной работы;
- 21.09 тов. Темиргалеев создал отдельную чистую ветку LinConsole, где работал с 21.09-18.10 по плану и схеме;
- 25.09 тов. Денисов сделал ветку LinConsole главной (master);
- 18.10 тов. Денисов подключился к работе и без каких-либо предложений и согласований наполнил ветку master материалами, которые не вяжутся ни с планом, ни со схемой.
5) Тов. Ширяев работал в своём отдельном репозитории, участвуя только в обсуждениях.

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

Тов. Темиргалеев ради более продуктивной работы переезжает в svn-хранилище bb-lin oberoncore.