OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Сентябрь, 2023 23:17

Часовой пояс: UTC + 3 часа


Правила форума


Посмотреть правила форума



Начать новую тему Ответить на тему  [ Сообщений: 603 ]  На страницу Пред.  1 ... 12, 13, 14, 15, 16, 17, 18 ... 31  След.
Автор Сообщение
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Пятница, 26 Май, 2023 21:31 

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Пятница, 26 Май, 2023 21:35 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3732
arisu писал(а):
запилил асинхронную отсылку клипборда, если там овердофига данных (т.е. если надо слать по чанкам через INCR). и вообще: переделал весь клипборд на временные файлы вместо массивов в памяти. заодно бампнул количество и размер файловых буферов до 32 кб на файл.

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

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

заодно чуть-чуть поменял стратегию выбора файлового буфера, если свободных нет: раньше их тупо циклически перебирали, сейчас я выбираю буфер, который использовался «давнее всего». и ещё не пытаюсь читать с диска буфера при `SetPos()`: лишнее оно. достаточно просто запомнить новую позицию, а реально на диск сходить кода реальный i/o будет.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Пятница, 26 Май, 2023 23:26 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
Иван Денисов писал(а):
Звучит очень здорово! Когда отладите с удовольствием утащу в сборку. Судя по всем это ведь достаточно изолированные изменения, и перенести должно быть не так сложно.
если вы про файлы и буфера — то я весь код буферизации вообще выделил в HostIOBuffers, и использую вместо копипасты.

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Пятница, 26 Май, 2023 23:29 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
а если вы про клипбоард — то я ваще не знаю, я ж напрямую с иксами работаю, а у gtk там какие-то свои примочки, про которые я знаю только то, что знать о них не хочу ничего. ;-)

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Суббота, 27 Май, 2023 04:48 

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Суббота, 27 Май, 2023 05:11 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
и ещё немного экспериментов для любопытства.

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

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

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

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

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

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

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


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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Суббота, 27 Май, 2023 06:32 

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Суббота, 27 Май, 2023 17:34 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
вы, кстати, не знаете, а в LC есть поддержка шрифтов-размазни (antialiasing). сделана по просьбе уважаемого товарища luowy.

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 28 Май, 2023 00:12 

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 28 Май, 2023 02:27 

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 29 Май, 2023 06:28 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
снова разрешил битмаповый скролл. смотреть отсюда и дальше.

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

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 29 Май, 2023 09:45 

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 29 Май, 2023 10:11 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
вот как-то так эта эвристика выглядит.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 29 Май, 2023 10:18 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3732
Вот это хорошо вы придумали. Меня смущало, что на каждый пробел в русском тексте Блэкбокс создаёт отдельный кусок в текстовой модели. И такое решение не меняется совместимость, если я правильно понимаю.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 29 Май, 2023 10:54 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
Иван Денисов писал(а):
Вот это хорошо вы придумали. Меня смущало, что на каждый пробел в русском тексте Блэкбокс создаёт отдельный кусок в текстовой модели. И такое решение не меняется совместимость, если я правильно понимаю.
да, именно так. только не спешите пока брать, я там сонный фигню сделал. уже починил, вроде бы, но посплю — перепроверю.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 29 Май, 2023 10:59 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
вообще, для лога таки надо насильно undo выключать, оно только зря память транжирит там. к сожалению, если текстовая модель видит секвенсор (а они есть у каждого документа) — то автоматически делает undo. опять же: я посплю и может придумаю, как это красиво обойти малой кровью. тогда и лог станет значительно быстрее, потому что сможет пойти по тому же пути, что и текстовая модель без view и секвенсора.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 29 Май, 2023 16:46 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3732
arisu писал(а):
вообще, для лога таки надо насильно undo выключать, оно только зря память транжирит там. к сожалению, если текстовая модель видит секвенсор (а они есть у каждого документа) — то автоматически делает undo. опять же: я посплю и может придумаю, как это красиво обойти малой кровью. тогда и лог станет значительно быстрее, потому что сможет пойти по тому же пути, что и текстовая модель без view и секвенсора.

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 29 Май, 2023 19:34 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
по-моему, быстро должно быть всё. и всё равно вывод в системный лог в итоге попадает в одну и ту же модель. ну, там есть какая-то буферизация, но я и в ней особого смысла не вижу (как минимум в существующем виде).

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 29 Май, 2023 21:59 

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

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 29 Май, 2023 22:17 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1105
кстати. а вы в курсе, что текстовому потоку пофигу, какие символы в себе хранить, но в промежутке [0..255] он некоторые тупо выкидывает в окошко?
Код:
   IF ((ch >= 20X) & (ch < 7FX)
      OR (ch = tab) OR (ch = line) OR (ch = para)
      OR (ch = zwspace) OR (ch = digitspace)
      OR (ch = hyphen) OR (ch = nbhyphen) OR (ch >= 0A0X) & (ch < 100X))
   THEN
      WriteSChar(wr, SHORT(ch))   (* could inline! *)
   ELSIF ch >= 100X THEN


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

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

а, я там ещё кусочек с конвертацией некоторого юникода пропустил:
Код:
   ELSIF ch = 200BX THEN wr.WriteChar(zwspace)
   ELSIF ch = 2010X THEN wr.WriteChar(hyphen)
   ELSIF ch = 2011X THEN wr.WriteChar(nbhyphen)

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 603 ]  На страницу Пред.  1 ... 12, 13, 14, 15, 16, 17, 18 ... 31  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2023, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB