OberonCore

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

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




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

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 293
Откуда: Russia
Да вроде бы в сообщении о языке


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Я имею в виду, где это закодировано. Впрочем, не так уж важно это.


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
А кстати я не могу найти сообщение о языке. Упоминание о типах CHAR16 есть только в википедии, но оттуда я не могу по ссылкам найти документ или хотя бы связанную цепочку документов, в которых было бы чётко показано, что в A2 есть CHAR16. Может кто-нибудь подсобить? Часть ссылок здесь вообще битые. http://www.ocp.inf.ethz.ch/wiki/Documentation/Language


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

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
В A2 нет CHAR16 и CHAR32. Используется CHAR и ARRAY OF CHAR, который, в то же время, строка в UTF8. В подсистеме Text используется Texts.Char32, и ARRAY OF Texts.Char32. Это UCS4.
Репорт устарел, нового пока нет, так как состояние языка пока не зафиксировано. Можно глянуть в FoxParser.Mod текущее состояние - там везде расставлено формальное описание конструкций. Можно, также, сгенерировать документацию


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
А есть возможность использовать кодовые страницы, хотя бы KOI-8R?


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
KOI-7 H1 :twisted:

Код:
      процедуре сЕТ* (ЦОЛОР, БГЦОЛОР, ЖОФФ : лонгинт; цонст НАМЕ : арраы оф цхар; СИЗЕ : лонгинт; СТЫЛЕ : сет);
      бегин
         селф.ЦОЛОР := ЦОЛОР;
         селф.БГЦОЛОР := БГЦОЛОР;
         селф.ЖОФФ := ЖОФФ;
         нев(ФОНТиНФО);
         цопы(НАМЕ, ФОНТиНФО.НАМЕ);
         ФОНТиНФО.СИЗЕ := СИЗЕ;
         ФОНТиНФО.СТЫЛЕ := СТЫЛЕ
      енд сЕТ;

Сразу и ключевые слова в нижнем регистре...


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

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
Цитата:
А есть возможность использовать кодовые страницы, хотя бы KOI-8R?

Использовать где? Если учесть, что Text - UCS4, а остальное, где руки дотянулись, UTF8. Есть также конвертеры CyrillicUtilities.Mod, куда можно добавить KOI-7( KOI-8R есть ). Есть подсистема IME


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

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


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

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
Если компилировать из IDE, то можно выбрать Format.
В остальном нет. Лучше допилить до глобального использования UTF8


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Вот в этом фрагменте кода из FoxScanner.mod что Вы понимаете под «глобально использовать utf-8?»

Код:
WHILE (s # EndOfText) & (s # End) & (s # With) & (s # Unequal) DO
 token.position := position;
 endPos := position.start;
 IF (ch >= 'A') & (ch <= 'Z') OR (ch >= 'a') & (ch <= 'z') THEN
  newline := FALSE;
  GetIdentifier(token);


Здесь ch - глоб. перем типа CHAR, которая получается с помощью Streams.Reader.Char . Если мы мыслим в терминах байт и хотим сюда запихнуть кириллицу, то в этом месте нужно парсить utf-8. Если же мы хотим использовать какой-нибудь условный Utf8String.Reader.Char, то ch должно уже быть чем-то типа ucs-4, и нужно менять все места, где оно используется, и дальше вниз по течению заменять CHAR на Char32. Может я что-то не понял, но мне кажется, что некорявое решение здесь только через ucs-4, а оно довольно трудоёмкое.


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Слегка покопался и упёрся в то, что CHR может вернуть только ASCII. Т.е., KOI-8 не поддерживается. Вот до чего доводит увлечение Utf-8. А зачем оно вообще нужно? Я согласен, что оно неизбежно в использовании в интернете, т.е., безусловно, нужно уметь читать и писать файлы в этой кодировке. Но внутренне представление в utf-8 - это не более, чем кривой костыль для того, чтобы не переделывать работающие юникс-программы. При этом, в рамках ASCII они действительно продолжают работать, а вне оного встречаются глюки, которых я уже наелся в tcl/tk. Я попробовал компилировать с форматом KOI-8R в PET - что-то успехов никаких. Судя по выводу вот этой программки
Код:
MODULE z;
IMPORT KernelLog;

PROCEDURE Do*; VAR z:ARRAY 3 OF CHAR;
BEGIN
z := 'ю';
KernelLog.Ln;
KernelLog.String(z);
KernelLog.Ln;
KernelLog.String("First char: ");
KernelLog.Int(ORD(z[0]),0);
KernelLog.Ln;
KernelLog.String("Second char: ");
KernelLog.Int(ORD(z[1]),0);
KernelLog.Ln;

END Do;
END z.

независимо от формата файла, содержащего эту программу (а это KOI-8R и в PET тоже установлено KOI-8R) всё равно буква 'ю' при чтении превращается в utf-8. Т.е. наивная надежда получить внутреннее представление строк в KOI-8R сразу же разрушилась.

Я уже давно пришёл к выводу, что utf8 - это империалистическая
кодировка, которая решает проблемы США за счёт остальных стран. Поскольку я вообще полез в эту A2, чтобы сделать «учебную русскоязычную ОС» или продукт для собственного употребления, в котором не будет дискриминации русского языка, то я категорически не принимаю использование utf-8 для внутреннего представления строк. Если я не осилю это переделать, то этот продукт просто не для меня. Дальше вопрос к Вам, kemet, как к одному из представителей сообщества A2 - что Вы думаете на тему замены utf8 внутри везде на UCS4 (или 16-разрядную, если китайцев побоку) кодировку, допиливания типа CHAR32 или CHAR16? И что на эту тему думает сообщество? Всё же Texts.Char32 - это не более, чем псевдоним для LONGINT. Такой уровень сервиса со стороны компилятора явно недостаточен.


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

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
budden писал(а):
Если мы мыслим в терминах байт и хотим сюда запихнуть кириллицу, то в этом месте нужно парсить utf-8
Если работать в PET, то внутри UCS4 или UTF8. Конвертеры преобразуют в эту форму.
Если же в PET написать программу в KOI8R, сохранить на диск и компилировать командой Compiler.Compile, то компилятор работает с файлом напрямую через потоки, и там прочитается то, что ты записал - байт c символом в KOI8R. Но как по мне все эти кодировки маразм чистой воды. Распарсить UTF8 не большая проблема. Но я так и не понял, зачем тебе это.


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

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
budden писал(а):
...замены utf8 внутри везде на UCS4...

UTF-8 это представление кодами переменной длинны символов Unicode. UCS-4 (UTF-32) тоже самое, только 32-битными целыми. Шило на мыло?

И при всё уважении к ГОСТ (в данном случае это ГОСТ 19768-74), KOI-8R -- жуткий анахронизм, кстати, зафиксированный уже даже не в ГОСТ, а в RFC1489. Там даже порядок букв через одно место, чтобы коррелировать с латиницей.


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

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
budden писал(а):
Слегка покопался и упёрся в то, что CHR может вернуть только ASCII.

CHR и ORD дают обратимый результат:
Цитата:
MODULE Test;

PROCEDURE Do*;
VAR x, y: LONGINT; ch: CHAR;
BEGIN
x := 254;
ch := CHR(x);
y := ORD(ch);
TRACE( x, y );
END Do;

END Test.Do ~

Вывод: {P cpuid= 0, pid= 11804 Test.Do@107:x= 254; y= 254; }
Цитата:
Судя по выводу вот этой программки

Всё, что заключено в кавычки это, в общем случае, строковой литерал и могут быть, на первый взгляд, странности, потому что подсистема Text юникодная.
А вот символы вида 09X никуда не конвертируются.


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Kemet писал(а):
budden писал(а):
Если мы мыслим в терминах байт и хотим сюда запихнуть кириллицу, то в этом месте нужно парсить utf-8
Если работать в PET, то внутри UCS4 или UTF8. Конвертеры преобразуют в эту форму.
Если же в PET написать программу в KOI8R, сохранить на диск и компилировать командой Compiler.Compile, то компилятор работает с файлом напрямую через потоки, и там прочитается то, что ты записал - байт c символом в KOI8R. Но как по мне все эти кодировки маразм чистой воды. Распарсить UTF8 не большая проблема. Но я так и не понял, зачем тебе это.

Compiler.Compile с единственным параметром - путём к файлу с кириллицей в KOI-8R - говорит "illegal character in string". Т.е. я так думаю, что внутри компилятора зашито мнение о том, что файл закодирован в utf-8. Параметра про кодировку или формат я в FoxCompiler.mod не нашёл. Нужно мне это для русскоязычных идентификаторов, как в ББЦБ, чтобы писать «PROCEDURE Печатай» и т.п.


Последний раз редактировалось budden Понедельник, 28 Январь, 2019 09:45, всего редактировалось 2 раз(а).

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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Цитата:
MODULE Test;

PROCEDURE Do*;
VAR x, y: LONGINT; ch: CHAR;
BEGIN
x := 254;
ch := CHR(x);
y := ORD(ch);
TRACE( x, y );
END Do;

END Test.Do ~

Отсутствие документации печалит. Согласно документу A2 Programming Quickstart GUide от 2010 CHR и ORD понимают только ASCII. Теперь получается, что это неправда. А вот конструкция nnX точно не понимает ничего за пределами ASCII. С0X - это ошибка компиляции, поэтому задать таким видом «ю» не выйдет. Да его и не будет во входном потоке (насколько это пока что показывают эксперименты), а вместо него будет 209 и 142 последовательно. Спасибо за TRACE :) .


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

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


Правда, TRACE уже не смог напечать имя «ю», т.е. в любом случае похоже, что обход всего с вмешательством повсюду неизбежен. Потому что чтение идентификатора - одно, чтение строки - другое, печать - третье. Именно поэтому введение типа для литер в кодировке UCS4 (например, CHAR32), позволяет создать уровень абстракции, при котором труда понадобится меньше.


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

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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Понял, я не там пропатчил. В общем, похоже, что можно как-то пинками заставить работать KOI-8R, например, однобуквенные идентификаторы в KOI-8R уже работают (см. код GetNextSymbol и в конце его ELSE, которая считает, что всё непонятное - это начало идентификатора - скорее всего это баг, но в данном случае он полезен!). Но это всё неправильно. Если у нас культ простоты, то должен быть один тип CHAR. Если мы дружим с CJK, то 32 бита. Если нет - то 16. При этом мы понимаем, что простота имеет свою цену. Например, нам может понадобиться более мощный компьютер для решения простой задачи. Это входит в цену простоты - зато у нас только один CHAR, а не несколько, определения типов и их конвертация упрощается. А также должен быть тип BYTE.


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Борис Рюмшин писал(а):
Шило на мыло?

Отнюдь. Хотя бы возьмите операцию взятия i-го элемента строки. Но вообще разница очевидна, странно, что тут вопрос возникает.

Цитата:
Там даже порядок букв через одно место, чтобы коррелировать с латиницей.

В utf-8 всё ещё хуже - там русских букв как объекта в памяти вообще нет. При чтении из потока это две идущих подряд буквы, т.е. все алгоритмы работы с текстом резко усложняются и требуют ручной переработки с привлечением ума. 8-битная кодировка мне не особо нравится, но если рассчитывать только на свои силы, то выкинуть utf-8 и перейти на 8-битную кодировку в компиляторе мне по силам. А вот допилить полноценную поддержку юникода - уже вовсе не факт. Т.е. решения принимаются исходя из наличных ресурсов.


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

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
budden писал(а):
Дальше вопрос к Вам, kemet, как к одному из представителей сообщества A2 - что Вы думаете на тему замены utf8 внутри везде на UCS4 (или 16-разрядную, если китайцев побоку) кодировку, допиливания типа CHAR32 или CHAR16? И что на эту тему думает сообщество? Всё же Texts.Char32 - это не более, чем псевдоним для LONGINT. Такой уровень сервиса со стороны компилятора явно недостаточен.

UTF8, на мой взгляд, хорошая транспортная кодировка. Для чтения и записи достаточно байтового потока. Данные могут храниться в обычных однобайтовых строках и это хорошо, так как переделки заключаются в увеличении длины строки и использованиb процедур из USF8Strings вместо Strings, а это делается простой заменой в импорте Strings := UTF8Strings. Остальное правится быстро по мере надобности. Дело в том, что есть коммерческий софт, основанный на А2. И нужны минимальные телодвижения, чтобы оно продолжало работать. Вспоминается эпичный период, когда в Дельфи таки решили перейти на юникод, поломав многое из того, что работало.
В чем-то UTF8 не оптимальна, но глобальное использование UTF32 это вообще маразм - чудовищный оверхед и это, в общем-то мало чего решает, так как и в UTF32 нельзя просто адресоваться по индексу, необходимо сканировать строку. Да, в гораздо меньших объемах чем UTF8 или UTF16, но всё же. Единственный плюс - более-менее прямое использование таблиц преобразования.
С UTF16 другая проблема - суррогаты, хотя он более оптимальный по хранению, но и технокалия больше. Но всё-же UTF16 хороший выбор для подсистемы Text, в которой сейчас UCS4.
Я думаю, что нельзя оставить один тип. Мне в микроконтроллерах более чем достаточно однобайтового CHAR а если не достаточно - UTF8 спасает отцов русской демократии.
В общем - исходники должны храниться в UTF8, никаких экзотических кодировок в системе быть не должно и не должно быть предположений об их существовании = где нужно принимаем/передаем UTF8.


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

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


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

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


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

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