-
Notifications
You must be signed in to change notification settings - Fork 310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remote PsySH #121
Comments
Yes. That is the (eventual) plan. If you'd like to see it sooner, we'd happily accept a pull request :) |
@bobthecow I started working on this and ran into a few ways of doing it. I sent you an email, maybe you could point me the right direction on how you would like to see it going? I could paste it in here if that makes it easier. |
Yes, you did. Sorry, I haven't had a chance to answer. I'll get on that :) |
What about an input_server on one port, and output_server on another port. The client would connect to both of them based on the configuration. That way we keep the same abstraction we have now, but we'd have to maintain two connections. Thoughts? |
I originally thought that this would be a good opportunity to refactor a bit of the PsySH internals and make it use more of a client/server model for regular use as well. Essentially, split out the readline/input and stdout/output into a "Client", and move the execution loop into a "Server", both of which are owned by the Shell app. This way you could use The more I think about it, the deeper this rabbit hole gets, though, so it might be worth writing a simpler version now and working toward that in the future :) |
The bare minimum you'd need is a socket-based |
:) |
Any progress on this? Is there a branch or fork where it's being worked on @Markcial? |
I had in fact a experiment that worked, but needs heavy refactor of the shell class, in order to have the experiment working the shell needs a public api of the eval method, so a websocket server is listening for incoming connections and preserve the context. I will dig back in time in my git history, maybe the experiment is still there, ping you back in a couple of days. |
That would be awesome |
Any update on this? |
+1 |
I know that it would be a killer feature. I heavily tried to get it working successfully, but the inner design of PHP makes really hard to share states and object representations between PHP threads. And PHP is meant to be used as a single shot worker, not a daemon serving data. The feature would work for simple variables and states that can be easily serialized in json, but not for complex objects that might include things like sockets, resources, closures, and so on. For unserializable objects this feature would be a complete dead end, i am sorry about this. I will try to post the source of the samples, but i will have to start again from scratch because seems that i lost the source on some backup. |
@Markcial, maybe we should start by getting in the abstraction layer that just works for the current implementation so this isn't such a large project? You probably already have this done, so maybe just tear the rest out for now? Or maybe there's another way to break up this work? It seems like there is a LOT of interest, so making this a more iterative approach is probably the best option. |
Another solution would be to replace the interactive shell of the IDE when On Friday, 18 March 2016, Blaine Schmeisser notifications@github.com
|
I appreciate the interest on this feature but currently i have a lot of code waiting for review that would imply subsequent newer features, the code completion currently needs some eval of the current object for example, currently the PySH shell doesn't haves a somewhat public api for evaluating objects. The interactive shell via browser needs too that public api for evaluating. There is a lot of stuff going on, and before getting this thing done, those features would need get to master, not all, but the ones that imply a non forking process for object preservation instead of serialization and the other one that exposes the shell execution to a public method. Non forking process loop => #163 What i mean, if you really want a feature like that, start doing code reviews of the currently pending PR i did long time ago, and maybe we can do a fresh start via a more extensible PySH shell. /cc @bobthecow |
@Markcial meanwhile, there is a PHP "kernel" for Jupyter. It's far from perfect, but it's based on PsySH and takes advantage of the Jupyter Notebook frontend, Nteract and other frontends... : |
As with #505, this would increase the security footprint of PsySH significantly. I can see it being very useful, especially on crappy webhosts which do not give SSH or XDebug access so debugging applications can be a nightmare, but IMO it should be split off into a separate package, as CLI PsySH can be very useful in a production environment, while installing code for a network backdoor (which would presumably be off by default, but code and configuration mistakes happen) seems like invitation for trouble. |
Since PHP is usually ran by apache, it would be nice for psych to open up a socket connection or something, and allow you to connect to it remotely, or on the same box that way you aren't limited in debugging things you run from the command line.
The text was updated successfully, but these errors were encountered: