OberonCore

кстати, не получаются. Oberon → Oberon-2 → Oberon-07, например. ;-) хотя O7, пожалуй, уже другой язык на базе оригинального оберона, просто Вирт как обычно поленился имя менять.

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

и раз уж речь о системе зашла, чтобы два раза не вставать: я склоняюсь к мысли прибить гвоздями и размер POINTER'а. тоже четыре байта. технически в обероне всё равно это скорее HANDLE, нежели POINTER. а для общения с системой ввести тип native pointer, размер которого как раз зависит от архитектуры. хочется работать со всей памятью напрямую — импортируем SYSTEM, кастуем обероновский указатель в нативный, и делаем что хотим.

да, это ограничивает доступную процессу память в четыре гига даже на 64-битных системах. меня устраивает. если устраивать не будет — я сделаю диалект Ultra Pascal 64, где это поменяю. на практике задачи, где нужно больше четырёх гб памяти — это очень специализированые задачи, под которые всё равно надо будет делать отдельный рантайм (и, скорее всего, новый GC, без stop-the-world, а к нему компилятор с барьерами), и там мало пользы от полной среды BBCB. BBCB же можно традиционно использовать как среду кросс-разработки таких монстров.

зато чёткое определение размера указателя снимает вообще все проблемы с портированием BBCB куда угодно: мы можем спокойно перекрашивать указатели в INTEGER и обратно (увы, такого кода в BBCB весьма немало). на 64-бит системе просто зарезервируем четыре гб адресного пространства и будем трактовать обероновские указатели как смещения от начала этой области. первые 64 кб традиционно мапить не будем — и получим традиционный же сегфолт при разыменовании NIL. заботу о рихтовании указателей берёт на себя компилятор: ну, будет не `MOV EAX, [someptr]`, а `MOV EAX, [someptr + REGBASE]`. там регистров много, один выделим для хранения базы, подумаешь. или просто сразу все `someptr` починим при загрузке модуля (всё равно они и сейчас чинятся).

Ultra Pascal 64 - мы только за.

Размер POINTER в 4 байта недостаточен для программ xDelta и аналогов.
В самом крайнем случае, примите размер унифированного указателя за 48 bit.
Так в PAE и большинстве систем с x64.

видите ли, в чём дело… лично мне 32 бита хватает на все мои задачи. вдобавок код BlackBox активно красит указатели в целые и обратно. если я прибью гвоздями размер указателя в 32 бита — мне ничего больше делать не надо. а если больше — то придётся кучу кода (не только BBCB) переделывать, чтобы работал. а он и так уже работает. в принципе, для меня выбор очевиден. ;-)

и есть аргумент ещё более важный: GC в BBCB тупо не справится. в смысле, работать-то будет, но тормозить начнёт адово. какой смысл иметь возможность адресовать кучу памяти, если при попытке её штатно использовать система начнёт тормозить так, что любая операция, вызывающая сборку мусора, залипает на десятки, сотни, а то и больше миллисекунд? получится обман: вроде бы теоретически система может, а на практике смысла нет.

если у вас, предположим, ось на 64 бита — то никто не мешает выделять там память напрямую, системными средствами, и работать с ней через native pointer. это будут специфические задачи, которые так или иначе потребуют специфического кода, чтобы ворочать такими объёмами данных.

поэтому я считаю, что нет никакого смысла иметь размер указателей на объекты под управлением ящика больше, чем 32 бита. это раз и навсегда решает все проблемы с портируемостью, и этого совершенно достаточно для решения практических задач.

кстати, указатели в 32 бита засоряют процессорные кэши в два раза меньше, чем указатели в 64 бита. забавный эффект от этого я наблюдал на практике: некоторый мой софт на x86_64 работал медленней, чем у меня на просто x86. при том, что процессор на 64-битных тестах был быстрее. хотя казалось бы: и регистров больше, и камень мощнее… но специфика кода, который активно с указателями работает (а потому хранит в структурах много указателей). в итоге приходим к тому, что если у нас много указателей — то дешевле делать их в 32 бита, и трактовать как смещения от некоторой области памяти… то есть, ровно то, что я и хочу сделать в BBCB.

