OberonCore

Я весь форум замусорил, не хочу и этот замусорить. Пожалуйста, напишите в личку, если есть кто-то, кто знает A2, а я задам вам в личку свои вопросы. Хотя, раз уж я эту тему создал, то в ней могу спросить то, что меня интересует:

• есть ли функция перехода к определению? Рыл исходники, пока не нашёл.
• есть ли отладчик?

А последующие вопросы уже в личку.

1) Нет, реализована лишь навигация по структуре - если перемещать курсор по тексту, то в дереве модуля активный элемент подсвечивается, и наоборот, если в дереве структуры модуля нажать на элемент, то курсор в редакторе установится в нужное место. Переход к определению из произвольного места требует наличия некоторой информации. Не то чтобы её сложно получить, просто это никому особо не нужно было - при реальной разработке используются внешние инструменты.
2) Нет, по крайней мере публично не доступен. Есть модули Debugging.Mod, DebugДщп.Mod , используемые для отладки и логирования.

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

Какие внешние инструменты традиционно используются и как вообще устроен процесс разработки (где об этом написано)?

И чтобы два раза не вставать - есть ли какой-то план разработки, задачи, которые можно поделать для разгона? Лично я начал бы с того, что собрал бы у себя всю документацию. Есть сайт a2os.org.ua, но неясно, сколько он ещё проживёт - надо сделать зеркало. Обновить туториал.

Никто не говорит, что отсутствие функционала это хорошо. И большинство людей понимают, что минимализм и отсутствие функционала это совершенно разные вещи. Но комьюнити у оберон-технологий маленькое, а если учесть и фрагментированность, обусловленную множеством реализаций, то оно вообще исчезающе мало. И люди, которые всё-таки используют "оберон" как стек технологий, не склонны делиться своими наработками. Просто, если у вас есть конкурентное преимущество, на котором вы неплохо зарабатываете, зачем его отдавать посторонним. Эта проблема не только в обероне - в закуклившихся проектах это распространено, так как нет мотивации публиковать то, на что ты "потратил лучшие годы своей жизни".
Большое сообщество - большая конкуренция за место в этом сообществе. А подняться в сообществе, заныкав вкусные плюшки и грызя их по ночам в темном темном уголочке, не получится. Поэтому оберонам не хватает критической массы, способной произвести достаточно кинетической энергии и сказать "лёд тронулся, господа присяжные заседатели...".

Спасибо, печальная картина, даже не знаю, что ответить. Переход к определению, думаю, я осилю и без больших трудозатрат. А вот отладка... Один отладчик в другой я кое-как оборачивал, а с нуля... Не имею не малейшего представления, с чего начинать.

Ну, переход к определению хорошая плюшка, да. Но, учитывая, что в обероне область видимости четко определена и локализована, и требуется обязательная квалификация модуля, то пройтись по иерархии не сложно даже в текущем состоянии. . Понятно, что если мы не используем квалификатор, то сущность принадлежит или локальному скопу, в котором находимся ( процедура и она подсвечивается в структуре модуля ) или типу, которому принадлежит процедура ( и он подсвечивается ) или модулю, то есть найти не сложно. Если есть квалификатор, опять же, иерархия скопов прозрачна и найти ее в структуре не проблема. Не удобно, да, но можно достаточно быстро.
В любом случае, перейти к определению можно будет только в пределах модуля, потому что найти внешний модуль по его имени в общем случае не возможно, потому что имена программного модуля и объектного модуля могут не совпадать. например имя файла у наc Windows.Test.Mod, Linux.Test.Mod, а внутри он описан как module Test; или module Test1 или...
Частично эту проблему решил бы файл проекта, в котором это всё описано. Или описать package в файле типа Release.Tool и, используя Release.Mod строить проект на лету для выбранного билда.

Чтобы быть находимой, достаточно того, чтобы эта инфа должна записываться компилятором и быть среди метаданных модуля после того, как он загружен. Обычно это "информация об исходном тексте", которой пользуются отладчики, и она является частью отладочной информации. В ББЦБ это есть, неужели же нет в более продвинутой A2?

> Не удобно, да, но можно достаточно быстро.
Но после лиспа, SQL, 1С, C#, Js довольно трудно себе обосновать, почему можно позволить себе терять столь драгоценное время.

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

Ок, может быть, но это - малосущественная деталь. Там есть отображение номеров строк на адреса в коде, на чём основано отображение трапов и пошаговая отладка. Неужто имя файла, если оно понадобится, не поместится? Тут вопрос другой: кто это будет делать?

