OberonCore

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

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




Начать новую тему Ответить на тему  [ Сообщений: 105 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 28 Январь, 2019 13:32 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
Программа, в которой присутствуют строки с KOI8R, нормально компилируется.


Последний раз редактировалось Kemet Понедельник, 28 Январь, 2019 13:41, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 28 Январь, 2019 13:39 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
budden писал(а):
А вот конструкция nnX точно не понимает ничего за пределами ASCII. С0X - это ошибка компиляции

Всё работает, просто такие литералы должны начинаться с цифры
VAR ch := 0FFX: CHAR;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 28 Январь, 2019 16:08 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Да, был неправ. На данный момент результат такой:
Код:
module z; import KernelLog;
procedure Do*;
var ю:array 20 of char; begin
ю := 'ddddd';
KernelLog.String("===="); KernelLog.Ln;
KernelLog.String(ю);KernelLog.Ln;
KernelLog.String("===="); KernelLog.Ln; end Do;
end z.

Compiler.Compile C:/ob/KOI8-program.Mod ~
SystemTools.Free z ~
System.Free z ~
z.Do ~

Если 'ddddd' заменить на кириллицу, то программа компилируется и без ошибки выполняется, но ничего не печатается.
Идентификатор ю проходит из-за баги в компиляторе, о которой я писал чуть выше. Экспортированное
в кириллице имя интерпретатор не видит. Итог: для поддержки KOI-8 тоже нужно потрудиться.
Спасибо! :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 29 Январь, 2019 14:20 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Чтобы два раза не вставать - ищу работу. Резюме здесь: http://программирование-по-русски.рф/static/Будяк-Денис-Валерьевич-2019-01-29.pdf

Из достигнутого в области Оберонов:

- содействовал в модернизации отладчика для ББЦБ (разобрался, как работает старый)
- форк ББЦБ с текстовым форматом исходных текстов и псевдо-текстовым - для составных документов - выступал заказчиком и руководителем проекта
- экспериментальное расширение компилятора ББЦБ для полиморфизма
- проект деобфускации компилятора ББЦБ - примерно 20% функций документировано и переименовано в более подробные имена (хотя, было ли это деобфускацией или дообфускацией - это вопрос во многом субъективный)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 01 Февраль, 2019 15:29 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Человек, которого я пытался кириллицей привлечь в комьюнити, уже отвалился, поэтому в кодировки можно пока и не лезть. Расшифруйте, пожалуйста:
Цитата:
и в UTF32 нельзя просто адресоваться по индексу, необходимо сканировать строку

В Википедии написано наоборот.
Цитата:
Остальное правится быстро по мере надобности. Дело в том, что есть коммерческий софт, основанный на А2. И нужны минимальные телодвижения, чтобы оно продолжало работать.

Сейчас это не очень актуально, но ведь мне никто не платит за поддержку этого коммерческого софта. Вот моя история с tcl/tk: http://core.tcl.tk/tk/info/62f1343ad2
Они просто, извините, положили с прибором на всех неанглоязычных пользователей. Развитие tcl/tk идёт весьма интенсивно, но на эту проблему они просто никак не отвечают. Помимо того, у них в редакторе при переносе строк посреди utf-8 возникают вместо буквы кириллицы всякие забавные значки. Это то, что я называю «как бы работает». Настоящих решения два - или 8-битная кодировка с нужным языком, или переопределение CHAR.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 01 Февраль, 2019 17:25 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
budden писал(а):
Цитата:
и в UTF32 нельзя просто адресоваться по индексу, необходимо сканировать строку

В Википедии написано наоборот.

Code point, к которым действительно прямая адресация, не равно "символ", так как как конечный символ может состоять из нескольких code point. Так устроен юникод. Поэтому и придётся сканировать строку, чтобы правильно её отрендерить/разбить...

Цитата:
Настоящих решения два - или 8-битная кодировка с нужным языком, или переопределение CHAR.

В той же UTF8 в любой позиции можно узнать - стартовая это позиция или нет, поэтому разбить правильно не проблема.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 01 Февраль, 2019 17:38 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Да, это бяка. Я бы сказал, что юникод - это бяка :) Мы в своё время думали-думали и пришли к тому, что наилучшим решением будет такое: строка - это массив графем. Потому что распад й на «и» и отдельную закорючку иначе как диверсией сложно назвать. Хотя наверняка найдётся язык (человеческий), в котором это не сработает. В музыкальном точно не сработает - там есть лига, которая применяется ни к одной ноте, а сразу к нескольким, и влияет на все.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 01 Февраль, 2019 17:45 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Но тут опять же - какова цель. Моя цель - хорошая поддержка РЯ, а не всех языков. Причём РЯ должен быть в приоритете. Все проблемы должны быть сброшены на иные языке. Ведь именно так и поступили американцы с utf-8. Не вылезаешь за ASCII - и всё вообще прекрасно. Это у других народов будут проблемы с отображением, поиском, и т.п. Причём совершенно конкретные: https://habr.com/ru/post/262679/

