OberonCore

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

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

Я именно об этом случае, к Оберонам, действительно, не имеет отношения. Я не имел в виду, что МультиОберон так долог. Историю слышал от вас устно, теперь вот из устного предания она превратилась в письменный источник. До этой истории я собирал как-то раз gtk, и это очень долго у меня выходило. Я полагал, что отсутствие опыта, кривые руки и слабый компьютер тому виной. А потом вас послушал и решил, что не, наэн со мной все в порядке.


А почему же не сделать? Вкратце (осторожно: многобукаф):
Фронтэнд Мультиоберона (ФЭМ) выдает таблицу символов, унаследованную от СР2, обозначим ТС.
Фронтэнд Гершеля (ФЭГ) выдает семантический граф, обозначим СГ; он поступает на вход прямого генератора кода.

Взмах рукой - и:
ФЭМ --выдает--> ТС --поступает в--> Трансформатор ТС=>СГ --поступает в--> Прямой генератор кода от Гершеля.

Трансформатор у меня, по случаю, имеется - появился в ходе экспериментов над ТС, которые привели к появлению СГ.

Ответ Luowy и вопросы, относящиеся к LLVM, МультиОберону и ко мне здесь

Сотрудничество лучше, и намного хуже бежать в разных направлениях.
Один разработчик, который держит невольно многое в своей голове - а зачем ему - не надо кому-то объяснять - это всегда ненадёжно ...
как уже много раз не могли найти как кто-то из основных разработчиков что-то менял , а потом его это уже не интересовало ... так были похоронениы многие перспективные проекты.

Если собираетесь использовать ))), то почему просто не участвовать в совместной разработке? Тем более идейных противоречий нет?

Сообщество выиграет только от совместной работы. Если вы готовы обсуждать чего ещё нет в проекте
нативного Omb, то может быть и получится. У вас это пока на уровне красивой идеи, у Дмитрия Дагаева информации о проекте больше, тем более в статьях и на Днях Оберона уверенно прослеживается линия по разработке ПО, пригодного для промышленной эксплуатации.

У Вирта не стояла задача в разработке ПО, предназначенного для промышленной эксплуатации.

"1 человек", который во всем разбирается - не может быть целью проекта.

Тогда из этого логически следует, что целью проекта может быть "много человек, которые ни в чем не разбираются" Для каких-то целей это может быть хорошо, например, строится какой-то секретный объект, но никто из строителей не знает проект полностью

Когда только начинал заниматься BB, меня поразила дискуссия, в которой обсуждался последний на тот момент проект Герметизации - был один автор этой версии, но потом стал заниматься другими проектами и пропал - концов не могли найти

Один основной автор, который держит многое в своей голове - это Ненадёжно Всегда! ... Говорю как будущий потенциальный пользователь. Вы сами решайте - объединяться основным разработчикам нативного компилятора или нет ...

Если это вопрос? ... Когда ставится задача подобная задачам в докладах Дмитрия Дагаева - разработка проектов ПО, для промышленной эксплуатации, а не просто для обучения студентов по теме "Разработка собственного компилятора" ... И этот намного более сложный проект нового компилятора могут поддерживать несколько основных разработчиков, даже если один из них перестает заниматься этим проектом. При этом у них остаётся желание заниматься этим компилятором, у которого уже появились пользователи.

Соглашусь; целью проекта Вирта был не 1 человек (он), который во всем разбирается, а система, обозримая для 1 человека.

А мне любопытно: как вы определяете термин "промышленная"? Кроме очевидного и неинтересного определения "та, которая используется в промышленности" - какими свойствами нужно обладать системе, чтобы мы признали ее промышленной?

Чем, скажем, система Оберон - не промышленная?
И чем компилятор СР2 - не промышленный?
И чем gcc - промышленный?

arlean1, надо смириться с тем, что коллективного творчества не бывает. А разработка компилятора — это научно-техническое творчество.
Дмитрий Викторович сформулировал хорошую метафору на последней встрече про лебедя, рака и щуку. Суть в том, чтобы дополнять друг друга. Но нечем будет дополнять, если никто не творит. Пусть Антон творит так, как ему нравится, без ваших ограничений и поучений. Многие противоречия совершенно несущественны потому что их на самом деле нет, они кажущиеся. Антон вон написал, что у него даже уже есть конвертер символьных таблиц. Я в свою очередь слежу за фреймворком.

