OberonCore

по промежуточным итогам обсуждения вот здесь было принято волевое решение совершить убийство. жертвой был избран StdLibrarian, который я уничтожил, и заменил на подсистему Subs, в которой находится SubsManager. потому что по идеологии Lament Configuration «подсистема» — это не набор файлов на диске, а вид на некоторый (заданый текущей конфигурацией) набор документов. соответственно, SubsManager занимается отображением этого набора на конкретное хранилище.

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

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

p.s.: а ещё я не смог придумать красивого имени в одно слово, чтобы положить это в System. StdSubsysManager же выглядит страшно, да и там уже три модуля, на самом деле. как раз время делать подсистему. ;-)

поскольку добровольно никто никогда чейнджлоги не читает, то LC при первом запуске насильно покажет новую часть из "lament_whatsnew.odc". так, понятно, тоже никто читать не станет — но я хотя бы старался.

убивать — это прельстиво! убил HostLocHook: поскольку я сделал в локаторе API, который где-то на форуме предлагал, то этот хук стал совершенно бесполезен. API в локаторе удобней, потому что локатор точно знает, как отформатировать свой путь в канонический, и гарантирует, что авторы оверлейных FS со своими локаторами не забудут сделать для них возврат пути: компилятор обругает, если забудут.

надо будет точно документировать, что есть «канонический путь» ещё.

замечу, что пути из локатора совершенно не обязательно про диск: это просто текстовое представление, которое можно скормить `Files.dir.This()`, и получить локатор в то же место, в которое указывал локатор, из которого мы канонический путь добыли. и ещё этот канонический путь можно пользователю показывать. нечто типа URI, только локаторы.

по поводу новых компиляторов в LC. была у меня раньше идея попробовать утащить Fox из A2, или сделать новый оптимизирующий кодоген на SSA к тому же CP2. по некотором размышлении я пришёл к выводу, что оно того не стоит.

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

Fox, возможно, лучше, и умеет больше гитик — но вы видели его размеры? нет, вы видели?! местами абсолютно impenetrable модули по 400-600 кб исходника. при этом выходной код у него не то чтобы настолько лучше, чтобы оправдать такие размеры. ну, я понимаю, почему Fox такой, это не критика компилятора, это про то, что внесение подобной сложности в BBCB с моей точки зрения не окупается.

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

во-вторых, шибко оптимизирующий компилятор обладает весьма неудобным недостатком: после всех трансформаций машинный код часто весьма слабо соответствует оригинальному исходнику. а у нас есть преудобнейший инструмент post-mortem view aka trap window, уникальный по мощности и простоте использования. который начнёт показывать погоду на марсе, потому что что там наоптимизировал компилятор — будет непонятно. слил какие-то локалы, переставил местами код — и получаем в трапе сплошные загадки.

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

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

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

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

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

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

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

сами по себе потоки инструмент довольно специфический, требуют внимания и аккуратности как при работе с бензопилой, в которую встроен AI, активно ненавидящий всё живое. поэтому адаптация идей A2 — это на очень далёкую перспективу.

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

в принципе, по гамбургскому счёту потоки нужны в основном там, где есть длительное блокирующее i/o, которое никак не обойти. сейчас это тоже можно организовать, надо только высунуть наружу платформо-независимую обёртку над API создания потоков. а дальше обычная схема: заякореный RECORD с нужными параметрами, фоновый action с проверкой флажка завершения, и колбэк/посылка сообщения. код надо сразу под такое проектировать, конечно. платим прибитым гвоздями минимальным квантом на фоновую операцию (ну, относительно прибитым, неважно в данном случае), так что имеет смысл только для очень долгих операций, или для операций не критичных к тому, что они могут занять 50, например, мсек, хотя завершатся намного раньше. для какого-нибудь DNS resolving, например, нормально. ну, и батчить можно.

тем не менее, потоков с меньшим квантом хочется. может, действительно сначала ABB портировать. короче, джинн опять думать будет — тем более оно не горит.

> про A2, и про то, что многопоточность на самом деле кооперативная

Нет. Точнее:

