[opencog-dev] Re: ./octool: line 583: cd: cogutils-master/: No such file or directory

[Dagi S]

Hi David, 

Maybe u should just update ur octool. 
cogutils was renamed to cogutil a few days ago.
https://github.com/opencog/ocpkg/pull/93

Thanks! 
Dagim


On Thursday, October 5, 2017 at 9:32:08 PM UTC+3, David Beitler wrote:
>
> Hello, everyone. I'm brand new to the group and just getting started with 
> OpenCog. Just working on installing and exploring right now. 
>
>
> Ran into this issue on a fresh install of Ubuntu Server 17.04. 
>
> Kept getting the following message every time I ran  ./octool -rsdpcalv
>
>
> ./octool: line 583: cd: cogutils-master/: No such file or directory
>
>
>
> Seems the issue is that the folder that is created by untarring the 
> cogutils master.tar.gz is not named correctly in the octool script. 
>
>
> If I edit the octool script on line 583 to say "cogutil-master" (remove 
> the 's' from cogutils) it works again. 
>
> Hope this will help anybody else who is also getting this same issue. 
>
>
> -David Beitler  
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/961b012e-cea2-46f7-b81e-838e17c7ff49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

['Nil Geisweiller' via opencog]

On 10/06/2017 02:10 AM, Linas Vepstas wrote:
it would be nice to have a fast crisp prover so that the system could 
jump to conclusions, and pln more slowly in the background.


Yes, even for our rule engine alone there is a benefit to that. On top 
of being faster to evaluate, crisp rules tend to have less premises than 
their probabilistic counterparts.


Then the question is how to set the TV of these conclusions. If the 
axioms are crisps with (stv 1 1) or (stv 0 1), then the conclusions 
would be (stv 1 1) or (stv 0 1). But if the axioms are non-crisp, then I 
guess the crisp rules could set (stv 1 Epsilon) or (stv 0 Epsilon), just 
to express that something is possibly true or false. Or else we can 
create a new TV type for it.


Nil



On Oct 4, 2017 5:45 PM, "'Nil Geisweiller' via opencog" 
> wrote:


On 10/04/2017 11:02 AM, Linas Vepstas wrote> And can implement
algorithms in the graph database-agnostic way and

 use all the industrial power of the best database available.
 Scientists do use commercial off-the-shelf computers for
HPC, why
 not to use industrial software? And similar things we can
say about
 use of external reasoners (linear logic, Coq, Isabelle, etc.).


If you can attach coq to tinkerpop and make it work ... sure.
But you would probably have to completely rewrite both coq and
gremlin in order to do this.  And that is a huge amount of work.


I never tried Coq or Isabelle, but the provers I've tried (E and
Vampire) were using resolution
https://en.wikipedia.org/wiki/Resolution_(logic)
, which doesn't
work for a para-consistent logic like PLN, at least not
out-of-the-box. On top of that PLN is probabilistic (or even
meta-probabilistic we could say). These make it difficult or at best
unnatural to use traditional automatic theorem provers. Maybe
there's an easy way, or a more general framework that I missed, but
that was my impression when I studied the domain.

Nil

-- 
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+unsubscr...@googlegroups.com
.
To post to this group, send email to opencog@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/a261e2b5-7d6e-74f9-fe87-cd83304adb2a%40gmail.com

.
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 opencog+unsubscr...@googlegroups.com 
.
To post to this group, send email to opencog@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/CAHrUA343%2BH5CT5zGobgT5hq9sy_iLPSGJUh52WcsgHUPUZNqcw%40mail.gmail.com 
.

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 opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/8762676a-e52c-e3b4-9edb-bcd2c21e9aa0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] ./octool: line 583: cd: cogutils-master/: No such file or directory

['Nil Geisweiller' via opencog]

Hi David,

