DTProbLog query - prolog

i'm using DTProblog in ProbLog version 2.1.0.34 downloaded
from the bitbucket repository at https://bitbucket.org/problog/problog/src/develop/.
To run a program which uses dtproblog i type on terminal
$ problog dt program.pl
Looking at the examples in the bitbucket repository at
https://bitbucket.org/problog/problog/src/develop/test/dtproblog/viralmarketing.pl
i see that several queries are allowed, such as dtproblog_ev/2 ecc...
How can i run one of those queries from the command line?
I've tried also to open a shell using
$ problog shell
but when i try to load a program using consult/1 (https://problog.readthedocs.io/en/latest/cli.html#interactive-shell-shell)
i have an error:
?- consult('viralmarketing.pl').
Traceback....
TypeError: _builtin_consult() takes at least 2 arguments (3 given)
Thanks for the help.

I've posted the same question in the ProbLog mailing list. I've received an answer: basically, queries as dtproblog_ev/2 are no more supported in the newest version of ProbLog.
Regarding the consult/1 issue, it was a bug and now is fixed.

Related

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))

How to find out version of ghc that corresponds to snapshot without causing download of ghc

Need a way to determine the ghc version associated with a given snapshot without having to download ghc.
I could run this command to get the information, but unfortunately, it first downloads the ghc before printing out the version:
stack query compiler wanted
I need this because I am optimising a CI build and having a way to obtain the ghc version allows me to use that as a key to retrieve the appropriate build cache. The fact that trying to query this information triggers a download undermines any optimisation I attempt.
Not ideal but one can parse the stdout or stderr of
stack --resolver SNAPSHOT --no-install-ghc query
or stack --resolver SNAPSHOT --no-install-ghc path --compiler-exe.
Or here is a small program using pantry to get the info:
import Pantry
main :: IO ()
main = do
rsnap <-
runPantryApp $ do
let rurl = defaultSnapshotLocation (LTS 18 0)
url <- completeSnapshotLocation rurl
loadSnapshot url
print $ rsCompiler rsnap
#mgsloan gave me enough information to put together a solution, which can be found here:
https://github.com/haskell-works/hw-dsv/blob/master/scripts/ghc-version

GnuCOBOL entry point not found

