Reset the atomspace in scheme

[Nemquae]

For the ghost rules authoring, and more generally, we'd like a function that can return the atomspace to its initial/original state. Effectively like restarting the atomspace process, but through a function in scheme so it's faster for rules authors.

Eventually we'll have more than just the atoms for rules, like those for perceptions and actions, so we really would like all of the atoms to be reset.

[linas]

Certainly, you can clear and reload the atomspace. But perhaps this eats up too much CPU/elapsed time? If so, there is another possibility: load the base rules and content into one atomspace, but then use a 'child' atomspace for perceptions and actions. The child atomspace can be discarded, leaving behind the base.

No one has yet experimented with this kind of arrangement, and there are likely to be bugs and bizarre, unexpected behavior and side-effects. I think, however, that this is an important long-term direction, and so getting started on it now, rather than later, would be good.

[linas]

At the guile prompt:

(use-modules (opencog))
,a atomspace

,a is short for ,apropos. This will list a dozen functions. Then, ,d is short for ,describe, for example:

,d cog-atomspace-clear
,describe cog-set-atomspace!
,d cog-new-atomspace

[Nemquae]

Ok, thanks for the suggestions. I'll try it tomorrow and see how it behaves.

[Nemquae]

It crashed. Here's the error report when I try (cog-atomspace-clear (cog-atomspace)):
AtomSpaceClearError.txt

It may be that I need to go over it with @amebel, since this call may or may not be what we need. Essentially we're looking for a simpler way to restart the atomspace for testing purposes that more or less corresponds to how we expect to do this in practice, i.e. when resetting the robot on-site. With ChatScript, we can reset the context of the conversation without rebooting the whole machine. For now I'll just reboot everything to continue testing.

[amebel]

By using the overlay atomspace introduced in opencog/atomspace#1895 as working atomspace for openpsi and ecan, and introducing a ghost-reset command this could be achieved.

[amebel]

clear shouldn't be used because if there is a link between atoms in the base atomspace with a masking masking atom in the overlay atomspace, then the linked atom in the base atom will also be removed.

[amebel]

Care should be made when traversing the incoming/outgoing set of atoms in the overlay-atomspace to avoid computing urges, attention-values,... based on values of masked atoms in the base atomspace, since there are no guarantee that their wouldn't be any links between masking and masked atoms.

[linas]

Hmm. this now occurs to me: when automatically making a copy of an atom into the overlay, I almost surely need to copy it's entire incoming set, too, which is currently not being done. Without this, pattern matching will be broken (because the ... ugh. I see two or three problems) The masking should be made as perfect as possible, and right now, its not. So sorry @mjsduncan this is not quite usable, just yet.

[linas]

@amebel the (clear) function is buggy; I will alter to use cog-atomspace-clear which does the right thing, later today.

I also take back my earlier comment above ... maybe traversal is not such a problem. I came up with several fixes, and then realized that I didn't understand the problem I'm fixing. So, advice/request for you and for @mjsduncan -- can you please tentatively try the new new features, per example in /examples/atomspace/copy-on-write.scm and see how it goes? Report unexpected behaviors, anything that looks like a bug, etc.

In short, I currently don't see why "perfect masking" is needed or desirable; it's not that hard to implement, and probably would have a very small performance penalty, but I don't clearly see why its needed, at the moment. Glimmers, but nothing clear.

[amebel]

@linas It was after going through the example and playing with the feature that I commented. Will "perfect masking" be required for applying the feature requested by this issue? I don't know.

I added the above comments as a note

[linas]

... or not. I'm modifying unit tests to work in the new scenario, and some pass, and some unexpectedly fail. Hold your breath.

[linas]

Please ignore the remark immediately above. The unit tests work fine, after I fixed a silly little bug in #1902. Basically everything works fine. So, I believe the following usage scenario will work with no surprises, exactly as you might hope it would (?):

; load most or all of ghost
 (define base (cog-atomspace))
 (define ovly (cog-new-atomspace base))
 (cog-atomspace-ro! base)
 (cog-set-atomspace! ovly)
; do things with ghost
(clear)
; do more things with ghost, and it should work exactly just as it you had restarted from scratch.
(clear)
; again, it should behave as if restarted from scratch.

That is, you only load ghost once, do all subsequent work in the overlay only, and after each clear, its as if you were back at the beginning.

[linas]

... argh. Except I forgot to isolate the attention bank. And also the python bindings. So what I wrote above works, but only if ghost doesn't use the attention bank or python. ;-) Will fix tomorrow.