OberonCore

ещё настойчиво рекомендую в `HandleTrap()` сделать примерно вот так:

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

в общем, сделайте что-то по мотивам этого кода у себя.

Пакет в Debian репозитории обновил.

Этот тест оказывается уже добавили в подситему Check. Модуль CheckKernel2.

Проверил ещё на OpenBSD и FreeBSD — работает исправление корректно.

Заодно починил в OpenBSD и FreeBSD переустановку сигналов для буфера обмена.

Внёс также (мы обсуждали в чате), чтобы для новичков поиск по справке F1 был без учёта регистра, а то не могут найти какие-то полезные вещи, так как галочка Ignore case не совсем очевидна.

возьмите уже у меня нормальные регулярки. ;-) код там, конечно, адский жоп — зато работает. я TextCmds под регулярки адаптировал, удобно. в замене вдобавок есть приятные фичи типа «преобразовать в верхний/нижний регистр», «capitalise», и прочая. надо бы ещё вызов команды добавить — в смысле, вызывать команду для обработки subexpressions в заменяторе. положительно не понимаю, как вы без регулярок живёте.

Регулярные выражения всё же это уже как дополнение. Не оставляю попытки сохранять минимализм базового фреймворка.

Решение надо будет как-то дорабатывать, а то в целом Блэкбокс перестаёт по Ctrl+C завершаться. Наверное он большую часть времени крутится в ядре. Надо тогда по Ctrl+C устанавливать какой-то флаг, чтобы как он из ядра выходил, тогда и останавливал выполнение.

Это ещё предстоит делать. Спасибо за исправление.

а он и не должен.
он в основном сидит в готэка, ожидает события. технически кидать сигналы прерываний когда мы в системных библиотеках — плохо, поэтому и не кидаем. Ctrl+C — так же, как Ctrl+Break в оригинале — предназначена для того, чтобы прервать зациклившийся код на компонентном паскале. именно так оно в виндовом оригинале и работало. то, что до правок Ctrl+C работало иначе — это был баг.

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

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

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

p.s.: `UP.` для CP, понятно, не нужны, их при адаптировании можно просто выкидывать. возможно, ещё объявления переменных придётся наверх сдвинуть, потому что в ультрапаскале можно иметь секцию объявлений после вложеных процедур.

ошибочка в WinFiles: в `NewLocator`:

а должно быть так:

Большое спасибо, внёс исправление.

Актуализировалась тема с выделением платформенно зависимых модулей подсистемы.
Я попробовал на примере платформенной части DevProfiler внести решение/предложение.
По аналогии с тем, как это сделано в МультиОбероне обозначения платформ выделил двойным подчёркиванием.
DevProfiler__Win
Фильтрация модулей реализована в DevCompiler указанием специального квалификатора/селектора после символа at.

Мне видится, что такой символ "__" очень ярко обособляет эти модули, и также во время импорта будет провоцировать заменить это на
Plarform := DevProfiler__Win

У некоторых пользователей может быть отрицательное отношение к символу подчёркивания, в связи с некоторым противопоставлением верблюжьего стиля и сишного стиля разделения семантических частей названия процедур и переменных. Я пытаюсь оценить, насколько это серьезная проблема. Скажите, "коробит" ли вас такое обозначение? Какой символ для отделения платформенной части вы бы предпочли или его отсутствие?

Ранее, к примеру, в проекте Sdl2 были использованы платформы без отделяющего символа StdLin.odc StdWin.odc. На мой взгляд это может быть недостаточно явно выделяет особенность этих модулей, а также может привести к коллизиям, когда случайно конец названия совпадёт с названием платформы. Ваши мнения?

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

Как временный костыль может и подойти.
Меня больше "напрягает" жёсткая загрузка этой пары модулей (DevProfiler) через Init (пусть даже и по наличию Dev) под Windows.

В целом согласен. Лучше вот так?

Да, так лучше.

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

а я ведь говорил, что subsystem manager понадобится. и что с ним можно быть более совместимым, вернув на место универсальный Host. it's just a first glimpse of problems awaiting you right around the corner.

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

В решении arisu мне не нравится нарушение соответствия названия модуля и его кода (наличие глобального состояния платформы). Также мы очень сознательно убрали Host подсистему, чтобы сделать настоящую честную кросс-разработку, сделали её более прозрачной.
Мы обсуждали с Александром ещё вариант, чтобы название модуля делать как в А2 с указанием платформы через точку. Тогда как-то расположение модуля возможно выносить в папки внутри подсистемы. И будет однозначное соответствие названия модуля и его расположения в системе. Но это потребует доработки парсера, чтобы он понимал названия модулей с точками.

эм… а вот это не глобальное состояние разве?


и, кстати, как это нарушение? вот написано: `HostBackends`. открываем модуль — там `MODULE HostBackends`. печатаем в среде `HostBackends`, выделяем, нажимаем Ctrl+0 — открывается исходник HostBackends. тот самый, который скомпилен. где нарушение-то? «показать документацию» правильную документацию показывает. «показать исходник» правильный исходник показывает. поиск ищет по правильным модулям. и происходит это всё при помощи ровно тех же проверок (ну, похожих по смыслу, не по тексту) типа той, что я выше процитировал. только среда это делает сама, а не заставляет меня руками писать то, что она и так уже знает.

до тех пор, пока мы работаем со всем изнутри среды — соответствие будет автоматическое. единственный случай, когда можно немного запутаться — это кросс-разработка: правка модулей от чужой архитектуры. и это решается просто глобальным переключением текущей архитектуры. впрочем, в заголовках табов всегда указано `[<ArchName>]`, если мы открываем архитектурно-специфический файл в редакторе (будь то модуль, или ресурс, или документация).

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

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

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

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