А можно как-то зарегистрироваться на www.ocp.inf.ethz.ch? Он не отправляет на почту сообщение о подтверждении регистрации.

Куда не поместится? Вроде речь шла об IDE, а оно работает с исходниками. В А2 для кроссплатформености используется, например, такая схема именования Window.MyModule.Mod, Linux.MyModule.Mod, которые внутри именованы как module MyModule; именно это имя используется при импорте. Как узнать, какой именно файл открыть Window.MyModule.Mod или Linux.MyModule.Mod? А может вообще Solaris.MyModule.Mod или Darwin.MyModule.Mod? В АО имя файла и имя объектного модуля вообще никак не связаны. А ведь ещё есть разделение и по архитектуре процессора...
Так что перейти в другой модуль достаточно нетривиальная задача. Поэтому я и говорю, что частично эту проблему может решить файл проекта, где гвоздями будут прибиты имена файлов, или указана некая маска, по которой можно сформировать имя файла из имени объектного модуля.
И да, в одном файле может находится несколько модулей, как их в таком случае автоматически искать?

> Вроде речь шла об IDE, а оно работает с исходниками.
Это зауженное представление об IDE. В лиспе IDE работает И с исходниками, И с образом, получая инфу и оттуда, и отсюда. У в каком-нибудь SQL вообще IDE работает только с образом - все исходники хранятся в СУБД.

Система BlueBottle знает по имени модуля, где его найти? Как интерпретатор находит модуль, если он не загружен в память? Или он найдёт только тот, который загружен?

У объектных свой каталог, отдельно от исходников.

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

Другой вариант - типа файла проекта, а точнее, набора правил, который преобразует имя модуля в имя файла - тоже жизненен. Менее надёжен, но более гибок, например, позволяет проинсталлировать кросс-компилированную систему на другой компьютер и тыкать в исходники. В лиспе и такой вариант есть - так обычно показываются исходники самой реализации.

Есть и третий вариант - разработка в образе, когда объектный файл содержит все исходники в себе.

Какой из них лучше - это вопрос, достойный обсуждения.

По моему все варианты одинаково хреновые. В чём проблема в добавить к именам файлов префикс, если известно на какой платформе/процессоре оно запущено? Я примерно так и сделал у себя в ББ.

Бинарники нам ничем не помогут. Кроссплатформенная разработка привносит некоторые сложности, в том числе и поиск нужного файла. Это легко решается в сборочных скриптах или проектах, но это для сборки, когда файл всегда один, под конкретную платформу. Если же мы занимаемся разработкой, то всегда должны учитывать наличие некоторого количества поддерживаемых платформ. И ответ на вопрос, какой файл открывать - Windows.Module.Mod или Linux.Module.Mod, а может AMD64.Module.Mod - мы не получим. Можно, конечно, использовать некие соглашения или префиксы, и открывать конкретный файл в зависимости от того, на какой платформе работаем - если это Windows, то и пытаться открыть Windows.Module.Mod. Однако, у такого подхода есть существенные недостатки. А вдруг это общий модуль, и у него просто нет префиксов, или он общий для нескольких платформ, а для какой-то конкретной - отдельный, с префиксом. Ни и самое главное, как тогда разрабатывать в Windows для нативной A2, учитывая несколько архитектур процессора? да и для других хостов? Ведь тогда мы не сможем перейти в файл нужной нам реализации.
Поэтому все эти умолчания и подразумеваемые схемы именования ничего не решают, скорее наоборот.
Запихивание всё в один файл и использование директив условной компиляции также мало помогает, вообще в исходниках заблудишься. И ещё момент о директивах условной компиляции - като раз я решил проект отрефакторить в одной распространенной ide, там как раз были директивы, так оно вод текущую платформу переименовало, а под другие - нет, ну а что, участки кода не активные же.
То есть у всех методик одни и те же проблемы - отсутствие доступа к исходникам модуля отличной от текущей платформы. Лично для меня более правильным подходом было бы открытие всех программных модулей, относящихся к имени объектного модуля. То есть в ide должны открываться всё файлы по маске содержащей имя объектного модуля. А ещё лучше было бы наличие спецификации модуля.

В символьный файл можно.

Эта тема, думаю, уже достаточно замусорена, можно, я тут позадаю вопросы?
Вот вопрос такой

Чему равен CHAR в 32-разрядной WinAos в 2015 году?

CHAR8, как и в 2019

Спасибо. А где это записано?