OberonCore

да ненене, я не в претензии. twisted humor, всё такое. LC же нельзя пользоваться, я даю примерно ноль гарантий, что завтра не поменяю что-то, что всё сломает. я-то свой код чиню по дороге, но давать такое людям — это создавать впечатление, что BB в принципе неюзабелен. тут вся тема про то, что LC — absolutely retarted. стараюсь держать уровень… ретардации.

по результатам долгих раздумий и бурных обсуждений всё-таки получается, что место для pixmap API исключительно в bottleneck. то есть, нужен пиксмап в виде массива, которым можно манипулировать из кода, и рисовать его на экране (иногда с масштабированием и альфой). как ни крути, а тут без реальных пиксельных размеров никуда. протекание пиксельных размеров в интерфейс Frame — некрасиво, там у нас универсальные координаты везде. так что получается только в Rider, наподобие `GetRect()`/`SetRect()`.

в принципе, это верно: прямая работа с пикселями — это низкий уровень, коду выше это не должно быть нужно. то есть, код выше — это уже про загрузку готовых изображений и их блиты. соответственно, должен быть некий Raster, который можно блитать с дополнительными параметрами (типа опционального альфа-блендинга и масштаба), а также создавать из более низкоуровневого представления «массив пикселов». и операции `Raster ↔ Raster` для композитинга, видимо.

приношу благодарность SovietPony за обсуждение и помощь в осмыслении.

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

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

чисто шутки ради сделал ctrl+wheel зум отцепленых окон. увы, благодаря ошибкам округления рисовалка безьерок иногда на один пиксель вылетает за границы clip rect. или это я сигил так округлил криво. в любом случае — это так, трюкачество, i don't mind it.

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

размышления о наполнении. а точнее, о текстах.

сама по себе текстовая модель вполне поддаётся переделке на балансированые деревья. дело нехитрое, будет O(log n) на позиционирование, O(1) на последовательный доступ — то есть, пропадут тормоза простых ридеров, когда они скачут по тексту далеко от текущего места. там обычный piece chain, они все так ускоряются довольно тривиально.

а вот с форматированием текста — там интересней. насколько я понял из беглого просмотра — форматирование делается не сразу по всему тексту после открытия, а on demand, и по видимой части (по сути, от начала строки и пока видимая часть не закончится). подход хороший и быстрый, но имеет фатальный недостаток: scrollbar (и позицию в принципе) можно иметь только по размеру текста, а не по количеству видимых строк. именно поэтому можно скроллить видимую область за последнюю строку. и тут я в раздумьях…

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

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

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


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

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

движок совершенно стандартный: recursive-descent парзер в AST, потом кодоген по AST в код виртуальной машины, потом многопоточная исполнялка по Томпсону для простого поиска, и по Пайку если нужны захваты. в память гадит в основном в процессе создания AST, а сама программа для VM — просто массив целых.

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

всё вплоть до исполнялки по Томпсону (включительно) уже портировано и даже работает; осталась только исполнялка по Пайку.

потому что этот ваш CpcRegul я даже не смотрел: он, понимаете, Бабеля требует, а я Бабеля до сих пор не читал.


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

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

немножко статсов: исходник на ~69 килобайт, скомпилированый код ~24.5 килобайт.

пайковая вм адово гадит рекордами потоков, увы. в принципе, это можно соптимизировать трюками через SYSTEM и [untagged] — там не надо ничего якорить, но… premature optimisation, как известно — корень of all evil. и непортабельно будет. если уткнусь когда-нибудь в тормоза от GC — тогда и подумаю. я всё равно сильно подозреваю, что оно даже в таком виде обставит CpcRegul как лежачего, гыг. ну, то есть, по скорости, про размеры и герметичность и говорить нечего.

сишный оригинал, btw, использует memory pools, которые просто выкидывает по окончании работы. тоже такой своеобразный GC.

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

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

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

