CogServer replacement?

[Roman Treutlein]

Hey,

so this is mainly a question to linas. You seem to want to get rid of the CogServer and I was wondering what exactly you would prefer in its place.

The way I see it the CogServer currently serves a vital role in the whole Architecture by providing a way for all the different parts of OpenCog to come together in one place. 

And by managing a bunch of threads used by the various modules.

And those seem to be functions that we will always need. So I don't really see how the CogServer could be replaced. Improved and Changed sure but not replaced.

So how do you see OpenCog working without a CogServer?

best regards

Roman

[Linas Vepstas]

On Thu, Jun 8, 2017 at 2:22 AM, Roman Treutlein <lordm...@gmail.com> wrote:

Hey,

so this is mainly a question to linas. You seem to want to get rid of the CogServer and I was wondering what exactly you would prefer in its place.

The way I see it the CogServer currently serves a vital role in the whole Architecture by providing a way for all the different parts of OpenCog to come together in one place. 

And by managing a bunch of threads used by the various modules.

Except it does none of these things. You can use opencog, via both python and scheme, without ever starting the cogserver.  You can use both python and guile together, even, without starting the cogserver.

Now, the cogserver provides a network interface, but so does guile, and I presume that there's some generic python module out there that would do this too.  So you can start the a scheme or a python network server, and remotely log into opencog, without ever actually starting the cogserver.  So basically, the cogserver isn't needed for neworking.

I'll bet Haskel also has some network server module, too. I'll bet that at least some of these network modules might be pretty fancy, providing encryption, login credentials, other security bells and whistles that we sure-as-shootin are never going to add to the cogserver.  And we shouldn't -- it breaks the concept of modular design.  If some module out there provides secure, safe, audited, encrypted network access, we should use that. We should not reinvent the wheel, badly, (which is what we've done) by putting this function in the cogserver.  We should remove this mis-feature, not enhance it.

So what else does the cogserver do? Well, it manages "mind-agents". Except (1) the code for managing mind-agents is badly implemented and completely buggy, and (2) you do NOT need a cogserver to manage a pool of mindagents!  These are completely distinct, unrelated concepts that, due to historical accident, got mashed together into one. 

If the mind-agent code was redesigned so that it worked correctly, and so that it was a stand-alone module, instead of a lean-to, then the cogserver would become just a network server, and nothing more, and, as I say, there are surely better network servers out there.  The cogserver is currently a crutch, a hack job.

 

 

And those seem to be functions that we will always need. So I don't really see how the CogServer could be replaced. Improved and Changed sure but not replaced.

So how do you see OpenCog working without a CogServer?

Well, easy. I do this every day, all the time. I only rarely start the cogserver.  So, for example, in guile

$ guile

guile> (use-modules (opencog))

guile> (use-modules (system repl server))

guile> (call-with-new-thread run-server)

Then  in another shell:

telnet localhost 37146

that's the default port nummber. To change it, see

https://www.gnu.org/software/guile/manual/html_node/REPL-Servers.html

then guile> (Concept "foo")

Bingo! -- you've just used the atomspace -- logging in remotely, using a two-line replacement for the cogserver. One line to load the network module, one line to start the network module. What do we need a cogserver for, again?

I'm sure you can get something similar in python and heskel.

--linas

 

best regards

Roman

--
You received this message because you are subscribed to the Google Groups "opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/fb65213f-7bb7-4746-9893-1d4190f2474c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roman Treutlein]

Okay so make Mind-Agents managed their own resources. Yea that makes sense.

You'd still need some simple Agent-Manger but yea I can see how that would clean up the overall design.

Thanks for clearing my Mind. It got a bit stuck after redesigning ECAN and depending on the CogServer so much :)

best regards

Roman

To unsubscribe from this group and stop receiving emails from it, send an email to opencog+u...@googlegroups.com.

[Linas Vepstas]

On Fri, Jun 9, 2017 at 2:54 AM, Roman Treutlein <lordm...@gmail.com> wrote:

Okay so make Mind-Agents managed their own resources. Yea that makes sense.

