I'm very new to Prolog and have been using Sicstus to help debug my code. Is there a way to view all the bindings while you are stepping through a query using trace/0? Or is there some other way to print out during the steps?
This is done automatically if you use the SPIDER IDE. You can also show the bindings when running SICStus from within the Emacs mode and, finally, the debugger can print the bindings using the 'v' debugger command.
Not all variables are available since some variables may disappear due to compiler optimization. If this is a problem you can use consult/1 to run the code interpreted. This is slower but sometimes gives somewhat more details in the debugger.
If using Sicstus with Emacs then C-c C-g will open a buffer that will display prolog bindings as you step through with trace
Related
I'm using SICStus 4.2.0 and I was not able to find out how to clear the content of the console. Is it even possible?
write('\33\[2J').
This is in no way specific to SICStus. It is the ANSI escape code and works in any ISO conforming system.
While SWI-Prolog provides a tty_clear predicate in its tty library, Sicstus doesn't seem to have a built-in alternative for this. But there is a simple workaround (for unix/linux, may not be that simple on windows): You can start the sicstus shell via rlwrap, which is a readline-wrapper for arbitrary shell commands. Besides the obvious benefit of the command history, this also means you can now use other shell functionality in sicstus, like the left/right arrow keys, home/end keys, Ctrl-k for deleting everything after the cursor, and Ctrl-l to clear the screen.
rlwrap is available as a package for many linux distributions, for windows you would need to use cygwin - this article describes how to setup rlwrap with powershell (for use with sqlplus in this case) so I guess powershell is a requirement too.
In summary, once you have rlwrap installed, simply start sicstus as rlwrap sicstus and use Ctrl-l to clear the screen.
I have spent some time looking through the documentation and I could not find a way to programmatically clear the console screen (in case this is possible, I am happy to be proven wrong). Alternatively, you might want to use SPIDER, that is a SICStus Prolog IDE: http://sicstus.sics.se/spider/ In Spider, the ordinary TopLevel interface has the option of clearing the current content of the console. Hope this helps.
If you're using swipl, then add this line in your user init file:
cls:-write('\33\[2J').
That should do it.
I am very interested in learning more about the specifics of debugging, and I am looking into making a very simple GUI for debugging with GDB.
I understand in general how debuggers work, but I am having trouble of how an IDE interacts with an external debugger like GDB.
I am sure I could call commands to setup breakpoints and such in the debugger, but I am unsure of how an IDE would get the information back like, oh the breakpoint you set has been hit or variable values and such. Is there good information of using GDB within another program, I tried searching google, but all results I get are about how to debug another program using GDB or setting it up in a IDE already developed.
does it involve hooking into GDB? or does GDB have a library?
Thanks.
does it involve hooking into GDB? or does GDB have a library?
No and no.
GDB has a machine interface, intended for interfacing between and IDE and GDB.
I want to write a GUI based debugger wrapped over GDB. Because, I dont want the program to stop after watch points or break points. Instead, it should redirect the details like filename, line number, new value and stuffs to a file and continue execution.
I am pretty bad at scripting. So, I want some starting point to start developing front end for GDB. As far as I googled, this link http://ftp.gnu.org/old-gnu/Manuals/gdb-5.1.1/html_node/gdb_211.html is not much understandable for a beginner in this activity?
Hopefully, I will get help on development in C/C++.
For writing a GDB frontend, you indeed want to use the GDB/MI protocol but perhaps read this up-to-date copy instead of the older one you linked to.
Sample GDB/MI session
(Lightly edited version of this section from the GDB manual)
Launching GDB with the MI Command Interpreter
$ gdb -q --interpreter=mi2
=thread-group-added,id="i1"
(gdb)
File /bin/true
-file-exec-and-symbols /bin/true
^done
(gdb)
Break main
-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004014c0",func="main",file="true.c",fullname="/usr/src/debug/coreutils-8.17/src/true.c",line="59",times="0",original-location="main"}
(gdb)
Run and Breakpoint Hit
-exec-run
=thread-group-started,id="i1",pid="2275"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
=library-loaded,id="/lib64/libc.so.6",target-name="/lib64/libc.so.6",host-name="/lib64/libc.so.6",symbols-loaded="0",thread-group="i1"
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004014c0",func="main",file="true.c",fullname="/usr/src/debug/coreutils-8.17/src/true.c",line="59",times="1",original-location="main"}
*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x00000000004014c0",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffde98"}],file="true.c",fullname="/usr/src/debug/coreutils-8.17/src/true.c",line="59"},thread-id="1",stopped-threads="all",core="1"
(gdb)
Continue
-exec-continue
^running
*running,thread-id="1"
(gdb)
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
Quitting GDB
(gdb)
-gdb-exit
^exit
Existing GDB/MI Clients
There are several GDB/MI client implementations in C, C++, Java, Python. I'll list a few that I find easy to read:
The inactive libmigdb project (sample program, public interfaces) -- The good news is that it's an attempt at creating a reusable C library. The bad news is that it's not well maintained, e.g. I think it's missing GDB non-stop mode and catchpoint commands support, features that your use case would likely need.
python-gdb-mi -- Quite readable if you know Python
The C++ GDB/MI client code in QtCreator -- Also quite readable though it's written as part of an abstraction layer to support multiple debugger engines.
You might want to also browse this list of GDB frontends.
Since you already pointed out the gdb/mi interface maybe an existing solution might give you an idea on how to address your needs. Here is a list of existing interfaces. Look at their approaches and how they address the different issues.
Another approach that might be helpful could be automated sessions. Not to discourage you from writing a gdb gui, but such an automation could be a good start to get a feeling for the steps needed and could maybe also used as a start. Maybe generating a session script and starting gdb with it. gdb -x to load a command file.
Here a link concerning automating:
What are the best ways to automate a GDB debugging session?
I hope it helps. Good luck!
Though writing new GUI tools gives you more knowledge, I suggest you to take up eclipe and modify according to your needs. It saves lot of your time as well as more flexible.
Programming a gdb wrapper to achieve your goal is way to much work.
See how you can execute script on breakpoint hits: gdb scripting: execute commands at selected breakpoint
Also take a look a gdb tracepoints: http://sourceware.org/gdb/onlinedocs/gdb/Tracepoints.html
During web searching, I found the following comment : Traditional Lisp debugging practices can still be used.
What are the traditional debugging practices?
Normally, what tools are used for debugging lisp (with/without emacs)?
I don't know what Bill meant specifically, but IME:
Typically your editor will have a running instance connected to it. You can compile functions immediately to insert them into the running image -- since Lisp has its own compiler, you're just telling the running image to read and compile a small section of text. Or you can run functions directly, to see what they do.
When an exception is thrown (or a condition is signaled, if you're lucky enough to be in a dialect with conditions), the debugger will show you the stack trace and let you decide how to continue.
The major difference between Lisp and other high-level compiled languages is that in Lisp you're basically always writing code with the debugger attached.
As clojure was tagged in the question, I'll give our perspective.
Class files generated by the clojure compiler include line- and method-based debugging info, so any java debugger will interoperate directly with clojure code, including breakpoints and object inspection.
If you use emacs/slime as your development environment, integration with slime's debugger has recently been included. As documentation is a little sparse, it's probably best to check out the scope of the support on github directly.
Run edebug-defun in emacs and you will see that lisp is magic.
In something that I would call approaches a "traditional set of Lisp debugging techniques" are:
Debug printouts
Function tracing (each invocation of a traced function
is printed with an indentation that corresponds to call depth, on return the return
value is printed).
Explicit invocation of the in-image debugger
Ending up in the in-image debugger due to a bug (trying to add an integer and a symbol, for example)
Basically just things like adding code to print out values as it runs so you can see what's happening.
I'm using OCamlWinPlus v1.9RC4. It sucks pretty hardcore. It's constantly crashing, and lacks basic features. What other toplevel OCaml programs can be recommended for Windows Vista?
You can use a Windows version of Emacs and use the customization files (*.el) provided with OCaml's source archive to turn Emacs in a powerful, if idiosyncratic, toplevel.
You'll find the instructions in ocaml-3.11.1/emacs/README. Specifically:
Once you have started caml by M-x run-caml:
M-C-x send phrase to inferior caml process
C-c C-r send region to inferior caml process
C-c C-s show inferior caml process
C-c` goto error in expression sent by M-C-x
I used ocaml from cmd. Editing with history is there..
Can you elaborate on ocamlwinplus crashes? Did you try to debug it?
I use Notepad++ to write code then I compile it from cmd, simply there is no simple way to do it with OCAML!