это красивый пример применения бабеля, и это ужасно как практический движок регулярок. мало того, что оно тащит за собой огромнейшую подсистему, так эта подсистема ещё и практически полноценный парзер формальных языков. да почему «практичести», это оно и есть — конкурент Coco/R, flex+bison, etc.

ну, это как если бы BBCB для своего компилятора использовал какой-нибудь lex+yacc, потом базировал это на GCC (в смысле compler collection, не си), требовал полный тулчейн к нему… ну, в итоге, наверное, был бы крутой оптимизирующий компилятор, но не совсем то, что удобно и быстро.

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

в оригинальном коде на си, например, парзер тоже был на yacc. в итоге выхлопная портянка одного парзера занимала столько же, сколько сейчас весь движок. ну, то есть, я орнул чаечкой и сделал recursive descent мгновенно. ну да, в recursive descent сложнее контролировать стек, если скормить ему патологический вход. но возможно (и в srex возможно, просто мне лень это делать; там механика всплытия на месте, надо только один счётчик добавить, делов).

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

p.s.: а знаний таки требует, потому что во-первых, там синтаксис нестандартный, а мне надоело каждый раз новый синтаксис для регулярок учить. а во-вторых, там — кажется — нет нежадных повторений, только жадные (или наоборот, но точно один вид всего). то есть, надо выучить бабель, понять, есть ли там управление жадностью, переписать грамматику… то бишь, именно для использования потом не требует, но для адаптации — ещё как. но я же Настоящий Программист: мне проще самому накоекакить, чем пытаться чужое прочесть.

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

в общем, я там сделал культурненько, даже какую-никакую документацию забабахал. когда-нибудь внедрю в поисковик. вместе с историей, а то заколебали туда (в Ctrl+F) гадить все кому ни попадя.

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

вообще, надо будет как-нибудь попробовать сделать постоянные блоки — и посмотреть сколько кода сломается.

и мысль отвлечённая: я понял, почему лично у меня никогда не было ломки по поводу раскраски синтаксиса в BBCB! во всём виноват белый цвет фона у текста. вот если бы он был тёмно-синий, например, или тёмно-серый…


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

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

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

фигасе. нашёл свои старые исходники на компонентном паскале, от 2003-го года. однако. BWT-компрессор, а поверх него потоки для чтения и записи а-ля дельфийские. оно даже собралось и заработало. хренасе я старый…

забавно, что поля ввода даты и времени сделаны просто хаком поверх обычного редактора. я-то думал, там в оригинале красота, фичи, кнопочка «показать календарик» и всё такое… (ну да, не использовал, не помнил.) но омики пошли по пути чистого MVP. so did i.

таки разделил `f.Input()` и `f.QueryInput()`. второе просто опрашивает текущее состояние, но не делает никакил слипов, не вызывает акшоны и ты пы. где-то в Views, кажется, даже одну замену сделал. `f.Input()` по-прежнему можно звать для одноразовой проверки состояния, но неэффективно.

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

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

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

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

опять про потоки. я тут подумал: а надо ли в принципе заморачиваться переделкой ядра под них? ну, то есть, потокобезопасный GC в принципе не нужен, нужна дисциплина (and punishment, да).

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

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

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

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

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

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

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

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

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

таки привинтил ассемблер. конечно, далеко от идеала, и для инлайнов (которые <code>) ещё не сделал, но в принципе — уже можно пользоваться. фиксапы тоже не все, так что обращаться из асм-кода имеет смысл только к глобалам и локалам через `a[EBP]` (второе только для non-naked). рыть по использованию `DevCPA`, и нового типа ноды `Nassembler`. дифы лучше не делать, потому что я по дороге немного переформатировал код компилятора под свой вкус (я так новый код изучаю обычно — ручным переформатированием).

оно очень WIP, так что тащить пока особого смысла нет. но полюбопытствовать можно. там пришлось добавить публичную процедуру в DevCPL для фиксапов, и экспортировать `ch` и `Number` из DevCPS. вроде больше особо ничего особого не было.


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


p.s.: привинтил асм и к кодоинлайнам.