Новая версия Nova

Что нового за полгода:
Исправлено 2 бага (1 со словом ALT: , другой с передачей параметра в поток)
Существенно упрощен транслятор файлов, все равно в ini подключается более навороченный.
ALLOCATE FREE и RESIZE стали пользовательскими векторами с поведением по умолчанию, что позволило легко написать либу по проверке хипа на утечки.
Добавлено слово NDROP

По либам:
Написана ещё более страшная, но и более рабочая библиотека по поддержке ООП :D
~er/oop/oop2.f

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

Короче, во 2-й библиотеки версии это учтено :), да и написана она гораздо понятнее чем предшественница

Не прошло и полгода и вот появилась новая версия форта)

Что нового?
Слово TEMP-OUT убирает временный словарь со стека контекста
Слова DW@ DW! DW, для будущей совместимости
Слово USER-VECT-DEF - создание пользовательского вектора с поведением по умолчанию
Слово TYPE теперь пользовательский вектор.

Добавлена наработка для перенаправления TYPE-вывода в строку

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

NOVA-CDW

Основные изменения:
Добавлены слова: [b]UMIN UMAX U> U< BYE[/b]
Новая документация (пока разрабатывается) Спасибо [b]KROL[/b]!
Основное направление сейчас: причёсывание исходников и написание документаций к либам и Нове в целом.
В ini-файле подключается более навороченный транслятор файлов. Позиционирует ошибку вплоть до слова и выводит путь к файлу, строку и соб-но слово.

[url=https://vk.com/doc189457568_509116573?hash=4f7c1fdb4b800a9be7&dl=183edef841ea4f4b42]Скачать можно тут[/url]

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

Как будто кто-то запрещает использовать ассемблер при необходимости :)

Тут вопрос не в том, что чего-то не хватает, а в том, что некоторые вещи нельзя доопределить, потому что нужно или знать внутреннюю структуру, или иметь доступ к вещам, которых на уровне слов Форта просто нет. D+ как раз такое слово, его надо писать на ассемблере, а через + не выразить никак.

У меня тогда вопрос, где вы используете числа такой большой длины? Где 4 гигабайтов не хватает?

[quote="Victor__v"]Да и вообще при ошибке выдаётся краткая информация:
последнее скомпилированное слово[/quote]Да я заметил. Но если пишешь исходник не для компиляции в EXE, а для немедленной интерпретации, то ниже последнего определяемого слова может быть уйма текста. Там ведь обычно нужные слова наопределяешь, а потом или расписываешь что в процессе интерпретации делать. И если при этом используешь словечко которого нет, то начинается засада найти где грабль.
[quote]По остальному конечно,[/quote]смотри. Не важно что у тебя каких-то слов нет. Важно чтобы не было препятствия определить нужные слова. А без U< у тебя много чего определить будет невозможно. Или перейти к арифметике еще большей точности. Тут бы D+ и главное без UM* и UM/MOD не обойтись, это слова у которых произведение и делимое двойного размера, вот без них никак. Умножения и деления совсем уж больших чисел через них определять.

WORDS это жёстко)
Я использовал связку число и точка т. е. [code]5 .[/code] к примеру
Да и вообще при ошибке выдаётся краткая информация:
последнее скомпилированное слово
STATE и BASE возникшие при ошибке.

По остальному конечно,
Слов для работы с числами двойной длины нет поскольку не требовались отчего-то ни разу за последнее время, а так вещь нужная.
С LITERAL ситуёвина интереснее. Слово несколько блеклое что ли... связка [ LIT, ] наглядней.
Соот-но : LITERAL LIT, ; IMMEDIATE
Я уже и не помню почему решил отказаться от этого слова.

[quote="Victor__v"]Насчёт спартанской отладки в квадрате не черезчур ли?[/quote]Так эта. Если Форт выводит эхо строк, то на какой строке заткнулось видно сразу. Если еще показывает на каком именно слове в строке ошибка, то вообще комфорт, хотя без этого не проблема и обойтись. А у тебя ни того ни другого. Я в исходник слово WORDS вставлял и смотрел вывалило ли список слов или нет. Если выволило - ошибка по тексту выше, если не вывалило по тексту ниже. Потом слово WORDS перемещал вверх или вниз и опять смотрел. Так строку с ошибкой и вычислял. А ошибки-то какие были - оказывается у тебя CHAR+ нет, S>D нет, 2@ нет, 2! нет, D< U< 0< нет, LITERAL нет и даже после подключения ~ER/DOLOOP.F нету J . Вот глядя на текст как ошибку было увидеть ? Нашел проблемную строку, пучишь на нее глаза и непонятно, ну здесь-то что может не нравится ? Приходится дополнительными экспериментами вычислять теперь уже проблемное слово в строке, порой пошинковывая ее на строки и [ WORDS ] между ними вставляя. Ну чем не спартанская отладка в квадрате ?
Тут решения два - или валить в консоль эхо строк исходника, читаемого из файла, или показать проблемное слово. Либо то, либо другое, либо и то и другое. Это вот как я у себя делал. Либо как Хищник предлагает вывести номер проблемной строки.

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

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

В Нове с этим проблемы с подобной отладкой.
В СПФ это есть, но подозреваю, что там всё завязано с трансляцией файлов.

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

Впрочем, ошибки позиционируются с точностью до последнего определённого слова. Думаю, что с выводом слова породившего исключение это будет достаточно.
Ну или переопределить слово TRANSLATE-FILE, благо это вектор :)

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

[quote="Ethereal"]
Кстати если -7D3 word not found то уже пиши какое именно word not found [/quote]
Хотите верьте, хотите нет, но только сейчас в голову пришло, как это получше сделать, не трогая транслятор :) М-да.

Насчёт спартанской отладки в квадрате не черезчур ли?