Когда я захочу изучить тонкости Read-Evaluate-Print Loop (REPL), в частности, как работает сервер Tornado, IPython kernel, как работать с сокетами..., zeromq - Distributed Computing Made Simple я использую ссылки из этого поста...
Зачем мне знать, как работает IPython Notebook? Сейчас я знаю, что сервер запускается по команде "IPython Notebook" из консоли. При этом корневая папка сервера создается при первом запуске, называется ".ipynb_checkpoints" и помещается в директорию, из которой быда запущена команда консоли. Таким образом, полагаю, удобно не валить все в кучу, а задавать (и запускать при желании - одновременно) разные серверы...
Сервер взаимодействует с браузером по протоколу HTTP (естественно) Редакатирование данных в окнах браузера осуществляется при помощи javascript.
Иногда странички в браузере "подвисают", но пока все решалось перезапуском сервера из консоли (cmd.exe).
Другую проблему - куда и как помещать файлы (javascript, text, html), чтобы их можно было загружать через сервер, мы решили в предыдущем посте (сервер видит все подпапки из "корня" - .ipynb_checkpoints)
Сервер взаимодействует с браузером по протоколу HTTP (естественно) Редакатирование данных в окнах браузера осуществляется при помощи javascript.
Иногда странички в браузере "подвисают", но пока все решалось перезапуском сервера из консоли (cmd.exe).
Другую проблему - куда и как помещать файлы (javascript, text, html), чтобы их можно было загружать через сервер, мы решили в предыдущем посте (сервер видит все подпапки из "корня" - .ipynb_checkpoints)
Пока мне этих знаний достаточно. Конечно, хотелось бы знать, как работает сервер, как подгружаются скрипты..., регулярно выскакивает ошибка с загрузкой jQuery (например)..., но пока не вижу смысла "лезть глубже"... Потому здесь дальше просто перечислим ссылки, которые понадобятся для более глубокого изучения процессов работы сервера.
IPython has abstracted and extended the notion of a traditional Read-Evaluate-Print Loop (REPL) environment by decoupling the evaluation into its own process. We call this process a kernel: it receives execution instructions from clients and communicates the results back to them.
This decoupling allows us to have several clients connected to the same kernel, and even allows clients and kernels to live on different machines. With the exclusion of the traditional single process terminal-based IPython (what you start if you run ipython without any subcommands), all other IPython machinery uses this two-process model. This includes ipython console, ipython qtconsole, and ipython notebook.
This decoupling allows us to have several clients connected to the same kernel, and even allows clients and kernels to live on different machines. With the exclusion of the traditional single process terminal-based IPython (what you start if you run ipython without any subcommands), all other IPython machinery uses this two-process model. This includes ipython console, ipython qtconsole, and ipython notebook.
Ø The socket library that acts as a concurrency framework.
Ø Carries messages across inproc, IPC, TCP, and multicast.
Ø Connect N-to-N via fanout, pubsub, pipeline, request-reply.
Ø Asynch I/O for scalable multicore message-passing apps.
Ø Large and active open source community.
Ø 40+ languages including C, C++, Java, .NET, Python.
Ø Most OSes including Linux, Windows, OS X.
Ø Free software with full commercial support.
Ø Carries messages across inproc, IPC, TCP, and multicast.
Ø Connect N-to-N via fanout, pubsub, pipeline, request-reply.
Ø Asynch I/O for scalable multicore message-passing apps.
Ø Large and active open source community.
Ø 40+ languages including C, C++, Java, .NET, Python.
Ø Most OSes including Linux, Windows, OS X.
Ø Free software with full commercial support.
Посты чуть ниже также могут вас заинтересовать
Комментариев нет:
Отправить комментарий