You'd still need some simple Agent-Manger but yea I can see how that would clean up the overall design.

well, there are also some deep theoretical problems with the naive conception of "mind-agents".  I suppose I should write this in a wiki somewhere.

--  its surely just a lot easier to just launch a thread if you need that.

-- the naive idea is that mindagents are scheduled, but how? this is a really hard problem that OS designers struggle with. What if a mind-agent does file or network i/o? etc. naive conceptions of ecan can't solve this.

-- for robustness and reliability, its usually better to split up large things into multiple network servers, so that if one small component crashes, it doesn't take down the whole system.  Jamming all mind-agents into one giant address space goes counter to this.

-- a classic example of where mutiple adress spaces are viewed as importnat/good is for data applications: you don't want a rogue mind-agent corrupting the atomspace. classic examples include: bad apps can't crash an OS kernel (recall, with MSDOS/windows 3.1, Mac os9, they could, hello, the birth of linux), bad database apps can't corrupt or crash databases (in dbase/foxdb, they could; oracle started as a tiny company cause they had a solution to this data corruption problem, called SQL. Ingres turned into postgres).

adress space management is how this is accomplished.  we should not regress to having rogue / wild / beta / untested mindagents running in the same address space as the atomspace, where we may have some semi-precious data we are trying to keep in order.

Even humans (mammals) have something called the blood-brain barrier, meant to keep dangerous crap in your blood for getting into your brain. to keep you alive/alert in case you get viruses in your blood.

So this naive conception of mindagents has to be completely reformulated.

--linas

[Mitch Francis]

I tried this approach, but running into issues when loading a module

scheme@(guile-user)>  (use-modules (opencog))

While compiling expression:

ERROR: no code for module (opencog)

I saw on github that someone mentioned manually copying the modules into the Guile module path. Can someone provide more clarification on what to copy?

Also tried to run CogServer compiled using PostgreSQL 9.5 (Ubuntu 16.04), and am unable to access the SQL commands (sql-load, sql-open, etc). No error was reported

best regards

Roman

To unsubscribe from this group and stop receiving emails from it, send an email to opencog+u...@googlegroups.com.

[Mitch Francis]

Found the module directory under /usr/share/opencog

I exported the directory using the  GUILE_LOAD_PATH environment variable

export GUILE_LOAD_PATH=/usr/local/share/opencog/scm

guile

GNU Guile 2.0.11

Copyright (C) 1995-2014 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))

;;; 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/opencog.scm

;;; compiled /home/mitch/.cache/guile/ccache/2.0-LE-8-2.0/usr/local/share/opencog/scm/opencog.scm.go

scheme@(guile-user)>

[Linas Vepstas]

On Mon, Jul 3, 2017 at 11:27 PM, Mitch Francis <vaektor...@gmail.com> wrote:

I tried this approach, but running into issues when loading a module

scheme@(guile-user)>  (use-modules (opencog))

While compiling expression:

ERROR: no code for module (opencog)

You almost surely need to say
 (add-to-load-path "/usr/local/share/opencog/scm")

it might also be convenient to add

 (use-modules (ice-9 readline))
  (activate-readline)

(debug-enable 'backtrace)
; Record positions of source code expressions.
  (read-enable 'positions)

(add-to-load-path ".")

Its convenient to cut n paste those into ~/.guile

I saw on github that someone mentioned manually copying the modules into the Guile module path. Can someone provide more clarification on what to copy?

Don't copy. Just add /usr/local/share/opencog/scm to the search path, as above.

In the long run, perhaps we should just copy to where guile finds these by default.

Also tried to run CogServer compiled using PostgreSQL 9.5 (Ubuntu 16.04), and am unable to access the SQL commands (sql-load, sql-open, etc). No error was reported

   (use-modules (opencog persist) (opencog persist-sql))

--linas

[Mitch Francis]

Thank you for the assistance!

[Dagim Sisay]

true that the cogserver isn't very useful specially considering how everything should be running.
modules should be fired from within a code not by typing into a terminal.
but does the attention module have a scheme binding that can "start-ecan" : the various agents
that manipulate the attention values of atoms?