Ignore undefined facts in SWI Prolog - prolog

I'm running queries against a generated set of facts, and some facts may not exist. When that happens, SWI Prolog errors out with e.g. Undefined procedure: 'LongIdent'/4. Is there a way to get it to instead simply have the goal involving 'LongIdent'/4 fail?

Well you could change the default behavior using unknown/2 which is declared as unknown(-Old, +New), Old is the old-current flag, New is the new flag that you use:
?- unknown(trace,fail).
Warning: Using a non-error value for unknown in the global module
Warning: causes most of the development environment to stop working.
Warning: Please use :- dynamic or limit usage of unknown to a module.
Warning: See http://www.swi-prolog.org/howto/database.html
true.
?- a(1).
false.
But you see the warnings explaining that this may not be a good idea...
If you don't know the current/old flag you could use it like:
?- unknown(X,fail).
Warning: Using a non-error value for unknown in the global module
Warning: causes most of the development environment to stop working.
Warning: Please use :- dynamic or limit usage of unknown to a module.
Warning: See http://www.swi-prolog.org/howto/database.html
X = trace.

Related

Mercury "undefined reference" compilation error when using local module

I have a module exporting nat/1 to test/generate natural numbers:
:- module nat.
:- interface.
:- import_module int.
:- pred nat(int).
:- mode nat(in) is det.
:- mode nat(out) is multi.
:- implementation.
:- pragma promise_pure(nat/1).
nat(_::in).
nat(0::out).
nat(X::out) :- nat(Y), X = Y + 1.
and a main module in the same directory to try it out:
:- module main.
:- interface.
:- import_module io.
:- pred main(io__state::di, io__state::uo) is cc_multi.
:- implementation.
:- import_module nat.
main(!IO) :- nat(X), print(X, !IO).
I run mmc --make-int nat.m which successfully generates the interface files, but then when I run mmc main.m I get the following error:
/usr/bin/ld: main.o: in function `<predicate 'main'/2 mode 0>':
main.c:(.text+0x45): undefined reference to `<predicate 'nat.nat'/1 mode 1>'
collect2: error: ld returned 1 exit status
I'm using MMC version 20.06.1, on x86_64-pc-linux-gnu.
Am I missing something obvious? Code improvements are also very welcome.
After "mmc --make-int nat.m", the command you need to run is not "mmc main.m",
but "mmc main.m nat.m". The former compiles only main.m, while the latter also compiles nat.m. Both attempt to build an executable from the resulting
object files, but the former will fail, since the definition of the "nat" predicate would be in the object file it does not generate.
In general, instead of trying to manage the creation of interface files, object files and executables manually, it is much easier to use an automated
build system: either the mmake script, or mmc --make.
As for code improvements, I would suggest replacing io__state with just plain io, which is a lot shorter. We added "io" as a synonym for the "state"
type in io.m specifically to make this possible.

Vagrant outputs loads of Ruby warnings

vagrant outputs warnings like these:
NOTE: Gem::Specification.default_specifications_dir is deprecated; use Gem.default_specifications_dir instead. It will be removed on or after 2020-02-01.
Gem::Specification.default_specifications_dir called from /usr/share/rubygems-integration/all/gems/vagrant-2.2.6/lib/vagrant/bundler.rb:428.
NOTE: Gem::Specification.default_specifications_dir is deprecated; use Gem.default_specifications_dir instead. It will be removed on or after 2020-02-01.
Gem::Specification.default_specifications_dir called from /usr/share/rubygems-integration/all/gems/vagrant-2.2.6/lib/vagrant/bundler.rb:428.
/usr/share/rubygems-integration/all/gems/vagrant-2.2.6/plugins/kernel_v2/config/vm.rb:354: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call
/usr/share/rubygems-integration/all/gems/vagrant-2.2.6/plugins/kernel_v2/config/vm_provisioner.rb:92: warning: The called method `add_config' is defined here
/usr/share/rubygems-integration/all/gems/vagrant-2.2.6/lib/vagrant/errors.rb:103: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call
/usr/share/rubygems-integration/all/gems/i18n-1.8.2/lib/i18n.rb:195: warning: The called method `t' is defined here
/usr/share/rubygems-integration/all/gems/vagrant-2.2.6/lib/vagrant/ui.rb:171: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call
/usr/share/rubygems-integration/all/gems/vagrant-2.2.6/lib/vagrant/ui.rb:223: warning: The called method `say' is defined here
They seem to be internal vagrant warnings and not about my use of vagrant.
The amount of warnings is around 10x the output of vagrant itself. This makes it harder to see the output from vagrant.
Is there a way I can get rid of those?
I removed ubuntu repo version (2.2.6) and using latest vagrant version (i.e. 2.2.9) solved the issue

Xcode watch 'invalid expression'

I'm stepping through some Swift code in Xcode and I'd like to watch values. Following the advice in many of the answers here (e.g. this one) I can add the expression to the local variables window.
The breakpoint I am on is the last line of this fragment from the Starscream library (by daltoniam) which I include as a pod.
for i in 0..<dataLength {
buffer[offset] = data[i] ^ maskKey[i % MemoryLayout<UInt32>.size]
offset += 1
}
var total = 0
I've added two expressions to watch:
buffer[0] and
MemoryLayout<UInt32>.size
For both the value I see is "invalid expression":
These expressions are clearly are not invalid, if they were the code would have thrown an exception when they were encountered executing the previous few lines. What am I missing? How should I watch and not get 'invalid expression'
N.B. If I call p buffer[0] from the lldb prompt I get the cryptic error:
(lldb) p buffer[0]
error: warning: :12:9: warning: initialization of variable
'$__lldb_error_result' was never used; consider replacing with assignment to '_'
or removing it
var $__lldb_error_result = __lldb_tmp_error
~~~~^~~~~~~~~~~~~~~~~~~~
_
error: :19:5: error: value of type 'WebSocket' has no member
'$__lldb_wrapped_expr_72'
$__lldb_injected_self.$__lldb_wrapped_expr_72(
^~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~
I have tried changing the podfile (as per Jim's answer) so that it explicitly gets the debug code:
pod 'Starscream', '~> 3.0.6', :configuration => 'Debug'
and I have even gone as far as removing the pods, cloning Starscream, and including the source code as a sub-project. I still get the same error.
An expression that accesses buffer[0] where buffer is a UnsafeMutablePointer works correctly in the expression parser when I'm stopped in some simple function. And from your experience with the expr command directly, it looks like your problem is not with this particular expression. Rather it looks like there's something about the context you are stopped in that's tripping up the expression parser altogether.
Make sure that you aren't using binary cocoapods's and that you've rebuilt all your code and all the pods you are using have been rebuilt from scratch with the same swift compiler. At present, lldb and swiftc are version locked - lldb can only debug programs built with the swiftc that it ships with.
If that doesn't fix the issue, then we'll need to figure out what about the particular function you are stopped in that's causing the problem. This seems like the sort of thing better dealt with by filing a bug with the swift project (http://bugs.swift.org).

How to run an aleph program with Swi-prolog?

I’m trying to work Aleph with Swi-prolog. Are there any one could please tell me how to run this program if I have a file named train.pl (including the background and positive and negative examples.) What can I do to induce my program and get the output? By the way, I have already downloaded Aleph.pl for my program. When I ran it, it showed like this:
ERROR: c:/users/mac/downloads/aleph.pl:97:
Wrong context: arithmetic_function/1 can only be used in a directive
I also had similar problems. However, after some googling, I found a github repository which contains the aleph script that actually works (prolog/aleph.pl). However, the manual could be more detailed (at least for a newbie like me). A minimal working example that I have managed to run is the trains example (prolog/examples/train.pl) and I did the following:
Put the aleph.pl script into some directory path/to/dir
Put the train.pl script into the same directory.
Executing the following commands, one by one:
working_directory(_, 'path/to/dir').
consult('aleph.pl').
consult('trains.pl').
induce.
I ignored some errors and warnings that have appeared when executing the command consult('trains.pl').:
ERROR: path/to/dir/train.pl:16:
ERROR: source_sink `library(aleph)' does not exist
Warning: path/to/dir/train.pl:16:
Warning: Goal (directive) failed: user:use_module(library(aleph))

