OberonCore

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

то есть, поменять можно, конечно, но меня останавливает несколько вещей.

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

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

ну и третьи мелочи: всякие бленды и premultiplied alpha с opacity делаются в основном простыми умножениями. то есть, главное — premultiplied alpha — это просто `r * (a + 1) DIV 256`. а на самом деле `r * a DIV 256`, немножко неправильно, но фиг кто заметит. фиг с ним, конвертировать альфу просто в асм-коде ещё кое-как можно, но в sse… а, ну да, про sse я уже писал.

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


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

в общем, надо как-то себя убедить, что идеологическая правильность лучше сиюминутных практических выигрышей in the long run. (нет, блин, не лучше! никогда не окупится потому что, код для блендинга всегда будет тормозной и уродливый!)

в свете вот этого недоумения вытащил LSH и ROT из SYSTEM. ну камон, или трусы, или крестик. или BITS спрятать в SYSTEM (а поздно, ахахахаха… мяу, то есть), или уже вытащить две полезные штуки оттуда.

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

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

Т.к. разработки будущей Java покупали (?) Oberon у Н.Вирта, а не Н.В. покупал J у них, то ...

Позволю себе предположить, что Java сделана по мотивам Oberon.

P.S. Что там ( в Java) нового могли обнаружить создатели Component Pascal, просто не могу себе представить.

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

добавил слайсы, убрал из Files импорт SYSTEM. а, ну да, я в филесы добавил ReadSChars и WriteSChars, потому что заколебало. естественно, это были просто обёртки, которые транслировали массивы шортчаров в массивы байтов через THISARRAY. теперь — со слайсами — они опять не нужны, но пусть будут, мне лень код переделывать. а SYSTEM.THISARRAY там точно больше не нужен.

я, кстати, и в Stores добавил <Read|Write><Bytes|SChars>. я фиг знает, почему там этого нет. Stores удобно использовать для более высокоуровневой работы с файлами, но читать-писать блобы там тоже надо иногда. конечно, старый добрый цикл работает, но… зачем? это же очень и очень!

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

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

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

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

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

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

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

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

Оно да, просто модель бизнеса пытались создать с закрытыми компонентами.

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

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

омикам бы положить в поставку ещё и кодоген для жабки (жаль, что они его так и не отдали), и упирать на «write once, run everywhere», с дополнительной уберфичей «а кому мало, может делать нативный код без жывыэм» — может и взлетело бы. или найти где-то Много Денег, и фигакнуть пиар «элитный инструмент для элитных персон за много баксов» — может, удалось бы на элитарности как-то подняться.

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

всё как-то лапы не доходили, но однако перешёл на Fossil. иба ваистену. не переживайте, гит-репа осталась, фоссил туда зеркалит. только надо заново склонировать.

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

libfossil, конечно, проще, но я как-то привык по возможности максимум инструментов иметь на том языке, на котором пишу. да и в духе оберона будет: нам не нужны милости от природы, сделать свои — вот наша задача!

p.s.: надо бы ещё напрячься и сделать экспорт odc в фоссиловый маркап, чтобы хотя бы вацнью в фоссил-вики положить.

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

в принципе, то же самое можно сделать и в mainline: совместимость со старым кодом это не ломает вообще никак. единственная разница — если кто-то вдруг проверял секвенсеры через получение текстового имени типа: поскольку реэкспорт, то тип секвенсера теперь "Stores.Sequencer", а не "Sequencers.Sequencer". в смысле, в коде по-прежнему используется `Sequencers.Sequencer`, но штуки типа `Services.GetTypeName()` вернут другое. в среде я такого кода не нашёл, и не представляю, зачем бы он мог кому-то понадобиться. ну и можно сделать хак в "Services", если очень-очень надо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

так что массивы (эти деревья эмулируют именно массивы span'ов) со временем на поиск позиции/вставку/удаление O(log n), и O(1) на итераторы — очень полезная штука. (worst time is O(2*log n), если что, свойство AA trees.) один раз такое написал — и можно кучу гвоздей этим забить.

включить мозг и доказать правильность кода, или фигакнуть fuzzy-тест на недельку? какой сложный выбор… да ладно, шучу! конечно fuzzy-тест, пусть лошадь^w машина думает, она железная!

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

правда, это значит, что ещё и тестер надо портировать…