OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 29 Март, 2024 01:44

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




Начать новую тему Ответить на тему  [ Сообщений: 49 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Четверг, 12 Декабрь, 2019 18:06 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Борис Рюмшин писал(а):
Внутри ему делать нечего.

Может аргументируйте чем плох Utf8 в качестве внутренней реализации для кодирования идентификаторов, чтобы вообще проблема была понятна людям. У меня опасения, что если влезть в компилятор на ровном месте без причин на то, то будем баги вылавливать несколько лет. Это точно того стоит?

Плюсы, что большинство идентификаторов в бинарниках занимает мало места в однобайтной кодировке. Алгоритмы сравнения работают быстрее для однобайтных строк?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Четверг, 12 Декабрь, 2019 19:16 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 293
Откуда: Russia
Кто мешает загружать модули разных версий, конвертируя старые "на лету"? Тогда можно держать и старый формат с utf8, и новый с utf16, а внутри все в utf16


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Пятница, 13 Декабрь, 2019 04:40 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Борис, а у вас уже есть какие-то эксперименты? А то может опасения по поводу сложности изменения компилятора напрасны. Может там не так всё плохо?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Пятница, 13 Декабрь, 2019 12:25 
Администратор

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Воскресенье, 22 Декабрь, 2019 13:03 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 583
Откуда: Москва
Иван Денисов писал(а):
Новое ядро проектируем для версии 1.8, подключился Антон и орловцы. Вот поэтому и Борис про Utf8 написал, что раз идет редизайн ядра, то можем сделать всё более элегантно.

Ну, если так, тогда и я дам свое видение.

1. Интерфейс Uft8 в ядре не нужен. И понятие Kernel.Utf8 не нужно.
2. Есть проблема SHORT(lstring) и LONG(sstring). По уму, если lstring в кодировке UCS2, то s := SHORT(lstring) должно переводить это в кодировку UTF8. И наоборот, если sstring в кодировке UTF8, то ls := LONG(sstring) должно переводить к кодировку UCS2.
3. Я в LLVM в ядро вставлял процедуры:
Код:
PROCEDURE StrcpySL* (IN src: ARRAY OF SHORTCHAR; VAR dst: ARRAY OF CHAR; len: INTEGER);
PROCEDURE StrcmpSL* (IN x: ARRAY OF CHAR; IN y: ARRAY OF SHORTCHAR): INTEGER;
PROCEDURE StrapndSL* (IN src: ARRAY OF SHORTCHAR; VAR dst: ARRAY OF CHAR; len: INTEGER);

для преобразования строк из SHORT в LONG.
Идея из OFront - там это в сишном виде.
4. Предлагаю в Kernel добавить интерфейсы, например, адреса процедур StrcpySL, StrapndSL (append), которые по умолчанию задаются процедурами из Kernel, но могут инсталлироваться из другого модуля.
5. Модуль с реализацией, ну там HostStrings, содержит процедуры конвертации UTF8 <-> UCS2.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Воскресенье, 22 Декабрь, 2019 14:52 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Дмитрий Викторович, ваше предложение мне кажется очень рациональным.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Воскресенье, 22 Декабрь, 2019 18:38 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Воскресенье, 22 Декабрь, 2019 19:23 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Дмитрий Дагаев писал(а):
2. Есть проблема SHORT(lstring) и LONG(sstring). По уму, если lstring в кодировке UCS2, то s := SHORT(lstring) должно переводить это в кодировку UTF8. И наоборот, если sstring в кодировке UTF8, то ls := LONG(sstring) должно переводить к кодировку UCS2.

5. Модуль с реализацией, ну там HostStrings, содержит процедуры конвертации UTF8 <-> UCS2.

Такое изменение семантики SHORT/LONG опасно. Как минимум для старого кода.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Воскресенье, 22 Декабрь, 2019 20:01 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1428
Дмитрий Дагаев писал(а):
И наоборот, если sstring в кодировке UTF8, то ls := LONG(sstring) должно переводить к кодировку UCS2.

А откуда LONG узнает, что sstring в кодировке UTF8?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Воскресенье, 22 Декабрь, 2019 21:23 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 583
Откуда: Москва
Я согласен с критическими замечаниями в адрес такого предложения. Попробую аргументацию в свою защиту.
StrcpySL, StrapndSL по умолчанию задаются процедурами из Kernel - то есть обычные преобразования char<->shortchar.
Борис Рюмшин писал(а):
Такое изменение семантики SHORT/LONG опасно. Как минимум для старого кода.

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

Sergej Durmanov писал(а):
UCS2 не нужна, лучше сразу UTF16

Любая возможна, нужно только "на берегу" договариваться, какая кодировка у CHAR

Trurl писал(а):
А откуда LONG узнает, что sstring в кодировке UTF8

Моя схема допускает установка любых перекодировщиков, например, UTF7. Если Вы для Ваших задач хотите использовать другую кодировку для SHORTCHAR - это будет работать. Но не будет совместимо с другими, если они в UTF8. Надо "на берегу" договариваться, что у SHORTCHAR кодировка UTF8


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Воскресенье, 22 Декабрь, 2019 23:42 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Дмитрий Дагаев писал(а):
Только для нового кода (1.8 версия) мы прибиваем реализацию HostStrings, где уже фиксируем кодировки. Для совместимости остается дефолтная реализация со старой семантикой.

Всё равно не надо такого. SHORT предполагает какое-то урезание (низкоуровневое), а не преобразование. Причём не очевидное.

Код:
VAR x: ARRAY 8 OF CHAR; y: ARRAY 8 OF SHORTCHAR;

y := SHORT(x);

А в x 7 символов кириллицы. И всё.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Понедельник, 23 Декабрь, 2019 00:55 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Дмитрий Дагаев писал(а):
4. Предлагаю в Kernel добавить интерфейсы, например, адреса процедур StrcpySL, StrapndSL (append), которые по умолчанию задаются процедурами из Kernel, но могут инсталлироваться из другого модуля.
5. Модуль с реализацией, ну там HostStrings, содержит процедуры конвертации UTF8 <-> UCS2.


Поддерживаю. Но предлагаю все же BlackBox way: Hook с типозависимыми процедурами.
Борис Рюмшин писал(а):
Всё равно не надо такого. SHORT предполагает какое-то урезание (низкоуровневое), а не преобразование. Причём не очевидное.

А здесь поддерживаю Бориса. И еще обращаю внимание, что сейчас a: ARRAY OF CHAR и SHORT(a) - гарантированно одного размера, а как изменится размер массива после преобразования кодировок - поди угадай. Кроме того, единственный останов, который может сейчас произойти при SHORT - это value out of range, причем независимо от базового типа массива. А при преобразовании кодировок - чего хочешь, вплоть до "файл не найден" или "iconv сегодня не в духе" - кто из нас может привести исчерпывающий список исключений, которые могут произойти при вызове Host? И вообще, мы привыкли, что слова, написанные прописными латинскими буквами - это надежно и предсказуемо, как гранит; а если спрятать за SHORT обращение к Host... Обращаться к iconv, конечно, надо, это неизбежное зло, но лучше, чтобы было видно, что это не язык и не языковый рантайм.

Про урезание: если включена проверка Value out of range, то SHORT не урезает; он срабатывает без останова, только если значение "влезает" в младший тип. А если не влезает - то будет останов. Поэтому я бы сказал, что это не урезание, а отбрасывание старших незначащих нулей. И его нужно охранять: IF с < MAX(CHAR) THEN s := SHORT(c) ELSE s := SHORT(CHR(ORD(c) MOD ORD(MAX(SHORTCHAR))) END.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Понедельник, 23 Декабрь, 2019 10:48 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Надо, чтобы преобразование было встроено в ядро. Не надо делать для таких низкоуровневых вещей никаких хуков. И без iconv, конечно! Должно быть платформенно-независимое преобразование.
Либо вообще без преобразований, как Борис изначально предложил.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Понедельник, 23 Декабрь, 2019 14:18 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 02:12
Сообщения: 473
Откуда: KZ
Trurl писал(а):
Дмитрий Дагаев писал(а):
И наоборот, если sstring в кодировке UTF8, то ls := LONG(sstring) должно переводить к кодировку UCS2.

А откуда LONG узнает, что sstring в кодировке UTF8?

Другие кодировки не нужны :wink:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Понедельник, 23 Декабрь, 2019 15:03 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1488
Откуда: Украина, Киев
Alexander Shiryaev писал(а):
Другие кодировки не нужны :wink:
640K ought to be enough for anybody :wink:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Понедельник, 23 Декабрь, 2019 23:13 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 02:12
Сообщения: 473
Откуда: KZ
https://www.opennet.ru/opennews/art.shtml?num=42795
https://www.openbsd.org/papers/eurobsdcon2016-utf8.pdf, стр. 39


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Вторник, 24 Декабрь, 2019 01:10 

Зарегистрирован: Пятница, 13 Март, 2015 16:40
Сообщения: 597
Ярослав Романченко писал(а):
640K ought to be enough for anybody :wink:

И за это тоже, его в аду будут жарить на сковородках без масла...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Вторник, 24 Декабрь, 2019 19:15 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 583
Откуда: Москва
Alexander Shiryaev писал(а):
https://www.opennet.ru/opennews/art.shtml?num=42795
https://www.openbsd.org/papers/eurobsdcon2016-utf8.pdf, стр. 39

И правильно, проблемы от избытка. Если б было везде SHORTCHAR (лучше CHAR) с utf8 - не было б проблемы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Среда, 25 Декабрь, 2019 12:38 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
На мой взгляд, проблема не в том, что используется UTF8 для кодирования идентификаторов, а в том, что в Strings импортируется реализация UTF8 из ядра. Это временное решение, которое должно быть устранено. Но также импортируются реализации IsUpper IsLower. А они библиотечные! И они также нужны в ядре. И получается, что даже если вы хотите брать только UCS2. То проблема зависимости Strings от ядра не убирается, так как либо надо делать HostStrings, где будут библитечные реализации Upper и т.п., либо оставить так как сейчас их хост-зависимые библиотечные реализации в ядре. Это важные момент. Никто не хочет писать свою реализацию Upper и Lower для всех известных языков? Если кто-то напишет, то давайте включим это в Strings и тогда можно будет убрать зависимость от ядра.

А в целом как внутренняя реализация UTF8 очень удобен, внутри рантайма везде используется экономичный SHORTCHAR. А парсер и средства отладки работают с UCS2.
Более логичным был бы дальнейший переход на UTF8, так как сейчас подсистема Text не выдерживает критики. Тексты на русском весят очень много, так как TextModels крошит всё отображение на мелкие куски. Пробелы кодируются в SHORTCHAR, а слова в UCS2. И у каждого куска в довесок идет метаинформация. То есть у каждого пробела и слова в русском тексте возникает свой кусок. И это ужасно сказывается на производительности и на размере файлов.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Предложение: убрать UTF8 из BlackBox
СообщениеДобавлено: Среда, 25 Декабрь, 2019 12:50 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Ну размер то файлов никак не изменится (для русского), при переходе на UTF8. Будет тоже самое, по сути. Вот, кстати, тексты полностью на CHAR перевести можно было бы.
И проблема не только в экспортированных их Kernel процедурах, а в том, что юникодизация выполнена не штатными средствами. Если бы поддержки юникода в КП не было, разговор про utf8 внутри имел бы смысл, но она есть.


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

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


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

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


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

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