Coder Social home page Coder Social logo

opencog / generate Goto Github PK

View Code? Open in Web Editor NEW
29.0 9.0 12.0 726 KB

Generate networks from syntax (e.g. natural language, math proofs, action plans, biome/reactome nets)

License: Other

Scheme 20.47% CMake 4.60% C++ 74.94%
natural-language-processing natural-language-generation link-grammar network-generator planner action-plan

generate's Introduction

Example random network

Network Generation

Graphical networks are generic: natural language parse trees are graphs. So are the chains of axioms and logical deductions in a mathematical proof. So are plans for movement and motion through 3D space, as well as plans for accomplishing some more abstract action: planning a party or planning a coordinated disaster relief effort. Biological reaction pathways, involving genes, proteins and other molecules, are graphical networks as well. So are social networks. What these all have in common is an underlying set of allowed (or preferred) attachments, moves, changes or state transitions, as well as hard and soft constraints on what attachments, moves are possible.

The goal of the code in this repo is to generate such networks, given a (weighted) collection of constraints and/or transition rules and/or a syntactical (grammatical) description of the system. More precisely, it is to effect a transformation from a complex of initial states into a complex of final states, with the initial and final complexes possibly being of fundamentally different types. In between the start and end is a networked web of interconnected moves, transitions, constraints. In essence, this is as a constraint satisfaction solver which allows probabilistic weighting and guiding, and allows the general problem to be described as a collection of syntactical rules or moves (AKA rules of inference, axioms, judgments).

Currently focused on natural language generation; however, the theory is generic, and is intended for use on any deduction or induction problem. The image above was generated with this example code; it shows a random network, with all links and nodes being of the same type, and the node arity (number of connections) being Zipfian-distributed (that's why most nodes have only one connection, and only one has six connections).

Sheaves, germs and syntax

To accomplish the above, snapshots or instances of the interacting system are assumed to be describable as a graph (a generic directed, labeled, typed, weighted graph, possibly containing loops). Such generic graphs can be decomposed into pieces, which can be roughly envisioned as jigsaw-puzzle pieces, having mating connectors. In the typical case, each vertex in the graph corresponds to a jigsaw puzzle-piece, with "half-edges" or connectors connecting it to it's nearest neighbors. The pieces may be all alike, or all different, limited or unlimited in number, having connectors of only a few, or of many different types. In general, the pieces are NOT 2D, but of arbitrary dimension (that is, there may or may not be constraints on the crossing of links).

This vertex plus half-edge description of a graph is so general that it encodes a very large collection of concepts from mathematics and the sciences. The graphical interpretation allows concepts from cellular homology to be applied, most importantly, those of sheaf theory. In effect, the rules for assembling jigsaw puzzle pieces are precisely the sheaf gluing axioms. The pairing together of connectors resembles the contraction of raised/lowered indexes in a tensor algebra. That is, individual jigsaw-puzzle pieces are instances of tensors. Since a partially-assembled jigsaw looks like a particularly complicated single piece, this description applies to any category-theoretic category with a tensor product.

One particularly notable analogy to mating together a pair of connectors is that of beta-reduction (in lambda calculus and functional programming languages). The pair is of typed-variable to value! That is, one of the connectors can be taken as a variable (in a function or lambda expression) and the other connector is any "value" that can be substituted in for that variable. The "shapes" of the connectors enforce the requirement that the type of the value must correspond to the type of the variable. Unlike the variable/value distinction, thinking in terms of connectors makes beta-reduction more obviously symmetric. One can either apply a function to some values, or one can insert some values into a function: these are effectively the same, and there is no longer any particular necessity to distinguish between these two operations.

The puzzle-piece analogy is sufficient to capture and encode the concept of syntax, in all of it's fullness. For example, the Backus-Nauer Form (BNF) of (context-free) syntax rules are readily encoded as jigsaw-shapes: the production arrow is the piece itself; the expression on the left is just a connector; the term or expression on the right is just a conjunction of one or more connectors. A disjunction of terms on the right correspond to a disjunction of jigsaw-pieces: for a given connector tab on the left, one chooses one-and-only-one on the right. (This is consistent with the sheaf-gluing axioms, and resembles the rules of linear logic: viz. the no-cloning and the no-deleting theorems of dagger-compact categories.)

The grammar of natural language can also be encoded as jigsaw pieces; the foundational papers of the Link Grammar theory of natural language explicitly present parsing as the joining-together of jigsaw pieces.

In light of all of this, one can roughly say that the jigsaw piece analogy is the natural setting for the extension of Curry-Howard correspondence to a broad range of settings.

Parsing and generation

Graph generation via syntax rules can be understood as a search of a problem space. However, unlike traditional path search, where the start and end-points are of the same general kind (e.g. traveling salesman) here, path is transformative, and the start and endpoints might be of entirely different classes. For example, in (natural language) parsing, one starts with a linear sequence of words, and concludes with a parse tree. In natural language generation, one begins with a bag of semantic concepts, and generates a word-sequence capturing that semantics. The act of parsing or generation bridges between these two representations. The bridge itself is not a single ordered path or chain, but is also a network of connections and constraints that must be satisfied.

Parsing and generation can be thought of as a special case of the more general act of theorem-proving. In theorem-proving, one has a collection of axioms and inference rules (represented as jigsaw pieces!) together with a hypothesis (a collection of unconnected connectors), with the goal of a proof being to arrive at an appropriate assembly culminating in a "boundary" of "true" (all remaining unconnected connectors can be joined to a "true" jigsaw-piece, or rather, being all-true connectors). Unlike parsing, in theorem-proving, the jigsaw pieces can be freely chosen (as long as they fit together). In parsing, the jigsaw pieces must correspond to the words in a sentences, and the word-order must be preserved.

Markov logic and Bayesian blankets

Theorem proving (and generally, constraint satisfaction) are known hard problems, and so, defacto this is what this project is aiming at. All the pitfalls apply, including combinatoric explosion, algorithmic heuristics, etc. On top of all of this, a very explicit aim is that each of the jigsaw pieces and connectors are weighted, so that certain kinds of assemblies are preferred over others. Were it not for this weighting, one might consider using existing constraint satisfaction solvers. For example, Answer-Set Programming (ASP) is a particularly convenient way of specifying discrete, crisp-logic constraints. More generally, one might even consider SAT solvers, or maybe even Satisfiability Modules Theories (SMT) solvers. Once on throws in weightings, none of the existing SMT solvers appear to be adequate for the job. Thus, this project.

The goal of saying "weighting" is to avoid saying "probability". In reality (based on long experience) the weights do resemble log-probabilities, in that it is very convenient to assign a single preference score that is a sum of weights. There are some strong theoretical arguments that the correct weighting is the Boltzmann distribution, and thus, the assembled jigsaw pieces form a Markov blanket. Insofar as the jigsaw pieces can encode logic, the resulting blankets can be taken to be Markov Logic blankets. Again, the formation, discovery and data-mining of such blankets is a known-hard problem, filled to the brim with combinatoric explosions, and eminently lacking in general tractable algorithms. C'est la vie.

Unlike Markov logic, there is no presumption here that the jigsaw pieces are logical expressions. In particular, there is no constraint that the network be directed and acyclic. Thus, again, MLN solvers and Bayesian network solvers (belief networks, decision networks) are insufficient to tackle the problem at hand. Although the jigsaw connectors can have a polarity (and thus connections can be directed), there is no presumed constraint that the resulting graph is acyclic or directed (or planar, or has any other long-range properties that aren't encoded in the connector scheme.)

Strategic Development Plan

The above provides an very abstract description of the project, and emphasizes just how daunting it is. The abstract goals are not achievable in a handful of programmer-years; it is potentially some dozens if not hundreds of scientist-years of research effort. Thus, a narrower, tighter focus is needed.

Characterizing learning systems

This project is motivated by a need to characterize and evaluate unsupervised learning systems, specifically, learning systems for natural language. The normal course for such projects is to obtain a natural language corpus, usually in English, that has been annotated by professional linguists (or rather, their undergrad and gradate-student workforce) and then evaluate any given system against this corpus. Practice has shown that this is a poor way of evaluating the quality of natural-language parsing, understanding, inference, question-answering and generation. Considerable confusion and ambiguity abounds.

In place of this, it seems best to evaluate such systems against artificial languages; ideally, random languages where various aspects can be tightly controlled. For example: the size of the vocabulary. The relative distribution of nouns, verbs, adjectives. The number of meanings of words (viz, words that happen to have the same spelling, but have different syntactic behaviors, from which one infers different meanings). One might also vary the number of synonymous words: words that behave the same way, syntactically, but have different spellings. Or even synonymous phrases. The Zipfian distribution of natural language is a confounding factor: rare words simply don't offer enough examples to allow easy learning. Thus, one wishes to evaluate learning algorithms for different distributions.

Thus, the immediate goal of this project is to generate a corpus of "sentences" from a randomly-generated, constrained artificial grammar. One then asks of the grammar learner can learn the known grammar from this corpus of sentences. In can then evaluate the learner in much the same way that one evaluates audio amplifiers, looking for high-fidelity.

Specifically, this is for the OpenCog language learning subsystem.

Generating natural language

If instead one starts with a fixed grammar, e.g. that of English, and specifies a handful of words, then generation is useful for converting a bag of concepts into a sequence of spoken sentences. That is, to move from semantic networks to surface structure. For example, given the abstract concepts "Ben", "pizza" and "to eat", and the grammar for the English language, one wishes to generate any plausible sentence that embeds these concepts. Ideally, the sentence is short and not too flowery, and perhaps has a constraint on tense, number, and other linguistic features.

The plan is to tackle this after basic generation sort-of-works-ish.

Abstract generation

As sketched above, logic, reasoning, inference, and deduction can all be characterized as the assembly of jigsaw pieces. It is hoped that the above system will be general enough to "easily" provide an alternative implementation for several existing OpenCog systems, specifically, for PLN (Probabilistic Logic Networks), the URE (Unified Rule Engine) and the OpenPsi rule scheduling system.

Architecture

In what follows, the terms "section", "germ" and "disjunct" will be used somewhat interchangeably. The differences are as follows:

  • A "germ" is just one item (a "point"), with a list of connectors on it.
  • Commonly, an object (a "point") will have several germs associated with it these are disjoined from one-another, and are thus called "disjuncts". The disjoin is in the sense of a menu-entry: you can pick one, but only one.
  • A "section" is a collection of multiple germs, connected to one-another. Such a collection will typically have unconnected connectors, and thus behaves much like one giant-sized germ. It's like a partially-assembled jigsaw-puzzle: the assembled portions behave much like single giant-sized pieces. The term "section" refers to a "section of a sheaf": starting from one particular germ, one can extend outwards "horizontally" in a coherent fashion. Coherency requires that all of the gluing axioms of a sheaf must be satisfied.

Germs

With this in mind, germs are represented as OpenCog Atoms as follows:

   Section
       Atom "foo"
       ConnectorSeq
           Connector
               Atom "bar"
               ConnectorDir "+"
           Connector
               ...

Here, Atom "foo" and Atom "bar" can be any Atomese Atom; for natural language, these will typically be either WordNodes for individual words, or WordClassNodes for collections of words (nouns, verbs, etc.). The user is free to choose what kind of Atoms to use here; there is no pre-established convention (except for words, when dealing with linguistic graphs).

Two germs can be connected together if and only if they have matching connectors of opposite polarity. Thus,

    Connector
        Atom "bar"
        ConnectorDir "+"

can only connect to

    Connector
        Atom "bar"
        ConnectorDir "-"

The polarity is indicated with ConnectorDir. Several different kinds of polarity are possible, and are in common use. By convention, the +/- polarities indicate linear order: something must come to the left/right of the other. The h/d polarities indicate head/dependent relationships: a directed edge. The v/g polarities indicate variable/ground relationships: a variable that can be beta-reduced with a particular value. The polarity pairs are by convention only; they are not mandated by the system.

This representation is discussed in greater detail in the Connectors and Sections wiki page.

Implementation

There is an inherent combinatorial explosion, which will certainly be CPU-intensive, and require considerable algorithmic sophistication, e.g. pruning, to make things run fast. Thus, in anticipation of this, the prototype implementation will be in C++. There were/are three other design choices:

  • Use the Link-Grammar internal code. This code is now extremely fast, and uses some very robust pruning algos. It has two drawbacks: it assumes sequential order (i.e. words in a sentence) and has a large number of in-built assumptions aimed at language parsing, rather than generation.

  • Write everything in scheme (or even python), and use the pattern matcher for all heavy lifting. This does not seem tenable at this time.

  • Locate some existing system that meets many of the requirements, and modify it to fit. I don't know of any system that even comes close to meeting any of the requirements. If you do, please let me know! I have no desire to reinvent any wheels, here.

Version 0.1.0

The current code implements a breadth-first aggregation algorithm. It provides two search modes: a deterministic explorer that will exhaustively generate all finite "unambiguous" graphs, and an random network explorer, useful for sampling from larger grammars that cannot be fully explored via exhaustive enumeration. It passes all unit tests. See opencog/generate/README for algo details.

The deterministic explorer is works well, and is effectively complete. It explores all possible graphs up to a given depth (maximum diameter), and thus provides an exhaustive listing, even in the case of grammars to might generate an infinite number of graphs.

The random explorer seems to work "well enough", but is still missing desirable features. These will be added as the need arises. Foremost are additional tunable parameters to control the statistical distribution of the generated graphs.

This has not yet been tried on anything but small, toy grammars, and may fail pathologically, or get bogged down with poor performance, for large, complex grammars.

Upcoming plans are to provide constraints to generate planar graphs. An extension to force linear order (so as to obtain sequences, e.g. word sequences) is also required.

Some of the missing features are listed in the github issues list.

Building & testing

The code here presumes the AtomSpace as a pre-requisite. The AtomSpace is a (hyper-)graph database with assorted advanced features not found in other graph databases; this is why it's used here.

Building and testing works exactly the same way as the AtomSpace; build that, and then build the stuff here in the same way.

Examples

Jump to the examples directory!

The demo directory contains a simple epidemic-network simulation model. It demonstrates different aspects of the AtomSpace, such as value flows, as well as random network generation. There's even a blog post that you might want to read first.

generate's People

Contributors

linas avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

generate's Issues

Allow multiple connectors of the same type.

The code, as written, currently allows only one connector of a given type in a disjunct. Of course, it should be possible to have more than one; this requires adding tracking info as to which of several can be referred to. This should not be hard, but it is invasive.

exclusive link types.

In the SEIR Covid-19 simulation, the generated random network contains both "friend" and "stranger" relationship links between individuals. It should be possible to somehow say "if a link of one types already exists, do not create a link of the other type". A work-around for this is to allow one and only one link between two network points, no matter what the link-type may be (instead of creating one link of type "friend" and one link of type "stranger").

Estimate if/when grammars lead to infinite recursion.

For simple grammars (and maybe for all grammars?) its seems possible to determine in advance, if they will lead to infinite recursion, on average. Infiinte recusion happens if, on average the likelihood of picking an arity-three (or larger) section exceeds the likelihood of picking an arity-one section. That is, an arity-n section increases the number of open connectors by (n-2) on average, while an arity-one link reduces the number of open connectors by one. Since each section is weighted with the probability of it being chosen, it is a "simple matter" of computing the expectation values.

Its not entirely simple, when there are multiple connector types, but ... it seems feasible to do in code, and can provide advance warning of infinite recursion, before generation is even started. Seems low-priority, for now. See the export-to-gml.scm example for an explicit calculation for the simple case.

Error executing export-to-gml.scm example

Hi,
I'm getting an error when executing the export-to-gml example at this step:

;; Convert the Atomese representation of these networks into
;; a GML string.
(define gml-string (export-to-gml graph-set))
scheme@(guile-user) [1]> (define gml-string (export-to-gml graph-set))
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Value out of range 0 to 18446744073709551615: -1

Some direction about to to fix that?
Thanks,
Ely

Build fails

�[1;34m[octool] Source Directory is set to /home/opencog/generate�[0m
�[1;34m[octool] Build Directory is set to /home/opencog/generate/build�[0m
�[1;34m[octool] cmake -B/home/opencog/generate/build -H/home/opencog/generate�[0m
Found CMake version 3.16.3
-- The C compiler identification is GNU 9.4.0
-- The CXX compiler identification is GNU 9.4.0
-- Check for working C compiler: /usr/lib/ccache/cc
-- Check for working C compiler: /usr/lib/ccache/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/lib/ccache/c++
-- Check for working CXX compiler: /usr/lib/ccache/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build type: Release
-- CogUtil found.
-- AtomSpace found.
-- Found PythonInterp: /usr/bin/python3.8 (found version "3.8.10")
-- CxxTest found.
-- Guile (3.0.7 >= 2.2.2) was found.

Building for Ubuntu 20.04.5 LTS

The following components will be built:

Generate - Graph Generation.
Scheme bindings - Scheme (guile) bindings.
Unit tests - Unit tests.

-- Configuring done
-- Generating done
-- Build files have been written to: /home/opencog/generate/build
�[1;34m[octool] make -C /home/opencog/generate/build -j16�[0m
make: Entering directory '/home/opencog/generate/build'
make[1]: Entering directory '/home/opencog/generate/build'
make[2]: Entering directory '/home/opencog/generate/build'
make[2]: Entering directory '/home/opencog/generate/build'
make[2]: Entering directory '/home/opencog/generate/build'
Scanning dependencies of target COPY_TO_LOAD_PATH_IN_BUILD_DIR_FROM__home_opencog_generate_opencog_scm
Scanning dependencies of target SCM_CONFIG
make[2]: Leaving directory '/home/opencog/generate/build'
make[2]: Leaving directory '/home/opencog/generate/build'
Scanning dependencies of target generate
make[2]: Entering directory '/home/opencog/generate/build'
make[2]: Leaving directory '/home/opencog/generate/build'
make[2]: Entering directory '/home/opencog/generate/build'
[ 0%] Built target SCM_CONFIG
[ 9%] Building CXX object opencog/generate/CMakeFiles/generate.dir/CollectStyle.cc.o
[ 18%] Building CXX object opencog/generate/CMakeFiles/generate.dir/Dictionary.cc.o
[ 27%] Building CXX object opencog/generate/CMakeFiles/generate.dir/Aggregate.cc.o
[ 36%] Building CXX object opencog/generate/CMakeFiles/generate.dir/RandomCallback.cc.o
[ 45%] Building CXX object opencog/generate/CMakeFiles/generate.dir/BasicParameters.cc.o
[ 54%] Building CXX object opencog/generate/CMakeFiles/generate.dir/Frame.cc.o
[ 63%] Building CXX object opencog/generate/CMakeFiles/generate.dir/LinkStyle.cc.o
[ 72%] Building CXX object opencog/generate/CMakeFiles/generate.dir/SimpleCallback.cc.o
make[2]: Leaving directory '/home/opencog/generate/build'
[ 72%] Built target COPY_TO_LOAD_PATH_IN_BUILD_DIR_FROM__home_opencog_generate_opencog_scm
In file included from /home/opencog/generate/opencog/generate/Frame.h:25,
from /home/opencog/generate/opencog/generate/RandomParameters.h:25,
from /home/opencog/generate/opencog/generate/BasicParameters.h:26,
from /home/opencog/generate/opencog/generate/BasicParameters.cc:22:
/usr/local/include/opencog/atomspace/AtomSpace.h:58:1: error: expected class-name before ‘{’ token
58 | {
| ^
/usr/local/include/opencog/atomspace/AtomSpace.h: In member function ‘virtual const HandleSeq& opencog::AtomSpace::getOutgoingSet() const’:
/usr/local/include/opencog/atomspace/AtomSpace.h:205:62: error: ‘_outgoing’ was not declared in this scope
205 | virtual const HandleSeq& getOutgoingSet() const { return _outgoing; }
| ^~~~~~~~~
/usr/local/include/opencog/atomspace/AtomSpace.h: In function ‘opencog::AtomSpacePtr opencog::AtomSpaceCast(opencog::AtomSpace*)’:
/usr/local/include/opencog/atomspace/AtomSpace.h:542:32: error: ‘class opencog::AtomSpace’ has no member named ‘shared_from_this’
542 | { return AtomSpaceCast(as->shared_from_this()); }
| ^~~~~~~~~~~~~~~~
/usr/local/include/opencog/atomspace/AtomSpace.h: In function ‘opencog::Handle opencog::HandleCast(opencog::AtomSpace*)’:
/usr/local/include/opencog/atomspace/AtomSpace.h:544:29: error: ‘class opencog::AtomSpace’ has no member named ‘shared_from_this’
544 | { return HandleCast(as->shared_from_this()); }
| ^~~~~~~~~~~~~~~~
/usr/local/include/opencog/atomspace/AtomSpace.h: In function ‘opencog::AtomSpacePtr opencog::createAtomSpace(Args&& ...)’:
/usr/local/include/opencog/atomspace/AtomSpace.h:553:7: error: ‘using element_type = class opencog::AtomSpace’ {aka ‘class opencog::AtomSpace’} has no member named ‘install’
553 | asp->install();
| ^~~~~~~
make[2]: *** [opencog/generate/CMakeFiles/generate.dir/build.make:76: opencog/generate/CMakeFiles/generate.dir/BasicParameters.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs....
In file included from /home/opencog/generate/opencog/generate/Aggregate.h:29,
from /home/opencog/generate/opencog/generate/Aggregate.cc:28:
/home/opencog/generate/opencog/generate/GenerateCallback.h:114:35: error: ‘Odometer’ does not name a type
114 | virtual void push_odometer(const Odometer&) {}
| ^~~~~~~~
/home/opencog/generate/opencog/generate/GenerateCallback.h:115:34: error: ‘Odometer’ does not name a type
115 | virtual void pop_odometer(const Odometer&) {}
| ^~~~~~~~
In file included from /home/opencog/generate/opencog/generate/Aggregate.cc:28:
/home/opencog/generate/opencog/generate/Aggregate.h:48:2: error: ‘Odometer’ does not name a type
48 | Odometer _odo;
| ^~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.h:55:13: error: ‘Odometer’ was not declared in this scope
55 | std::stack _odo_stack;
| ^~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.h:55:21: error: template argument 1 is invalid
55 | std::stack _odo_stack;
| ^
/home/opencog/generate/opencog/generate/Aggregate.h:55:21: error: template argument 2 is invalid
/home/opencog/generate/opencog/generate/Aggregate.h:47:8: error: cannot declare field ‘opencog::Aggregate::_frame’ to be of abstract type ‘opencog::Frame’
47 | Frame _frame;
| ^~~~~~
In file included from /usr/local/include/opencog/atomspace/AtomSpace.h:38,
from /home/opencog/generate/opencog/generate/Aggregate.cc:26:
/usr/local/include/opencog/atomspace/Frame.h:38:7: note: because the following virtual functions are pure within ‘opencog::Frame’:
38 | class Frame : public Atom
| ^~~~~
In file included from /usr/local/include/opencog/atoms/base/Link.h:30,
from /home/opencog/generate/opencog/generate/Aggregate.cc:25:
/usr/local/include/opencog/atoms/base/Atom.h:441:25: note: ‘virtual std::string opencog::Atom::to_string(const string&) const’
441 | virtual std::string to_string(const std::string& indent) const = 0;
| ^~~~~~~~~
/usr/local/include/opencog/atoms/base/Atom.h:442:25: note: ‘virtual std::string opencog::Atom::to_short_string(const string&) const’
442 | virtual std::string to_short_string(const std::string& indent) const = 0;
| ^~~~~~~~~~~~~~~
/usr/local/include/opencog/atoms/base/Atom.h:281:25: note: ‘virtual opencog::ContentHash opencog::Atom::compute_hash() const’
281 | virtual ContentHash compute_hash() const = 0;
| ^~~~~~~~~~~~
/usr/local/include/opencog/atoms/base/Atom.h:463:18: note: ‘virtual bool opencog::Atom::operator==(const opencog::Atom&) const’
463 | virtual bool operator==(const Atom&) const = 0;
| ^~~~~~~~
/usr/local/include/opencog/atoms/base/Atom.h:476:18: note: ‘virtual bool opencog::Atom::operator<(const opencog::Atom&) const’
476 | virtual bool operator<(const Atom&) const = 0;
| ^~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc: In constructor ‘opencog::Aggregate::Aggregate(opencog::AtomSpace*)’:
/home/opencog/generate/opencog/generate/Aggregate.cc:38:10: error: no matching function for call to ‘opencog::Frame::Frame()’
38 | : _as(as)
| ^
In file included from /usr/local/include/opencog/atomspace/AtomSpace.h:38,
from /home/opencog/generate/opencog/generate/Aggregate.cc:26:
/usr/local/include/opencog/atomspace/Frame.h:62:2: note: candidate: ‘opencog::Frame::Frame(opencog::Type, opencog::HandleSeq)’
62 | Frame(Type t, const HandleSeq oset)
| ^~~~~
/usr/local/include/opencog/atomspace/Frame.h:62:2: note: candidate expects 2 arguments, 0 provided
/usr/local/include/opencog/atomspace/Frame.h:57:2: note: candidate: ‘opencog::Frame::Frame(opencog::Type)’
57 | Frame(Type t)
| ^~~~~
/usr/local/include/opencog/atomspace/Frame.h:57:2: note: candidate expects 1 argument, 0 provided
/home/opencog/generate/opencog/generate/Aggregate.cc: In member function ‘void opencog::Aggregate::clear()’:
/home/opencog/generate/opencog/generate/Aggregate.cc:54:24: error: request for member ‘empty’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
54 | while (not _odo_stack.empty()) _odo_stack.pop();
| ^~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:54:44: error: request for member ‘pop’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
54 | while (not _odo_stack.empty()) _odo_stack.pop();
| ^~~
/home/opencog/generate/opencog/generate/Aggregate.cc:56:9: error: ‘class opencog::Frame’ has no member named ‘clear’
56 | _frame.clear();
| ^~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:57:2: error: ‘_odo’ was not declared in this scope
57 | _odo.clear();
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc: In member function ‘void opencog::Aggregate::aggregate(const HandleSet&, opencog::GenerateCallback&)’:
/home/opencog/generate/opencog/generate/Aggregate.cc:83:11: error: ‘class opencog::Frame’ has no member named ‘_open_sections’
83 | _frame._open_sections.insert(sect);
| ^~~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc: In member function ‘void opencog::Aggregate::recurse()’:
/home/opencog/generate/opencog/generate/Aggregate.cc:95:18: error: ‘class opencog::Frame’ has no member named ‘_open_sections’
95 | if (0 == _frame._open_sections.size()) return;
| ^~~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:101:36: error: request for member ‘size’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
101 | _frame_stack.size(), _odo_stack.size());
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:117:2: error: ‘_odo’ was not declared in this scope
117 | _odo._step = 0;
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc: In member function ‘bool opencog::Aggregate::init_odometer()’:
/home/opencog/generate/opencog/generate/Aggregate.cc:150:2: error: ‘_odo’ was not declared in this scope
150 | _odo._from_index.clear();
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:155:34: error: ‘class opencog::Frame’ has no member named ‘_open_sections’
155 | for (const Handle& sect: _frame._open_sections)
| ^~~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc: In member function ‘bool opencog::Aggregate::do_step()’:
/home/opencog/generate/opencog/generate/Aggregate.cc:194:13: error: ‘class opencog::Frame’ has no member named ‘_wheel’
194 | if (_frame._wheel == _odo._step and
| ^~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:194:23: error: ‘_odo’ was not declared in this scope
194 | if (_frame._wheel == _odo._step and
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:195:13: error: ‘class opencog::Frame’ has no member named ‘_nodo’
195 | _frame._nodo == _odo_stack.size()) pop_frame();
| ^~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:195:33: error: request for member ‘size’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
195 | _frame._nodo == _odo_stack.size()) pop_frame();
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:198:17: error: ‘_odo’ was not declared in this scope
198 | _odo._step, _odo._size, _odo_stack.size());
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:198:52: error: request for member ‘size’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
198 | _odo._step, _odo._size, _odo_stack.size());
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:215:46: error: request for member ‘size’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
215 | ic, _odo._size, _odo_stack.size());
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:237:46: error: request for member ‘size’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
237 | ic, _odo._size, _odo_stack.size());
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:249:10: error: ‘class opencog::Frame’ has no member named ‘_wheel’
249 | _frame._wheel = ic;
| ^~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:265:54: error: request for member ‘size’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
265 | _odo._step, _odo._size, _odo_stack.size());
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:274:10: error: ‘class opencog::Frame’ has no member named ‘_open_points’
274 | _frame._open_points.size(), _frame._open_sections.size(),
| ^~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:274:38: error: ‘class opencog::Frame’ has no member named ‘_open_sections’
274 | _frame._open_points.size(), _frame._open_sections.size(),
| ^~~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:275:10: error: ‘class opencog::Frame’ has no member named ‘_linkage’
275 | _frame._linkage.size());
| ^~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:278:18: error: ‘class opencog::Frame’ has no member named ‘_open_sections’
278 | if (0 == _frame._open_sections.size())
| ^~~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc: In member function ‘bool opencog::Aggregate::step_odometer()’:
/home/opencog/generate/opencog/generate/Aggregate.cc:289:36: error: request for member ‘size’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
289 | _frame_stack.size(), _odo_stack.size());
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:294:6: error: ‘_odo’ was not declared in this scope
294 | if (_odo._size < _odo._step) return false;
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:301:19: error: ‘_odo’ was not declared in this scope
301 | if (SIZE_MAX == _odo._step)
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:303:67: error: request for member ‘size’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
303 | logger().fine("Exhaused the odometer at depth %lu", _odo_stack.size());
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:306:50: error: ‘_odo’ was not declared in this scope
306 | logger().fine("Failed to step, try wheel %lu", _odo._step);
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc: In member function ‘opencog::HandlePair opencog::Aggregate::connect_section(const opencog::Handle&, size_t, const opencog::Handle&, const opencog::Handle&)’:
/home/opencog/generate/opencog/generate/Aggregate.cc:330:9: error: ‘print_section’ is not a member of ‘opencog::Frame’
330 | Frame::print_section(fm_sect);
| ^~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:331:9: error: ‘print_section’ is not a member of ‘opencog::Frame’
331 | Frame::print_section(to_sect);
| ^~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc: In member function ‘opencog::Handle opencog::Aggregate::make_link(const opencog::Handle&, size_t, const opencog::Handle&)’:
/home/opencog/generate/opencog/generate/Aggregate.cc:392:9: error: ‘class opencog::Frame’ has no member named ‘_open_sections’
392 | _frame._open_sections.erase(sect);
| ^~~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:398:10: error: ‘class opencog::Frame’ has no member named ‘_open_sections’
398 | _frame._open_sections.insert(linking);
| ^~~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:399:10: error: ‘class opencog::Frame’ has no member named ‘_open_points’
399 | _frame._open_points.insert(point);
| ^~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:404:10: error: ‘class opencog::Frame’ has no member named ‘_linkage’
404 | _frame._linkage.insert(linking);
| ^~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:405:10: error: ‘class opencog::Frame’ has no member named ‘_open_points’
405 | _frame._open_points.erase(point);
| ^~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc: In member function ‘void opencog::Aggregate::push_frame()’:
/home/opencog/generate/opencog/generate/Aggregate.cc:416:21: error: ‘_odo’ was not declared in this scope
416 | _odo_sections.push(_odo._sections);
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:417:9: error: ‘class opencog::Frame’ has no member named ‘_nodo’
417 | _frame._nodo = _odo_stack.size();
| ^~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:417:28: error: request for member ‘size’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
417 | _frame._nodo = _odo_stack.size();
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:418:9: error: ‘class opencog::Frame’ has no member named ‘_wheel’
418 | _frame._wheel = -1;
| ^~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:421:35: error: ‘class opencog::Frame’ has no member named ‘_open_points’
421 | _frame_stack.size(), _frame._open_points.size(),
| ^~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:422:14: error: ‘class opencog::Frame’ has no member named ‘_open_sections’
422 | _frame._open_sections.size(), _frame._linkage.size());
| ^~~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:422:44: error: ‘class opencog::Frame’ has no member named ‘_linkage’
422 | _frame._open_sections.size(), _frame._linkage.size());
| ^~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc: In member function ‘void opencog::Aggregate::pop_frame()’:
/home/opencog/generate/opencog/generate/Aggregate.cc:429:2: error: ‘_odo’ was not declared in this scope
429 | _odo._sections = _odo_sections.top(); _odo_sections.pop();
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:432:35: error: ‘class opencog::Frame’ has no member named ‘_open_points’
432 | _frame_stack.size(), _frame._open_points.size(),
| ^~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:433:14: error: ‘class opencog::Frame’ has no member named ‘_open_sections’
433 | _frame._open_sections.size(), _frame._linkage.size());
| ^~~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:433:44: error: ‘class opencog::Frame’ has no member named ‘_linkage’
433 | _frame._open_sections.size(), _frame._linkage.size());
| ^~~~~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:434:9: error: ‘class opencog::Frame’ has no member named ‘print’
434 | _frame.print();
| ^~~~~
/home/opencog/generate/opencog/generate/Aggregate.cc: In member function ‘void opencog::Aggregate::push_odo()’:
/home/opencog/generate/opencog/generate/Aggregate.cc:440:21: error: ‘_odo’ was not declared in this scope
440 | _cb->push_odometer(_odo);
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:441:13: error: request for member ‘push’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
441 | _odo_stack.push(_odo);
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:443:65: error: request for member ‘size’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
443 | logger().fine("==== Push: Odo stack depth now %lu", _odo_stack.size());
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc: In member function ‘void opencog::Aggregate::pop_odo()’:
/home/opencog/generate/opencog/generate/Aggregate.cc:451:9: error: ‘_odo’ was not declared in this scope
451 | while (_odo._frame_depth < _frame_stack.size()) pop_frame();
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:453:20: error: ‘_odo’ was not declared in this scope
453 | _cb->pop_odometer(_odo);
| ^~~~
/home/opencog/generate/opencog/generate/Aggregate.cc:454:20: error: request for member ‘top’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
454 | _odo = _odo_stack.top(); _odo_stack.pop();
| ^~~
/home/opencog/generate/opencog/generate/Aggregate.cc:454:38: error: request for member ‘pop’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
454 | _odo = _odo_stack.top(); _odo_stack.pop();
| ^~~
/home/opencog/generate/opencog/generate/Aggregate.cc:456:64: error: request for member ‘size’ in ‘((opencog::Aggregate*)this)->opencog::Aggregate::_odo_stack’, which is of non-class type ‘int’
456 | logger().fine("==== Pop: Odo stack depth now %lu", _odo_stack.size());
| ^~~~
In file included from /usr/include/x86_64-linux-gnu/c++/9/bits/c++allocator.h:33,
from /usr/include/c++/9/bits/allocator.h:46,
from /usr/include/c++/9/bits/stl_tree.h:64,
from /usr/include/c++/9/map:60,
from /usr/local/include/opencog/util/Logger.h:31,
from /home/opencog/generate/opencog/generate/Aggregate.cc:22:
/usr/include/c++/9/ext/new_allocator.h: In instantiation of ‘void __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up = opencog::Frame; _Args = {const opencog::Frame&}; _Tp = opencog::Frame]’:
/usr/include/c++/9/bits/alloc_traits.h:483:4: required from ‘static void std::allocator_traits<std::allocator<_Tp1> >::construct(std::allocator_traits<std::allocator<_Tp1> >::allocator_type&, _Up*, _Args&& ...) [with _Up = opencog::Frame; _Args = {const opencog::Frame&}; _Tp = opencog::Frame; std::allocator_traits<std::allocator<_Tp1> >::allocator_type = std::allocatoropencog::Frame]’
/usr/include/c++/9/bits/stl_deque.h:1574:30: required from ‘void std::deque<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = opencog::Frame; _Alloc = std::allocatoropencog::Frame; std::deque<_Tp, _Alloc>::value_type = opencog::Frame]’
/usr/include/c++/9/bits/stl_stack.h:234:9: required from ‘void std::stack<_Tp, _Sequence>::push(const value_type&) [with _Tp = opencog::Frame; _Sequence = std::deque<opencog::Frame, std::allocatoropencog::Frame >; std::stack<_Tp, _Sequence>::value_type = opencog::Frame]’
/home/opencog/generate/opencog/generate/Aggregate.cc:415:26: required from here
/usr/include/c++/9/ext/new_allocator.h:146:4: error: invalid new-expression of abstract class type ‘opencog::Frame’
146 | { ::new((void )__p) _Up(std::forward<_Args>(__args)...); }
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [opencog/generate/CMakeFiles/generate.dir/build.make:63: opencog/generate/CMakeFiles/generate.dir/Aggregate.cc.o] Error 1
In file included from /home/opencog/generate/opencog/generate/Frame.h:25,
from /home/opencog/generate/opencog/generate/CollectStyle.h:25,
from /home/opencog/generate/opencog/generate/CollectStyle.cc:24:
/usr/local/include/opencog/atomspace/AtomSpace.h:58:1: error: expected class-name before ‘{’ token
58 | {
| ^
/usr/local/include/opencog/atomspace/AtomSpace.h: In member function ‘virtual const HandleSeq& opencog::AtomSpace::getOutgoingSet() const’:
/usr/local/include/opencog/atomspace/AtomSpace.h:205:62: error: ‘_outgoing’ was not declared in this scope
205 | virtual const HandleSeq& getOutgoingSet() const { return _outgoing; }
| ^~~~~~~~~
/usr/local/include/opencog/atomspace/AtomSpace.h: In function ‘opencog::AtomSpacePtr opencog::AtomSpaceCast(opencog::AtomSpace
)’:
/usr/local/include/opencog/atomspace/AtomSpace.h:542:32: error: ‘class opencog::AtomSpace’ has no member named ‘shared_from_this’
542 | { return AtomSpaceCast(as->shared_from_this()); }
| ^~~~~~~~~~~~~~~~
/usr/local/include/opencog/atomspace/AtomSpace.h: In function ‘opencog::Handle opencog::HandleCast(opencog::AtomSpace*)’:
/usr/local/include/opencog/atomspace/AtomSpace.h:544:29: error: ‘class opencog::AtomSpace’ has no member named ‘shared_from_this’
544 | { return HandleCast(as->shared_from_this()); }
| ^~~~~~~~~~~~~~~~
/usr/local/include/opencog/atomspace/AtomSpace.h: In function ‘opencog::AtomSpacePtr opencog::createAtomSpace(Args&& ...)’:
/usr/local/include/opencog/atomspace/AtomSpace.h:553:7: error: ‘using element_type = class opencog::AtomSpace’ {aka ‘class opencog::AtomSpace’} has no member named ‘install’
553 | asp->install();
| ^~~~~~~
make[2]: *** [opencog/generate/CMakeFiles/generate.dir/build.make:89: opencog/generate/CMakeFiles/generate.dir/CollectStyle.cc.o] Error 1
/home/opencog/generate/opencog/generate/Frame.cc:30:6: error: no declaration matches ‘void opencog::Frame::clear()’
30 | void Frame::clear(void)
| ^~~~~
/home/opencog/generate/opencog/generate/Frame.cc:30:6: note: no functions named ‘void opencog::Frame::clear()’
In file included from /usr/local/include/opencog/atomspace/AtomSpace.h:38,
from /home/opencog/generate/opencog/generate/Frame.cc:24:
/usr/local/include/opencog/atomspace/Frame.h:38:7: note: ‘class opencog::Frame’ defined here
38 | class Frame : public Atom
| ^~~~~
/home/opencog/generate/opencog/generate/Frame.cc:39:6: error: ‘Odometer’ has not been declared
39 | void Odometer::clear(void)
| ^~~~~~~~
/home/opencog/generate/opencog/generate/Frame.cc: In function ‘void clear()’:
/home/opencog/generate/opencog/generate/Frame.cc:41:2: error: ‘_sections’ was not declared in this scope
41 | _sections.clear();
| ^~~~~~~~~
/home/opencog/generate/opencog/generate/Frame.cc:42:2: error: ‘_from_index’ was not declared in this scope
42 | _from_index.clear();
| ^~~~~~~~~~~
/home/opencog/generate/opencog/generate/Frame.cc:43:2: error: ‘_to_connectors’ was not declared in this scope
43 | _to_connectors.clear();
| ^~~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Frame.cc:44:2: error: ‘_size’ was not declared in this scope; did you mean ‘dysize’?
44 | _size = 0;
| ^~~~~
| dysize
/home/opencog/generate/opencog/generate/Frame.cc:45:2: error: ‘_step’ was not declared in this scope
45 | _step = -1;
| ^~~~~
/home/opencog/generate/opencog/generate/Frame.cc:46:2: error: ‘_frame_depth’ was not declared in this scope
46 | _frame_depth = 0;
| ^~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Frame.cc: At global scope:
/home/opencog/generate/opencog/generate/Frame.cc:54:6: error: no declaration matches ‘void opencog::Frame::print_section(const opencog::Handle&)’
54 | void Frame::print_section(const Handle& section)
| ^~~~~
/home/opencog/generate/opencog/generate/Frame.cc:54:6: note: no functions named ‘void opencog::Frame::print_section(const opencog::Handle&)’
In file included from /usr/local/include/opencog/atomspace/AtomSpace.h:38,
from /home/opencog/generate/opencog/generate/Frame.cc:24:
/usr/local/include/opencog/atomspace/Frame.h:38:7: note: ‘class opencog::Frame’ defined here
38 | class Frame : public Atom
| ^~~~~
/home/opencog/generate/opencog/generate/Frame.cc:73:6: error: no declaration matches ‘void opencog::Frame::print() const’
73 | void Frame::print(void) const
| ^~~~~
/home/opencog/generate/opencog/generate/Frame.cc:73:6: note: no functions named ‘void opencog::Frame::print() const’
In file included from /usr/local/include/opencog/atomspace/AtomSpace.h:38,
from /home/opencog/generate/opencog/generate/Frame.cc:24:
/usr/local/include/opencog/atomspace/Frame.h:38:7: note: ‘class opencog::Frame’ defined here
38 | class Frame : public Atom
| ^~~~~
/home/opencog/generate/opencog/generate/Frame.cc:92:6: error: ‘Odometer’ has not been declared
92 | void Odometer::print_wheel(const Frame& frm, size_t i) const
| ^~~~~~~~
/home/opencog/generate/opencog/generate/Frame.cc:92:56: error: non-member function ‘void print_wheel(const opencog::Frame&, size_t)’ cannot have cv-qualifier
92 | void Odometer::print_wheel(const Frame& frm, size_t i) const
| ^~~~~
/home/opencog/generate/opencog/generate/Frame.cc: In function ‘void print_wheel(const opencog::Frame&, size_t)’:
/home/opencog/generate/opencog/generate/Frame.cc:95:26: error: ‘_sections’ was not declared in this scope
95 | const Handle& fm_sect = _sections[i];
| ^~~~~~~~~
/home/opencog/generate/opencog/generate/Frame.cc:96:10: error: ‘const class opencog::Frame’ has no member named ‘_open_sections’
96 | if (frm._open_sections.find(fm_sect) == frm._open_sections.end())
| ^~~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Frame.cc:96:46: error: ‘const class opencog::Frame’ has no member named ‘_open_sections’
96 | if (frm._open_sections.find(fm_sect) == frm._open_sections.end())
| ^~~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Frame.cc:100:47: error: ‘_from_index’ was not declared in this scope
100 | const Handle& fm_con = disj->getOutgoingAtom(_from_index[i]);
| ^~~~~~~~~~~
/home/opencog/generate/opencog/generate/Frame.cc:109:4: error: ‘_to_connectors’ was not declared in this scope
109 | _to_connectors[i]->getOutgoingAtom(1)->get_name().c_str(),
| ^~~~~~~~~~~~~~
/home/opencog/generate/opencog/generate/Frame.cc: At global scope:
/home/opencog/generate/opencog/generate/Frame.cc:128:6: error: ‘Odometer’ has not been declared
128 | void Odometer::print_odometer(const Frame& frm) const
| ^~~~~~~~
/home/opencog/generate/opencog/generate/Frame.cc:128:49: error: non-member function ‘void print_odometer(const opencog::Frame&)’ cannot have cv-qualifier
128 | void Odometer::print_odometer(const Frame& frm) const
| ^~~~~
/home/opencog/generate/opencog/generate/Frame.cc: In function ‘void print_odometer(const opencog::Frame&)’:
/home/opencog/generate/opencog/generate/Frame.cc:130:46: error: ‘_size’ was not declared in this scope; did you mean ‘dysize’?
130 | logger().fine("Odometer State: length %lu", _size);
| ^~~~~
| dysize
make[2]: *** [opencog/generate/CMakeFiles/generate.dir/build.make:115: opencog/generate/CMakeFiles/generate.dir/Frame.cc.o] Error 1
In file included from /home/opencog/generate/opencog/generate/Frame.h:25,
from /home/opencog/generate/opencog/generate/CollectStyle.h:25,
from /home/opencog/generate/opencog/generate/RandomCallback.h:25,
from /home/opencog/generate/opencog/generate/RandomCallback.cc:27:
/usr/local/include/opencog/atomspace/AtomSpace.h:58:1: error: expected class-name before ‘{’ token
58 | {
| ^
/usr/local/include/opencog/atomspace/AtomSpace.h: In member function ‘virtual const HandleSeq& opencog::AtomSpace::getOutgoingSet() const’:
/usr/local/include/opencog/atomspace/AtomSpace.h:205:62: error: ‘_outgoing’ was not declared in this scope
205 | virtual const HandleSeq& getOutgoingSet() const { return _outgoing; }
| ^~~~~~~~~
/usr/local/include/opencog/atomspace/AtomSpace.h: In function ‘opencog::AtomSpacePtr opencog::AtomSpaceCast(opencog::AtomSpace*)’:
/usr/local/include/opencog/atomspace/AtomSpace.h:542:32: error: ‘class opencog::AtomSpace’ has no member named ‘shared_from_this’
542 | { return AtomSpaceCast(as->shared_from_this()); }
| ^~~~~~~~~~~~~~~~
/usr/local/include/opencog/atomspace/AtomSpace.h: In function ‘opencog::Handle opencog::HandleCast(opencog::AtomSpace*)’:
/usr/local/include/opencog/atomspace/AtomSpace.h:544:29: error: ‘class opencog::AtomSpace’ has no member named ‘shared_from_this’
544 | { return HandleCast(as->shared_from_this()); }
| ^~~~~~~~~~~~~~~~
/usr/local/include/opencog/atomspace/AtomSpace.h: In function ‘opencog::AtomSpacePtr opencog::createAtomSpace(Args&& ...)’:
/usr/local/include/opencog/atomspace/AtomSpace.h:553:7: error: ‘using element_type = class opencog::AtomSpace’ {aka ‘class opencog::AtomSpace’} has no member named ‘install’
553 | asp->install();
| ^~~~~~~
make[2]: *** [opencog/generate/CMakeFiles/generate.dir/build.make:141: opencog/generate/CMakeFiles/generate.dir/RandomCallback.cc.o] Error 1
In file included from /home/opencog/generate/opencog/generate/Frame.h:25,
from /home/opencog/generate/opencog/generate/CollectStyle.h:25,
from /home/opencog/generate/opencog/generate/SimpleCallback.h:25,
from /home/opencog/generate/opencog/generate/SimpleCallback.cc:24:
/usr/local/include/opencog/atomspace/AtomSpace.h:58:1: error: expected class-name before ‘{’ token
58 | {
| ^
/usr/local/include/opencog/atomspace/AtomSpace.h: In member function ‘virtual const HandleSeq& opencog::AtomSpace::getOutgoingSet() const’:
/usr/local/include/opencog/atomspace/AtomSpace.h:205:62: error: ‘_outgoing’ was not declared in this scope
205 | virtual const HandleSeq& getOutgoingSet() const { return _outgoing; }
| ^~~~~~~~~
/usr/local/include/opencog/atomspace/AtomSpace.h: In function ‘opencog::AtomSpacePtr opencog::AtomSpaceCast(opencog::AtomSpace*)’:
/usr/local/include/opencog/atomspace/AtomSpace.h:542:32: error: ‘class opencog::AtomSpace’ has no member named ‘shared_from_this’
542 | { return AtomSpaceCast(as->shared_from_this()); }
| ^~~~~~~~~~~~~~~~
/usr/local/include/opencog/atomspace/AtomSpace.h: In function ‘opencog::Handle opencog::HandleCast(opencog::AtomSpace*)’:
/usr/local/include/opencog/atomspace/AtomSpace.h:544:29: error: ‘class opencog::AtomSpace’ has no member named ‘shared_from_this’
544 | { return HandleCast(as->shared_from_this()); }
| ^~~~~~~~~~~~~~~~
/usr/local/include/opencog/atomspace/AtomSpace.h: In function ‘opencog::AtomSpacePtr opencog::createAtomSpace(Args&& ...)’:
/usr/local/include/opencog/atomspace/AtomSpace.h:553:7: error: ‘using element_type = class opencog::AtomSpace’ {aka ‘class opencog::AtomSpace’} has no member named ‘install’
553 | asp->install();
| ^~~~~~~
make[2]: *** [opencog/generate/CMakeFiles/generate.dir/build.make:154: opencog/generate/CMakeFiles/generate.dir/SimpleCallback.cc.o] Error 1
make[2]: Leaving directory '/home/opencog/generate/build'
make[1]: *** [CMakeFiles/Makefile2:273: opencog/generate/CMakeFiles/generate.dir/all] Error 2
make[1]: Leaving directory '/home/opencog/generate/build'
make: *** [Makefile:130: all] Error 2
make: Leaving directory '/home/opencog/generate/build'

random selector: abandon odo if no forward progress

Sometimes, the random selector quickly advances to an odometer from which all further progress seems to be barred. Thus, all remaining search cycles are wasted searching and re-searching this impossible odo. There needs to be a way of detecting this impossible condition, and backing up a level.

In particular, this seems to always happen after one solution is found; a second solution is never found...

Control inf recursion on degenerate labels

The following graph

        +---------------------------Xp--------------+
        +--------------------WV---------------+     |
        |            +------------S-----------+     |
        |            +------MXs------+        |     |
        |            |  +------Xd----+        |     |
        +-----W------+  | +---Ds-----+        |     |
        |      +--D--+  | |    +--A--+-Xc-+   +--Xc-+
        |      |     |  | |    |     |    |   |     |
    LEFT-WALL the   dog , a black   lab   , barked  .

allows infinite recursion, because the Xc to period can attach to lab, which opens up a new, unconnected LEFT-WALL, which allows the graph to be further expanded, ad infinitum.

One obvious fix is to allow only one LEFT-WALL per graph. Another is the force planar graphs (issue #5) Are there other, more interesting solutions?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.