-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
feat: stop ModularServer closes #1642 #1675
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -223,19 +223,24 @@ def on_message(self, message): | |
| if self.application.verbose: | ||
| print(message) | ||
| msg = tornado.escape.json_decode(message) | ||
| try: | ||
| msg_type = msg["type"] | ||
| except KeyError: | ||
| print("Unexpected message. Key 'type' missing.") | ||
| return | ||
|
|
||
| if msg["type"] == "get_step": | ||
| if msg_type == "get_step": | ||
| if not self.application.model.running: | ||
| self.write_message({"type": "end"}) | ||
| else: | ||
| self.application.model.step() | ||
| self.write_message(self.viz_state_message) | ||
|
|
||
| elif msg["type"] == "reset": | ||
| elif msg_type == "reset": | ||
| self.application.reset_model() | ||
| self.write_message(self.viz_state_message) | ||
|
|
||
| elif msg["type"] == "submit_params": | ||
| elif msg_type == "submit_params": | ||
| param = msg["param"] | ||
| value = msg["value"] | ||
|
|
||
|
|
@@ -246,6 +251,10 @@ def on_message(self, message): | |
| else: | ||
| self.application.model_kwargs[param] = value | ||
|
|
||
| elif msg_type == "shut_down": | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is it necessary to be in debug mode in order for the shutdown to be functional?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My way of thoughts was:
By the way, I have a general question:
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Some people might have done this, that I am not aware of. The relevant issue is #481. We are also currently exploring the possibility of having the UI stack fully in Python (#1622), in a way that can be run on a Jupyter notebook. Hosting Jupyter notebooks is so ubiquitous that there are canned ways to do it securely.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am in the opinion that if the pure Python implementation goes well, it might replace the current clunky Tornado server, in a way that is easy to extend, and based on existing established data interaction frameworks. cc: @ankitk50. Another past attempt at revamping the frontend: #1334 by @Corvince. |
||
| if self.application.is_debug_mode(): | ||
| self.application.stop() | ||
|
|
||
| else: | ||
| if self.application.verbose: | ||
| print("Unexpected message!") | ||
|
|
@@ -407,7 +416,13 @@ def launch(self, port=None, open_browser=True): | |
| try: | ||
| tornado.ioloop.IOLoop.current().start() | ||
| except KeyboardInterrupt: | ||
| tornado.ioloop.IOLoop.current().stop() | ||
| self.stop() | ||
|
|
||
| def stop(self): | ||
| tornado.ioloop.IOLoop.current().stop() | ||
|
|
||
| def is_debug_mode(self): | ||
| return bool(self.settings["debug"]) | ||
|
|
||
| @staticmethod | ||
| def _is_stylesheet(filename): | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't encountered this branch point yet.
I think the safeguard is not necessary. Printing this error message instead of raising the exception results in an information loss about the location in which the error happens.
Replacing with
msg_type = msg["type"]should do.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ran into this, as I was trying out various changes in
mesa/visualization/templates/js/runcontrol.js.When I sent a message that didn't contain a key "type"
=>
If we add an error handling, the server will continue running despite of the unexpected message.
I'm not sure whether this is a good or bad thing.
That's a good point.
Is there more info that should be included in the error message?
Or do you think that raising the exception and shutting down the server is the way to go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a change that is made by the developer instead of the user, as such, I believe the server should halt violently with tracebacks instead of continue running.