[Common Lisp] Инкрементальная разработка и VCS

buzzwords:

git SLIME

hg, mq.

Subversion не нужен.

Поподробнее можно? если я в SLIME'овском REPL'е переопределил на рабочей системе функцию через defun, он мне обновит определение функции в нужном исходнике?

Поправил. Только вот VCS vs. DVCS срача тут не нужно, не об том вопрос

> если я в SLIME'овском REPL'е переопределил на рабочей системе функцию

через defun, он мне обновит определение функции в нужном исходнике?

Всё не так. Ты поправишь код по месту его определения, нажмёшь C-c C-c и SLIME отправит его в REPL. В SLIME всё превращает в REPL. REPL это не обязательно командная строка.

> Только вот VCS vs. DVCS срача тут не нужно, не об том вопрос

Аналогов mq для SVN просто нет, а mq - незаменимая вещь для инкрементальной разработки.

MQ may refer to:

• Macquarie University, Australia
• Macquarie Bank, Australia
• Magic Quadrant, a market analysis visualization method proprietary to Gartner
• Martinique: country code within ISO 3166-1 alpha-2
• Merseburg-Querfurt, a district of Germany
• Message queue, in computer science
• Metol and hydroquinone, a mixture used to develop photographic film
• Midway Islands: territory code within FIPS PUB 10-4
• Museumsquartier, a cultural area of Vienna, Austria
• WebSphere MQ, a computer software product from IBM
• Mech Quest, a game by Artix Entertainment.
• MQ: American Eagle Airlines's IATA Code.
• MQ: multi-role (M) unmanned aircraft system (Q) (1962 United States Tri-Service aircraft designation system—United States Department of Defense code)

Какое из этих значений вы имели в виду?

> mq - незаменимая вещь для инкрементальной разработки.

Не в контексте CL.

Хорошо, понятно. А есть какое-нибудь редакторонезависимое решение?

Внезапно, http://mercurial.selenic.com/wiki/MqTutorial

>> mq - незаменимая вещь для инкрементальной разработки.

Не в контексте CL.

Независимо от языкового контекста.

