Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 23 апр 2017, 17:39

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




Начать новую тему Ответить на тему  [ Сообщений: 20 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: 31 мар 2013, 20:02 
Не в сети
Аватара пользователя

Сообщения: 791
Откуда: Днепропетровская обл.
Наконец-то я добрался и освоил автоподсветку синтаксиса. Хоть комфортно работается и без этого, но в ряде случаев с ней всё-таки приятнее. Подсистема «Мастер» С.Ю. Губанова для раскраски синтаксиса модулей на языках Оберон/Компонентный Паскаль. Вероятно, это самое зрелое и функциональное из имеющихся решений для цветной подсветки синтаксиса в среде BlackBox.

Сопутствующие темы:


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

P.S. Для схожих целей кроме подсистемы «Мастер» знаю ещё CpcBeautifier и Smart (Boris Ilov). Последнюю тестировал, тоже неплохо работает (для ядра 1.6 пришлось чуть-чуть допилить чтобы убрать зависимость от National).


Вложения:
Комментарий к файлу: Подсистема «Мастер» для BlackBox 1.6
MasterBB1.6.7z [47.71 КБ]
Скачиваний: 171
Комментарий к файлу: Подсистема «Smart» для BlackBox 1.6
SmartBB1.6.7z [7.64 КБ]
Скачиваний: 118
Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 03 апр 2013, 15:50 
Не в сети
Аватара пользователя

Сообщения: 791
Откуда: Днепропетровская обл.
Сергей Юрьевич постарался и сделал действительно прекрасную подсистему с гибкими настройками, как раз в духе Оберон-технологий. Чем больше её использую — тем сильнее нравится.

Обновил архив MasterBB1.6.7z в первом посте. Добавлена служба раскраски MasterService, введён механизм работы с текстовыми исходниками (для этого необходимо дополнительно зарегистрировать конвертеры из ColorViews.odc на желательное расширение модулей. Просто добавьте в System/Mod/Config.odc пару строк:
Код: "OBERON"
  1. Converters.Register("MasterColorViews.ImportText", "MasterColorViews.ExportText", "MasterColorViews.View", "mod", {Converters.importAll});
  2. Converters.Register("MasterColorViews.ImportText", "MasterColorViews.ExportText", "MasterColorViews.View", "def", {Converters.importAll});
И перекомпилируйте модуль Config. Также я добавил поддержку кодировки Win1251, поскольку большинство текстовых исходников у меня хранится именно в ней.

Ну и вот какая пока нарисовалась схема раскраски. Возможно, пёстровато, и лучше было бы поскромнее (примерно как в Дельфи), но пока что мне нравится.


Вложения:
Redirect.png
Redirect.png [ 20.82 КБ | Просмотров: 3426 ]
Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 04 апр 2013, 21:03 
Не в сети

Сообщения: 58
Перебор кодов символов в цикле (процедура WideCharToCP1251) не слишком быстрый приём.
Я для этого воспользовался хэш-таблицей. Одна хэш-таблица обслуживает кодировки CP1251, KOI8R, KOI8U, CP866 и ISO-8859-5.
Модуль включен в репозиторий операционной системы A2 (AOS, Bluebottle).


Вложения:
CyrillicUtilities.7z [6.29 КБ]
Скачиваний: 129
Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 04 апр 2013, 23:44 
Не в сети
Аватара пользователя

Сообщения: 791
Откуда: Днепропетровская обл.
Исходники модулей, на которые рассчитан мой перекодировщик в CP1251, вряд ли будут многомегабайтными. Я применил самый компактный приём, который в данном случае обеспечивает весьма приемлемое быстродействие, и даже оптимизировал его, сделав поиск по циклу, начинающийся с конца таблицы — ведь те русские буквы, которые встретятся в исходниках — это, в основном, немногочисленные комментарии, и буквы в них чаще будут строчными, чем заглавными (а строчные в CP1251 — как раз в конце таблицы). Конечно поиск по хэш-таблице, возможно, имеет некоторое преимущество в скорости и, безусловно, является более универсальным решением, но он и более громоздок и ёмок по расходу памяти. Короче говоря, памятуя советы классиков оптимизировать только там, где это действительно необходимо, не уверен, что в данном случае стоит стрелять из пушки по воробьям.

P.S. Не стремлюсь предельно оптимизировать по скорости этот вариант ещё и потому, что понимаю, что в итоге всё равно придётся переходить на UTF-8 или юникод.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 05 апр 2013, 12:01 
Не в сети

Сообщения: 58
Да, мой модуль отводит сейчас порядка 17 Кб памяти под данные, но и поиск соответствия юникодовского символа к однобайтовому выполняется без единой коллизии в хэш-таблице, т.е. гарантированно за время O(1).
Можно уменьшить размер таблицы руководствуясь рекомендуемым фактором заполнения хэш-таблиц не более 63% и тем фактом, что все поддерживаемые модулем кодировки в сумме дают всего 185 разных символов юникода. Получаем таблицу размером 307 элементов.
Плюс, если уменьшить статические кодовые таблицы (используются для конвертации из однобайтовых кодов в юникод и для инициализации хэш-таблицы) до 128 элементов, а не так расточительно как это сделано у меня (256 элементов)...
Итого, будет необходимо 6551 байт суммарно под все статические кодовые таблицы и одну хэш-таблицу, или около 1310 байт на обслуживание одной кодировки.
В твоей реализации, Олег, нужно всего 512 байт под одну кодовую таблицу. Т.е. разница где-то в 2,5 раза.
Программистам всегда приходится решать известную дилемму (память/производительность) :)
Я когда делал свою реализацию, прицеливался не столько на программные тексты сколько на вёрстку HTML страниц с использованием AOS. Тут при размере текста в пару десятков - сотню килобайт уже начинают ощущаться тормоза от конвертации кодировок.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 05 апр 2013, 13:26 
Не в сети
Аватара пользователя

Сообщения: 791
Откуда: Днепропетровская обл.
sage писал(а):
В твоей реализации, Олег, нужно всего 512 байт под одну кодовую таблицу. Т.е. разница где-то в 2,5 раза.
Не 512, а 256, ибо символов 128, а тип CHAR в КП/ББ занимает 2 байта (и здесь возможно замедление поиска из-за невыравненных данных). Но зачем изобретать себе проблемы, если всё равно придут толпы злых линухоидов и скажут, что 1251 это отстой, а рулит если не KOI-8R, то, в крайнем разе, UTF-8. Там у тебя в процедуре hashSearch ещё масса проверок и вычислений, так что разница в скорости будет действительно минимальной. Мой вариант прост как гвоздь и не универсален. Но если хочешь, Ярослав, специально для тебя сделаю вариант с хэш-таблицей. Если ты действительно собираешься пользоваться XDev, и все исходники у тебя тоже в кодировке 1251. :) Выйгрыша будет немерено, порядка десятков микросекунд при экспорте каждого исходника. ;)

