search

opencog / atomspace

The OpenCog (hyper-)graph database and graph rewriting system
https://wiki.opencog.org/w/AtomSpace
Other
819 stars 232 forks source link

Fix the Scheme integration to preserve source file names and line numbering #2318

Closed ferrouswheel closed 5 years ago

ferrouswheel commented 5 years ago

Lately I've been very frustrated by Scheme stack traces with references to "unknown file" without any line reference.

Either Scheme is an unproductive language for doing serious development in, or our bindings are done in a weird way that doesn't preserve line information and this should be fixed.

If the former, I guess this issue can be closed, but developers should probably be warned of the limitations.

I guess it's also possible that people are using the bindings wrong, but I keep seeing In unknown file: in different environments and projects (and I think I recall seeing these in output of the atomspace tests too), so if they are being used wrong it's a common pattern and documenting how to avoid this would be beneficial.

(or maybe the docs to avoid this already exist somewhere?)

linas commented 5 years ago

Without some kind of specific examples, I don't know how to respond. You can take the issue up on the guile-user mailing list.

Warning users of "language limitations" and how "unproductive" they are is absurd. What are we gonna write? "Scheme is the shittiest programming language ever, except for python, which, hard to believe, is even worse. And C++ sucks rocks, so don't even try to use that."

All programming languages are application-specific; Java is server-generic, but otherwise verbose, inflexible, overweight, intolerable. Javascript is marvelous for small GUI projects but bogs down for number-crunching. Serious javascript people seem to think that Rust is good. I dunno. Python is the Visual Basic of the 21st century, and everything that comes with that mentality: putrid heaps of badly-designed code written by teen-aged fanbois. Haskell is ... well, there are interesting theoretical reasons to like it, but I don't see that it offers anything useful for opencog. It seems like R has a decent userbase, and, from what I can tell, it seems to have wonderful language bindings; the people who created that really really understood data, and how data gets used. But R, the language itself, meh. I dunno, I was not impressed, but maybe it's reasonable to have R bindings simply because of their raw power and usability.

If you look at data representation systems, or anything with internal languages, scheme/lisp dialects always dominate, for obvious reasons. Insofar as the atomspace is effectively a graph database language, scheme is an obvious choice -- (compare to opencog's python bindings -- you wrote those yourself -- it's like a poster-child for just how fucked up python is for data representation. Friends don't let friends program in python.)

I dunno; I don't see any plausible alternatives.

ferrouswheel commented 5 years ago

As an example, here is the stack trace I'm trying to decipher.

Server listening on 0.0.0.0:7032
WARNING: (opencog nlp): `get-line' imported from both (ice-9 textual-ports) and (rnrs io ports)
WARNING: (virtual-assistant virtual-assistant): `run-server' imported from both (system repl server) and (web server)
In ice-9/boot-9.scm:
    705:2 11 (call-with-prompt _ _ #<procedure 5589a14502a0 at ice-9…>)
    705:2 10 (call-with-prompt _ _ #<procedure 5589a147af20 at ice-9…>)
In ice-9/eval.scm:
    619:8  9 (_ #(#(#<directory (virtual-assistant virtual-assis…> …)))
    619:8  8 (_ #(#(#<directory (virtual-assistant virtual-assis…>) …))
    619:8  7 (_ #(#(#<directory (virtual-assistant virtual-assis…>) …))
In srfi/srfi-1.scm:
    640:9  6 (for-each #<procedure 5589a12cf820 at ice-9/eval.scm:3…> …)
    640:9  5 (for-each #<procedure 5589a2129e20 at ice-9/eval.scm:3…> …)
In ice-9/eval.scm:
   293:34  4 (_ #(#(#<directory (virtual-assistant virtual-assis…>) …))
    619:8  3 (_ #(#(#(#<directory (conceptnet) 5589a1745640>) # …) …))
   626:19  2 (_ #(#(#(#<directory (conceptnet) 5589a1745640>) # …) …))
    155:9  1 (_ #(#(#(#<directory (conceptnet) 5589a1745640>) "…") #))
In unknown file:
           0 (utf8->string "Internal Server Error")
ERROR: In procedure utf8->string:
In procedure utf8->string: Wrong type argument in position 1 (expecting bytevector): "Internal Server Error"

The issue is that I have no idea where the line (utf8->string "Internal Server Error") is coming from, so can't try to address the issue. I've grepped every repo that could be related for this line with no success.

The other parts of this trace are Scheme internals.

I didn't write this, but I don't think one should have to be the original author to be able to find the line of code that is raising an error.

Like my original issue said, maybe this isn't Scheme specific, maybe it's just how the bindings work or how people use Scheme and the atomspace bindings together.

Whatever the cause, it's still infuriating and I think there should be clear guidance to help people not implement downstream projects in this way.

linas commented 5 years ago

This appears to be a normal, everyday, ordinary systems debugging problem. The stack trace says "virtual-assistant" and "conceptnet"; and 500 "Internal Server Error" is a standard HTTP response code (just like 404 "Not Found"; the 500 series errors are all HTTP server errors).

Now, opencog does not employ conceptnet in any repo that I am aware of; there are no opencog bindings in that stack trace, so I can't tell why you decided to blame opencog. A naive guess would be that someone somewhere wrote some conceptnet code in scheme, and somehow you loaded something that runs it. That conceptnet code appears to be trying to contact some web server somewhere that appears to be misconfigured, and is spewing server errors.

Reading the error more closely, it does seem odd that there is a byte string was passed when a UTF8 string was expected. For that, there are two hints at the top:

`get-line' imported from both (ice-9 textual-ports) and (rnrs io ports)
`run-server' imported from both (system repl server) and (web server)

I would not be surprised if rnrs (a standards-compatibility layer) is not UTF-8 enabled, and that is the likely distal cause of the error. The second warning is troubling too: the repl server (repl == read, evaluate, print loop) is just a simple telnet server that opens a socket and listens for telnet connections: you telnet into it, and it just runs whatever guile commands are typed in. (so, its like the cogserver, but simpler) Appearenty, the webserver also has a run-server command in it, and so now its confusing as to which server is supposed to be started. Whoever wrote the conceptnet code did not disambiguate which "server" is supposed to be run, and, equally badly, did not disambiguate how to read a line of text (presumably from the network socket)

My conclusion would be not to blame either opencog, nor guile, but to blame the conceptnet people for failing to disambiguate "run-server" and "get-line".

Given these two hints as to where the error might be, standard debugging procedure would be insert printf's until you can narrow down the problem -- in this case, somewhere within conceptnet, someone is doing some kind of access to some kind of webserver somewhere, and then blowing it with ASCII-vs-UTF8 strings.

linas commented 5 years ago

... Or maybe this: the conceptnet code tried to start the repl server, and accidentally started a webserver instead; it makes sense that the webserver now instantly spews "500 internal server error", because it was never configured. Track down the callers of run-server and get-line, and try to see what it was trying to do.