cog-set-atomspace! not switching the atomspace used by the cogserver about cogserver HOT 12 OPEN

wait, where's the bug? It sets the space to alt-as correct it looks like?

from cogserver.

oh, nevermind, cog-set-atomspace supposed to return the previous atomspace

from cogserver.

is this still a bug?

from cogserver.

Yes.

I also noticed the default atomspace and the new atomspace has different length, not sure if that's part of the problem.

guile> (define alt-as (cog-new-atomspace))

guile> (cog-set-atomspace! alt-as)
#<atomspace 0x2557f50>
guile> (cog-atomspace)
#<atomspace 0x2557f50>
guile> alt-as
#<atomspace 0x7f56140113c0>
guile> 

from cogserver.

This bug only happens in the lower scm shell, at port 17001 not the one at 18001

from cogserver.

Yeah, I can reproduce this. It is a "feature" not a "bug".

By design, each thread can have a different current atomspace. This so that you can run two threads, each doing different work in different atomspaces. It works, and I believe one of the unit tests tests this.

The port-17001 shell processor works like this: it creates a new thread, evaluates the scheme in the new thread, and then ends that thread, returning any string output in the main command-prompt thread. You can verify this by issuing this on a single line: (cog-set-atomspace! alt-as) (ConceptNode "qwerty") (cog-prt-atomspace )

To avoid this confusion, we can change port 17001 to not fork a new thread for each command. This makes it sightly less convenient, though -- one then cannot send interrupts (ctrl-C) to kill the running process, if it hangs. Working with long-running scripts becomes hard too ...

from cogserver.

I'm strongly tempted to close this as "not a bug"; before closing, though, the docs for 17001 should be updated to explain this.

from cogserver.

ok, then basically the issue is how to handle multiple (nested or cloned) atomspaces in a single thread.

I guess if one want to use multiple atomspaces, then they can swith to port 18001

from cogserver.

By the way, what is the purpose of having two scheme shells?

from cogserver.

!? multiple nested/cloned atomspace work just fine in a single thread or in multiple threads.

If you want to use port 17001 in a single thread, then you have three choices:

• put your scheme code in a file, and then load that file. Everything will execute in the same thread.
• cut-n-paste your code into one line. The 17001 shell creates a new thread for each tcpip stream packet that has a carriage return at the end of it.
• alter the c++ code to not create a new thread when running 17001 commands. Very strongly discouraged.

from cogserver.

There are not two, but three scheme shells :-) all sharing the same atomspaces. so, for example:

$ guile
GNU Guile 2.0.9
Copyright (C) 1995-2013 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (use-modules (opencog cogserver))
scheme@(guile-user)> (start-cogserver)
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /usr/local/share/opencog/scm/repl-shell.scm
;;; compiled /home/linas/.cache/guile/ccache/2.0-LE-8-2.0/usr/local/share/opencog/scm/repl-shell.scm.go
Listening on port 17001
$6 = "Started CogServer"

The above shares the same atomspaces with both 17001 and 18001.

The 17001 was the earliest implementation.

The 18001 came later, when the guile guys added a simple tcpip server at some point. For me, 18001 has always been buggy, though, prone to hangs and weird behavior. Shame about that.

The third form, of just running the cogserver inside scheme, instead of the other way around, only became possible recently, when we hacked together all the infrastructure needed for guile modules.

from cogserver.

That is clear, thanks.

For interactive experimentation, 18001 or the third shell are enough.

I have changed the labeling to documentation. This should come in handy for the python shell(or future haskell shell maybe) too. As consistant behavior, were possible, will make opencog-noob's life easier.

from cogserver.