Мощная среда ZXDev для разработки НА ПЯТИ ЯЗЫКАХ для ZX готова к тестированию

[Vitamin]

А то в Обероне я привык перечислять в секции импорта модули в любом порядке, и считаю это удобным.

Это препроцессор фигней страдает. Можно посмотреть что на вход компилятора попадает.

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

А кто-то такое утверждал? Чем более низкоуровневый язык, тем ниже потолок сложности создаваемых систем.

[PPC]

Console.c:17: error: incompatible types for redefinition of 'Console_WriteStrLn_WinAPI'

А то в Обероне я привык перечислять в секции импорта модули в любом порядке, и считаю это удобным.

Боже мой, ну при чём тут импорт модулей или символов из модулей?

Вы ещё ничего и никуда не импортируете, и, возможно, вообще этот ваш Console_WriteStrLn_WinAPI не линкуете.

(Подразумевая, что Console_WriteStrLn_WinAPI - callable entity), вы в Обероне, что, можете объявить её signature, потом переобъявить её signature другими другими типами (ещё параметров добавьте-уберите) и не посыпаться в рантайме? Вас ведь компайлер умный предупреждает. Зря, наверное.

Если sizeof() типов одинаковый и возможен type-to-type mapping, отключите strong type checking и поглядите, скомпилит-ли.

Ну а так - бага в одном из .h файлов, который windows.h не включает, но переопределяет уже объявленные там типы. Только не надо говорить, что windows.h это должет делать - это MS API, они имеют полное право introduce свои типы без учёта, что кто-то уже WINAPI или что-нибудь определил.

Это к вопросу о том, что Си ну вот нисколечко ещё не протух на сегодняшнее время. И дизайн в нём прекрасный, и всё прозрачно.

При чём тут дизайн в C, и что непрозрачно?

P.S. Вообще-то работает и без этого

Естественно, типы возможно аллокируют одинаковое количество байт (или даже используют один-и тот-же базовый тип) на платформе под которую вы компилитесь. Как и сказал, отключите strict type checking, если ваш код не предполагает быть portable.

[Sergey]

Олег, как переделать sdcc-шные либы под ZXDev? Сразу говорю, пример на твоём сайте я не понял.

[Oleg N. Cher]

Sergey, если для Вас это ещё актуально, дайте знать. Я просто свернул это направление как неприоритетное.

Что конкретно непонятно? Там всё очень чётко расписано. Если я и собирался что-то добавить, то только как проецировать сишные типы на обероновские.

[Oleg N. Cher]

P.S.

• Резон появления и смысл среды XDev
  
• ZXDev + TR-DOS
  
• Компактная вещественная арифметика для Спектрума
  
• Демо-версия рогалика для ZX на Обероне. С критикой, пожалуйста, не ко мне. Неинтересно.
  
• Прогресс разработки порта игры “Dark Woods”

[Oleg N. Cher]

Портировал с Turbo Pascal на Оберон для ZX Spectrum простенькую консольную игру «Кости».

https://github.com/Oleg-N-Cher/Dice

[Advertiser]

[Oleg N. Cher]

Попутно ещё хочу рассказать г-ну introspec'у, что в его родном Лондоне функционирует фирма Padded Cell Software Ltd, PO Box 1880, London NW6 1BQ, United Kingdom, которая активно использует язык Оберон для разработки программного обеспечения повышенной надёжности для своих клиентов, среди которых — государственные организации Англии. Об этом говорит Пол Рид в своих статьях Building Your Own Tools - An Oberon Industrial Case-Study и An Oberon Linker for an Imperfect World – More Notes on Building Your Own Tools

Эти статьи не являются публично доступными, видимо, таковы соглашения с издательством. Но я получил от Пола разрешение цитировать их частично, поэтому вот:

Summary: Our experience creating custom application software has taught us that total control over our development tools is a necessity. Project Oberon provided an excellent starting point for us to build our own cross-platform application programming environment. Our adaptation of Wirth's compiler is re-targetable at run-time via a small set of installable up-calls, enabling a single machine-specific code-generation module of typically less than a thousand lines of code. The only significant additions to the original Oberon language are floating-point binary-coded decimals and open-array variables with string concatenation (e.g. s := "Error: " + t). Accompanying run-time libraries, written in Oberon, for operating systems such as Microsoft Windows (32-bit) and MS-DOS have been developed. Several systems created using the new tools have been in use by customers for some time.

1. Introduction

We present an industrial application of Niklaus Wirth's and Jiirg Gutknecht's research project [1], the programming language [2] and operating system Oberon, which aims to retain the original's simplicity, clarity and reliability. First the motivation for developing the software is explained, and the occasionally roundabout route which led to it is described in some detail. The particular design aspects of our version of the Oberon compiler and its target run-time environment are summarised, and finally we outline the steps involved in writing a new code generator for a given machine. In publishing these experiences, we hope that others may be encouraged to take Wirth's blunt attitude to 'bells and whistles', and enjoy reliable software as a natural result.

2. Motivation

Providing working software for real customers is in most cases hard work, yet despite warnings [3] the complexity involved continues to be underestimated by the industry's practitioners. Many large, high-profile software projects fail completely - and 'small' software is often unreliable. Critics often contrast this with civil engineering, where (on the whole) bridges do not tend to collapse during construction. Considering that in software we have far more control over the properties of our tools and materials than in other branches of engineering, the phenomenon is all the more surprising.

We reject the argument that computing is still in its infancy and therefore that such failures are only to be expected - consider aviation, where through great effort and the will to create a safety culture, passenger flights were made acceptably safe by the 1930's and fatality rates were improved again by an order of magnitude by the late 1950's.

In our experience, the biggest obstacle to providing finished software is finding the time to write it. Analysing our past projects, which used the complex development tools available commercially, it dawned on us that a frightening proportion of intellectual effort and time was being wasted on installation, configuration and debugging of these tools - we estimated in one extreme case as much as eighty percent of the entire project time.

We feel that it is partly because software offers the freedom to design ridiculously over-featured compilers and other development tools (most of which are far from bug-free) that the complexity of projects can get out of hand. Wrestling with the unpredictable properties of a fault-ridden programmer's tool may be stimulating, but it is distracting, and leaves less of our mental capacity available to solve the problems in the customers' domain.

Creating simple, single-purpose tools is unfashionable because it restricts scope and flexibility; but this can sometimes actually be beneficial, reducing the sheer number of decisions to be made along the way. An example of this is the software running the tiny computer fitted to the Voyager 2 space probe, whose outstandingly successful mission inspired Wirth to begin the original Oberon project [1].

The concept of providing just enough is expounded repeatedly in Project Oberon. But what makes it unique is the presentation of the entire source code of the operating system and compiler, and extremely lucid descriptions of their design and construction, all in a single compact volume. Many excellent expositions of compiler design and compiler-writing toolkits exist, for example [4], [5]; but the emphasis is often on a general approach. Attention in the literature tends to be focused on writing a 'front-end', where statements formulated in the source language are parsed, whereas actual code-generation (the 'back end') is sometimes even left as an exercise to the reader.

Knowing that we could fall back on the source code and explanations in the book, at the beginning of 1997 we decided to start a project to build some new in-house development tools based around the hand-crafted, single-pass, recursive-descent Oberon compiler designed by Wirth.

3. Objectives

The goal of our project was a simple, portable application programming environment gained in a reasonably short time scale.

Simplicity was essential in order to ensure a complete understanding of the tool on which we were totally reliant. This avoids being in the position, when developing software systems for customers, of blaming tools like bad workmen. There is also usually a need to maintain and adapt software long after it has been created, and our compiler tool would not be exempt from this.

Several different machines and operating systems, including at least Microsoft Windows (32-bit) and Apple Macintosh, would need to be supported. So the compiler would need to be portable, generating code for more than one processor chip (at least Intel 80386 and Motorola 68000 respectively).

The third requirement was that the programming of the tools should not be an undue distraction - either during their construction or afterwards. We had no intention of becoming a development tools company, spending large amounts of time on the maintenance of our compiler for each machine platform - we wished actually to use the tools.

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

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

Или г-н introspec считает: что хорошо и весьма актуально для структур государственного значения в Англии и Швейцарии, плохо для русских спектрумистов? Так тогда это вообще диверсия против русских.

P.S. Никто не пробовал работать с Mira Modula-2? А то я смотрю, тут библиотеки есть. Можно на ZXDev портировать.

[Reobne]

Спасибо, интересно.

Мой вариант "С чего начать":

Скрытый текст

1.

Скачать: https://github.com/Oleg-N-Cher/XDev/zipball/master

2. Распаковать.
3. Запустить BlackBox.exe
4. Открыть в нём TourRu.odc
5. Изучать.
6. Почитать файл ZXDev\Docu\ZXDevRus.txt
7. Позапускать примеры из папки ZXDev\Mod\
8. Почитать ZXDev\Docu\obe_faq2.htm

[свернуть]

Моё "ЧаВо":

Скрытый текст

1. Файлы примеров бывают *.Mod и *.Odc. В чём их различия?
odc - это сложный документ, может быть с картинками или с гиперссылками и т.д. Mod - простой текст.

2. При нажатии F11 возникла ошибка "command error: object OfrontOPM.MaxStruct inconsistently imported from OfrontOPC" Что это?
Такое может случится от внутреннего несоответствия модулей подсистемы Ofront, (они рассинхронизировались).
Чтобы исправить откройте XDev/Ofront/Docu/Rebuild-Ofront.odc (двойным щелчком по имени этого файла или через File -> Open) и кликните по чёрному кругляшику (коммандеру) для пересборки подсистемы.

3. Когда я выделяю в тексте название модуля, давлю правой кнопкой мыши, выбираю "Interface", то ничего не происходит
Дело в том, что эта возможность предусмотрена только для модулей, собранных самим BlackBox Component Builder, его подсистемой Dev, которая компилирует модули в 32-битный код процессора 80x86.
Разработка же для Спектрума ведётся с помощью другой схемы. И, соответственно, посмотреть интерфейс можно, выделив в тексте название модуля и выбрав из меню XDev -> Show Definition. Притом в меню Ofront тоже есть пункт "Show Definition", но он не всегда будет корректно срабатывать, и я планирую убрать его.

ЧаВо по Оберону от "Информатика21"
ЧаВо по Оберону от oberoncore.ru

[свернуть]

[Oleg N. Cher]

Что ж, TourRu.odc это конечно интересное чтиво, но, пожалуй, оно имеет не так много отношения к Спектруму. Хотя как сказать.

Спасибо за Ваш пост! Очень важно видеть живой отклик.

[introspec]

Попутно ещё хочу рассказать г-ну introspec'у, что в его родном Лондоне функционирует фирма Padded Cell Software Ltd, PO Box 1880, London NW6 1BQ, United Kingdom, которая активно использует язык Оберон для разработки программного обеспечения повышенной надёжности для своих клиентов, среди которых — государственные организации Англии.

Клиентов, как я посмотрю, настолько много, что у фирмы нет даже денег на собственный офис. PO Box 1880 - это примерно как почтовый ящик до востребования.

Спасибо, посмеялся.