OberonCore

Реально ли сделать из компилятора Black Box-а "обычный" компилятор работающий из командной строки, не переписывая его снуля конечно?

И если можно, хотелось бы узнать, что да как сделать.

Почему не реально? Эта задача уже поднималась, в свете интеграции в системы автоматического олимпиадного тестирования. Иван Горячев (Ivor) тогда за пару дней сделал такой консольный компилятор.
http://blackbox.metasystems.ru/forum/viewtopic.php?t=62
У меня лежит где-то промежуточная версия, но, честно говоря, я не смотрел и не помню где. Спросим у Ивана про окончательную версию, и тогда либо он сам скинет вам ее, либо выложим...

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

Второе конечно предпочтительнее. Мало ли кто ещё заинтересуется.

Я прекрасно понимаю Вас, когда Вы ратуете за то, чтобы выкладывалось побольше исходников и т.п. Однако у этого есть и обратная сторона: если выкладывать все в недоделанном виде, возникает большая свалка. Люди начинают использовать промежуточные варианты, потом разработчика вяжет обратная совместимость, и получается не как лучше, а как всегда...
Не хочется превратить BlackBox в подобие Линукса. Линукс - отличная система с современной архитектурой, однако крайне раздражает масса похожего софта, из которого ни один не работает, как надо, тысячи файлов, про которые уже никто толком не помнит, что и для чего нужно. Вот в чем разница: когда человек, начинающий заниматься ББ, увидит что-то необычное, непривычное, и спросит у меня - а почему сделано именно так? - я смогу на любой такой вопрос дать аргументированный ответ и назвать веские причины проектного решения. Когда я начинаю осваивать Линукс и задаю аналогичные вопросы, на большинство из них ответ один: "А шут его знает, так получилось, уже никто не помнит, почему, просто так принято, и привыкли все и т.п."

Главым образом, надо править DevCPM и DevCompiler.
Вместо TextModels использовать "обычный" текст, вместо StdLog вывод в stdout. Избавиться от DevMarkers и выводить сообщения об ошибках опять же в stdout, желательно в формате какого-нибудь популярного компилятора.

Есть еще одна проблема. Типичная схема использования "обычного" компилятора отличается от того, что принято в ББ. И возникают интересные вопросы - куда класть объектные и символьные файлы и где искать символьные файлы импортируемых модулей?

Уверен что BB это не грозит. Обратная совместимость - общая проблема для всякого развивающегося приложения. Если старые программы не работают в новой версии системы - тем хуже для них. А Linux системы просто больше по объему. И сравнивать их надо с аналогичными системами (которые ОС). И еще. Между знакомством и использованием существует небольшая разница. Как раз достаточная, чтобы не превращать в свалку копилку используемых средств.

А чем не устраивает механизм подсистем? Вполне можно его и оставить.

Вот именно.
Оставить все как в полном ББ, просто команды вызывать с командной строки и ее же использовать в качестве Log.

По кр. мере достаточно, чтобы новый народ начал вкус чувствовать.

Я не то говорил.
Это будет половинчатое решение. Желательно использовать консольный компилятор независимым от системы образом. Включая сюда и возможность редактирования текстов модулей посторонними редакторами. В случае документов BlackBox это затруднительно.

Зато быстро можно сделать. А потом уж вторую половину.

А текстовый формат для исходников -- самая маленькая проблема.

Собственно, и проблемы никакой нет. Все вопросы формата хранения решаются через конверторы.

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

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

У меня контрпредложение: не делать лишних телодвижений. Подождём материалов от ОМС по юникоду, ещё по разным поводам репы почешем, и тогда уже всё в одном пакете выпистим.

Боюсь, не оценят.

Указанный компилятор в планы OMS не входит. Поэтому нужно серьезно подумать стоит ли его вообще включать. Кто его будет сопровождать к примеру? А если даже и найдутся желающие - будет ли возможность и дальше использовать оригинальные исходники. Вопросов в общем больше, чем ответов. Хотя как промежуточный вариант для сегодняшних запросов, почему его не сделать – не понимаю.

Мне кажется было бы супер, если бы в ББ встроить формат исходников в виде OpenDocument http://ru.wikipedia.org/wiki/OpenDocument. Во-первых это была бы первая система программирования, поддерживающая такой формат, во вторых, решилась бы проблема чтения ББ-файлов сторонними программами без потери форматирования и возможность их редактирования. Да что там объяснять, всем понятно преимущество открытого стандарта над внутренней разработкой типа формата odc. Кроме того, есть надежда, что к этому формату приспособят со времененм и какую-нить системку типа Diff.

Вот кто бы ещё это сделал? Я даже описания стандарта не видел, а оно, говорят, занимает 700 страниц. Это вам не Оберон!

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