OberonCore

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

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

just in case: это шутка. так-то LC имеет всё, что у вас, кое-что, что у вас только в планах (например, модальные формы-данетки средствами самой среды, или вообще независимая от ОС рисовалка), и кое-что, чего у вас в планах даже нет (и не надо их совсем! (ц) ). но без вашего 2.0 всё это было бы невозможно. так что примкнувший к вам шепилов стоит на плечах как титанов прошлых времён, так и на ваших. ;-) и мне, конечно, проще, потому что не надо париться особой совместимостью со старым кодом, которого у меня всё равно почти нет.

Это тут про что?

Благодарю, погляжу!

да просто смотрю ваше видео с дней оберона про 2.0. простите, не упомянул. написал тут, потому что это, в принципе, LC касается.

кстати, Борис там тоже не совсем прав: LC процентов на 99 (ну, может 98) совместим с остальными по прикладному коду. я сами интерфейсы среды не трогаю в основном, потому что — а зачем? умные люди придумывали ведь. просто код на компонентном паскале надо пометить как код на компонентном паскале, и мой CP2 спокойно его скомпилирует. фактически, несовместимы в основном bottleneck-интерфейсы.

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

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

p.s.: заливки — это вы про HostPictures (StdPictures) где упоминали. у вас там залито радикальным оранжевым цветом, потому что нет апей для pattern fill. у меня в LC есть, поэтому у меня залито нормальной сеточкой. хотя в оригинале сеточка всё равно должна была эмулировать серый цвет, так что правильней всего серым было и заливать. просто я оранжевый больше люблю.

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

да, и про вяленд. там xwayland вполне имеется, и вряд ли в обозримом будущем куда-то денется. поэтому использование xlib как раз позволяет поддерживать и иксы, и вяленд.

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

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

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

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

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

Это хорошо.

А вот это точно надо.

ну, не без того. например, `.Pos()` и `.Length()` у Files теперь возвращают LONGINT, чтобы инты получить — надо использовать `.Pos32()` и `.Length32()`. у Frame появилось разделение на `QueryInput()` и `Input()`, и опциональный `InputWithTimeout()`. зато это немного компенсируется наличием Host, куда софт из 1.6 любит лазить за получением времени модификации файла. ;-)

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

вообще, в идеале и далёком будущем надо бы ещё кодогенератор избавить от прямого выплёвывания опкодов. это же абсолютно нечитаемо, и сопровождать это невозможно. надо сделать что-то типа asmjit, чтобы собирать инструкции примерно как `A.MOV(A.EAX, A.SIBX(A.EDX, A.ESI, 4, disp));`. она и в компиляторе пригодится, и как отдельная библиотека для генерации кода на лету. портировать бэкэнд в таком виде будет тоже значительно проще, мне кажется.

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

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

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

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

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

сердце и печень — one-at-a-time Боба Дженкинса. лучшая хэш-функция в классе «32 бита на внутреннее состояние», и вообще очень-очень хорошая. в отличие от многих других (типа того же мурмура) — буквально три асм-инструкции, и никакого умножения в цикле. я к ней добавил простенькую контрольную сумму, которая обеспечивает уникальность. без контрольной суммы на трёх миллионах имён у нас было ~4100 коллизий (что само по себе впечатляет), с контрольной суммой — 0.

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

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

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



p.s.: с идентификаторами во всяких таблицах имён справится нисколько не хуже.

Большое спасибо, применил этот код, и теперь в Windows масштабирование делается им. Качество достойное.

прекрасно. основные благодарности, впрочем, давайте вместе адресуем авторам A2. ;-)

offtopic, but may be of some interest to someone. ;-) just published UrForth/Beast — self-hosting x86 GNU/Linux (windoze version is planned too) Direct Threaded Forth System. it is "self-hosting" in the sense that it can recompile itself using Uroborus target compler (included), and doesn't require any external tools besides it's own binary (included in the repo too). it can create both static and dynamic ELF executables (and windoze PEs, but other windoze code is not ready yet), and it also supports "live snapshots" via "SAVE-IMAGE" word.

