Оберон-клуб «ВЄДАsoft»

Сегодня состоялся официальный выпуск проекта Free Oberon - кроссплатформенной среды в стиле Free Pascal для разработки на Обероне.
Новая версия имеет поддержку графики (модуль Graph) и снабжена обширной документацией. Проект выпущен под свободной лицензией GPLv3.
http://freeoberon.su

Документация: http://freeoberon.su/files/FreeOberon_v0.1.0.pdf
Скачать Free Oberon: http://freeoberon.su/files/FreeOberon_v0.1.0_win32.zip (не требует установки на Windows)
Среда поставляется с несколькими примерами программ.

Приветствую!
Я не люблю псевдографику, но надо отдать должное: игрушка занятная. Есть парочка "претензий":
1) В документации не хватает подробного описания языка. Это O2? Но O2 в чистом виде, так, как он был описан в начале 90-х, устарел. По крайней мере, устарела система типов. Кое-где в исходниках попадается тип HUGEINT. Значит, в этой реализации язык был модернизирован. Неплохо бы отразить в документации все расширения и изменения языка, перечислить все элементарные типы, описать псевдомодуль SYSTEM (и другие псевдомодули, если есть). Сборщик мусора, как я понимаю, есть? Однопоточный?
2) Консольные приложения (которые используют модули In и Out) в Windows не запускаются вне IDE. То есть, непосредственно из самой ОС запустить скомпилированную программу невозможно. По крайней мере, никаких видимых действий не происходит. Может быть, в заголовке бинарника не установлен флаг консольного приложения или причина в чем-то другом. Вообще, ИМХО, консольные приложения -- это, скорее, архаизм. Но всё же...
3) Как можно скомпилировать dll?

Рад слышать!

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

Да, это Оберон-2, но с изменённой системой типов. Это описано в документации, а также на главной странице сайта freeoberon.su. Лично мне нравится Оберон-07 (я не отрицаю некоторых его недостатков, но понимаю, с какими огромными преимуществами они связаны), скорее всего основная ветвь развития Free Oberon будет означать постепенный переход на Оберон-07, с этим связана и задержка с документацией.

Есть, однопоточный.

Я понимаю, что это неудобно, но сейчас дело обстоит так: любое приложение компилируется как "оконное", и в него при компоновке включаются модули Graph и SDL2. Чтобы этого не было, необходимо поменять местами файлы "compile_no_graph.bat" и "compile.bat", находящиеся в каталоге "FreeOberon\data\bin" (на самом деле, используется только файл "compile.bat"). Сейчас идёт разработка система автоматической сборки проекта. Это дело не простое, требующее тщательного продумывания.

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

С ходу ответить не могу, т. к. этим вопросом не занимался. Можно ли обойтись правкой файла compile.bat, а именно изменением команд, даваемых компилятору GCC, или же получающиеся в процессе трансляции исходные коды Си тоже придётся менять — не знаю.

Насколько я знаю, вы связаны с разработкой компилятора Оберона-07. Хочу задать вопрос, связанный с развитием Free Oberon. Какие расширения языка Оберон-07, позволяющие работу с динамическими массивами без использования псевдомодуля SYSTEM, вам известны?
Например, можно ли в каком-либо компиляторе языка Оберон-07 объявить локальную переменную следующим образом: VAR m: ARRAY OF CHAR;, а затем задать размер массива оператором NEW? (И как в таком случае быть с некоторыми возникающими в языке неоднозначностями?)

Странно... Один из главных недостатков O7 -- отсутствие методов. И лично мне их реально не хватает. Я не могу поверить, что кому-то может быть удобнее писать

вместо простого и понятного

Добавьте к этому еще и необходимость инициализации процедурных полей.

Вообще, O7 -- это язык не для удобства программиста-пользователя, а для удобства разработки компилятора. Этим и объясняется его экстремальное упрощение, даже переупрощение в ущерб удобству использования. Я бы скорее добавил методы в O7, чем удалил их из O2. А процедурные переменные лучше оставить для более низкого уровня, вроде обратных вызовов.
И еще: система FreeOberon предназначается для использования в обучении, сомнительно, что процедурные переменные проще для понимания начинающими программистами чем методы. Это всё, конечно, ваше дело, просто я имею немалый опыт разработки на O7 и хорошо чувствую его недостатки.


Отсутствие динамических массивов -- другой серьезный недостаток. Это резко увеличивает частоту использования модуля SYSTEM или заставляет делать списки там, где можно обойтись массивом.
Rifat, автор компилятора Oberon-07M, сделал расширение для динамических массивов традиционным для оберонов способом: POINTER TO ARRAY OF, и для упрощения ограничился только одномерными массивами.
В реализации Oberon-07 Astrobe для микроконтроллеров, если я не ошибаюсь, динамические массивы сделаны именно так, как вы предлагаете: ARRAY OF. При этом, так объявить можно только локальную переменную (выделение памяти происходит прямо в стэке). Сделано это, похоже, для повышения эффективности работы с динамическим массивом в условиях микроконтроллера: память выделяется простым изменением регистра-указателя стэка и освобождается автоматически при возврате из процедуры. Подробно, техническими деталями я не интересовался.

В консольных программах для Windows, созданных в среде FreeOberon, проблема с русскими буквами из-за разницы в кодировке (как и было описано ранее).
Временный способ частично обойти проблему - перед запуском программы установить кодовую страницу UTF-8. Для этого можно запускать программу через батник, где первой строкой команда "chcp 65001", а второй - запуск самого exe-файла. Можно автоматически создавать такой такой батник, если добавить строки
в файл compile.bat после вызова gcc. Правда это срабатывает при выводе строк процедурой Out.String, для процедуры ввода In.Line это не помогает.

Я использую "*" для объявления динамического массива в O7: https://github.com/vladfolts/oberonjs/w ... mic-arrays

А если это будет выглядеть вот так:


В любом случае в методах необходимо передавать ссылку на себя.
Во второй строке для list -- непонятно,что это -- вариант от мене лишён данного недостатка.
Кроме того, в секции BEGIN модуля можно проводить инициализацию самого модуля, а для типа туЦепь в модуле модЦепь можно предусмотреть процедуру Создать():туЦепь, где членам типа туЦепь -- процедурным переменным можно присвоить ссылки на процедуры из модуля. Но! передавать ссылку на себя всё-равно придётся.
Так-что можно, но не совсем понятно зачем.

З.Ы. Я исхожу из того, что В Оберон-07 (да и в любом Обероне) нет понятия "класс". Потребность в нём перекрывается понятием "модуль". Типы разделяют семантику классов, но Вирт чётко разделяет код и данные. Типы относятся к данным.

_________________
Действия профессионала предсказуемы. Но в мире полно любителей!

Жаль, что не BSD - подобная лицензия. Например, BSD подобная позволила бы на базе этого проекта создать что-то наподобие 1С и зарабатывать деньги. А так - вряд ли получится.

Я про это частенько веду жаркие споры с тем же Комдивом. Умный парень, грамотный, но вот не желает делать BSD-2!))
Свой вариант компилятора на основе компилятора Антона Кротова (akron1) я решил делать в пассивном режиме, именно по причине его лицензии. Мои файлы под BSD-2 перекрываются его GNU GPL.

С другой стороны, надо правильно понимать GNU GPL. Да, компилятор именно под этой лицензией, но в соответствии с разъяснениями на официальном сайте ФСПО -- лицензия не распространяется на производные продукты, если только существенная часть продукта не содержит в достаточном объёме куски подпадающие под действие GNU GPL. Например, намертво зашитый компилятор Комдива в конечный продукт -- это 146% GNU GPL. Если связь через именованный канал, а сам компилятор просто лежит рядом и его легко заменить на аналогичный -- то уже нет. Например, результат работы BISON\LEXX -- входит в выходные файлы, но это оговорено отдельно и на них лицензия не распространяется. Так же, как например лицензия LibreOffice на файлы формата *.odt|*.ods|*odg. Офис -- да, GNU GPL. А файлики -- личные.

Но вот если есть желание модифицировать сам компилятор -- то его коды придётся открыть. Но это не значит, что придётся открыть коды и на продукт, который использует такой модифицированный компилятор. Это как разные квартиры в многоквартирном доме. Рядом, под одной крышей, но разные владельцы.

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

_________________
Действия профессионала предсказуемы. Но в мире полно любителей!

Вот, например, EMACS - он под GPL, и весь код, все расширения для него - тоже заражаются GPL. Думаю, в случае "1С", где реализация языка встроена в саму платформу, всё достаточно однозначно - подпадает. Среда, кстати, не сильно проще компилятора, так что трудоёмкость доработки среды тоже может требовать защиты, тогда опять же GPL не подходит.