p.s.: собственно, например, в переделке TextModels, которую я рано или поздно закончу, деревья для хранения кусочков текста выделяются как раз мимо BBCB, прямым запросом страниц у системы. как раз затем, чтобы не нагружать GC бессмысленной работой. это, конечно, открывает небольшую баночку червей и требует внимательности в коде (надо отдельно якорить некоторые объекты, и руками отслеживать моменты освобождения), зато даже порубаный на маленькие спаны текст систему не тормозит (а с GC тормозит, и очень ощутимо, я проверял). примерно такая же техника может применяться и для других задач, где надо много памяти/объектов и не надо грузить GC лишними проблемами.

(и если честно, я это делаю скорее для понтов. и ещё чтобы иметь потом тестовый полигон для отладки работы с native pointers.)

Т.к. xDelta зачастую требует более 4Gb RAM , то почти все эти методы в стиле x32 архитектуры Linux не подходят.

Скорее всего, будет проще портировать прикладную часть BlackBox на Active Oberon.
Или 90 процентов на АО, а утилиты переписать на Modula-3 .

Такая практика существует.
Придумали её до меня и без меня.

Практика достаточно успешна.

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

и да, я жадный и вредный, поэтому LC под GPL.

Ну, в России можно что угодно делать, но в "цивилизованном мире", откуда всё это родом, разве можно перебить лицензию от BBCB на GPL? Касаемо фана, BBCB лично у меня вызывает эстетическое отвращение своим убожеством и антипаттёрнами в области эргономики. Сообщество пользователей BBCB, которое не видит эти антипаттёрны и получает удовольствие от его использования, невзирая на то, что их заставляют поминутно делать лишние бессмысленные действия, кажется мне странным и оторванным от реальности (похоже, сейчас в меня полетят разные предметы). Но на вкус и цвет товарищей нет. Сам по себе язык КП выглядит более-менее адекватным, хотя его убожество тоже в современном мире не выглядит вдохновляющим. Однако это путь аскезы и на этом пути язык выглядит имеющим смысл, тут нет речи о дефектах, а скорее о некоем выборе. Впрочем, мне скучен язык без встроенных средств параллельности. То, как сделано в BBCB с циклом событий, конечно, позволяет иметь какую-то параллельность за счёт обработки событий, но маловато.

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

а вот финт наоборот уже не получится: снять таким образом GPL нельзя, и аннулировать её никак нельзя. это могу только я сделать, как автор, который нацепил, и только для будущих релизов. и это автоматически обозначает, что любой проект на базе LC обязан быть с открытыми исходными текстами, под GPL. хихи.

собственно, как нацепивший, я сделал одно исключение: в mainline 2.0 код из LC можно брать под оригинальной BSDL.

единственная проблема, которую я вижу абсолютно во всех оберонах — это тотальное игнорирование клавиатуры. именно поэтому, например, в LC можно запускать коммандеры через ctrl+enter, а не только мышкой; открывать и закрывать фолды с клавиатуры же; и поэтому же LC поддерживает не просто хоткеи, а «кейкомбы» — например, "^K 1" для установки букмарка, "^Q 1" для перехода на него. их можно штатно в меню прописывать. ну, и я планирую вообще отвязать кейкомбы от меню.

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

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

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

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

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

Ты реабилитирован Остальные пользователи ББЦБ - нет Они ведь не сделали это сочетание ctrl+enter, хотя это выглядит абсолютно необходимым для любого опытного разработчика со стороны. Программирование мышью - это для меня выглядит как признак профнепригодности, ну примерно как класть ноги на обеденный стол. Впрочем, пользователи ББЦБ - это обычно и не программисты, а люди из смежных областей, к ним не стоит предъявлять тех же требований, как к программистам. Тогда возникает вопрос, насколько непрограммисты способны управлять проектом такого рода, и программистов ли готовит школа Вирта. Но за это вообще на костёр могут отправить, я понимаю.

Это не единственная проблема, но это та, которую легко исправить и она не исправлена за много лет, что и делает для меня ББЦБ несостоятельным проектом. Что касается LC, то как минимум он на один уровень выше.

Из лично моих претензий к ББЦБ - ну из того, что помню, но это уже не только про эргономику:

* КЛЮЧЕВЫЕ СЛОВА КРИЧАТ НА МЕНЯ
* бинарный формат исходников
* отсутствие библиотекаря типа pip install, gem, go get, quicklisp, opam и иже с ними - они есть в любом состоятельном проекте.
* консервативный сборщик мусора
* отсутствие отладчика (точнее сказать, мы с Иваном Андреевичем почти оживили отладчик, работающий под Windows, но он никому не понадобился - это тоже из серии класть ноги на стол)

вот это да, уже вопрос выбора. у меня есть далёкие планы портировать части Active BlackBox, но — далёкие. опытным путём я пришёл к тому, что один раз потоки спасают, а тридцать — делают меня печальным кроликом. зато код поддержки всей этой механики усложняется неимоверно. и всё равно мы имеем GC, который stop-the-world, и вокруг которого надо плясать, чтобы он в самый ответственный момент не пришёл.

как по мне, то намного более полезная фича, которую надо в ядро затащить пораньше — это сопрограммы. сопрограммы — это хорошо, это вкусно. на них очень удобно всякие серверы писать: я знаю, я их писал в количестве. в схемах вот из коробки есть прикольное call/cc, с ним кучу всякого можно делать. в обероне, конечно, встроеных замыканий нет, но эмулировать их объектами не так уж и сложно.

так что я понимаю, почему Илья счёл проект Active BlackBox не особо полезным. это было прикольно как proof of concept, но на практике не особо надо.

Так в том и смысл A2, что там маленькое ядро и постижимый компилятор и можно управлять реализацией параллельности. Правда, нельзя сказать, что управлять ей легко. Для впиливания кооперативной многозатачности Florian Negele существенно менял язык, компилятор, среду выполнения и в итоге у него остались незакрытые ошибки в сложных местах. Но тем не менее, он сделал это в одно лицо и это показывает, что система достаточно компактна и податлива к изменениям, чтобы это было достижимой целью. И с третьей стороны, часть претензий из моего списка там были изначально уже закрыты.

Короче, с какой стороны не посмотри, а ББЦБ выглядит Запорожцем, который да, дёшево стоит, да, везёт из пункта А в пункт Б, но ни в какой момент нельзя забыть, что это Запорожец. A2 больше похожа на "каблук" - едет медленно, но берёт больше груза и есть простор. Похожа уже на полноценный автомобиль. Я в своё время посмотрел-посмотрел - да и свернул свою работу с ББЦБ, мне понадобилось порядка 4 месяцев календарного времени, ЕМНИП, от начала проекта до принятия решения о переходе.

Сборщиком мусора тоже можно управлять, все вроде сходятся на том, что нужно реализовать множественные кучи. А из коробки уже есть потоки реального времени, хотя статус их сомнителен, но им не страшен сборщик мусора. В целом, реализация многопоточности и в A2 не идеальна, но есть стартовая точка и кое-какая инфраструктура. До этой стартовой точки от текущего состояния ББЦБ очень далеко, а жизнь-то не вечна. Не всякий велосипедист успеет доехать до Марса.

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

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

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

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

добавлю кстати, что отсутствие возможности задать цвет фона под текстом в BBCB — очень странное упущение. его я в LC тоже починил.

ваще не парит. особенно с тех пор, как я дифалку от советской в LC положил. формат на самом деле очень простой, его можно спокойно распарзить и без BBCB. зато нет лишнего кода сериализации/десериализации в какой-то неудобоваримый псевдочитаемый текст. поскольку исходник — это обычный документ, то он может содержать в себе что угодно, так что надо делать полноценный универсальный сериализатор. я думал было сделать bijective XML, но потом передумал. с дифалкой стало не надо.

не парит по причине того, что я вообще почти нигде не использую чужие библиотеки. а если использую — то утаскиваю к себе и форкаю.

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

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

а это тоже вопрос того, что от системы хочется. мне лично мощь A2 в плане многопоточности/многозадачности («многоактивности», наверное — так правильней будет ;-) не нужна. избыточна. а BBCB в самый раз. у меня задачи-то не ахти какие сложные, один фиг большинство stalls на i/o, которое хучь ты сто потоков влупи — а всё равно сериализовано, потому что канал-то один.

