-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(use-modules (opencog)) doesn't seem to load scheme files #128
Comments
BTW, I've re-added (load-from-path "utilities.scm") at the end of opencog.scm. Same thing. |
Hi. If you use "use-modules" then all variables not exported by the module stay local inside the scope of module. Like a local function variables not visible from outside of the function or private methods in C++. There are several alternatives:
scheme@(guile-user)> (use-modules (opencog))
scheme@(guile-user)> (define-module (opencog))
$1 = #<directory (opencog) 2409870>
scheme@(opencog)> (stv 1 1)
$2 = (stv 1 0,99999982)
scheme@(opencog)>
scheme@(guile-user)> (load-from-path "opencog.scm")
scheme@(opencog)> (stv 1 1)
$1 = (stv 1 0,99999982)
scheme@(opencog)> Maybe this semantics changed between guile versions. Don't know. I checked GNU Guile 2.0.5-deb+1-1. |
Yes, What Jacek says is right; the current contents of opencog.scm makes an incorrect assumption about exports. The fix would need to be something like (export-everything-in-this-file "utilities.scm") and there must surely be something that already does this, but I don't know where. |
An alternative would be to change all "define" in those scm file to "define-public". That should export the functions (mentioned at https://github.com/opencog/atomspace/blob/master/opencog/scm/opencog.scm#L36 ) Might interfere with the cogserver's way to loading however... |
As a non scheme expert it seems the right fix is 1. suggested by @jswiergo . I'll proceed unless you have more suggestions. |
hmm, core_types.scm uses define-public. @williampma why do you think using define-public might interfere with the cogserver's way of loading? Anyway, I still like @jswiergo first suggestion better, it's good to have control over what is public and what is not, and it's better to have that information around the same place in a file. |
According to guile's manual define-public is equivalent to export. So if definie-public interferes with cogserver's way of loading so will export (if it's inside the file). Somehow I can't do (for-each export <FUN_LIST>) or (for-each (lambda (fun) (export fun) <FUN_LIST>) maybe I'll use define-public instead... |
I've come down to the following compromise, in each scheme file that can be used inside a module I define a function that exports all useful symbols and call it in the module definition, for instance I add (define (export-utilities) (export av stv itv ...)) in utilities.scm. Then add the following in opencog.scm (export-utilities) in opencog.scm. That way I don't create any interference and don't bloat the module definition. |
Any of these seem reasonable to me. I don't really know what the "best practices" is supposed to be. |
Ah, ignore my comment about interference. I just wasn't sure whether |
Closing. The problem as originally described appears to be fixed. I don't quite recall the problem, but using export in a loop seemed to be broken on guile, |
According to opencog/scm/opencog.scm scheme files like utilities.scm should be automatically loaded but aren't.
I've added a bunch of (display "~~~ N ~~~:") in opencog/scm/opencog.scm to see whether those loading lines are executed, they seem to be. I'm really puzzled, see below:
As you can see (stv 1 1) only runs after re-loading utilities.scm. Obviously (using-modules (opencog)) is present in my .guile config file. Running out of idea, any advice is welcome, thanks!
The text was updated successfully, but these errors were encountered: