I’m using the foreign language interface. It seems that the engine segfaults when entering the interactive debugger (in my case, calling pyswip’s Prolog.assertz("a23123 s 1/0") ). It does this in when run within IntelliJ’s PyCharm IDE. The problem goes away when I ask PyCharm to “emulate terminal in output console”.
I don’t really need the interactive debugger. I thought I could disable it with “–tty=false” or “–no-tty” to the PL_initialize call. These make no difference. Should I expect that these options would disable the debugger?
It shouldn’t enter the debugger on exceptions as long as you catch them (provided the Python interface passes on the Prolog exception). In some cases the debug_on_error flag could help, but it was more relevant in the days the system didn’t have exception handling .
Python does can catch and pass on the prolog exception. The debugger is entered before the Python receives it.
I guess its more of a compiler/syntax error.
Executing (via pyswip) Prolog.query(mod1:(assertz((a23123 s 1/0))).` enters a prompt:
Call: (1) pyrun("mod1:(assertz((a23123 s 1/0))).", _2798) ?
and typing h
Options:
+: spy -: no spy
/c|e|r|f|u|a goal: find .: repeat find
a: abort A: alternatives
b: break c (ret, space): creep
[depth] d: depth e: exit
f: fail [ndepth] g: goals (backtrace)
h (?): help i: ignore
l: leap L: listing
n: no debug p: print
r: retry s: skip
u: up w: write
m: exception details
C: toggle show context
… is managed by libswi.
FYI. I’m a little tied the foreign interface since I need some matrix-heavy computation to be performed interactively as a foreign predicate (I understand its possible to link swipl against a foreign .so – however, driving from another language provides us a lot more flexibility).
This probably means that the python wrapper around Prolog doesn’t tell Prolog it is willing to handle exceptions (see PL_open_query() flags). If Prolog finds itself in the situation where it has an open exception and nobody willing to handle it, it will by default start the debugger.
.