OberonCore
https://forum.oberoncore.ru/

О совместной работе Оберон-сообщества
https://forum.oberoncore.ru/viewtopic.php?f=28&t=5258
Страница 1 из 1

Автор:  Kemet [ Четверг, 27 Ноябрь, 2014 11:29 ]
Заголовок сообщения:  О совместной работе Оберон-сообщества

Добрый день, хотелось бы узнать, можно на Компонертном Паскале писать в стиле Языка Оберон, без расширений КП, а затем легко интегрировать в код на Компонентном Паскале, импортируя скомпилированные модули и используя типы, константы, переменные и процедуры таких модулей (написанных на каноническом процедурном Обероне).
Смысл в том, чтобы возвратиться к истокам и писать библиотеки именно на таком Обероне, а затем уже делать обертки для нужной ветви языка Оберон-семейства. Конечно, для этого нужно будет разработать соглашения, чтобы стыковка проходила более гладко, но каких-то сильно больших проблем я в этом не вижу, тем более, что профит от этого перекроет все возможные недостатки, т.к. позволит консолидировать сообщество - каждый может писать на чистом Обероне, а этот код можно использовать и для Компонентного Паскаля и для Активного Оберона и для Оберона-2 и, в общем-то, для для этого самого Оберона ). Понятно, что идея не нова, но может настало время воплотить её в жизнь.
Кто что думает по этому поводу.

