You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@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.
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 stream_select to handle input from readline/input, and output from stdout/output. It would make everything more responsive. It would make it possible to interrupt long running operations with ctrl-c without killing the entire shell. It would mean that the actual "doing work" part of psysh would simply be receiving code to evaluate and returning a string with output. psysh commands could then run on the "client" for the most part, but reach over to the "server" when they needed to interact with state. And ultimately, it would open the door for a lot more "client" types — a socket.io-based web client, a console based command to make one psysh instance into a client for another, etc.
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 \Psy\Readline, a socket based \Psy\Output\ShellOutput, a way to get \Psy\Shell to open up a pair of sockets and use those instead of the default input/output pair, and a way to connect as a "client". This should either be a web based client or a psysh command… the command version seems like a simpler place to start?
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.
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.
@Markcialhttps://github.com/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.
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub #121 (comment)
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
Public api for the execute method in the shell => #138
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.
@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.
Activity
bobthecow commentedon Dec 13, 2014
Yes. That is the (eventual) plan. If you'd like to see it sooner, we'd happily accept a pull request :)
bayleedev commentedon Dec 16, 2014
@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.
bobthecow commentedon Dec 16, 2014
Yes, you did. Sorry, I haven't had a chance to answer. I'll get on that :)
bayleedev commentedon Dec 25, 2014
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?
bobthecow commentedon Dec 27, 2014
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
stream_selectto handle input from readline/input, and output from stdout/output. It would make everything more responsive. It would make it possible to interrupt long running operations with ctrl-c without killing the entire shell. It would mean that the actual "doing work" part of psysh would simply be receiving code to evaluate and returning a string with output. psysh commands could then run on the "client" for the most part, but reach over to the "server" when they needed to interact with state. And ultimately, it would open the door for a lot more "client" types — a socket.io-based web client, a console based command to make one psysh instance into a client for another, etc.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 :)
bobthecow commentedon Dec 27, 2014
The bare minimum you'd need is a socket-based
\Psy\Readline, a socket based\Psy\Output\ShellOutput, a way to get\Psy\Shellto open up a pair of sockets and use those instead of the default input/output pair, and a way to connect as a "client". This should either be a web based client or a psysh command… the command version seems like a simpler place to start?Markcial commentedon Feb 24, 2015
a little teaser :
the downsides, some more dependencies, looking if they are really necessary.
bobthecow commentedon Feb 24, 2015
:)
jakefolio commentedon Jul 13, 2015
Any progress on this? Is there a branch or fork where it's being worked on @Markcial?
Markcial commentedon Jul 13, 2015
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.
theofidry commentedon Jul 13, 2015
That would be awesome
bayleedev commentedon Mar 9, 2016
Any update on this?
mikedfunk commentedon Mar 18, 2016
+1
Markcial commentedon Mar 18, 2016
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.
bayleedev commentedon Mar 18, 2016
@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.
theofidry commentedon Mar 19, 2016
Another solution would be to replace the interactive shell of the IDE when
using xdebug.
On Friday, 18 March 2016, Blaine Schmeisser notifications@github.com
wrote:
Markcial commentedon Mar 19, 2016
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
Public api for the execute method in the shell => #138
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
castarco commentedon May 20, 2017
@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... :
[-]Remote Psych[/-][+]Remote PsySH[/+]tgr commentedon Dec 11, 2022
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.