Вопрос касательно SPF4.18
Как в анекдоте -- а в чем подвох? Вот я не смог на этот вопрос ответить... Действительно, зачем этот каталог нужен, что в нем лежит?

Да, теорию, как и все, я знаю. Однако, наша объективность -- практика. По теории, там лежат наиболее часто используемые абстракции, конструкции и просто часто используемый и отлаженный код. Верно? К сожалению, нет. Посмотрите содержимое каталога devel -- что не автор, то свои библиотеки. Почему? Может есть причина?

История возникновения вопроса.

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

С моей точки зрения -- возможности системы отражает именно содержимое каталога lib. А что в нем сейчас находится?

Лежит у двух - ~ac и ~yz. И эти две реализации существенно различаются в обработке таблиц - первая выдаёт всё строками (a u), а во второй есть типизация.
В ~pinka и ~ygrek дополнения к ним.

По поводу lib - да, было бы неплохо там собрать на самом деле наиболее часто использующиеся либы.

а кто их поддерживать будет?
А вообще, достаточно положить пустышки с линками ( S" ~author/lib/somelib.f" INCLUDED ) на авторские библиотеки, дабы не такскать их туда сюда.

Также как и сейчас само ядро. Должна же быть точка опоры

Существующий механизм -- кто-то активно работает с библиотекой, находит баг, устраняет его. Сообщает в рассылке об это. Кому интересно подключаются. Проверяют. Работает? Включаем исправление.

Я вот как раз за то, чтобы общие библиотеки были в общем месте Если авторы, конечно, не против.

А как определять, что является "наиболее часто используемым", и насколько часто это делать?

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

>С моей точки зрения -- возможности системы отражает именно содержимое каталога lib. А что в нем сейчас находится?

Там находятся портированные в SPF широко известные библиотеки|компоненты и расширения ядра. И это правильно.

Возможности же системы (SPF как пакета) лучше отражать в отдельном документе, что уже и делается

Давно интересовал вопрос об упорядочивании поиска подключаемых либ.
А то, что не пример, то заморочки с компиляцией:)

P.S. Идея с указанием пустышек в каталоге либ или создания для spf
конфигурационного файла со ссылками на либы может быть решила
частично данную проблему.

Что имеется ввиду?

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

P.S. Так понятнее?

Глюкодром. Если неизвестное слово встретится в режиме компиляции, вам придётся откатываться назад, подключать нужную либу и продолжать компиляцию всего проекта сначала. Отлавливать баги с дубликатами слов при этом будет вообще одно удовольствие.


Это вообще кошмар. Почему тогда просто не вписать в проекте правильные пути REQUIRE, если эти пути всё равно надо прописывать явно?

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

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

Моя практика компилирования проекта указанием относительного
расположения spf.exe от текущего проекта ( ..\..\spf.exe файл.f ).

Вот еще:)

http://groups.google.com/group/comp.lan ... cf425b1c17

I'm testing SP-Forth [http://sourceforge.net/projects/spf/] to run an
ANS Forth application of mine and I need to set the default paths for
all file operations.

I have searched into its documentation but I did not find anything
about file paths but a file (devel/~pinka/samples/2005/lib/lay-path.f)
that "provides words for lay a path to file (creating non-existent
folders)". That's not really what I need. I could use that solution,
but I would have to add a new layer in my code and then adapt it back
to run in other ANS Forths.


I need something transparent and simpler, like the "General Search
Paths" words of gforth.


If needed, I could adapt the SP-Forth code myself but perhaps someone
has had the same problem before.


Thank you


Marcos

Никакой привязки к абсолютным путям в SPF нет при использовании файлов из дерева установки spf или относительно своего проекта (который может быть не в devel).
Поиск происходит следующим образом - S" file.f" INCLUDED будет искать - сначала просто короткое имя file.f, потом SPF_PATH/devel/file.f, потом SPF_PATH/file.f Если этих путей недостаточно, можно переопределить FIND-FULLNAME(который вектор) или воспользоваться моим решением - ~ygrek/lib/included.f
Тогда достаточно прописать (например в spf4.ini) что-то вида

или немного более низкий уровень

и файлы будут искаться также в my_path в дополнение к вышеперечисленному алгоритму.

PS За ссылку спасибо, сейчас скопирую этот же ответ туда.