Интерактивный удаленный шелл и горячая замена кода

Хочется найти CL/Scheme реализацию которая умеет Erlang-подобный удаленный шел

Я не знаю, как это сделано в Erlang, но для Common Lisp есть Slime, которая умеет коннектится к удалённо запущенному лиспу.

http://www.cliki.net/SLIME-HOWTO

См. секцию Starting SLIME

В документации slime всё есть - http://common-lisp.net/project/slime/doc/html/Connecting-to-a-remote-lisp.html.

Для clojure примерно так же - http://asymmetrical-view.com/2009/08/20/emacs-slime-remote-repl.html.

Для clojure примерно так же - http://asymmetrical-view.com/2009/08/20/emacs-slime-remote-repl.html.

Лучше использовать leiningen и lein-swank плагин, после чего достаточно lein swank для запуска swank сервера. Тут есть ман: https://github.com/technomancy/swank-clojure

на сколько понял, то на удаленном хосте мне нужно запустить swank-server (тоесть запустить этот сервер внутри работающего образа, после чего можно подключаться), но если я не использую slime, то подключиться к этому серверу я не смогу? в общем случае хочется чего-то вида sbcl --connect <remote host> без сторонних приблуд прибитых гвоздями к emacs.

опять же, все сводится к тому что внутри приложения надо запустить swank-server к которому может подключиться slime, но что делать в случае когда emacs не используется?

без сторонних приблуд прибитых гвоздями к emacs.

Без emacs, один фиг, сложно будет. Как сделать такое для SBCL и CL, без emacs, я не знаю (т.к. не юзаю их).

Для Clojure в плагине Eclipse есть возможность делать remote connect через GUI.

Не претендуя на экспертность, могу предположить, что swank-server не зависит напрямую от emacs, а работает по некоторому оговоренному протоколу.

в общем случае хочется чего-то вида sbcl --connect <remote host>

Только если переписать клиент с elisp под SBCL, следую протоколу SLIME... Ну и ключа --connect, конечно, не будет, *remote-swank-host* будет выставляться с лисповой стороны.

без сторонних приблуд прибитых гвоздями к emacs.

А почему не хочется использовать emacs? Какая разница - в терминал вбивать (его ещё и rlwrap-ом надо оборачивать) или в буфер REPL-а.

sbcl --connect <remote host>

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

ну вообще такое можно написать даже на питоне.

насколько я знаю, вы хорошо знаете Haskell - можно ли там такое замутить: допустим есть приложение поверх warp-a, делаем такую библиотеку iolib, который будет по определенному протоколу коннектиться к удаленному приложению и делать горячие замены кода? Вроде в ghc 7.4 что-то такое добавили в ghci или я ошибаюсь?

А если просто слушать особый сокет, и выполнять (loop (print (eval (read))))?

