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 On Thursday, June 8, 2017 at 3:08:23 PM UTC-7, linas wrote: > > > > On Thu, Jun 8, 2017 at 2:22 AM, Roman Treutlein <[email protected] > <javascript:>> 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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 >> >> <https://groups.google.com/d/msgid/opencog/fb65213f-7bb7-4746-9893-1d4190f2474c%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/628f42e1-22ba-4a69-b7a5-b166829f58c5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
