Activity for Felix Weitkämper
-
Felix Weitkämper committed [42002a] on XSB - Sources (GIT)
Further portability fixes to mcintyre.pl in the PITA package
-
More work with Mcintyre unearthed the following additional issue: The predicates save_..., which are supposed to copy "sampled" facts into a new predicate "mem" and then retract the "sampled" facts, are currently implemented using the schema save_samples(M,G):- sampled(R,Sub,V), assert(M:mem(G,R,Sub,V)), retract(sampled(R,Sub,V)), fail. save_samples(_M,_G). In SWI-Prolog, the failure-driven loop executes correctly, but XSB doesn't seem to take well to backtracking over a partially retracted predicate...
-
You were absolutely right! The "fake import" did fix the issue. What I have now done is just put explicit module qualifications on any predicate call within a maplist, and that also solved the problem.
-
You were absolutely right! The "fake import" did fix the issue. What I have now done is just put explicit module qualifications on any function call within a maplist, and that also solved the problem.
-
Porting functional-style code from SWI Prolog
-
Both compiling and predicate_property/2 work again beautifully, thank you both!
-
Thank you very much for the quick fix! Unfortunately, the current snapshot doesn't compile for me as the configure script terminates with the error config.status: error: cannot find input file: /home/weitkaemper/XSB/XSB/packages/janus/configvars.in before creating makexsb. The snapshot after David Warren's last commit (cf 6005) compiles perfectly well.
-
Thank you very much for the quick fix! Unfortunately, the current snapshot doesn't compile for me as the configure script terminates with the error config.status: error: cannot find input file: /home/weitkaemper/XSB/XSB/packages/janus/configvars.in' before creating makexsb. The snapshot after David Warren's last commit (cf 6005) compiles perfectly well.
-
predicate_property/2
-
Thank you! In this case, at the only place where we actually use the asserta/2 and erase/1 combination, we are actually asserting two (impure) proxy clauses for a goal, where order does matter. I don't think this is a bottleneck though, so it shouldn't have any serious performance impact there.
-
Missing predicates in Mcintyre
-
I believe it may have to do with gcc's stack checking, which is basically what you desribed above: https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html I have already deleted my pre-fix XSB sources, but I wonder whether setting the appropriate macros could also have helped with the issue?
-
I believe it may have to do with gcc's stack checking, which is basically what you desribed above: https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html I have already uninstalled my pre-fix XSB version, but I wonder whether setting the appropriate macros could also have helped with the issue?
-
Fantastic work, thank you so much! Now, using the set_arg hack, XSB actually outperforms YAP and SWI-Prolog's set_arg versions on the counting benchmark by 15% on my setup, which is very gratifying. The performance benefit of using XSB rather than YAP on my actual application is even greater (30%, probably due to superior tabling performance). For an algorithm that runs in approximately linear time in data size, this makes a substantial difference! This fix also makes XSB and hence Janus usable for...
-
Would it help if one/I tried compiling it with clang instead of gcc to see whether the issue persists?
-
Well, I am very grateful at least that it has been possible to reproduce the phenomenon, and confirm that it is indeed occasioned by the choice of operating system.
-
Very strange! My students and I on our various systems (all Linux though) have the same experience, despite using the current XSB versions compiled from source. I will do some more experiments as soon as I get to it, but since I will be attending the ICLP in London next week, it might be a little while.
-
Performance of the list comprehension predicates
-
Having attempted to find a minimum example, I have realised that in fact the C function itself is immaterial to the error. For instance, I get exactly the same behaviour with the file test.c: #include <cinterf.h> void test(){} and header file test.h :- foreign_pred ptest() from test():void. which leads to exactly the same behaviour: | ?- [test]. [Compiling Foreign Module ./test] [test compiled, cpu time used: 0.004 seconds] [Compiling C file ./test.c using gcc] gcc -s -o ./test.so -shared ./test.c...
-
My original suspicion was that it has something to do with my clumsy use of prolog_terms, since I don't understand sufficiently how memory allocation works for those. For instance, I am effectively doing this at some point: prolog_term NewList = p2p_new(); p2p_unify(NewList,OldList); To me, this seems to be conjuring stack space for an arbitrarily long list out of nowhere, since I only reserved memory for a variable. And they are not just pointers, as far as I understood, since I think I can now...
-
My original suspicion was that it has something to do with my clumsy use of prolog_terms, since I don't understand sufficiently how memory allocation works for those. For instance, I am effectively doing this at some point: prolog_term NewList = p2p_new(); p2p_unify(NewList,OldList); To me, this seems to be conjuring stack space for an arbitrarily long list out of nowhere, since I only reserved memory for a variable. And they are not just pointers, as far as I understood, since I think I can now...
-
Thank you so much for committing this extra feature! Regarding pinning down the issue, loading the foreign module is insufficient to provoke the crash dump, but a single execution of the foreign language routine suffices. See below for the console output, where matrix_popt.H is the FLI header and the last line is just the German expression for crash dump. [xsb_configuration loaded, cpu time used: 0.001 seconds] [sysinitrc loaded] [xsbbrat loaded] XSB Version 5.0.0 (Green Tea) of May 15, 2022 [x86_64-pc-linux-gnu...
-
Thank you so much for committing this extra feature! Regarding pinning down the issue, loading the foreign module was insufficient to provoke the crash dump, but a single execution of the foreign language routine suffices. See below for the console output, where matrix_popt.H is the FLI header and the last line is just the German expression for crash dump. [xsb_configuration loaded, cpu time used: 0.001 seconds] [sysinitrc loaded] [xsbbrat loaded] XSB Version 5.0.0 (Green Tea) of May 15, 2022 [x86_64-pc-linux-gnu...
-
Thanks again! I assume what I should have gotten is the usual Error[XSB/Runtime/P]: [Type (inf in place of evaluable)] Wrong type in evaluable function compare-operator/2: (Goal: compare-operator(5.0,inf)) from a well-behaved longjmp, as I would when running ?- 5.0 < inf on command line. I will see if I can pin down the conditions any better from my end, if that would be helpful. Of course, I am very happy to have located the issue. My main motivation for the port is the more sophisticated and stable...
-
I have found the mistake in my code, and fixed it. In fact, it had nothing to do at all with my foreign language code, and everything with the "innocuous list recursion" I mentioned in my first post. The issue is that in SWI-Prolog, I can use "inf" to notate infinity, which occurs in the base case of a list minimum. On my XSB setup, comparing against "inf" seems to cause the illegal longjmp error.
-
I have found the mistake in my code, and fixed it. In fact, it had nothing to do at all with my foreign language code, and everything with the "innocuous list recursion" I mentioned in my first post. The issue is that in SWI-Prolog, I can use "inf" to notate the largest floating-point number, which occurs in the base case of a list minimum. On my XSB setup, comparing against "inf" seems to cause the illegal longjmp error.
-
Dear David, Thank you so much for the hints! I am on Ubuntu 20.04 and have compiled from source, so recompiling is no problem at all. I was so hung up on trying to find a root cause in my foreign language code that it somehow never occurred to me simply to take the message at face value. To my great surprise, the procedure you suggested showed that the only one of these 6 longjmps that is evoked is in the function xsb_throw_internal from error_xsb.c
-
longjmp error
-
Numerical lists in the C-Interface
1