sage писал(а):
Я когда делал свою реализацию, прицеливался не столько на программные тексты сколько на вёрстку HTML страниц с использованием AOS. Тут при размере текста в пару десятков - сотню килобайт уже начинают ощущаться тормоза от конвертации кодировок.
Ну, другое дело. Если бы я делал часть ОС, и нужно было бы универсальное и максимально быстрое решение для работы с несколькими кодировками, — скорее всего, применил бы не передачу кодировки параметром в hashSearch(KOI8U, FALSE, ch, c), а сделал бы различные процедуры: hashSearchKOI8U, hashSearchCP1251 и т.д. Так было бы ещё быстрее, чем доп.параметр + проверка какую кодировку использовать, и ещё менее компактно. Надо просто тестировать разницу в скорости.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 05 апр 2013, 15:03 
Не в сети

Сообщения: 58
Zorko писал(а):
Не 512, а 256, ибо символов 128, а тип CHAR в КП/ББ занимает 2 байта
Я бы отводил и 2 байта, но в AOS в угоду универсальности поддерживаются 4-х байтовые коды юникода для поддержки всех возможных языков :)
Zorko писал(а):
Выйгрыша будет немерено, порядка десятков микросекунд при экспорте каждого исходника. ;)
Согласен, на исходниках выигрыша действительно будет немерянно :lol: Но если делать систему вёрстки HTML выигрыш уже будет вполне ощутим.
Zorko писал(а):
Так было бы ещё быстрее, чем доп.параметр + проверка какую кодировку использовать, и ещё менее компактно. Надо просто тестировать разницу в скорости.
Опять компромисы между скоростью и занимаемой памятью, дополнительные процедуры займут ещё чуть больше памяти но и чуть добавят скорости. Нет предела совершенству ;)


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 10 апр 2013, 12:52 
Не в сети
Аватара пользователя

Сообщения: 791
Откуда: Днепропетровская обл.
sage писал(а):
Я бы отводил и 2 байта, но в AOS в угоду универсальности поддерживаются 4-х байтовые коды юникода для поддержки всех возможных языков :)
Отводить 2 байта всё равно можно, если использовать для таблицы кодов тип INTEGER (который в AO занимает 2 байта), а при сравнении переводить числа в символы, но поскольку двухбайтовые числа не выравнены на границу 4-х байт — будут потери скорости. Я и так слегка удивлён, что ты не использовал константные массивы для таблиц (ведь в AO это, кажется, можно). Я пробовал задать таблицу не одиночными присваиваниями, а сразу строкой:
Код: "OBERON"
  1. CP1251 := 01X + 02X ... ;
Но для двухбайтовых символов в ББ такая конструкция почему-то не компилируется.

Сейчас меня больше интересует другой вопрос: почему если открыть документ .odc и сохранить его как (File -> Save As...), то в списке расширений не появляется зарегистрированный нами формат Mod? Неужто надо ещё где-то дополнительно регистрировать?


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 03 июл 2013, 18:51 
Не в сети
Аватара пользователя

