projectmesa
Enhancing Command Console
This issue is here to list some features that can improve the working of CommandConsole recently added in Mesa through PR #2697.
- [x] Arrow key navigation for commands.
- [x] Integrate the input field into the console (like in actual consoles).
- [ ] Extend the auto update than just using
force_update(). - [ ] Nice placement window for the console other than sidebar.
- [x] Improve autoscroll.
@quaquel I think we will need to discuss the placement of console, and what other functionalities we could need that force_update() is not able to perform. You did the test for console, how exactly was force_update() wasn't working if that was the case.
I tested it for Boltzman, but it should generalize. When using the console to change the wealth of an agent, the space plot did update, but the gini plot did not change.
The reason for this is obvious: gini is calculated in the model and the plot just extracts this number from the model. Because GINI is not a reactive variable, it is not updated when you change the wealth of an agent. So, the problem is not with console or force_update per se.
One solution is to use mesa.experimental.mesa_signals. For example, GINI could be turned into a Computed, while agent.wealth becomes an Observable. In this case, the moment you change the wealth of any single agent from the console, this will result in model.gini being set to dirty. When force_update than triggers the extraction of gini from the model, this will result in recalculating gini (because it's dirty), and the plot should be updated accordingly. This, however, is something to be tested (but also showcases nicely why I added mesa_signals).
@quaquel I'm exploring mesa_signals right now, and it's great! What is it based on, if anything?
mesa_signals is based on many things and emerged out of close to 1.5 years of discussions and exchanges of ideas. A good starting point is probably reading #2281 and #2291.
But in short, I have worked in the past with simulation libraries in Java that used the observable pattern for any UI-related functionality. This pattern itself is well over 20 years old by now. So, based on input from the other developers, I started reading up on more modern developments of this, most notably what is called signals in JavaScript. A good, rather technical read is https://github.com/tc39/proposal-signals. mesa_signals is a stand-alone implementation of these ideas, tailored to the need of MESA.
A key challenge is that signals in JavaScript are typically tied to a functional programming style, while in MESA we have a hybrid between OO and functional. Moreover, there were some API ideas that I really wanted to use (i.e., Descriptors). The current implementation works and does not have too much overhead. However, it can probably be developed and extended quite a bit. This however requires starting to use it in some models and see how it goes.
@quaquel I am also thinking of able to see matplotlib/Altair charts in the console, could this be useful?
I am also thinking of able to see matplotlib/Altair charts in the console, could this be useful?
Depends a bit on how it is done. Personally, I don't like the way plots are shown in pycharm for example.
Also, have you tested what happens if you try to make a simple figure in the console at the moment?
Nothing happens when we try to show a figure made in console at the moment. I am thinking of implementing maybe a popup of the chart if solara supports that otherwise adding the graph to as a solara card on screen could work.
I prefer the popup idea. It does however raise some follow up questions. If you do a popup, it is obvious that the plot represents the state of the model when creating the popup. If you make it a solara chart, this is less clear. In theory you could make it reactive (i.e., it updates when the model is updated).