thanks for your report! Your fix is correct. Generally, issues like this 
would be reported on github. Each repository has an issue tab that 
allows you to create one (for ocpkg it would be 
https://github.com/opencog/ocpkg/issues).


But since you already have a fix I would recommend that you directly 
create a pull request (fork the repo, push a commit to your master, and 
it will automatically appear as a selectable PR on upstream).


Thanks!

Nil

On 10/05/2017 09:32 PM, David Beitler wrote:
Hello, everyone. I'm brand new to the group and just getting started 
with OpenCog. Just working on installing and exploring right now.



Ran into this issue on a fresh install of Ubuntu Server 17.04.

Kept getting the following message every time I ran ./octool -rsdpcalv


./octool: line 583: cd: cogutils-master/: No such file or directory



Seems the issue is that the folder that is created by untarring the 
cogutils master.tar.gz is not named correctly in the octool script.



If I edit the octool script on line 583 to say "cogutil-master" (remove 
the 's' from cogutils) it works again.


Hope this will help anybody else who is also getting this same issue.


-David Beitler

--
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+unsubscr...@googlegroups.com 
.
To post to this group, send email to opencog@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/f88c8a4d-40a1-4bb4-9160-d7e43f987680%40googlegroups.com 
.

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 opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/38d61dde-b214-116c-48d4-0207b75ecbd0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Mark Nuzz]

On Thu, Oct 5, 2017 at 4:22 PM, Linas Vepstas  wrote:
> People seem not to read the tutorials... maybe because they don't see the
> point of doing so?
>

Do you think my theory is plausible? Tutorials on a large system must
be greater in scope, and are therefore more likely to be skimmed
(which leads to a failure in comprehension).

OTOH, If modules or projects were usable in isolation, and the
dependencies could be effectively treated as black boxes (as most
software dependencies are), or even simulated/mocked, and if
meaningful experimentation and feedback still able to be done within
the narrow scope of that one module, then maybe the tutorials won't be
so pointless.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CAMyYmr_W%3D%2Bfrxge4iEHhroZq7N2zFjBRU0AnNZsu%3D0F%2B%3Dvcuog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

People seem not to read the tutorials... maybe because they don't see the
point of doing so?

On Oct 6, 2017 3:10 AM, "Ben Goertzel"  wrote:

> "Modular" and "monolithic" are very general terms.   Could you
> articulate more precisely the ways in which you think OpenCog is
> "monolithic", and in which you think it could be made more "modular"?
>
> My thinking is: the Atomspace is a distinct module (in its own repo,
> it builds separately, etc.), and the various AI processes that can be
> used with the Atomspace are also independently buildable and runnable
> (MOSES, PLN, the NLP pipeline, ECAN, etc.).   Also when we use OpenCog
> for robot control, it communicates with other AI tools that are
> wrapped up in separate ROS nodes.  This already seems pretty modular
> to me.  So I am wondering what other kind of modularity you are
> looking for?
>
> Regarding Ivan's description
>
> ***
> I was referring to an imaginary system where the whole project would
> be a set of modules that work together, connected by well known set of
> interfaces. Each module could be modified or forked out in parallel
> with the original. It would be up to a user, which sub-forks she/he
> would choose to use to run the project, or to base her/his
> contribution on. Probably there would be a need for combination
> maintainers, something like persons that would choose different
> flavors of the project, and would propose their "deejay-combo" to the
> public, optimized for this or that use. Sub-fork combinations of low
> quality would be avoided, while really useful ones would live on.
> ***
>
> I guess one relevant point is that the different AI tools within
> OpenCog can interact in many many different ways.  E.g. there is no
> single, simple interface for interaction between PLN and MOSES; there
> are lots of ways they can interface, conceptually speaking.  And
> figuring out the best ways for them to interface is a current research
> topic...
>
> In building a particular OpenCog application, one can define specific
> interfaces between the various AI components...  But for OpenCog as a
> general platform, the interactions between the components have to
> remain flexible because there are so many interesting ways to do it...
>
> I think the biggest issue with OpenCog is that we need better
> tutorials and documentation.   I guess if we had that people would be
> able to understand the system better and then would also make more
> useful suggestions regarding improving the architecture...
>
> ben
>
>
>
>
>
> -- Ben
>
>
>
> On Fri, Oct 6, 2017 at 2:56 AM, Mark Nuzz  wrote:
> > On Thu, Oct 5, 2017 at 2:13 AM, Ben Goertzel  wrote:
> >
> >> I regret that OpenCog remains so hard to approach.  In large part it
> >> has evolved this way because the vast bulk of funding that has gone
> >> into OpenCog has been oriented toward paying a small group of people
> >> to work, in a hurry, on making OpenCog do something specific   We
> >> have not yet had a big chunk of funding dedicated to making it easy to
> >> use as a platform.  Hopefully that will change soon.
> >
> > This seems to be a very common theme with projects, especially with
> > limited resources. Though OpenCog is unique in the sense that it has
> > survived for so long with so many contributors, so the scale/extent at
> > which this happened is somewhat larger and therefore require greater
> > effort and coordination to really solve.
> >
> > I'm curious about a few things...
> >
> > 1) I know you implied this but I wanted to make sure: Do you see the
> > goal of an easy-to-use opencog architecture as a high priority item?
> >
> > 2) Do you think that the specific architecture direction
> > (modularization) presented by Ivan is generally the way that this
> > should be solved?
> >
> > 3) Has there been any concrete work in mapping out a specific
> > architectural direction to fulfill the goal of making opencog easy to
> > use?
> >
> > 4) Are these decisions that have already been formally agreed upon by
> > the governance of the project? Are there any dissenters among the core
> > developers, to the extent that it might interfere with such plans if
> > executed?
> >
> >
> > I am not quite aware of all the details but I have been trying to keep
> > up with all of the discussions lately in this group. Please forgive me
> > if I am being too pedantic... My impressions are that funding would be
> > easier to come by after these items are figured out in great detail
> > and then incorporated as part of a proposal. Such a proposal could
> > attract enough of the right unpaid volunteers too, as you know.
> >
> >
> > But yeah, I am not claiming by any means to know even remotely close
> > to what Ben knows on this subject. But from my vantage point, I am of
> > the opinion that the monolithic architecture is what's slowing
> > progress, and not the lack of funding. Suppose you get the funds and
> > then you hire the wrong people, 

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

