Re: [opencog-dev] A few bugs while installing a test version of OpenCog

2017-05-29 Thread 'Nil Geisweiller' via opencog

Linas,

based on

https://github.com/opencog/atomspace/blob/master/opencog/scm/opencog.scm#L113

I assume that cog-undefined-handle is getting obsolete. However it is 
still on the wiki page


http://wiki.opencog.org/w/Scheme#cog-undefined-handle

Could you update that accordingly? (I wanted to do it but I'm not fully 
confident).


Thanks,
Nil

On 05/29/2017 03:01 PM, Nil Geisweiller wrote:
Thanks a lot for your detailed bug report! Ideally you would create 
github issues if each of these, but this is already greatly appreciated.


I'll have a careful look at them, already though regarding the slow down 
due to cog-undefined-handle this is probably because it is getting 
obsolete and I haven't removed it from all PLN rules (doing that now).


Nil

On 05/29/2017 02:50 AM, rocketpwr.com wrote:

Dear OpenCog Development Community,

First, thank you for your hard work on this project.

I found a few bugs that I have been able to work around that you might 
find helpful.  Hopefully the below description of the problems and my 
work-arounds will help you or someone else who comes across the same 
problems.


/*1) Really really long compile times on loading up the 
conceptnet4.scm test dataset in 
test-datasets/conceptnet/conceptnet4.scm*./  I left it to run 
overnight, and it still had not finished. Actually, I believe it was 
going to take 70+ hours to load and compile this 14.5 MB file.  This 
seemed strange to me as smaller files loaded much faster.  What I 
determined by experiment is that, for some unknown reason, the Guile 
Scheme compiler had a compile time that is proportional approximately 
n^2 of the number of rules.  Here are some results on my test rig (a 4 
core 4 GB Ubuntu 16.04 setup):


|
Rulesloadtime rules/sec

259737.00
6343120.45
10007014.29
124911011.35
|


Because the Conceptnet4.scm file is about 60.5K I estimate that the 
compile time would be around 71 hours or 3 days.  I am guessing this 
is a bug/feature in Guile Scheme which was not really meant as a 
database.


My work-around:  a) split the 60K rule file into 61 files of 1K rules 
each, and then compile them.  Each file compiles in around 14 seconds, 
reducing the compile time to around 1.5 hours.  Once compiled, the 
rules do not need to be compiled again.  b) I wrote a small loader 
that loads all 61 files into Guile in a single command.


*/2) Really long execution time for (cog-bind 
deduction-inheritance-rule):/* I am experimenting with PLN, using the 
how-to tutorial: PLN by hand (http://wiki.opencog.org/w/PLN_by_Hand). 
  After loading up conceptnet4, I tried to run the inheritance rule as 
per the tutorial:


|
(cog-bind deduction-inheritance-rule)
|

Again, I left the computer to run overnight, and by morning it wasn't 
complete. I searched the machine and found the errors in the 
opencog.log file which has grown to 1 GB.  It was filled with a repeat 
of this message (with some other hex-addresses changed):


|
In unknown file:
?: 7 [opencog-extension cog-bind-first-n (# -1)]
In ice-9/boot-9.scm:
  157: 6 [catch #t # ...]
In unknown file:
?: 5 [apply-smob/1 #]
In ice-9/boot-9.scm:
  157: 4 [catch #t # ...]
In unknown file:
?: 3 [apply-smob/1 #]
In opencog.scm:
   89: 2 [cog-undefined-handle]
In ice-9/boot-9.scm:
  102: 1 [#args)> wrong-number-of-args ...]

In unknown file:
?: 0 [apply-smob/1 # wrong-number-of-args ...]

ERROR: In procedure apply-smob/1:
ERROR: Wrong number of arguments to #
ABORT: wrong-number-of-args


|

I have been researching this for a few hours and I was about to give 
up.   I then decided to experiment with smaller numbers of atoms 
(rules).  I used the Guile profiler and it showed that the majority of 
the time was being wasted in error "Catch" and formatting functions. 
After setting debug breakpoints, I decided that the problem was 
actually in this cog-undefined-handle function, and not the 
cog-bind-first-n function, or whatever apply-smob/1 is. (I can't find 
any documentation on apply-smob/1.) The cog-undefined-handle function 
was in /usr/local/share/opencog/scm/opencog.scm:


I changed this line:

|
(define-public (cog-undefined-handle X) '())
|

to

|
(define-public(cog-undefined-handle .X)'())
|

Note: I am not expert in Guile, Scheme, or Lisp. A poster on stack 
exchange said that by inserted the dot character in the argument list, 
it allows a Scheme function to take any number of arguments.  This 
seems to work -- now the opencog.log is clean and the (cog-bind 
deduction-inheritance-rule) runs on the entire data set in only a few 
minutes.

*/
/*
*/3) Hard coded gcc/g++ 4.8 compiler version in octool prevents 
installation on Ubuntu 16.04 LTS/*.  I understand that the base Linux 
configuration for Opencog is still 14.04 LTS.  However, that version 
is already 3 years old and I had just installed a 16.04 LTS image, and 
I did not want to reinstall after investing the time to set it up 
properly.  To get octool to finish the compilation and subsequent 
installation, I 

Re: [opencog-dev] A few bugs while installing a test version of OpenCog

2017-05-29 Thread 'Nil Geisweiller' via opencog
Thanks a lot for your detailed bug report! Ideally you would create 
github issues if each of these, but this is already greatly appreciated.


I'll have a careful look at them, already though regarding the slow down 
due to cog-undefined-handle this is probably because it is getting 
obsolete and I haven't removed it from all PLN rules (doing that now).


Nil

On 05/29/2017 02:50 AM, rocketpwr.com wrote:

Dear OpenCog Development Community,

First, thank you for your hard work on this project.

I found a few bugs that I have been able to work around that you might 
find helpful.  Hopefully the below description of the problems and my 
work-arounds will help you or someone else who comes across the same 
problems.


/*1) Really really long compile times on loading up the conceptnet4.scm 
test dataset in test-datasets/conceptnet/conceptnet4.scm*./  I left it 
to run overnight, and it still had not finished. Actually, I believe it 
was going to take 70+ hours to load and compile this 14.5 MB file.  This 
seemed strange to me as smaller files loaded much faster.  What I 
determined by experiment is that, for some unknown reason, the Guile 
Scheme compiler had a compile time that is proportional approximately 
n^2 of the number of rules.  Here are some results on my test rig (a 4 
core 4 GB Ubuntu 16.04 setup):


|
Rulesloadtime rules/sec

259737.00
6343120.45
10007014.29
124911011.35
|


Because the Conceptnet4.scm file is about 60.5K I estimate that the 
compile time would be around 71 hours or 3 days.  I am guessing this is 
a bug/feature in Guile Scheme which was not really meant as a database.


My work-around:  a) split the 60K rule file into 61 files of 1K rules 
each, and then compile them.  Each file compiles in around 14 seconds, 
reducing the compile time to around 1.5 hours.  Once compiled, the rules 
do not need to be compiled again.  b) I wrote a small loader that loads 
all 61 files into Guile in a single command.


*/2) Really long execution time for (cog-bind 
deduction-inheritance-rule):/* I am experimenting with PLN, using the 
how-to tutorial: PLN by hand (http://wiki.opencog.org/w/PLN_by_Hand). 
  After loading up conceptnet4, I tried to run the inheritance rule as 
per the tutorial:


|
(cog-bind deduction-inheritance-rule)
|

Again, I left the computer to run overnight, and by morning it wasn't 
complete. I searched the machine and found the errors in the opencog.log 
file which has grown to 1 GB.  It was filled with a repeat of this 
message (with some other hex-addresses changed):


|
In unknown file:
?: 7 [opencog-extension cog-bind-first-n (# -1)]
In ice-9/boot-9.scm:
  157: 6 [catch #t # ...]
In unknown file:
?: 5 [apply-smob/1 #]
In ice-9/boot-9.scm:
  157: 4 [catch #t # ...]
In unknown file:
?: 3 [apply-smob/1 #]
In opencog.scm:
   89: 2 [cog-undefined-handle]
In ice-9/boot-9.scm:
  102: 1 [#args)> wrong-number-of-args ...]

In unknown file:
?: 0 [apply-smob/1 # wrong-number-of-args ...]

ERROR: In procedure apply-smob/1:
ERROR: Wrong number of arguments to #
ABORT: wrong-number-of-args


|

I have been researching this for a few hours and I was about to give up. 
  I then decided to experiment with smaller numbers of atoms (rules).  I 
used the Guile profiler and it showed that the majority of the time was 
being wasted in error "Catch" and formatting functions. After setting 
debug breakpoints, I decided that the problem was actually in this 
cog-undefined-handle function, and not the cog-bind-first-n function, or 
whatever apply-smob/1 is. (I can't find any documentation on 
apply-smob/1.) The cog-undefined-handle function was in 
/usr/local/share/opencog/scm/opencog.scm:


I changed this line:

|
(define-public (cog-undefined-handle X) '())
|

to

|
(define-public(cog-undefined-handle .X)'())
|

Note: I am not expert in Guile, Scheme, or Lisp. A poster on stack 
exchange said that by inserted the dot character in the argument list, 
it allows a Scheme function to take any number of arguments.  This seems 
to work -- now the opencog.log is clean and the (cog-bind 
deduction-inheritance-rule) runs on the entire data set in only a few 
minutes.

*/
/*
*/3) Hard coded gcc/g++ 4.8 compiler version in octool prevents 
installation on Ubuntu 16.04 LTS/*.  I understand that the base Linux 
configuration for Opencog is still 14.04 LTS.  However, that version is 
already 3 years old and I had just installed a 16.04 LTS image, and I 
did not want to reinstall after investing the time to set it up 
properly.  To get octool to finish the compilation and subsequent 
installation, I did the following change:


|
$ diff octool octool~
843,844c843
<#CXX=g++-4.8 cmake .. -DCMAKE_BUILD_TYPE=Release