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

[Oleg N. Cher]

Да, проблема на x64 происходит из-за того, что конвертер bin2trd — досовый. Давно хочу от него избавиться. Пока что переделал батники ZXDev/Obj/HelloWorld.bat и ZXDev/Obj/TinyHello.bat чтобы собирать TAP'ы другой утилитой — bin2data. Она умеет вставлять машкод в бейсик-загрузчик после REM (или в виде DATA), поэтому с её использованием есть трудности в случае большой программы и низкого значения RAMTOP (как в LaserDemo). Так что утилита bin2data — временное решение, до тех пор пока не будет готова утилита MakeZX, которая по задумке более универсальна.

[Oleg N. Cher]

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

Сгенеренный ею TRD попробовал открыть в Spectaculator, вроде всё ок, и вот эта проблема не проявилась. Надо тестировать в других эмуляторах. Но в любом случае пока что ничего более подходящего на эту тему мне не попадалось. Зато есть исходник, если что-то придётся править. Спасибо, Влад! Спасибо также за эту адаптацию Александру Шабаршину.

Обновил trd2bin, поправил скрипт для сборки LaserDemo. Теперь должно работать в x64.

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

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

[Oleg N. Cher]

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

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

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

[Oleg N. Cher]

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

Сборка BlackBox-XDev для кросс- и embedded разработки

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

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

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

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

Как я пришёл к Оберону. Зачем его использую. Есть ли у него преимущества

О трансляции Оберона в Си (И зачем писать на Обероне, если есть Си?)

Обероны и кроссплатформенность

Среда XDev: с чего начать?

Будни разработки XDev

На Java для ZX (Java для Z80)

Как создать новую библиотеку для ZXDev

Порт графической библиотеки Graph (из Turbo Pascal) под ZXDev

[psb]

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

нетекстовое представление - это не как в языках ld/fbd ли? или как в simulink/labview?

[ZEK]

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

[perestoronin]

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

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

[Oleg N. Cher]

я за то чтобы исходники оставить в текстовом виде - конкретно в чистом unicode.

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

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

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

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

[Vitamin]

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

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

[psb]

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