it would be nice to have a fast crisp prover so that the system could jump
to conclusions, and pln more slowly in the background.

On Oct 4, 2017 5:45 PM, "'Nil Geisweiller' via opencog" <
opencog@googlegroups.com> wrote:

> On 10/04/2017 11:02 AM, Linas Vepstas wrote> And can implement
> algorithms in the graph database-agnostic way and
>
>> use all the industrial power of the best database available.
>> Scientists do use commercial off-the-shelf computers for HPC, why
>> not to use industrial software? And similar things we can say about
>> use of external reasoners (linear logic, Coq, Isabelle, etc.).
>>
>>
>> If you can attach coq to tinkerpop and make it work ... sure. But you
>> would probably have to completely rewrite both coq and gremlin in order to
>> do this.  And that is a huge amount of work.
>>
>
> I never tried Coq or Isabelle, but the provers I've tried (E and Vampire)
> were using resolution https://en.wikipedia.org/wiki/Resolution_(logic),
> which doesn't work for a para-consistent logic like PLN, at least not
> out-of-the-box. On top of that PLN is probabilistic (or even
> meta-probabilistic we could say). These make it difficult or at best
> unnatural to use traditional automatic theorem provers. Maybe there's an
> easy way, or a more general framework that I missed, but that was my
> impression when I studied the domain.
>
> Nil
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to opencog@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/ms
> gid/opencog/a261e2b5-7d6e-74f9-fe87-cd83304adb2a%40gmail.com.
> 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 opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CAHrUA343%2BH5CT5zGobgT5hq9sy_iLPSGJUh52WcsgHUPUZNqcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Ivan Vodišek]

Mark exactly hit the point I was trying to make. Imho, If I was joining an
open source project, I would like to see availability for programmers to
push any changes to any sub-area of the project without special permission
of a higher force. My thoughts are striving towards decentralization here.
But to make an order in such potentially chaotic conglomerate,
"distribution(s) maintainers" would compose and offer what they think it is
the best for particular use. Programmers would compete by code quality to
be included in future parallel distributions, just like it is the case with
Linux and its distributions. This idea sounds a bit progressive on the
first look, but it might work. It takes some to implement it, but maybe
some source control solutions that Mark proposed would be ready yet now,
without a much an effort.

