Python API: scheme_eval_h not working

[memetic007]

After an entirely fresh install and build of opencog/atomspace, Python code using scheme_eval_h that previously ran under the old (February 2015) opencog/opencog build is failing.

Here is a Python test program running against opencog/atomspace that demonstrates that the Atomspace is working and the Python API add_node method is working, while attempting to add a node via scheme_eval_h fails:

from opencog.atomspace import Atom, AtomSpace, TruthValue, types, get_type_name
from opencog.scheme_wrapper import load_scm, scheme_eval, scheme_eval_h, __init__

atomspace = AtomSpace()
__init__(atomspace)

TRUTH_VALUE = TruthValue(1,1000000000)

data = ["opencog/atomspace/core_types.scm",
        "opencog/scm/utilities.scm"]

for item in data:
    load_scm(atomspace, item)

atomspace.add_node(types.ConceptNode, "Object_001",TRUTH_VALUE)
atomspace.add_node(types.ConceptNode, "Object_002",TRUTH_VALUE)

my_nodes = atomspace.get_atoms_by_type(types.ConceptNode)

for i in my_nodes:
        print i

scheme_string = \
    '''
    (ConceptNode "Object_003")
    '''

result = scheme_eval_h(atomspace, scheme_string)

Running that program produced the following errors:

Traceback (most recent call last): File "/home/jimrutt/PycharmProjects/SchemeEvalTests/SchemeEvalTest001.py", line 23, in result = scheme_eval_h(atomspace, scheme_string) File "scheme_wrapper.pyx", line 58, in opencog.scheme_wrapper.scheme_eval_h (/home/jimrutt/atomspace/build/opencog/cython/opencog/scheme_wrapper.cpp:1241) RuntimeError: Backtrace: In ice-9/boot-9.scm: 157: 12 [catch #t # ...] In unknown file: ?: 11 [apply-smob/1 #] In ice-9/boot-9.scm: 157: 10 [catch #t # ...] In unknown file: ?: 9 [apply-smob/1 #] ?: 8 [call-with-input-string "(ConceptNode \"Object_004\")" ...] In ice-9/boot-9.scm: 2401: 7 [save-module-excursion #<procedure a1e7690 at ice-9/eval-string.scm:65:9 ()>] In ice-9/eval-string.scm: 44: 6 [read-and-eval #<input: string 9e4dc30> #:lang ...] 37: 5 [lp (ConceptNode "Object_004")] In ice-9/eval.scm: 386: 4 [eval #<memoized (ConceptNode (quote "Object_004"))> ()] 393: 3 [eval # ()] In unknown file: ?: 2 [memoize-variable-access! # #<directory # 9f1e630>] In ice-9/boot-9.scm: 102: 1 [#<procedure a1e5a20 at ice-9/boot-9.scm:97:6 (thrown-k . args)> unbound-variable ...] In unknown file: ?: 0 [apply-smob/1 # unbound-variable ...]

ERROR: In procedure apply-smob/1: ERROR: Unbound variable: ConceptNode ABORT: unbound-variable (/home/jimrutt/atomspace/opencog/guile/SchemeEval.cc:879)

[memetic007]

The commit I built was:

commit a41f220c8018844d566c26f38ee9e64b54bbd06d

[cosmoharrigan]

@memetic007 I was able to replicate this issue by running the script you provided. The problem seemed to be that the .scm files core_types.scm and utilities.scm were not found.

If you provide absolute paths, then it works fine.

The following modified code works (after you change the absolute path defined for atomspace_build_folder to the correct value for your system):

from opencog.atomspace import Atom, AtomSpace, TruthValue, types, get_type_name
from opencog.scheme_wrapper import load_scm, scheme_eval, scheme_eval_h, __init__

atomspace = AtomSpace()
__init__(atomspace)

TRUTH_VALUE = TruthValue(1,1000000000)

data = ["opencog/atomspace/core_types.scm",
        "opencog/scm/utilities.scm"]

# Put the absolute path to the build folder for the atomspace repository here
atomspace_build_folder = "/home/cosmo/atomspace/build/"

for item in data:
    load_scm(atomspace, atomspace_build_folder + item)

atomspace.add_node(types.ConceptNode, "Object_001",TRUTH_VALUE)
atomspace.add_node(types.ConceptNode, "Object_002",TRUTH_VALUE)

my_nodes = atomspace.get_atoms_by_type(types.ConceptNode)

for i in my_nodes:
        print i

scheme_string = \
    '''
    (ConceptNode "Object_003")
    '''

result = scheme_eval_h(atomspace, scheme_string)

print(atomspace[result])

[linas]

If you do a sudo make install then I beleive that you could change the atomspace_build_folder fo be /usr/local/share and it would work, since those files get installed to /usr/local/share/opencog/scm/core_types.scm and the loader should be able to find that.

[linas]

BTW, load_scm and it's half-a-dozen other friends in opencog use a hacky fragile system to search a variety of different paths to find the files to be loaded. It mostly usually kind-of works-ish, but seems somehow inelegant. I don't have patience to find a "good" solution.

[memetic007]

The absolute file names work. Curiously, when using the relative file names core_types.scm failed to be found, while utilities.scm succeeded.

I rather don't like using absolute file names as they break portability. If relative file names are not going to work reliably, I'm going to switch to using /usr/local/share/opencog/ (which worked), though that would require everybody to install to achieve portability. Is "install" going to be specified in the "getting started' instructions going forward? It currently isn't.