Блин, вот не осталось больше на ЛОРе людей, которые никогда лажу не писали, я думал что ты последний, а вот оказалось что нет :(

> А есть какое-нибудь редакторонезависимое решение?

Любая среда для CL работает аналогичным образом. Использовать CL без специальной среды не имеет смысла.

> Блин, вот не осталось больше на ЛОРе людей, которые никогда лажу не писали, я думал что ты последний, а вот оказалось что нет :(

Осталось.

Потому что я снова прав :D

> Любая среда для CL работает аналогичным образом.

CUSP тоже?

Да нет же. Я тебя очень уважаю hg с mq еще больше, но истина дороже :)

Смотри, что чувак хочет. У него есть интерпретатор лиспа (или лисп-машина, не важно).

Он в ней делает хаки разные, прямо в интерпретаторе, не сохраняя ничего в ФС. Потом хочет эти свои хаки засинкать с файловой системой и VCS. каким боком тут mq поможет?

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

> У него есть интерпретатор лиспа (или лисп-машина, не важно).

Он в ней делает хаки разные, прямо в интерпретаторе, не сохраняя ничего в ФС. Потом хочет эти свои хаки засинкать с файловой системой и VCS. каким боком тут mq поможет?

У него всё равно есть дерево исходных кодов. И после сеанса хаков в запущенном образе системы ему нужно обновить это дерево; то же самое - после следжующего сеанса. Собственно, вот он и пришел к mq.

> а если посылать в интерпретатор минуя ФС, то тут уже только спец-плагин, скидывающий все в ФС поможет.

или свой defun с hg и mq

Весь вопрос КАК ему обновить дерево исходных кодов.

> Собственно, вот он и пришел к mq.

Ну и? Сказал «а» говори «б», как здесь конкретно поможет mq? выдернет из Lisp-образа скомпилированные функции, декомпилирует, угадает, где они были определены, обновит исходник?

> или свой defun с hg и mq

...а также defgeneric, defmethod, defclass и ещё кучку def*-ов.

>> Собственно, вот он и пришел к mq.

Ну и? Сказал «а» говори «б»

Я бы сказал «б», но, судя по:

Ignatik> выдернет из Lisp-образа скомпилированные функции

и

Ignatik> ...а также defgeneric, defmethod, defclass и ещё кучку def*-ов.

ты просто не понимаешь, о чем идет речь.

понятно, по существу ответить не можете

Лисп не подходит для интерпрайза. Успокойся, пожалуйста

Вас что-то беспокоит, хотите поговорить об этом?

А есть какое-нибудь редакторонезависимое решение?

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

> в стдин запущенного repl

SLIME работает не так, возможности взаимодействия через stdin очень ограниченные, SLIME взаимодействует со SWANK-сервером по сокету с помощью специального протокола.

SLIME работает не так

Это понятно.

Но разве, просто гипотетически, досылка кода, просто в ввод repl, не приведет к замене кода в образе?

Если нет, то есть под рукой, чтиво, для ознакомления, какие там еще манипуляции производятся?

>> mq - незаменимая вещь для инкрементальной разработки.

Не в контексте CL.

а как в контексте CL решается следующая задача (упрощенно):

допустим, у нас есть 5 каких-либо функций, и у каждой есть 3 версии А, В, С

нам нужно легко переключаться между

1. проектом, в котором все функции имеют версию А,

2. проектом, в котором все функции имеют версию В,

3. проектом, в котором все функции имеют версию С

кстати, эта же функциональность имхо нужна везде, например в фотошопе

допустим, у нас есть 3 надписи, и нам надо посмотреть их все

1. синим цветом и шрифтом А

2. синим цветом и шрифтом В

3. фиолетовым цветом и шрифтом А

4. фиолетовым цветом и шрифтом В

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

что в данном случае выручает гуманитариев? наверное, особый Гуманитарный Склад Ума

в 3д-максе можно было линковать друг с другом атрибуты (хотя и гемора все же много), а в фотошопе, как я его знал (где-то до 6 версии) ничего такого не было

> а как в контексте CL решается следующая задача (упрощенно):

допустим, у нас есть 5 каких-либо функций, и у каждой есть

3 версии А, В, С

git checkout? Только при чём здесь инкрементальная разработка в CL? Впрочем, следующий пост

фотошоп

что в данном случае выручает гуманитариев? наверное,

особый Гуманитарный Склад Ума

3д-макс

Показывает влияние веществ, довольно сильных.

> Но разве, просто гипотетически, досылка кода, просто в ввод repl,

не приведет к замене кода в образе?

Это не совсем верно. Если перекомплировать определение функции, то с символом свяжется новый код, поэтому это не совсем «замена». Кроме того, просто выполнение кода в REPL соответствует стадии :execute, в то время как команда C-c C-c (slime-compile-defun) обеспечивает стадию :load-toplevel, которая имеет несколько отличную семантику, плюс при этом сохраняется информации о позиции нового определения в буфере (так что его легко найти с помощью M-.), а также так лучше работать с сообщениями компилятора. Для полной эмуляции оправки в REPL используется C-M-x (slime-eval-defun), но для типовой работы обычно лучше подходит C-c C-c. Всё это описано в доке на SLIME.

Всё понятно. Спасибо за разъяснения.

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

я догадывался, что он сломает твои шаблоны, и в целях предосторожности адресовал его не тебе

ну а вопрос в предыдущем посте? ты на него ответишь, или нет?

git checkout? Только при чём здесь инкрементальная разработка в CL?

то есть ты хочешь сказать, что инкрементальная разработка в CL никак не реализует вышеописанную мной упрощенную версию моих потребностей?

__________________________________________

полная версия потребностей обычно выглядит так: скомбинировать версию А одной группы функций с версией В другой группы и с версией А третьей группы; погонять; далее скомбинировать версию А одной группы функций с версией В другой группы и с версией С третьей группы; ...

инкрементальная разработка

полная версия потребностей…

В моём представлении то, что ты хочешь, к инкрементальной разработке имеет весьма опосредованное отношение.

> сломает твои шаблоны

Таки да, шаблон сломался, при чём здесь инкрементальная разработка? Просто очень интересно даже стало это узнать.

> полная версия потребностей обычно выглядит так: скомбинировать версию А одной группы функций с версией В другой группы и с версией А третьей группы; погонять; далее скомбинировать версию А одной группы функций с версией В другой группы и с версией С третьей группы; ...

Stellation is dead, get over it.

> Таки да, шаблон сломался, при чём здесь инкрементальная разработка? Просто очень интересно даже стало это узнать.

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

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

не понял, раскрой тему

кстати, вот еще надо аналогичный вопрос поднять где-нить тут — способность NTFS к транзакции записи, в которой участвуют несколько файлов — это хорошо или плохо? есть ли юниксовые аналоги?

> У него всё равно есть дерево исходных кодов. И после сеанса хаков в запущенном образе системы ему нужно обновить это дерево;

Откуда возьмется дерево исходных кодов, если он хакал в репле? Боженька даст?

> не понял

Лет 10 назад была в разработке такая система - Stellation. Она умела версионировать артефакты языка - классы, методы и прочее. Умерла тихой смертью или была засекречена - ХЗ, но исчезла.

> и неужели тебе никогда не хочется откатиться назад

Инкрементальная разработка никак не связана с «откатиться назад». наоборот - откаты там невозможны. В принципе. Только внесение новых изменений.

> Откуда возьмется дерево исходных кодов, если он хакал в репле? Боженька даст?

Ну откуда-то же берутся все эти файлы с суффиксом .lisp... хотя, может, их ради прикола сохраняют, а реальные Лисп-программы не выходят за пределы REPL.

> Ну откуда-то же берутся все эти файлы с суффиксом .lisp... хотя, может, их ради прикола сохраняют, а реальные Лисп-программы не выходят за пределы REPL.

Какие файлы? Откуда взялись файлы? Вот я запустил репл, написал (defun fun () «hello qworld»), выключил репл. Где твои файлы?

> Вот я запустил репл, написал (defun fun () «hello qworld»), выключил репл. Где твои файлы?

А где твоя fun?

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

http://archive.eclipse.org/technology/archives/stellation-project.tar.gz

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

> А где твоя fun?

После выхода из репла? В образе.

Потом хочет эти свои хаки засинкать с файловой системой и VCS

Частично в этом может помочь dribble, но это все равно фигня, править надо исходниые файлы.

> Какие файлы? Откуда взялись файлы? Вот я запустил репл, написал (defun fun () «hello qworld»), выключил репл. Где твои файлы?

Сколько же упёртых людей, которые никак не хотят понять простой вещи: def'ы, с нормальным REPL, не объявляют в нём, а объявляют в реальных файлах(в случае emacs это может быть не сохранённый буфер), которые можно(и, обычно, нужно) сохранить. А в REPL посылают уже конкретную реализацию функции из файла.

В самом REPL уже не вводят тела функций(попробуйте ввести там функцию состоящую строчек из 5 раз 5-6, поймёте, что это дико неудобно).

Поэтому исходный код всегда будет в наличии(по крайней мере в буферах emacs), главое не забывать его сохранять и юзать VСS любимую.

Имхо, проблема топикстартера в том, что он ещё не совсем понял, как юзать REPL(не пробовал?).