OberonCore

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

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




Начать новую тему Ответить на тему  [ Сообщений: 82 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 27 Декабрь, 2021 17:42 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1488
Откуда: Украина, Киев
budden писал(а):
Одна из них встроена в A2
Она адаптирована под все нововведения A2 скорее-всего, чтобы хотя-бы компилироваться. В А2 она просто скорее как демонстрация того, что она теперь может выполняться внутри А2 как приложение.


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Ярослав Романченко писал(а):
budden писал(а):
приняли решение, что тексты будут храниться в UTF32
В A2 по умолчанию тексты в utf-8 хранятся. А с наличием системы кодеков это вообще не проблема. Можно работать с любыми мыслимыми кодировками. Всё перекодируется "на лету"


Исходные тексты хранятся в utf-8. В буфере редактора (модуль Texts.Text) есть как минимум MemUnicodePiece, который хранит их в кодировке UTF32 (они называют это UCS32, разницу я не уловил). Также API работы с текстом, например, объект TextReader выдаёт по одной UCS32 букве за вызов, вот как он это делает:

https://github.com/metacore/A2OS/blob/5 ... s.Mod#L572

Т.е. нет никакого перекодирования на лету в этом случае. Текст (объект Texts.Text) внутри A2 и хранится в UTF32, и выдаётся в поток UTF32, поэтому и является естественным парсеры для текста писать сразу в UTF32. Да, для записи в файл он кодируется в UTF8, да, во многих местах в API используется UTF8, в т.ч. в компиляторе-линкере, но не везде.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 27 Декабрь, 2021 18:05 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 293
Откуда: Russia
Денис, ты постоянно пытаешься хамить и оскорблять сотрудников ETHZ и разработчиков A2. Может у тебя где-то подгорает, но люди не обязаны исполнять твои фантазии. Мы к твоему стилю общения уже привыкли, но в телеграм-чате Алексей уже делал тебе замечание. Прежде чем кого-то оскорблять, разберись в сути вопроса.
Над библиотекой поддержки юникода работаю я, о чём писал в телеграм-канале. То, что ты выдаешь за такую библиотеку оной не является.
Подсистема Text в A2 изначально поддерживала некое подмножество ansi . Потом добавили поддержку UTF-8 ( и следы этого видны до сих пор). Затем преобразовали в UTF32. Но эта замена себя не оправдала.
Очевидно, что строки в а2 должны строиться на на сырых указателях и массивах. Об этом мы тоже говорили в чате. И над этим идет работа.
Но можно продолжать бить себя в грудь и хамить, для поднятия чсв.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 27 Декабрь, 2021 19:59 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1488
Откуда: Украина, Киев
budden писал(а):
Т.е. нет никакого перекодирования на лету в этом случае
Игра слов? Ну, играйся, играйся


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Sergej Durmanov писал(а):
Денис, ты постоянно пытаешься хамить и оскорблять сотрудников ETHZ и разработчиков A2


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

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

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

В модуле StringsUCS32.Mod имеется:
* реализация "строк" на базе указателей
* построитель строк на базе потока из которого можно получить строку в UTF32 без перекодировок
* конкатенация, перевод регистра, обрезание строк.
* печать типов, оформленная в виде операций над строками, например,
можно прибавить целое к строке, чтобы получить любимое "2"+2 = "22",
надо, кстати, это выкинуть.
* сравнение строк
* поиск символа в строке

Иными словами, всё то же, что в модуле Strings, но для UTF32.
Помимо этого модуля, расширен интерфейс потоков - он позволяет читать и писать строки в формате UTF32. Перекодировка в UTF-8 происходит как раз-таки "на лету" или "не совсем лету" - возможно, где-то выделяется промежуточный буфер и это, конечно, нехорошо. Не помню и лень сейчас лезть туда.


Соответственно, наличие UTF32 в модуле Texts (и большое количество клиентов этого модуля) в сумме с наличием модуля StringsUCS32 создаёт предпосылки для того, чтобы ввести тип симв32 (CHAR32), и я это сделал. Если в A2 нет подобного модуля (хотя он, как ты пишешь, не тянет на библиотеку), то предпосылок
для введения типа CHAR32 в A2, возможно, меньше. Однако, я считаю, что
крайне неудобно иметь представление букв в тексте в виде чисел, поэтому одного модуля Texts должно хватить.

Цитата:
Затем преобразовали в UTF32. Но эта замена себя не оправдала.

Оправдала она себя или нет - код на сегодняшний день написан именно так. А чем она себя не оправдала, можно узнать?


Последний раз редактировалось budden Понедельник, 27 Декабрь, 2021 20:59, всего редактировалось 2 раз(а).

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

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

(* Proba.Дей ~ *)
использует Strings, StringsUCS32;

проц Дей*;
нач
   перем Строка8 := Strings.NewString("2") : Strings.String;
   Строка8 := Строка8 + 2;

   перем Строка := StringsUCS32.NewString(Лит32("2")) : StringsUCS32.String;
   Строка := Строка + 2;

   трассируй(Строка8^, Строка^);
   кон Дей;
   
кон Proba.

Печатает следующее:
Код:
{P cpuid= 0, pid= 14848 C:/ob/jaos/source/Proba.ярм@268 Proba.Дей : Строка8^= 22; Строка^
= 22; }

Убрать такую операцию "+" для 8-битных строк я не уверен что смогу, а вот для 32-битных - сделаю как руки дойдут. Вообще я уже давно считаю, что конкатенация должна быть отдельным значком. Это так даже для векторов: сложить вектора (1,2,3) и (4,5,6) - это совсем не то же самое, что их конкатенировать. Идея изображать конкатенацию сложением кажется мне... эээ... как бы кого не оскорбить :lol:

При том, несмотря на то, что я очень рано познакомился с вижуал бейсиком, это понимание почему-то дошло до меня сильно не сразу. Во всяком случае, прошу не пенять мне за этот "+" - его придумал не я, он был в модуле Strings изначально.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 27 Декабрь, 2021 21:38 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1488
Откуда: Украина, Киев
budden писал(а):
Во всяком случае, прошу не пенять мне за этот "+" - его придумал не я, он был в модуле Strings изначально.
Как будто бы это что-то плохое :lol: Можно открыть модуль Strings и увидеть соответствующие перегруженные операторы.
Моё мнение, что конкатенация - вообще плохо. Чтобы накидать код на скорую руку, в качестве прототипа, это нормально. Но потом переписать более оптимально


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 27 Декабрь, 2021 21:47 

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

Код:
StringsUCS32.NewString(Лит32("2"))


Что делает эта строчка?
Код:
проц NewString*(конст str : UCS32.StringJQ) : String;
перем l : размерМЗ; s : String;
нач
   l := Length(str) + 1;
   нов(s, l);
   UCS32.COPYJQvJQ(str, s^);
   возврат s
кон NewString;
...

проц Length* (конст string: UCS32.StringJQ): размерМЗ;
перем len: размерМЗ;
нач
   len := 0; нцПока (string[len].UCS32CharCode # 0) делай увел(len) кц;
   возврат len
кон Length;

Т.е., она меряет длину своего аргумента до знака с кодом 0 включительно, затем выделяет 4*длина байт и копирует туда это значение. Если бы литералы были закодированы в UTF-8, то для вычисления данной длины нужно было бы перекодировать литерал в UTF32. А где взять место для этого? На стеке нельзя, поскольку аргумент имеет неизвестную длину. Соответственно, нужно на время выделить буфер какой-то длины. Константин утверждал, что "Размер нормализованного текста в UTF-8 меньше либо равен тексту в UTF-32", однако здесь нам нужна оценка в обратную сторону. Т.е. мы не можем переиспользовать буфер назначения для перекодировки. Значит, мы вынуждены выделить его на куче, и эта память будет нужна только на очень короткое время. Но канонического способа выделить память в куче на короткое время и её освободить в A2/ЯОС вроде бы нет (в Си есть alloca, аналогов в АО мне неизвестно).

Другой вариант - перекодировать UTF-8 в UTF-32 два раза - сначала для измерения длины (для подсчёта количество "кодовых точек" UTF-8 достаточно буфера фиксированного размера), а затем уже для записи...

...а вместо всего этого можно просто ввести второй тип строкового литерала.


Последний раз редактировалось budden Понедельник, 27 Декабрь, 2021 22:02, всего редактировалось 1 раз.

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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Ярослав Романченко писал(а):
budden писал(а):
Во всяком случае, прошу не пенять мне за этот "+" - его придумал не я, он был в модуле Strings изначально.
Как будто бы это что-то плохое :lol: Можно открыть модуль Strings и увидеть соответствующие перегруженные операторы.
Моё мнение, что конкатенация - вообще плохо. Чтобы накидать код на скорую руку, в качестве прототипа, это нормально. Но потом переписать более оптимально


Не знаю, думаю, что оптимальность нужна не везде, где-то и конкатенация сойдёт. А вот обозначать конкатенацию плюсом - это не слишком хорошо, по моему скромному мнению. И я думаю, что я такой не один. Поэтому и дисклеймер. Ждём комментариев про объявления переменных в теле процедуры - это решение тоже вызывает полемику, но тут я как раз на стороне разработчиков A2, потому и скопировал это к себе (правда, у меня не все варианты работают, но пока и так хватит). Это же нарушение основополагающих канонов не только Оберона, но и вообще виртовских языков.


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

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
budden писал(а):
"Размер нормализованного текста в UTF-8 меньше либо равен тексту в UTF-32", однако здесь нам нужна оценка в обратную сторону.
В худшем случае в 4-е раза больше и это же просто цена 32-битности вместо 8-и бит. И для точного подсчёта символов в UTF-8 избыточно перекодировать в UTF-32 - достаточно посчитать байты >= D0H и < 80H


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 27 Декабрь, 2021 23:23 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Не уверен, что такой подсчёт правильно покажет длину некорректного кода в кодировке UTF-8.

Код:
В худшем случае в 4-е раза больше

Да, но NewString выделяет ровно столько памяти, сколько надо, а не с запасом. Но ладно, если мы считаем длину с фиксированным буфером раскодировки (5 байт или 6), то доп память выделять не нужно - "всего лишь" дважды перекодировать, вместо того, чтобы скопировать кусок памяти известного размера.


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

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
А что вообще нужно сделать в примере? Сделать копию строки такого же типа?


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Прибавить "2" + 2 и получить "22". Но пример просто показывает, что в ЯОС есть модуль StringsUCS32, аналогичный модулю Strings, но для UTF32. В общем-то ничего не нужно. Честно сказать, уже надо завязывать с этой темой, вроде всё разжёвано, и поругаться успели. Спор - это лучший способ убедиться в своей правоте, как известно, хотя я и спорить не собирался, просто задал вопрос, как оформить литералы UTF32 и потом дал обратную связь. Обсуждать ненужность этих литералов в мои планы вообще не входило - у меня для них есть конкретное применение, где они, наверное, оправдались. Теперь парсер в редакторе стал одновременно чуть быстрее и код его стал чуть менее уродливым.

Правда, можно ещё упомянуть, что и в Ofront+ недавно добавили двухбайтовый CHAR.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 28 Декабрь, 2021 01:34 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Так если не надо конвертировать, а достаточно оставаться в одном типе строк, то для Utf-8 была бы та же логика. Посчитать количество байт до 0, выделить буфер, скопировать.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 28 Декабрь, 2021 13:04 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Про перерасход памяти: бесспорно, 2 байта - вдвое больше, чем 1 байт. Однако этот фактор не самый весомый. Сейчас передо мной ББ, с двумя загруженными компиляторами, менеджером пакетов, открыто 9 текстов (из них 5 модулей ~40000 литер) в моем редакторе с раскраской на лету и два плиточных окна на двух мониторах - израсходовано 6 мегабайт. Страница Google Keep в Хроме с моими записочками, не более 10 тыс литер - израсходовано 200 МБ.
Архитектура приложения большее влияние имеет на расход памяти, кмк, чем размер литерного типа.

Денис, про спор. Покуда дискуссия остается в уважительном тоне, меня она обогащает. Вот конкретно эта - помогла четче разобраться в своей позиции, заставила залезть в Священное Сообщение о языке несколько раз, позволила понять, как видят мир те, кто не разделяет моей позиции, и почему. То есть, я хоть и остался при своем, но шире и глубже понимаю мир. Это бесценно, не говоря уж о том, что развлекательно ))


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

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Только литерный тип - это часть архитектуры, и которую так просто не поменять. А аргумент в духе "воровство лучше убийства" - это манипуляция. А так, UTF-16 для определённого набора литер может быть компактней UTF-8. Последняя - не чемпион по компактному представлению.

