LINUX.ORG.RU

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

 , ,


0

4

Доброго времени суток, ЛОР

Хочется найти CL/Scheme реализацию которая умеет Erlang-подобный удаленный шел, и возможность замены кода без остановки системы. На сколько понимаю, со вторым особых проблем не должно быть, а для первого пока нагуглил только запуск окружения в screen, что мне не нравится. Может еще подскажет кто платформы с подобным функционалом? Сейчас в голову только Erlang и приходит.

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

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

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

См. секцию Starting SLIME

Norgat ★★★★★
()
Ответ на: комментарий от Norgat

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

SlothSpot
() автор топика
Ответ на: комментарий от quasimoto

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

SlothSpot
() автор топика
Ответ на: комментарий от SlothSpot

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

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

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

Norgat ★★★★★
()
Ответ на: комментарий от SlothSpot

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

dave ★★★★★
()
Ответ на: комментарий от SlothSpot

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

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

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

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

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

sbcl --connect <remote host>

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

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

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

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

anonymous
()

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

dave ★★★★★
()
Ответ на: комментарий от quasimoto

это больше вопрос привычек, поскольку для разработки использую 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) это все не заработает и надо искать что-то другое?

SlothSpot
() автор топика
Ответ на: комментарий от quasimoto

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

SlothSpot
() автор топика
Ответ на: комментарий от SlothSpot

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

SlothSpot
() автор топика

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

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

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

buddhist ★★★★★
()
Ответ на: комментарий от anonymous

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

Только там не будет обновляемого машинного кода как такового, будет байткод (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).

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

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

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

quasimoto ★★★★
()
Ответ на: комментарий от SlothSpot

И уточню еще что для меня сейчас 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-....

quasimoto ★★★★
()
Ответ на: комментарий от buddhist

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

SlothSpot
() автор топика
Ответ на: комментарий от theNamelessOne

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

SlothSpot
() автор топика
Ответ на: комментарий от quasimoto

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

SlothSpot
() автор топика
Ответ на: комментарий от SlothSpot

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

slav ★★
()
Ответ на: комментарий от quasimoto

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

SlothSpot
() автор топика
Ответ на: комментарий от anonymous

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

SlothSpot
() автор топика
Ответ на: комментарий от SlothSpot

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

anonymous
()
Ответ на: комментарий от SlothSpot

на ноду смотрел, но не фанат 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 выглядит лучше всего.

quasimoto ★★★★
()
Ответ на: комментарий от SlothSpot

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

dave ★★★★★
()
Ответ на: комментарий от dave

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

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

SlothSpot
() автор топика
Ответ на: комментарий от quasimoto

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

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

SlothSpot
() автор топика
Ответ на: комментарий от SlothSpot

В 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
* 
quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

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

SlothSpot
() автор топика
Ответ на: комментарий от SlothSpot

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

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

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

SlothSpot
() автор топика
Ответ на: комментарий от quasimoto

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

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

quasimoto ★★★★
()
Ответ на: комментарий от SlothSpot

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

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

korvin_ ★★★★★
()
Ответ на: комментарий от quasimoto

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

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

SlothSpot
() автор топика
Ответ на: комментарий от korvin_

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

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

SlothSpot
() автор топика

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

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

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

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

Macil ★★★★★
()
Ответ на: комментарий от SlothSpot

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

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

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

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

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

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

quasimoto ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.