OberonCore

Вот такой странный вопрос. Дело в том, что BlackBox на самом деле написан очень специфически. И из-за этого просто заменой "A" на "W" не обойдёшься - для полной юникодизации придётся перелопачивать практически всё. И то, что получится в результате, не будет совместимо с существующими версиями среды. Так стоит ли овчинка выделки?

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

Сейчас надо будет подправить систему Text. Текст, который набирается в ББ, сохраняется великолепно, а вот вставленный из буфера (вот из того же Фара, например) оказывается в какой-то странной двухбайтовой кодировке - не-Юникод. Ее опознает только ББ. Видимо, надо править обработку сообщений вставки в TextControllers.
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 - нет. Но вот дальше всё лопатить както не очень хочется. Вот отсюда вопрос и возник.

Да...

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

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

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

Я так понимаю, что перекодировка вносит в код избыточность. Есть ли шанс избавиться от неё полностью? Мне думается одной кодировки (вероятно всё-таки Unicode) вполне достаточно.

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

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

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

Да, кстати... есть самая последняя строка:



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

А чем вызвано такое ограничение Руслан? Насколько я понял при создании 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

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

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

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

Да, точно.

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

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

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

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

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

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

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

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

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

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

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

Unicode imeet kuchu nedostatkov. Vsem interesuyushimsya sovetuyu pochitat podrobnosti v proekte Rosetta. Vozmogno s Unikodom voobshe zamorachivatsya ne stoilo.

Чуть точнее можно? И ссылки прямые приветствуются.