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
Is your feature request related to a problem? Please describe.
The supposed problem would be, if I have windows with the same name in different env, then accroding to event_handler, their events would cross-talk.
Describe the solution you'd like
change the event_handler to binds to a precise (env,win) pair.
Describe alternatives you've considered
second thought. As long as the "target" emited from frontend interaction is paired with backend callback, it should be controllable. Currently "target" points to the interacting window, thus currently there isn't a way of controlling the message target when creating windows and plots.
Additional context
current code looks like this. event message example.
defregister_event_handler(self, handler, target):
assertcallable(handler), 'Event handler must be a function'assertself.use_socket, 'Must be using the incoming socket to '\
'register events to web actions'iftargetnotinself.event_handlers:
self.event_handlers[target] = []
self.event_handlers[target].append(handler)
callback execution
defon_message(message):
message=json.loads(message)
if'command'inmessage:
# Handle server commandsifmessage['command'] =='alive':
if'data'inmessageandmessage['data'] =='vis_alive':
logger.info('Visdom successfully connected to server')
self.socket_alive=Trueself.socket_connection_achieved=Trueelse:
logger.warn('Visdom server failed handshake, may not ''be properly connected')
if'target'inmessage:
forhandlerinlist(
self.event_handlers.get(message['target'], [])):
handler(message)
The text was updated successfully, but these errors were encountered:
shouldsee
changed the title
[feat] event handler is shared across envs
[feat] bind event handler to env and window
Sep 28, 2022
This is an interesting discussion, as the current callback functionality is definitely limited. I think your second thought direction is likely more compelling, as this opens up Visdom towards a model of having remote procedure calls. Still, it's also more complicated as choosing what actions to register for frontend windows is somewhat unclear.
Ultimately I'd be happy to accept either solution though.
This is an interesting discussion, as the current callback functionality is definitely limited. I think your second thought direction is likely more compelling, as this opens up Visdom towards a model of having remote procedure calls. Still, it's also more complicated as choosing what actions to register for frontend windows is somewhat unclear.
Ultimately I'd be happy to accept either solution though.
Hi jack thanks for reading. I am currently using the second-thought solution, using "target" as pointer to backend-registered callback, which is working fine so far, with the frontend message sent through the following line of js-hacker.
I am currently heavily using vis.text to create custom html window with js-hacker callback func and it's working like a charm so far. Definitely worth adding rpc design into visdom since it's definitely a highly frequent demand!
Is your feature request related to a problem? Please describe.
The supposed problem would be, if I have windows with the same name in different env, then accroding to event_handler, their events would cross-talk.
Describe the solution you'd like
change the event_handler to binds to a precise (env,win) pair.
Describe alternatives you've considered
second thought. As long as the "target" emited from frontend interaction is paired with backend callback, it should be controllable. Currently "target" points to the interacting window, thus currently there isn't a way of controlling the message target when creating windows and plots.
Additional context
current code looks like this. event message example.
callback registration
callback execution
The text was updated successfully, but these errors were encountered: