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

Oleg N. Cher

17.03.2012, 13:53

Я с Вами согласен, Barmaley_m. Просто советовал проверить и убедиться, как оно есть на самом деле. Конечно я завёл в Дураке тип Index (для индексации массивов) и старался использовать переменные этого типа везде, где подразумевается индекс массива. И что ж думаете. Когда Index был CARDINAL (2 байта без знака), код был на полкилобайта БОЛЬШЕ, чем когда он стал SHORTCARD (1 байт без знака), главное чтобы хватило разрядности индекса. Где массив <=256 байт, там это хорошо подходит. Вот вам пример кодовой оптимизации. Поэтому я призываю не писать SHORTINT где это явно указывает на что-то такое, чего можно обозвать другим словом (например, Coords, Mode или Color). Последнее: a) нагляднее; b) лучше поддаётся изучению "а что будет если я изменю этот тип на N? Как поведёт себя код и какой будет выйгрыш".

Генератор кода ругать тоже не спешите, он там при передаче однобайтовых параметров даже лишний байт на стеке экономит. И спаривает параметры в регистровую пару, если таких параметра два. Я просто такты не считал. Думаете сам всё сделаешь? Руки ж блин до всего не доходят. Так что элементарно надо взять и проверить.

---------- Post added at 11:53 ---------- Previous post was at 11:38 ----------

Zorki-4k, исправил обозначенные Вами проблемы с HelloWorld и неверное определение типов в Basic. Добавил символьные файлы Basic и Laser, чтобы можно было смотреть интерфейсы по Ctrl+D (http://zx.pk.ru/showthread.php?t=18489).

- Add sym files for ZXDev/Basic and ZXDev/Laser.
- Fix type declaration bugs in ZXDev/Basic.
- Add to ZXDev/HelloWorld 'B.FLASH(B.Off)', 'B.WaitAKey', 'PRWORD -> PRCARD', 'Coords -> Coords/TextCoords'

Если не владеете контролем версий, примеряйтесь. Чтобы всё заново не перекачивать, а только исправленные моменты.

Типы – это самое слабое место в кроссплатформенности Оберон-программ, потому что на практике с типом связывают определённую разрядность. Уверенно советую пользоваться обёртками для типов. Оверхед нулевой. Наглядность повышается. А если вынести обёртки в другой модуль (скажем, Settings), то появляется возможность абстрагироваться в своих модулях от платформы, подставляя на другой платформе другую реализацию модуля Settings (с указанной другой разрядностью типов, более подходящих для другой платформы). Поэтому нас интересует минимальная разрядность (или диапазон значений), которой будет достаточно для реализации назначения данного типа, а прирост разрядности на других более мощных платформах будет им только на пользу, потому что, например, для Win32/Linux32 – 8 и 16-битная арифметика не имеет никаких преимуществ ни в скорости работы, ни в компактности кода. А ещё на мощных RISC-процессорах и платформах использование беззнаковых типов вцелом никак не более эффективно, чем знаковых. Вцелом. Придраться к моему высказыванию можно, но не нужно. :biggrin: А вот реальное смешивание знаковых и беззнаковых типов – часто излишний груз для компилятора и бедных мозгов программиста. Часто просто хочется указать, что это число (INTEGER), и поехали.

Превратил PRWORD в PRCARD (вывести беззнаковое число). Развёл типы Coords и TextCoords, для наглядности, что это не одни и те же сущности. Coords задаётся в пикселях, TextCoords в знакоместах.

Eltaron

17.03.2012, 14:38

хм, а я точно помню, что не только через стек
в функцию, у которой только один параметр, и он однобайтовый, sdcc передаст значение через аккумулятор

Oleg N. Cher

17.03.2012, 15:00

Eltaron, что-то в этом я сильно сомневаюсь. Но предлагаю Вам проверить, и если это и правда так, то предлагаю Вам заняться оптимизацией библиотеки Basic. Сделайте что-то мелкое, но хорошее, все скажут только спасибо.

Eltaron

17.03.2012, 15:18

Eltaron, что-то в этом я сильно сомневаюсь. Но предлагаю Вам проверить, и если это и правда так, то
Так проверял. Было б это не так, этот пример бы не работал - http://zx.pk.ru/showpost.php?p=471807&postcount=7
Но это касается только единичного 8битного параметра. Во всех других случаях sdcc передает через стек.

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

У меня более глобальные планы :)

Oleg N. Cher

17.03.2012, 18:03

Так проверял. Было б это не так, этот пример бы не работал

Смотрите, Eltaron:

;HelloWorld.c:15: Basic_BORDER(4);
ld a,#0x04
push af
inc sp
call _BORDER
inc sp
;HelloWorld.c:16: Basic_PAPER(0);
ld a,#0x00
push af
inc sp
call _PAPER
inc sp

Если бы всё было так, как Вы утверждаете, то SDCC сгенерировал бы что-то вроде:

;HelloWorld.c:15: Basic_BORDER(4);
ld a,#0x04
call _BORDER
;HelloWorld.c:16: Basic_PAPER(0);
ld a,#0x00
call _PAPER

Вот если бы Вы сказали, что есть ключик, который включает безстековую передачу однобайтового параметра, с убиранием кода, генерирующего фрейм [push af : inc sp : call ... : inc sp], тогда другое дело, и Ваше утверждение было бы 100% корректно и имело бы больше смысла и пользы для нас. А Вы призываете пользоваться тем фактом, что параметр попадает в стек именно через регистр A. Это наведённый эффект, и если способ передачи параметров в SDCC изменят (а кодогенерация SDCC активно дорабатывается), например, начнут передавать через другой регистр, то у Вас всё перестанет работать. Я-то могу конечно убрать внутри процедур BORDER, PAPER и др. доставание параметров из фрейма в аккумулятор, но это такая мелочь, на которой много не выиграешь. А вот проблемы в будущем возникнуть могут. Предпочитаю кулхацкерству надёжное программирование. Хотя могу добавить включаемую ифдефом опцию, которая будет “оптимизировать” такие процедуры. Но она будет по умолчанию отключена.

P.S. Настоящий прогресс у нас начнётся, когда кто-то из команды, занимающейся кодогенерацией SDCC, действительно добавит такой ключик. А заодно и превратит “ld a,#0x00” в “xor a” (или “sub a”) – (там, где это даст выигрыш). Или найдётся человек, который пропихнёт такие предложения Филиппу Краузе. Дело за малым. Не сидеть и мечтать об идеальном кодогенераторе, а что-нибудь для этого сделать, хотя бы маленький шаг.

alone

17.03.2012, 21:35

Реквестирую одной кнопкой компиляцию + сборку + запуск эмуля с автозапуском проги.

Oleg N. Cher

17.03.2012, 23:28

Сделаю.

Eltaron

18.03.2012, 01:18

...
Упс. Да, это хак, согласен

превратит “ld a,#0x00” в “xor a” (или “sub a”) – (там, где это даст выигрыш). Или найдётся человек, который пропихнёт такие предложения Филиппу Краузе.
а это очень просто, кстати
подобная замена одного кода на другой легко выполняется через sdcc-шный механизм peep hole optimization. Суть его в том, что после основной компиляции запускается поточный текстовый редактор, заменяющий одни конструкции на другие
надо лишь добавить правило

replace restart {
ld a, #0x00
} by {
xor a
}

ЗЫ Запостил Филлипу патч, авось примет

Barmaley_m

18.03.2012, 12:16

Только что пощупал SDCC на предмет качества генерации кода. Результат, мягко говоря, не впечатлил. Поэтому, если генератор кода не использует XOR A вместо LD A,0 - то это самая малая из его проблем. Основное падение быстродействия программ будет происходить не из-за этого. Так что, думаю, не стоит заморачиваться с этой отдельно взятой оптимизацией. Снявши голову, по волосам не плачут, как говорится.

Впрочем, генерируется рабочий код Z80 - это тоже результат! Для быстрого написания программ такой компилятор вполне годится. Помнится, я пользовался турбо паскалем под CP/M для некоторых нужд. Результат вполне устраивал, я даже при этом не рассматривал, какой генерируется код. Работает, в память влезает - и хорошо, что не пришлось писать его на ассемблере.

newart

18.03.2012, 14:46

Результат, мягко говоря, не впечатлил.
Можно поподробнее? А то разговоров на эту тему много, а примеры встретишь редко.

Barmaley_m

18.03.2012, 15:40

Можно поподробнее? А то разговоров на эту тему много, а примеры встретишь редко.
Ну вот например, шлю тестовую программу на си и результат ее компиляции в асм. Программа состоит из двух простых функций: gcd для поиска наибольшего общего делителя; и recupow для возведения в степень с помощью рекурсии (хотел посмотреть, как компилируется рекурсия).

Замечания следующие:
1) Генерируется код для инициализации глобальных переменных (строки 47-65 асм-файла). Вместо этого можно было бы иметь сегмент инициализированных данных, эта концепция поддерживается многими компоновщиками.

2) Код инициализации данных чрезвычайно неэффективный:
LD IY, adr
LD (IY),data

3) Для сравнения двух однобайтовых переменных (строки 84-87 асм-файла) используется команда SUB, а не CP. В результате портится значение аккумулятора, которое далее по тексту программы приходится восстанавливать.

4) Весь цикл функции gcd (строки 84-104 асм-файла) реализован без использования регистров для локальных переменных, все данные сохраняются в памяти посредством индексной адресации. Мне удалось разместить переменные на регистрах только если объявить их локальными, скопировать в них значения аргументов функции, а в цикле работать с локальными переменными. Что ж - спасибо и на этом, хотя с семантической точки зрения разницы быть не должно, и оптимизатор, в идеале, должен генерировать одинаковый код в обоих случаях.

5) Для функции recupow, сравнение одного и того же числа с разными значениями, строки 121, 129 асм-файла. Во-первых, выполнение OR A не портит значение аккумулятора, поэтому восстанавливается он без необходимости. Во-вторых, сравнение с единицей командой SUB 1. Почему не CP? Почему не DEC? Тем более что далее по тексту программы значение аккумулятора снова восстанавливается из памяти (строка 136) и снова уменьшается на единицу, на этот раз командой DEC.

Засылка однобайтового числа на стек обычно выполняется командами PUSH AF / INC SP. Этим экономится 1 байт на стеке за счет потери тактов на команду INC SP и, возможно, DEC SP при удалении со стека аргументов после возврата функции, если их число было нечетным.

Однако в строках 138-140 асм-файла аргумент засылается на стек почему-то посредством LD D,A / PUSH DE / INC SP. Я не нашел этому разумного объяснения.

Путем некоторых шаманских действий с программами - таких как перемена местами операндов при сравнении на неравенство (!) - мне удавалось иногда повысить эффективность генерируемого кода. Но если писать на Си или другом языке высокого уровня, изначально учитывая особенности оптимизатора - то проще уж сразу на ассемблере писать программы.

Barmaley_m

18.03.2012, 15:43

Добавлю, что в приведенном примере код был сгенерирован еще относительно оптимально. Но это только потому, что я везде использовал тип данных байт (unsigned char). Изначально я применил просто char (знаковый), так тогда компилятор нагенерировал кучу проверок флага знакового переполнения (JP PO) при простых операциях с такими числами, таких как сравнение на равенство/неравенство. Я даже не берусь предполагать, какой код получится при работе с 16-битными знаковыми числами. Хоть стреляйся, наверно. Хотя беззнаковые 16-битные должны обрабатываться неплохо.

Barmaley_m

18.03.2012, 16:07

Вот еще один пример - подпрограмма быстрого возведения в степень. С ней нареканий совсем немного. Честно говоря, результат компиляции меня даже приятно порадовал. Потому что трудно ожидать, что компилятор мог бы улучшить этот результат хоть сколько-нибудь существенно. Ну так, по мелочи: строки 95-97, пользуется серией команд LD A,(IX+6) / SRL A / LD (IX+6),A и при этом в дальнейшем не использует значение аккумулятора, вместо того, чтобы сделать операцию одной командой SRL (IX+6). При этом команду DEC (IX+6) генератор кода знает. Создается впечатление, что это просто недоработка, может быть авторы не учли наличие у Z80 команд сдвига памяти по IX.

Еще в строках 64-66 проверяется младший бит по адресу IX. Компилятор сгенерировал LD A,(IX+6) / AND 1 / JR Z, хотя то же самое можно было бы сделать через BIT 0,(IX+6) / JR Z.

Поэтому оптимизация XOR A вместо LD A,0 - это капля в море.

Но в целом не поймите неправильно. Код довольно неплохой получается. Даже то, что использована команда DEC (IX+6) - это тоже очень хорошо. Могло ведь быть и хуже: LD A,(IX+6) / SUB 1 / LD (IX+6),A.

Также порадовала в строках 58-62 реализация сравнения с нулем на неравенство посредством OR A (фактически - сравнение на равенство). То есть оптимизатор разобрался, что для беззнакового числа сравнение с нулем на равенство и неравенство - это одно и то же.

Eltaron

18.03.2012, 18:00

Замечания следующие:
1) Генерируется код для инициализации глобальных переменных (строки 47-65 асм-файла). Вместо этого можно было бы иметь сегмент инициализированных данных, эта концепция поддерживается многими компоновщиками.
Хак - объявить глобальные переменные как const и обращаться к ним через указатель. Тогда они разместятся в кодовом сегменте. Но вообще да, то, что сегмент .data на самом деле функционирует как .bss очень бесит.

---------- Post added at 18:57 ---------- Previous post was at 18:55 ----------

Поэтому оптимизация XOR A вместо LD A,0 - это капля в море.
Мой патч для этого, кстати, не приняли. Аргумент разумный - XOR портит флаги, а LD нет. И поэтому в лоб заменить все ld a,0 на xor a нельзя, надо заменять выборочно.

---------- Post added at 20:00 ---------- Previous post was at 19:52 ----------

Ну так, по мелочи: строки 95-97, пользуется серией команд LD A,(IX+6) / SRL A / LD (IX+6),A и при этом в дальнейшем не использует значение аккумулятора, вместо того, чтобы сделать операцию одной командой SRL (IX+6).
версия sdcc из транка svn это уже умеет

;fastpow.c:16: b >>= 1;
srl 6 (ix)
jr 00104$

а еще оно теперь вместо

;fastpow.c:8: if(b&1)
ld a,6 (ix)
and a, #0x01

генерит

;fastpow.c:8: if(b&1)
bit 0, 6 (ix)

Oleg N. Cher

19.03.2012, 23:01

ЗЫ Запостил Филлипу патч, авось примет
Благодарю Вас.

Видите, Eltaron, я так осторожненько добавил после “превратит “ld a,#0x00” в “xor a” (или “sub a”) ”:

(там, где это даст выигрыш).

Я могу представить себе ситуацию, где SDCC надеется, сгенерировав “ld a,#0x00”, на неизменность флагов, а такой пипхол опять грозит нам головной болью. Нет, тут надо всё фундаментально делать, а не по-хацкерски, согласны?

Вы запостите Филиппу не идею пипхольной замены, а пусть он научит SDCC генерировать “xor a” там, где не нужно сберегать значение флагов. А заодно пусть и правда подумает о передаче единственного однобайтового параметра через аккумулятор. Идея отличная.

Я тем временем напишу Йозефу Темплу просьбу разрешить мне править код Ofront'а. Беззнаковые типы (байт, слово, двойное слово) - это то, что на очереди к реализации практически в самом начале списка. Сам понимаю, насколько эффективно юзать эти типы на Z80.

Господа, я медленно подвожу вас к тому, чтобы при программировании на Обероне выносить зависимые от платформы вещи в отдельный модуль-конфигуратор Settings. В дальнейшем можно будет даже разработать графический редактор свойств такого модуля (например, похожий на редактор свойств компонентов в Дельфи). Насколько проще, приятнее и нагляднее станет конфигурировать тонкости работы программ. Любой школьник младших классов сможет выбрать из менюшек доступные из свойств и, быстро пересобрав программу, посмотреть, что изменилось. Сравните это с суровым “configure; make; make install”.

Вот ещё одна наша маленькая победа на Оберон-нивах: ссылка на мои Оберон-биндинги к кроссплатформенной библиотеке SDL добавилась на оф.сайт SDL - http://www.libsdl.org/languages.php. Sam Lantinga похвалил качественно проделанную работу, так что я всех нас с этим поздравляю. Это хороший шаг к появлению кроссплатформенного эмулятора Спектрума на Обероне.

После некоторых размышлений я соглашаюсь с модераторами данного форума в том, что использование Оберон-технологий и среды XDev выходит далеко за рамки тем данного форума по ZX, поэтому подумываю о форуме для поддержки нашей среды разработки. А если среди нас соберётся ядро хотя бы 2-3 человека, которые будут активно дорабатывать ZXDev, пропихивать идеи кодогенерации в SDCC-сообщество, взаимодействовать на форумах с заинтересованными людьми на предмет изучения высказываемых идей и предложений, то в итоге выиграют все. Все, кто ещё программируют для Спектрума.

newart

19.03.2012, 23:24

что сегмент .data на самом деле функционирует как .bss очень бесит.
Что это значит?

Изначально я применил просто char (знаковый), так тогда компилятор нагенерировал кучу проверок флага знакового переполнения (JP PO) при простых операциях с такими числами, таких как сравнение на равенство/неравенство.
А как бы ты сделал?

bigral

19.03.2012, 23:35

Что это значит?

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

А как бы ты сделал?

Использование знаковых типов вместо беззнаковых тупо, ясное дело что для координат speccy экрана нужно использовать unsigned char.

Barmaley_m

20.03.2012, 01:08

А как бы ты сделал?
А ведь и в самом деле, вариантов особо и нет. Сравнение двух чисел со знаком на больше/меньше - задача, которая не имеет эффективного решения на Z80. Если беззнаковые числа можно сравнивать командой CP и потом проверять флаг C - то для знаковых чисел таких простых решений нет. Нужно выполнять как минимум две проверки.

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

Любопытно, как SDCC работает с дробными числами. Применяется ли там некое подобие ПЗУшного псевдокода "калькулятора" или какой-то другой подход, наподобие прямого вызова подпрограмм работы с дробными числами? Надо будет глянуть.

Насчет модификации компилятора с целью передачи единственного аргумента функции в аккумуляторе - это полумера. Если уж делать - то полноценную передачу аргументов функций в регистрах (fastcall).

Oleg N. Cher

20.03.2012, 14:07

Насчет модификации компилятора с целью передачи единственного аргумента функции в аккумуляторе - это полумера. Если уж делать - то полноценную передачу аргументов функций в регистрах (fastcall).
Да, согласен, но надо с чего-то начинать. Пусть первый шаг будет полумерой, это всё ж лучше, чем просто мечатать о fastcall. Вот в самом BlackBox реализовано нечто среднее между стековой и регистровой передачей параметров, вещь любопытная: один параметр процедуры передаётся в регистре всегда. Остальные в стеке. Это очень даже хорошо. Намного проще, чем fastcall, но намного эффективнее, чем если все в стеке. Надо искать разумные компромиссы, которые можно реализовать быстро. Девелопинг штука чрезвычайно гибкая, и можно превратить начатое нечто в законченное абсолютно что угодно, поэтому меня даже удивляет, почему многие разработчики так любят делать всё с нуля, игнорируя готовые здравые наработки, которые дают очень неплохой старт.

Oleg N. Cher

21.03.2012, 12:33

Запускаю BlackBox.exe раскапованный в папку c:\Oleg-N-Cher-BB-XDev-e216b8d. Он показывает главное окно с меню и выводит MessageBox с ошибкой.

Сегодня получил ответ на баг-репорт от Oberon Microsystems:

From: Blackbox Support Oberon microsystems AG
Subj: Re: [BLACKBOX] Bug report (keyboard interrupt just after starting BlackBox)

Thank you very much, Oleg.

Even though I run BlackBox 1.6-rc6 on 32-bit Windows XP every day, I never encountered this problem before. Do you have any additinal hints fow what the cause could be? Maybe the Intel Q9950 processor?

Thanks again and kind regards,
Marc

Я ответил так:

Dear Marc,
I don't have any hints or ideas.
I and other people in this mail list have started BB
on thousands of different machines, and have no problems.
It's a wonder, probably it's really some particularities of the CPU.

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

Oleg N. Cher

21.03.2012, 19:35

Вот ещё от пользователя Romiras:

Set of possible reasons that can affect:

* Implementation of BlackBox (Std, Host, Kernel) or its configuration. First, try previous versions: 1.5, 1.6 RC5
* Software environment: modified distribution of Windows, specific drivers, specific system configuration or even key-logger (who knows?).
* Hardware: bad keyboard (some key pressed down all the time), CPU (instructions in DevCP*486)
Кстати, vinxru, а в самом деле попробуйте BlackBox 1.5 (с оф.сайта). Скопируйте в установленный ББ папки ZXDev, Nav и Ofront.

Возможно, Ofront понадобится пересобрать: /Ofront/docu/Rebuild-Ofront.odc

Oleg N. Cher

31.05.2012, 15:30

Свежие новости по проекту.

Получил разрешение от Йозефа Темпла на распространение в составе XDev/ZXDev модифицированного транслятора Ofront. Более того, Йозеф перевёл его под более либеральную лицензию BSD. Теперь Ofront можно совершенно свободно использовать в любых целях, а также дорабатывать.

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

Разобрался таки с селекторами (аналог #ifdef, хотя и не буквальный), изумительная штуковина. Прямого аналога нет ни в одной из известных мне IDE. В стандартных фирменных сборках ББ работа с селекторами в меню не выведена, поэтому возможность остаётся всё-таки скрытой. Вывел в меню Dev->Paste Left View/Paste Middle View/Paste Right View. Подробнее о работе с селекторами можно прочесть в статье Евгения Темиргалеева “DevSelectors — переключатели вариантов в исходном коде (http://oberoncore.ru/wiki/blackbox/devselectors)”.

Если нужна более традиционная реализация макросов, остаётся возможность использовать компонент CpcPreprocessor (http://zinnamturm.eu/downloadsAC.htm#CpcPreprocessor), который легко встраивается в ББ. С ним я не экспериментировал, как-то особо не было нужды. Не знаю что он умеет. Но полагаю, на его основе можно наваять всё что может понадобиться.

Планирую пропиарить ZXDev на форуме World of Spectrum.

Так что основные проблемы ZXDev в качестве практического инструмента для ZX-разработки считаю решёнными.

Написал ли кто-нибудь хоть что-то маленькое на Обероне для ZX?

Oleg N. Cher

15.09.2012, 00:16

Найдено решение ещё одной проблемы ZXDev. Теперь возможно получение очень маленьких программ, куда из библиотек линкуются только лишь необходимые функции. Для облегчения разбивки исходных сишных текстов на "модули" (в терминологии SDCC), а на деле просто на фрагменты с отдельными функциями, я написал утилиту ZXDev/Bin/smartlinkrel, облегчающую подготовку библиотек. Она автоматически делит сишный исходник на несколько (по отдельным функциям или как-либо ещё). Заголовок и "линии отреза" задаются с помощью специального вида комментариев.

Модуль, демонстрирующий принцип работы "умной" линковки:

MODULE TinyHello; IMPORT Basic; BEGIN Basic.PRSTR("Hello World") END TinyHello.Целевой бинарник этой программы занимает всего лишь 45 байт! Для программы на языке высокого уровня это вполне близко к идеалу. А можно ли меньше? Да, возможность сделать TinyHello ещё меньше появится когда Филипп Краузе реализует передачу параметров в регистрах.

Подробнее читайте на форуме поддержки ZXDev в теме "Умная" линковка (smart linking) в ZXDev/SDCC (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=34).

Теперь, когда найден способ смартлинковать сущности из библиотек, среда ZXDev стала ещё привлекательнее в качестве высокоуровневого клея между ассемблерными подпрограммами и исходниками на ЯВУ, в качестве средства для накопления и наработки библиотек. Трёхуровневая система разработки, в которой умелый программист может извлечь пользу из любого уровня (низкий-асм, средний-Си и высокий-Оберон), — идеальный на данный момент структурно-модульный клей между всеми тремя уровнями (без оверхеда на каждом из них). Поэтому утверждаю, что ZXDev — это не "игрушечная" среда. Это серьёзный инструмент, предназначенный как для начинающих, так и для профессионалов, позволяющий выполнить разработку практически любого софта. И в то же время идеологически он выполнен в духе SDCC, которому не чужды промежуточные уровни представления кода.

SfS

15.09.2012, 15:53

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

Это обходится. Немного коряво, но приемлемо.

Определяешь структуру как const что-то, а в *.h файле объявляешь её же без const. Например:

файл vars.c

const int a=0x3456;

файл vars.h

external int a;

Отдельно компилишь vars.c в объектники и всё путём...

КРиво, я знаю. не пинайся.

Oleg N. Cher

29.11.2012, 20:07

Проект ZXDev анонсирован на World of Spectrum ( http://www.worldofspectrum.org/forums/showthread.php?t=41120). Приём получился гораздо теплее, чем здесь. Raydac оказался прав.

Исправлен глюк со сбросом примера на Laser Basic. Проблема будет интересна всем, кто юзает SDCC. Это даже не глюк, допущенный случайно. Дело в том, что я после извлечения параметров функций допускал изменение регистра IX. А делать оказывается этого нельзя, ибо SDCC иногда полагается на его значение после возвращения из функции. (Как написал Филипп: “IX is a calle-saves register”).

Благодаря помощи Филиппа Краузе и Eltaron’а реализована экспериментальная поддержка модели вызова fastacall (передача параметров в регистрах). Из-за отсутствия (пока) в SDCC поддержки fastcall присутствует серьёзное ограничение: параметры должны быть только константами, вычислямыми в процессе компиляции. Фишка по умолчанию отключена. Включить можно в Libs/BasicCfg.h

С использованием модели fastcall получается такой код:

B.BORDER(B.Black); B.PAPER(B.Green); B.CLS;

;HelloWorld.c:15: Basic_BORDER(0);
xor a,a
call 0x229B
;HelloWorld.c:16: Basic_PAPER(4);
ld c,#4
call _Basic_PAPER_fastcall
;HelloWorld.c:17: Basic_CLS();
call _Basic_CLS

Реорганизовал структуру ZXDev и, как по мне, стало логичнее и удобнее.

Начата работа над многофункциональной утилитой для конвертирования BIN/IHX в форматы TAP/TRD (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=37) (возможно, будет поддержан и TZX). Пишу на Обероне с прицелом на трансляцию через Ofront в Си. Принимается любая помощь, в т.ч. идеи.

Alex Rider

29.11.2012, 22:39

Могу поделиться Delphi-исходниками своей TapTool (http://zx.pk.ru/showthread.php?t=19326) на Delphi.

Error404

29.11.2012, 22:51

Благодаря помощи Филиппа Краузе и Eltaron’а реализована экспериментальная поддержка модели вызова fastacall (передача параметров в регистрах). Из-за отсутствия (пока) в SDCC поддержки fastcall присутствует серьёзное ограничение: параметры должны быть только константами, вычислямыми в процессе компиляции. Фишка по умолчанию отключена. Включить можно в Libs/BasicCfg.h

С использованием модели fastcall получается такой код:

B.BORDER(B.Black); B.PAPER(B.Green); B.CLS;

;HelloWorld.c:15: Basic_BORDER(0);
xor a,a
call 0x229B
;HelloWorld.c:16: Basic_PAPER(4);
ld c,#4
call _Basic_PAPER_fastcall
;HelloWorld.c:17: Basic_CLS();
call _Basic_CLS

В примере две функции, обе с одним параметром: Basic_BORDER, Basic_PAPER. Почему для первой генерится передача параметра в регистре А, а для второй функции - в регистре С? Это такой странный выход транслятора или просто пример "с листа"?

Oleg N. Cher

29.11.2012, 23:38

Это, разумеется, сделано для эффективности и компактности машинного кода. Если знаете Си, то вот как именно это реализовано:

#define __hash__ #
#define __id__(x) x
#define __ld_a__(x) if(x==0) {__asm xor a,a __endasm;}else{__asm ld a,__id__(__hash__)x __endasm;}
#define __ld_c__(x) __asm ld c,__id__(__hash__)x __endasm

import void Basic_BORDER_stdcall (SHORTINT color);
#ifndef BORDER_fastcall
#define Basic_BORDER Basic_BORDER_stdcall
#else //BORDER_fastcall
#define Basic_BORDER(color) __ld_a__(color); \
__asm \
call 0x229B \
__endasm;
#endif

import void Basic_PAPER_stdcall (SHORTINT color);
import void Basic_PAPER_fastcall (void /* Register C */);
#ifndef PAPER_fastcall
#define Basic_PAPER Basic_PAPER_stdcall
#else //PAPER_fastcall
#define Basic_PAPER(color) __ld_c__(color); Basic_PAPER_fastcall()
#endif

Sergey

15.01.2013, 21:04

Oleg N. Cher

24.01.2013, 20:20

Приветствую, Олег!
Интеллекта не хватает, твою систему освоить. Поэтому пока балуюсь только гольным sdcc.
Не подскажешь ли, как мне 1) crt0.rel свой сделать, 2) как на выходе бинарные файлы получать вместо ihx?

Та ладно, Сергей, не прибедняйтесь. ;) Не так там уж сложно всё. Впрочем, готов поотвечать на вопросы в аське, ирц, жаббере или на форуме ZX.Oberon2.Ru/Forum (http://zx.oberon2.ru/forum/), милости прошу, пишите ЛС, если есть охота.

crt0.rel я никогда не делал, даже не баловался. Если честно, я даже не знаю зачем оно надо. ;) Тут нам вместе надо обратиться к гуру SDCC.

Перегнать IHX в BIN можно несколькими способами. ZXDev использует утилиту Hex2bin, скачивается отсюда: http://sourceforge.net/projects/hex2bin. Есть планы сделать утилиту, напрямую конвертирующую IHX в TAP/TZX/TRD (с добавкой произвольного загрузчика). Первая версия уже почти-почти готова (но пока умеет только BIN в TAP, без IHX).

Eltaron

24.01.2013, 20:31

как мне 1) crt0.rel свой сделать, 2) как на выходе бинарные файлы получать вместо ihx?
http://zx.pk.ru/showpost.php?p=539849&postcount=36

Oleg N. Cher

24.02.2013, 07:59

По реквесту AlCo сделал возможность автосборки и запуска Оберон-программ для Спека нажатием F12 (можно переделать на любую другую комбинацию или отдельную клавишу). Сделано несложно, а именно: для модуля Module.odc (или Mod/Module.odc) ищется одноименный файл Obj/Module.bat, всё остальное делает уже сам батник. Проверяет существование откомпилированных модулей (при необходимости перекомпилируя их), вызывает сишный компилер, проверяет не вернул ли он ошибку; если да, то останавливается; если нет, для основного модуля вызываются Hex2bin, bin2trd, далее целевой собранный TRD-шник запускается в эмуле, связанном с расширением .trd. Запускать TRD-шник автоматически при старте умеют не все эмули. Бороться с этим планирую переходом на формат TAP.

Есть ещё варианты как сделать. Например, если одноименного батника для модуля нет, можно запускать в зависимости от выбранной команды один из батников (Bin/compile, Bin/build, Bin/run) на всю подсистему, они-то и будут знать как компилировать, собирать и запускать программы заданным компилером. Ещё вариант: ручной выбор из меню компилятора и целевой платформы, а батники будут лежать в папке bin компилятора. Эти варианты обдумываются.

Ewgeny7

24.02.2013, 20:50

Прошу прощения, а под х64 будет работать? Пока что посылает лесом, ругается на х64.

Oleg N. Cher

24.02.2013, 22:11

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

vlad

24.02.2013, 23:33

А как именно ругается?
40058
Запускал и в режиме совместимости, результат тот же.

vlad

25.02.2013, 01:11

Удалось найти пока только это: http://zx.pk.ru/showthread.php?t=18315 (тот же) и то что во вложении.

Oleg N. Cher

25.02.2013, 01:33

Да, проблема на x64 происходит из-за того, что конвертер bin2trd — досовый. Давно хочу от него избавиться. Пока что переделал батники ZXDev/Obj/HelloWorld.bat и ZXDev/Obj/TinyHello.bat (https://github.com/Oleg-N-Cher/BB-XDev/commit/60591cd4e230efd288b659af4bb4a3d8cb62e670) чтобы собирать TAP'ы другой утилитой — bin2data (https://github.com/Oleg-N-Cher/BB-XDev/commit/742497ccc5d141ef97876dc108e0835cea248563). Она умеет вставлять машкод в бейсик-загрузчик после REM (или в виде DATA), поэтому с её использованием есть трудности в случае большой программы и низкого значения RAMTOP (как в LaserDemo). Так что утилита bin2data — временное решение, до тех пор пока не будет готова утилита MakeZX (https://github.com/Oleg-N-Cher/MakeZX/), которая по задумке более универсальна.

Oleg N. Cher

25.02.2013, 04:21

Ух ты! Оказывается, утилитка bin2trd (Медноногова) есть собранная и для виндовз. Честное слово, не знал.

Сгенеренный ею TRD попробовал открыть в Spectaculator, вроде всё ок, и вот эта проблема (http://zx.pk.ru/showpost.php?p=558344) не проявилась. Надо тестировать в других эмуляторах. Но в любом случае пока что ничего более подходящего на эту тему мне не попадалось. Зато есть исходник, если что-то придётся править. Спасибо, Влад! Спасибо также за эту адаптацию Александру Шабаршину.

Обновил trd2bin (https://github.com/Oleg-N-Cher/BB-XDev/commit/809ee04b40d48271315a294662cd5dd367adce88), поправил скрипт для сборки LaserDemo (https://github.com/Oleg-N-Cher/BB-XDev/commit/f6f8b421b1519868f11356516dc82c4f51310f1c). Теперь должно работать в x64.

---------- Post added at 02:21 ---------- Previous post was at 02:14 ----------

P.S. Обнаружил, что эта версия trd2bin все буквы имени целевого TRD-шника делает строчными и устанавливает для целевого файла атрибут только для чтения.

Oleg N. Cher

25.02.2013, 07:49

Подготовил примерчик, показывающий как работать с беззнаковыми числами. (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=81)

Проблемы всё ещё есть, например, импортированные из других модулей (кроме SYSTEM) беззнаковые типы и переменные считаются знаковыми. Решать их предлагаю по мере необходимости в данном подходе. Мне важно показать, что всё, что понадобится, в технологию XDev/ZXDev можно добавить, причём не только библиотеки, но даже новые языковые конструкции, и сделать это достаточно легко.

Теперь на очереди, видимо, подсветка синтаксиса и препроцессор?

Oleg N. Cher

18.03.2013, 01:44

Ну что ж, раз все молчат — значит вопрос о раскраске синтаксиса неактуален. Тем более, такие вещи решаются в среде BlackBox Component Builder с помощью сторонних компонентов. Я знаю минимум парочку. Больше информации есть в этой теме:

Сборка BlackBox-XDev для кросс- и embedded разработки (http://forum.oberoncore.ru/viewtopic.php?f=114&t=3864)

Также обращаю ваше внимание на то, что BlackBox (и вследствие этого — XDev) обладает подходом к оформлению текстов программ, недоступным для традиционного и повсеместно используемого текстового формата с раскрашенным по шаблону синтаксисом. Например, можно внедрять в качестве комментариев к исходникам рисунки (что в ряде случаев не просто удобно, а вообще незаменимо), расширенные возможности фолдинга, позволяющие, в частности, иметь несколько вариантов исходного текста и удобно переключаться между ними. Разумеется, такой нетекстовый формат представления исходников имеет проблемы с системами контроля версий, заточенными под текст, но, надеюсь, это временная трудность, которая будет решена, ибо развитие программерского подхода должно вестись и в направлении изучения преимуществ нетекстового представления исходников, а традиция текстового представления, сложившаяся в умах программистов, на этом пути является тормозом эволюции.

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

Вот ещё одна полезная и уникальная возможность. Я дорабатываю транслятор Ofront, который ещё раньше портировался автором с Oberon-2 на Component Pascal. Часть кода осталась исходной на Обероне-2, и такой код в исходнике имеет чёрный цвет; изменения, коснувшиеся перевода на КП, обозначены красным; а свои изменения я отмечаю синим цветом. Это позволяет быстрее ориентироваться в исходниках и не путаться, имея чёткий критерий, что именно менял сам. Такой подход используется и в BlackBox (В свете этого появляется весомое преимущество задания ключевых слов в Обероне заглавными буквами, выделяющими структуру и отчасти снимающими необходимость в раскраске синтаксиса).

Темы, которые также могут быть интересны ZX-кодерам:

Как я пришёл к Оберону. Зачем его использую. Есть ли у него преимущества (http://zx.oberon2.ru/forum/viewtopic.php?f=25&t=72)

О трансляции Оберона в Си (И зачем писать на Обероне, если есть Си?) (http://zx.oberon2.ru/forum/viewtopic.php?f=46&t=93)

Обероны и кроссплатформенность (http://zx.oberon2.ru/forum/viewtopic.php?f=46&t=88)

Среда XDev: с чего начать? (http://zx.oberon2.ru/forum/viewtopic.php?f=8&t=84)

Будни разработки XDev (http://zx.oberon2.ru/forum/viewtopic.php?f=8&t=90)

На Java для ZX (Java для Z80) (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=92)

Как создать новую библиотеку для ZXDev (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=94)

Порт графической библиотеки Graph (из Turbo Pascal) под ZXDev (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=85)

psb

18.03.2013, 02:47

ибо развитие программерского подхода должно вестись и в направлении изучения преимуществ нетекстового представления исходников
нетекстовое представление - это не как в языках ld/fbd ли? или как в simulink/labview?

ZEK

18.03.2013, 02:54

Все адекватные люди от бинарных форматов уходят, яркий пример MS Office

perestoronin

18.03.2013, 02:58

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

Oleg N. Cher

18.03.2013, 10:56

я за то чтобы исходники оставить в текстовом виде - конкретно в чистом unicode.Мало ли Вы за что. Программинг шагает вообще от представления программы в виде текста к набору различными путями визуализированных принятых решений и свойств программы.

Может быть здесь прозвучат адекватные достоинства текстового представления перед нетекстовым? (не имеется в виду бинарным; это мелочи, как именно это реализовано; имеется в виду использование различных средств, повышающих графическую наглядность программы, удобство настройки путём модификации её свойств и т.п. Рано или поздно рамки текстового формата скажут "нет", и придётся их отбросить).

perestoronin, что ж Вы не прокомментировали перечисленные выше полезные возможности, которых Вы лишены при работе на чисто текстовом представлении?

Но, впрочем, спорить я не буду, программьте на чём привыкли. Или на чём заставляют гиганты индустрии.

Vitamin

18.03.2013, 11:00

Программинг шагает вообще от представления программы в виде текста к набору различными путями визуализированных принятых решений и свойств программы.
Не надо путать представление программы и контейнер для хранения артефактов разработки этой программы.
Все вышеуказанное прекрасно можно хранить в текстовом xml-based формате. Который можно и редактировать вручную при необходимости и четко видеть изменения в системе контроля версий.

psb

18.03.2013, 12:53

Oleg N. Cher, так что есть нетекстовое представление-то?

Oleg N. Cher

18.03.2013, 14:12

psb, в основном я под этим понимаю расширяемый формат составных документов каркаса BlackBox Component Builder и всю массу управляющих элементов, которые можно на нём разработать плюс инструменты по визуализации и редактированию (кнопки, строки ввода команд, визуальные мини-редакторы свойств и форм), которые легко встроить в компонентную среду на базе этого каркаса, гораздо легче, чем вцепиться намертво в текстовое представление и городить текст, а потом поверх него различные xml-файлы форм, свойств проекта, мейк-файлы и прочея.

Конечно можно иметь исходник в тексте и рядом с ним текстовый же xml, который будет расписывать где в каком месте этого исходника какой цвет и где вставлена картинка, но — упс — подредактировали чуток текст и всё рассыпалось. Зачем же так изголяться? Не для редактирования ли мы с этим xml мирились? Только для какого редактирования? А почему нельзя редактировать двоичный файл? Религиозная привязанность к любимому Notepad'у? Не лучше ли адаптировать системы контроля версий в контексте наших задач и использовать более компактный и универсальнее, чем xml, двоичный формат?

В BlackBox есть конвертеры из и в текстовое представление (html, rtf, txt и т.д.), так что совместимость по исходникам (и для контроля версий) остаётся, никуда мы от неё не убежим.

Vitamin, теги — не для чтения. Это компромисс между человеческим и машинным, подход, который имеет ограниченную применимость. Также для меня уродливо выглядит попытка насадить весь мир на xml для чего надо и в особенности для чего не надо.

Посмотрите, господа, вы в одних случаях "за" текстовый вид (например, в xml, где оно в ряде случаев чревато ошибками, громоздко, времяёмко по распарсиванию, да и требует больших объёмов памяти), а вот промежуточное представление для трансляции Оберон-программ в виде текста на языке Си — смущает. Что не так? Хотите чтобы вся музыка и графика тоже хранилась в xml, а не в mp3, jpg и png? :) Ну может со временем так и будет, если адекватные дяди из майкрософт постараются. Когда-то майкрософт удивлялся плоским html и считал их неэффективными, использовал двоичные .doc и .xls форматы. А теперь сажает на xml весь мир. Не надоело хавать всё, что суют под нос?

Господа, понятно, что расширенные возможности форматирования текстов программ могут понадобиться не всем из вас, и я, разумеется, собираюсь поддержать простой plain текст в виде UTF-8, например, и с раскраской синтаксиса, когда-нибудь. Я не ставлю цель угодить всем. А то некоторым здесь больше нравится придираться к моим формулировкам и затеять священную войну за "а мне так больше ндравица", чем аргументированно доказывать свою точку зрения, или, не дай бог, увидеть преимущества чего-то выходящего за рамки привычного и поучаствовать в его развитии.

Vitamin

18.03.2013, 15:03

Vitamin, теги — не для чтения. Это компромисс между человеческим и машинным, подход, который имеет ограниченную применимость. Также для меня уродливо выглядит попытка насадить весь мир на xml для чего надо и в особенности для чего не надо.
Возражения не сколько против бинарности формата (тот же BXML вполне себе существует), сколько против очередного самописного велосипеда с крайне туманными перспективами по устойчивости, сопровождаемости и расширяемости. И невозможность посмотреть текстовый документ без кучи всяких спецпрограмм.

Когда-то майкрософт удивлялся плоским html и считал их неэффективными, использовал двоичные .doc и .xls форматы. А теперь сажает на xml весь мир. Не надоело хавать всё, что суют под нос?
Как раз потому что бинарные доки парсить- это ужоснах, потому и переехали на более многословный, но гибкий и расширяемый xml.

psb

18.03.2013, 15:12

psb, в основном я под этим понимаю расширяемый формат составных документов каркаса BlackBox Component Builder и всю массу управляющих элементов, которые можно на нём разработать плюс инструменты по визуализации и редактированию
поискал скриншоты, ничего нового не увидел, что бы отличалось от, скажем, vb или делфей 2004 года выпуска (они описания форм хранят в тексте). куда смотреть, где примеры того, о чем вы говорите?

Oleg N. Cher

18.03.2013, 15:29

psb, пример — сама среда BlackBox Component Builder (http://oberon.ch/blackbox.html). Она в одном своём внутреннем формате сочетает то, на что в других случаях используется много форматов. Вы открываете Word и сохраняете документ в docx, открываете Си-редактор и сохраняете в текст, открываете в браузере HTML, но чтобы сохранить сразу всю страницу, Вам нужен уже веб-архив chm или mht. BB предлагает для всего этого один расширяемый формат .odc (Oberon DoCument). И для гиперпереходов, и для исходников, и для форматированных документов с динамическими картинками. Это универсализация подхода к документам вообще. А поглядеть можно... ну, например, посмотрите как изящно в тексты встраиваются коммандеры (аналог кнопки-командной строки), можно разработать подобные же, но другие по функционалу элементы управления.

Если неохота вникать в среду BlackBox, читать доки, пробовать (давно штудировали VisualStudio с многотонным талмудом в руках?). Если пипл не понимает и не хочет понимать преимуществ форматируемых элементов в исходниках (например, подчеркнуть важный фрагмент кода, а сверхважный выделить красным жирным; не до конца отлаженное пометить курсивом, а временный код бледным серым),

тут я пас.

ZEK

18.03.2013, 15:33

psb, он о маразме BB, там можно к примеру гифку анимированую или кнопку вставить в исходник, и что там как в RTF можно текст раскрашивать

Vitamin

18.03.2013, 15:39

- Итак, у нас есть 50 разных контейнеров для хранения текстовой информации, каждый со своими плюсами и минусами.
- Какой ужас! Надо что-то с этим делать! Надо придумать контейнер, заменяющий всю эту свору!
...
- Итак, у нас есть 51 разный контейнер для хранения текстовой информации...

psb

18.03.2013, 16:31

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

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

п.с. кто-то пытался сравнивать разные ревизии опенофисовских документов (текстовые xml, ага)? успешно (в смысле, все ли понятно)?

Vitamin

18.03.2013, 16:38

Alex Rider

18.03.2013, 16:39

Может быть здесь прозвучат адекватные достоинства текстового представления перед нетекстовым?

1. Можно смотреть и/или править код программы на компьютера без IDE.
2. Можно сравнивать версии кода при помощи текстовых компарилок типа WinMerge.
3. Возможность использовать для компиляции программы любые сторонныие компиляторы, поддерживающие синтаксис языка.
4. Распространенные системы контроля версий поддерживают слияние кода только в текстовом формате.

Хватит?

На самом деле, выделение разных участков кода разными стилями - это хорошая возможночть, которой мне не хватает в той же Visual Studio. Но цена бинарного подхода очень высока. Олсо костыли в виде вспомогательных файликов рядом некошерны.

Oleg N. Cher

18.03.2013, 17:00

Как сопоставить высказывание Vitamin'а об ужасности парсенья бинарных файлов и существовании вполне себе бинарного формата BXML? Я не против этого формата. Но не соотношу его с текстовым XML. Токенизированный двоичный BXML в моих глазах приобретает перед текстовым xml важное преимущество — работать с ним должна только машинная программа, а не человеческое восприятие. Я против ручного редактирования больших массивов текста в перемешку с тегами. Это больше приличествует маньяку, чем похоже на комфортную работу в визуальном средстве разработки. А то, знаете, есть такая штука ant (кто юзает яву, тот в курсе), большим недостатком которого на мой вгзляд является xml-представление командного файла. Приходится много ручками редактировать. Не, ну может кому-то и нравится. А мне это настолько давит на мозг, что уж лучше бы там были плоские текстовые команды с параметрами, но без всяких тегов.

Чем же так принципиально трудно парсить бинарные форматы? Может парсилка кривая? Я исхожу из того, что любое текстовое представление ASCII (или UTF) — это подмножество бинарного представления, но не наоборот; соответственно, потенциал бинарей выше. Нет, Vitamin прав в том, что если сломается корявый софт и придётся отскребать мозги от асфальта, то тут да, сломанные бинарные форматы отдыхают, а xml безусловно вне конкуренции.

1. Можно смотреть и/или править код программы на компьютера без IDE.ЗАЧЕМ?

Можно программить на компе без Visual Studio, в debug.exe. Или на ZX без асма, прям в хекс дампе.

2. Можно сравнивать версии кода при помощи текстовых компарилок типа WinMerge.Как-нить откройте в BlackBox два документа и нажмите F9.

3. Возможность использовать для компиляции программы любые сторонныие компиляторы, поддерживающие синтаксис языка.А почему Вы решили, что сейчас в XDev это нельзя? По-моему, я так и вызываю SDCC. :)

4. Распространенные системы контроля версий поддерживают слияние кода только в текстовом формате.Решаемо. Было бы желание решать. Как сказал умный человек: кто хочет сделать, тот ищет возможности, а кто не хочет — ищет отмазки.

На самом деле, выделение разных участков кода разными стилями - это хорошая возможночть, которой мне не хватает в той же Visual Studio. Но цена бинарного подхода очень высока. Олсо костыли в виде вспомогательных файликов рядом некошерны.Так Вы бы попробовали. ;) Нету там никаких воспомогательных файликов, только одни .odc

---------- Post added at 15:00 ---------- Previous post was at 14:55 ----------

Это называется Code Review.Это называется костыль. Придуманный, чтобы заткнуть недостатки принятого решения в виде текстового хранения исходников.

Но, впрочем, пусть будут оба подхода, раз они востребованы.

Vitamin

18.03.2013, 17:09

Я не против этого формата.
Для чего тогда изобретается новый? Или я что-то путаю, и .odc является каким-то стандартным контейнером бинарных данных (bxml/ogg/zip etc)?

ЗАЧЕМ?

Можно программить на компе без Visual Studio, в debug.exe. Или на ZX без асма, прям в хекс дампе.
А ЗАЧЕМ такие крайности- "программируй либо в IDE со всеми наворотами или прямо в отладчике по-джедайски"? Во имя чего отрезать принципиальную возможность редактировать в любимом vim/notepad/etc?

Решаемо.
Всего один вопрос- как?
Откладывание таких вопросов "на потом" - еще один гвоздь в крышку гроба хорошего начинания.

Это называется костыль.
Что именно "костыль"? Система ревью кода?

Alex Rider

18.03.2013, 17:18

ЗАЧЕМ?
А зачем мне ставить IDE и настраивать (!) ее на тестовый комп только чтобы поглядеть исходники?

Можно программить на компе без Visual Studio, в debug.exe. Или на ZX без асма, прям в хекс дампе.
А кто говорить про "программировать без IDE"? Я про посмотреть / пофиксить мелкий баг. А если я хочу на телефоне посмотреть реализацию и быстро прояснить кому-то как-йто момент работы кода? На Спектруме это можно сделать из STS, да или через POKE просто. В виду наличия эмуляторов с отладчиками мало нужно. Бесплатный легкий (относительно) компилятор csc.exe позволяет пересобрать сборку из чуть поправленных в блокноте исходников на C#. ЕМНИП, ASP.NET страницы вообще можно править "на лету", без остановки Web-сервера. В общем, не убедительно.

Как-нить откройте в BlackBox два документа и нажмите F9.
1. Я люблю WinMerge.
2. см. п.1 мне опять нужна IDE для этого.

А почему Вы решили, что сейчас в XDev это нельзя? По-моему, я так и вызываю SDCC.
Для компиляции текстового C-исходника в asm? Или SDCC теперь знает ваш хитрый бинарный формат и генерит бинарь прямо их Оберона? А если я хочу написать свой компилятор вашего бинарного текста, мне, о ужос, надо еще и парсер формата написать? Или уповать на чей-то готовый?

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

Это называется костыль.
Это средство отделения информации об анализе кода от самого кода. Ибо тулам для обработки и хранения кода эта информация совсем не нужна. А хранить ее в исходном коде накладно.

Eltaron

18.03.2013, 17:52

Можно программить на компе без Visual Studio, в debug.exe. Или на ZX без асма, прям в хекс дампе.
Я, например, активно использую поиск по файлам. Просто потому, что мне не нравится, как оно медленно в VS работает, и как неудобно по результатам перемещаться. И ни в одной IDE, что я видел, удобно не реализовано.
А если мне надо сделать какую-то хитрую операцию? BlackBox умеет, скажем, многострочные регэкспы применять ко всем файлам проекта?
А с кодогенерацией как? Писать свой сериализатор?
Бинарные форматы - это самое большое зло на свете. Для обработки текста существует слишком обширный удобный инструментарий (grep, sed, awk, perl, wc, tr etc), чтобы отказываться от него ради картинок в тексте. Код надо писать так, чтоб и обычных-то комментариев требовалось минимум, а уж картинок и подавно.

psb

18.03.2013, 19:19

Это называется Code Review. И инструментов для этого- куча. И таки все эти пометки на полях и прочие обсуждения в конечный исходник не попадают.
не попадают, а рядом лежат? или не лежат? и мне не столько бы для ревью этого бы хотелось, сколько для истории. сейчас, например, есть репа с проектом и багтрекер. в багтрекере куча полезной инфы, но она же в другом месте. и когда-то она потеряется, и кому-то потом будет неизвестно, а почему сделали именно так, останется только номер тикета, которого нет.

п.с. заточка на одну единственную среду (типа, делайте все только в нашей крутой ide) - не взлетит, имхо.

Vitamin

18.03.2013, 19:46

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

Eltaron

18.03.2013, 20:38

в багтрекере куча полезной инфы, но она же в другом месте. и когда-то она потеряется, и кому-то потом будет неизвестно, а почему сделали именно так, останется только номер тикета, которого нет.
А если сервер с системой контроля версий (не распределенной) подохнет, то потеряется вся история и комментарии к коммитам. А еще база данных, заполненная нужными данными, в том числе с таблицами-словарями, может потеряться. Но это всё не повод терабайтную помойку в VCS устраивать, достаточно просто делать бэкапы :)

Alex Rider

18.03.2013, 21:10

и кому-то потом будет неизвестно, а почему сделали именно так, останется только номер тикета, которого нет.
А кто вообще мочит тикеты из баг-трекера? o_O Самоубийцы?

Oleg N. Cher

18.03.2013, 21:17

Если IDE эта — Visual Studio, то метания понятны. Это одоробло только ставится полчаса. А ББ в полной поставке весит 5 метров и умеет работать с флешки. На остальное отвечу позже, но хочу заметить, что в XDev будет оба подхода — возможность сохранять исходники как в .odc, так и в текстовом виде со стандартной раскраской (это уже сейчас можно сделать с помощью подсистемы Мастер, если не лениться, правда, я её не тестировал под ядром 1.6). В ББ уже сейчас возможно сохранять как .odc, так и html/rtf/txt, а с помощью доп. модуля и в юникод/UTF. Все вы умнейшие ребята, но возможностей ББ не знаете даже и приблизительно, поэтому и критикуете не саму её, а своё мнение о ней.

Я, если честно, ожидал не споров по поводу текст vs не-текст, а конкретных предложений помочь с библиотеками для ZXDev. Но если это выше ваших сил, тогда ладно, сам буду помаленьку делать.

Vitamin

18.03.2013, 22:06

ББ в полной поставке весит 5 метров и умеет работать с флешки.
А работать под linux хотя бы i686 умеет?

Alex Rider

18.03.2013, 22:34

А ББ в полной поставке весит 5 метров и умеет работать с флешки.

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

Я не имею возможности критиковать/одобрять систему потому что вот на этом форуме так и не увидел ссылку чтобы скачать это, поставить по инструкции и собрать Hello, world. Приходится основываться только на словах популяризатора. У меня пока скорее смутные представления о том, что надо найти и выкачать 100500 компонентов, поредактировать 25 ini'шников, выставить сотни опций, и только тогда будет мне посмотреть. Вот например даже на пример. Сылка в начале дискуссии про новую сборку ведет на форум, на котором ссылки на setup.exe тоже нет (или не нашел).

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

perestoronin

19.03.2013, 01:44

xml ничем не лучше чем "нетекстовое представление" для хранения исходного текста.

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

В идеале наверное будет лучше если это будет документация проекта (конечно же в текстовом представлении) со встроенным в нее кодом проекта.

И никаких пожалуйста xml и двоичного хранение не надо мне "продвигать". Сыт ими. Уж и не знаю - поработаете с двоичным представлением сами поймете наверное. Особенно - когда приспичит что-нибудь найти в коде, а ссылки перестраиваются несколько часов, и ночью они как раз в этот день не были по мистической причине автоматом перестроены. Аналогично и с xml - при нарушении закрытия тега - потом тяжело найти или восстановить структуру в целом. Конфиги же в xml - кроме тоски ничего не навивают. Есть же альтернативы - причем в нормальных форматах. Загляните к таким языкам и фреймворками как Ruby On Rails. Я не говорю что они свободны от недостатков, но в части хранения конфигов, кода и доступа к нему - им нет равных, и все организовано исключительно на тексте, без блобов, двоичной сериализации и монстрообразных убогих мне не нужных xml. Особо тоскливо от html5 - родственника xml и javascript - чем то издалека напоминающего зеленую java (промышленный однако стандарт, руки выдергнуть тому, кто его "принял").

Eltaron

19.03.2013, 15:32

javascript - чем то издалека напоминающего зеленую java (промышленный однако стандарт, руки выдергнуть тому, кто его "принял").
Да ладно, джаваскрипт няшный. Как можно не любить язык с регэкспами без кавычек? :)

psb

19.03.2013, 15:35

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

А кто вообще мочит тикеты из баг-трекера? o_O Самоубийцы?
да все проще. проекты бывают продают по несколько раз, и отдают только исходники и доки, а тикетов или нет, или багрекер другой был, или черт-те что бывает, нету короче больше инфы. видно тока что фиксили какую-то проблему №n, а что, почему так, что за *****код такой - не понятно.

Vitamin

19.03.2013, 16:38

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

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

psb

19.03.2013, 17:33

нужно требовать и базу тикетов сразу. А то это организаторские костыли какие-то получаются.
слишком много усилий понадобится (а нумерация все равно же пропадет при переносе в багтрекер, ибо никто не будет поднимать 100500 разных багтрекеров сразу), а "вы же и так все сделаете, без базы". жизнь такая, без костылей не бывает. те люди вообще почти уверены, что нормальная система версий не нужна, мол, "мы будем все аккуратно делать и писать кратко суть изменений в ченджлоге каждого исходника". так что о чем вы говорите?:)))

Vitamin

19.03.2013, 17:47

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

Alex Rider

19.03.2013, 21:03

а нумерация все равно же пропадет при переносе в багтрекер, ибо никто не будет поднимать 100500 разных багтрекеров сразу

Поле типа old_document_id не спасает?

psb

19.03.2013, 21:10

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

Поле типа old_document_id не спасает?
а оно есть? я хз. и другие тоже мб хз - говорю же, заморочек много.

perestoronin

19.03.2013, 21:36

Да ладно, джаваскрипт няшный. Как можно не любить язык с регэкспами без кавычек? :)
Хороший, если его использовать как Coffescript http://jashkenas.github.com/coffee-script/

Alex Rider

20.03.2013, 00:14

а оно есть?
В любом нормальном баг-трекере набор полей тиекта кастомизируем. Привинтить и заполнять при импорте.

psb

20.03.2013, 12:45

В любом нормальном баг-трекере набор полей тиекта кастомизируем. Привинтить и заполнять при импорте.
1. кто этим будет заниматься? предполагается, что нет незанятых людей.
2. как искать эти тикеты? по спец. поисковому запросу? тогда большой разницы нет, если например хранить эти тикеты просто в отдельных текстовых файлах.

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

Alex Rider

20.03.2013, 17:51

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

как искать эти тикеты? по спец. поисковому запросу?
А почему нет? Фильтр типа old_ticket_id = nnnnnn - это сложно? Нужен отдельный способ поиска для каждой бумажки придумать? Тогда уж действительно идея с xml рядом с исходниками выглядит няшной.

psb

20.03.2013, 20:20

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

Sergey

26.03.2013, 19:03

Ребят, не подскажите, есть ли в SDCC возможность выравнивать данные на четные адреса?

Oleg N. Cher

29.04.2013, 15:14

Я не имею возможности критиковать/одобрять систему потому что вот на этом форуме так и не увидел ссылку чтобы скачать это, поставить по инструкции и собрать Hello, world. Приходится основываться только на словах популяризатора. У меня пока скорее смутные представления о том, что надо найти и выкачать 100500 компонентов, поредактировать 25 ini'шников, выставить сотни опций, и только тогда будет мне посмотреть.Это неверно.

Вот например даже на пример. Сылка в начале дискуссии про новую сборку ведет на форум, на котором ссылки на setup.exe тоже нет (или не нашел).Не нашли. setup'а нет, есть архив, скачивается по прямой ссылке "Download".

Хорошо, Алекс, вот вам инструкция.

(на самом деле она была дана уже тут на форуме (http://zx.pk.ru/showpost.php?p=539721&postcount=28), да где и как вы её проморгали — не знаю). В начале данного топика тоже есть ссылка на всё (http://zx.pk.ru/showthread.php?t=18472) (см. Скачать: https://github.com/Oleg-N-Cher/XDev/zipball/master). Там в архиве даже есть ZXDev/Docu/ZXDevRus.txt. Он на русском.

Скачать (https://github.com/Oleg-N-Cher/XDev/zipball/master). Это zip архив. Распаковать куда-нибудь.
Запустить BlackBox.exe
Открыть File->Open->ZXDev/Mod/TinyHello.odc
Нажать F12 (компиляция и запуск в эмуле по умолчанию)

ВСЁ!

Размер всего набора компонентов в репозитории смущает? Это архив разработчика. Там есть компоненты, не относящиеся напрямую к ZXDev. Заметьте, релиза версии 1.0 ещё не было. Но я берусь собрать всю среду ZXDev в пятиметровый архивчик. Но это в процессе.

P.S. Эх уж мне эта долбанная предвзятость... Это ваш линух без пуда соли, поллитры самогона и десяти потерянных лет жизни не освоить. А в XDev всё делается культурно, чтобы было удобно и по возможности просто. Оберон-традиция такая.

А работать под linux хотя бы i686 умеет?Под Wine должно заработать. Но не уверен.

Я с линухом почти не вожусь, поэтому направление работ "ZXDev + Linux" открыто для всех желающих (возможно, что даже при моей активной поддержке).

kgmcneil

01.05.2013, 17:27

Thanks for continuing to develop this tool... I am glad that you are still working on it, to make it easier to understand and more user friendly. I understand that it is a confusing collection of archived files for some, only because it is still a work in progress.

I know almost nothing about Oberon, but have been trying to learn more about this language since discovering your tool; I owe that curiousity to you! Your work has left an impression on me and inspired me to try to learn more about this language!

In the same way that a picture is worth a thousand words, maybe some of the bias that you talk of can be overcome with more demonstrations of your tool?... Perhaps if you show more examples and products of Oberon, your audience will realise the potential for this tool?... After being impressed by examples, they may then find the incentive and motivation to seek out more information on the language?...

Perhaps you should post some .TAP or .TRD files on the forum (or on WorldOfSpectrum.Org) of examples, demonstrations produced by your tool?... This may help keep interest going?...

Thank you again for making a valid contribution to the way in which programs can now be written on ZX machine!!

I look forward to seeing this project grow!

Regards,

KgMcNeil
==================================
Спасибо за продолжаем развивать этот инструмент ... Я рад, что вы все еще работаем над этим, чтобы сделать его проще для понимания и более удобной для пользователей. Я понимаю, что это запутанное коллекция архивных файлов для некоторых, только потому, что он все еще находится в стадии разработки.

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

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

Возможно, вам следует разместить несколько. Коснитесь или. TRD файлы на форуме (или на WorldOfSpectrum.Org) примеров, демонстраций производства вашего инструмента? ... Это может помочь сохранить интерес собирается? ...

Еще раз спасибо за делает весомый вклад в то, каким образом программы теперь могут быть написаны на ZX машины!

Я с нетерпением жду встречи с этим проектом расти!

С уважением,

KgMcNeil

Oleg N. Cher

25.05.2013, 03:22

Dear KgMcNeil,
Thank you again for your interest in the project XDev.

I have plans to release XDev in the future as main kit XDev and set of subsystems (plug-ins) for development for different platforms - ZXDev, WinDev, JmeDev, LinDev etc. And no doubts that size of XDev + ZXDev distribution will be really about 5 MB in archive of 7zip format.

Now we have a real perspective of support in XDev except Oberon-2 is also a new revision of the language Modula-2 (rev 2010) ( https://bitbucket.org/trijezdci/m2r10/). It's well designed powerful, strong and safe programming language. Translator from M2R10 into C and front-end for LLVM are currently in development.

I tried to take into account the wishes that have been expressed here and at WoS forum ( http://www.worldofspectrum.org/forums/showthread.php?t=41120).

1. Made restructuring project files (to streamline “a big dump of files”).
2. Simplified building of new projects (almost no need to manually write trl-files).
3. Made syntax coloring ( http://zx.oberon2.ru/forum/viewtopic.php?f=34&t=95).
4. Supported very base generating TAP-format (still need to make own converter).
5. Added some new libraries and code examples. Obtained a very basic portability between ZX Spectrum and Windows (http://zx.oberon2.ru/forum/viewtopic.php?f=8&t=97).
6. Added possibility to compile a module by F11 and build/run the project by F12.

But the project is in the stage “still not ready”. And probably need to wait for the release for not a short time. In particular, the need to improve the work with unsigned data types, correct semantic of FOR loop. These things are very important, so I do not do the first release and even new posts on the WoS and other steps in advertising now, and just going after the environment will be ready to be used not only for testing. How long will it take? The sensitive issue.

Great success of the project ZXDev that we have a new developer - Oleg Komlev (Saferoll). He has been joined to the project, and increased the viability of it by twice.

The importance of the opportunity to study Oberon and work in this language is good not only for the ZX machine, but for others (almost all) architectures and platforms. If you take the semantics of a typical imperative language, such as Modula-2 or C, then semantics of Oberon can not be fully implemented in this languages. Therefore, we can use for such resources-limited machine as ZX only a subset of Oberon. But even very large in size and capability language I would like to see based on the full set of semantics of Oberon-2, but better – of Component Pascal. Oberon is the balanced minimal semantic set, which in many cases is sufficient even for the development of serious projects. But, basically, we want to improve the language by adding new features to it, which seems to us necessary.

What is now most important to the project? The users. The new libraries, ideas and open source projects. One or two people like you and me can do a little in this direction. This is vicious circle. To have more users - we need to show them the benefits and advantages of XDev. And to have more benefits - we need people who will encourage and contribute directly to its implementation.

Most annoying confounding factors. This is a great competition among programming languages, the total inertia of people and too little programmers for the Spectrum, and 99% of them do not use for development for Z80 anything other than the assembler.

XDev project needs of interested enthusiasts who will take it and use it in the form in which it is, and all defects and deficiencies will be corrected together. And I see only such a strategy for its development.

You are certainly right that the low prevalence of the project XDev can be overcome by posting pictures and snapshots of the target audience. And the best advertisement would certainly be ready projects, but there is no one to do, as you see, people are not very interested in it.

So if you have questions or suggestions, if you are interested in the language Oberon and development in it for ZX and any other platform, I am pleased to invite you to the forum of ZXDev project ( http://zx.oberon2.ru/forum/viewforum.php?f=10). English language is not an obstacle, almost of all programmers of Russia and Ukraine understand it.

Уважаемый KgMcNeil.
Ещё раз спасибо за Ваш интерес к проекту XDev.

Я планирую в будущем сделать релиз системы XDev как основного инструмента, и к нему — набор подсистем (плагинов) для разработки для различных платформ — ZXDev, WinDev, JmeDev, LinDev и т.д. И несомненно размер дистрибутива XDev + ZXDev действительно будет около 5 Мб в архиве формата 7zip.

Сейчас у нас есть реальная перспектива поддержать в XDev, кроме Оберона-2, ещё и новую ревизию языка Модула-2 (rev 2010) ( https://bitbucket.org/trijezdci/m2r10/). Это хорошо продуманный, мощный и безопасный язык программирования. Транслятор с M2R10 в Си и фронт-энд для LLVM сейчас в стадии разработки.

Я постарался учесть все пожелания, которые были высказаны здесь и на форуме WoS ( http://www.worldofspectrum.org/forums/showthread.php?t=41120).

1. Сделана реструктуризация проекта (чтобы упорядочить “большую свалку файлов”).
2. Упрощена компиляция новых проектов (почти нет необходимости вручную писать trl-файл).
3. Сделана раскраска синтаксиса ( http://zx.oberon2.ru/forum/viewtopic.php?f=34&t=95).
4. Поддерживается базовое создание TAP-формата (всё еще нужно делать собственный конвертер).
5. Добавлены новые библиотеки и примеры. Достигнута весьма начальная кроссплатформенность между ZX Spectrum и Windows (http://zx.oberon2.ru/forum/viewtopic.php?f=8&t=97).
6. Добавлена возможность компиляции модуля по F11 и сборки/запуска проекта по F12.

Но проект всё ещё в стадии неготовности. И ждать реализации, вероятно, ещё долго. В частности, требуется улучшение работы с беззнаковыми числами, коррекция работы цикла FOR. Эти вещи очень важны, поэтому я и не делаю первой реализации и пока не делаю новые посты на WoS и другие шаги по рекламе сейчас, а только собираюсь после того как среда будет готова к использованию не только для тестирования. Сколько времени это займёт? Непростой вопрос.

Большая удача проекта ZXDev — это то, что к нам присоединился ещё один разработчик — Олег Комлев (Saferoll), так что жизнеспособность выросла в два раза.

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

Что сейчас самое важное для проекта? Это пользователи. Новые библиотеки, идеи и проекты с открытыми исходниками. Один или два человека, как Вы и я, могут мало сделать в этом направлении. Это — заколдованный круг. Чтобы было больше пользователей — нужно показать им преимущества XDev, а чтобы преимуществ появилось больше — нужны пользователи, которые будут стимулировать и прямо способствовать их появлению.

Самые досадные мешающие факторы. Это большая конкуренция среди языков программирования, общая инертность людей и слишком маленькое количество программистов для Спектрума, а 99% из них не применяют для кодирования под Z80 ничего, кроме ассемблера.

Проект XDev очень нуждается в заинтересованных энтузиастах, которые будут брать его и использовать в том виде, в котором он есть, а все недочёты и недостатки будут исправляться совместно. И я вижу только такую стратегию его развития.

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

Поэтому если Вас интересует язык Оберон и разработка на нём для любой платформы, я рад пригласить Вас на форум проекта XDev ( http://zx.oberon2.ru/forum/viewforum.php?f=10). Английский язык не будет препятствием, его понимают практически все программисты в России и Украине.

Oleg N. Cher

21.08.2013, 01:34

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

Или давайте подискутируем о том, как вы попали на необитаемый остров с ноутом, полным бинарных исходников, но забыли парукилобайтный декодер в текст? ;)

Вообще же с грустью констатирую недалёкость программерских умов (включая и свой тоже, просто самому это не так заметно).

http://redmine.molpit.com/projects/bbcb/repository

Вот непредвзятый чел на Обероне игру делает для Спека, зацените:

http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=125&start=10#p585

psb

21.08.2013, 04:43

игра агонь! все на оберон! ждем также демы на обероне!

ZEK

21.08.2013, 09:53

вы попали на необитаемый остров с ноутом, полным бинарных исходников
:) это страшный сон оберонщика?

Остальным не грозит, им даже тестового редактора обычного достаточно

Oleg N. Cher

21.08.2013, 12:57

Это страшный сон тех, кто не видит дальше своего носа.
Редактор бинарных исходников - такая же программа, как и текстовый редактор. Ничем не хуже. Значит с дискеткой с vi сидим на острове?

> Эти 2 пользователя(ей) сказали Спасибо ZEK за это полезное сообщение:
Вот так и растут рейтинги незаслуженно.

---------- Post added at 11:57 ---------- Previous post was at 11:54 ----------

игра агонь! все на оберон! ждем также демы на обероне!

Неа, все срочно на асм Z80. И поторопитесь - предложение сильно ограничено - количество живых процессоров этого типа в мире стремительно уменьшается.

jerri

21.08.2013, 12:59

Oleg N. Cher, чтобы оценить устрицу, надо ее прожевать.
когда автор обещает прототип?

Oleg N. Cher

21.08.2013, 13:08

Прототип чего?

---------- Post added at 12:05 ---------- Previous post was at 12:01 ----------

Если ты об игре, то не знаю. Вопросы к автору.

---------- Post added at 12:08 ---------- Previous post was at 12:05 ----------

Я ему уже намекал, что неплохо бы поиграть. Но, похоже, игра делается для какого-то конкурса (или пати), так что придётся подождать.

Vitamin

21.08.2013, 13:09

Это страшный сон тех, кто не видит дальше своего носа.
Вот решил я таки посмотреть что это за язык программирования такой- оберон и с чем его едят применительно к теме.
Иду на указанный адрес http://redmine.molpit.com/projects/bbcb/repository. Вижу приятный репозиторий. Пытаюсь посмотреть какой-нибудь файл типа ocf из папочки Code. В онлайне просмотр не работает. Просмотр диффов тоже не работает. Предлагают скачать. Ладно, выберу notepad в качестве просмотрщика. Открывается бинарное херпоймичто. Нахрен.

ZEK

21.08.2013, 13:14

Значит с дискеткой с vi сидим на острове?
бредим? при чем тут дискета и vi ?

Сколько операционок у которых в базовом комплекте нет хоть какого то чаморошного редактора текста?
А сколько операционок у которых в комплекте редактор модулей BB ?

---------- Post added at 12:14 ---------- Previous post was at 12:12 ----------

Просмотр диффов тоже не работает.
У товарища контроль версий это хранение истории файлов

Vitamin

21.08.2013, 13:15

Сколько операционок у которых в базовом комплекте нет хоть какого то чаморошного редактора текста?
Даже если нет редактора, есть хотя бы просмотрщик. В том же досе есть type/more, в самом что ни на есть голом линуксе есть cat/less/more.

jerri

21.08.2013, 13:20

Oleg N. Cher

21.08.2013, 13:58

Вижу приятный репозиторий. Пытаюсь посмотреть какой-нибудь файл типа ocf из папочки Code. В онлайне просмотр не работает. Просмотр диффов тоже не работает. Предлагают скачать. Ладно, выберу notepad в качестве просмотрщика. Открывается бинарное херпоймичто. Нахрен.А это бинарный файл. Ты лучше EXE в нотепаде открой. Ламерство нафиг.

---------- Post added at 12:52 ---------- Previous post was at 12:51 ----------

А просмотр диффов безусловно работает:

http://redmine.molpit.com/projects/bbcb/repository/revisions/e66246e5c264426ce77bdd68de8d9f0efe8652e5

---------- Post added at 12:54 ---------- Previous post was at 12:52 ----------

бредим? при чем тут дискета и vi ?

Сколько операционок у которых в базовом комплекте нет хоть какого то чаморошного редактора текста?
А сколько операционок у которых в комплекте редактор модулей BB ?Сколько домов, в которых есть лопаты! А сколько чмошных городских квартир, в которых нету экскаватора? Тотоже.

---------- Post added at 12:58 ---------- Previous post was at 12:54 ----------

Я вообще не вижу смысла брать для работы случайный текстовый редактор из случайной операционки. Он может даже нужных кодировок не поддерживать. Или фич. В чужой операционке свои исходники не правь. Лучше иметь при себе свой комплект инструментального софта. С этим поспоришь?

Ну а если нету, значит и правда остров и дискетка с vi, и никакого инета с вайфаем и любимой флешкой в кармане.

Vitamin

21.08.2013, 14:04

А это бинарный файл. Ты лучше EXE в нотепаде открой. Ламерство нафиг.
Открыл odc. Уже лучше. Но все равно, с точки зрения просмотра без специнструментов - лажа.
И для чего в репозитории хранить компилированные версии исходников?

А просмотр диффов безусловно работает:
Безусловно?
Переходим на родительский коммит, открываем дифф по odc файлу и внезапно получаем МПХ на весь экран
http://redmine.molpit.com/projects/bbcb/repository/revisions/c2afaeac26ea8220ac022c65c853cf5ed6e0439e/diff/System/Mod/Kernel.odc
Следующие родители вроде бы работают
http://redmine.molpit.com/projects/bbcb/repository/revisions/ba20daa197001c91118f531eba25ec40a9dfad23/diff/Dev/Mod/CPC486.odc
http://redmine.molpit.com/projects/bbcb/repository/revisions/e13aef1d3ac421d85fa3828e4f7fc1f6653d5621/diff/Text/Mod/Cmds.odc
Потом опять- часть работает, часть не работает.
http://redmine.molpit.com/projects/bbcb/repository/revisions/d44df092bd7e36a2202296cbd109a4fd09e0a472/diff/Host/Mod/Files.odc
http://redmine.molpit.com/projects/bbcb/repository/revisions/d44df092bd7e36a2202296cbd109a4fd09e0a472/diff/Host/Mod/PackedFiles.odc

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

Так и пиши "просмотр диффов ограниченно работает". Будет честнее.

Oleg N. Cher

21.08.2013, 14:06

Вот уже ж самолюбие затронул. :) Vitamin, остановись подумай. Пропагандируемый тобою Linux-way - его может на твой век и хватит, но это же не повод рубить сплеча только-только пробивающие себе путь ростки альтернативщины? С таким настроением Оберон лучше не осваивать. Конечно проблемы есть, но репу-то без году неделя. А дифы между .ocf это всё равно что между .exe, смотри дифы между .odc - это исходники.

Vitamin

21.08.2013, 14:10

Сколько домов, в которых есть лопаты! А сколько чмошных городских квартир, в которых нету экскаватора? Тотоже.
Ага. Спецредактор- это как раз экскаватор. Неудивительно, что во многих чмошных городских квартирах его нет.

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

Он может даже нужных кодировок не поддерживать. Или фич.
Фичи редактора влияют исключительно на удобство пользования, а не на выходной результат.

В чужой операционке свои исходники не правь. Лучше иметь при себе свой комплект инструментального софта.
А как же совместная разработка через систему контроля версий? Или каждый только свои собственные файлы правит дабы не нарушить Заповедь?

Vitamin

21.08.2013, 14:13

но это же не повод рубить сплеча только-только пробивающие себе путь ростки альтернативщины
Я извиняюсь, какие к черту "только-только пробивающие"???? Никто чтоли не пользовался документами от msoffice? Со всеми их плюсами и минусами
(да, я знаю об встроенной истории изменений и о плагине к windiff, позволяющему смотреть разницу между doc файлами).

Oleg N. Cher

21.08.2013, 14:13

Github вроде тоже не показывает изменения между бинарями? Так чего ж ты, родной, от меня хочешь. ;)

---------- Post added at 13:13 ---------- Previous post was at 13:10 ----------

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

А как же совместная разработка через систему контроля версий? Или каждый только свои собственные файлы правит дабы не нарушить Заповедь?Нормально всё организовано. А если ты про автоматическое слияние правок в бинарях, то хотелось бы рассмотреть это на примере PDF или EXE. Нормально если такую ответственную вещь как слияние бинарей в проекте с небольшим количеством разработчиков доверить исключительно ручкам, а не кривому скрипту, а?

ZEK

21.08.2013, 14:14

Лучше иметь при себе свой комплект инструментального софта. С этим поспоришь?
А еще лучше когда помимо родных инструментариев (которые могут не устроить по каким либо критериям) есть и альтернативы, тот же C# можно править в Visual Studio, а можно Notepad++. Выбираем по потребностям, когда выбор есть это еще лучше чем просто наличие родного инструментария, с этим поспоришь?

Oleg N. Cher

21.08.2013, 14:15

"только-только пробивающие" это я про сувание в Git поддержки для диффов исходников бинарного формата .odc

Да и вообще про Обероны.

Vitamin

21.08.2013, 14:15

Нормально всё организовано. А если ты про автоматическое слияние правок в бинарях, то хотелось бы рассмотреть это на примере PDF или EXE. Нормально если такую ответственную вещь как слияние бинарей в проекте с небольшим количеством разработчиков доверить исключительно ручкам, а не кривому скрипту, а?
"Слияние exe бинарей". You made my day!
Ты, пусть хоть и ручками, это сделать можешь? В самом общем случае, разумеется.

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

Oleg N. Cher

21.08.2013, 14:19

Выбираем по потребностям, когда выбор есть это еще лучше чем просто наличие родного инструментария, с этим поспоришь?Против выбора не поспоришь. Но ты говоришь о готовых текстовых редакторах. Подход обкатан по самую жопу. А я о будущих фичах редакторов, которые ещё предстоит сделать. Но чего-то я скатываюсь в спор ради спора. Некарашё. ;)

---------- Post added at 13:19 ---------- Previous post was at 13:18 ----------

Я ручками PDF и EXE слить не могу. Но ты тут говоришь о коллективной разработке. А я о слиянии бинарных исходников.

Vitamin

21.08.2013, 14:19

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

Oleg N. Cher

21.08.2013, 14:22

Обычно - да. Видишь смысл продолжать этот разговор? Любимый Мозоль заживёт, посты останутся висеть.

Vitamin

21.08.2013, 15:00

Обычно - да. Видишь смысл продолжать этот разговор? Любимый Мозоль заживёт, посты останутся висеть.
.

Hacker VBI

21.08.2013, 15:02

По утверждению Вирта, разработчики языка Java за несколько лет до её создания «изучили исходные коды Оберона и, в частности, исходные коды обероновских сборщиков мусора. Потом они испортили Оберон синтаксисом Си и назвали получившееся словом Java».

:)

Vitamin, хороший сжатый ответ.

jerri

21.08.2013, 15:24

Vitamin, а оберон разве императивный язык программирования?

и это я тут вот такую табличку нашел (http://ru.wikipedia.org/wiki/Сравнение_языков_программи рования)
закачаетесь. там почему то purebasic есть а оберона нет - нипарядок

Vitamin

21.08.2013, 15:32

Vitamin, а оберон разве императивный язык программирования?

Класс языка:
императивный, структурированный, модульный

http://ru.wikipedia.org/wiki/Оберон_(язык_программирова� �ия)

Oleg N. Cher

21.08.2013, 15:52

На моём острове как раз не нашлось поверпоинта версии не ниже 2003 (с поддержкой формата pptx от 2007, разумеется). ;)

Vitamin, мы как-то все (не только ты) научились прощать unix-вею его недостатки, как-то они нам примелькались и перестали замечаться. А вот недостатки Оберон-вея так и прут. Приходи, зарегься девелопером, отладить диффы поможешь. Это будет полезнее, чем злобственно отстаивать свою сомнительную точку зрения, подкреплённую ничем, кроме таких же злых линухоидов с убитым взглядом красных глаз.

Но твои посылы в этом контексте сродни многоголосому вою при появлении новой парадигмы "Зачем, ЕСЛИ У НАС УЖЕ ЕСТЬ СТАРАЯ С КУЧЕЙ ГОТОВЫХ ИНСТРУМЕНТОВ?"

ps Да, разумеется, Java слизана с Оберона. Это заметно невооружённым взглядом убитых красных глаз. :)

ZEK

21.08.2013, 15:57

По утверждению Вирта, разработчики языка Java за несколько лет до её создания «изучили исходные коды Оберона
А разработчики оберона сперли сборку мусора у lisp ( который лет за 10 до оберона появился) итд так долго качать можно

Oleg N. Cher

21.08.2013, 16:00

Вирту принадлежат лавры реализации сборки мусора в императивном и компилируемом языке. До Оберона это было только в функциональных и интерпретируемых.

Плюс Оберон ближе к железу. Почему на C# и Java никогда-никогда не будут писать задачи жёсткого реального времени, ОС и дрова? Да нам просто подсунули неполноценные ЯП для шурования "бизнес-логики" во все её... эээ... проявления. :)

ZEK

21.08.2013, 16:01

очему на C# и Java никогда-никогда не будут писать задачи жёсткого реального времени, ОС и дрова?
Гугл в помощь реализации осов и дров на C# и Java

Vitamin

21.08.2013, 16:07

На моём острове как раз не нашлось поверпоинта версии не ниже 2003 (с поддержкой формата pptx от 2007, разумеется).
А на моем не нашлось uber-oberon-source-view-utility

Vitamin, мы как-то все (не только ты) научились прощать unix-вею его недостатки, как-то они нам примелькались и перестали замечаться. А вот недостатки Оберон-вея так и прут.
Причем здесь unix-way? Исходный текст программы предназначен для редактирования и просмотра человеком, крайне желательно стандартными средствами.

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

Но твои посылы в этом контексте сродни многоголосому вою при появлении новой парадигмы "Зачем, ЕСЛИ У НАС УЖЕ ЕСТЬ СТАРАЯ С КУЧЕЙ ГОТОВЫХ ИНСТРУМЕНТОВ?"
Подтасовка фактов.
1) никакой новой парадигмы нет
2) не "зачем новая, если есть старое", а "почему старое не может быть применено без оснований"

Плюс Оберон ближе к железу. Почему на C# и Java никогда-никогда не будут писать задачи жёсткого реального времени, ОС и дрова? Да нам просто подсунули неполноценные ЯП для шурования "бизнес-логики" во все её... эээ... проявления.
Т.е. все программирование сводится к писанине задач жесткого реального времени? А бизнес-логика совсем нигде и никак не нужна?

Oleg N. Cher

21.08.2013, 16:22

А на моем не нашлось uber-oberon-source-view-utilityТак ты бы начал непредвзятое изучение вопроса не с попыток открыть скомпилированный бинарник в блокноте и не смешивания недостатков Оберона с глючностью недоотлаженного дифа, а сперва реп себе склонировал да запустил BlackBox.exe, посмотрел бы. Хотя честно с такими настроениями лучше и не браться за это.

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

Прекрати, сделай поддержку обычного текстового формата, привлечешь гораздо больше людей.В своей сборке XDev я уже давно сделал поддержку обычного текстового формата (и подсветку синтаксиса) (http://zx.oberon2.ru/forum/viewtopic.php?f=34&t=95), о чём даже анонсировал это здесь (http://zx.pk.ru/showpost.php?p=604017&postcount=97) (и куду вашы глаза смотрелы?). Но людей (адекватных и непредвзятых), как видишь, не привлёк. Так чего мне терять, товарищ. ;)

1) никакой новой парадигмы нет(имхо имхо имхо, прости боженька)

Т.е. все программирование сводится к писанине задач жесткого реального времени? А бизнес-логика совсем нигде и никак не нужна?Нужна конечно, но противно смотреть как она превалирует над всем остальным (и здравым смыслом тоже). Творцы своего светлого коммерческого будущего из корпоративных кирпичиков готовых компонент в полу-компонентных средах.

Дело энтузиастов - прорабатывать новые парадигмы и искать решения, а не тупо гнуться под бизнес-логику, пусть она стожды распрекрасна для коммерции.

ZEK

21.08.2013, 16:35

прорабатывать новые парадигмы и искать решения
это если кто то оплачивает эти поиски решения и предприятие где внедряют эти новые парадигмы готовы понести финансовые потери в угоду светлого будущего энтузиастов

Vitamin

21.08.2013, 16:46

Так ты бы начал непредвзятое изучение вопроса не с попыток открыть скомпилированный бинарник в блокноте и не смешивания недостатков Оберона с глючностью недоотлаженного дифа, а сперва реп себе склонировал да запустил BlackBox.exe, посмотрел бы. Хотя честно с такими настроениями лучше и не браться за это.
1) Попытка открыть нескомпилированный исходник точно так же ничем хорошим не закончилась.
2) По поводу оберона как языка я абсолютно ничего не говорил. Крайне сомневаюсь, что бинарный формат исходников является его неотъемлимой частью.
3) И не собираюсь возиться с wine для банального знакомства с тулчейном

Это крайне стандартная точка зрения!
Те же немногочисленные избранные, кто в теме насчёт достоинств расширяемых исходников BlackBox, от них по возможности не откажутся уже никогда.
Где шел разговор об отказе от каких-то фич среды?

В своей сборке XDev я уже давно сделал поддержку обычного текстового формата (и подсветку синтаксиса), о чём даже анонсировал это здесь (и куду вашы глаза смотрелы?).
1) По первой ссылке нашел упоминание в середине страницы (а не поста), по второй ссылке упоминания не нашел.
2) Поддержка импорта текстовых файлов != хранение в plain text по дефолту

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