Также, для удовлетворения интереса(но без далеко идущих выводов), могу предложить запустить blackbox через
Код:
/usr/bin/time -f "%M KiB"

Заодно попробовать пооткрывать файлы побольше и посмотреть на поведение. Вам не надо, а кому-то надо. Потом попредставлять UTF-32 вместо UCS-2


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

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 293
Откуда: Russia
уже много раз обсуждали: в юникоде один глиф не всегда равен одному unicode code point. В этом плане, независимо от варианта utf строку нужно сканировать, позиционировать на начало utf последовательности и всегда проверять валидность при операциях так как в противном случае глиф состоящий из нескольких юниколных позиций будет разорван.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 28 Декабрь, 2021 23:52 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Это отвратительно, но на литералы в рамках одного типа это никак не влияет. А для кириллицы можно запретить двойной "й" и всё будет прекрасно. А вообще, когда я выяснял, есть ли где-то нормальная реализация, мне сказали, что в EMACS есть Mule, в котором глиф является элементом массива. Правда, как устроен этот массив, я так и не выяснил.


Последний раз редактировалось budden Вторник, 28 Декабрь, 2021 23:55, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 28 Декабрь, 2021 23:54 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
adimetrius писал(а):
Про перерасход памяти: бесспорно, 2 байта - вдвое больше, чем 1 байт. Однако этот фактор не самый весомый. Сейчас передо мной ББ, с двумя загруженными компиляторами, менеджером пакетов, открыто 9 текстов (из них 5 модулей ~40000 литер) в моем редакторе с раскраской на лету и два плиточных окна на двух мониторах - израсходовано 6 мегабайт. Страница Google Keep в Хроме с моими записочками, не более 10 тыс литер - израсходовано 200 МБ.
Архитектура приложения большее влияние имеет на расход памяти, кмк, чем размер литерного типа.

