more complete init-soar

[garfieldnate]

We are seeing that users will close and re-open the debugger for every change during their development cycle just to make sure everything works with a complete initialization. This is tedious and we should support a better workflow.

Part of the reason is that the users' agents connect with simulation environments that aren't initializing in response to init-soar. I'll need to investigate why, but it may be the case that some documentation about how to do this can be improved. An example of how a client could/should automate tests of this functionality may also be useful.

We should also have complete command coverage for initializing the Soar agent/kernel.

init-soar is an alias for soar init, which clears WM.

smem --clear clears smem (but fails if smem hasn't been added to yet, see #370).

To remove productions we have production excise --all, but you may wish to keep the user ones (the ones in your source files); we have --user to remove only the user ones, but no --non-user to remove the non-user ones: RL, chunks, RL templates, and defaults (I don't actually know what those last two are).

To clear epmem we have epmem --init.

Am I missing anything? I would also want a command that resets all settings everywhere to their default (epmem off, smem off, etc.).

Perhaps the most basic thing we could do is provide a button in the debugger which simply destroys the current agent and creates a new one?

[garfieldnate]

Bob W.'s ideas here:

• soar init --all would clear all memories including production memory (excise all and excise --chunks)
• soar init --rebase would clear all memories except production memory

[PLatCIC]

This is a clarification about the relationship between Soar and the simulation environment. In some simulations, there are multiple Soar agents running simultaneously. This puts limits on what can be reasonably done from an individual Java debugger. There is the question of what should happen when trying to initialize with multiple agents. There are several options:

1. A single button on the simulator that initializes all agents together.
2. Using the InitSoar button on a single debugger to initialize that agent only.
3. Having the simulator know that InitSoar was pushed on one agent, and it initializes all the others as well.

For the simulation we are currently using we have decided, for now at least, to implement option 1 using the Reset button on the main UI window. We can't prevent a user from doing option 2, but the results my be unpredictable.

Another important point is that when initializing one or more agents running with a simulator, both the simulator and the Soar agents should be stopped when doing init-soar. If not, strange behavior, including crashes, can be expected. This is enforced in our current simulator by disabling the Reset button when the simulation is running.

[wrayre]

To elaborate a little, we do not need sims to reset when init-soar is entered in the debugger or CLI. It's fine for reset to be driven by the user via the sim/sim UI. However, what we are seeing is that different users have different requirements for what they want "reset" to do. Some of these reset requirements are application specific (eg, should reset retain all agent instances in a multiagent sim? What should happen on reset if some agents spawn others during a run?). The main issue at the architecture level is what should happen on reset to the agent(s)? Depending on what parts of Soar a developer is using, init-soar() may not be sufficient to fully reset an agent. Ideally (I think), we would like to have a range of reset options at the API level (equivalents of init-soar --all, init-soar --rebase, init-soar-and-excise-chunks, etc.) so that the user has more control over what happens when the simulation is reset in terms of "resetting" their agents and these different choices could be readily incorporated in the simulation control/UI. As is, reset is (or appears to be) limited to InitSoar() which is often insufficient for resetting a Soar 9 agent.

[garfieldnate]

Should also clear all SVS scenes.