This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Kawa debugging with Eclipse
- From: Charles Turner <chturne at gmail dot com>
- To: Andrea Bernardini <andrebask at gmail dot com>
- Cc: Kawa mailing list <kawa at sourceware dot org>
- Date: Wed, 23 Apr 2014 16:26:23 +0100
- Subject: Re: Kawa debugging with Eclipse
- Authentication-results: sourceware.org; auth=none
- References: <20140423154800 dot 5e31c5ff at vaio>
Hi Andrea,
(reposting to list, sorry Andrea)
On 23 April 2014 14:48, Andrea Bernardini <andrebask@gmail.com> wrote:
> Is it possible to use Eclipse to build and run Kawa?
It is surely possible, but no one to my knowledge has done that. I
used the Netbeans IDE when working on Kawa. Netbeans is "officially"
supported by Kawa, and the debugger works very well. An invaluable tip
I learned was the remote debugging feature, where you can start a REPL
on the command line and debug Kawa from the Netbeans IDE whilst
interacting at the REPL, very handy!
>
> Now I'm using Eclipse as editor, but I can't build the project nor use
> the debugger.
Yeah, that makes sense. If it's palatable for you, I suggest Netbeans.
If you have some Eclipse skills, you could look into what exactly
needs to be done for Eclipse and submit a patch, I know you're not the
only one who has wanted to use Eclipse in the past.
I know others edit in something like Emacs, and then only use Netbeans
for code navigation / refactorings / graphical debugging.
> Anyway, what other tools do you use to debug kawa?
Aside from the graphics debugging facilities in Netbeans, I use:
* The debugging procedures in the Kawa Scheme language when
appropriate (http://www.gnu.org/software/kawa/Debugging.html). The
`disassemble' procedure is particularly useful.
* For internal compiler debugging, there are some command line
options (http://www.gnu.org/software/kawa/Options.html see section
"Options for debugging"). In particular, -print-debug-expr is very
useful to see if your transformations are actually doing what you
expect.
* There are various bits of invariant checking code sprinkled in
comments in the particularly hairy parts of Kawa that obviously Per
has found useful in the past. Uncommenting these can reveal the
Dragons of Bit Rot, but in general they're useful to figure out what
some of the core invariants are in a particular module.
* Print statements! Sadly, this is one of my most effective tools
when I'm lost with what's going on.
* Per is also a very useful debugging aid :-D
Hope there's something there that helps you.
Cheers,
Charles.