Нужна конечно, но противно смотреть как она превалирует над всем остальным (и здравым смыслом тоже). Творцы своего светлого коммерческого будущего из корпоративных кирпичиков готовых компонент в полу-компонентных средах.

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

И да, чем неоптимальное, но быстрое написание программ на Java для обычного ПЦ хуже, нежели неоптимальное, но быстрое программ на Oberon для ZX Spectrum?

Oleg N. Cher

21.08.2013, 17:07

1) Попытка открыть нескомпилированный исходник точно так же ничем хорошим не закончилась.В блокноте? Мы уже тут полгода талдычим, что исходники в ББ - бинарные. Их надо открывать в BlackBox.exe

2) По поводу оберона как языка я абсолютно ничего не говорил. Крайне сомневаюсь, что бинарный формат исходников является его неотъемлимой частью.Разумеется, не является.

3) И не собираюсь возиться с wine для банального знакомства с тулчейномВаше право! Вот slenkar (автор игры) тоже не возится с wine. Взял и заюзал (что не заюзалось - допилил) под линух весь инструментарий для разработки на Обероне для ZX.

Где шел разговор об отказе от каких-то фич среды?От фич, предоставляемых не чисто текстовыми бинарными исходниками? Разве такой отказ не подразумевается желанием нормально отредактировать нормальный текстовый исходник в любом кривом редакторе, первым попавшимся под руку?

1) По первой ссылке нашел упоминание в середине страницы (а не поста), по второй ссылке упоминания не нашел.Я проверял ссылки, там всё чётко.

2) Поддержка импорта текстовых файлов != хранение в plain text по дефолтуЭкспорт тоже поддеривается. А заплатишь - вообще конфетку сделаем. Ты же у нас любитель бизнес-подхода. :v2_dizzy_punk:

Сколько проект существовал до этой поддержки и сколько людей было привлечено?Ну примерно с год. И человека с полтора. :)

А можешь дать определение понятия "бизнес-логика"? А то вижу крайне слабое знание матчасти.Каким боком тут матчасть до бизнеса? Эх был бы я модером, поубывав бы за срач в ветке. Ты ко мне на форум приходи, там оторвёмся. ;)

И да, чем неоптимальное, но быстрое написание программ на Java для обычного ПЦ хуже, нежели неоптимальное, но быстрое программ на Oberon для ZX Spectrum?Здесь дело в удовольствии от написания правильных программ на правильном языке для правильного компьютера. ;) А не в подгибании под убогий синтетический синтаксис а ля напиши quick&dirty кодик, страшненькое обязательное ООП, кривую и тормозатую виртуальную машину, которую никогда-никогда не реализуют в железе и специально сделанную чтобы срубить бабла.

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

ps Вот он почерк крютого линухойда. В винде ему презентацию сделать не западло, а ББ посмотреть западло. ;)

Vitamin

21.08.2013, 17:24

От фич, предоставляемых не чисто текстовыми бинарными исходниками? Разве такой отказ не подразумевается желанием нормально отредактировать нормальный текстовый исходник в любом кривом редакторе, первым попавшимся под руку?
Чем плохо разделение исходников на две части- чисто текстовую и метаинформацию?

Ну примерно с год. И человека с полтора.
Полтора человека за год. Значит за 4 месяца (время внедрения поддержки текстового формата) это полчеловека. Банально не долждался.

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

кривую и тормозатую виртуальную машину, которую никогда-никогда не реализуют в железе
Да ну?
http://en.wikipedia.org/wiki/Java_processor
http://en.wikipedia.org/wiki/Jazelle

страшненькое обязательное ООП
По-твоему ООП - это написание кода в классах?

Я тебе и на яве могу без ООП писать и на С с ООП писать.

Oleg N. Cher

21.08.2013, 18:02

Чем плохо разделение исходников на две части- чисто текстовую и метаинформацию?

Тем, что метаинформацию приходится редактировать в xml, а это костыль и прошлый век. А если это будет несколько файлов, то есть риск рассинхронизации со всеми вытекающими. А если всё впихнуть в бинарь, то откатываемся к пункту 1. :)

Полтора человека за год. Значит за 4 месяца (время внедрения поддержки текстового формата) это полчеловека. Банально не долждался.Я так и знал, что ты это спросил не просто чтобы посочувствовать. :)

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

Да ну?
http://en.wikipedia.org/wiki/Java_processor
http://en.wikipedia.org/wiki/JazelleНе, ты покажи это у меня дома. :) А зек пусть покажет дрова на яве для винды. И новую версию виндовз на сишарпе. То - экзотика.

Да-да, знаю что Оберон тоже экзотика. ;)

По-твоему ООП - это написание кода в классах?

Я тебе и на яве могу без ООП писать и на С с ООП писать.Я тебе о том же. Только на яве без ООП не можешь. Здесь дело в том, какие кирпичики даёт парадигма для того, чтобы разрабатывать с их помощью код. Как заставляет мыслить, если хочешь. Мне модули намного ближе классов. Они и технически совершеннее. В модуле может быть куча классов, а может и ни одного. Java же заставляет лепить классы и строить логику софта, исходя из классов, отсюда классы-обёртки и прочие прелести.

Но пока не прочувствуешь всё - не поймёшь. Я и логику работы с *.h и *.c начал понимать, когда научился эмулировать модульность такими средствами. Когда узнал что это такое. А до этого инклюдил *.c друг из друга и удивлялся варнингам. А некоторые уважаемые (и очень опытные!) программисты, не буду тыкать пальцем, до сих пор инклюдят *.c из *.c - из этого они делают вывод, что в их работе по-другому нельзя. Оптимальность, логика работы программы и ещё много умных слов. Я же делаю вывод, что они не понимают что такое модульность и не умеют ею пользоваться. Потому что я прошёл через всё это банально много лет назад. Это просто этап. А в Обероне так ни-зя.

Vitamin

21.08.2013, 18:17

Тем, что метаинформацию приходится редактировать в xml, а это костыль и прошлый век. А если это будет несколько файлов, то есть риск рассинхронизации со всеми вытекающими. А если всё впихнуть в бинарь, то откатываемся к пункту 1.
Храни метаинформацию в бинарном виде.
В конце концов, если сам файл исходника будет подмножеством xml, то совместит в себе преимущества текстового представления (просмотр в оригинальном виде после примитивной вырезалки тегов, легкость разрешения конфликтов при работе с системами контроля версий- как ты в своем формате эти конфликты разрешаешь?)

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

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

Я тебе о том же. Только на яве без ООП не можешь.
Пишу все в статических функциях. Храню все в статических переменных. Никакого ООП.

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

Мне модули намного ближе классов.
Вот с этого надо было начинать и этим же заканчивать. А не притягивать из-за этого предпочтения какую-то псевдотеорию.

А некоторые уважаемые (и очень опытные!) программисты, не буду тыкать пальцем, до сих пор инклюдят *.c из *.c - из этого они делают вывод, что в их работе по-другому нельзя. Оптимальность, логика работы программы и ещё много умных слов. Я же делаю вывод, что они не понимают что такое модульность и не умеют ею пользоваться. Потому что я прошёл через всё это банально много лет назад. Это просто этап. А в Обероне так ни-зя.
А если не инклюдить *.c из *.c - это означает знание что такое модульность и умение ей пользоваться?

ZEK

21.08.2013, 18:28

что такое модульность и не умеют ею пользоваться
в C# модульность покруче будет (сборки, assembly), а глобальные сборки это сродни обероновским, расширяют систему в целом и становятся частью общей среды, в питоне модульность вообще на новый уровень поднята

Как бы за 50 лет придуман не только синтаксический сахар но и очень полезные вещи, к примеру нормальные метаданные а не обероновский rtti

Ознакомиться для саморазвития с новшествами полезно, может что в оберон перетянете, я тож когда до считал оберон крутой штукой, но со временем понял что он мягко говоря морально устарел и убог, причем как в средствах так и в реализации

банальная путаница бизнес-логики и бизнес-приложений
когда упомнинается "бизнес логика" совместно с java/c# это в 99% энтерпрайз калькулятор очередной

Vitamin

21.08.2013, 18:31

когда упомнинается "бизнес логика" совместно с java/c# это в 99% энтерпрайз калькулятор очередной
А если не с java/c# - то что тогда?
Ты хоть, надеюсь, знаешь в чем разница? Или после слова "бизнес", ассоциирующегося с лощеными мажорами в пиджаках думалка отказывает?

ZEK

21.08.2013, 18:34

Ты хоть, надеюсь, знаешь в чем разница?
прикинь она даже в железе есть и Scada системах в которых то и код в общем понимании не сильно и код

Oleg N. Cher

21.08.2013, 19:11

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

А как насчёт иметь метаинформацию в бинарном виде, а потом, отредактировав исходник, к которому она "прилагается" "любым текстовым редактором", получить рассинхронизацию и глюки?

Чего такого хорошего в xml, кроме того, что ты можешь его отредактировать "в любом текстовом редакторе", если это прошлый век и нужны спец.редакторы? В чём преимущества подхода чисто текстового представления xml, если информацию они несут бинарную, и могли бы вполне быть бинарными?

Не, мы определённо говорим на разных языках. Ты - сильно прожжённый программер, которого жизнь заставила писать "бизнес-логику", я - почти такой же наивный пацан, как и в 17 лет за первым спектрумом. Не мне тебя судить. Но и не тебе решать кто из нас круче знает матчасть и владеет терминологией.

Пользы только я от всего этого нашего общения мало для дела вижу, вот что.

В конце концов, если сам файл исходника будет подмножеством xml, то совместит в себе преимущества текстового представления (просмотр в оригинальном виде после примитивной вырезалки тегов,С тем же успехом - после примитивной конвертилки из бинаря в текст. Не, ну вот чего ты такой односторонний? :)

легкость разрешения конфликтов при работе с системами контроля версий- как ты в своем формате эти конфликты разрешаешь?)Ты мне что ли предлагаешь xml ручками редактировать? Я это ненавижу. :)

Ну раз так, чем тогда оберон лучше явы? Ничем. Хуже, пожалуй, распространенностью и всеми вытекающими из этого последствиями. Языковые тонкости не рассматриваю- каждому языку свою задачу и свою область применения.Ну если тебе так будет спокойнее жить, то пускай Оберон хуже явы. :) Но ты помнишь мой пост? Си эмулирует модульность инклюдами, а ява классами. Но почему сразу не нормальную модульность?

Вообще же грешок Оберона - в том, что он сильно опередил своё время (и не спорь, иначе из него бы идеи не таскали и по сей день; и хоть бы полностью вытаскали, а так ведь пропускают через своё кривущее испорченное всеми бедами мировоззрение). И у него есть чему поучиться многим другим языкам.

Вероятно, стоит отметить что закат C++ не за горами, он слишком большой и тяжёлый, старичок уже совсем. C# не намного проще его, хотя и сильно моложе. Делать из него монстра дальше - это единственное предложение от мелкомягких. Оберон же - в самом начале этого пути, и никогда не будет поздно сделать из него монстра. Но я его чту за здравую МИНИМАЛЬНУЮ программную основу, а вовсе не за те недостатки, к которым вы придираетесь, господа.

Пишу все в статических функциях. Храню все в статических переменных. Никакого ООП.Ты без объектной терминологии не объяснишь новичку как писать хело ворлд. Сперва ты загрузишь его что такое класс, потом что такое экземпляр класса (потому что кому-то не понравилось слово "объект"), но так и не сможешь ему втолковать на первый год что такое this. ;)

А если не инклюдить *.c из *.c - это означает знание что такое модульность и умение ей пользоваться?Это вовсе не обязательно.

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

---------- Post added at 18:11 ---------- Previous post was at 18:03 ----------

в C# модульность покруче будет (сборки, assembly), а глобальные сборки это сродни обероновским, расширяют систему в целом и становятся частью общей среды, в питоне модульность вообще на новый уровень поднятаВот все так говорят. Но ничем такой взгляд не подтвержается, кроме кучки желающих самоутвердиться, сбившихся в сообщество.

Разумеется, концепция обероновских модулей гораздо чище сишарповских "сборок". К тому же C# - это язык одной компании и практически для одной платформы. Но давайте поговорим о нём лет через 20. Тогда это будет такой же архаикой как PL/1 сегодня.

Как бы за 50 лет придуман не только синтаксический сахар но и очень полезные вещи, к примеру нормальные метаданные а не обероновский rttiКак бы это проблема не языка, а кода (например, ядра системы), написанного на нём?

я тож когда до считал оберон крутой штукой, но со временем понял что он мягко говоря морально устарел и убог, причем как в средствах так и в реализацииКак бы ни так. Лучше вспомни свою идею Активного Оберона на спеке (многозадачность средствами IM2?). А ведь IM2 это вовсе не панацея, да и большевато ядро AO для спека. Любой проект кто-то должен держать на плаву. Без грамотного мэйнтейнмента со временем сдохнет любой дотнет со всеми его кривыми метаданными. :)

Чего не хватает Оберону - жёсткого пиара и бабловых вливаний. Для развития в среде не-энтузиастов.

ZEK

21.08.2013, 19:24

Оберон весь состоит из подпорок недоделанных, в нем напрочь отсуствуют средства которые могли бы заинтересовать не энтузиастов, попробуйте реализуйте вменяемый dependency injection в среде оберона, поломаетесь, придется лезть в компилер и среду исполнения, вот это убогость среды, а язык в отрыве от среды это конь в ваккуме, не говоря уже о отсуствии юнит тестирования

Если средство разработки не позволяют мне убедиться что изменив код процедуры я ничего не поломал, то такое средства идет лесом, ценю личное время (это как энтузиаст)

Oleg N. Cher

21.08.2013, 20:45

И зачем же из этой кучи подпорок уже 25 лет таскают идеи? :) Более того, зачем эта куча вся состоит из хороших идей?

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

Ценность же Оберона (и несомненное его преимущество перед любыми другими средствами) - что эта парадигма может развиваться, разрабатываться и специализироваться под задачи малыми коллективами. И на её основе можно решать нетривиальные задачи (типа программинга для ZX или, например, написания встроенного п/о для космической ракеты) и даже успешно делать бизнес, не полагаясь на сомнительные авторитеты. Быть независимым от авторитетов. От фирм. Иметь свою парадигму, свою идею развития. Однако это не всем нужно, и с этим кто бы спорил. Кому-то надо делать быстрые деньги, кто-то не дорос до понимания ситуации в таком глобальном масштабе, у кого-то вера к мелкомягким (гуглю, эпплу и т.д.) зашкаливает.

В качестве средства для разминки предлагаю попробовать реализовать dependency injection из явы в линукс-ядро. :-D

Vitamin

21.08.2013, 20:58

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

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

Не, мы определённо говорим на разных языках. Ты - сильно прожжённый программер, которого жизнь заставила писать "бизнес-логику", я - почти такой же наивный пацан, как и в 17 лет за первым спектрумом. Не мне тебя судить. Но и не тебе решать кто из нас круче знает матчасть и владеет терминологией.
Т.е. мое использование технологий программирования для хобби- это ересь?
А если я тебе скажу, что в своих программах ты тоже пишешь бизнес-логику. Кем ты себя после этого будешь считать?

С тем же успехом - после примитивной конвертилки из бинаря в текст. Не, ну вот чего ты такой односторонний?
Если бы твоя конвертилка была встроена во все просмотрщики и браузеры, вопросов бы не было, двусторонний ты наш:)

Ты мне что ли предлагаешь xml ручками редактировать? Я это ненавижу.
Всего лишь разрешать конфликты при мердже изменений. Что есть не такая уж частая операция и для которой есть готовые удобные инструменты. Для бинарных форматов это крайне ресурсоемкая (если вообще возможная) операция.

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

Вероятно, стоит отметить что закат C++ не за горами, он слишком большой и тяжёлый, старичок уже совсем.
Да его уже лет 15 хоронят. Что дальше?

Ты без объектной терминологии не объяснишь новичку как писать хело ворлд. Сперва ты загрузишь его что такое класс, потом что такое экземпляр класса (потому что кому-то не понравилось слово "объект"), но так и не сможешь ему втолковать на первый год что такое this.
Очень просто: класс- модуль. И откуда таки экземпляры класса и this в случае исключительно статических функций?

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

---------- Post added at 20:58 ---------- Previous post was at 20:57 ----------

В качестве средства для разминки предлагаю попробовать реализовать dependency injection из явы в линукс-ядро. :-D
facepalm.jpg
Тебе предлагали реализовать DI из оберона в виндовс-ядро? Или таки в пределах языка?

Oleg N. Cher

21.08.2013, 21:09

Я одобряю подход, который лично мне удобен для использования. Остальное- твои домыслы.Ты не просто его одобряешь. Ты зафукиваешь всё, что ему не соответствует.

А как насчет возможной безвозвратной порчи твоего бинарного формата из-за пары поврежденных байт?А как насчёт туда и дорога исходникам ламеров, которые не пользуются бэкапами и контролем версий? :)

Рассинхронизация прекрасно отлавливается контрольными суммами если что.Ага, буду я ручками рассинхронизацию в исходниках править, щаз.

Если бы твоя конвертилка была встроена во все просмотрщики и браузеры, вопросов бы не было, двусторонний ты наш:)Та ты шо! Прям таки во все? :)
Не, ну зачем делать что-то новое, у нас ведь всегда есть такое хорошее и проверенное старое! ;)

Всего лишь разрешать конфликты при мердже изменений. Что есть не такая уж частая операция и для которой есть готовые удобные инструменты. Для бинарных форматов это крайне ресурсоемкая (если вообще возможная) операция.Да всё можно порешать, если искать решалку, а не отмазки не делать этого.

Критерий "нормальной модульности" в студию, пожалста. Ответ "как в обероне" не катит.Ой это долго печатать. Давай уже не сегодня. Или сам найди статьи про правильную модульность, просветишься заодно. :)

Тебе предлагали реализовать DI из оберона в виндовс-ядро? Или таки в пределах языка?Я это понял как разговор двух пацанят в яслях. :) "Я вот такое умное слово знаю, а ты не знаешь" :)

Vitamin

21.08.2013, 21:30

Ты не просто его одобряешь. Ты зафукиваешь всё, что ему не соответствует.
А что все-то? Вообще-то это именно ты лоббируешь один бинарный вариант, зафукивая два моих (чисто текстовый и с отдельной метаинфой).
Кстати о птичках. Что же это за информация там хранится в бинарном виде кроме текста?

А как насчёт туда и дорога исходникам ламеров, которые не пользуются бэкапами и контролем версий?
Лол. Ты сам хоть давно переехал с кучи датированных зипников на систему контроля версий? Вышеупомянутый репозиторий был 7 дней назад создан.

Ага, буду я ручками рассинхронизацию в исходниках править, щаз.
Типа "перетру своим и пох"?

Та ты шо! Прям таки во все?
Не, ну зачем делать что-то новое, у нас ведь всегда есть такое хорошее и проверенное старое!
Да незачем. Делов-то... Полтора человека- это очень мощное комьюнити (наверное. от слова "мощи").

Да всё можно порешать, если искать решалку, а не отмазки не делать этого.
Разумеется. Только сложность решения должна хоть как-то быть соизмерима с результатом. Именно поэтому простые, но удобные средства всегда превалируют над многофункциональными, но неудобными.

Ой это долго печатать. Давай уже не сегодня. Или сам найди статьи про правильную модульность, просветишься заодно.
Слив защитан? Насчет остальных вопросов тоже?

Я это понял как разговор двух пацанят в яслях. "Я вот такое умное слово знаю, а ты не знаешь"
Трех. Двух школьников и одного ясельника:)

ZEK

21.08.2013, 22:58

Я вот такое умное слово знаю, а ты не знаешь
и кто то учит нас модульности...

---------- Post added at 21:51 ---------- Previous post was at 21:45 ----------

бинарном виде кроме текста?
рисунки, раскраска, шрифты, командеры (фича оберонов типа прям в коде можно вызвать процедуру которую только что написал), информация о внедрении контейнеров, можно к примеру в процедуре сделать что бы после объявления переменных был видеоролик о пользе переменных :)

---------- Post added at 21:58 ---------- Previous post was at 21:51 ----------

А между прочим если бы вы DI и юнит тестирование реализовали то качество и простота кода выросли бы. Я забил на Active Oberon буквально через 15 минут после просмотра адовой жести в модулях компилера, такое месиво в учебники писать надо, я знал что его студенты за зачеты писали, но блин не настолько же жестко, и это притом что вирт придумал такую замечательную вещь как COCO/R

И еще Вирт кричит на каждом углу что отладка жесть и для ламерюг (при этом ничего кроме трапа не предоставил), а у самого компилер умеет INT3 ставить после каждой строки сырка и дебаг информацию собирает но никуда не пишет, вот так...

Компилер изучал от бутылки

psb

22.08.2013, 00:52

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

А дифы между .ocf это всё равно что между .exe
вообще-то, диффы между exe и прочими исполняемыми кодами давно существуют. BinDiff вроде называется (могу ошибаться в названии).

Oleg N. Cher

22.08.2013, 01:16

Вообще-то это именно ты лоббируешь один бинарный вариант, зафукивая два моих (чисто текстовый и с отдельной метаинфой).Они не твои, а так сложилось. ;) Более того, я регулярно юзаю текстовые исходники. Почти каждый день, во круто, да?

Кстати о птичках. Что же это за информация там хранится в бинарном виде кроме текста?Ой, это долгая история. Знаешь анекдот про оберонщика и толпу мэйнстримистов? Приходишь на пляжь, а там станки, станки...

Ты сам хоть давно переехал с кучи датированных зипников на систему контроля версий? Вышеупомянутый репозиторий был 7 дней назад создан.Это не мой реп. А гит юзаю давно, хотя бы по XDev'у посмотри.

Более того, а ты готов доверить запорченному на два байта исходнику? А вдруг чисто случайно там число изменилось, и твоя ракета полетит не на марс, а в *опу? :-)

Полтора человека- это очень мощное комьюнити (наверное. от слова "мощи").Так ты бы помощь предложил, а то только самоутверждаешься тут. :) А это кроме тебя никому неинтересно.

Разумеется. Только сложность решения должна хоть как-то быть соизмерима с результатом. Именно поэтому простые, но удобные средства всегда превалируют над многофункциональными, но неудобными.Да-а-а? [обалдело] А я-то считал что визуальная студия вообще распространилась незаслуженно. :-) Плохи её дела!

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

Особенности поддержки концепции модуля в языках Delphi (Object Pascal), Modula-2 и Оберон
http://www.oberon2005.oberoncore.ru/qa261005.html

Динамическая модульность в BlackBox - OberonCore
http://oberoncore.ru/wiki/динамическая_модульность

Модульное программирование: Terra Incognita
http://oberon2005.oberoncore.ru/qa191005.html

Но меня смущает термин dependency injection, который, видимо, настолько умён, что ему даже нету соответствующего термина в лексиконе русских программистов. И я бы тут изложил свою позицию, но она будет для тебя малоинтересна, поэтому я рассмотрю это с позиций Оберон-парадигмы.

Если уж эта сверхрулезная фича нам так кровь из носу нужна и жить без неё мы не сможем никогда:

1) Рассматриваем можно ли её реализовать в виде библиотеки (модуля);

если нет, то:

2) Можно ли её встроить в ядро Оберон-среды исполнения;

если нет, то:

3) Можно ли её безболезненно встроить в сам язык, не нарушит ли она баланс языковых средств, не будет ли смотреться уродливым наростом;

4) И так ли она необходима? Может её можно обобщить или заменить другими языковыми средствами?

5) М.б. стоит её встроить в отдельное языковое расширение (типа Component Pascal или OberonX)?

6) Доказываем, что программировать без этого ВООБЩЕ НЕЛЬЗЯ. И только тогда...

...вспоминаем, что через 50 лет изобретут фишки, которых сейчас нету в наших любимых средствах разработки. Вот повод вырвать волосы-то. ;)

Я всегда думал, что динамическая типизация - это хороший повод передать в функцию двухгигабайтный массив вместо целого числа, которое она ждёт, и никто-никто ещё не доказал мне, что без этого кровь из носу нельзя программировать. Что со мной не так? :)

Уже ничего хорошего услышать про Оберон от тебя и не жду, Vitamin, но вот один вопрос я бы хотел обсудить, если есть что сказать. Это генерация кода с ЯВУ в машкод, сопоставимая по качеству с ручным кодированием на асме, сделанного опытным специалистом, или даже превосходящая эту планку. Назовём условно это сверхкодогенерацией.

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

Здесь есть тонкий вопрос насчёт систем команд процев. Какие они должны выпускаться, чтобы было оптимально под них кодить. Я вижу ажиотаж насчёт arm, но не насчёт Форт- или Java-процессоров. Наверно этому есть хорошее объяснение.

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

Двух школьников и одного ясельника:)Неа, как минимум двух ясельников и одного тока вчера с роддома - и это не я. :)

[тихо шепчет остальным] видите, он узнал умное слово, и теперь для него все ясельники - типично подростковая психология :) И ведь не скажешь что фидошник. Алё, ты меня помнишь по фидо, балбес? :)

---------- Post added at 00:16 ---------- Previous post was at 00:13 ----------

не думаю, что большинству это важно. было бы важно, давно бы форум был пуст.Форум-то конечно не пуст, но мало кто что делает. И по делу пишут мало (ИМХО). Разочарованное поколение. Начали со спека, закончим лечением от интернет-зависимости. ;)

вообще-то, диффы между exe и прочими исполняемыми кодами давно существуют. BinDiff вроде называется (могу ошибаться в названии).Ну да, только к гиту прикрутить. Я это и предполагаю сделать. Только вот практического смысла в таких дифах иногда мало. А кому-то надо чтобы дизасмило и показывало разницу между асм-исходниками, например. Всем не угодишь, не устаю повторять.

psb

22.08.2013, 02:11

Форум-то конечно не пуст, но мало кто что делает. И по делу пишут мало (ИМХО).
во все времена мало что делали вообще-то (по относительным меркам). а прозвучало это так, как будто вы тут один что-то делаете, а остальные вообще здесь лишние;)

А кому-то надо чтобы дизасмило и показывало разницу между асм-исходниками, например.
биндифф это и показывает.

... и никто-никто ещё не доказал мне, что без этого кровь из носу нельзя программировать.
так программировать можно вообще в хекс-редакторе или на брейнфаке. понятно, к чему это или надо разжевать?

ZEK

22.08.2013, 02:58

Но меня смущает термин dependency injection,
гугл по первой ссылке даст на педивики ссылку с наиболее употребляемым переводом

1) Рассматриваем можно ли её реализовать в виде библиотеки (модуля);
В C# Java Python PHP реализовано в виде библиотек (в списке то что юзал)

2) Можно ли её встроить в ядро Оберон-среды исполнения;
Во что превратиться ядро в него встраивать паттерны?

3) Можно ли её безболезненно встроить в сам язык, не нарушит ли она баланс языковых средств, не будет ли смотреться уродливым наростом;
Это не языковая конструкция, это средство созданное на основе сред исполнения многих языков программирования

4) И так ли она необходима? Может её можно обобщить или заменить другими языковыми средствами?
Можно, ручками, но код станет читаться хуже чем без DI с ручным закатом сонца

5) М.б. стоит её встроить в отдельное языковое расширение (типа Component Pascal или OberonX)?
Это средство, оформленное в виде библиотеки, фремеверка, упрощающее жизнь программисту, повышающее чистоту кода, уменьшающее зависимости внутри приложения и тем самым открывающее дорогу безголовняковому unit тестированию и делает приложения более расширяемые и модифицируемые, имхо должно быть как библиотека

Доказываем, что программировать без этого ВООБЩЕ НЕЛЬЗЯ. И только тогда...
Программить можно и без циклов и процедур, только с ними удобнее как бы

---------- Post added at 01:58 ---------- Previous post was at 01:33 ----------

И еще DI не панацея, может для Оберона другие варианты IoC подойдут, DI особенно который через конструктор (для оберона какую нить процедурку дергать в секции инициализации модуля, если туда вызов нельзя програмно запихать) это наиболее удобный и естественный способ дробить приложение на куски

Vitamin

22.08.2013, 07:17

Они не твои, а так сложилось. Более того, я регулярно юзаю текстовые исходники. Почти каждый день, во круто, да?
Они мои ровно настолько, насколько бинарный формат твой. Придирка к словам, в общем.

Более того, а ты готов доверить запорченному на два байта исходнику? А вдруг чисто случайно там число изменилось, и твоя ракета полетит не на марс, а в *опу? :-)
Вот для этих целей как раз и существуют тесты.

Да-а-а? [обалдело] А я-то считал что визуальная студия вообще распространилась незаслуженно. :-) Плохи её дела!
Чисто между нами- я студию тоже недолюбливаю. И использую оттуда только компилятор (изредка отладчик), редактируя код в других редакторах. А делфи так вообще ненавижу. Тем не менее, эти среды позволяют удобно создавать всякие простые поделки. Сложнее задача- удобство резко падает, проще сменить инструмент. Как раз то, что я сказал.

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

Но меня смущает термин dependency injection, который, видимо, настолько умён, что ему даже нету соответствующего термина в лексиконе русских программистов. И я бы тут изложил свою позицию, но она будет для тебя малоинтересна, поэтому я рассмотрю это с позиций Оберон-парадигмы.
Почему нету? "Внедрение зависимости". Как тебе уже сказали- в википедии довольно хорошо это описано.
Как выглядит паттерн "обращение зависимости". Вместо прямого вызова каких-либо функций из кода зовутся функции посредника. А вот этот посредник (точнее, разные его реализации), уже и выполняет деятельность.
Например, ты пишешь выводилку списка файлов. Только если вместо прямого вызова методов библиотеки/winapi/posixapi будешь звать соответствующие методы посредника (обладающего специализированным протоколом, удобным для использования именно этой выводилке), то получится изоляция алгоритма (вывод списка файлов) от способа получения входных данных. И один и тот же кусок кода
у тебя используется и для перечисления файлов в папке и для перечисления файлов в архиве- ему пофиг на разницу если предоставляемый посредник соблюдает установленный протокол обмена.
В общем, полиморфизм во весь рост.
Да, кстати, в обероне есть ООП?

PPC

22.08.2013, 09:11

Да его уже лет 15 хоронят. Что дальше?

Эээ, дорогой Vitamin, тут вы очень мягко ещё сказали. На моей памяти, C++ хоронят аж с года с 91го, с самого страус трупа первого, с x3.169, а то и ранее, когда один cfront был препроцессирующий. Хоронят яростно, иступлённо-фанатично, с рвением и горящими глазами.
Правда, за это время, многие из тех кто хоронили как-бы сами помре, но тихонечко, в уголку. А кое-кто из хоронящих даже реинкарнировался. Microsoft Java, никто не помнит что такое и откуда и куда? ;-)
Синтаксис, семантика, новые выразительные средства, лямбды, мусорщики, насаждение одной определённой memory management policy (будь то COW, reference counting, потом reference linking) как панацеи от всего, прорыв в будущее rapid SW development, кибернетические олигофрены из Rational Rose с их идеями о "программист-это вред" и "последний программист ещё в нашем тысячелетии" (знаком лично) автоимплементацией из сиквенс и стэйт диаграм, Power Builder с кошмарной промежуточной кодогенерацией, пи-коды всех мастей, пост-компилируемый PEF, языки с промоутом смарт поинтеров одного жёсткого типа, сколько всего было...
И где это? APL, Lisp, F, Pascal, Ada (толстая и говорливая женщина), Модула, пи-эли, эйффели, Алголы, Коболы, Сноболы, жабы,языки с обратной польской нотацией типа Форта, ООП-нашествие, фанатичный Никлаус, упёртый Седжвик, проблемно-ориентированный кошмар VLC, скриптовое нашествие, новые волны managed конструкций, упрощения Бэйсика (кухарки, управляющие империями), библиотеки поддержики, размером с Большую Советскую Энциклопедию, где есть всё, кроме того что вам нужно, время контролов (умрут все языки, но контролы будут жить). Они все с нами, конечно. Но как тараканы - пр нишам. Все они в той, или иной мере, пытались ограничить возможности программиста, отгородить его от машины, вогнать в рамки "новых космических парадигм", проверить и уличить "нерадивого". И у всех-одна беда - они были задуманы против программера. А C и плюсы -за программера. Не для программера, а ЗА Программера с Большой буквы. И compile-time полиморфизм, дедукция шаблонов, тайп листы, частичная специализация и лямбды в Cxx.11 не императива, а расширение выразитедьных средств-не более того. И никто не обидится на ваш собственный пролог код, выбранный вариант динамической линковки или лично вами прописанную rtl для какой-то платформы, или small object allocator, выделяющий память по 3 бита на Марсе. Хотите модульность-используйте. Любите ООП -занаследуйтесь до ациклического визитора, или законтейните все контейнеры stl как матрёшка в матрёшку. Проверяйте поинтеры при входе, не проверяйте -делайте как хотите. Хотите корявый дизайн с динамическими апкастами и rtti - да пожалуйста. Хотите разбить весь код на 100500 модулей до уровня строка-на модуль - ради бога. Раздельная компиляция и линкер вам в помошь. Или хотите запихать весь ваш код, включая Nucleus , STL port и SQL ядро в один файл-ваше дело, вам дерзать (только с пространствами имён разберитесь). Хотите за$$ть весь код ассемблерными вставками, и закондитить компиляцию под 100 платфлрм, создать алиас на сегмент кода и модифицировать его как сегмент данных-ради бога.
Нет ребята, С и С++ не вечны, но они погибнут только тогда, когда появится язык предоставляющий программеру БОЛЬШЕ свободы. Свобода-это стимул к совершенствованию, а человек так устроен, что он не может не совершенствовать потому, что он при этом совершенствует себя.
А какой-то одной фичей (православная модульноссть, встроенный мусоропровод) или парадигмой кого, вы удивиить хотите!?
Ну тока что для, кайфа. Сорри за некий флейм, но тема вполне стала его достойна имхо.

Vitamin

22.08.2013, 09:37

Уже ничего хорошего услышать про Оберон от тебя и не жду, Vitamin, но вот один вопрос я бы хотел обсудить, если есть что сказать. Это генерация кода с ЯВУ в машкод, сопоставимая по качеству с ручным кодированием на асме, сделанного опытным специалистом, или даже превосходящая эту планку. Назовём условно это сверхкодогенерацией.
Сферической конь в вакууме.
1) что есть качество кодирования? Четкий формальный критерий пожалста
2) для каких объемов кода меряется качество? Как известно, чем больше выборка, тем она достовернее. Проблема в том, что человек всегда будет отставать от компилятора.

Проблема сверхкодогенерации ведь не решена, а отодвинута сверхмощным железом в долгий, почти вечный ящик. А ведь проблема интересная. И могла бы быть обкатана на спеке и поюзана на других архитектурах, вытесняя нафиг виртуальные машины, интерпретаторы и прочее зло на законно полагающееся для них место - фтопку.
Зачем сужать кругозор? Те проблемы, которые на одних платформах решаются путем невероятных усилий, на других просто не существуют. Это как живой мир- есть размножение, скрещивание, мутации. Выживают лучшие по каким-либо важным показателям. Меняются приоритеты- меняются лучшие.

И ведь не скажешь что фидошник. Алё, ты меня помнишь по фидо, балбес?
Не могу помнить, балда! У меня никогда не было поинта, а число постов через гейт можно пересчитать по пальцам на руке.

---------- Post added at 09:37 ---------- Previous post was at 09:31 ----------

PPC, и мне отсыпьте:)

PPC

22.08.2013, 10:24

[/COLOR]PPC, и мне отсыпьте:)
Аминь! :-)

Oleg N. Cher

23.08.2013, 16:52

Значит за 4 месяца (время внедрения поддержки текстового формата) это полчеловека. Банально не долждался.Говорю тебе ещё раз: поддержка экспорта в текст и импорта из текста в среде ББ, на которой базируется XDev, есть уже давно. И готовые подсистемы поддержки раскраски синтаксиса есть (как минимум 3), хоть и не встроены в базовый дистрибутив, так что моя вся работа была - прикрутить кодировку 1251 (да, знаю-знаю, это заслуживает всяческой критики, а надо UTF-8) и внедрить подсистему для раскраски в сборку XDev, маленько адаптировав выбранную мной готовую подсистему под новое ядро ББ 1.6, под котороге она не была заточена изначально.

Так что если уж перефразировать твоё "на дождался", то как минимум в "не больно-то и хотелось", согласен? ;)

попробуйте реализуйте вменяемый dependency injection в среде оберона, поломаетесь, придется лезть в компилер и среду исполнения, вот это убогость средыЭто гнусная лжа. :-) Не придётся лезть не в среду, ни в компилер. И вот почему.

Дело в том, что средства, достаточные для реализации dependency injection введены в первый Оберон (не только в систему, а в язык) около 25 лет назад, заметьте, когда не было ещё никаких яв с дотнетами. В Си и Паскале их тоже можно достичь, но только статически (путём использования указателей на процедуры/функции) или же средствами вышележащей среды исполнения - такими механизмами как динамические библиотеки, которые не являются частью языков Си и Паскаль, хотя и к Си, и Паскалю (Дельфи) они были прикручены потом навесными средствами; а такая докрутка влияет не самым положительным образом на сбалансированность средств языка и является костылём, который вам уже настолько примелькался, господа, что вы его не замечаете и считаете незаменимым средством в вашей работе.

Оберон весь состоит из подпорок недоделанныхТакое резкое высказывание неплохо бы проаргументировать несколькими примерами. В отношении Си и Паскаля - вот это чистейшего вида подпорки в языке:

extern "C" __declspec(dllexport) error WINAPI roseInit(const HWND hWnd);или:
function RasSetEntryPropertiesW(lpszPhonebook, szEntry: PWideChar; lpbEntry: Pointer): Longint; stdcall; external 'rasapi32.dll' name 'RasSetEntryPropertiesW';
И Дельфи, и Си на сегодняшний день состоят из таких подпорок, но вот Оберон - совсем другое дело. Разумеется, в некоторых реализациях Оберона есть и [stdcall], но это не часть языка, а системное средство, широкое использование которого по всему коду ограничено (и это благо) - его можно использовать в системных модулях для связки с готовыми библиотеками. Но вернёмся к dependency injection. Перво-наперво я перепутал его с code injection который безусловно достижим в Оберон-среде (http://www.youtube.com/watch?v=Pe0ZdzO_urU).

Но после того как нам милостиво объяснили что это такое и мы поняли:

Вместо прямого вызова каких-либо функций из кода зовутся функции посредника. А вот этот посредник (точнее, разные его реализации), уже и выполняет деятельность.
Например, ты пишешь выводилку списка файлов. Только если вместо прямого вызова методов библиотеки/winapi/posixapi будешь звать соответствующие методы посредника (обладающего специализированным протоколом, удобным для использования именно этой выводилке), то получится изоляция алгоритма (вывод списка файлов) от способа получения входных данных. И один и тот же кусок кода
у тебя используется и для перечисления файлов в папке и для перечисления файлов в архиве- ему пофиг на разницу если предоставляемый посредник соблюдает установленный протокол обмена.
В общем, полиморфизм во весь рост.

Это называется "мы придумали велосипед потому что плохо учили матчасть, но зато назвали его умным словом". И заметьте, Оберон, оставляя в чистоте концептуальную сторону вопроса предлагает нам решение, которое не требует многих мегабайт дотнета и явы-рантаймов (плюс всё, что к этому прилагается в виде обязательного лицензирования своей JVM и ласковых рук мс на юзерском горле), а ограничиваясь компактным ядром Оберон-среды исполнения (в ББ оно занимает около 30 кб кода). Оставим за бортом достоинства дотнетов, вместо этого сосредоточимся на их недостатках, которые вовсе не так уж безобидны и преодолимы.

Господа, а вы в курсе, что загрузчик модулей в ББ реализован именно описанным способом? И ему по барабану откуда грузить модуль - из файла .ocf, распаковывать из EXE (реализовано) или же загружать по сети в зашифрованном виде (предусмотрены слоты для расширений подобного рода). Или почему ББ называется расширяемой и компонентной системой?

Ещё пример из ББ. Files это работа с файлами. PackedFiles устроен также, но это работа с пакованными файлами. Переключиться между работой с обычными и пакованными файлами - строчка кода. HostFiles и HostPackedFiles - реализации. Пожалуйста, добавляйте свои собственные HostFilesAtDropBox или HostFilesAtYandexDisk, если угодно.

И ББ реализован так весь. Смотрите Files и HostFiles, Dialog и HostDialog. Вообще подсистема Host - это сплошной dependency injection со всеми его рулезностями, позволяет чуть ли не ОС приложению менять на ходу. Загружать, выгружать и переключать реализации в рантайме, иметь их миллион штук; идеально для плагинов и т.д. Всё - средствами Оберон-среды исполнения без вышележащих механизмов ОС типа динамических библиотек. Но что самое важное - всё достигнуто без привлечения дополнительных концептуальных наслоений в языке. Чтобы этого достичь - пришлось добавить в Оберон не __declspec(dllexport) и stdcall, а более практичные средства проектирования каркасов больших систем - атрибуты ABSTRACT, EMPTY, LIMITED и EXTENSIBLE всё тех же записей, которые и объекты, и структуры. Так из Оберона и получился Компонентный Паскаль.

а язык в отрыве от среды это конь в ваккуме, не говоря уже о отсуствии юнит тестирования
Угу, а ещё травка зеленеет и солнышко блестит. Всмысле, я не спорю. :-)

Если средство разработки не позволяют мне убедиться что изменив код процедуры я ничего не поломал, то такое средства идет лесом, ценю личное время (это как энтузиаст)А тебя как энтузиаста не угнетает тот факт, что твой код помрёт вместе с ms, что не за горами?

Я как энтузиаст лучше буду искать способы независимой деятельности энтузиаста. Сегодня Оберон можно транслировать как в Си и Java, так и в байт-код .NET и JVM. Завтра будут другие платформы. Где дотнет и Java будут реализованы силами третьих лиц. А если нет? Если придумают что-то более другое? Придётся переписывать весь код. А то могу рассказать грустную историю о том как я учился 3 года программить под палмы, а они взяли да и сдохли. А вот Оберон развернётся и там, и заточить все свои разработки будет достойным (и весьма возможным) делом для энтузиастов.

Примеры? Ну хотя бы вот: http://norayr.arnet.am/weblog/2010/02/15/erzahlung-uber-einfach-portieren

И юнит-тестирование не такая уж мудрая штука, чтобы быть несовместимой с Оберонами. Или это повод чтобы переориентировать всю свою разработку под крылышко одной весьма сомнительной фирмы? И доверить ей успех своего бизнеса, своей деятельности и своей жизни. Чувствуете разницу? И я бы ставил вопрос именно так, а не как "вменяемый dependency injection [ | unit-тестирование ] крутая и незаменимая штука, без неё нельзя жить, а её нету в Оберонах". Подумаешь. Придумали как эмулировать одно API средствами другого. Т.е. изобрели эмулятор. :) Воистину нет ничего нового под этим солнцем!

Oleg N. Cher

23.08.2013, 17:02

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

Также я получал письма от людей, которые сделали большие коммерческие проекты на Обероне силами маленьких коллективов. Реализовали поддержку нужных им платформ и фич, взяв за базис систему ETH Oberon. Поскольку проекты их коммерческие - они вовсе не торопятся делиться своими решениями, т.к. затратили на это свои личные средства и ресурсы. Возможно, проблема Оберона ещё и в том, что для него нету мощной поддержки платформы (примерно как AppStore). Но рано или поздно должно появиться стойкое неприятие избыточной сложности. Да, поиск простых решений безусловно требует нетривиального подхода, и сложность такого поиска отнюдь не сопоставима с написанием очередного калькулятора для бизнеса. Но искать такие решения нужно, потому что у нас перед носом который-то на очереди кризис п/о. А знаете как звучит один из базовых тезисов Вирта в отношении современного состояния информатики? "Мощность железа растёт меньшими темпами, чем замедляется софт". И это не голословное высказывание мэтра Вирта, оно весьма подкреплено фактами.

Вам, господа, нужно знать что есть некоторое количество весьма умных людей, которые предпочитают минимальный подход Оберона. То, что их мало не должно вас смущать. Причины этого уже неоднократно анализировались. Оберон сейчас в неблагоприятной конкуренции с другими средствами (ему просто не находится место в умах программистов, оно вытеснено другими средствами), поэтому его развитие сейчас происходит замедленными темпами, поэтому, например, нету юнит-тестирования. Или может быть есть. Я не знаю. Но это вовсе не из позиции, что оно неполезно. Просто не хватает сил потянуть всё сразу. А тут пришёл чел, поковырял среду 15 минут (или попытался открыть бинарь в блокноте) и поставил вечный диагноз. У меня тут книжица лежит "Разработка операционной системы и компилятора. Проект Оберон", выпущенная в ДМК пресс тиражом в 200 экземпляров. Раритет практически. Думаете неинтересная? Да уж поинтереснее сишарпов для чайников за 21 день, поверьте на слово. Какие тут могут быть вопросы по развитию Оберона, если программерское сообщество в массе своей охотно купается в избыточной сложности, ест с неё хлеб, орудует ею и не видит других путей вообще никак. Собственно, есть и подход "Я не верю в простое решение сложных задач. Сложные задачи требуют сложных средств" (Жан Ишбиа, автор языка Ада). И можно поспорить, существует ли вообще простое решение. А кто-то, устав от гонки в никуда, просто уходит из программирования вообще.

А то тут говорили много хороших слов про язык Си. Да, прекрасная затея, пользуемся. Но багрепортим (https://sourceforge.net/p/sdcc/bugs/2205/). Не доверяется как-то продукту, который не был бы вылизан десятками умных голов и сотнями бетатестеров за годы и годы. Где здесь есть ниша для простого подхода? А если надо заточить кодогенерацию под другой проц? Уже надо переписать тысячи строк кода, и снова бетатестирование и прочее. Оберон-компиляторы, как правило, дают не очень хороший код. Их просто не вылизывают до такой степени, это требует лет и лет. Но зато заточить под новый кодогенератор проще. Это не оправдание компиляторов Оберона. Это не повод делать плохие сишные компилеры. Это пример того как, пожертвовав избыточной сложностью, получить одни достоинства за счёт отказа от других. Это повод искать как упростить сам подход к кодогенерации. Например, разработкой оптимизированных под это дело железных процессоров. Чтобы не пришлось по-комсомольски героически решать ненужные задачи. А кто построил плохие процессоры? Дяди, которым надо было делать быстрые деньги. И потом тогда никто не знал как лучше проектировать процессоры. Но теперь ведь знают. Но продолжают городить thumb поверх arm, и закончится это тем самым, до чего дошла архитектура i8086. Т.е. избыточностью, рудиментарностью и т.п. Но прощаем. Арму прощаем, он ещё молод. Оберону прощаем, он всё ещё так мал. Сишарпу не прощаем, ему двигаться почти некуда. Не будет надмножеств сишарпа, как есть C++ и Objective C над Си. Не будет никогда и универсальности. Не будет и энтузиастов, которые возьмутся облагораживать этот язык просто за то, что он хорош. Неподъёмное дело.

Избыточная концептуальная перегруженность (в т.ч. и в языках программирования) воспринимается совершенно с младенческим восторгом. Слышь, во что за штука такая, да! Улёт! Но я могу легко объяснить своей племяннице что такое модуль, но затрудняюсь ей объяснить что такое сборка (коллекция классов), экземпляры классов и прочие This. И это только маленький пример того, как наслоение таких моментов на бедный ум девелопера приводит к появлению клана избранных-очень умных-элитных, куда простым смертным зась, а как второе - к появлению кучи глючащего и странно работающего софта, ошибки в котором скрыты годами и пылью лет. И какие бы решения не предлагала промышленность - чаще они уводят от сути или незавуалированно являются теми же яйцами в профиль, но под другим "фирменным" соусом, т.е. практическое средство конкурентной борьбы за умы. И появляется догма "Нет синтаксиса, удобнее сишного, и C# пророк его...", которая на ура хавается благодарным сообществом из-за новых (хорошо забытых старых) плюшек.

И в то же время в Оберон-среде можно найти аналог (или по крайней мере разработать) любой из фирменных плюшек. Как языковых, так и среды.

Не останавливайтесь на сказанных мной словах, я могу иметь понимание, но быть в затруднении передать его программистам, которые с молоком матери всосали Си [C++, C#, Java, Python и т.д.]-парадигму со всеми её достоинствами и недостатками. И если о достоинствах принято кричать на все углах, то мы с вами как честные люди должны поднять вопрос об их недостатках, не ограничиваясь тёплым и уютным кружком задач, с которых мы едим свой кусок хлебца.

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

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

И даже более того - данная возможность была заложена неодобряемым вами г-ном Виртом в ОС Оберон ~25 лет назад! Ещё задолго до появления таких монстров как .NET и Java.

И еще Вирт кричит на каждом углу что отладка жесть и для ламерюг (при этом ничего кроме трапа не предоставил), а у самого компилер умеет INT3 ставить после каждой строки сырка и дебаг информацию собирает но никуда не пишет, вот так...Вирт просто пытается искать и утверждать новые подходы к отладке, что ему простительно как опытному профессору. Он говорит "я бы пошагово сборщик мусора не отладил". А ты бы отладил? И многопоточные риэлтаймовые программы тоже? С учётом всех взаимовлияний и зависимостей?

А INT3 такие могут быть полезны не только для отладки, но и для многих других применений, например, для профилирования кода.

а прозвучало это так, как будто вы тут один что-то делаете, а остальные вообще здесь лишние;)Может быть я просто хочу бурной и активной публичной коллективной деятельности по облагораживанию Спектрума. ;) Во оптимист, да? :)

P.S. Ответил сегодня сколько успел, буду отвечать позже, если не утону в мессагах.

Vitamin

23.08.2013, 17:21

Так что если уж перефразировать твоё "на дождался", то как минимум в "не больно-то и хотелось", согласен?
Ага. Очевидно, что тебе не очень-то и хотелось, но все же сделал. Нет проблем.

Такое резкое высказывание неплохо бы проаргументировать несколькими примерами. В отношении Си и Паскаля - вот это чистейшего вида подпорки в языке:
А как в оберонах выглядит объявление функции-колбека, который отдается в дебря системы (например, winapi)?

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

Ещё пример из ББ. Files это работа с файлами. PackedFiles устроен также, но это работа с пакованными файлами. Переключиться между работой с обычными и пакованными файлами - строчка кода. HostFiles и HostPackedFiles - реализации. Пожалуйста, добавляйте свои собственные HostFilesAtDropBox или HostFilesAtYandexDisk, если угодно.
У HostFiles/HostPackedFiles есть общее описание интерфейса, которое можно использовать при написании кода, в который позже можно передать ссылку на конкретную реализацию? Или переключение делается сменой подключаемого модуля на этапе сборки?

Почитал статьи на тему модульности. Абсолютно непонятно чем обероновская модульность лучше оной в яве, например.
В С/С++ как языках более низкого уровня нежели оберон, модульность слабее, но все плюшки прекрасно реализуются. И плагинизация и динамическое подключение и т.п.

Oleg N. Cher

23.08.2013, 19:16

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

А как в оберонах выглядит объявление функции-колбека, который отдается в дебря системы (например, winapi)?Так же как и объявление обычной функции. Потом можно присвоить эту функцию указателю на функцию того же типа и передать куда угодно, или, если это метод, передать ссылку на объект, или же взять прямо низкоуровневый адрес использованием SYSTEM.ADR(Fn)

Пруф на обязательное лицензирование JVM пожалста.Это ты сам ищи, я в яве не контингент, просто краем уха слышал.

У HostFiles/HostPackedFiles есть общее описание интерфейса, которое можно использовать при написании кода, в который позже можно передать ссылку на конкретную реализацию?Так можно. Интерфейс описан в Files. HostFiles - это одна из реализаций, которая вставлена в слот как дефолтная.

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

Почитал статьи на тему модульности. Абсолютно непонятно чем обероновская модульность лучше оной в яве, например. В С/С++ как языках более низкого уровня нежели оберон, модульность слабее, но все плюшки прекрасно реализуются. И плагинизация и динамическое подключение и т.п.Да, но какими средствами? И потом, ты давно багрепортил баги в багтрекер SDCC? Я - недавно. Значит опять скатываемся к хорошо вылизанному продукту десятка лет и сотен тысяч баксов? Который будет развиваться именно так, как надо _им_, или даже не развиваться, а "развиваться". Кроме того, что в Си слабее модульность, там ещё и приходится пользоваться средствами ОС, плодя непереносимости или же костыли на подпорках с макропроцессором. Если говорить о Java, то там модульность через призму ООП, что сбивает с толку и заставляет вырезать аппендикс через гланды.

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

---------- Post added at 18:16 ---------- Previous post was at 17:24 ----------

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

И того же понимания хотелось бы в ответ.

Vitamin

23.08.2013, 19:28

Так же как и объявление обычной функции. Потом можно присвоить эту функцию указателю на функцию того же типа и передать куда угодно, или, если это метод, передать ссылку на объект, или же взять прямо низкоуровневый адрес использованием SYSTEM.ADR(Fn)
А как быть с разными стандартами на передачу параметров/очистку стека (то, для чего нужны всякие там stdcall и прочая)?

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

Так можно. Интерфейс описан в Files. HostFiles - это одна из реализаций, которая вставлена в слот как дефолтная.
Т.е. можно ли писать чтото вроде:
procedure MyFunc(files : Files)
{
files.List();
...
}

И в одной и той же программе вызвать
MyFunc(HostFiles);
и
MyFunc(PackedFiles);
?

Да, но какими средствами? И потом, ты давно багрепортил баги в багтрекер SDCC? Я - недавно. Значит опять скатываемся к хорошо вылизанному продукту десятка лет и сотен тысяч баксов? Который будет развиваться именно так, как надо _им_, или даже не развиваться, а "развиваться". Кроме того, что в Си слабее модульность, там ещё и приходится пользоваться средствами ОС, плодя непереносимости или же костыли на подпорках с макропроцессором.
Я же сразу сказал- С/С++ находится на более низком уровне, нежели оберон. А это значит может делать все, что могут языки более высокого уровня, но многословнее. Равно как и на ассемблере можно тоже сделать все, что на С/С++, но еще многословнее.

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

А мне просто интересно все, что касается программирования.

Oleg N. Cher

23.08.2013, 19:47

Глубокоуважаемые вагоновожатые господа сишники, хочу испросить вашего совета.

У меня в подсистеме XDev/WinDev (https://github.com/Oleg-N-Cher/BB-XDev/tree/master/WinDev) есть модуль Console, и в его сишной реализации XDev/WinDev/Lib/Console.c используется такой код:

#if defined(WIN32) || defined(_WIN32)
# include <windows.h>
#endif

#include "Console.h"
#include "SYSTEM.h"
Он прекрасно компилируется, но если его изменить на:

#include "SYSTEM.h"
#include "Console.h"

#if defined(WIN32) || defined(_WIN32)
# include <windows.h>
#endifначинаются самые непонятные глюки:

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

Компилить лучше всего конечно в самой XDev, для этого качаем её из репа (https://github.com/Oleg-N-Cher/BB-XDev/archive/master.zip), запускаем BlackBox.exe и открываем WinDev/Lib/Mod/Console.Mod (выберем тип файла Oberon module (*.Mod)) и компилим F11. Как всё это устроено - даёт понять батник WinDev/Lib/Bin/compile.bat, вызываемый с параметром-имя файла:

\XDev\WinDev\Lib\Bin\> compile.bat Console

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

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

Спасибо!

P.S. Вообще-то работает и без этого, но блесните мудростью, просветите народ, в чём тут пень. В целях повышения всеобщей образованности, тыкскыть.

ZEK

23.08.2013, 21:41

Это гнусная лжа. :-) Не придётся лезть не в среду, ни в компилер. И вот почему.
Еще раз читаем что такое IoC/DI до просветления

каким образом по запрашиваемому контракту найдет необходимый модуль (множество модулей удовлетворяющих контракту), иницициализирует переменные ссылками итд, т.е. как будет работать Service locator (паттерн такой)

Это называется "мы придумали велосипед потому что плохо учили матчасть, но зато назвали его умным словом"
это ты конкретную реализацию примера зацепился

Я к примеру помню как в бутылке мега модно расширяется менюха, в ББ не помню как (вроде как тоже таким караличем), надо ручками в конфиг файл лезть и прописывать информацию о расположении, наименовании и обработчике менюхи

А так по нормальному вы объявляли бы к примеру какой нить интерфейс для работы менюшек, среда при запуске сканировала окружение (Service Locator) находила все модули в которых надо смыкнуть функцию для получения описания пункта меню и обработчика, заполнила бы ссылками на эти процедуры какую нить коллекцию потребителя этих контрактов (иньекция зависимостей) и без каких либо напрягов, к примеру добавил новый модуль, у которого есть реализация контракта для добавления менюхи, система его автоматом подхватит

И вот тут самое главное: не будет возникать рассинхронизации между метаданными менюхи и кодом, а так код надо поправить, потом в ресурсы лезть и прописывать там менюху, а у вас в результате рефакторинга выкинул один обработчик за ненадобностью, другому дали имя более вменяемое и все, свалилось все

что твой код помрёт вместе с ms, что не за горами?
код на дельфи не помер со смерью борланд, до сих пор могу спокойно откомпилить
Темболее средства тестирования есть далеко не только от MS, куча вариантов свободных Unit тестирование это не кнопка от MS, а методолгия придуманная одними энтузиастами и принятая на вооружение в том числе и проф. разработчиками

И по поводу дров на С#
ATA http://cosmos.codeplex.com/SourceControl/latest#source/Cosmos/Cosmos.Hardware/ATA.cs
PCI Bus http://cosmos.codeplex.com/SourceControl/latest#source/Cosmos/Cosmos.Hardware/PCIBus.cs

Vitamin

23.08.2013, 22:59

А то в Обероне я привык перечислять в секции импорта модули в любом порядке, и считаю это удобным.
Это препроцессор фигней страдает. Можно посмотреть что на вход компилятора попадает.

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

PPC

23.08.2013, 23:11

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

02.09.2013, 23:09

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

Oleg N. Cher

23.12.2013, 22:58

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

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

Oleg N. Cher

24.12.2013, 00:31

P.S.

Резон появления и смысл среды XDev (http://zx.oberon2.ru/forum/viewtopic.php?f=25&t=168)

ZXDev + TR-DOS (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=139)

Компактная вещественная арифметика для Спектрума (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=141)

Демо-версия рогалика для ZX на Обероне. (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=125&start=10#p657) С критикой, пожалуйста, не ко мне. Неинтересно.

Прогресс разработки порта игры “Dark Woods” (http://zx.oberon2.ru/forum/viewtopic.php?f=5&t=4#p845)

Oleg N. Cher

11.05.2014, 02:56

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

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

Oleg N. Cher

14.05.2014, 05:15

Попутно ещё хочу рассказать г-ну introspec'у, что в его родном Лондоне функционирует фирма Padded Cell Software Ltd, PO Box 1880, London NW6 1BQ, United Kingdom (http://www.paddedcell.com), которая активно использует язык Оберон для разработки программного обеспечения повышенной надёжности для своих клиентов, среди которых — государственные организации Англии. Об этом говорит Пол Рид в своих статьях Building Your Own Tools - An Oberon Industrial Case-Study (http://link.springer.com/chapter/10.1007/10722581_23) и An Oberon Linker for an Imperfect World – More Notes on Building Your Own Tools (http://link.springer.com/chapter/10.1007/978-3-540-45213-3_28)

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

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 (http://www.worldofspectrum.org/infoseekid.cgi?id=0012459)? А то я смотрю, тут библиотеки есть. Можно на ZXDev портировать.

Reobne

14.05.2014, 06:45

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

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

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" (http://www.inr.ac.ru/~info21/qna.htm)
ЧаВо по Оберону от oberoncore.ru (http://oberoncore.ru/faq/start)

Oleg N. Cher

14.05.2014, 06:50

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

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

introspec

14.05.2014, 13:57

Sergey

15.05.2014, 04:07

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

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

Oleg N. Cher

16.05.2014, 08:37

Спасибо, посмеялся.Не знаю что там с почтовым ящиком, возможно, фирма, получающая государственное финансирование, не желает светить свой адрес. У таких фирм совсем другое отношение и к рекламе. Но я точно знаю, что софт, написанный на Обероне, находится в активной эксплуатации в гос. структурах Англии. И его поддержкой занимается фирма Padded Cell Software Ltd. Мне об этом написал Рид.

Dear Mr. Cher,

Thank you for your request. Unfortunately we have no plans to release the
compiler covered by my papers under an open source licence. It's still a
tool used commercially on an everyday basis by us and some of our clients;
it's a non-standard implementation of Oberon; and there are not currently
enough resources available to manage an effective publication to our
satisfaction.

The papers, which themselves entailed a considerable amount of work to get
to a usable and helpful state, were intended to provide aid and
encouragement to people thinking of taking the step I made, from compiler
user to compiler user and maintainer. This is what I would like to see
more of, not a simple copy of what we did.

Prof. Wirth does the real work, however, in keeping the compilers simple
enough to be understood in their entirety. Open source projects do not
have a very good track record in this direction.

Currently, I am currently helping revise the Project Oberon book and
system, using an FPGA to implement Wirth's RISC processor from the
Compiler Construction book (rather than the defunct NS32032). This
project, although underway for some time, has no firm publication date yet
because there is still much work to do. But I hope it will provide an
alternative route to some of your desires below.

For some more information, please see our talk at last year's 25th
Anniversary Oberon Day celebration:

http://www.oberonday2011.ethz.ch/

Best regards,
Paul Reed

Сам же Пол Рид по сей день активно занимается научной деятельностью и Оберон-технологиями. В этом можно убедиться, почитав рассылки ETH (https://lists.inf.ethz.ch/mailman/listinfo).

introspec

16.05.2014, 09:09

Во упырюга. Кола осинового на тебя нет, засланец. :)Oleg, а не нужно поминать меня в буквально каждом вашем посте, глядишь, и полегчает. Не я к вам сюда в тред пришёл, а вы меня призвали, в довольно гнусной форме, кстати. Я понимаю, что у Оберона на спектруме осталась всего одна большая проблема - Враг в Лондоне, но попробуйте всё же немного сдерживаться с тоном ваших остроумных высказываний, тем более что по сути вам возразить, очевидно, нечего.

denpopov

16.05.2014, 09:55

что интересно, так очевидные вопросы пропали...

Oleg N. Cher

16.05.2014, 14:21

2. При нажатии F11 возникла ошибка "command error: object OfrontOPM.MaxStruct inconsistently imported from OfrontOPC" Что это?Данную ошибку в репозитории я уже починил, а заключалась она в том, что я увеличил константу - максимальную длину идентификатора, но не пересобрал модули, которые зависели от этой константы. BlackBox такую ошибку легко определяет и очень часто это помогает экономить время.

Как именно происходит разработка XDev.

Тот вариант, который скачивается из ветки master, - не тот же, который крутится у меня на машине. Бывает так, что я обкатываю какую-то фишку, но не заливаю её пока не убежусь, что всё работает стабильно.

Так что повторение именно этой ошибки маловероятно.

Когда именно планируется выпуск релиза XDev. Меня уже критиковали на WoS (да и здесь по-моему тоже) за "большую кучу файлов", бОльшая половина из которых действительно не нужна для разработки под Спектрум. Поэтому в планах есть выпуск XDevLite. Это будет минималистическое IDE + к нему в дополнение подсистемы для разработки под разные платформы: ZXDev, WinDev, LinDev, JmeDev. Возможно, ещё какие-то, например ZXEvoDev или NesDev - если сумеем освоить это направление. Я хотел бы покодить для NES, но не знаю её асма.

Вопрос сроков релиза XDevLite + ZXDev упирается в незаконченную утилиту MakeZX для создания TAP'ок, которую я планировал включить в первую версию. И ещё в одну проблемку с подсистемой раскраски синтаксиса. А также в желающих поучаствовать в бета-тестинге. Вернее, в их практически полном отсутствии. Окончательный размер всего набора утилит планируется такой (в zip архиве):

XDevLite = ~1,5 Mb
ZXDev = ~3,5 Mb

Никаких особенных фич, помимо уже реализованных, не планируется. Так что с репа доступна практически первая версия, просто без глянца.

Oleg N. Cher

16.05.2014, 21:15

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

Люди, которые предпочитают "не маргинальные" средства разработки, вообще не воспринимают их недостатков, т.к. ослеплены их достоинствами. С ними безполезно говорить о том, что C# плох для риэлтайма или микроконтроллеров, что это язык одной фирмы и его будущее зависит от этой фирмы. И ещё кучу всего. Точно также в штыки они воспринимают достоинства других средств, с которыми не планируют работать.

И ты, introspec, может и очень созидательная личность и дома своим детям самолично варишь молочную кашку, чтобы покормить их из ложечки. Но в отношении моего детища (ZXDev) ты выступил разрушителем, хотя может и нечаянно. А кому это понравится - когда его дитятю втаптывают в грязь, причём не очень-то и заслуженно.

А фраза про упырюгу предназначалась крыске. И когда это он успел удалить свою мессагу. Я щас ту тогда тоже отредактирую.

Alex Rider

16.05.2014, 22:40

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

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

Люди, которые предпочитают "не маргинальные" средства разработки, вообще не воспринимают их недостатков, т.к. ослеплены их достоинствами. С ними безполезно говорить о том, что C# плох для риэлтайма или микроконтроллеров, что это язык одной фирмы и его будущее зависит от этой фирмы. И ещё кучу всего. Точно также в штыки они воспринимают достоинства других средств, с которыми не планируют работать.
Ну да, тут, кончено,все подряд только и делают, что сравнивают Spectrum Basic с C#, ассемблер Z80 и современного PIC и выбирают на чем из этого завтра начать коммерческий стартап или новый проект на работе :) Это была ирония, если что.

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

hobot

16.05.2014, 23:02

Олег, задумайся еще раз о способе подачи информации здесь.
Вот тут я пожалуй скажу, что с этим то проблем нет.
Разве Олег не свою тему создал внутри "Программирование" ?
Это его авторская тема, мне (к примеру) его посты и не только его очень даже
интересно почитать, ПКМ на форуме есть что почитать в принципе
(свежий воздух как бы + не хилый такой вызов для завуалированного сайбернетика
где-то глубоко внутри меня), пока в разделе ДВК\УК-НЦ и эмуляторов затишье (но это временно).
Плохо то, что некоторые товарищи не могут мимо пройти,
молча в смысле. Что то им мешает. (вот не дождётесь перехода на личности!).
Хорошо то, что есть люди кому интересно и которые тоже пишут
свои мысли.

У меня слегка не по теме вопрос, просто связан с Модулой2, нет ли среди участников тех кто работал\пользовался компилятором языка на ЭВМ ДВК? Нужна помощь пока официального описания нет, по правильной настройке и использованию компилятора? Советы какие нибудь и примеры простых программ - всё вместе )
http://zx-pk.ru/showthread.php?t=20444 - pascal+macro11
http://zx-pk.ru/showthread.php?t=22278 - modula2

Спасибо.
:wink:

Oleg N. Cher

17.05.2014, 05:01

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

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

В-третьих, я могу даже убраться отсюда, раз так уж сильно мешаю и выбиваюсь из общей струи. Всегда есть форум zx.oberon2.ru/forum (http://zx.oberon2.ru/forum). А данный форум будет ещё более кошерным для тебя и твоих сотоварищей.

Kakos_nonos

18.05.2014, 13:37

Скачал среду, изучаю. Протестуещие пусть идет лесом, хорошая вешь. Это ж практически паскаль.

denpopov

18.05.2014, 17:04

Скачал среду, изучаю. Протестуещие пусть идет лесом,
квартира готова?:)

Andrew771

19.05.2014, 10:24

Сообщение от Reobne
2. При нажатии F11 возникла ошибка "command error: object OfrontOPM.MaxStruct inconsistently imported from OfrontOPC" Что это?
Данную ошибку в репозитории я уже починил, а заключалась она в том, что я увеличил константу - максимальную длину идентификатора, но не пересобрал модули, которые зависели от этой константы. BlackBox такую ошибку легко определяет и очень часто это помогает экономить время.
Я тоже пробовал ZXDev на днях, но эта же ошибка выскочила. Опять буду пробовать.

---------- Post added at 10:24 ---------- Previous post was at 10:23 ----------

Если разберусь, то библиотеки на асме могу потом делать потихоньку

Kakos_nonos

19.05.2014, 10:32

квартира готова?
Одну уже TS-Labs'у подарил, сейчас в поиске другой. Кстати, если скрестить ТСконфу и эту среду, думаю крутотень выйдет. Отрисовкой спрайтов будет не тормознутый код занимться а железо, а логику игры в оберон (или модулу, она мне как-то больше приглянулас)

Andrew771

19.05.2014, 11:20

Если разберусь, то библиотеки на асме могу потом делать потихоньку
Вопрос пока, как будут передаваться параметры процедур из Оберона в асм (например, вывод нужного спрайта в нужной позиции). Но возможно решится сам, если разберусь со средой.

Alex Rider

19.05.2014, 11:37

Вопрос пока, как будут передаваться параметры процедур из Оберона в асм
ZXDev использует SDCC как прослойку при компиляции, а в SDCC аргументы функций лежат на стеке после адреса возврата.

Andrew771

19.05.2014, 12:23

Во, наконец получилось скомпилить файл ASCII.mod.

Исходный Оберон:

MODULE ASCII; (*$MAIN*)
IMPORT Console;
VAR
n: INTEGER;
BEGIN
FOR n := 32 TO 127 DO Console.WriteCh(CHR(n)) END;
END ASCII.

Скомпилировалось в:

.area _GSINIT
;--------------------------------------------------------
; Home
;--------------------------------------------------------
.area _HOME
.area _HOME
;--------------------------------------------------------
; code
;--------------------------------------------------------
.area _CODE
;ASCII.c:14: export main(int argc, char **argv)
; ---------------------------------
; Function main
; ---------------------------------
_main_start::
_main:
;ASCII.c:20: ASCII_n = 32;
ld iy,#_ASCII_n
ld 0 (iy),#0x20
ld iy,#_ASCII_n
ld 1 (iy),#0x00
;ASCII.c:21: while (ASCII_n <= 127) {
00101$:
ld a,#0x7F
ld iy,#_ASCII_n
cp a, 0 (iy)
ld a,#0x00
ld iy,#_ASCII_n
sbc a, 1 (iy)
jp PO, 00114$
xor a, #0x80
00114$:
jp M,00103$
;ASCII.c:22: Console_WriteCh((CHAR)ASCII_n);
ld iy,#_ASCII_n
ld h,0 (iy)
push hl
inc sp
call _Console_WriteCh_COMPACT
inc sp
;ASCII.c:23: ASCII_n += 1;
ld iy,#_ASCII_n
inc 0 (iy)
jr NZ,00101$
ld iy,#_ASCII_n
inc 1 (iy)
jr 00101$
00103$:
;ASCII.c:25: __FINI;
ld hl,#0x0000
ret
_main_end::
.area _CODE
.area _INITIALIZER
.area _CABS (ABS)

Это оптимально?
И что за строки типа .area _CODE?
Это не будет работать на асме.

denpopov

19.05.2014, 12:25

cp a, 0 (iy)
что это? оО

Blade

19.05.2014, 12:42

Это оптимально?

Нет.

jerri

19.05.2014, 13:28

что это? оО

cp (iy+0)

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

я бы использовал

cp (hl)

но код портировали с 6502 потому и IX и IY

ну и то что он использует WORD вместо CHAR тоже неправильно.

Andrew771

19.05.2014, 13:34

ну и смысл всё это использовать?

---------- Post added at 13:34 ---------- Previous post was at 13:32 ----------

или там где-то опять настройками sdcc играться? :)

Blade

19.05.2014, 13:43

Ну да SDCC дает не самый оптимальный код. мягко говоря.

SDCC может и такой код выдать:

;main.c:15: for(n=32;n<128;n++)
ld h,#0x20
00106$:
;main.c:16: Console_WriteCh(n);
push hl
push hl
inc sp
call _Console_WriteCh
inc sp
pop hl
;main.c:15: for(n=32;n<128;n++)
inc h
ld a,h
sub a, #0x80
jr C,00106$

Andrew771

19.05.2014, 13:44

SDCC может и такой код выдать
это где опции крутить?

Oleg N. Cher

19.05.2014, 13:49

У меня получилось так:

Исходный Оберон:

MODULE ASCII; (*$MAIN*)
IMPORT Console;
VAR
n: SHORTINT;
BEGIN
FOR n := 32 TO 127 DO Console.WriteCh(CHR(n)) END;
END ASCII.

Скомпилировалось в:

_main_start::
_main:
push ix
;ASCII.c:20: ASCII_n = 32;
ld hl,#_ASCII_n + 0
ld (hl), #0x20
;ASCII.c:22: ASCII__for__1 = (ASCII__for__1 - ASCII_n) + 1;
ld hl,#_ASCII__for__1 + 0
ld (hl), #0x60
;ASCII.c:23: do {
00101$:
;ASCII.c:24: Console_WriteCh((CHAR)ASCII_n);
ld a,(#_ASCII_n + 0)
push af
inc sp
call _Console_WriteCh_ROM
inc sp
;ASCII.c:25: ASCII_n += 1;
ld hl, #_ASCII_n+0
inc (hl)
;ASCII.c:26: ASCII__for__1 -= 1;
ld hl, #_ASCII__for__1+0
dec (hl)
;ASCII.c:27: } while (!(ASCII__for__1 == 0));
ld a,(#_ASCII__for__1 + 0)
or a, a
jr NZ,00101$
;ASCII.c:28: __FINI;
ld hl,#0x0000
pop ix
ret
_main_end::

Немножечко "догнал" опцией --oldralloc, немножечко можно попробовать реализацией FOR от Saferoll (впрочем, прироста именно в этом случае не даёт). Немножечко отказом от OUTPUT_COMPACT в пользу OUTPUT_ROM. Итоговая TAP'ка весит 198 байт.

И что за строки типа .area _CODE?Директива секции кода, встроенная в SDCC-асм.

ну и смысл всё это использовать?Сделай лучше. Потихоньку. ;)

(или модулу, она мне как-то больше приглянулас)Чем планируем транслировать Модулу в код Z80?

Andrew771

19.05.2014, 13:55

Как мне избавиться от индексного регистра iy и скомпилировать, как у тебя, с регистром hl :)

---------- Post added at 13:55 ---------- Previous post was at 13:54 ----------

и чтобы бредятина типа .area сама выкидывалась

Oleg N. Cher

19.05.2014, 14:02

Жосткая оптимизация - 192 байта. ;)

MODULE ASCII; (*$MAIN*)
IMPORT Console;
VAR
n: SHORTINT;
BEGIN
n := 3*32; REPEAT Console.WriteCh(CHR(3*32-n+32)); DEC(n) UNTIL n = 0;
END ASCII.Можно и ещё меньше конечно.

---------- Post added at 13:02 ---------- Previous post was at 12:57 ----------

Как мне избавиться от индексного регистра iy и скомпилировать, как у тебя, с регистром hl :)Сам не пойму, то с hl компилит, то с iy. Попробуй поиграться с опцией --reserve-regs-iy

--reserve-regs-iy This option tells the compiler that it is not allowed to use register pair iy.The option can be useful for systems where iy is reserved for the OS.

However in general, the use of ix may depend on --reserve-regs-iy: sdcc should try to generate good code. And sdcc might decide whether using ix is a good idea depending on whether iy is available: When there are few accesses to the stack, sdcc might decide to not use ix, and instead access the stack using hl and iy only. But if iy is not available, sdcc will be more likely to decide to use ix for accessing the stack. The option for forbidding the use of ix is --fomit-frame-pointer (which in your case might be a usable workaround for the issue).

и чтобы бредятина типа .area сама выкидываласьДа не надо её выкидывать, она не мешает. Это асм такой. Разве только прикрутить к SDCC другой асм, но смысл?

Kakos_nonos

19.05.2014, 14:04

а .Mod файлы в архиве это не модула?

Oleg N. Cher

19.05.2014, 14:06

Нет, это тоже Оберон. Придумаем как транслировать Модулу - будет поддержана и Модула.

jerri

19.05.2014, 14:20

SDCC может и такой код выдать:

;main.c:15: for(n=32;n<128;n++)
ld h,#0x20
00106$:
;main.c:16: Console_WriteCh(n);
push hl
push hl
inc sp
call _Console_WriteCh
inc sp
pop hl
;main.c:15: for(n=32;n<128;n++)
inc h
ld a,h
sub a, #0x80
jr C,00106$

Круто, чо.
весь вопрос КАК?

---------- Post added at 14:20 ---------- Previous post was at 14:13 ----------

У меня получилось так:

Исходный Оберон:

MODULE ASCII; (*$MAIN*)
IMPORT Console;
VAR
n: SHORTINT;
BEGIN
FOR n := 32 TO 127 DO Console.WriteCh(CHR(n)) END;
END ASCII.

объявление переменной вижу я :)

denpopov

19.05.2014, 14:29

чухня полная. лучше я сам напишу, чем этот код причесывать.

jerri

19.05.2014, 14:35

denpopov, его не надо причесывать, его надо использовать.
тут сам принцип - не писать на асме а программировать на ЯВУ.
но конечно для начала надо настройки выставить чтобы SDCC создавало что-то приемлемое. раз уж автор за этим не следил.

Oleg N. Cher

19.05.2014, 14:44

А ты уверен, крыска, что они есть - те настройки SDCC, качество кода с которыми тебе бы понравилось?

В любом случае, идеи по кодогенерации можно и нужно двигать в SDCC. Этот модуль выиграл бы и от модели передачи параметров fastcall (в регистре/ах), и оттого, что не сохранял бы на стеке ix, и даже если бы не возвращал 0 в hl при выходе. Но придраться всегда будет к чему, я вас уверяю. Идеал почти недостижим.

jerri

19.05.2014, 15:00

А ты уверен, крыска, что они есть - те настройки SDCC, качество кода с которыми тебе бы понравилось?

А ты помолчи, дурачок, не с тобой разговариваю.

В любом случае, идеи по кодогенерации можно и нужно двигать в SDCC. Этот модуль выиграл бы и от модели передачи параметров fastcall (в регистре/ах), и оттого, что не сохранял бы на стеке ix, и даже если бы не возвращал 0 в hl при выходе. Но придраться всегда будет к чему, я вас уверяю. Идеал почти недостижим.

ага за исключением пары нюансов.
1 скорость получаемого кода должна быть приемлемой, а не минимальной.
2 http://zx.pk.ru/showthread.php?t=21895 сколько еще таких "оптимизаций" зарыто в кодогенераторе?

Oleg N. Cher

19.05.2014, 15:03

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

Скорость не страдает! Размер выигрывает! 185 байт, кто меньше?

_main_start::
_main:
;ASCII.c:20: ASCII_n = 96;
ld hl,#_ASCII_n + 0
ld (hl), #0x60
;ASCII.c:21: do {
00101$:
;ASCII.c:22: Console_WriteCh((CHAR)((96 - ASCII_n) + 32));
ld hl,#_ASCII_n
ld a,#0x80
sub a, (hl)
push af
inc sp
call _Console_WriteCh_ROM
inc sp
;ASCII.c:23: ASCII_n -= 1;
ld iy,#_ASCII_n
dec 0 (iy)
;ASCII.c:24: } while (!(ASCII_n == 0));
ld a,(#_ASCII_n + 0)
or a, a
jr NZ,00101$
;ASCII.c:25: __FINI;
ret
_main_end::( что менял? добавил опцию --no-std-crt0, убрал в конце return 0 в пользу return; --oldralloc убрал тоже - не всегда помогает )

Итого: бинарь ASCII.bin = 47 байт. И это, заметьте, для тех, кто может не знать асма. Воистину: ZXDev - кладезь неисчерпаемых возможностей. :)

jerri

19.05.2014, 15:11

Oleg N. Cher

19.05.2014, 15:22

Да конечно можно, но не вручную же этим заниматься? Пусть SDCC сам это делает.

Такие идеи надо двигать Филиппу Краузе. Мне порой жаль, что нельзя взять маленький понятный участок оптимизации и дописать его самому. В идеале надо бы разработать скриптовый язык, на котором можно было бы описывать разные случаи оптимизации. Но это конечно сложновато.

Да, кстати, я давно не обновлял версию SDCC в ZXDev. Остановился на той, которая показалась мне наиболее стабильной - она собирает "Дурака" и "Dash" без ошибок, а там довольно много кода.

Может более новая версия SDCC даст код получше?

jerri

19.05.2014, 15:28

Да конечно можно, но не вручную же этим заниматься? Пусть SDCC сам это делает.

Можно ли вообще запретить компилятору использование индексных регистров?

просто даже вот этот кусок

ld a,#0x7F
ld iy,#_ASCII_n
cp a, 0 (iy)
ld a,#0x00
ld iy,#_ASCII_n
sbc a, 1 (iy)
jp PO, 00114$

без использования IY смотрелся бы лучше.

Такие идеи надо двигать Филиппу Краузе. Мне порой жаль, что нельзя взять маленький понятный участок оптимизации и дописать его самому. В идеале надо бы разработать скриптовый язык, на котором можно было бы описывать разные случаи оптимизации. Но это конечно сложновато.

Да, кстати, я давно не обновлял версию SDCC в ZXDev. Остановился на той, которая показалась мне наиболее стабильной - она собирает "Дурака" и "Dash" без ошибок, а там довольно много кода.
Может более новая версия SDCC даст код получше?

не факт http://zx.pk.ru/showthread.php?t=21895
но кто знает.

denpopov

19.05.2014, 15:32

тут сам принцип - не писать на асме а программировать на ЯВУ.
я уж забыл, какой компилятор Си брал, но получил на выходе такое, что волосы дыбом встали. асм - ближе и роднее:)

Oleg N. Cher

19.05.2014, 15:34

Можно ли вообще запретить компилятору использование индексных регистров?iy - можно. ix, насколько я знаю, нет.

просто даже вот этот кусок без использования IY смотрелся бы лучше.Согласен. Но запрещение использования iy в данном случае не даёт выигрыша (по размеру кода).

В общем-то можно долго говорить о том, что SDCC даёт код похуже, чем ручное кодирование программистом. Это так, ничего не поделаешь.

jerri

19.05.2014, 15:43

я уж забыл, какой компилятор Си брал, но получил на выходе такое, что волосы дыбом встали. асм - ближе и роднее:)