Для русского языка, равно как для совокупности русского, английского, и, скажем, греческого, нет никакой необходимости в кодировке, в которой какая-либо русская буква содержит несколько code points. Я бы разбил все тексты на «чистые» и «нечистые». Чистые нормализованы так, что й - это всегда й. А нечистые - это уже обычный юникод.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Февраль, 2019 01:27 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Kemet, зацените предложение по кодировке: оно позволяет сделать «всем хорошо» без глобальных переделок. Для полноценного включения кириллицы понадобится две вещи:

1. Небольшой фильтр на входе, к-рый перекодирует.
2. Везение (неиспользование особых не-ascii кодов букв для каких-то особых целей).

http://вики-ч115.программирование-по-русски.рф/Ч115/KOI-8RВПрограммах


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Февраль, 2019 12:00 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
Ну вот сейчас как сделано - открываешь текст в TextView - используются кодеки, приводя всё к единому виду внутри. Открываешь файл - работаешь напрямую. В последнем случае нужно в Streems добавить методы для работы с UTF8, ну или в сканер ( похоже это будет лучше на данном этапе ). И в сканере после получения правильной UTF8 Последовательности, преобразовывать в UCS4, которые использовать в CASE части метода GetNextToken ( вроде они нигде больше не нужны, так как ключевые слова и идентификаторы остаются в UTF8 ). Вместо строкового представления там же дальше используется хэш.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Февраль, 2019 13:56 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Проблема шире - CHAR везде и всюду используется для подписей в интерфейсе, которые вшиты в исходный текст. Моё решение делает строку простой, а не замороченной, в пределах кириллицы и латиницы. Литерал "ю" будет возможно присвоить типу CHAR, а при использовании UTF-8 этого сделать нельзя. Поэтому здесь вряд я вряд ли отступлю.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Февраль, 2019 15:17 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
budden писал(а):
Проблема шире - CHAR везде и всюду используется для подписей в интерфейсе, которые вшиты в исходный текст.
Там отлично живёт UTF8, более того, встроенный транслятор переводит надписи на нужный язык.
budden писал(а):
Литерал "ю" будет возможно присвоить типу CHAR, а при использовании UTF-8 этого сделать нельзя.
А это действительно нужно, использовать CHAR? Вполне можно использовать какой-нибуть UTF8Strings.Char.
Ну вот в Виндовс у нас будет CP1251, в Линукс KOI8 ( хотя у меня там везде UTF8 ), в Солярисе? в Дарвине?, в...? в А2?..... UTF8 потому и выбрана, что это достаточно универсальная и оптимальная транспортная кодировка. К тому-же в А2 она поддержана. Затачивать А2 под никому не нужную KOI это вообще убить всё.
Вообще уже обсуждалось, использовать в качестве строк массивы символов напрямую требуется лишь на системном ( или нижнем, по отношению к некой конструкции ) уровне. На прикладном это должны быть более высокоуровневые конструкции с собственным набором операций. Пока что я с этим согласен.

