OberonCore

Главное, тут не нужно путать генеральную линию партии (АК) с политикой партии...

+100 :о) Занести в мАксимы!

б) не хорошо, а в остальном почему бы и нет.

Проблема в том, что дескрипторы модуля и типов напрямую отображаются из ocf в память. И сия замена разом поменяет формат кодового файла. Я попытался грузить файлы с преобразованиями SHORTCHAR -> CHAR, но завис на fixup'ах

А формат кодового файла менять не надо.

Т.е. в кодовом файле хранить имена в SHORTCHARах в кодировке типа utf-8? На это в Kernel есть процедуры GetRefProc и GetRefVar. Часть символьной информации отображается прямо в память, но не выражается в системе ни в каких структурах - упомянутые процедуры елозят по памяти в поисках данных, в том числе и имён. И им придётся каждый раз преобразования кодировки делать. Невелик труд, конечно, тут вопрос в "правильности" скорее - отображать модуль напрямую в память или грузить его по частям, с заполнением всяких структур?

Да и пусть себе елозят.

Ещё некоторые атавизмы остались в StdLinks, StdFolds и т.д.

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

Это задает совсем другой контекст для задачи юникодизации идентификаторов в ББ.
Как-то уже есть ощущение Неизбежности. Независимо от позиции Оминк.

У нас тут главный Trurl ведь?
Как бы прояснить состояние на данный момент?

Кажется, есть совсем юникодный ББ. Пока только русский.

Вот примерно так.

Надо ещё с несовместимостями разобраться.

Вот
Взять BlackBox 1.6; накатить на него это; открыть Build-Tool, скомпилировать, слинковать.
Или, по вкусу, использовать папку как целевую, далее по плану.

Отличия:

• StdFolds,StdLinks,StdStamps,OleClient,SqlControls теперь умеют сохранять свои свойства в уникоде. Пришлось изменить версии. Но, если строки все же помещаются в Latin-1, то сохраняются по-старому, для совместимости.
• Kernel все имена отдает/принимает как ARRAY OF CHAR. Соответственно, изменены модули, которые его используют.
• В объектных файлах имена предполагаются в UTF-8 (точнее CESU-8), так что возможны недоразумения с модулями, скомпилированными в стандартном ББ и содержащими символы из верней половины Latin-1.
• Точно так же Stores сохраняет имена типов. Возможны те же проблемы.
• Процедуры, которые распознают имена изменены так, что принимают не только Latin-1.
• Компилятор допускает те же символы в идентификаторах.

Набор символов сверх Latin-1: латинские с диакритикой, кирилица, греческий.

Упаковал с неправильным StdCmds

Спасибо, скачал.

Очередная школьная версия на 1.5, она практически готова.

И теперь потихоньку-полегоньку будем экспериментировать с этой.

Вот еще перекодировал из 1.5. Поскольку National (пока?) нет добавил i21sysNational.

Оказывается перекодированная документация уже есть.

Я вот думаю: хранить имена в UTF-8 конечно напрашивается, но получается некоторая несовместимость. Может, добавлять в начало какой-нибудь символ?

Вот зря Вы торопитесь.

Само перекодирование не проблема.
Важно четко знать, ЧТО перекодировать.

"некоторая"?
Как в "некоторая несвежесть"?

Можно пример?

Может быть и проблемой. Ссылки на русские имена файлов, напрмер. А что делать с формами, я даже не знаю.


Да, что-то в этом роде.

Например, некий немец пишет

и компилирует это в стандартном ББ.
Теперь в "уникодизированном" ББ получим китайские иероглифы: Man嵥r;subsidi㰀.
И наоборот, если скомпилировать это в "уникодизированном", то в стандартном получим

Спасибо, теперь понял.

У Цинна была где-то тулза как раз про программную обработку форм -- переименования и т.п.

Но тут уникод подмешивается.
Пож., приведите на этот счёт тоже явный пример.

Хочу зафиксировать всё явно, для экономии умственной энергии в недалёком будущем.

Т.е. тут все буковки SHORTCHAR, но две -- из верхней АСКИ.

Т.е. у-ББ считает литерки из верхней АСКИ за шифровку уникодных литер, пока в какой-то момент не вырулит опять на чистый нижний АСКИ.

То есть сначала конвертируем исходник в уникод, чтобы две буковки перешли из верхней АСКИ куда-то в уникод.

когда попытаемся из стандартного изучить бинарники уникодного, например, пытаясь посмотреть интерфейс посредством Ctrl+D
то есть каждая высокоуникодная литерка превратится в пару АСКИшных.

Понятно.
Понятно, что спешить тут не показано.
-------------
И какую литерку предлагается вставлять перед строкой УТФ-8?
Чтобы её видел стандартный ББ?
Разве это возможно?

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

Тогда для использования стандартного бинарника в у-ББ нужно добавить некий интерфейсный модуль (как делается для dll).

Пусть у-ББ маркирует свои идентификаторы спец.литерой (которая запрещена для идентификаторов в стандартном ББ), а две тулзы как-то это понимают.

No?