I figure it may not be built to do that but I might ask.
I want to run a simple cli application and have it show the backtrace in case of error.
swipl -f test.pl -g test(X)
This runs the goal test in the program.
ERROR: -g test(X): Arguments are not sufficiently instantiated
However, it doesn't show the full backtrace. What I need to do is every time, open the GUI, type guitracer,trace, run it, etc. That shows the program can keep a backtrace.
I figure it may not be built to do that but I might ask.
Can't believe I got lost in debugger pages. As said in comments,
:- use_module(library(prolog_stack)).
is enough.
Related
I setup a breakpoint in my Go code with runtime.Breakpoint(), save the file (my editor, Atom with go-plus installed, runs go install . on save). Then I run Delve in terminal with dlv debug, and type continue after it starts.
When the breakpoint kicks in, I want to test a couple of things (basically to print reader's data via a bytes.Buffer). But, I get the following error
buf := new(bytes.Buffer): "1:5: expected 'EOF', found ':='"
and in general cannot do much more than print values.
Is it really not possible to do this sort of thing? I am used to Python's pdb where setting variables or calling functions is not a problem and I would expect Delve is capable of the same.
So, what am I doing wrong?
Not possible yet. Right now (2018-NOV) work is in progress on Delve, but unfinished.
Go runtime was changed recently to allow this kind of call. Delve have a Github issue tracking the progress of such feature, but is still experimental and incomplete.
I've got a Makefile pretty big, and it have some errors/warnings.
My objective is to filter the display to show only the error of the Makefile; it will help me a lot for debugging and executed this Makefile good by saving a lot of time.
There is something of 40+ errors and 100+ warnings, so it's just a pain to see all warnings and is really difficult to determine if a correction of the Makefile works good or bad
I have already tried to use the grep command with make | grep error, but the display is the same (all warnings are printed).
I'm using Ubuntu 16.04 LTS
I have been using SWI Prolog for a while and I am a little unhappy about the interpreted nature of it. When I found the qsave_program/2 I though I was in for a treat. I wasn't. Apparently SWIPL doesn't actually statically compile, even with qsave_program('foo.exe', [stand_alone(true), goal(foo(X))]).
This is what I have done:
From the GUI console, I have loaded the source file *.pl with consult/1,
I do a test and query foo(X) and get the expected result,
I submit the command qsave_program/2 as above (with real input of course),
I attempt to run the program foo.exe,
I receive a system error, outlining the execution error which states that 'libswpl.dll does not
exist' (I am running windows of course),
I rage at SWIPL.
I have noticed that libswipl.dll does exist - in the SWI Prolog program file that is! I can successfully run the program in this location, which is in the same directory as SWIPL-win.exe
I ask you: what am I missing? Do I need to do any other precompiling for SWI Prolog?
In my attempt to compile GCC I noticed that while ./configure doesn't yield error messages and returns an error code of 0, there are still errors logged in config.log, which do later on cause make to fail. So, why doesn't configure fail already? Or does make modify config.log later on?
config.log contains the output of all configure probes. Some of them are expected to fail. For example, frequently Autoconf probes for several different possible alternative implementations of particular functionality, and some of them are expected to fail depending on the characteristics of your system.
It's therefore up to the author of the Autoconf configure.ac script to explicitly fail the configure step if the results are not viable. Some people do this when writing their configure.ac and some don't. Sometimes it can be quite hard to know at configure time whether a particular set of findings are viable. There's also a reasonable argument that it's easier to diagnose problems during the build, later on, than to issue an error message from configure and make people search through config.log for the details. That's particularly the case if the problems are relatively obscure.
The short answer is that configure didn't fail because the people who wrote the configure script you're running didn't program it to fail for the specific errors that you're seeing, for one reason or another.
I find it difficult sometimes to locate errors/warnings in large projects upon make-ing (gnu). How do I segregate the errors/warnings from the usual compilation messages when the error does not stop the build process from going any further? A wrapper shell script could pick and display whatever I want, but before fleshing out one I thought of asking about the alternatives.
Thanks.
In theory, make -s will suppress the "routine" output of the build process, leaving you with only the errors and warnings. Also in theory, make will stop as soon as it encounters an error.
If either of those is not true for the project(s) you're working with, that's probably due to poorly written makefiles. So fixing the makefiles is one alternative.
To help make sense of verbose builds, some simple highlighting as provided by colorgcc can go a long way. IDEs like eclipse or even emacs can also helpfully pick out the error messages in the build output.
Also, it might be helpful to note that warning and error messages are usually written to stderr, while everything else goes to stdout. So it might be useful to simply discard stdout like so: make >/dev/null.