IAR как говорят выдает приемлемый код, но он платный и очень дорогой.

---------- Post added at 15:43 ---------- Previous post was at 15:38 ----------

http://zx.pk.ru/showthread.php?t=1408 вот тут кстати еще обсуждали С

haywire

19.05.2014, 15:47

IAR выдаёт код компактнее в 2-3 раза подделок типа SDCC, но ветка для Z80 не развивается и купить его невозможно. И 170 Евро c девбордой- это для такого рода продуктов практически бесплатно.

Andrew771

19.05.2014, 16:15

Vitamin проделал как-то большую работу, протестировал несколько компиляторов: http://zx.pk.ru/showthread.php?t=4110&page=8

Oleg N. Cher

19.05.2014, 19:02

IAR выдаёт код компактнее в 2-3 раза подделок типа SDCCЕсть надежда, что когда-нибудь SDCC достигнет очень высокого уровня оптимизации, и тогда юзеры ZXDev смогут воспользоваться этими плодами. Кстати, IAR C к ZXDev тоже можно прицепить.

Библиотеки, которые мы можем разработать, также можно будет использовать и с IAR, и с SDCC, и с ZXDev. Есть смысл сосредоточиться на библиотеках, а не спорить в который раз какой Си-компилер лучше.

Принимаются идеи насчёт библиотек. Принимается код. Также буду рад пообщаться голосом с товарищами из Украины про ZXDev да и вообще про Спек. Скидывайте в ЛС № мобильного. Skype нет по техническим причинам. :)

Eltaron

19.05.2014, 19:14

IAR выдаёт код компактнее в 2-3 раза подделок типа SDCC
1-2
http://sdcc.sourceforge.net/mediawiki/index.php/Z80_code_size
IAR выигрывает у SDCC два с лишним только в одном случае - на умножении 32-битных чисел.

Valen

19.05.2014, 20:03

Вот ругают SDCC обычно те , которые его не юзали вообще (либо в последнее время). Ведь даже по ссылке сходить и почитать - это ж непомерный труд ...

И совсем не знают, что там как минимум два очень рульных добавления было сделано, за последние 7-8 месяцев.
Первое, это новый оптимизатор распределения регистров, именно для z80.
Второе, это поддержка банков памяти для переменных Си программы.

Сравнение с другими z80 компилерами давно, лежит (и обновляется) по ссылке, которая постом выше есть.

jerri

20.05.2014, 10:00

Valen, никто SDCC не ругает. Просто в недоумение иногда приводит код выдаваемый этим самым SDCC. Но все знают что над SDCC ведется работа и когда нибудь компилятор достигнет уровня IAR.

Oleg N. Cher

20.05.2014, 12:51

Мне в целом нравится стратегия работы над SDCC. Филипп обещал сделать передачу параметров в регистрах. Просто это сложный участок работ, к которому он не решается приступить.

Сейчас в SDCC/ZXDev можно применять параметры в регистрах, но только если это константы. В связи с желанием оптимизировать ASCII дальше вспомнилась идея, которую как-то высказал vinxru (http://zx.pk.ru/member.php?u=6677), условно назовём её "впрыскиванием" (POKE'ing) параметров в тело процедуры. Я хотел выиграть так ещё несколько байтов. Получилось вот что:

_main_start::
_main:
;ASCII.c:20: ASCII_n = 96;
ld hl,#_ASCII_n + 0
ld (hl), #0x60
;ASCII.c:21: do {
00101$:
;ASCII.c:22: Console_WriteCh((CHAR)((96 - ASCII_n) + 32));
ld hl,#_Console_WriteCh_ROM_poke
ld bc,#0x000A
add hl,bc
ex de,hl
ld hl,#_ASCII_n
ld a,#0x80
sub a, (hl)
ld (de),a
call _Console_WriteCh_ROM_poke
;ASCII.c:23: ASCII_n -= 1;
ld iy,#_ASCII_n
dec 0 (iy)
;ASCII.c:24: } while (!(ASCII_n == 0));
ld a,(#_ASCII_n + 0)
or a, a
jr NZ,00101$
;ASCII.c:25: __FINI;
ret
_main_end::Чтобы было понятно: параметр "впрыскивается" в тело процедуры Console_WriteCh_ROM_poke по смещению 10.

#define __POKE(addr,val) (*(unsigned char*) (addr) = (val))
#define Console_WriteCh(ch) __POKE((int)Console_WriteCh_ROM_poke+10,ch); Console_WriteCh_ROM_poke()Но SDCC сгенерил, увы, вот такой код:

ld hl,#_Console_WriteCh_ROM_poke
ld bc,#0x000A
add hl,bcубив на корню все возможные выиграши. Я игрался с глобальной меткой (по адресу которой хотел POKE'ать параметр), с __at() (которая, увы, понимает только константный адрес, а не метку). Может и можно что-то сделать, но сдаётся мне, лучше всего будет направить новый feature request Филиппу. Вот так и предлагаю делать оптимизацию. Заодно Филиппу будет стимул, что он не варится в своём соку, а его труд востребован и ожидаем. Это многого стоит.

Andrew771

20.05.2014, 13:39

это всё геморно для рядового пользователя. Нужно так: ввел исходник на Обероне, нажал одну кнопку, он скомпилировался в асмовский файл. Если, Олег, ты сделаешь эту кнопку, то будут пользователи.

CodeMaster

20.05.2014, 13:48

Если, Олег, ты сделаешь эту кнопку, то будут пользователи.

Как он это сделает, если SDCC не допилен, для повсеместного использования? Вообще, ZXDev видится пока, только как предложение для допиливания SDCC до приемлемого уровня.

Библиотеки, которые мы можем разработать, также можно будет использовать и с IAR, и с SDCC, и с ZXDev. Есть смысл сосредоточиться на библиотеках, а не спорить в который раз какой Си-компилер лучше.

Вопрос в другом: кто будет это делать? Те для кого асм сложно не смогут этого, тем для кого он не сложен это не нужно. Дилемма, однако :-/

Kakos_nonos

20.05.2014, 13:49

Да оно там так и есть, написал код, нажал ф12 и всё запустилось. Транслировалось в си, потом в асм, ассемблировалось и в тап.

Eltaron

20.05.2014, 14:12

Как он это сделает, если SDCC не допилен, для повсеместного использования? Вообще, ZXDev видится пока, только как предложение для допиливания SDCC до приемлемого уровня.
В смысле не допилен? На SDCC как минимум построен тулчейн для написания игр под пентеву (EVO SDK), на котором уже сделано несколько законченных игр.
Проблема в том, что он генерирует не самый оптимальный код. Но даже сейчас этот код намного лучше кода, который генерирует самый популярный компилятор для zx-разработки, zcc из z88dk. А на нём весь миллион игр от Mojon Twins написан, между прочим.

Oleg N. Cher

20.05.2014, 15:07

Меня знаете что удручает. То, что лезут давать советы, даже не попробовав что уже сделано и чего оно там уже умеет.

В работе важно идти на компромиссы. Мой компромисс - это кодогенерация SDCC. Я с ней согласен, потому что это лучший среди живых компилятор.

А ZXDev видится даже не как замена Си. Оно видится как попытка вывести разработку спектрумного (да и не только) софта на более высокий уровень. Наглядности. Портабельности. Высокоуровневой оптимизации. Кто с этим не согласен - продолжает кодить на асме, и оспаривать это святое право никто не претендует.

Andrew771, ты ведь уже вроде ASCII собрал? Иначе бы не возник вопрос "волшебной кнопки". Но, кстати, вот тебе прекрасная иллюстрация того, какие именно претензии ты получишь к своему паскалю. По приравниванию неоптимальности к невозможности пользоваться. Наслаждайся.

Andrew771

20.05.2014, 15:32

Andrew771, ты ведь уже вроде ASCII собрал? Иначе бы не возник вопрос "волшебной кнопки". Но, кстати, вот тебе прекрасная иллюстрация того, какие именно претензии ты получишь к своему паскалю. По приравниванию неоптимальности к невозможности пользоваться. Наслаждайся.
ну я сейчас вставляю в Кросс-Асм этот (http://zx.pk.ru/showpost.php?p=711513&postcount=186) полученный код, он не компилируется, выдает кучу ошибок:
1. Имя area не определено
2. Отсутствует ORG
3. Ошибка синтаксиса ld 0(iy),#0x20
4. Странные адреса

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

Oleg N. Cher

20.05.2014, 15:49

Странно имхо то, чем ты там занимаешься. Пытаешься выход одного асма натравить на вход другого. А это не работает ещё с времён GENS4.

А чем тебя не устраивает асм, встроенный в SDCC? Это модульный асм. На нём можно разрабатывать библиотеки с возможностью использовать их из асма, из Си и из Оберона. Со смартлинковкой.

---------- Post added at 14:49 ---------- Previous post was at 14:47 ----------

p.s. ld 0(iy),#0x20 это ld (iy+0),20H

Andrew771

20.05.2014, 16:55

ааа, извини, я тупой. Всё, нашел, запустил свой ASCII.bat, сработало в эмуляторе!
Ну это супер!
Попытаюсь чё-нить более серьезное на Обероне написать, для теста.

Oleg N. Cher

20.05.2014, 17:11

Да просто жми F12 - это билд и запуск сразу. И я виноват тоже - в ридми про это не сказано. Но я исправляюсь - обновил ридми.

Andrew771

20.05.2014, 17:13

А Оберон у тебя все операторы поддерживает или есть ограничения?

Oleg N. Cher

20.05.2014, 17:52

Операторы Spectrum-Basic, в смысле? Наверное не все. INKEY там нет, не успел реализовать. Список можно увидеть в интерфейсе модуля (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=193#p1189).

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

Andrew771

20.05.2014, 21:50

Операторы Spectrum-Basic, в смысле? Наверное не все. INKEY там нет, не успел реализовать. Список можно увидеть в интерфейсе модуля.
нет, забудь про Бейсик. Я про Оберон. Т.е. readkey нет, пичалька. А как управлять в игре с клавиатуры?
Записи, массивы есть?

---------- Post added at 21:50 ---------- Previous post was at 21:49 ----------

Поддержка кириллицы?

Oleg N. Cher

21.05.2014, 07:07

Т.е. readkey нет, пичалька. А как управлять в игре с клавиатуры?Ну, как сказать, нет readkey. Есть Input.Read. Есть чтение из порта Basic.PORTIN. Есть системная переменная LAST_K, доступная при разрешённых прерыванииях. Что-то на эту тему было тут (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=30#p77). В конце концов, есть асм и ручки. :)

Записи, массивы есть?Ну куда же без них родимых. И ООП есть.

Поддержка кириллицы?

ZXDev + кириллица (http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=194)

Только когда будешь пробовать - не забудь добавить русский шрифт в модуль GrFonts и пересобрать его (по F12). В репе я уже сделал, добавил шрифт, оказавшийся под рукой - из игры "Дурак". Чтобы снять вопросы по тонкостям как именно добавить шрифт - вот ссылка на коммит (https://github.com/Oleg-N-Cher/XDev/commit/70e97c51e9eb378cf32fd29a9d91bf8deb4d69ef).

Alcoholics Anonymous

21.05.2014, 09:24

Меня знаете что удручает. То, что лезут давать советы, даже не попробовав что уже сделано и чего оно там уже умеет.

В работе важно идти на компромиссы. Мой компромисс - это кодогенерация SDCC. Я с ней согласен, потому что это лучший среди живых компилятор.

Привет Олег ,

Извините за плохой русский язык. Если вы можете говорить по-английски , я оставил английский текст ниже.

Знаете ли вы , что z88dk имеет более чем 100 000 строк ассемблера подпрограмм в нем ?

Просто чтобы дать вам вкус , есть :

* Функции для чтения клавиатуры , джойстики и мышей.
* Спрайт двигатели
* C + + STL контейнеры , как вектор, стек , очередь , priority_queue
* C11 динамического распределения памяти , в том числе создания нескольких куч
* Пропорциональна печать с FZX
* 1 -битная звуковая
* Полное STDIO , включая как Printf и зсапЕ
* Заполнение строки и stdlib реализации
* Выбор быстрого или небольшой целое математике

Они собираются в новый CLIB в отрасли развития теперь, в настоящее время совместимы с SDCC .

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

Все это зависит от диска.

Причина z88dk был в более широкое применение , чем SDCC в гх сообщества в том, что из этих библиотек . Нет компилятор не может конкурировать с рукописной АНМ , и в результате , z88dk всегда сгенерированный код меньше и быстрее в несколько раз для реальных программ , когда C код написан с использованием библиотек . Это библиотеки , которые наиболее важны при генерации кода из-за разрыва между выходом для составителей и то, что человек может достичь .

Существует никаких сомнений , что SDCC может производить более оптимальный код, чем sccz80 ( компилятора z88dk в ) , и именно поэтому проект z88dk пытается разрешить использование SDCC для генерации кода теперь . Однако, есть принципиальная разница в подходе двух компиляторов. SDCC стремится сделать много встраивания и это то, что делает код выглядеть лучше. sccz80 пытается использовать подпрограммы для распространенных задач (например, добавить две длинные позиции ) , и это должно привести к меньшим еще медленнее кода. Таким образом, даже с двумя компиляторов , используя те же библиотеки , я думаю, sccz80 будет производить меньшее код, если C код написан наведение sccz80 . Но , что еще предстоит увидеть :)

Я думал, я хотел бы упомянуть репозиторий z80 кода в z88dk теперь, как это является одним из крупнейших Z80 хранилищ с открытым исходным кодом в сети и я вижу, что вы ищете z80 кода.

Филиал развитие коренится здесь:
http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/

Существует еще код вне Dev филиала , но это труднее найти свой путь вокруг этого.

======

Hi Oleg,

Are you aware that z88dk has more than 100,000 lines of asm subroutines in it?

Just to give you a taste, there are:

* functions for reading the keyboard, joysticks and mice.
* sprite engines
* C++ STL containers like vector, stack, queue, priority_queue
* C11 dynamic memory allocation, including creation of multiple heaps
* proportional printing with fzx
* 1-bit sound
* complete stdio, including both printf and scanf
* complete strings & stdlib implementations
* choices of fast or small integer math

These are being collected into a new clib in the development branch now that is being made compatible with sdcc.

Outside this subset in the rest of z88dk is code for drawing graphics, among other things.

All of this is independent of the ROM.

The reason z88dk has been in more widespread use than sdcc in the zx community is because of these libraries. No compiler can compete with hand-written asm and as a result, z88dk has always generated code smaller and faster by several times for real programs when C code is written using the libraries. It is the libraries that are most important when generating code because of the gap between the compilers' output and what a human can achieve.

There is no doubt that sdcc can produce more optimal code than sccz80 (z88dk's compiler) and that is why the z88dk project is trying to allow use of sdcc for code generation now. However, there is a fundamental difference in the approach of the two compilers. sdcc tends to do a lot of inlining and this is what makes the code look better. sccz80 is trying to use subroutines to do common tasks (eg, add two longs) and this should lead to smaller yet slower code. So even with the two compilers using the same libraries, I think sccz80 will produce smaller code if C code is written targetting sccz80. But that remains to be seen :)

I thought I would mention the z80 code repository in z88dk now as it is one of the largest open source z80 repositories on the net and I can see you are looking for z80 code.

The development branch is rooted here:
http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/

There is more code outside the dev branch but it is harder to find your way around that.

Oleg N. Cher

21.05.2014, 10:22

Hi Alcoholics Anonymous,

Nice to know that you read this forum.

Yeah, I know about 100,000 lines of asm subroutines of z88dk.

But SDCC has a better code generation. So there is a sense to adapt this libraries to SDCC at least partially. If Philipp Krause will implement passing parameters to procedures in registers (fastcall) - it will be another reason to use SDCC instead of z88dk.

But my preference is coding in Oberon, and not only for Spectrum. And I do not see any problems to connect z88dk to ZXDev as a back-end code generator. And use all this perfect libraries with ZXDev now.

Alcoholics Anonymous

21.05.2014, 11:26

Но моя предпочтение кодирования в Oberon , и не только для Spectrum. И я не вижу никаких проблем для подключения z88dk чтобы ZXDev как генератор фоновых кода. И использовать все эти прекрасные библиотеки с ZXDev сейчас . [/ QUOTE]

Я также не заинтересованы в только Spectrum :) То, что мы делаем, не слишком отличается , кроме вы смотрите на более широком кросс-платформенной совместимости в то время как мы смотрим на z80 кросс-платформенной совместимости . Весь код z88dk , или столько, сколько мы можем, носит общий характер и библиотеки , которые должны быть специализированные написаны на работу , как на многих платформах , как это возможно , используя тот же интерфейс . Так, например ,1-битовый библиотека звук проигрывает музыкальные и звуковые эффекты на 20 + различных Z80 машин . Графическая библиотека также рисует графику на 20 + различных Z80 машин . Спрайт двигателя меньше повезло , только работая на трех разных машинах. Поиск хорошего API, которые могут применяться на разных платформах не легко, и есть много мелких деталей , чтобы волноваться о . Например, 1 -битная звуковая поколения зависит от скорости процессора - так как вы генерировать те же ноты из того же кода ? Точно так же существуют различия в пиксельных и цветового разрешения с платформы на платформу так , пишущие хороший кросс-платформенный графическую библиотеку не так просто.

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

Я читал некоторые из ваших сообщений на вашем форуме и главное, что я хотел обратить ваше внимание на том, что мы написали часть кода z80 , которого вы ищете , и мы на самом деле движется в том же направлении в течение нескольких вещей . Например, у меня есть идея для реализации z80 сборщик мусора , что я буду преследовать после следующего релиза z88dk и у меня есть идеи о том, как написать лучшую графическую библиотеку, которая включает в себя графический конвейер для масштабирования ( разные разрешения ) и вырезку , в то же время что позволяет для различных цветовых решений задач . Я заинтересован в коде обмена , API и подходов к Z80 целей так вот почему я отправляю , чтобы убедиться, что все знают друг о друге :)

Что касается SDCC , мы проводим тестирование компиляцию с SDCC сейчас . Я могу генерировать SDCC программы, используя z88dk библиотеки , но есть еще проблемы, которые работают вне. SDCC может утверждать основной C LIB в z88dk , но бывает ли , что не гарантируется. SDCC должен беспокоиться о более чем цель z80 и включения переменного Lib , что значительно больше, и отличается от любого другого процессора может быть не то, что они хотят сделать . В любом случае , наверняка, нестандартные вещи, как графика, звук , спрайты не представляет интереса для SDCC . z88dk всегда будет домом для этого, и целью является , чтобы позволить аналоговый или цифровой компиляции с использованием двух различных компиляторов - SDCC и sccz80 .

======

[QUOTE=Oleg N. Cher;711942]
But my preference is coding in Oberon, and not only for Spectrum. And I do not see any problems to connect z88dk to ZXDev as a back-end code generator. And use all this perfect libraries with ZXDev now.

I am also not interested in only the Spectrum :) What we're doing is not too dissimilar other than you are looking at a broader cross-platform compatibility whereas we are looking at z80 cross-platform compatibility. All the z88dk code, or as much as we can, is generic and the libraries that must be specialized are written to work on as many platforms as possible using the same interface. So, for example, the 1-bit sound library plays music and sound effects on 20+ different z80 machines. The graphics library also draws graphics on 20+ different z80 machines. The sprite engine is less fortunate, only working on three different machines. Finding good APIs that can apply across platforms is not easy and there are many small details to worry about. For example, the 1-bit sound generation is affected by cpu speed -- so how do you generate the same notes from the same code? Likewise there are differences in pixel and colour resolution from platform to platform so writing a good cross platform graphics library is not easy.

We're fortunate in that all the z80 machines are approximately the same in terms of computing power and resolution. Your task is harder as the range in capability is extreme. You're faced with either creating a lacklustre least common denominator API or taking on a much more difficult task of designing an API that degrades sensibly for less capable targets.

I've read some of your posts on your forum and the main thing I wanted to bring to your attention is we've written some of the z80 code you are looking for and we are in fact heading in the same direction for several things. For example, I have an idea for implementing a z80 garbage collector that I will pursue after the next z88dk release and I have ideas on how to write a better graphics library that includes a graphics pipeline for scaling (different resolutions) and clipping, while still allowing for different colour resolutions of targets. I'm interested in sharing code, apis and approaches for z80 targets so that's why I post, to make sure everyone is aware of each other :)

With regard to sdcc, we are testing compilation with sdcc now. I can generate sdcc programs using z88dk libraries but there are still problems to work out. sdcc may adopt the core c lib from z88dk, but whether that happens is not guaranteed. sdcc has to worry about more than the z80 target and incorporating a c lib that is much larger and dissimilar from every other processor might not be what they want to do. In any case, for sure, the non-standard things like graphics, sound, sprites are of no interest to sdcc. z88dk will always be the home for that and the intent is to allow seemless compilation using two different compilers -- sdcc and sccz80.

Andrew771

30.05.2014, 10:32

Почитал вашу перепалку: http://zx.oberon2.ru/forum/viewtopic.php?f=10&t=201
Оба неправы :)

Oleg N. Cher, чтобы твоей средой начали пользоваться, нужно сделать ее дружелюбной - компилирование в конечный файл Спектрума без танцев с бубном (этот у тебя уже есть) и наличие необходимых библиотек (этого пока нет). Плюс хорошая кодогенерация (SDCC барахлит частенько в плане выдачи оптимального кода). Библиотеки нужны, чтобы, к примеру, юзер не писал процедуру вывода спрайта или текста на Обероне - это не будет работать быстро на ЯВУ. А медленно - не нужно, не работоспособно. Как ты сделал "Дурака" без библиотек, я не знаю.
Поэтому, займись сейчас сам встраиванием библиотек в среду, я тебе могу подкинуть некоторые процедуры уже сейчас. А также рекомендую пособирать на сайте http://zxdn.narod.ru/coding.htm
Также рекомендую выкинуть из языка ненужные для Спека элементы, если они существенно займут время твоей разработки - действительные числа, многомерные массивы и др. Просто, они не нужны в реальной жизни на Спеке.
И, ИМХО, хоть Оберон и "красивее" Паскаля, но для имеющихся спектрумистов лучше всё же Паскаль, т.к. его многие уже знают, у них и в сети есть куча исходников на Паскале. На Обероне почти нет. Переводить в Оберон никто не захочет. Так исторически сложилось, и переломить это мы не можем. Вот тебе пример - формат ogg для музыки лучше mp3 по качеству со сравнимым размером файла, но его мало кто использует. Не успели вовремя раскрутиться. Тут кто первый со своим кривым поделием, того и TAP-ки. Компилир z88dk так себе, я рассматривал его для своей работы, даже С хотел выучить наконец, но забраковал из-за крайне неэффективного кода. Но лучше пока нет.
Второй вариант - делай Оберон для себя, для фана, как ты хочешь. Тогда и спорить тут ни с кем смысла нет. Спектрум с точки зрения здравого смысла - бесперспективная платформа для большинства народа. Оберон - не взлетел. Паскаль и Делфи для коммерческих разработок умерли. И спорить про вакансии смысла нет. Хочешь зарабатывать денег на программировании, учи C++ и Java (и чё там еще щас). С этим мирком бороться бесполезно, пусть бегают как белка в колесе, а мы с попкорном понаблюдаем, писия на старом добром Паскале. :)

Kakos_nonos

30.05.2014, 12:00

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

Oleg N. Cher

30.05.2014, 12:42

наличие необходимых библиотек (этого пока нет).Нельзя говорить, что библиотек нет совсем. Смотрите что есть:

Доступные библиотеки
====================

Basic - Sinclair ZX Spectrum Basic для Ofront/SDCC
Best40 - "40 лучших процедур" от SerzhSoft. На самом деле меньше. :)
Console - консольный ввод-вывод
Graph - графическая библиотека, совместимая с Turbo Pascal
Input - ввод с клавиатуры
GrFonts, GrPixel, GrScr, GrTiles - кроссплатформенная графика XDev
Laser - Laser Basic для Ofront/SDCC
Math - вещественная математика, генерация случайных чисел
Mega - Пара процедур из Mega Basic
Platform - платформенно-зависимые возможности
Strings - работа со строками
Timer - задержка времени
TrDos - работа с функциями TR-DOS

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