Just sharing some thoughts, someone might find it useful.


2017-10-05 21:49 GMT+02:00 Mark Nuzz :

> On Thu, Oct 5, 2017 at 12:10 PM, Ben Goertzel  wrote:
> > "Modular" and "monolithic" are very general terms.   Could you
> > articulate more precisely the ways in which you think OpenCog is
> > "monolithic", and in which you think it could be made more "modular"?
> >
> > My thinking is: the Atomspace is a distinct module (in its own repo,
> > it builds separately, etc.), and the various AI processes that can be
> > used with the Atomspace are also independently buildable and runnable
> > (MOSES, PLN, the NLP pipeline, ECAN, etc.).   Also when we use OpenCog
> > for robot control, it communicates with other AI tools that are
> > wrapped up in separate ROS nodes.  This already seems pretty modular
> > to me.  So I am wondering what other kind of modularity you are
> > looking for?
>
> That's good news. My views are that this architecture needs to be
> developed further in order to reap the full benefits of it toward the
> project's goals.
> First and foremost, why are the independent processes part of the main
> opencog repo and not managed as separate projects with their own
> versioning and dependency toolchain? Do we have a fluent understanding
> of the pros and cons of doing it this way versus separate
> repositories? My guess is no, not because the team isn't smart, but
> because the resources seem to be focused on the specific modules
> rather than the architecture as a whole.  But I've learned not to ever
> underestimate the expertise of the team so this is just a wild guess.
>
> By dependency toolchain, I'm only aware of robust tooling for systems
> written in a single language or framework. Examples are npm, nuget,
> rubygems, paket. This reddit thread suggests that C++-based package
> management is a hard problem, and I'm inclined to agree.
> https://www.reddit.com/r/cpp/comments/3d1vjq/is_there_a_c_
> package_manager_if_not_how_do_you/
> However, it may still be worth trying.
>
> The vision that I have with this -- and this is the key point -- is
> that by keeping the modules as separate projects, the perceived
> complexity of the system is greatly reduced. The intimidation factor
> is reduced (for anyone new). The build tools can be simplified. Each
> project can have a concrete release build with a semantic version.
> Docker images could be provided, with pre-built binaries, for each
> major release. Each separate project could be developed independently
> with the assumption that your only required dependencies are those
> which are the latest major releases, and therefore if someone has
> trouble building, for whatever reason, then they can resort to using a
> docker image. Anyone who wants to work on a subproject can hit the
> ground running as there will be more concrete releases. Version 1.15
> of a given project will always be version 1.15. The way I see it now,
> is that we have a one-dimensional master branch for a large chunk of
> modules that exist in the opencog repo, though I see there are some
> efforts to do what I'm suggesting... so we might have the same vision
> but with someone varying ideas on how to execute it.
>
>
>
> >
> > Regarding Ivan's description
> >
> > ***
> > I was referring to an imaginary system where the whole project would
> > be a set of modules that work together, connected by well known set of
> > interfaces. Each module could be modified or forked out in parallel
> > with the original. It would be up to a user, which sub-forks she/he
> > would choose to use to run the project, or to base her/his
> > contribution on. Probably there would be a need for combination
> > maintainers, something like persons that would choose different
> > flavors of the project, and would propose their "deejay-combo" to the
> > public, optimized for this or that use. Sub-fork combinations of low
> > quality would be avoided, while really useful ones would live on.
> > ***
> >
> > I guess one relevant point is that the different AI tools within
> > OpenCog can interact in many many different ways.  E.g. there is no
> > single, 

Re: [opencog-dev] Contributing to Opencog

[Ben Goertzel]

"Modular" and "monolithic" are very general terms.   Could you
articulate more precisely the ways in which you think OpenCog is
"monolithic", and in which you think it could be made more "modular"?

My thinking is: the Atomspace is a distinct module (in its own repo,
it builds separately, etc.), and the various AI processes that can be
used with the Atomspace are also independently buildable and runnable
(MOSES, PLN, the NLP pipeline, ECAN, etc.).   Also when we use OpenCog
for robot control, it communicates with other AI tools that are
wrapped up in separate ROS nodes.  This already seems pretty modular
to me.  So I am wondering what other kind of modularity you are
looking for?

Regarding Ivan's description

***
I was referring to an imaginary system where the whole project would
be a set of modules that work together, connected by well known set of
interfaces. Each module could be modified or forked out in parallel
with the original. It would be up to a user, which sub-forks she/he
would choose to use to run the project, or to base her/his
contribution on. Probably there would be a need for combination
maintainers, something like persons that would choose different
flavors of the project, and would propose their "deejay-combo" to the
public, optimized for this or that use. Sub-fork combinations of low
quality would be avoided, while really useful ones would live on.
***

I guess one relevant point is that the different AI tools within
OpenCog can interact in many many different ways.  E.g. there is no
single, simple interface for interaction between PLN and MOSES; there
are lots of ways they can interface, conceptually speaking.  And
figuring out the best ways for them to interface is a current research
topic...

In building a particular OpenCog application, one can define specific
interfaces between the various AI components...  But for OpenCog as a
general platform, the interactions between the components have to
remain flexible because there are so many interesting ways to do it...

I think the biggest issue with OpenCog is that we need better
tutorials and documentation.   I guess if we had that people would be
able to understand the system better and then would also make more
useful suggestions regarding improving the architecture...

ben





-- Ben



On Fri, Oct 6, 2017 at 2:56 AM, Mark Nuzz  wrote:
> On Thu, Oct 5, 2017 at 2:13 AM, Ben Goertzel  wrote:
>
>> I regret that OpenCog remains so hard to approach.  In large part it
>> has evolved this way because the vast bulk of funding that has gone
>> into OpenCog has been oriented toward paying a small group of people
>> to work, in a hurry, on making OpenCog do something specific   We
>> have not yet had a big chunk of funding dedicated to making it easy to
>> use as a platform.  Hopefully that will change soon.
>
> This seems to be a very common theme with projects, especially with
> limited resources. Though OpenCog is unique in the sense that it has
> survived for so long with so many contributors, so the scale/extent at
> which this happened is somewhat larger and therefore require greater
> effort and coordination to really solve.
>
> I'm curious about a few things...
>
> 1) I know you implied this but I wanted to make sure: Do you see the
> goal of an easy-to-use opencog architecture as a high priority item?
>
> 2) Do you think that the specific architecture direction
> (modularization) presented by Ivan is generally the way that this
> should be solved?
>
> 3) Has there been any concrete work in mapping out a specific
> architectural direction to fulfill the goal of making opencog easy to
> use?
>
> 4) Are these decisions that have already been formally agreed upon by
> the governance of the project? Are there any dissenters among the core
> developers, to the extent that it might interfere with such plans if
> executed?
>
>
> I am not quite aware of all the details but I have been trying to keep
> up with all of the discussions lately in this group. Please forgive me
> if I am being too pedantic... My impressions are that funding would be
> easier to come by after these items are figured out in great detail
> and then incorporated as part of a proposal. Such a proposal could
> attract enough of the right unpaid volunteers too, as you know.
>
>
> But yeah, I am not claiming by any means to know even remotely close
> to what Ben knows on this subject. But from my vantage point, I am of
> the opinion that the monolithic architecture is what's slowing
> progress, and not the lack of funding. Suppose you get the funds and
> then you hire the wrong people, then you're even worse off than before
> because you probably wouldn't get another shot at funding for awhile.
> If it were up to me I would have at least one existing core developer
> be involved with this effort full-time, preferably whomever has the
> most knowledge in modular software architectures.
>
> --
> You received this message because you 

Re: [opencog-dev] Contributing to Opencog

[Mark Nuzz]

On Thu, Oct 5, 2017 at 2:13 AM, Ben Goertzel  wrote:

> I regret that OpenCog remains so hard to approach.  In large part it
> has evolved this way because the vast bulk of funding that has gone
> into OpenCog has been oriented toward paying a small group of people
> to work, in a hurry, on making OpenCog do something specific   We
> have not yet had a big chunk of funding dedicated to making it easy to
> use as a platform.  Hopefully that will change soon.

This seems to be a very common theme with projects, especially with
limited resources. Though OpenCog is unique in the sense that it has
survived for so long with so many contributors, so the scale/extent at
which this happened is somewhat larger and therefore require greater
effort and coordination to really solve.

