В чём плюсы image-based разработки?

В статически типизированном да, но в лиспе хоть и есть такие возможности, но их мало используют.

В sbcl работает (почти везде).

проблемы могут возникнуть исключительно в том случае когда ты что-то подправляешь непосредственно из repl'консольки минуя свой исходник.

Я же писал.

Пишем в файле и компиилруем через C-c C-c

(defmacro foo (x)
  `(list ,x 1))

(defun bar ()
  (foo 2))

(defun baz ()
  (foo 3))

Потом исправляем и компилируем

(defmacro foo (x)
  `(list ,x 2))

Потом делаем код baz как у bar

(defun baz ()
  (foo 2))

Тестируем в REPL

> (bar)
(2 1)
> (baz)
(2 2)

В файле

(defmacro foo (x)
  `(list ,x 2))

(defun bar ()
  (foo 2))

(defun baz ()
  (foo 2))

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

Я тут еще посмотрел доки для lispworks. Там есть такая штука как «сохраненная сессия» (термин), если ты совсем хочешь вести разработку image-based в духе smalltalk, только без исходников. Это когда текущий «запущенный образ» (термин) сохраняется на диске. Потом можно восстановиться, загрузив «сохраненный образ» (термин). Вопрос только в том, можно ли сделать delivery, т.е. создать бинарник.

Бинарник, вообще-то, по сути тоже является сохраненным образом, на который просто натравили tree shaker и обфускатор. Кажется, там основная проблема в том, что для delivery нужно отрубать многопоточность. Например, при сохранении сессии многопоточность тоже отрубается перед сохранением.

Быть может, что и delivery можно сделать по запущенному образу или на худой конец по сохраненному образу. Наверняка, последнее возможно (надо проверять). Тогда может возникнуть гипотетическая возможность, вообще, разрабатывать без исходников, но зачем это только надо? Возникнет та же проблема с измененным глобальным макросом, и что тогда делать?

Чорд, а ведь тебя в лиспотредах реально не хватало! Была одна скука и уныние. С возвращением!

Кроме того, что image-based хреново работает со стандартными средствами командной строки — ничего.

не факт. вот под BlackBox Component Pascal (Оберон-2) есть такой модуль-сервер, который берёт команду из клиента и выполняет её «в образе». там пересборка программы/системы делается «почти» как в REPL, только defsystem/asdf по факту дефолтного нет, пишут какой-то свой велосипед с топологической сортировкой модулей, принудительной выгрузкой загрузкой.

там тоже ручная работа почти как в REPL. написали модуль, скомпиляли, щёлкнули по «коммандеру» (как в ворде cмарттеги) => модуль автоматически загрузился, и процедура, написанная рядом с коммандером выполнилась. так тесты например делают.

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

команды могут брать свои аргументы из текста (например, можно писать тесты после окончания текста модуля). в общем-то похоже на REPL, только нет рестартов и принудительно приходится прерывать и останавливать на уровне модулей.

так вот, там для сборки через make пишут свой велосипед. клиента командной строки, который через UDP шлёт команду модулю-серверу, который сидит «в образе», интерпретирует её, и выполняет (сортирует модули топологической сортировкой, выгружает клиентов, перезагружает сервер, загружает клиентов).

так что обычные тулзы через image-based подход легко выражаются.

например, в Corman CL, Ufasoft, BEE LISP под винду лисп реализован COM-объектом. ЕМНИП, в Lispworks тоже что-то похожее.

ничто не мешает прикрутить make/jam/ant/gradle к такому клиент-серверному модулю в образе, и собирать ими.

Спустя некоторое время обновляю sbcl. Загружаю свой проект: опа, не компилируется. Оказывается, разные файлы скомпилировались с разными версиями макроса (и синтаксис, соответственно имели под разные версии).

делаешь систему, макросы в пакет-подсистему, клиентов макроса в пакет-надсистему. надсистема зависит от подсистемы через asdf/defsystem/... . при каждом изменении макроса пересобираешь/перегружаешь подсистему и надсистему.

почему бы этому не работать?

А GTK3 под windows распространять можно? Насколько я помню, билдскриптов под неё не существует.

"- Хм, странно, " — сказал Вовочка. — " Жопа есть, а билдскриптов слова нет"

вот тут были, самые полезные с http://www.tarnyko.net но сайт сдох.

а вообще OpenSUSE_Factory , и кросскомпиляция во все поля

ну или + MXE / IMCROSS

в случае с лиспом я могу прицепиться к процессу на удалённой машине, посмотреть проблему и даже исправить её на лету

Машинный код поправить нельзя, это да. Данные - по крайней мере теоретически можно.

и данные нельзя. зависит от времени жизни. допустим, объект С++ упал, внезапно вызвался деструктор. объект разрушен, но ссылка на него осталась. ссылку разыменовывать низзя, и данные объектов, в которых транзитивно эта ссылка используется править тоже низзя. данные объектов, которые транзитивно связаны по времени жизни с этими — тоже использовать низзя, вдруг они попытаются вызвать метод разрушенного объекта?.

рестартов нету, поэтому после исправления данных можно только упасть, но не отжаться.

не факт.

Факт.

почти как в REPL.

При чём тут REPL?

ничто не мешает прикрутить make/jam/ant/gradle

grep/sed/awk...

grep/sed/awk...

ну и ? пишется очередной модуль, который сидит в образе. он будет выгружать из образа в текст и загружать из текста. потом какая-то среда сборки, которая выгрузит в текст, запустит на нём grep/sed/awk... , даст выхлоп в скрипт, получит команду через клиент-сервер по TCP из CLI клиента, запускаемого из скрипта, с параметром выхлопа, сделает что-то с этой командой с образом.

в итоге, среда сборки + CLI клиент + серверный модуль в образе делают всё то же самое, что и среда сборки + отдельный компилятор, только дёргают не отдельный процесс-компилятор, а серверный-модуль-в-образе-фронтенд-к-компилятору-или-среде-сборки

или пишется свой sed/grep/awk в образе :))

сильного велосипедостроительства можно избежать, если написать вместо клиент-сервера в образе какой-то FUSE модуль в ядре :))

«виртуальная ФС» через FUSE напрямую отображается в образ, и доступна из него в обе стороны.

всё, что работает с ФС, автомагически работает и с образом. осталось только в виде ФС данные из образа вытащить, но это уже какой-то Plan 9 получается :)

потом, есть же файлы /proc/PID/fd, /proc/PID/..., которые автоматически поддерживаются ядром. вот пусть это /proc/PIDобраза/логическийПутьвФС образ сам и поддерживает.

вот тут были

Они все подразумевают использование линукса и/или OpenSuSE Factory.

Я верно понимаю, что к примеру программа под GPL может быть написана на Microsoft FoxPro? А если кто-то напишет компилятор языка, на этом языке напишет программу под GPL, выложит исходники, но компилятор распространять не будет, то он тоже выполнит условия GPL?

Они все подразумевают использование линукса

там была ссылка про GTK2 и сборку из-под виндового MinGW. но кросскомпилятор из-под линукса как-то стабильнее работает.

Я верно понимаю, что к примеру программа под GPL может быть написана на Microsoft FoxPro? А если кто-то напишет компилятор языка, на этом языке напишет программу под GPL, выложит исходники, но компилятор распространять не будет, то он тоже выполнит условия GPL?

вроде бы да

или, если под винду, берётся рамдиск с исходниками и конструируется «виртуальная ФС образа» по образу Plan 9 :))

например, виртуальная ФС типа система:/пакет/файл.lisp/функция-или-макрос{,/символN-определённый-в-функции}. то есть, логическое пространство имён. делаем в asdf зависимости между системами в этой **логической** ФС. вешаем в драйвере виртуальной ФС хуки на «обновился файл, вызвался хук»; вызвался хук, распарсил путь в логической ФС, определил правило из движка правил, вызвал обработчик.

и потом через простой cp копируем в образ или из образа.

а при этом автомагически что-то в образе компилируется.

или, наоборот, скинуть из образа в билдсистемо-подобную надстройку над обычными текстовыми файлами.

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

Машинный код поправить нельзя, это да. Данные - по крайней мере теоретически можно.

и данные нельзя.

А данные можно.

зависит от времени жизни

Не правь те, время жизни которых кончилось. Это в любом случае бессмысленно.