Сообщения: 791
Откуда: Днепропетровская обл.
Столкнулся с ошибкой в модуле Master/Mod/ColorViews.odc, которую даже не знаю как исправлять (ввиду слабого знания BlackBox API). Ошибка проявляется при наличии в автоподсвечиваемом исходнике маркеров. При этом первый раз не срабатывает копирование выделенного текста. Воспроизвести можно так. Откройте, например, модуль WinDev/Mod/ASCII.Mod, внесите искусственно ошибку, скомпилируйте (F11) и, когда маркер ошибки появится, выделите любой фрагмент текста и скопируйте его (Ctrl+C или выбором «Копировать» в контекстном меню, без разницы). Теперь если вставить текст из буфера — это не будет скопированный только что фрагмент. Но если скопировать повторно, во второй раз, тогда скопируется. Ошибка эта не очень критична, но конечно некрасива, и исправить надо, так что буду рад помощи или совету.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 28 авг 2013, 21:22 
Не в сети
Администратор
Аватара пользователя

Сообщения: 221
Откуда: Россия
Zorko писал(а):
Столкнулся с ошибкой в модуле Master/Mod/ColorViews.odc, которую даже не знаю как исправлять (ввиду слабого знания BlackBox API). Ошибка проявляется при наличии в автоподсвечиваемом исходнике маркеров. При этом первый раз не срабатывает копирование выделенного текста. Воспроизвести можно так. Откройте, например, модуль WinDev/Mod/ASCII.Mod, внесите искусственно ошибку, скомпилируйте (F11) и, когда маркер ошибки появится, выделите любой фрагмент текста и скопируйте его (Ctrl+C или выбором «Копировать» в контекстном меню, без разницы). Теперь если вставить текст из буфера — это не будет скопированный только что фрагмент. Но если скопировать повторно, во второй раз, тогда скопируется. Ошибка эта не очень критична, но конечно некрасива, и исправить надо, так что буду рад помощи или совету.
Покопался в потрохах ББ и вот что удалось понять (не претендую на полное знание этих "потрохов", выяснял больше методом тыка :) ).
ColorViews отслеживает события Controllers.EditMsg в процедуре PROCEDURE (v: View) HandleCtrlMsg*(...). Это ввод\удаление символа и операции с буфером обмена , в т.ч. и Ctrl+C «Копировать». На каждую такую операцию происходит перераскраска отображения (View) текста программы (Text). При ошибке Ofront вставляет в текст маркер ошибки, но это не событие EditMsg, поэтому ColorViews пока об этом не знает. Мы выделяем текст, но это тоже не EditMsg. А теперь нажали Ctrl+C - вот это уже EditMsg! HandleCtrlMsg запускает Colorize, определенную в этом же модуле, в которой вызывается MasterColors.ColorizeText. ColorizeText просматривает текст, видит маркер ошибки и изменяет его атрибуты на "лучшие" с точки зрения этого Мастера. Текст оповещает все свои отображения, что он изменился, в результате чего выделение сбрасывается и в буфер нечего копировать. Поэтому копирование не срабатывает.
Почему оно срабатывает в следующий раз? А потому что атрибуты у маркера ошибок уже "хорошие" с точки зрения Мастера, поэтому они не меняются и текст не посылает сообщение своим вьюшкам об обновлении.
Поэтому же не мешает копированию в буфер маркер ошибок, появляющийся по Ctrl-K, потому что у него изначально "хорошие" текстовые атрибуты. А может совсем атрибуты при вставке не задаются или вставляется маркер каким-то образом, что Мастер это замечает и успевает атрибуты сменить. Кстати, видно, что маркеры по Ctrl-K и по F11 отличаются, а после нажатия любой клавиши маркер Ofront'a превращается в «стандартный».
Если изменить атрибуты какого-то участка текста, то Ctrl+C тоже не сработает, пока Мастер не изменит эти атрибуты в соответствии со своими правилами.
Для Ctrl+C «Copy» исправить это несложно. Ведь эта команда не изменяет текст, а значит и перекрашивать его не надо. Поэтому изменим в модуле MasterColorViews процедуру
Код: "OBERON"
  1. PROCEDURE (v: View) HandleCtrlMsg* (f: Views.Frame; VAR msg: Controllers.Message; VAR focus: Views.View);
  2. BEGIN
  3. WITH
  4. | msg: Controllers.EditMsg DO
  5. IF msg.op # Controllers.copy THEN (*добавили вот это условие*)
  6. v.Colorize(); v.needRefresh := TRUE
  7. END
  8. | msg: Controllers.TickMsg DO
  9. IF v.needRefresh THEN v.needRefresh := FALSE; v.Colorize() END
  10. ELSE
  11. END;
  12. focus := v.inner;
  13. END HandleCtrlMsg;
  14.  

Всё бы хорошо, но такая же проблема и с операцией Ctrl-X “Cut”. Можно конечно написать
Код: "OBERON"
  1. IF (msg.op # Controllers.copy) & (msg.op # Controllers.cut) THEN
  2. v.Colorize(); v.needRefresh := TRUE
  3. END
но это неправильно, потому что вырезание как-раз меняет текст, в результате чего может измениться окраска — попробуйте, например, вырезать в буфер часть ключевого слова. Так что для Ctrl-X “Cut” проблема пока открыта.


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 20 ]  На страницу 1, 2  След.

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


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

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


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

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Тех.поддержка phpBB