I've installed GnuCOBOL 2.2 on my Ubuntu 17.04 system. I've written a basic hello world program to test the compiler.
1 IDENTIFICATION DIVISION.
2 PROGRAM-ID. HELLO-WORLD.
3 *---------------------------
4 DATA DIVISION.
5 *---------------------------
6 PROCEDURE DIVISION.
7 DISPLAY 'Hello, world!'.
8 STOP RUN.
This program is entitled HelloWorld.cbl. When I compile the program with the command
cobc HelloWorld.cbl
HelloWorld.so is produced. When I attempt to run the compiled program using
cobcrun HelloWorld
I receive the following error:
libcob: entry point 'HelloWorld' not found
Can anyone explain to me what an entry point is in GnuCOBOL, and perhaps suggest a way to fix the problem and successfully execute this COBOL program?
According to the official manual of GNUCOBOL, you should compile your code with:
cobc -x HelloWorld.cbl
then run it with
./HelloWorld
You can also read GNUCOBOL wiki page which contains some exmaples for further information.
P.S. As Simon Sobisch said, If you change your file name to HELLO-WORLD.cbl to match the program ID, the same commands that you have used will be ok:
cobc HELLO-WORLD.cbl
cobcrun HELLO-WORLD
Can anyone explain to me what an entry point is in GnuCOBOL, and perhaps suggest a way to fix the problem and successfully execute this COBOL program?
An entry point is a point where you may enter a shared object (this is actually more C then COBOL).
GnuCOBOL generates entry points for each PROGRAM-ID, FUNCTION-ID and ENTRY. Therefore your entry point is HELLO-WORLD (which likely gets a conversion as - is no valid identifier in ANSI C - you won't have to think about this when CALLing a program as the conversion will be done internal).
Using cobcrun internally does:
search for a shared object (in your case HelloWord), as this is found (because you've generated it) it will be loaded
search for an entry point in all loaded modules - which isn't found
There are three possible options to get this working:
As mentioned in Ho1's answer: use cobc -x, the reason that this works is because you don't generate a shared object at all but a C main which is called directly (= the entry point doesn't apply at all)
preload the shared object and calling the program by its PROGRAM-ID (entry point), either manually with COB_PRE_LOAD=HelloWorld cobcrun HELLO-WORLD or through cobcrun (option available since GnuCOBOL 2.x) cobcrun -M HelloWorld HELLO-WORLD
change the PROGRAM-ID to match the source name (either rename or change the source, I'd do the second: PROGRAM-ID. HelloWorld.)

Caffe for Windows on VS 2013 failing with leveldbutil error

I am trying to compile and run cafee with the directions found here:
https://initialneil.wordpress.com/2015/07/15/caffe-vs2013-opencv-in-windows-tutorial-i/
But when I run it, for example on the MNIST example:
"bin\caffe.exe" train --solver=examples\mnist\lenet_solver.prototxt
I get the output:
Usage: leveldbutil command...
dump files... -- dump contents of specified files
What do I do to fix this?
Pulling from https://github.com/BVLC/caffe/tree/windows solved the problem.
Check the users group in case you need help:
https://groups.google.com/forum/#!forum/caffe-users
Check the issue tracker in case you need help:
https://github.com/BVLC/caffe/issues

Resurrecting old PLT-Scheme project (pre-1999)

I'm trying to resurrect an old (1999 or earlier) project written in Scheme (PLT-Scheme, using the mzscheme interpreter (?) commandline tool). To make the matters worse, I don't know Scheme, or Lisp (in fact, I want to learn, but that's another story).
I have the source code of the project at:
github.com/akavel/sherman
Now, when running the code, it bails out with an error message like below:
Sherman runtime version 0.5
Hosted on MzScheme version 52, Copyright (c) 1995-98 PLT (Matthew Flatt)
reference to undefined identifier: list->block
(I've tried PLT-Scheme versions 52, 53, 103, 103p1. Earlier versions don't allow mzscheme -L option, which is referenced in the sherman.bat script used in the project. Later versions also have some more serious problems with the code or options.)
The difficulty is, that from what I see, list->block actually is defined - see: collects/sherman/BLOCK.SS line 48. So, what is wrong?
To run the code, I perform the following steps:
Download PLT-Scheme v. 103p1 (from the old versions download page - first closing the "PLT Scheme is now Racket" banner) - for Windows, use: mz-103p1-bin-i386-win32.zip.
Unzip (e.g. to directory c:\PLT).
Copy c:\sherman\collects\sherman directory with contents to: c:\PLT\collects\sherman (where c:\sherman contains the contents of the github repository).
Run cmd.exe, then cd c:\sherman.
set PATH=c:\PLT;%PATH%
sherman.bat run trivial.s
this command is in fact, from what I understand, equivalent to:
(require-library "runtime.ss" "sherman")
(parameterize ((current-namespace sherman-namespace)) (load "trivial.s"))
(current-namespace sherman-namespace)
After that, I get the error as described above (MzScheme version would be reported as 103p1 or whatever).
Could you help me solve the problem?
EDIT 2: SOLVED!
To whom it may concern, I've added a fully fledged "How to use this project" instruction on the project page, detailing the solution to the problem thanks to soegaard's help.
In short:
copy trivial.s trivial.rs
rem (the above is workaround for problems with 'r2s.exe < trivial.r > trivial.rs')
sherman.bat compile trivial.rs
sherman.bat run trivial.zo
rem (or: sherman.bat run trivial.ss)
Not an answer, but a few notes too big for a comment.
1. Sanity Check
The error message says list->block is undefined.
Make sure that the code in block.ss is run, by
inserting (display "block.ss is loaded!") in block.ss
just to make sure, the code is run.
2. Random Thoughts
The file blocks.ss begins with:
(require-library "functios.ss")
(require-library "synrule.ss")
(require-library "stream.ss" "sherman")
The file "sherman/stream.ss" is in the repository,
but where is "synrule.ss" and "functios.ss" ?
Ah... This code is old! Here is a description of
how require-library worked. It lists functios.ss
and synrule.ss as part of MzLib.
http://www.informatik.uni-kiel.de/~scheme/doc/mzscheme/node158.htm
Let's check out how require-library worked:
When require-library is used to load a file, the library name and the
resulting value(s) are recored in a table associated with the current
namespace. If require-library is evaluated for a library that is
already registered in the current namespace's load table, then the
library is not loaded again; the result(s) recorded in the load table
is returned, instead.
So when the code in block.ss is run, the names are stored in a namespace. If the current namespace is the wrong one, when the code in block.ss is evaluated, it would explain you error message of list->block being undefined.

Resources