Там две редакции: одна с "обыкновенной", вторая - с псевдо-кооперативной.
И, если не ошибаюсь, кооперативность для нитей оказавшихся на одном ядре процессора,
а задействуются все.

> реальных потоков всегда столько, сколько в системе процессоров

Впрочем, Вы про это же чуть позже написали.
В любом случае это для "кооперативного варианта A2", в "обыкновеном" "всё по-другому"

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

doctoral thesis (забыл, как это правильно переводится ;-) очень увлекательный. я его начинал листать с весьма скептическим настроем, но по мере чтения проникся. кросивое.

нежно украл из Active BlackBox weak pointers. имейте в виду: оно под GPL, и автоматически заGPLило Kernel. кстати, означает ли это, что все модули, которые импортируют Kernel, тоже автоматом стали GPL (а за ними рекурсивно и всё остальное)? меня, в принципе, это совершенно не напрягает, я бы и так GPL везде сделал, просто лень.

в принципе, там и переписать несложно: один дополнительный список, да процедура для вайпа дохлых указателей по нему: реализация очевидна для любого, кто Kernel читал. но технически код получится совершенно тот же самый, поди докажи, что это с нуля накарябано, а не тупо скопировано. тем более если следовать букве лицензии, то я уже и не могу это сам написать: я же в исходник ABB заглядывал. так что чтобы было не-GPL, надо кого-то, кто знаком с BB, с Kernel, не читал код ABB, и сделать clean room implementation. я, знаете, вертел это всё на половом органе.

кстати, это автоматически обозначает, что в BB 2.0 нельзя реимлементировать ни слабые указатели, ни детали никому, кто в ABB смотрел. а смотрели, полагаю, все активные разработчики. опа-опа, котаны!

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

Опустив тот факт, что GPL в России, как и остальные лицензии, без реальной юридической бумаги смысла не имеет, замечу, что автор явно не будет возражать против смены лицензии на BSD.

Просмотрел список изменений в BBLC... ну теперь уже это совсем не BlackBox, конечно. В смысле совместимость с каркасами 1.6/1.8/2.0 уже разъехалась окончательно.

ну, в принципе проект не только для РФ же. могут поинтересоваться. а так-то я тоже думаю, что автор не против, но всё-таки без ведома автора менять лицензию некультурно.

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

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

экспериментально добавил «типа-дейкстра-циклы»:



почему с трубами? ну, во-первых, это красиво. а во-вторых, в `LOOP` без трубы никак, иначе первый `IF` не отличить от обычного. а тогда для единообразия и в `WHILE` пусть тоже трубы будут. `ELSIF` же для того, чтобы показать, что конструкция выберет первый истинный guard. хитрый `WHILE` будет переписан в `REPEAT` со скрытой переменной выхода: так надо, чтобы не нарушать семантику `EXIT`, и не добавлять в компилятор новые ноды.

в принципе, оба цикла «не по Дейкстре», хотя издалека и похожи; и первый можно выразить практически без изменений, просто добавив в конец `ELSE EXIT END` (что компилятор и делает). однако в такой форме оно мне кажется красивей. подержу их пока, а когда-нибудь потом внезапно уберу, чтобы у кого-нибудь код сломался.

Поправьте, что-то не работает прокрутка в файловом браузере. Большое спасибо за паттерны в MarkRect, утащил.

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

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

кстати, раз вспомнил. в Text отметка рамочкой (когда окно не в фокусе) — на один пиксель ширее и вышее. от этого иногда появляются артефакты (например, при replace and find next). это ещё в винде было сто лет тому назад. потому что рамочка за строку вылазит, натурально, а так нельзя.


p.s.: там у меня есть ObxCtrlsTest8 — это то, что я использовал для проверок на одинаковость рендера. там сейчас накидано больше, чем надо, но тем не менее.

спасибо, починил скроллинг. постараюсь больше не ломать. ;-)

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

У меня есть идея сделать ссылки на разные сборки на страничке загрузки
https://blackbox.oberon.org/download

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

Есть список сборок https://oberoncore.ru/tags/bb/installation. Он несколько староват и LC там нет. Только вот LC уже и не сборка. Это ответвление, если угодно. Да и часть сборок в этом списке тоже не сборки, на самом деле.