time to rebuild the system from the scratch on my 3GHz Core II Duo: 55 milliseconds. ;-)

x86 assembler and disassembler included. batteries NOT included.

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

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

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

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

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

само собой, поскольку self-hosting, то целевой компилятор написан на самом Чудовище.

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

вам это всё скорее всего не пригодится нигде и никогда, но если вдруг любопытно посмотреть на программирование немного с другой скалы — то you are welcome.

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

шоп вы все жили долго, итить, и счастливо!

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

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

Спасибо. С Новым Годом!

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

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

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

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

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

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

в моём «большом» текстовом редакторе это решено при помощи слоёв, которые покрывают весь документ вообще, но у меня там архибыстрые aa-деревомассивы, поэтому позиционирования и проверки O(log n). а для piece list это лучше, наверное, в каждый кусочек совать (разбивая/объединяя кусочки при необходимости). для отметок блоков-то, например, слои подойдут, но вот для раскраски синтаксиса, к примеру, будет БОЛЬ: там же на каждое слово по кусочку получится, без быстрого нахождения кусочка по смещению никак.

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

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

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

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

собственно, таким образом мы получаем универсальный (и отдельный) механизм для реализации «атрибутных слоёв» любого уровня «наслоения», который вообще не затрагивает текстовый поток. со списками кусочков ребята такую штуку провернуть не могли, потому что оно бы адово тормозило в итоге; но если время нахождения кусочка O(log N) — или пусть даже O(2*log N) — то оно стоит совершенно ничего. ну, почти ничего, пренебрежимо малое время по сравнению со всем остальным.

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

ну, придётся иметь механизм для пристёгивания временных атрибутных слоёв из контроллера (аттачить их к райдеру, например). мелочь. зато! зато мы можем выделить рисовалку текста вообще в отдельный модуль! то есть, вынести её из view, и отвязать от контроллера (потому что ей больше не надо знать про выделения и прочие штуки). у нас будет API «нарисуй форматированый текст вот в этом прямоугольнике, используя вот этот райдер». ой. мы только что получили универсальный апи рисования текста на любых контролах, причём текста с любым форматированием, и даже с вложеными объектами, и без необходимости создавать dummy views только для того, чтобы разложить текст.

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

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

портировал любимые аа-деревомассивы на форт. ну как… заново переписал, конечно. это на ультрапаскаль с сишечки кое-как портировать всё же можно, на форт ни с того, ни с другого нельзя. по дороге пересмотрел необходимость в объединении нод прямо в insert и delete. вердикт: не нужно. дело редкое, внесение в insert ничего особо не оптимизирует, а код усложняет. объединялку всегда можно вызвать руками пост-фактум. она всё равно нужна в основном после undo/redo, в остальных ситуациях объядинять особо нечего.

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

двухгигабайтный файл при загрузке сканируется EVE на предмет разделителей строк примерно за семь секунд. сишный вариант делает это за полторы. на практике же оба за примерно пятнадцать, потому что i/o bounded. в среднем, файл на 500 кб с прогретыми кэшами загружается за 25-30 мсек, с непрогретыми за 60-100. поскольку EVE его сразу же и сканирует, то побочным эффектом получаем прогретые кэши. что довольно важно, потому что я стырил идею из BBCB, и использую оригинал как подкачку вместо полной загрузки в память.

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

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

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

а вы знаете, что… (блесполезное знание №очередной).

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

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

кстати, моя форт-система жутко напоминает модулу. в смысле, там всё почти упрятано в модули, допускаются вложеные модули, довольно много кода выглядит как «dart:cfa>pfa» («модуль:имя»). правда, модули ещё можно «доопределять» (расширять, то бишь; поскольку это просто словарики).

на самом деле всё ещё интересней, потому что к любому слову в системе можно подцепить личный словарик. к переменным, например, цепляется мини-словарик со служебными словами. получается так: «var» — значение. «var:!» — присваивание. «var:^» — адрес. причём всё это без хаков в системе и заглядывания вперёд по входному потоку (что требуется если делать Как Принято: «TO var», например). такое себе ООП.

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