Я не вижу действительной необходимости держать всё в однобайтовом CHAR. UTF8 нормально отрисовывается на всех виджетах. В компиляторе UTF8 тоже вполне себя нормально может чувствовать.
Закукливание (особенно с использованием странных штуковин) это путь в тупик. А ведь даже бронепоезд стоит не в тупике, а на запасном пути.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Февраль, 2019 15:42 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Мне кажется, я привёл массу примеров на тему того, почему наличие типа для буквы важно. Могу привести ещё. По файлам .mod я нахожу 30 файлов с вхождением строки «'z'». Если мы хотим поддержать кириллицу, из них где-нибудь 25 придётся переработать. Заглядываем в первый попавшийся и видим: (CAP(char) <= 'Z') . Если мы хотим тут добавить ветку для кириллицы и строка в берём utf-8, то мы не сможем сделать char<='ю', потому что 'ю' в utf-8 - это не CHAR. Нам придётся в каждое такое место втыкать парсер utf-8, добавлять несуществующий CHAR32 (или, ещё хуже, суррогатный Char32, равный Longint, и массированно менять все типы во всех исходниках, где нас интересуют буквы и их диапазоны. Всё это непросто и даже нелинейно.

Моё решение будет иметь проблемы в отдельных местах, но их можно локализовать, поискав, где используется utf-8. Решение будет линейным.

При этом я не посягаю на внешнее представление. В файлах пусть будет utf-8. Моя кодировка - это по смыслу то же, что utf-8, но кодирование происходит другим КА. Т.е. можно не менять ни типы данных (CHAR остаётся CHAR-ом), ни структуру кодировщика. Просто нужно клонировать кодер-декодер utf-8 и вставить преобразование из/в utf-8 там, где происходит взаимодействие с внешним миром. Из проблем здесь, пожалуй, можно придумать только переполнение ARRAY OF CHAR, но оно и с utf-8 может случиться. Просто здесь оно может случиться в более неудобном месте.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Февраль, 2019 16:37 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
Проблема Оберона - разобщённость. Начиная с языка, форматов и тд. Да даже BlackBox уже разошёлся минимум на 3 ветки. В Реальности больше.
С A2 ситуация более удачная на данный момент. И хочется чтобы так и оставалось. Если заточить на какую-то закукленную ( и по сути мёртвую ) кодировку, то разобщённость только увеличится. Это уже проходили, когда в Оберон так же зашили свою кодировку с немецкой( вроде) ориентацией, и оно частично перетекло в A2. От этого избавила UTF8. Сейчас ты предлагаешь наступить ровно на те же самые грабли. Никому это не нужно. Как быть разработчикам из Франции, Германии, Китая, Кореи, хе, да из Казахстана, если там хрен знает что? Фтопку КОИ.
Я спорить на эту тему больше не буду, потому что не вижу в этом никакого смысла. Ни в какой-то особой кодировке, ни в споре.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Февраль, 2019 17:46 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Ну, я вообще изначально собирался делать со временем форк. Вопрос лишь о том, в какой момент это случится. Если хотите, чтобы нам какое-то время было по пути и я помогал общему развитию, то нужен хотя бы план этого развития - а такого плана нет. Т.е. мне даже не с чем сверяться. Как я тогда могу понять, по пути мне с вами или нет? Пока что вы мне предлагаете постулировать, что мои хотелки никогда не будут воплощены, поскольку я должен заботиться о ваших контроллерах и о разработчиках из Кореи. Это как бы не самый конструктивный вариант. А конструктивные варианты при этом существуют. Можно было бы параметризовать систему и позволить национально-ориентированные сборки с любой внутренней кодировкой. Это нелегко, но возможно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Февраль, 2019 17:59 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
Ну во так же подумают и китайцы и забьют болт, ну иероглифы в А2 на всех уровнях, ну а что, зачем им кириллица. Одна контора так и хотела поступить, к счастью, мы пересеклись с девушкой из той организации до того, как они начали пихать везде иероглифы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Февраль, 2019 18:19 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Ну и как они обошлись без пихания иероглифов? Их пользователи смирились читать всё по-английски или какой-то другой вариант? И какой профит сообществу? Присылают что-нибудь корейцы-китайцы в паблик?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Февраль, 2019 18:24 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 293
Откуда: Russia
Ооо, я помню чудные мгновения в Лазарусе с зоопарком кодировок на нижележащем слое. Частично это решилось введением UTF8. Так что это наименьшее зло. Хотя меня бы устроло наличие UTF16 в а2 начиная с ядра. А то в компиляторе CHAR16/CHAR32 вроде как есть, но сделать с ними ничего нельзя! Допилил бы уже, а?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Февраль, 2019 18:28 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Kemet, а utf-16 пойдёт для ваших контроллеров? Он лучше utf-8 тем, что он обостряет проблему перехода, и не такой жирный. То, что не переделано, выскакивает сразу. Utf-8 позволяет глюкам существовать годами (как в tcl/tk). Хотя я бы сразу ориентировался на флагмана мирового развития и взял бы GB18030 - вроде там кириллица двумя байтами и при этом ё на своём месте.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Февраль, 2019 18:37 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Baikal писал(а):
Допилил бы уже, а?

Сначала переход к определению, потом можно и за это взяться. Пока готовьте ТЗ с учётом всех нюансов, чтобы потом не переделывать.


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

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


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

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


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

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