OberonCore

Дмитрий, а что не меняется? Вам ведь нужно Dev запустить и параметры ему передать. Я пока так Вашу задачу понял. А в цикле это будет или нет - вопрос другой.

https://svn.oberoncore.ru/community/BlackBox-Linux

Доступ - RW группе, которая занимается всеми разработками у нас тут. Димыч, вы теперь тоже член партии , для вас данные в ЛС. GUEST если вам это интересно - присылайте логин и пароль. Вопрос о доступе только на чтение для всех желающих пока в процессе.

После некоторой паузы и переустановки всего домашнего ПО хочу поделиться
результатами работы и исследований.

Выкладываю файлы для сборки ББ под Линукс. Пока на файлообменник, завтра
постараюсь выложить на SVN.

Скачать можно отсюда и отсюда.

Что в архиве?
В архиве файлы HOST.zip и TARGET.tar.gz.
Первый содержит два файла - инструкцию по сборке HOST-системы и по
компиляции TARGET-системы, второй - bat-файл для запуска HOST-системы на
Windows (нужен при старте HOST-системы и указания где лежит
TARGET-система).

Второй (TARGET.tar.gz) содержит уже собранную TARGET-систему.
Готовую к запуску.

Да, термины HOST и TARGET служат для различения
кросс-компилируемых систем. HOST - собирающая, TARGET - собираемая
системы.

Внутри TARGET-системы собраны подсистемы Xwin и Gtk. Xwin - заголовочные
модули для X Window System. Gtk - заголовочные модули для GTK2.
Ни то, ни другое не отличается полнотой перевода. И если Xwin - работающая
подсистема, то GTK - это перевод с Modula-2 на CP, сделанный "в лоб".
Я его даже еще не пытался запускать. Но, перевод делался в связке
HOST-TARGET, так что в архиве он есть.

Вообще для меня вопрос остается открытым, на какую систему ориентироваться
с точки зрения интерфейса - X, GTK или Motif. Я склоняюсь к GTK, но
трудоемкость там довольно высокая. Рассматривал Motif (OpenMotif), там
надо вручную все переводить или с Модулы опять же.

Буквально вчера наткнулся на Gtk# из проекта Mono, там сделан
автоматический перевод заголовков GTK на C# с помощью XSLT, но еще не
копал. Кому интересно - http://gtk-sharp.sourceforge.net/ и
http://www.mono-project.com/GAPI

Дмитрий

В догонку.
Во FreeBSD с установленным Linux-compartibility пакетом BB запускается, отрабатывает консольная процедура, а вот X-часть не работает, говорит, что не находит libX11.so.6.
Но, главное, запускается!

Так я же говорил, что неграфическая часть запускается.

У меня дома идёт миграция со старого компа HDD 20 Гб на старый комп HDD 200 Гб, но процесс идёт с трудом (флопик, например, запустился с 4 - го раза, причём, дважды пришлось доставать ОЗУ, один раз - отключать веник). Как закончу - протестирую работу графической части у себя. Может, случится чудо : ).

Код размещен на SVN.
Правда, похоже, что libBB.so туда не попал - был проигнорирован при импорте.
Исправлю, хотя его можно пересобрать

имхо, можно вообще кодовые и символьные файлы исключить из репа, кому надо - откомпилируют сами, это же секундное дело

Само обращение к процедурам внешних библиотек делается совершенно единообразно (так, как описано в "Платформенно-зависимые особенности" в документации). Компилятор генерирует точки подстановки адресов и таблицу в кодовом файле модуля. А редактирует связи StdLoader при загрузке модуля. Он получает адрес для связывания путём вызова Kernel.LoadDll и Kernel.ThisDllObj. Т.е. вся платформенность по доступу к ДЛЛ собрана в двух этих функциях. В Kernel для Linux они реализованы (через библиотеку dl Линукса).

Уважаемый Дмитрий,

спасибо за Вашу работу - стартовый пакет собран очень аккуратно.
Мы в "Метасистемах" сейчас начали работать по своим задачам от него.

Касательно Dev под Линукс: тут в OpenBUGs обнаружилась интересная подсистема Lindev. Это как раз вариант компилятора, расчитанный на консольную работу в Линуксе (т.е. без подсистемы Text). Подсистема недокументирована, это у них "кишки", которые отвечают за динамическую генерацию из их скриптов...

Посмотрите как точку использования подсистемы модуль BugsCPCompiler.

В той Dev, котороя выложена на SVN подсистема Text используется. Может быть, не стоит от Text отказываться, Илья? В консольном варианте Вашего компилятора она присутствует.

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

В моём Rocot весь Framework изолирован и подключается как частная реализация.

Но с Линуксом дело в том, что Text тянет много хвостов из графической части каркаса. Которую сейчас поднять нереально.

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

Речь о том, что в текущем варианте "те части, которые занимаются обработкой содержания" тянут по импорту конкретно гуёвую часть среды, почти весь каркас в итоге.

Пусть тянут. Пока те "гуевые части" которые тянутся по импорту не готовы их можно заменить заглушками. Так о чем всё-таки речь тогда.

О том факте, что братья-финны сделали версию Dev, отрезанную от Text. Кого интересует - можно посмотреть.

Её удалили с SVN. Почему?

Её туда никто и не клал.
Качайте OpenBUGs целиком - и найдёте там подсистему Lindev. Она не упомянута нигде в документации, это внутренность OpenBUGs.

Вообще-то я делал в своё время консольный компилятор ББ. На svn-е подсистема Dev и сейчас отрезана от графики - проблема была не в использовании Text, а в понатыканом всюду StdLog. Если же нужны исходники стартовых модулей консольного компилятора - могу поискать. Правда там тихий ужас

А подсистема Text на графику никак не завязана - только на [System]

StdLog можно перенаправлять в стандартный вывод. Если у Вас его модуль сохранился - можно его использовать.
В Text реализовано текстовое отбражение, которое умеет себя показать. Сделать это без графики невозможно, поэтому прорисовку текстов надо отсрочить до появления Linux-графики в каком-либо виде. Пока же можно ограничиться отладочной печатью соответствующих процедур.