OberonCore

и, кстати, перевёл HostFiles/Lin с `Libc.FILE` на обычный fd-API. потому что использовать `fopen()` со товарищи там совершенно бессмысленно: среда и так делает буферизацию, накойфиг ещё и буферизация от либц? только зря память тратит.

надо бы ещё `New()` перевести на O_TMPFILE. потому что внутри у среды логика именно такая: новый файл безымянный, и в каталоге не шебуршится; имя ему нужно только при регистрации. вот тогда и звать "linkat 2".

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

если вы про файлы и буфера — то я весь код буферизации вообще выделил в HostIOBuffers, и использую вместо копипасты.

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

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

если про переход на fd-API, то тут даже не знаю… там довольно много мелких изменений, вы рискуете что-то пропустить (я и сам в несколько заходов делал, потому что провтыкивал ;-). ну, можно попробовать, если что — всегда можно откатиться. ;-) проблема в том, что `Libc.FILE` совместимо по присваиванию с fd (int), и если где-то забыть поменять, компилятор даже не квакнет, а последствия — сами понимаете. у меня HostFiles довольно сильно перелопачен, его просто копированием уже вряд ли пересадишь…

но это всё, конечно, не мешает попробовать. ;-) все изменения в HostIOBuffers и HostFiles/Lin, довольно изолированы, да.

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

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

по ходу, выяснил забавное: если отключить нафиг в TextModels оптимизацию кусочков для латиницы, и тупо совать всё в LPiece — то 140 мегов текста ящик прожевал без проблем, меньше чем за минуту. всё сложил в spill file, памяти отожрал меньше десяти мегов, работает шустро.

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

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

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

и ещё немного экспериментов для любопытства.

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

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

то есть, текст вставился, его нарисовали, каретка была в конце текста. я нажал C-PgUp, и всё сразу стало плохо, гыг.

отсюда несколько наблюдений.

первое: забирать у системы более 600-700 мб памяти никакого смысла нет, всё упадёт, но очень непредсказуемо. следовательно, надо поставить в кернале такое ограничение: пусть падает предсказуемо.

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

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


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


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

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

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

вы, кстати, не знаете, а в LC есть поддержка шрифтов-размазни (antialiasing). сделана по просьбе уважаемого товарища luowy.

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

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

короче, со сглаживанием тоже не всё так просто.

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

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

так что GC у ящика лучше, чем я там выше пугал. но эти случайные тормоза мне знатно помогли в разборках, так что это был полезный глупый баг.

и, кстати. я чуть-чуть переработал пастер (убрал одну лишнюю сериализацию), и ящик таки осилил 40 мб текста с разбивкой на кучу кусочков. и после того, как я убрал тормоза из GC — вы не поверите, но открытый документ вполне нормальный, и в среде можно работать без БОЛИ И УНИЖЕНИЙ. правда, что-то там он препроцессил полтора часа, и сожрал около 580 мб RAM (а потом пришёл GC, и ужал до 360). но сам факт! а, я ещё размер кластера бампнул до мегабайта (с 256 кб).

короче, отставить панику! GC в ящике великолепен.

предварительно — тормозит `TextModels.CopyOf()`, которая усердно копирует все кусочки.

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

битмаповый скролл отлично работает если не открыт ни один оверлей (меню или попап, например). соответственно, StdDocuments.Document должен блочить такие попытки, если у его оверлей болтается. стддок я научил, и в Views надо начинать спрашивать не с двух фрэймов выше, а с одного. я фиг знает, почему там делается сначала `f.up`, а потом ещё и проверяется на `g.up # NIL` вместо `g # NIL`. таким образом мы пролетаем мимо документа из текущего окна, и если оверлей открыт не в UltimateRoot, то ой, беда. а у меня такие оверлеи открываются (автодополнятор, например). также это не работает для detached windows.

короче, проверяю на `g # NIL`. хотя я вообще сильно подозреваю, что и `g := f.up` надо заменить на `g := f`, потому что текущий фрэйм тоже должен иметь право заблочить безобразие.

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

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

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

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

вот сейчас попробовал: а чего, идея-то рабочая! скопипастил текст на 140 мегов — ящик попыхтел секунд 10-15, и… работает! выжрал ~30 мегов памяти — мелочи. даже не тормозит. файл, если что — дамп базы от rss, там овердофига строк содержит кириллицу (а начинаются они все с латиницы, натурально).

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

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

вот как-то так эта эвристика выглядит.

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

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

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

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

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

не, ну можно после флаша лога просто undo чистить, но это всё равно лишние тормоза и разбазаривание памяти. GC потом соберёт, но зачем? это же очень и очень!

короче, буду думать.

У журнала есть два режима, один через Log, другой через StdLog, вот тот что через StdLog может быть медленный. Он скажем прокручивает документ до положения вывода. А вот Log нужен максимально быстрый. Вот там как раз undo нормально отключать.

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

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

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

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

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

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

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

p.s.: коммит. я там красиво зелёненьким всё выделил, и даже немного комментариев написал. смотреть `WriteSChar()`, и по аналогии в `EditOp.Do()`.

кстати. а вы в курсе, что текстовому потоку пофигу, какие символы в себе хранить, но в промежутке [0..255] он некоторые тупо выкидывает в окошко?

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

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

а, я там ещё кусочек с конвертацией некоторого юникода пропустил:

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

p.s.: в конвертере, кстати, забыли 2007X → digitspace. потому что рисовать дигитспейс надо именно этим, 08FX (которое в модели digitspace) — ни разу не юникодный символ, там на этом месте какая-то разлюли малина.