OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 27 Май, 2018 06:20

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




Начать новую тему Ответить на тему  [ Сообщений: 57 ]  На страницу 1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: А нужен ли юникод?
СообщениеДобавлено: Понедельник, 28 Ноябрь, 2005 01:30 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток
Вот такой странный вопрос. Дело в том, что BlackBox на самом деле написан очень специфически. И из-за этого просто заменой "A" на "W" не обойдёшься - для полной юникодизации придётся перелопачивать практически всё. И то, что получится в результате, не будет совместимо с существующими версиями среды. Так стоит ли овчинка выделки?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 30 Ноябрь, 2005 15:38 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8945
Откуда: Россия, Орёл
Не знаю, мне кажется, что сейчас надо исчерпать ресурс этой среды, а потом потребуется ее кардинальная реконструкция, возможно, полная. Встанут еще вопросы работы под .NET (хотя интеграция в их framewrok, как набор классов и концепций разарботки, считаю ненужной. Надо развивать свое.), генерации 64-разарядного кода. Остро встает вопрос переноса под Linux. Мы бы в Орле им занялись, но команда слишком мала, "распараллеливаться" дальше уже не можем, будет взаимная блокировка задач :-) Видимо, Linuxom займемся только после Нового года.

Сейчас надо будет подправить систему Text. Текст, который набирается в ББ, сохраняется великолепно, а вот вставленный из буфера (вот из того же Фара, например) оказывается в какой-то странной двухбайтовой кодировке - не-Юникод. Ее опознает только ББ. Видимо, надо править обработку сообщений вставки в TextControllers.
Ivor, расскажите, пожалуйста, поподробнее, что осложняет перевод под Юникод?
Я так понимаю, что все данные от системы приходят сейчас в ASCII, сохраняются тоже в ASCII, а вот внутри среды идут многократные перекодировки? Видимо, вначале среда была на коротких символах, потом решили перейти на Юникод, но ограничилсиь только определением типа CHAR как 2-байтового, а все ранее напианное они перелопачивать не стали?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 30 Ноябрь, 2005 16:18 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток
Илья Ермаков писал(а):
Ivor, расскажите, пожалуйста, поподробнее, что осложняет перевод под Юникод?
Я так понимаю, что все данные от системы приходят сейчас в ASCII, сохраняются тоже в ASCII, а вот внутри среды идут многократные перекодировки? Видимо, вначале среда была на коротких символах, потом решили перейти на Юникод, но ограничилсиь только определением типа CHAR как 2-байтового, а все ранее напианное они перелопачивать не стали?

Именно так и есть. В системе и компиляторе используется тип SHORTCHAR (в модуле Kernel, в загрузчике - везде имена объектов короткие). Ну ладно, это можно вылечить малой кровью через UTF-8. Формат Блекбоксовских документов - для хранения типов объектов опять используются короткие символы. В подсистеме Text при сохранении отдельно идут символы набора Latin-1, отдельно - юникода. Ресурсные файлы (по крайней мере файлы сообщений) читаются ПОБАЙТНО, а не через подсистему Text! Ну и почти все win-функции представлены "A"-вариантами. Это из того, с чем я столкнулся. По отдельности всё это исправляется, но только с неюникод-варсиями среды работать не будет. Ну в самом деле, исправлю я среду, будет она юникод в коротких строках как utf-8 хранить и перекодировать при необходимости. Но как с такими модулями из неюникод-версий работать? Вместо русских имён кракозябрвы писать?

На это ещё накладываются куски от Mac-версии, от Java-версии, полная каша, одним словом. Вот чем дольше я на BlackBox смотрю, тем больше убеждаюся, что его не исправлять надо, а переделывать с нуля.

Так что я сейчас подправил подсистему Text - она теперь все символы как юникод хранит (и Latin-1 в том числе). Изменил все процедуры на "W"-варианты. У меня под Wine`ом с грехом пополам работает. Под WinXP тоже. А под 98 - нет. Но вот дальше всё лопатить както не очень хочется. Вот отсюда вопрос и возник.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 30 Ноябрь, 2005 16:40 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Ivor писал(а):
Вот чем дольше я на BlackBox смотрю, тем больше убеждаюся, что его не исправлять надо, а переделывать с нуля.


Да...

1) Кодировка
2) Надо менять модуль Stores. (Текущая реализация модуля Stores предполагает временное разрешение (в целях облегчения переноса программ) супервызовов методов доступных только для реализации.)
3) Однопоточный ---> многопоточный сборщик мусора.

...и т.д. и т.п. можно целую ветку форума этому вопросу посвятить...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 30 Ноябрь, 2005 17:29 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1076
Илья Ермаков писал(а):
Я так понимаю, что все данные от системы приходят сейчас в ASCII, сохраняются тоже в ASCII, а вот внутри среды идут многократные перекодировки?

Данные от системы приходят в том виде, в котором их посылают. И если они пришли в юникоде, то все нормально. Но символы 80X..9FX (то, что между ASCII и Latin-1) перекодируются исходя из CP1252, а то, что неопределено отображается в Private Use Area. Получается, проблема в том, что ББ "слишком юникодный".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 30 Ноябрь, 2005 22:37 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 984
Я так понимаю, что перекодировка вносит в код избыточность. Есть ли шанс избавиться от неё полностью? Мне думается одной кодировки (вероятно всё-таки Unicode) вполне достаточно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Четверг, 01 Декабрь, 2005 13:44 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 22:34
Сообщения: 431
Откуда: Москва
GUEST писал(а):
Я так понимаю, что перекодировка вносит в код избыточность. Есть ли шанс избавиться от неё полностью? Мне думается одной кодировки (вероятно всё-таки Unicode) вполне достаточно.


А как при этом быть с нарушением спецификации языка Component Pascal? Насколько я помню, там достаточно жестко прописано, что строковые константы состоят из символов типа SHORTCHAR.

При изменении BlackBox, наверное, не стоит забывать, что покушаться на язык надо в самую последнюю очередь. Иначе это будет новый язык.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Четверг, 01 Декабрь, 2005 16:44 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Руслан Богатырев писал(а):
Насколько я помню, там достаточно жестко прописано, что строковые константы состоят из символов типа SHORTCHAR.


Не достаточно жестко.

Код:
   CONST
      str = "abc" + 0ABCX + "def" + 0FFFX + "gh" + 0X;


Цитата:
Constant strings which consist solely of characters in the range 0X..0FFX and strings stored in an array of SHORTCHAR are of type Shortstring, all others are of type String.


Цитата:
Константные цепочки, состоящие только из литер в диапазоне 0X..0FFX, и цепочки, хранящиеся в массиве элементов типа SHORTCHAR, имеют тип Shortstring, все остальные — тип String.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Четверг, 01 Декабрь, 2005 22:44 
Администратор

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

Цитата:
Реализация, которая не удовлетворяет этим требоваениям к компилятору и среде выполнения, не считается удвлетворяющей определению Компонентного Паскаля.


Вот вам по сути дела и стандарт языка.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пятница, 02 Декабрь, 2005 00:49 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 984
Сергей Губанов писал(а):
Руслан Богатырев писал(а):
Насколько я помню, там достаточно жестко прописано, что строковые константы состоят из символов типа SHORTCHAR.

А чем вызвано такое ограничение Руслан? Насколько я понял при создании Component Pascal вопрос об единственной кодировке не ставился. Но это решение его не ставить все-таки в стандарт языка не вошло. Конечно, если не рассматривать стандарт как описание реализации.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пятница, 02 Декабрь, 2005 13:34 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 22:34
Сообщения: 431
Откуда: Москва
GUEST писал(а):
Сергей Губанов писал(а):
Руслан Богатырев писал(а):
Насколько я помню, там достаточно жестко прописано, что строковые константы состоят из символов типа SHORTCHAR.

А чем вызвано такое ограничение Руслан? Насколько я понял при создании Component Pascal вопрос об единственной кодировке не ставился. Но это решение его не ставить все-таки в стандарт языка не вошло. Конечно, если не рассматривать стандарт как описание реализации.


Я посмотрел еще раз описание Компонентного Паскаля (КП). Сергей Губанов дал точную цитату.

Насколько я понимаю, Пфистер и Шиперски при проектировании КП хотели сохранить двойственность и ввели пару SHORTCHAR и CHAR.

Возможно (это всего лишь мое предположение) предполагалось в SHORTCHAR держать внутренние вещи (как-то исходные тексты и т.п.), а в CHAR (Unicode16) -- внешние.

В действительности это, понятное дело, создает проблемы.

Если затрагивать сферу промышленного ПО, то надо придерживаться известного принципа GIL -- globalization-internalization-localization (http://www.lisa.org). Желательно об интернационализации продукта (проектирование его с учетом последующих различных локализаций) думать заранее. И в этом смысле надо избегать использования в исходниках текстовых констант, подлежащих локализации (вообще).

Где встречаются текстовые строки:
1. Исходники КП (за вычетом текстовых констант)
2. Текстовые константы
3. Текстовые переменные (внешние тексты)

Проблема в том, что исходники в КП -- это тот же документ, который равноправен любому обычному документу (т.е. пункту 3).

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

A). 1 => SHORTCHAR, 2+3 => CHAR
B). 1+2 => SHORTCHAR, 3 => CHAR
C). 1+2+3 => CHAR


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Суббота, 03 Декабрь, 2005 08:03 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 984
Руслан Богатырев писал(а):
Я посмотрел еще раз описание Компонентного Паскаля (КП). Сергей Губанов дал точную цитату.

Насколько я понимаю, Пфистер и Шиперски при проектировании КП хотели сохранить двойственность и ввели пару SHORTCHAR и CHAR.

Возможно (это всего лишь мое предположение) предполагалось в SHORTCHAR держать внутренние вещи (как-то исходные тексты и т.п.), а в CHAR (Unicode16) -- внешние.

В действительности это, понятное дело, создает проблемы.

Вы правы, предположения можно строить. На мой взгляд, то что предполагали Пфистер и Шиперски это одно, а то, что создает проблемы другое. Не вижу проблемы в определении размещения констант, подлежащих локализации. Если угодно в отдельный модуль их. А что касается исходников (как обычного документа) тоже никто не заставляет. Можете защищать как угодно. Ещё лучше оставлять их закрытыми.
Я бы ещё добавил вариант D). ARRAY OF SHORTCHAR => 1+2+3 => ARRAY OF CHAR.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Суббота, 03 Декабрь, 2005 15:42 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
GUEST писал(а):
Если угодно в отдельный модуль их.


Если изменить значение экспортируемой модулем константы, то изменится её fingerprint. Этот модуль будет несовместим с другими модулями-клиентами использующими эту константу - нужна будет перекомпиляция. Нельзя заменить модуль с одними значениями констант на другой модуль с другими значениями констант избежав при этом перекомпиляции модулей-клиентов.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Суббота, 03 Декабрь, 2005 15:55 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток
Сергей Губанов писал(а):
Если изменить значение экспортируемой модулем константы, то изменится её fingerprint. Этот модуль будет несовместим с другими модулями-клиентами использующими эту константу - нужна будет перекомпиляция. Нельзя заменить модуль с одними значениями констант на другой модуль с другими значениями констант избежав при этом перекомпиляции модулей-клиентов.

Зато если вместо констант использовать read-only переменные, ничего перекомпилировать не придётся.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Суббота, 03 Декабрь, 2005 16:02 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Ivor писал(а):
Зато если вместо констант использовать read-only переменные, ничего перекомпилировать не придётся.


Да, точно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Суббота, 03 Декабрь, 2005 21:36 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 984
Это уже детали, дорогие мои. Размещение констант в сегменте кода позволяет оптимизировать работу с виртуальной памятью. В случае с internalization мы вообще видим всех клиентов. А какая проблема в повторной компиляции интересно?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Суббота, 03 Декабрь, 2005 23:05 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 22:34
Сообщения: 431
Откуда: Москва
GUEST писал(а):
Не вижу проблемы в определении размещения констант, подлежащих локализации. Если угодно в отдельный модуль их. А что касается исходников (как обычного документа) тоже никто не заставляет. Можете защищать как угодно. Ещё лучше оставлять их закрытыми.
Я бы ещё добавил вариант D). ARRAY OF SHORTCHAR => 1+2+3 => ARRAY OF CHAR.


На мой взгляд, один из возможных путей к решению проблемы с кодировками в BlackBox состоит в том, чтобы не идти на крайние варианты (все в SHORTCHAR или все в CHAR), а использовать признак кодировки в заголовке любого документа (.odc), вне зависимости от того, исходник это или нет.

Это позволит на лету осуществлять необходимые преобразования между кодировками.

Тогда, например, для исходников вполне можно применять SHORTCHAR, что позволяет для многих случаев обеспечивать двуязычность (английский - национальный). Если же требуются составные комбинации (три и более языков, либо языки азиатской группы), то использовать CHAR (на уровне комментариев и текстовых строк).

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

Общий подход -- исходники в массе своей в SHORTCHAR, а сторонние документы -- в CHAR.

Если говорить короче, то для обычных текстов применять SHORTCHAR или CHAR, а для исходников -- преимущественно варианты A или D.

Уточню, что в схеме вариантов упустил комментарии. Здесь при маркировке документов (.odc) гибкость можно сохранять, но брать за основу все же SHORTCHAR.

Более того, маркировка в заголовке позволяет использовать не только Unicode16, но при необходимости и другие кодировки (8-, 16- и 32-разрядные).

При этом документы (включая исходники) должны иметь две взаимнооднозначные формы -- бинарную (ODC-подобную) и текстовую (XML-подобную).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Воскресенье, 04 Декабрь, 2005 08:29 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 984
Милое дело сначала создать проблему, а потом её решить. Какая будет проблема с кодировками в BlackBox после однократного прохождения по пункту D? Решение ввести дополнительные атрибуты в .оdc интересное, но цель его не гибкость. Мое мнение - ставится цель во чтобы то ни стало сохранить существующий код в части работы с SHORTCHAR неизменным.
P.S. Относительно динамического изменения ресурсов надо сказать, что константами там и не пахнет. Статические ресурсы быстрее обрабатываются. Не намного правда.
P.P.S. Желательно всё-таки не отклоняться на обсуждение других вопросов, пока в одном не пришли к согласию. Я имею в виду XML.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вторник, 30 Январь, 2007 12:21 

Зарегистрирован: Вторник, 04 Июль, 2006 13:04
Сообщения: 88
Откуда: Novosibirsk
Unicode imeet kuchu nedostatkov. Vsem interesuyushimsya sovetuyu pochitat podrobnosti v proekte Rosetta. Vozmogno s Unikodom voobshe zamorachivatsya ne stoilo.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вторник, 30 Январь, 2007 18:24 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4081
Откуда: Россия, Орёл
Чуть точнее можно? И ссылки прямые приветствуются.


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

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


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

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


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

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