плюс мне A2 не нравится тем, что там нет этого… которое называют словом vision. это экспериментальная площадка, где лежит куча концепций, но ни одна толком до ума не доведена. три компилятора, два типа UI-библиотек (ни одна до ума не допилена), и ты ды, и ты пы. я понимаю, что это прямо вытекает из специфики проекта, и всё это можно вычистить и допилить, но… но это всё уже сделали за меня в BBCB. ;-) лично для меня единственный вариант превратить A2 во что-то юзабельное — это портировать туда BBCB. если мне когда-нибудь понадобится мощь A2 в плане параллельности — я так и сделаю, наверное.

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

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

Бинарный формат исходников - нужно же ещё ветки сливать. Если бы не было этой возможности, я бы не осилил свои задачи по A2.

> почти нигде не использую чужие библиотеки

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

> да нет, он precise как раз. за исключением стека

Точный за исключением стека - это как "немножко беременна".

https://dzen.ru/video/watch/635aeb4884afe060a954f50e

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

Если пользоваться только своим кодом, то так можно попробовать. Я работал и с отладчиком, и без. С отладчиком для меня лучше. Я с сомнением отношусь к программисту, который заявляет, что отладчик не нужен вообще и что его можно заменить другими средствами без ущерба. Отладчик нужен не только для поиска своих ошибок, но и для изучения чужого кода. Как пример, я нашёл одну ошибку в компиляторе A2, только благодаря пошаговому отладчику. С трапом тоже можно было бы этой цели добиться, но трудозатраты были бы во много (в десятки) раз больше и не факт, что я бы не слился на полдороге. При том, что отладка является сложным процессом, увеличение её трудоёмкости в десятки раз превращает легко постижимые ошибки в непостижимые, т.к. в уме уже невозможно удержать модель изучаемого явления.

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

Идея портировать ББЦБ в A2 уже давно обсуждается, но ни у кого руки так и не дошли. Видимо, и не дойдут уже никогда. Я одно время пытался это спланировать и поместить в список задач, но никто из ББЦБ-шников не захотел вложить в это свой труд. Потом я посчитал количество пользователей ББЦБ в России - и получается, что гораздо выгоднее портировать на A2 любую другую технологию, хоть Бейсик, хоть Го, хоть JS, хоть Java, хоть Ершол. Будет в миллионы раз более выгодное вложение сил, хоть и более трудоёмкое.

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

Не так нужны картинки именно в коде, чтобы на это стоило бы пойти для всех исходных текстов.

вот этого, пожалуй, в BBCB немножко не хватает. да и то настолько некритично, что мне даже возиться лень. ;-) в принципе, можно научить магическое дополнение к редактору их выделять. сейчас магия комментарии автоматически курсивом делает, например.

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

а у советской кроме дифалки ещё и мержилка есть. опять же: всё внутри BBCB, так что мержилка может красиво отметить конфликты, по желанию отметить все изменения, и всё такое. как по мне — удобней, чем внешние инструменты, которые о документах BBCB ничего не знают.

мой личный многолетний опыт показывает, что если библиотека большая и сложная — то на то, чтобы разобраться с её API времени уходит не меньше, чем на реализацию нужной её части с нуля. а если маленькая и простая — то и тем более я лучше сам сделаю, чем тащить дополнительную зависимость.

исключения — это штуки типа OpenAL для звука, всякие там декодеры аудиовидеофайлов, и подобное: тут мне тупо знания математики не хватает, чтобы сходу самому напилить. ну, или дурацкие штуки типа SSL/TLS, которые лопнешь сам реализовывать.

велосипедизм, конечно, я не спорю. но я ж и не скрываю, что люблю велосипедить. ;-)

ну как сказать. это значит, что вся необходимая низкоуровневая механика и реализована, и работает, и используется. а сделать точный сборщик по стеку при наличии колбэков из чужого кода в общем случае просто невозможно. разве что заниматься постоянным переключением стеков при вызове библиотек ОС и колбэков из этих библиотек — что, как по мне, не особо осмысленно, и выделки не стоит. на самом деле «консервативность по стеку» совершенно не страшна в силу отсутствия в оберонах такой штуки, как interior pointers. то есть, ложных срабатываний исчезающе мало: я ни разу с такой проблемой ещё не сталкивался.

