Web interface partially working when executed through vscode server port forward

[jeremyfix]

Describe the bug

I'm running a mesa simulation on a remote machine. I'm programming on the remote with vscode server; The issue comes with the visualisation.

Running, for example mesa runserver examples/wolf_sheep , vscode correctly detects the server being created on port 8521 and sets up a port forward from

remote:8521 to http://localhost:8080/proxy/8521/

The proxy/8521/ that appears in the URL seems to be causing trouble to mesa-viz-tornado.

Here is what I get :

Then, opening the developper console, I noticed a lot of messages complaining about the inability to get various files , for example

GET
http://localhost:8080/static/external/bootstrap-5.1.3-dist/css/bootstrap.min.css
[HTTP/1.1 404 Not Found 12ms]

I then edited your modular_template.html, replacing all the /static/ and /local/ to respectively static/ and local/ removing the leading / ; Then , the visualization gets more elements but I'm not yet there;

As you can see, there are some remaining "Unexpected token" errors . It seems to me also that :

• part of the UI is not displayed (on the left, to tweak the parameters of the simulation)
• the image with the grass is not shown

Do you have any idea of how to fix this ? On the vscode side, I did not find any way to change the forwarded port prefix, to remove the proxy/8521/ prefix; My hope is to adapt your html production code to prevent the ressource loading to go back to the root of the site;

[rht]

http://localhost:8080/static/external/bootstrap-5.1.3-dist/css/bootstrap.min.css

The problem is that the visualization code might be hardcoded to have the URL path as localhost:port/ instead of localhost:port/more/stuff, and needs fixing.

[rht]

Just wondering if you have tested forwarding the new experimental visualization framework via Solara: https://github.com/projectmesa/mesa-examples/tree/main/examples/boltzmann_wealth_model_experimental.

[rht]

I then edited your modular_template.html, replacing all the /static/ and /local/ to respectively static/ and local/ removing the leading / ; Then , the visualization gets more elements but I'm not yet there;

There are still more / prefixes at

mesa-viz-tornado/mesa_viz_tornado/ModularVisualization.py

Lines 290 to 301 in 8ef4748

	page_handler = (r"/", PageHandler)
	socket_handler = (r"/ws", SocketHandler)
	static_handler = (
	r"/static/(.*)",
	tornado.web.StaticFileHandler,
	{"path": os.path.dirname(__file__) + "/templates"},
	)
	custom_handler = (
	r"/local/custom/(.*)",
	tornado.web.StaticFileHandler,
	{"path": ""},
	)

.

[jeremyfix]

Unfortunatley, this does not work

I tried your two suggestions ;

1. removing the leading "/" on the 290-300 linus of ModularVisualization ; I do not see any progress; On the Wolfe/sheep, the grass display is not shown ; The start button does not start the simulation (step counter does not increment, contrary to clicking on the step button which increments the step counter); The only error I see is still a JSON.Parse which seems to receive an empty string in the message . I do not know how to debug further

2. for the experimental solara run , I ran the linked example. With the vscode forward and its /proxy/xxx prefix, the app does not load. Looking into the HTML, it also contains several /static/ with leading /. With the same server running, if I rather use a ssh port forward ssh -L 8765:localhost:8765 remotehost , opening the browser on http://localhost:8765, the simulation starts. So it is also still a question of the simulation page not supporting other patterns than http://host:port/ without other stuff after the URL.

I do not see how to make any progress on this;

[rht]

If you want to inspect the mesa-viz-tornado, you might want to try adding console.log(message.data) just before https://github.com/projectmesa/mesa-viz-tornado/blob/8ef4748ca7f1021ceb76048d824ed9bd80bd6f55/mesa_viz_tornado/templates/js/runcontrol.js#L143C15-L143C21, to see why it is not a valid JSON.

As a fallback, for the Solara option, I wonder if any of the options in https://solara.dev/docs/deploying/self-hosted is viable for your current use case.