search

opencog / cogserver

Distributed AtomSpace Network Server
Other
15 stars 22 forks source link

cog-set-atomspace! not switching the atomspace used by the cogserver #1

Open amebel opened 9 years ago

amebel commented 9 years ago

not sure if it is a cogserver bug or a guile binding bug

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

guile> (cog-set-atomspace! alt-as)
#<atomspace 0x14e4c20>
guile> (cog-atomspace)
#<atomspace 0x14e4c20>
williampma commented 9 years ago

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

williampma commented 9 years ago

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

linas commented 8 years ago

is this still a bug?

williampma commented 8 years ago

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>
amebel commented 8 years ago

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

linas commented 8 years ago

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 ...

linas commented 8 years ago

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

amebel commented 8 years ago

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

amebel commented 8 years ago

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

linas commented 8 years ago

!? 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:

linas commented 8 years ago

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.

amebel commented 8 years ago

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.