Тоже хотел про это написать.

Цитата:
Денис, про спор. Покуда дискуссия остается в уважительном тоне, меня она обогащает. Вот конкретно эта - помогла четче разобраться в своей позиции, заставила залезть в Священное Сообщение о языке несколько раз, позволила понять, как видят мир те, кто не разделяет моей позиции, и почему. То есть, я хоть и остался при своем, но шире и глубже понимаю мир. Это бесценно, не говоря уж о том, что развлекательно ))

Ладно, но я бы хотел иметь больше времени для работы, а тема всё длится и длится...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 10 Февраль, 2022 18:38 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
budden писал(а):
Не знаю, думаю, что оптимальность нужна не везде, где-то и конкатенация сойдёт. А вот обозначать конкатенацию плюсом - это не слишком хорошо, по моему скромному мнению. И я думаю, что я такой не один.

К слову, вспомнилось... В новой (условно) "математической" Julia плюс забанили, аргументируя:
https://docs.julialang.org/en/v1/manual/strings/
Цитата:
Julia also provides * for string concatenation:
Код:
julia> greet * ", " * whom * ".\n"
"Hello, world.\n"

While * may seem like a surprising choice to users of languages that provide + for string concatenation, this use of * has precedent in mathematics, particularly in abstract algebra.

In mathematics, + usually denotes a commutative operation, where the order of the operands does not matter. An example of this is matrix addition, where A + B == B + A for any matrices A and B that have the same shape. In contrast, * typically denotes a noncommutative operation, where the order of the operands does matter. An example of this is matrix multiplication, where in general A * B != B * A. As with matrix multiplication, string concatenation is noncommutative: greet * whom != whom * greet. As such, * is a more natural choice for an infix string concatenation operator, consistent with common mathematical use.

More precisely, the set of all finite-length strings S together with the string concatenation operator * forms a free monoid (S, *). The identity element of this set is the empty string, "". Whenever a free monoid is not commutative, the operation is typically represented as \cdot, *, or a similar symbol, rather than +, which as stated usually implies commutativity.


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

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


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

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


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

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