OberonCore

Здравствуйте, уважаемые коллеги!

Хочу представить на суд общественности свою работу по переводу библиотеки Anti-grain geometry на язык Оберон (в реализации XDS).

Краткое описание работы
Скачать архив

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

Продублировал файл на форуме.

Весьма интересно! Правда, у меня не получилось что-либо загрузить
Если интересен порт также и под A2 можете заглянуть к нам http://a2os.org.ua/forums/index.php, у нас и SVN уже есть
В A2 уже есть библиотека для формата SVG, например.

Интересно, почему при входе с логином я вижу тему, а без логина - нет? и в активных темах она не отображается. Где-то галку выставить?

Для перевода библиотеки на BlackBox надо перевести на CP модуль AggColor.ob2.
Там - математика по преобразованию цветов, связанная с беззнаковым целым 8 бит (с байтом то бишь).
У меня не получилось. Если кто подскажет, можно будет начать переделывать и под BB.

Может я не открыл Америку, но вчера сделал интересное для себя открытие.

Если в процессе работы программы указателям, ставшим уже ненужными, присваивать значение NIL, расходование памяти происходит не так агрессивно.

Если же этого не делать, то память высвобождается медленнее.

Эксперименты производитись на следующем коде:


Если выделенную строчку закомментировать, программа потребляет примерно вдвое больше памяти, и ее освобождение происходит медленнее.

Это повод пересмотреть использование памяти в AGG для Оберон.

Полагаю, это происходит от того, что в момент выделения памяти для массива, p всё ещё занят предыдущим значением, и поэтому память освободиться не может. В реальных задачах этот эффект может быть не заметен.

Но предыдущее значение -- массив другого размера.

У меня наоборот получилось - если строку ":= NIL" закомментировать, то среднее и максимальное потребление памяти ниже (чаще освобождает). Вы чем пользовались для замеров? Я смотрел Performance Graph в свойствах процесса в Process Explorer v.11.20 с выборкой раз в секунду.

Кстати, почему бы не попробовать более чистый эксперимент? Вынесите тело цикла в отдельную процедуру, чтобы указатель p был локальной переменной. Такая ситуация ближе к реальности, вы ведь не будете всю программу запихивать в MAIN. Вполне возможно, что это задействует дополнительные оптимизации, и присвоение NIL не потребуется.

Ещё одна причина, по которой пример слишком надуман: когда вы делаете NEW (p#NIL), то прежнее значение указателя ещё может являться якорем и препятствовать освобождению прежнего массива. Вот, кстати, почему вынос в локальную переменную, да и прочая нормальная работа (не тесты) будут вести себя более адекватно. При условии, конечно, что не выключен "+GENPTRINIT" (по умолчанию включен).

Если же HEAPLIMIT # 0, то GC XDS (насколько я его знаю) освобождает память только тогда, когда доходит до верхнего предела, так что для этого случая ваш тест вообще не имеет смысла.

В 49 итерациях из 50 следующий массив в (i + 1)/i раз больше предыдущего, что довольно мало для достаточно больших i, да к тому же в 1 итерации на каждые 50 новый массив в 50 раз меньше предыдущего. Всё это вполне может сойти за двойной перерасход памяти.

Пример, мною придуманный - совершенно синтетический, согласен.

Вопросом этим я задался тогда, когда сравнил производительсность [url http=http://agg-sharp.sourceforge.net/]AggSharp[/url] и того, что делаю я.
Так вот, демка "lion" написанная на C# если начать львенка крутить потребляет какое-то количество памяти, и на этом останавливается, а на Обероне - нет.
Хотя, возможно я просто не дождался верхней границы, но для простого приложения 60 мб уже многовато, в сравнении с ~15 на C#.

Замеряю помощью Task manager, колонки занято памяти и занято виртуальной памяти.
Process Explorer как-то даже не подумал запустить

Попробуйте воспользоваться литерными типами CHAR и SHORTCHAR. Они как раз и есть беззнаковые 2- и 1-байтовые. ORD делает из них более широкое целое беззнаковым расширением.

Поставьте HEAPLIMIT="14000000".

Хм, это получилось.

Теперь еще вопрос, как организовать инициализацию массивов в ВВ?

В XDS достаточно просто -
TYPE
A = ARRAY 10 OF INTEGER;
VAR
a: A;

BEGIN
a := A{0, 10, 20 ...};

А в ВВ?

Так не получится, поэлементно задавать нужно. Что Вам конкретно нужно?

Тоже достаточно просто:
TYPE
A = ARRAY 10 OF INTEGER;
VAR
a: A;
BEGIN
InitA(a, 0, 10, 20, ...);

PROCEDURE InitA (VAR a: A; a0, a1, a2, ...: INTEGER);
BEGIN
a[0] := a0; a[1] := a2; a[2] := a1; ...
END InitA;

Посмотрите модуль AggGSVText
Там много массивов размером по нескольку тысяч элементов.
Их надо загрузить в память.
Поэлементно ... э ... долго

Однозначно - надо скинуть содержание массивов во внешний ресурс (составной документ, CSV, XML) и загружать оттедова.

Вполне и .odc подойдёт. Без всяких конвертеров открывай, да TextMappers.Scanner-м читай. Цикл в пару-другую строчек на все про все.

Для начала проще всего. Если захочется избавиться от использования под-мы Text, тогда можно думать о др. формате.

А это можно сделать по месту?
В смысле прямо в том же документе, после завершающего END.?

Проще в начале, после символов "(" и "*"... ; )