stdout and stderr on the server is not captured

[gruis]

$ bin/pry-remote-em
[pry-remote-em] client connected to pryem://127.0.0.1:6462/
[pry-remote-em] remote is PryRemoteEm 0.1.0
[1] pry(#<Hash>)> puts "bad"
=> nil

$ ruby -I lib -r pry-remote-em/server -e 'EM.run{ {:caleb => true, :bruce => false, :gavin => true}.remote_pry_em }' 
[pry-remote-em] listening for connections on pryem://localhost:6462/
[pry-remote-em] received client connection from 127.0.0.1:53230
bad

[gruis]

This also affects the switch-to command. It causes the server side to output a new prompt and not respond to the client until someone manually exits the prompt on the server side.

Client

$ bin/pry-remote-em pryems:///
[pry-remote-em] client connected to pryem://127.0.0.1:6462/
[pry-remote-em] remote is PryRemoteEm 0.1.0 pryems
[pry-remote-em] negotiating TLS
[pry-remote-em] TLS connection established
[1] pry(#<Hash>)> switch-to

Server

[pry-remote-em] listening for connections on pryems://localhost:6462/
[pry-remote-em] received client connection from 127.0.0.1:55214
[pry-remote-em] ssl connection established
[1] pry(#<Hash>)> ls
Enumerable methods: all?  any?  chunk  collect  collect_concat  count  cycle  detect  drop  drop_while  each_cons  each_entry  each_slice  each_with_index  each_with_object  entries  find  find_all  find_index  first  flat_map  grep  group_by  inject  map  max  max_by  min  min_by  minmax  minmax_by  none?  one?  partition  reduce  reverse_each  slice_before  sort  sort_by  take  take_while  zip
JSON::Ext::Generator::GeneratorMethods::Hash methods: to_json
Hash methods: ==  []  []=  assoc  clear  compare_by_identity  compare_by_identity?  default  default=  default_proc  default_proc=  delete  delete_if  each  each_key  each_pair  each_value  empty?  eql?  fetch  flatten  has_key?  has_value?  hash  include?  index  inspect  invert  keep_if  key  key?  keys  length  member?  merge  merge!  pretty_print  pretty_print_cycle  rassoc  rehash  reject  reject!  replace  select  select!  shift  size  store  to_a  to_hash  to_s  update  value?  values  values_at
self methods: __binding_impl__
locals: _  _dir_  _ex_  _file_  _in_  _out_  _pry_
[2] pry(#<Hash>)> 

[gruis]

[5] pry(#<Hash>)> each do |k|
[5] pry(#<Hash>)*   Kernel.puts k
[5] pry(#<Hash>)*   end
NoMethodError: undefined method `tty?' for #<PryRemoteEm::Server::EM_CONNECTION_CLASS:0x007fc70bacdf30>
from /Users/caleb/.rvm/gems/ruby-1.9.2-p290/gems/pry-0.9.7.4/lib/pry/pry_instance.rb:330:in `retrieve_line'
[6] pry(#<Hash>)> 

[banister]

any ideas how to solve this issue? i think this is the only outstanding issue that prevents pry-remote-em hitting the big time :)

[gruis]

A few options:

• close STD{IN,OUT,ERR}
• redirect STD{IN,OUT,ERR} to the most recently connected and active client
• redirect STD{IN,OUT,ERR} to all connected clients
• redirect STD{IN,OUT,ERR} to all clients that connect with certain parameters

I'm not sure which is the best choice, so probably

• all of the above, but make them configurable when starting the server; also make them changeable while the server is running via PryRemoteEm.servers

Of course it would be nice if there was some way to make methods that use STD{IN,OUT,ERR} redirect to the client that was responsible for executing the method.

Any thoughts?

[TreyLawrence]

I'd like to help out with this issue. I'm fairly new to ruby dev, but I have a lot of time to put towards this, and I think it'd be a good learning opportunity :).

I agree that STD{IN,OUT,ERR} should probably be redirected to the client that was responsible for executing the method. But I guess it comes down to a design question. How do we want to have multiple client debugging sessions work? Should it be like screen or tmux, where you can see what the other person is typing? If so, then it's probably best that we redirect it to all clients connected. We'd also need to share locals between clients.

[gruis]

Thanks for the offer Trey. Pull requests are always welcome.

Frankly I don't see any way to ensure that the client responsible for executing the method will be the only one to receive the output, etc.,.

With that option off the table, I think you're right. Redirecting to all connected clients is the most reasonable and probably most expected behavior. I'd like it to be possible for a client to opt-out/in though.

At the moment there is no facility to cause whatever any client is typing to be shared with other clients. If STD{IN,OUT,ERR} is shared then it's probably reasonable for people to assume that what they type is also being shared.

So perhaps all clients receive STD{OUT,ERR} data, but only display it if the user asks for it.

After the messaging feature was added I wanted to include some concept of window panes into the client. One pane would be used for normal interaction and another would be used for messaging. If STD{OUT,ERR} is broadcast then maybe it should be displayed in a third pane that can be hidden. Adding windowing to the cli client is a massive undertaking, so I don't think it is reasonable to make the STD{IN,OUT,ERR} a dependency on it. I just wanted to share my thoughts on it.

Of course if participating in STD{IN,OUT,ERR} is optional then anybody could use tmux to create a second tmux pane with a second client running in it just for STD{IN,OUT,ERR}

[Xanders]

If you are still interested, I created the sandbox environment that partially fixes this issue in my fork. You can use it with this line in the Gemfile:
gem 'pry-remote-em', git: 'https://github.com/Xanders/pry-remote-em', branch: 'a_lot_of_improvements', require: 'pry-remote-em/server'
Please see breaking changes before:
https://github.com/Xanders/pry-remote-em/blob/a_lot_of_improvements/CHANGELOG
There is no readme for sandbox for now, so feel free to ask a questions.

[Xanders]

Sandbox is released on 1.0.0:
https://github.com/gruis/pry-remote-em#sandbox

But it is partial solution, and there still problems with switch-to command, so I'll not close the issue.