Thanks very much for that information. I will look into seeing what can be done. (I haven't understood that code for handling byte-backward issues for at least 35 years, if I ever did, even though I'm quite sure I wrote it. I hope I'm not too old to relearn it....)
So I guess the accepted way to do these things would be to use union types? And storing under one type and retrieving through the other? Hmmm. If that would work, that would require having an extra memory location for the union variable and the copy. If this would work, and it's worth the trouble, I could look into it.
You found another way file times are tested. OK. I've made changes to the system, as you suggested. Maybe now we've found them all? Thanks for your patience.
I've committed the changes. Alvin, can you try again?
I see I didn't change all the places that file times were checked. I've found and changed more. I will see if it passes the testsuite, and if so, commit the changes. Stay tuned....
Yes, explicit module modifiers override the module associated with the symbol (at least in all places we remembered to add the necessary code :-).
I think I know what is going on. Note that the predicate/functor maplist appears both as maplist/3 as the outer call (as a predicate) and as maplist/1 (as the functor of the first argument to the outer call). Now the definition of maplist probably makes a call of the form call(P,X,Y). Now call/3 uses the module of the first argument to make the predicate symbol for the resulting call. So here the maplist/1 functor is not imported, so it is in usermod, and thuse the maplist/3 call is also to maplist...
Thanks for letting us know. It was in an internal C function, make_ground, which is called by excess_vars, which is called by setof, which is called by predicate_property. It didn't handle the arity=0 case. I've fixed it and will commit it after running the testsuite. Thanks!
That looks like it. (You just gotta know where to look :-). When I get a chance, I'll experiment with defining that macro and see if that fixes the problem as well. Thanks!
That's great, Felix. And thanks again for bringing this to our attention. Too many users would see the results and just give up. It's users like you who help make XSB better (and faster!) Michael, I don't understand enough about operating system architecture and hardware to understand why GCC put this in. I'm assuming there are circumstances in which this initial touching of every page in the activation record is a good idea. Obviously MSVC doesn't do this at all. (Well, I haven't looked, but I think...
OK. I found and have fixed the problem. A few more tests and then I'll commit the changes to sourceforge. I dumped the assembler code that gcc generates for the builtin.c file. I know little about x86_64 assembler code, but it seems that gcc generates code such that on entry to a function, it loops through all the pages for the frame that will contain local variables. For every page, it seems to "or" a 0 to one (double) word in each page. (every 4096 words(?)). The only reason I can think of for...
The problem is that gcc compiles the builtin_call function, which is very large, so that it is very expensive to call. I suspect it has to do with how it allocates (and initializes?) local variables. I will find some time to try to factor it so that components that need significant space will have their own sub-function. I'll let you know what I find.
Well, I got XSB compiled on my ubuntu for windows system. And indeed, when I run that same program, I get: warren@xsb-pc62:/mnt/c/xsb-tests$ xsb [xsb_configuration loaded] [sysinitrc loaded] [xsbbrat loaded] XSB Version 5.0.0 (Green Tea) of May 15, 2022 [x86_64-pc-linux-gnu 64 bits; mode: optimal; engine: slg-wam; scheduling: local] [Build date: 2023-07-15] | ?- [term_set_arg_test]. [Compiling ./term_set_arg_test] [term_set_arg_test compiled, cpu time used: 0.015 seconds] [term_set_arg_test loaded]...
(It looks like an underscore variable got lost in the call to count(childof(,),Cnt), in test in the above code. It was there when I executed the code (otw a syntax error). Sorry if that was confusing.)
Hi Felix, Again, I am stumped. With the following file, compiled: :- import term_arg/3,term_set_arg/4 from machine. :- import for/3 from basics. test(K) :- for(,1,K), count(childof(,_),Cnt), Cnt =\= 16, % check we got right answer writeln(oops), fail. count(Goal,Cnt) :- Term = cnt(_), term_set_arg(Term,1,0,0), (do_all call(Goal), term_arg(Term,1,Cnt0), Cnt1 is Cnt0+1, term_set_arg(Term,1,Cnt1,1) ), term_arg(Term,1,Cnt). childof(a1,a2). childof(a2,a3). childof(a4,a5). childof(a6,a7). childof(a8,a9)....
As discussed, a special hack for count of the number of times a goal succeeds should be more efficient: :- import term_arg/3,term_set_arg/4 from machine. count(Goal,Cnt) :- Term = cnt(_), term_set_arg(Term,1,0,0), (do_all call(Goal), term_arg(Term,1,Cnt0), Cnt1 is Cnt0+1, term_set_arg(Term,1,Cnt1,1) ), term_arg(Term,1,Cnt). This uses term_set_arg with the fourth argument of 1 to not trail the assignment, to keep the value over backtracking. (I'm not sure if these predicates are documented, so I tried...
Hi Felix, We have noticed no particular performance issues with findall in XSB. Our implementation is in C and was contributed by Bart Demoen. I have run your test on my laptop, having instantiated childof to childof(i,i+1) for i=1..16. (I did have to add :- import between/3 from basics.) I get sh-4.4$ xsb [xsb_configuration loaded] [sysinitrc loaded] [xsbbrat loaded] XSB Version 5.0.0 (Green Tea) of May 15, 2022 [x64-pc-windows; mode: optimal; engine: slg-wam; scheduling: local] [Build date: 2022-07-06]...
Hmmm. That is interesting. I'll see what I can find.
Yes, that may be a more likely issue. The C routine is responsible for being sure that there is enough space on the heap to hold whatever it causes to be put there. The way to do this is to determine the amount of heap space needed, and then to call a routine to ensure that that much space is available. To see if this might be a problem, what I'd do is start XSB with a very large heap (which should be large enough to handle any large term constructed on the heap) and see if the problem disappears....
Very interesting. The only thing I can think of, and it's a long shot, is that maybe your C routine is overflowing the C runtime stack. Is your C routine recursively traversing a list? That is dangerous because the C runtime stack is quite small for such things. If that is a possibility, you could either rewrite the code to be iterative, or you could compile XSB with a larger runtime stack. (I don't know the particular option for your C compiler but it should not be hard to find.)
I said "Fritz" when I meant "Felix". Sorry....
Hi Fritz, You motivated me to add inf as a constant float, which will evaluate to the IEEE inf float value when used in expressions, as in X < inf, or in is/2 expressions. I hope this would have avoided the error you encountered when using inf. I've committed it to the XSB repository. I assume you were using a cinterf.c macro or function when the error was thrown. If so, do you happen to know what particular macro/function you were using? My current conjecture on why you got the longjmp error is...
Yes, if you have more information about from where the exception was thrown, that would be helpful. I looked quickly and didn't see anything obvious. But that is to be expected since we throw those errors all the time in XSB and they work fine. You get what your suggest as a runtime XSB error and a forward trace. The largest floating point number in 64-bits is slightly larger than 1.797E308 . XSB doesn't have a "float_max" function, a limitation. You can generate the +inf representation by dividing...
Interesting. I'm glad you found and fixed the problem. Yes, I know that our treatment of floats is more primitive than SWI's. I actually remember seeing that SWI had the inf constant and treated it as floating point infinity, but for some reason never incorporated that into XSB. But you still have uncovered a bug in XSB's handling of exceptions generated in C code. The idea of the error handing is to give you a more informative error message than the one you got:-). I'll take a look at that code...
Hi Felix, As you note, XSB doesn't have builtin routines to pass arrays of basic XSB datatypes back and forth to C, so you must use (as you do) the various p2c_ and c2p_ functions. So that all seems right. As to the longjmp error, I'm not an expert in longjmp, but I would first try to locate the particular longjmp call that generates the error. By grepping through the emu directory .[ch] for longjmp, I find there are the following occurrences in XSB: biassert.c: longjmp(assertcmp_env, num); cinterf.c:...
Hi Christophe, The way an aggregate predicate is processed when it is called with a non-variable in the aggregated position is to abstract that to a variable, then call the aggregate predicate and then see if the result is what is passed it. So your | ?- testPO(f(1,1),foo). is treated as though it were written as: | ?- testPO(X,foo), X = f(1,1). To see why it essentially has to do this, think of an aggregate like sum. To see if the sum of some set of numbers is, say, k, one has to add them up and...
Hi Tuncay, Thanks for the fix. It breaks the windows compile, since it seems windows has strdup as a macro. I tried compiling on linux, but couldn't figure out how to compile it. The makefile in sgml package doesn't seem to work for me. So, anyway, I've conditioned your change using our DARWIN flag (the flag for MACOS). Thanks!
Declared decode_index/2 exported in curr_sym and commented back in an index decl in file_op.H (and commiting consult.xwam that seemed out of sync).
Fixed some uses of incorrect defined constants: tag instead of token constants. (Note didn't change .xwam).
Removed obsolete FactFlg in load_dync. Also put all constants in usermod in load_dyn(c) (even if standard_symbols).
Removed obsolete FactFlg in load_dync. Also put all constants in usermod in load_dyn(c) (even if standard_symbols).
Fixed some uses of incorrect defined constants: tag instead of token constants. (Note didn't change .xwam).
Declared decode_index/2 exported in curr_sym and commented back in an index decl in file_op.H (and commiting consult.xwam that seemed out of sync).
Removed a spurious (I hope) globalize of (/)/2 in lattice transformation processing.
Removed a spurious (I hope) globalize of (/)/2 in lattice transformation processing.
Fixed to use defined constants from C rather than integers.
Fix len in strncpy to be correct. (Avoids warning)
Set env type of mod for dynamically loaded explicitly named modules. Allows better handling of errors.
Fixed bug in load_dyn(c) in setting module type (sim to previous bug/fix)
Made variant tabling take advantage of previously interned terms.
Fixed bug in modules when loading a module with load_dyn(c)
Fixed bug in modules when loading a module with load_dyn(c)
Made variant tabling take advantage of previously interned terms.
Fixed to use defined constants from C rather than integers.
Fix len in strncpy to be correct. (Avoids warning)
Fixed bug in load_dyn(c) in setting module type (sim to previous bug/fix)
Set env type of mod for dynamically loaded explicitly named modules. Allows better handling of errors.
Fix of bug in *fmt_write handling the %! format spec
Slight generalization of incr_memset. (But didn't find another place to apply it...)
Improved fix of delete_return edge case bug in resetting the ALN ptr when necessary. Also added documentation on these tagged ALN ptrs.
Changed memset of very long chunk buffer to be incremental and stop sooner. Was put in for obscure gc bug we dont have a test for, so it is hard to test.
Fix obscure bug in delete_return in handling the combination of defined and undefined answers.
Very minor fix in handling big arities for interned structures.
Fix bug in checking internstr when arity > 255.
Minor efficiency improvement with tag checking.
Explicit initialization of no max memory set.
Fix bug in intersect_db (in rtl_intersect/3) and add comments.
Fixed buglet in update_views/4.
Eliminated recursion in xsb_eval (evaluating expressions is/2) by using an explicit stack. Now no bound on expression depth.
Fix a minor with add_to_db. Docs.
Restore Makefile which was inadvertantly changed.
changed xwams due to addition of bldkavars intstruction.
Add compiler optimization to combine consecutive bldavar insts to new bldkavars.
Add new instruction bldkavars (similar to unikavars) for efficiency. Will shortly commit compiler and .xwam changes.
Fix read error when operator is followed by a semicolon, so should be read as atom.
Took off the 'privatizer' for byte-code filenames for all (I hope) messages.
Rename private xwam if command throws an error on load; add a cut to a first efficiency clause in subsumes/2.
Init c to NULL to be sure always defined.
Fix to answer subsumption transformation to support attributed variables.