А медленно - не нужно, не работоспособно. Как ты сделал "Дурака" без библиотек, я не знаю.См. выше. Для Дурака, собственно, хватает библиотек Laser и Basic. Для него они начаты, уже не для него продолжены.

Поэтому, займись сейчас сам встраиванием библиотек в среду, я тебе могу подкинуть некоторые процедуры уже сейчас.А подкинь-ка плиз. А то я уже года три как среду делаю сам. И вынужден отстаивать идеи высокоуровневой разработки для Спека, хотя такие игры давно делаются на z88dk. И идеи Паскаль-языков. Хотя у языков данного семейства есть свои ценители.

Также рекомендую выкинуть из языка ненужные для Спека элементы, если они существенно займут время твоей разработки - действительные числа, многомерные массивы и др.Ничего специально выкидывать не буду - они достались мне даром. :) То есть уже реализованы в Ofront'е и SDCC. Я могу рассказать что я вижу мешающим и как вижу дальнейшее усовершенствование, но не путём отбрасывания этих средств конечно. Не нужны - не пользуйся. А кому-то могут понадобиться. Более того, достигается какая-то доля портабельности, но она возможна только за счёт набора библиотек с одинаковой логикой и интерфейсами, которые мне тоже приходится разрабатывать одному, притом для разных платформ.

И, ИМХО, хоть Оберон и "красивее" Паскаля, но для имеющихся спектрумистов лучше всё же Паскаль, т.к. его многие уже знают, у них и в сети есть куча исходников на Паскале. На Обероне почти нет.Готовые исходники на Паскале очень слабо подойдут для Спека, так что это не аргумент. Их приходится модифицировать. Более того, "вещи в себе" можно за пять минут переписать на Оберон, а серьёзные вещи с TurboPascal'я на Спек не перепишешь, не хватит ресурсов.

Благодарю за "красивее". Он действительно красивее. Например за счёт отказа от лишних BEGIN'ов. Не стоит за них держаться.

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

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

Оберон - не взлетел. Паскаль и Делфи для коммерческих разработок умерли.Погоди, нельзя так говорить. Дельфи жив, вон ввели поддержку C++ для Андроида. FreePascal жив и для коммерческих разработок, вообще очень интересная среда, я хотел бы видеть в итоге с XDev что-то похожее, только на базе Оберона.

И к Оберону в научных кругах интерес огромный. Этот язык не имеет аналогов в качестве простого современного императивного языка для публикации алгоритмов и т.п.

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

P.S. Ты если с кодом решишься помогать, то делай это тоже не для меня, а для себя, для своей будущей игры, а я тебе всячески помогу, т.к. понимаю как непросто решиться вкладывать свой труд в ZXDev. Но это в общем то же направление, что и твоё, и, хотя для многих это неочевидно, я просто предлагаю собрать ZX-библиотеки в одном месте, снабдить их высокоуровневыми интерфейсами, возможностью смарт-линковки и возможностью вызывать их не только из Оберона, но и из Си и асма. Что здесь не так, что никто не поддержал это начинание?

---------- Post added at 11:42 ---------- Previous post was at 11:39 ----------

Для того, чтобы среда пошла в массы надо сделать туториалы и хорошо её описать, как начать, как закончить, что писать и т д.Kakos_nonos, собственно, что мог сделать один человек - он делает. См. на форуме Пристанище Спектрум-кодера (http://zx.oberon2.ru/forum/viewforum.php?f=10). Дальше - люди берут и пользуются этим, задают наводящие вопросы, помогают. Или критикуют конструктивно. Либо же нет.

Andrew771

30.05.2014, 14:41

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

Готовые исходники на Паскале очень слабо подойдут для Спека, так что это не аргумент. Их приходится модифицировать. Более того, "вещи в себе" можно за пять минут переписать на Оберон, а серьёзные вещи с TurboPascal'я на Спек не перепишешь, не хватит ресурсов.
Ну если там нет действительных типов, то не так сложно. Скорректировать только координаты вывода на экран. Я вот здесь для примера посмотрел исходники, реально: http://pascal.proweb.kz/index.php?page=127

А подкинь-ка плиз. А то я уже года три как среду делаю сам.

P.S. Ты если с кодом решишься помогать, то делай это тоже не для меня, а для себя, для своей будущей игры, а я тебе всячески помогу, т.к. понимаю как непросто решиться вкладывать свой труд в ZXDev.
Выкладываю текущий свой проект Паскаля, библиотека процедур там в файле libasm.lib - это обычный текстовый файл с процедурами на асме. Некоторые надёргал из разных источников, некоторые сам написал. До спрайтов пока не дошел. Можешь себе брать.
А еще можешь поюзать сам Паскаль. Уже поддерживаются:
- переменные типов byte и word;
- одномерные и двумерные массивы типа ArrayWord[i,j];
- операторы: begin-end, :=, write(ln), if-then, for-to, while, repeat-until, pause, clrscr, gotoxy;
- математические и логические выражения; арифметические знаки + - * / % (целочисленные); скобки и приоритет операций поддерживаются;
- процедуры без параметров;
- нестандартные операторы: color(attr) - установка байта атрибутов; window(x,y,width,height) - установка и очистка окна в знакоместах.
- шрифт используется пока только 4х8 (64 символа в строке).

Оптимизации кода пока нет. Но буду делать по навету ZEKа - оптимизировать сгенерированный код - распознавать шаблонные комбинации команд и заменять оптимальными.
Планируется куча встроенных команд вывода спрайтов, вывода и обработки карт/лабиринтов, скроллингов и отражений окон. Часть процедур уже написана за предыдущие игры. Сейчас я занят поддержкой символьных переменных и массивов (помимо игры на конкурс "Твоя игра", но ей уже почти конец).

Oleg N. Cher

01.06.2014, 12:25

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

Но если вдруг (ну вдруг) кому-то понадобится в твоём Паскале трёхмерный массив, придётся вычислять координаты вручную. SDCC же это делает эффективно автоматически.

Ну если там нет действительных типов, то не так сложно. Скорректировать только координаты вывода на экран. Я вот здесь для примера посмотрел исходники, реально: http://pascal.proweb.kz/index.php?page=127Реально, но после неизбежной модификации. Куча готовых исходников на ТурбоПаскале - это работа с портами, векторами прерываний и с библиотеками, которые физически нельзя портировать на Спек, с большими массивами и ещё много чем. В случае с Дельфи случай ещё тяжелее, там потоки, сокеты и gui. Найди хотя бы десять исходников на Паскале, которые ты копипастой соберёшь для Спека. И даже если ты их найдёшь, это будет всего десять исходников. А тех, которые не соберутся - миллион. Это что, тоже аргумент за Паскаль вместо Оберона?

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

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

Самая интересная критика моего направления разработок заслуживает самого пристального внимания. Но даже более бездарной критики я очень редко удостаиваюсь, в основном, как видишь, это предвзятые придирки при полном нежелании даже скачать и опробовать среду. А к тебе в ветку ещё не приходили сравнивать твою кодогенерацию с SDCC? Значит придут. ;) Или, например, человек не посмотрел библиотеки, но вовсю кричит о "дичайшем отставании по библиотекам". А сам хоть бы процедурку адаптировал, например, из своей игры. ;)

Некоторые надёргал из разных источников, некоторые сам написал. До спрайтов пока не дошел. Можешь себе брать.Спасибо, гляну. Но насколько я понимаю, вкладываться в ZXDev, адаптируя процедуры самолично, ты не хочешь. Что ж, но даже такая рутинная работа требует усилий, хотя время от времени я ею занимаюсь (http://zx.oberon2.ru/forum/viewtopic.php?f=10&p=1223#p1223).

А еще можешь поюзать сам Паскаль.Мне есть смысль юзать его только в том случае, если он будет иметь серьёзные преимущества по сравнению с ZXDev. Пока же ZXDev:

выглядит более готовым;
позволяет использовать при разработке язык Си наряду с Обероном;
имеет оптимизирующую кодогенерацию; и побольше библиотек;
имеет все предпосылки для кроссплатформенной разработки. Притом данный подход соединяет даже такие несоединимые вроде бы вещи как Z80 и JavaME в возможности разрабатывать игру для этих двух платформ с одного листа на одном языке. И хотя у него хватает и недостатков, и достоинств здесь чувствуется огромный потенциал;
ну и, наконец, я предпочитаю продукты с открытыми исходниками.

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

7. Writing a New Code Generator

The general method which we found extremely helpful when developing a new code generator is the same as that explained in Project Oberon [1]. Before describing his compiler in detail, Wirth first lists fifteen sample 'code patterns' (we added a sixteenth for our open-array operations), showing what machine code should be output for a particular set of sample Oberon statements and expressions.

These patterns are far from working programs, but as Wirth points out, the discipline of deciding which code should be output (usually with a paper and pencil in our case) is a prerequisite, before discovering how best to design the generator. Working our way through the patterns kept the complexity of the task in check.

Each code-generation procedure has a standardised interface, and there are 14 procedures in all:

Released () Move () Addr() Index () MonOpO BinOpO Branch () JumpO Trap () Case () PrepCallO Call() Enter () Return ()Это кроссплатформенный компилятор.

И если бы удалась примерно такая же декомпозиция оптимизирующей кодогенерации на простые и инкрементально поддающиеся доработке различными заинтересованными людьми части, было бы просто замечательно. Но увы. Решение этой задачи лежит в слишком сложной плоскости. Ты его коснулся только слегка. Дальше будут такие дебри, что ой. Так что мы сможем собрать со всего форума претензии к коду, выданному SDCC, и применить их к твоему Паскалю в ещё большей степени. Не думай, что злорадствую. Я сочувствующий.

Reobne

03.06.2014, 15:57

Сделал первый "продукт" в среде ZXDev. :)
Иллюстрация окружностей и работы EORFill (http://zx.pk.ru/showpost.php?p=714673&postcount=380).
Первоначальный алгоритм рисования окружности (http://zx.pk.ru/showpost.php?p=714282&postcount=318)
где-то нарыл denpopov, потом его исправляли, в основном Titus.
За основу взял пример с цветочком. Flower.Mod

Текст на обероне:

MODULE Circl;
IMPORT G := Graph, Basic;

VAR
KD, MD, x0, y0, R, i: INTEGER;

PROCEDURE Circ (x, y, Radius: INTEGER);
VAR
X,Y,A:INTEGER;

PROCEDURE Plot4;
VAR
ty:INTEGER;
BEGIN
ty:=(y+Y);
IF ty<0 THEN ty:=0 ELSIF ty>G.GetMaxY() THEN ty:=G.GetMaxY() END;
G.PutPixel(x +X,ty);
IF X#0 THEN G.PutPixel(x -X,ty); END;
ty:=(y-Y);
IF ty<0 THEN ty:=0 ELSIF ty>G.GetMaxY() THEN ty:=G.GetMaxY() END;
G.PutPixel(x +X,ty);
IF X#0 THEN G.PutPixel(x -X,ty); END;
END Plot4;
BEGIN
(*This is the entire algorithm:*)

Y:= Radius;
X:=0;
A := Radius DIV 2;
REPEAT
(*;Could just use Plot8*)
Plot4;X := X + 1;
A := A - X;
IF A<0 THEN A:=A+Y ; Y:=Y-1 END;
UNTIL X >= Y;

(*; Now more or less reverse the above to get the other eighth*)

A := -(Radius DIV 2) - 1;
Plot4;
REPEAT
A := A + Y;
Y := Y - 1;
IF A>0 THEN X:=X+1;A:=A-X;Plot4; END;
UNTIL ~(Y>=0);

END Circ;

BEGIN (*$MAIN*)
KD := G.ZX;
MD := G.ZXMono;
G.InitGraph(KD, MD, "");
G.SetBkColor(G.Green); G.SetColor(G.Black); G.ClearDevice;
Basic.OVER(1);
(* x0 := (G.GetMaxX() + 1) DIV 2;
y0 := (G.GetMaxY() + 1) DIV 2;*)
FOR i:=0 TO 20 DO
x0 := Basic.RND(-60,G.GetMaxX()+60);
y0 := Basic.RND(-60,G.GetMaxY()+60);

FOR R:=20 TO 60 BY 20 DO
Circ(x0, y0, R);
END;
END;
(*Flower(x0, y0, y0 DIV 2 * 3, 5, 1.0, 0.25, 0.1);*)
Basic.PAUSE(0);
G.EORFill;
G.CloseGraph
END Circl.

Текст EORFill, которую я наглым образом добавил в модуль Graph :):

/*--------------------------------- Cut here ---------------------------------*/
export void Graph_EORFill (void)
{
__asm
LD L,#0X20
loop1$:
DEC L
LD H,#0X40
XOR A
LD C,#3
loop2$:
LD B,#8
LD DE,#32-7*256
loop3$:
XOR (HL)
LD (HL),A
INC H
XOR (HL)
LD (HL),A
INC H
XOR (HL)
LD (HL),A
INC H
XOR (HL)
LD (HL),A
INC H
XOR (HL)
LD (HL),A
INC H
XOR (HL)
LD (HL),A
INC H
XOR (HL)
LD (HL),A
INC H
XOR (HL)
LD (HL),A
ADD HL,DE
DJNZ loop3$
LD DE,#8*256-8*32
ADD HL,DE
DEC C
JR NZ,loop2$
DEC L
INC L
JR NZ,loop1$
RET
__endasm;
} //Graph_EORFill

Вложения (http://zx.pk.ru/attachment.php?attachmentid=48245&d=1401794840)

denpopov

03.06.2014, 16:52

исподники зажал?:)

Reobne

03.06.2014, 16:59

исподники зажал?
Исходники что-ли? Все что были, все под спойлер запихал.

denpopov

03.06.2014, 17:09

что-то мне все это Объект.Метод vbs напомнило(

Reobne

03.06.2014, 17:13

Только тут это не Объект.Метод, а Библиотека.Процедура. :)

denpopov

03.06.2014, 17:19

Только тут это не Объект.Метод, а Библиотека.Процедура.
даже
G.InitGraph(KD, MD, "");
?
это не среда разработки а fucking shame какой-то..

Oleg N. Cher

03.06.2014, 19:13

Не согласен, и вот почему. Допустим, есть две библиотеки с одноимёнными процедурами. Как их использовать вместе?
В Си это проблема, иногда даже трудно устранимая (если наложились стандартные имена, их нельзя переопределить ввиду невмешательства в сторонний код и т.д.)
В Дельфи это можно сделать так:
ИмяМодуля.ИмяПроцедуры (ИмяМодуля необязательно, и только для уточнения из какого именно модуля брать. Возникает вопрос: из какого будет браться, если ИмяМодуля опущено? Это совсем неочевидный момент).

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

Reobne, спасибо. Что-то по кругу есть в Basic, писано на Си и неоптимально. А ещё помню у меня где-то завалялась процедурка быстрого круга на асме, разрешающая рисовать круги, которые могут выйти за пределы экрана, могу подкинуть.

Oleg N. Cher

03.10.2014, 11:44

твой обожаемый мертвый язык так оскорбили и обидели...На это отвечу отдельно. Что есть “живой язык”.

Уточняется ли Оберон по сей день? (http://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.html) Да. Восьмидесятилетный дедушка Вирт (http://habrahabr.ru/post/212887/) охотно переписывается по поводу Оберона, кстати, считая Оберон своим основным достижением на поприще информатики. Не только как дисциплину программирования, но и как подходящее средство для реализации сложных проектов маленькими коллективами.

Появляются ли новые компиляторы Оберона? Да. Например, AyaCompiler (https://github.com/congdm/AyaCompiler) и OberonJS (https://github.com/vladfolts/oberonjs).

Используется ли Оберон в образовании? Да, например, см. проект Информатика 21 (http://www.inr.ac.ru/~info21/).

Есть ли современные диалекты Оберона? Да. Например, Компонентный Паскаль (http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D 1%82%D0%BD%D1%8B%D0%B9_%D0%9F%D0%B0%D1%81%D0%BA%D0 %B0%D0%BB%D1%8C).

Разрабатывается ли коммерческий софт на Обероне? (http://zx.oberon2.ru/forum/viewtopic.php?f=37&t=214) Безусловно. И что? Язык жив пока помогает решать задачи. Для меня мёртв C#. По той же причине. Я его не использую.

Не понимаю движухи вокруг осинового кола, вбиваемого в грудь Паскаля. Это эпоха. Половина моего любимого софта написана на Delphi – Total Commander, KMPlayer, RNQ. Это живой, развивающийся софт. Может у сишников только одна радость в жизни, кроме зарплаты конечно, – хоронить Паскаль? Я могу это понять как излияние чувства глубокой неполноценности тех средств, с которыми программисты вынуждены работать исключительно потому, что за это платят.

Глупо отбрасывать эту эпоху, особенно если ты выскочка, прочитавший пару книг про "C# за 21 день". Кстати, для подобных пассажиров как раз и характерны подобные высказывания. Опытные же программеры обычно воздерживаются от них, особенно если не в курсе. Когда я упомянул в разговоре с А.Боковиковым Оберон и сказал, что побочным эффектом от переноса библиотеки ACL на Оберон будет появление 64-битной версии – он начал распрашивать. И признался, что ничего не знает об этом языке. А это старый программер, начинал сто лет назад.

Оберон – это квинтэссенция Паскаля, Дельфи, Модулы-2. Это отличные красивые языки, которые нисколько не теряют исключительно потому, что появился раздутый язычишка C#, прикреплённый к фирме, переживающей не самые лучшие времена. Точно также и про всякую мудотень с динамической типизацией на основе интерпретации. Да, мы вынуждены это использовать, но не от хорошей же жизни.

XDev же современна, ибо прогрессивна в духе Haxe (http://haxe.org) или Monkey X (http://www.monkey-x.com). Пришло время таких средств.

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