SWI-Prolog: No permission to load source when "Non-module file" already loaded into some module)

This error may be a duplicate of
SWI Prolog ensure_loaded error
Since that question is not fully answered, I decide to post mine here.
There are some dynamic loaded files using <name>:compile(Filename) clause, which I suspect could be a reason for the error.
➜ chill git:(master) ✗ swipl --traditional [18/06/20| 8:54AM]
Welcome to SWI-Prolog (threaded, 64 bits, version 7.6.4)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
Please run ?- license. for legal details.
For online help and background, visit http://www.swi-prolog.org
For built-in help, use ?- help(Topic). or ?- apropos(Word).
?- expects_dialect(sicstus).
true.
?- consult('chill-test.pl').
true.
?- set_prolog_flag(double_quotes, chars).
true.
?- run_trials('orig-db', 'raw250-split1.pl', 'orig-db-evaluate', 25, 200, 'raw250-res1.out').
Reading Split File: raw250-split1.pl
Specializing with 25 top-level examples
Beginning Example Analysis
Attempting Example 1 ....
<omitted output>
BEGINING INDUCTION: 1 5
ERROR: No permission to load source `'/home/vimos/git/SP/mooney/chill/orig-db.i'' (Non-module file already loaded into module test; trying to load into thetheory)
ERROR: In:
ERROR: [36] throw(error(permission_error(load,source,'/home/vimos/git/SP/mooney/chill/orig-db.i'),context(...,'Non-module file already loaded into module test; trying to load into thetheory')))
ERROR: [34] '$assert_load_context_module'('/home/vimos/git/SP/mooney/chill/orig-db.i',thetheory,[expand(false),...]) at /usr/lib/swi-prolog/boot/init.pl:2439
ERROR: [33] '$mt_do_load'(<clause>(0x559a46329ea0),'orig-db.i','/home/vimos/git/SP/mooney/chill/orig-db.i',thetheory,[expand(false),...]) at /usr/lib/swi-prolog/boot/init.pl:2069
ERROR: [32] setup_call_catcher_cleanup(system:with_mutex('$load_file',...),system:'$mt_do_load'(<clause>(0x559a46329ea0),'orig-db.i','/home/vimos/git/SP/mooney/chill/orig-db.i',thetheory,...),_142002,system:'$mt_end_load'(<clause>(0x559a46329ea0))) at /usr/lib/swi-prolog/boot/init.pl:443
ERROR: [21] make_theory('orig-db.i',op/2,_142072) at /home/vimos/git/SP/mooney/chill/spchillin-nr.pl:966
ERROR: [20] top_induction('orig-db.i',[op(...,_142120)],[op(...,_142132),...|...],_142108) at /home/vimos/git/SP/mooney/chill/spchillin-nr.pl:129
ERROR: [19] chill_lib:cpu_time(user:top_induction('orig-db.i',...,...,_142186),_142170) at /home/vimos/git/SP/mooney/chill/chill_lib.pl:136
ERROR: [18] induce_control_definition('orig-db.i',[op(...,_142230)],[op(...,_142242),...|...],_142216,_142218) at /home/vimos/git/SP/mooney/chill/chill.pl:109
ERROR: [17] add_each_optimization(cxit([...|...]),'orig-db.i',fail,[(... :- ...),...],[],_142282,_142284) at /home/vimos/git/SP/mooney/chill/chill.pl:85
ERROR: [14] add_rules_for_targets([tr(...,function,fail)],'orig-db.i',[... - ...,...|...],[],[],_142346,_142348) at /home/vimos/git/SP/mooney/chill/chill.pl:79
ERROR: [12] chill_lib:cpu_time(user:create_optimized_rules(...,'orig-db.i',_142426,_142428),_142412) at /home/vimos/git/SP/mooney/chill/chill_lib.pl:136
ERROR: [11] chill_specialize('orig-db','<garbage_collected>','orig-db.i','orig-db-opt.pl') at /home/vimos/git/SP/mooney/chill/chill.pl:11
ERROR: [9] run_trials_loop(25,'orig-db',225,200,[[...],...|...],[ti(...,...,...),...|...],'raw250-res1.out') at /home/vimos/git/SP/mooney/chill/chill-test.pl:188
ERROR: [7] <user>
ERROR:
ERROR: Note: some frames are missing due to last-call optimization.
ERROR: Re-run your program in debug mode (:- debug.) to get more detail.
^ Exception: (32) setup_call_catcher_cleanup(system:with_mutex('$load_file', '$mt_start_load'('/home/vimos/git/SP/mooney/chill/orig-db.i', <clause>(0x559a46329ea0), [expand(false), expand(true)])), system:'$mt_do_load'(<clause>(0x559a46329ea0), 'orig-db.i', '/home/vimos/git/SP/mooney/chill/orig-db.i', thetheory, [expand(false), expand(true)]), _142584, system:'$mt_end_load'(<clause>(0x559a46329ea0))) ? creep
^ Call: (34) call(system:'$mt_end_load'(<clause>(0x559a46329ea0))) ? creep
^ Exit: (34) call(system:'$mt_end_load'(<clause>(0x559a46329ea0))) ? creep
There are two dynamic compiled modules test and thetheory. They are both compiled from the same file orig-db.i.
If I force one of them to read from a different file like orig-db.ii, the error will be different.
I tried the same code with yap, it didn't complain with this error.
➜ chill git:(master) ✗ yap [18/06/20| 9:21AM]
% Restoring file /usr/lib/Yap/startup.yss
YAP 6.2.2 (x86_64-linux): Sat Sep 17 13:59:03 UTC 2016
?- consult('chill-test.pl').
yes
?- run_trials('orig-db', 'raw250-split1.pl', 'orig-db-evaluate', 25, 200, 'raw250-res1.out').
<omitted output>
BEGINING INDUCTION: 1 5
% reconsulting /home/vimos/git/SP/mooney/chill/orig-db.i...
% reconsulted /home/vimos/git/SP/mooney/chill/orig-db.i in module thetheory, 0 msec 1344 bytes
Induction Time: 0.00
op(ps([traverse(pvar(1),freevar):[],const(pvar(1),riverid(mississippi)):[mississippi],answer(pvar(0),state(pvar(0))):[which,through]],[run,?]),G9) :-
db_lib:coref_vars(traverse,2,2,answer,2,1,ps([traverse(pvar(1),freevar):[],const(pvar(1),riverid(mississippi)):[mississippi],answer(pvar(0),state(pvar(0))):[which,through]],[run,?]),G9).
op(A,B) :-
introduce(density(_,_),[density],A,B).
op(A,B) :-
db_lib:coref_vars(density,2,1,state,1,1,A,B).
op(A,B) :-
db_lib:coref_vars(density,2,2,smallest,2,1,A,B).
op(A,B) :-
db_lib:lift_conj(state,1,smallest,2,2,A,B).
op(A,B) :-
db_lib:drop_conj(density,2,smallest,2,2,A,B).
Replacing ensure_loaded to reconsult does not solve the error in Swi-Prolog.
I need some hint to understand this error, is this an implementation issue of Swi-Prolog?
If you want to try it, the code can be found from the ftp url below.
Thank you for the help!
I am trying to migrate an earlier code to SWI-Prolog, which was written in
SICStus 3 #3: Thu Sep 12 09:54:27 CDT 1996 or earlier
by Raymond J. Mooney ftp://ftp.cs.utexas.edu/pub/mooney/chill/.
All the questions with this tag are all related to this task. I'm new to prolog, helps and suggestions are welcomed!
This is a documented, current limitation of SWI-Prolog, related to its make mechanism. A possible workaround is to duplicate the orig-db.i file. This way the two modules, test and thetheory, will be loading different files.

Resources