У меня два типа замечаний: придирки по реализации (это в принципе не важно и сильно субьективно), и по собственно целям библиотеки...
Код:
rus: ." Проблемы со сборкой либы." CR ;rus
eng: ." Can't make the library." CR ;eng
Это что же, для каждого языка надо будет отдельно компилировать разные программы?.. А если язык не русский, и не английский? Для
локализаций сообщений есть гораздо более удобные для пользователей способы (вроде тех же lng-файлов).
А если это сделано для написания
программ на обоих языках, то тогда я уже не понимаю зачем объединять одном файле обе версии... Зачем заставлять одноязычных с каждой стороны читать целую половину файла на чужом языке? Плюс ещё им в обязательном порядке придётся ставить эти флаги, для того чтобы определять язык компилирования библиотеки.
Цитата:
Существует необходимость при изменениях ядра СПФ производить тестирования все наработок.
Самым простым ( но достаточно трудоемким ) вариантом рещения данной задачи можно считать ручное тестирование. Но есть такое понятие лень… А либ становится все больше.
...
Я предлагаю пойти сразу по двум путям решения проблемы...
...
Код:
CREATE testing
S" lib-path\lib-name" INCLUDED
\ при этом будет lib-name подключен, и проверен на "вшивость" пассивным образом
\ и скомпилированный код останется в системе
либо же
S" lib-path\lib-name" testlib
\ будет сделано то же, что и с included но код в системе не останется.
...
Это не два пути решения одной проблемы, это две разные (пусть и зависимые) проблемы:
1. Собираемость (компилируемость) исходных файлов, зависит от наличия тех или иных слов в системе, и корректности IMMEDIATE-кода.
2. Корректность самого исполнения. Зависит вообще от всего, включая фазы Луны, тараканов в голове у программиста и последних изменений в ядре SPF. Причём без прохождения первого пункта, ко второму мы приступить не можем.
Чтобы быть уверенным в полной работоспособности библиотеки
оба пункта должны быть пройдены успешно.
На данный момент автоматически проверять 2-й пункт невозможно, так как для этого нужно принудить, обязать, дооформить в конце концов самому кучу тестового кода, который сейчас у большинства программистов спрятан за \EOF.
Тогда как первую проблему на автоматику взвалить вполне можно и сейчас.
С этой точки зрения, мне нравятся твои "перестраховочные слова" ?changes, ?where во второй половине библиотеки.
Кстати, щас тестовый код у большинства выглядит примерно так:
Код:
: TEST S" test" ;
" abc{TEST}123 5+5={5 5 +} Ok" STYPE CR
И тут бы хорошо для проверки корректности работы сделать что-то вроде:
Код:
>>> abctest 5+5=10
Где слово >>> должно проверять последний (?) вывод на соответствие строке. По-другому переписывать тестовые примеры достаточно сложно.
Теперь мелочные придирки по реализации:
Почему-то мне не прекращает не нравиться парсер process. Ты говорил что это не парсер... А мне вот почему-то кажется, что если что-то выглядит как парсер, действует как парсер, написан как парсер, и используется как парсер, то наверное это действительно немножко парсер?..
Ведь можно сделать проще, через словари:
Код:
VOCABULARY tests:
ALSO tests DEFINITIONS
: ;test PREVIOUS ;
: NOTFOUND 2DROP ;
PREVIOUS DEFINITIONS
work: и test: напрашиваются на рефакторинг...
А MARKER специально определён в самой библиотеке (а не взят из lib\include\core-ext.f), чтобы не зависеть от других библиотек, ну, в смысле чтобы оградить её от возможных там глюков?..
Резюме:
1. Придирка: мне не нравится свой парсер, потому что можно сделать проще.
2. Предложение: хорошо бы слово ">>>".