I'm curious about a few things...

1) I know you implied this but I wanted to make sure: Do you see the
goal of an easy-to-use opencog architecture as a high priority item?

2) Do you think that the specific architecture direction
(modularization) presented by Ivan is generally the way that this
should be solved?

3) Has there been any concrete work in mapping out a specific
architectural direction to fulfill the goal of making opencog easy to
use?

4) Are these decisions that have already been formally agreed upon by
the governance of the project? Are there any dissenters among the core
developers, to the extent that it might interfere with such plans if
executed?


I am not quite aware of all the details but I have been trying to keep
up with all of the discussions lately in this group. Please forgive me
if I am being too pedantic... My impressions are that funding would be
easier to come by after these items are figured out in great detail
and then incorporated as part of a proposal. Such a proposal could
attract enough of the right unpaid volunteers too, as you know.


But yeah, I am not claiming by any means to know even remotely close
to what Ben knows on this subject. But from my vantage point, I am of
the opinion that the monolithic architecture is what's slowing
progress, and not the lack of funding. Suppose you get the funds and
then you hire the wrong people, then you're even worse off than before
because you probably wouldn't get another shot at funding for awhile.
If it were up to me I would have at least one existing core developer
be involved with this effort full-time, preferably whomever has the
most knowledge in modular software architectures.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CAMyYmr-T4gevcMh_2mYHko-YwuRcCK6dyBfGZVwYT%2BuizjH6PQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[opencog-dev] ./octool: line 583: cd: cogutils-master/: No such file or directory

[David Beitler]

Hello, everyone. I'm brand new to the group and just getting started with 
OpenCog. Just working on installing and exploring right now. 


Ran into this issue on a fresh install of Ubuntu Server 17.04. 

Kept getting the following message every time I ran  ./octool -rsdpcalv


./octool: line 583: cd: cogutils-master/: No such file or directory



Seems the issue is that the folder that is created by untarring the 
cogutils master.tar.gz is not named correctly in the octool script. 


If I edit the octool script on line 583 to say "cogutil-master" (remove the 
's' from cogutils) it works again. 

Hope this will help anybody else who is also getting this same issue. 


-David Beitler  

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/f88c8a4d-40a1-4bb4-9160-d7e43f987680%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Ben Goertzel]

> I guess that in the
>> time of making first OpenCog lines, there were no graph databases, the
>> resarch and tools of graph mathcing and mining was only ascent field. But
>> today the situation is far more different - today graph databases and
>> mathcing/mining projects are available. Maybe the development strategy
>> should be changed - maybe one should more extensively use these projects and
>> there is mismatch of requirements then contribute to these speciality
>> projects back and not to try overdo them.

yeah, this makes sense until you look at the details...

One option we have looked at but not fully explored is Apache Ignite,
which is a sort of middleware layer between applications and storage.
It could possibly make sense to use Ignite as the basis for a
distributed OpenCog system -- retaining the current Atomspace as a
"local cache" and using Ignite to handle persistent storage and to
contain policies for interaction between local-cache Atomspaces on
different machines

However, this is easy to say and the hidden rocks may only become
apparent after actually trying it.   If someone feels like prototyping
this, that would be quite interesting.

I can say with confidence there is no other pattern-matching or
pattern-mining framework that does what OpenCog's does, and extending
Neo4J Cypher or whatever is not a viable route to reimplementing what
OpenCog's tools do...

It would require a lot less effort to create nice documentation and
interfaces for OpenCog, than to reimplement OpenCog functions atop
some fashionable platform that is inappropriate for the purpose...

I regret that OpenCog remains so hard to approach.  In large part it
has evolved this way because the vast bulk of funding that has gone
into OpenCog has been oriented toward paying a small group of people
to work, in a hurry, on making OpenCog do something specific   We
have not yet had a big chunk of funding dedicated to making it easy to
use as a platform.  Hopefully that will change soon.

-- Ben G

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@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/CACYTDBfAb2dtd1_ce34N7v__Kujj4%2Bk8nM2-mwLNvVseTO6G5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.