на главнуюВсе эхи RU.ALGORITHMS
войти ?

Make vs. data processing

От Ivan Shmakov (2:5020/400) к All

В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)


From: Ivan Shmakov <ivan@main.uusia.org>

Есть такой общеизвестный и популярный инструмент, как Make [1].
Хотя изначально оный предназначался для сборки программ (и в
этом преуспел), кое-кто, включая меня и моих коллег, имеет опыт
применения его в обработке результатов разнообразных физических
экспериментов (включая данные дистанционного зондирования Земли
и моделирование методами Монте-Карло.)

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

∙ Зависимости формулируются на языке имен файлов, а не на языке
свойств (список пар имя-значение, RDF, etc.)

∙ Порядок обработки не считается важным, пока он удовлетворяет
указанным зависимостям.

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

Первую проблему можно обойти кодируя свойства в имени файла, или
же препроцессором. Однако, первое легко приводит к проблемам,
если полный набор требуемых метаданных не известен заранее, да
это и едва ли удобно с точки зрения читаемости таких имен,
e. g.:

2006-08-09-tile-22-3.surface-reflectance-by-2006-08-08-brdf.7.okay-qa

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

Вторая проблема приводит к возможности поведения типа <<ленивый
студент>>: <<поскольку у меня хорошо получается первый этап
обработки, для начала выполню его для всех 999
образцов...>> А тут неслышно подкралась защита. И вместо хотя
бы одного полезного результата, получаем уйму промежуточных...
IOW, бесполезных. Ясно, что приоритет обработки должен быть тем
выше, чем ближе цель в графе зависимостей к конечной цели.

(К слову, поздравляю с защитами тех, кто причастен.)

Hаконец, третья проблема особенно актуальна, если
вспомогательные данные требуется получать из удаленных архивов
через Internet. Hа конкретном зеркале могли проводить
профилактику, или же файл нужный пока еще не появился, или
поставщик услуг подвел... Сколь полезны здесь retry и delay!
Hу, или наоборот.

В общем, возникли некоторые идеи по решению этих проблем (см., в
частности, [2].) Текущее их состояние -- около 1024 строк кода
на Prolog (ядро системы.) Если окажется, что в этом есть некая
новизна, я с радостью подготовлю статью, доклад на конференцию,
свободный программный пакет, да и, с должной скромностью, внесу
соответствующую строку в свои <<положения, выносимые
на защиту.>>

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

(Отдельная благодарность тем, у кого хватило терпения добраться
до сего момента.)

[1] http://en.wikipedia.org/wiki/Make_(software)
[2] news:comp.lang.prolog

--
FSF associate member #7257
--- ifmail v.2.15dev5.4
* Origin: Aioe.org NNTP Server (2:5020/400)

Ответы на это письмо:

From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку

From: Username
Или коротким

FGHI-url этого письма: area://RU.ALGORITHMS?msgid=<1187402445@violet.siamics.net>+63b8eb8e