This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Kawa debugging with Eclipse


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]