Автор:  Илья Ермаков [ Четверг, 27 Ноябрь, 2014 12:02 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

А компилировать эти библиотеки уже конкретной реализацией? Тогда всё же понадобится небольшой препроцессор, убирающий мелкие отличия.
Кроме того (кто занимается 07-м - скажет) - там отличия от остальных ветвей усилились по некоторым моментам (нет псевдонимов типов, допустим, и т.п.) - нужен также анализ, что и как сопряжётся.

А по существу дела - а какого назначения компоненты в первую очередь Вы подразумеваете?
Библиотеки к "внешнему миру", или "стандартную библиотеку", или GUI, или контейнеры, или...?

Автор:  Борис Рюмшин [ Четверг, 27 Ноябрь, 2014 12:19 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

Зачем хоть препроцессор то? :shock:

Кстати, у тов. Дагаева кажется есть именно такой опыт.

Автор:  Александр Ильин [ Четверг, 27 Ноябрь, 2014 12:32 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

Борис Рюмшин писал(а):
Зачем хоть препроцессор то?
Копирование строк: "s1 := s2$" vs "COPY(s2, s1)".
В КП все расширяемые рекорды должны иметь EXTENSIBLE в объявлении, а в Oberon всё можно расширять и без этого.
Обязательный атрибут NEW у новых (не унаследованных) методов.

В ББ есть документ про отличия от прежних Оберонов.

Автор:  Kemet [ Четверг, 27 Ноябрь, 2014 12:43 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

Илья Ермаков писал(а):
...

Конечно, компилировать конкретной реализацие, иначе смысла нет, потому и спрашиваю, насколько в КП и вообщев частности в ББ это возможно - в исходниках компилятора ББ ( как и в OP2 ) есть ключи, позволяющие ограничится только Обероном, но я не знаю, на каком уровне реальная поддержка и работает ли это вообще, импортируются ли такие модули потом в КП...
Конечно, нужно будет сделать, например, библиотечный модуль StdTypes( и т.п.) для нужной ветки Оберона, в которой привести базовые типы к единому знаменателю. Понятно, что О-7 выпадает из поддерживаемых веток, в силу его особенностей и специфической ориентации.
Как первоочередную задачу я вижу в реализации Оберон-библиотек для поддержки компрессии, графических форматов, юникодизации, криптографии, обработки текста и тп, т.е. базовых вещей, без которых просто не выжить среде разработки.
Также, на следующем этапе, графика - 2D/3D - также с последующкй обвязкой под конкретную реализацию Оберона/Каркаса...
GUI, думаю, лучше уже писать на конкретной реализации, использую уже готовые средства отрисовки, написанные на предыдущем шаге, т.к. очень много ньюансов.

Автор:  Дмитрий Дагаев [ Четверг, 27 Ноябрь, 2014 13:41 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

1. Я портировал Ta на BB, XDS, Ofront, A2. Для переносимого ПО был сделан препроцессор под BB. Исходник *.odc частично:
Код:
#IF @BB
   IMPORT Tb := Ta_Basics, Tc := Ta_Channels, Tl := Ta_Lib, Ti := Ta_TInfo, SYSTEM, Log @WSI;
#ELSIF @XDS
   IMPORT Tb := Ta_Basics, Tc := Ta_Channels, Tl := Ta_Lib, Ti := Ta_TInfo, SYSTEM,
      Log @WSI, oberonRTS;
#ELSIF @OFR
   IMPORT Tb := Ta_Basics, Tc := Ta_Channels, Tl := Ta_Lib, Ti := Ta_TInfo, SYSTEM, Log;
#ELSIF @AOS
   IMPORT Tb := Ta_Basics, Tc := Ta_Channels, Tl := Ta_Lib, Ti := Ta_TInfo, SYSTEM, Log;
#END
...
#IF @AOS
   PROCEDURE NewStation* (old: Station; cf: Tc.ChannelFactory;
   aid, sid: INTEGER; @IN name@R: ARRAY OF CHAR;
   VAR cqos: Tc.ChannelQosBase; is_datahost, is_send_station: BOOLEAN)
   : Station @NEW;
      VAR cr: Carrier; station: StdStation; res: INTEGER;
   BEGIN
      cr := SELF;
#ELSE
   PROCEDURE (cr: Carrier) NewStation* (old: Station; cf: Tc.ChannelFactory;
   aid, sid: INTEGER; @IN name@R: ARRAY OF CHAR;
   VAR cqos: Tc.ChannelQosBase; is_datahost, is_send_station: BOOLEAN)
   : Station @NEW;
      VAR station: StdStation; res: INTEGER;
   BEGIN
#END
      ASSERT(cqos.prot_format = cr.prot_format, Tb.WRONG_TYPE);
      IF old = NIL THEN
         NEW(station)
      ELSE
         station := old(StdStation);
         IF station.cqos.prot_format # cqos.prot_format THEN
            station.channel := NIL
         END
      END;
      IF station.channel = NIL THEN
         ASSERT(cf # NIL, Tb.NIL_POINTER);
         IF is_datahost THEN cr.host_sid := sid END;
         cf.NewChannel(aid, sid, cr.host_sid, station.channel, res);
#IF @XDS
         Tl.InstallFinalizer(FinalizeChannel, station.channel)
#ELSIF @OFR
         Tl.InstallFinalizer(FinalizeChannel, SYSTEM.VAL(LONGINT, station.channel))
#ELSIF @AOS
         AddToFinalizer(station.channel)
#END


Генерится odc - для BB, ob2 - для XDS, odc - для Ofront, Mod - для A2.
Можно делать подстановки @INT32 @EXTENSIBLE и проч

2. Пробовал писать на Oberon-2 (Ta), Oberon (Co) и портировать.
Портирование программы, написанной на Oberon-2 под A2 приводит к плохо читаемому коду #IF #ELSIF.
Портирование Oberon программы даже на BB/XDS не обходится без препроцессора
Код:
#IF @XDS
   (* XDS Windows/Linux Implementation *)
   IMPORT Ct := Co_Tasks, COROUTINES, SYSTEM;
#ELSIF @WIN
   (* BlackBox Windows Implementation *)
   IMPORT Ct := Co_Tasks, Co_Api, WinApi, SYSTEM, Kernel;
#ELSE
   (* BlackBox Linux Implementation *)
   IMPORT Ct := Co_Tasks, CA := Co_Api, SYSTEM, Kernel;
#END

   CONST
      CHECK_RANGE_ERROR* = 50; NIL_POINTER* = 51; NOT_AVAILABLE* = 52;
      MUST_BE_PRIMARY* = 53; CANT_BE_PRIMARY* = 54; INVALID_FINISH* = 55;
      ASSERT_IN_ROUTINE* = 56; INTERNAL_ERROR* = 57;
      CONTROL_DENIED* = 58; REENTRANT_ERROR* = 59;
      STACK_SIZE = 32768;
   
   TYPE
#IF @BB
#IF @WIN
      Fiber = WinApi.PtrVoid;
#END
#END
      (* ---------- Coroutine  ---------- *)
      Coroutine* = POINTER TO CoroutineDesc;
      C_PROC* =    PROCEDURE (c: Coroutine);
      CoroutineDesc* = @ABSTR RECORD (Ct.TaskDesc)
         eor-: BOOLEAN;
         stack_size*: INTEGER;
         error: BOOLEAN;
         disp: Ct.Dispatcher;
         from: Coroutine;
#IF @XDS
         cr: COROUTINES.COROUTINE;
         stack: POINTER TO ARRAY OF SHORTINT;
#ELSIF @WIN
         fiber: Fiber;
#ELSE
         context, tmp_context: CA.ucontext_t;
         stack: POINTER TO ARRAY OF BYTE;
#END
         size, addr, typeid: @INT32;
         Start-, OnStop*, Transfer-: C_PROC;
      END;


Код на Обероне-2 более эргономичен.

3. Если делаем внешние библиотеки, то экспортируем процедуры и записи, а не методы. Внешней программой вызвать Files.dir.New(), скажем, проблематично. А Files_New - пожалуйста. Портабельные библиотеки должны иметь Oberon-интерфейс.

Автор:  Kemet [ Четверг, 27 Ноябрь, 2014 13:54 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

Дмитрий Дагаев писал(а):
Портабельные библиотеки должны иметь Oberon-интерфейс.
Я об этом и говорю.
Препроцессор ненужен, ибо мы не портируем с языка на язык, мы используем модули на чистом процедурном Обероне так же как в C++ используют библиотеки на С и никаких нравственных страданий по этому поводу не испытывают.

Автор:  id_ler [ Четверг, 27 Ноябрь, 2014 14:26 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

Если собрать dll/so-библиотеку Оберон-компилятором, то потребуется обычный интерфейсный модуль (WinApi, для примера).

Автор:  Пётр Кушнир [ Четверг, 27 Ноябрь, 2014 14:56 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

Редукционизм.

Автор:  Роман М. [ Воскресенье, 30 Ноябрь, 2014 14:01 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

В тему о препроцессорах:
Замена условным директивам ifdef

Есть такие мнения:

Илья Ермаков писал(а):
Есть некая служба (например, файлы).

Делается модуль (например, Files), в котором нет платформенно-зависимого кода. А объявлены абстрактные типы-интерфейсы. Конкретные их реализации засунуты в другой модуль, про который никто не знает (HostFiles, или там LinHostFiles, и т.п.). Важно понять, что не Files импортирует HostFiles, а наоборот: HostFiles импортирует Files. HostFiles реализует все абстракные типы ("классы" в привычных дельфистам терминах) и втыкает специальный объект-разъём, директорию: Files.dir. Через этот объект все обращения динамически перенаправляются модулю реализации. Таким образом, реализация подключается динамически, и даже может динамически без перезапуска программы меняться.

Почитайте учебник ББ раздел 3 "Приёмы проектирования".


bohdant писал(а):
Цитата:
Как заменяются "традиционные" директивы IFDEF, ELSE, ENDIF при написании межплатформенного кода?

Эту гадость я просто ненавижу :evil: . О какой читабельности может быть речь если невозможно понять о чем где идет речь.

Я не знаю как сделано в ЧЯ, расскажу как сделано в ГБ.
Системные функции (или лучше сказать платформ-зависимые) выносятся в отдельные модули (ядро) типа:
Unix.Platform.Mod, Win32.Platform.Mod и т.п.
В зависимости от целевой платформы компилируется нужный модуль(компонентная система однако), и это происходит незаметно со стороны пользовательской программы(модуля), т.к. мы вызываем Platform.FPS_ISDIR - результат булеан, и никакой путанины.
Кстати почти аналогично можно писать на FPC, но видать IFDEF писать проще :cry:


Rifat писал(а):
Я считаю, что хоть в каком-нибудь виде, но препроцессор необходим. Например, в заголовочных файлах Windows при определении различных констант и т.д часто определение зависит от версии Windows для которой компилируется программа, от того 32 битная или 64 битная программа, UNICODE или нет.
Вот кусок кода из WinUser.h
Код:
#if (_WIN32_WINNT >= 0x0500)
#define WM_MOUSELAST                    0x020D
#elif (_WIN32_WINNT >= 0x0400) || (_WIN32_WINDOWS > 0x0400)
#define WM_MOUSELAST                    0x020A
#else
#define WM_MOUSELAST                    0x0209
#endif /* (_WIN32_WINNT >= 0x0500) */

Все эти комбинации по разным модулям разнести практически невозможно, так получится "комбинаторный взрыв".
Вот как раз для таких случаев был бы полезен препроцессор.

Автор:  Роман М. [ Воскресенье, 30 Ноябрь, 2014 14:07 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

Я плохо представляю как можно объединить в одном файле код языков с разной семантикой.
Почти наверняка получается каша. И чем больше вариантов нужно поддерживать, тем хуже всё будет выглядеть и труднее будет понимать.

Выходом может являться разве что какой-то DSL с общим знаменателем (обероно-подобный ?), из описания которого будет генерироваться код для разных диалектов Оберона.

Автор:  Илья Ермаков [ Воскресенье, 30 Ноябрь, 2014 21:06 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

Ну, я вверху в сообщении имел в виду под препроцессором не ветвление в стиле #ifdef.

А то, допустим, что код библиотек написан на классическом Обероне, а потом для использования в конкр. реализации он прогоняется через транслятор Оберон2ДиалектОберона, который преобразует всякие мелочи (типа EXTENSIBLE и прочего).

Автор:  Kemet [ Понедельник, 01 Декабрь, 2014 22:29 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

Роман М. писал(а):
Я плохо представляю как можно объединить в одном файле код языков с разной семантикой.
Почти наверняка получается каша. И чем больше вариантов нужно поддерживать, тем хуже всё будет выглядеть и труднее будет понимать.

Выходом может являться разве что какой-то DSL с общим знаменателем (обероно-подобный ?), из описания которого будет генерироваться код для разных диалектов Оберона.

Наверное я как-то непонятно объясняю.
Я не предлагаю использовать препроцессор, я не предлагаю использовать директивы условной компиляции, я не предлагаю пихать в один файл поддержку языков с разным синтаксисом и семантикой.
Я предлагаю писать библиотеки на стандартном процедурном Обероне, используя в таких модулях импорт специальных настроечных модулей, нивелирующих различие в БАЗОВЫХ типах.
А затем, для конкретного языка/платформы уже использовать импорт этих,написанных на стандартном процедурном Обероне, поддерживаемом,как минимум, компиляторами Активного Оберона и Компонентного Паскаля(в реализации ББ), реализуя уже необходимые,более высокоуровневые схемы ( в случае необходимости), в стиле нужного каркаса. Ровно так, как используют библиотеки написанные на языке Си, в других языках программирования.

Автор:  Борис Рюмшин [ Понедельник, 01 Декабрь, 2014 23:15 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

А я согласен с Kemetом, так как допускаю, что можно выделить некоторый совместимый экстракт из нужных языков.

Автор:  Kemet [ Вторник, 02 Декабрь, 2014 01:58 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

Я немного поэкспериментировал - добавил удаленный ключ компиляции Oberon, скомпилировал небольшой модуль на Обероне DevCompiler.CompileThis TestOberon$
В модуле на КП импортировал модуль Оберона - всё работает, типы/переменные/константы используются, процедуры вызываются. Понятно,что записи расширить уже нельзя, но этого и не нужно, цель совсем другая.
Конечно, нужно на более серьезных вещах потестировать, исходники компилятора посмотреть на предмет возможных проблем, но думаю их там нет.

Автор:  Иван Кузьмицкий [ Вторник, 02 Декабрь, 2014 09:44 ]
Заголовок сообщения:  Re: О совместной работе Оберон-сообщества

Kemet писал(а):
Я предлагаю писать библиотеки на стандартном процедурном Обероне, используя в таких модулях импорт специальных настроечных модулей, нивелирующих различие в БАЗОВЫХ типах.
Разрешите подписаться. Кстати, идею стандартной библиотеки сто лет тому назад ещё Руслан Богатырёв озвучивал.

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/