право, это очень синтетический пример. не то чтобы этого не могло случиться — но вероятность очень мала. в нормально написаном коде, который не проводит всё время внутри одной процедуры, выделяя там вот такое — она где-то в районе нуля. я даже в D на это не наступал за десять с лишком лет — а в D всё ещё хуже, потому что там разрешены interior pointers.

и да, в A2 будет точно та же проблема, если использовать её как процесс поверх уже существующей ОС. потому что точно по тем же причинам организовать стабильный и работающий в любых условиях сканер стека при наличии третьей стороны, которая может модифицировать стек по неизвестным правилам, невозможно. при таких раскладах я A2 уж точно использовать не рискну, если не на bare metal. ;-)

одна из причин, по которым я предпочитаю свои велосипеды. ;-)

интерактивный отладчик, это важно. живой post-mortem дамп — как окно трапа в BBCB — это тоже отладчик. только не интерактивный: в том смысле, что программа уже умерла, повзаимодействовать с ней не выйдет, только исследовать трупик. но это тоже отладка.

а здесь мне вполне достаточно логов (ну, и HALT-ов в стратегических местах). собственно, именно так я с кодом BBCB и разбирался: усыпал нужные места логами — и смотрю. единственно что — сделал отдельный логер в консоль, потому что лог в окно BBCB не шибко удобен для подобных целей.

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

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

ну, если бы я смотрел на то, что делают большинство программистов в мире, то я бы точно не занимался BBCB. ;-)

это не такая простая задача ведь. во-первых, нужен фронтэнд компонентного паскаля к фоксу. а во-вторых — и это намного сложнее — надо чистить код самого BBCB, бережно заменяя во всех местах раскрашивание указателей под интегеры и обратно. что кое-где потащит за собой и изменение сериализатора, и всякие другие неприятные мелочи. а потом ещё окажется, что BBCB очень не любит многопоточность, и придётся везде лочки распихивать, иначе какой смысл-то. а с лочками оно начнёт адски тормозить. переводить на текстовую подсистему A2? теряем совместимость по документам, да и по коду тоже: это уже не BBCB получается.

вот я лично на всё это посмотрел — и идею переселить BBCB на платформу A2 забраковал. усилий много, а профиты довольно спорные. впрочем, если бы в A2 был фронтэнд компонентного паскаля (а теперь уже ультрапаскаля, конечно ;-) — я бы, может, и попробовал.

> а сделать точный сборщик по стеку при наличии колбэков из чужого кода в общем случае просто невозможно

Вот поэтому и не нужны все эти гибриды, где на гнилом фундаменте пытаются построить нормальный дом. Нельзя построить нормальный дом на гнилом фундаменте, и точка. Опять же это для меня было причиной копаться в A2 - она способна работать на железе, т.е. в отличие от 99.9% софта, который мы видим вокруг, она не болеет этой болезнью. При этом осознании я уже никогда не смогу счесть двухэтажные системы, где на первом этаже Си, эстетически приемлемыми. Кроме такой экзотической ситуации с утечкой памяти через консервативность, есть же и другие неустранимые недостатки такой двухэтажности. Т.е. A2 - это уникальная вещь, красивая и безальтернативная (ну т.е. наверное где-то есть ещё ОС на Аде, яве или лиспе, может быть, там как-то по-другому). Странно, почему все ещё не бросили всё остальное и не занялись такими системами, ведь их преимущества очевидны с точки зрения кибербезопасности.

Но вот я кстати не знаю, как A2 в виде приложения решает этот вопрос. Возможно, это знает Сергей Дурманов и он напишет, если прочитает эту тему. Сергей?

> нужен фронтэнд компонентного паскаля к фоксу

Это не выглядит слишком уж сложным, с учётом того, что компонентный Паскаль - это почти подмножество АО. Думаю, работы там на несколько недель, не больше. Проблемы могут быть из-за конфликтов в понятиях об объекте, в подчинении типов, в особенностях строковых типов и т.п. Может получиться некрасивое лоскутное одеяло, где например, отношение подтипов будет определено более чем одним способом. Но это вряд ли помешает интероперабельности.

В общем-то в A2 же уже есть Оберон как приложение. Я выпилил его из ЯОС, т.к. там было 700 файлов и система была заметно тяжелее. Оберон запускается в своём окне со своей отрисовкой.