это больше вопрос привычек, поскольку для разработки использую vim и мне удобней erl --remsh <node> в соседнем терминале. Плюс, опять же, ищется изкоробочное решение чтобы не получить проблем несовместимости версий и избежать поисков рабочих комбинаций версий софта и библиотек. По поводу closure (та что поверх JVM) - тут я пока предпочту Scala + JRebel (хотя удаленного шела в рабочий образ и нету). И уточню еще что для меня сейчас CL/Scheme не самоцель, скорее просто ищу платформу с динамикой в рантайме и рядом фишек из Erlang. Пока все выглядит так что используя Emacs + SLIME и нода+swank-server можно получить что-то похожее на желаемое. (Со SLIME смущает: slime-2.0 is too old for use with current versions of SBCL. Fetch slime from CVS. (http://www.cliki.net/SLIME) - это реально что оно в cvs живет? или все же есть для человеков репозиторий git/hg? опять же там написано что SLIME нацелен на работу с CMUCL, если ли реальные проблемы при работе с SBCL?). И в догонку вопрос: правильно ли понимаю что для Scheme (Racket/Gambit-C) это все не заработает и надо искать что-то другое?

такое можно много на чем написать, но хочется избежать этого написания.

опять же там написано что SLIME нацелен на работу с CMUCL, если ли реальные проблемы при работе с SBCL?).

SBCL — форк CMUCL, так что все ок.

И в догонку вопрос: правильно ли понимаю что для Scheme (Racket/Gambit-C) это все не заработает и надо искать что-то другое?

да, правильно.

тут я пока предпочту Scala + JRebel

А у JRebel есть «free as beer» или «free as speech» аналог?

Кстати, раз такая пьянка пошла, то чем можно заменить JRebel в дот-нет мире?

раздавали в свое время лицензии для Scala разработки

CL/Scheme реализацию

умеет Erlang-подобный

Termite Scheme. Он давно не развивался, но ядро там — Gambit, который развивается вполне успешно + небольшая обертка для Erlang-like.

ну вообще такое можно написать даже на питоне.

Только там не будет обновляемого машинного кода как такового, будет байткод (eval с VM напишут новый байткод, старый соберёт GC).

Вроде в ghc 7.4 что-то такое добавили в ghci или я ошибаюсь?

Там просто добавили возможность объявлять data, type, newtype, class, instance, foreign и т.п.

От хорошего REPL-а хочется чтобы тот умел

1. Сетевую прозрачность. REPL принимает запросы в виде кода и отдаёт ответы в виде результатов, обновляя при этом состояние VM. Общение между REPLом и его пользователем может происходить в том числе и через сеть по подходящему протоколу.
2. Компилировать в нативный код в памяти, желательно без задействования промежуточных файлов в ФС (в том числе в tmpfs). Код REPLа должен работать не хуже, а точно так же как и скомпилированный код.
3. Обновлять работающее приложение с помощью замены единиц трансляции со старых версий на новые (единица трансляции - функция, модуль и т.п.). Нужно исходить из того, что приложение и соответствующий инстанс VM существуют продолжительное время, так что с ним нужно уметь работатать из разных REPLов и с разных машин, и что заранее неизвестно что именно в приложении нужно обновить.
4. Быть процессом ОС и иметь локальное состояние (окружение, текущую директорию и т.д.) не зависящее от работы самого REPLа, но доступное из него, так что REPL можно использовать как shell в том числе.
5. Опционально - иметь «вкладки» (с разными потоками вода/вывода), удобные средства запуска и прекращения задач (в разных вкладках в том числе), средства наблюдения за задачами, общения между задачами, назначения и перенаправления потоков ввода/вывода для задач, удалённые задачи на других нодах в конце концов.

GHCi ничего этого не умеет. Для первого можно пускать его удалённо (по ssh, через screen) или научить быть клиентом, то есть отправлять вводимый код серверу (но какому?). Второе возможно теоретически, но если попробовать:

{-# LANGUAGE ScopedTypeVariables #-}

import Unsafe.Coerce
import GHC hiding ( load )
import qualified GHC 
import GHC.Paths hiding ( ghc )
import DynFlags
import MonadUtils

load :: String -> Ghc SuccessFlag
load path = do
  dflags <- getSessionDynFlags
  setSessionDynFlags $ dflags {
    ghcLink = LinkInMemory,
    hscTarget = HscAsm, -- or HscLlvm,
    optLevel = 3
    }
  guessTarget path Nothing >>= addTarget
  GHC.load LoadAllTargets

eval :: String -> String -> Ghc a
eval mod fn = do
  let module_name = mkModuleName mod
  findModule module_name Nothing
  setContext [IIDecl $ simpleImportDecl module_name]
  compileExpr fn >>= return . unsafeCoerce

ghc :: Ghc a -> IO a
ghc = defaultErrorHandler defaultLogAction . runGhc (Just libdir)

main :: IO ()
main = ghc $ do
  load "Ex.hs"
  result :: Integer <- eval "Main" "test"
  liftIO $ print result

то не похоже, что он компилирует. Интерпретаторов с eval, прямой или косвенной, при этом достаточно - сам GHCi, hint (http://tryhaskell.org/ через него работает), ghc-mode, plugins.

Четвёртому пункту GHCi (и haskell-mode) не соответсвуют. Пятый это что-то в сторону CloudHaskell (толком его не смотрел). Ну а третий (непосредственно горячее обновление) - я не представляю как он может быть реализован в GHC с его заточенностью на модули, файлы и интерфейсы (*.hi).

Ясно. Спасибо большое!

Посмотри в сторону Lisp Flavoured Erlang. Это такой Lisp, реализованный для Erlang VM

то не похоже, что он компилирует

Кстати, бинарник собранный с -package ghc весит 50MB, в лучших традициях лиспа :) Хотя его можно и динамически слинковать с ghc.so.

И уточню еще что для меня сейчас CL/Scheme не самоцель, скорее просто ищу платформу с динамикой в рантайме и рядом фишек из Erlang.

Если для веба, то можно ещё на node.js посмотреть.

это реально что оно в cvs живет? или все же есть для человеков репозиторий git/hg?

Официальная страничка это вот - http://common-lisp.net/project/slime/. Для использования достаточно взять slime-current.tgz, на гитхабе есть зеркало (https://github.com/nablaone/slime).

правильно ли понимаю что для Scheme (Racket/Gambit-C) это все не заработает и надо искать что-то другое?

$ ls -1 contrib/*.scm
contrib/swank-kawa.scm
contrib/swank-larceny.scm
contrib/swank-mit-scheme.scm
contrib/swank-r6rs.scm

Ещё http://en.wikipedia.org/wiki/SLIME, http://stackoverflow.com/questions/110911/what-is-the-closest-thing-to-slime-....

видел в гугле, но по описанию оно ерланговсие процесы емулирует вроде и не понятно на сколько живое и используемое

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

мне как раз для веба в сторону SaaS; на ноду смотрел, но не фанат JS. По результатам треда у меня сложилось впечатление, что для достижения желаемого в любом случае придется курить Emacs+SLIME. Еще другого плана вопрос: в SBCL можно сохранять и восстанавливать образ рабочей системы, Racket/Gambit-C такого не умеет. Такая фишка - это особенность только SBCL? (С CL знаком пока весьма поверхностно и какой интерпретатор/компилятор выбрать под свои задачи пока не представляю, но сложилось впечатление что для Linux - SBCL наиболее развитый и поддерживаемый, или лучше для экспериментов что-то другое попробовать?)

Из бесплатных SBCL - де факто стандарт. Еще есть Clozure CL, не айс, но приемлимо.

Такая фишка - это особенность только SBCL?

это особенность CL.

это особенность CL.

По-моему нет, стандарт этого не требует. Но по факту большинство реализаций так умеет, да.

Описание REPL отличное, именно такую штуку себе и хочу. Пока из коробочно наиболее близок к удовлетворению всех требований REPL Erlang. Осталось только найти кто еще к нему близок. Судя по теме то SLIME+swank-server дают большую часть, но это не совсем часть какой либо платформы.

маленький CL в лице ecl на сколько плох? и где можно найти сводную таблицу-сравнение реализаций CL и Scheme по поддерживаемым плюшкам?

Кастую в тред gensym, у него есть опыт промышленной разработки и на Erlang-e и на CL.

на ноду смотрел, но не фанат JS.

Ну, если будет сложный клиент и/или Mongo/CouchDB, то и JS.

Такая фишка - это особенность только SBCL?

Это довольно распространённая функция - save-lisp в CMUCL, save-lisp-and-die в SBCL (переименовали, так как спастись после сохранения там явно не получается), saveinitmem в CLisp, save-application в CCL, save-image в LW, build-lisp-image в ACL.

но сложилось впечатление что для Linux - SBCL наиболее развитый и поддерживаемый, или лучше для экспериментов что-то другое попробовать?

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

Кроме SBCL и Clozure CL, еще полезно в арсенале средств держать LispWorks Personal Edition, который бесплатен, но имеет ряд неприятных ограничений. Во всяком случае, свой код проверить на совместимость имеет смысл на всех этих трех реализациях.

еще полезно в арсенале средств держать LispWorks Personal Edition, который бесплатен, но имеет ряд неприятных ограничений.

а что там за ограничения? вроде что-то про размер хипа и время сессии слышал, но если так - оно мне не подходит для проверок точно.

Это довольно распространённая функция - save-lisp в CMUCL, save-lisp-and-die в SBCL (переименовали, так как спастись после сохранения там явно не получается), saveinitmem в CLisp, save-application в CCL, save-image в LW, build-lisp-image в ACL.

Значит я не могу получать снапшоты системы таким образом без рестарта системы или это локальные косяки у SBCL?

или это локальные косяки у SBCL?

По крайней мере CMUCL, SBCL и CCL так себя ведут, про остальных не знаю.

CMUCL, SBCL и CCL так себя ведут

Но не CLisp.

В SBCL можно сделать так:

* (if (zerop (iolib.syscalls:fork))
      (sb-ext:save-lisp-and-die "foo.core" :executable t)
      (format t "We are Live!~%"))
We are Live!
NIL
* [undoing binding stack and other enclosing state... done]
[saving current Lisp image into foo.core:
writing 6352 bytes from the read-only space at 0x20000000
writing 4064 bytes from the static space at 0x20100000
writing 59604992 bytes from the dynamic space at 0x1000000000
done]
* (quit) ;; тут можно продолжать, сохранился и умер только дочерний процесс (fork копирует всю память, так что такой способ прокатывает).
$ ./foo.core
* 

спасибо большое, буду пробовать осваивать SBCL для начала со SLIME. Может еще подскажете за одно какой веб-сервер можно использовать для сервиса, который отдает себя только через REST и не генерит мордочек для пользователя?

c10k ещё пока никто на CL не решал. Есть кошерный hunchentoot с моделью клиент = тред ОС, что неплохо для небольшой нагрузки. И есть разные серверы которые пытаются использовать событийную модель (antiweb, dwim.hu, teepeedee2, sw-http, cl-mongrel2). Ещё есть библиотека iolib с неплохими примерами событийных серверов и клиентов, они не годятся с точки зрения перформанса (там что-то вроде 500 rps), но можно пытаться писать что-то своё, опять же будет практика. В основном проблемы три - быстрый разбор HTTP запроса, формирование ответа лисп-кодом и формирование ответа с использование сторонних ресурсов (cgi, db, fs).

спасибо еще раз за подсказки, буду вкуривать писание REST-сервисов на CL, потом уже думать на сколько оно имеет право на жизнь

буду вкуривать писание REST-сервисов на CL

Тогда есть смысл посмотреть на restas и на блог автора. Вот, например, как там выглядит интеграция со SLIME - http://restas.lisper.ru/ru/manual/slime.html.

Вот, например, как там выглядит интеграция со SLIME

И все эти вещи (маршруты и т.п.) можно переписывать удалённо в работающем приложении, естественно.

Еще другого плана вопрос: в SBCL можно сохранять и восстанавливать образ рабочей системы, Racket/Gambit-C такого не умеет. Такая фишка - это особенность только SBCL? (С CL знаком...)

На всякий случай: Racket/Gambit-C не имеют вообще никакого отношения к CL (Common Lisp).

Тогда есть смысл посмотреть на restas и на блог автора. Вот, например, как там выглядит интеграция со SLIME - http://restas.lisper.ru/ru/manual/slime.html.

Видел, судя по докам оно идет как надстройка над hunchentoot, а выше ты говорил про поток на подключение, а на сколько я понимаю в лиспе нету зеленых потоков (SBCL, хотя тут хз, на винде у него вроде с многопоточностью совсем все плохо, хотя меня винда и не интересует, но все же), значит это потоки ОС что при нагрузке даже в 1-2к подключений будет весьма тяжко жить. Плюс судя по активности на гитхабе, archimag на него несколько подзабил.

На всякий случай: Racket/Gambit-C не имеют вообще никакого отношения к CL (Common Lisp).

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

kawa умеет telnet прям сразу http://www.gnu.org/software/kawa/Options.html#General-options

kawa умеет telnet прям сразу http://www.gnu.org/software/kawa/Options.html#General-options

а есть опыт использования kawa для продакшена? или пока оно только игрушка?

Проблема в том, что любая супер-пупер лисп-система будет бессильна, если искомое состояние будет ВНЕ ее.

Т.е. как только ты начинаешь работать со сторонней не-лисп библиотекой, просить что-то серьезное у ОС, то начинаются НЮАНСЫ.

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

В эрланге, горячая замена намного лучше организована с точки зрения продакшена.

по докам оно идет как надстройка над hunchentoot

Просто потому что кроме hunchentoot толком ничего и нет, а так ничего не мешает сделать выбор бакендов (при наличии таких) - archimag писал cl-wsal который представляет такого рода абстрактное api которое должны иметь сервера чтобы их можно было научить работать с restas. В хаскеле, например, уже состоялось подобное - есть hack2 который предоставляет общий интерфейс для happstack, snap, wrap, wai и mongrel2.

а на сколько я понимаю в лиспе нету зеленых потоков

В CMUCL зелёные потоки, но CMUCL это раритет, плюс не факт, что под hunchentoot будет работать (по крайней мере, когда я пробовал у меня не получилось).

SBCL, хотя тут хз, на винде у него вроде с многопоточностью совсем все плохо, хотя меня винда и не интересует, но все же

На sbcl.org уже есть ссылка на форк в котором с многопоточностью более менее хорошо.