"This is a known bug/feature .. err. known to us. My standard solution is to disable compiling for these kinds of files. So: use primitive-load, instead of load. https://www.gnu.org/software/guile/manual/html_node/Loading.html <https://www.google.com/url?q=https%3A%2F%2Fwww.gnu.org%2Fsoftware%2Fguile%2Fmanual%2Fhtml_node%2FLoading.html&sa=D&sntz=1&usg=AFQjCNFRCuy7QvmsS4f40w4Dxe6R1WqcHw> Its much much easier than splitting the file into chunks. In the meanwhile, I should ask you to complain to the guile folks that it takes too long to compile large files. I think they're sick of hearing it from me :-)"
Hi Linas, Thank you and Nils for being so responsive. It's like having Linux Torvalds, Greg Kroah-Hartmann or Alan Cox help a newbee. I agree with your work-around. With respect to Guile, I think the problem is that Guile is not a popular enough Scheme implementation (combined with the fact that Scheme is not a popular enough language) to have a large core community working to fix performance problems. If it was Python, this compile time issue would repaired without us having to ask. In this situation, it would more than likely be up to us to spend 4 weeks learning enough about Guile to correct it. I'd rather learn about OpenCog. Thanks for looking at the problem. I surely will uncover new performance issues later-on that you have worked around, plus I am just learning PLN + Atomspace and I might need some help. I appreciate your time. Best, Mike On Saturday, June 3, 2017 at 4:10:22 PM UTC-4, linas wrote: > > Hi, > > On Sun, May 28, 2017 at 6:50 PM, rocketpwr.com <[email protected] > <javascript:>> wrote: > >> >> >> *1) Really really long compile times on loading up the conceptnet4.scm >> test dataset in test-datasets/conceptnet/conceptnet4.scm.* >> > > This is a known bug/feature .. err. known to us. My standard solution is > to disable compiling for these kinds of files. So: use primitive-load, > instead of load. > https://www.gnu.org/software/guile/manual/html_node/Loading.html > > Its much much easier than splitting the file into chunks. > > In the meanwhile, I should ask you to complain to the guile folks that it > takes too long to compile large files. I think they're sick of hearing it > from me :-) > > >> ERROR: Wrong number of arguments to #<procedure cog-undefined-handle (X)> >> ABORT: wrong-number-of-args-number-of-args ...] >> >> ERROR: In procedure apply-smob/1 >> > > There is no such thing as "cog-undefined-handle". Its totally bogus. > Wherever it is, it should be removed. Its some left-over mistake ... > > I changed this line: > > (define-public (cog-undefined-handle X) '()) > > to > > (define-public (cog-undefined-handle . X) '()) > > > Yeah, I guess that's maybe OK, but it's even better to just let it throw > the error. That tells the user that thier code is broken, and that they > should fix their code. > > *3) Hard coded gcc/g++ 4.8 compiler version in octool prevents > installation on Ubuntu 16.04 LTS*. > > That's a bug should be fixed. Beats me why it's hard-coded. > > --linas > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/0d044fb5-1675-4368-b2ce-d29eb2587a91%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
