Re: From Pyro to IPython/Jupyter
"Osborn, Raymond" <[email protected]>
| Newsgroups | gmane.comp.python.ipython.devel |
|---|---|
| Message-ID | <[email protected]> |
Frederic, We have been testing the use of Pyro4 as a method of loading remote NeXus files within NeXpy, which also uses a Jupyter shell (http://nexpy.github.io/nexpy/). It’s not part of the official distribution yet, but I would be happy to discuss it with you outside this list. As a fellow neutron scatterer, it might be relevant. Ray On Dec 2, 2015, at 7:27 AM, Frédéric Mantegazza <[email protected]<mailto:[email protected]>> wrote: Le 02/12/2015, Thomas a écrit : You could make a custom execution environment which only exposes a particular set of commands relevant to e.g. controlling a mass spectrometer. But broadly, a kernel is there to be the execution backend for a user typing in code, not an RPC framework. If you're happy with the way you use Pyro, you'd probably have to do quite a bit of work to reimplement a similar interface on top of our kernel/client model. When we started to develop our application (aka PyMAD), we had in mind to push the instrument responsible to dig into python, and offer him something closer to a framework, rather than a end-user application. This, because this guy is someone with 1000 ideas per hour, and often asks for new stuffs. So, giving to him such (very) high level tools to control his instrument could have been nice. But He never dig enough into python to be able to do so. I don't blame him at all, as it is not easy to change habits. Python was new to him... But he is about to retire, at the end of this year, and the new responsible is younger, and uses python to treat his scientific datas. So, I think it could be nice, this time, to implement what we always wanted to do. Saying this, it appears to me that we don't really need a RPC-like framework, and exposing all the internals of the application could be great. We will have to find a mecanism to hide some parts for simple users using the instrument, to avoid them to brake things during their experiment (:o/), but I think it can be done without too much work. On the other hand, having the jupyter mecanism, and being able to start a session from one place, in a pure console, or in a qtconsole, them go back home and switch to a web-based console to continue to work from the same point is really great. Last, it appears that Pyro4 dropped some features mandatory for our application, like the event service! So, we are stuck to the 3.x version... That's why I want to explore this idea. -- Frédéric MANTEGAZZA CEA-Grenoble Tel. : 33 (0) 476 207 617 INAC/SPSMS/MDN Fax : 33 (0) 476 483 906 17, rue des Martyrs Courriel : [email protected]<mailto:[email protected]> F-38054 Grenoble Cedex 09 _______________________________________________ IPython-dev mailing list [email protected]<mailto:[email protected]> https://mail.scipy.org/mailman/listinfo/ipython-dev -- Ray Osborn, Senior Scientist Materials Science Division Argonne National Laboratory Argonne, IL 60439, USA Phone: +1 (630) 252-9011 Email: [email protected]<mailto:[email protected]> _______________________________________________ IPython-dev mailing list [email protected] https://mail.scipy.org/mailman/listinfo/ipython-dev