Если нужен нативный компилятор для x64, поддежите Антона небольшим, но донатом.

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

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

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

Если посмотреть выступления Дмитрия Дагаева за последние годы на "Днях Оберона" в Орле, несколько его последних статей, то он посвятил этой теме достаточно много времени, рассказывал о своем опыте и требованиях в своей предметной области. Т.е. опыта и понимания в этой теме у него много, и как этих нужных Целей надо добиваться.

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

arlean1, не спорим, что Дмитрий Викторович прекрасный разработчик, но он не заинтересовался тематикой создания нативного компилятора для x64. Мы пытались заинтересовать. Ваша мысль уже предельно понятна.

Ваша критика ясна. Я с вами не согласен. Считаю, что вы не в курсе темы. Обсуждать социологические организаторские вещи тут считаю уходом от темы.

"вам просто нужен хороший аналитик" -- опять какая-то маниловщина.

Люди делают, что могут в конкретных реалиях, не надо им мешать. Иногда здорово выходит.

Кроме этого он ещё и отличный системный аналитик и тема им уже проработана. Но мне непонятна ваша поспешность с выводами и ненужная в данном контексте резкость суждений, которая, возможно, мешает вам договариваться с людьми ... ((( У вас на странице проекта больше текста написано о том, почему выбрано такое название и кто такой этот астроном Гершель ...
Но ещё буквально вчера на первой странице у Авторов проекта спрашивают - это сообщение добавлено: Понедельник, 20 Июль, 2020 20:15 , а по времени вашего региона это глубокая ночь:

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

Только помогать надо.
Пока эта задача сформулирована у Ивана на уровне задания для курсовой студенческой работы.
Аналитики, тем более системные, и нужны, чтобы получалось на профессиональном уровне.

Антон тут больше за аналитика и инженера. Я больше в роли организатора, вдохновителя, подсобного мозга, помогаю искать спонсоров, оформить. У меня, конечно, есть свой взгляд как это должно быть. Но стараюсь его больше держать при себе Есть ряд практических пожеланий от меня:
- минимальные изменения фреймворка, тут у нас Антоном отлаженная работа, так как уже полгода работаем над версией 1.8 и неплохо сработались.
- максимальная воспроизводимость вычислений на 32-битной и 64-битной версиях.

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

Вы меня чересчур вольно трактуете. Разве это я говорил? Я говорил, что МультиОберон для того и сделан, чтобы подключать разные бэкенды. И сам адаптировал под него DevCP*. Для чего я это делал? Чтобы получить нативный компилятор Omb для 32-бит.

Поэтому я только за, если кто-то решит делать Omb-64. И уважаемый коллега arlean1 об этом говорил здесь. Я много раз говорил, что я за диверсификацию, включая нативный компилятор. Поэтому дело не в нативном компиляторе.

Где я против? Объясняю на примере. В BlackBox 1.7 уважаемые разработчики из центра решили поменять интерфейс Files.File. Добавили-то всего 2 метода... Польза от этого была мизерная, но стольких людей это из-за этого напрягло, особенно тех, кто должен поддерживать совместимость с предыдущей версией.

Но это - цветочки, по сравнению с теми изменениями, которые повлекут за собой изменения фронтенда компилятора! И при этом никакого внятного технического обоснования не представлено.

Как это часто бывает на форуме - беседа заходит в деструктивное русло. Не раз уже в этом убеждаюсь. Это потому что за словами не видно эмоций.

Дмитрий Викрович, уточню на всякий случай, вы готовы принять участие в разработке Omb-64? Вы ведь ясно выразились, что хотите продолжить доработку своих начинаний по LLVM. Это вполне правильно и рационально. Поэтому тут никакого негативного оттенка. Я бы даже удивился, если вы вдруг занялись нативным компилятором.

Давайте продолжим в русле конструктивной дискуссии и обмена опытом.

Сейчас идет обсуждение аспектов версии 1.8. Там тоже есть изменения. Мы ведем открыто обсуждение. Но я понимаю, что невозможно участвовать во всём и везде. Потом будет много негатива на этот счёт. У всех изменений есть обоснования.