[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] A simple debugger

From: Peter Bex
Subject: Re: [Chicken-hackers] A simple debugger
Date: Sun, 6 Dec 2015 14:46:08 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Nov 27, 2015 at 12:46:40PM +0100, address@hidden wrote:
> Hello!
> This patch provides a graphical debugger, both for master and chicken-5.

Just to keep the ball rolling, some comments.  A few things are missing:

- distribution/manifest needs to be updated with the new source files
    so that pregenerated source tarballs will include the debugger.
- The "what gets installed" section in the README should mention
    bin/feathers(.bat) and share/chicken/feathers.tcl
- The NEWS file should probably mention the big new feature that
    there's now a debugger!
- A manpage for feathers.  Not sure if that's absolutely required,
   considering how minimal our manpages are.  But for completeness, so
   someone can get some info about where this strange new "feathers"
   executable in their path comes from :)

> The debugging-support consists of two parts: 1. An extension to the runtime 
> system
> that connects to a TCP server on port 9999 and communicates through a 
> text/s-expr
> based protocol and a graphical front-end written in Tcl/Tk.

Usability-wise (very subjective!), I have a few suggestions.

Firstly, it would be nice if the debugger would state what port it's
listening on, so that you can know what to use in CHICKEN_DEBUGGER.

I also found the behaviour a bit strange how it locates source files, but I
only tried it briefly so maybe that just takes some getting used to.
The way the debugger creates windows doesn't seem to play very well with my
tiling window manager "i3" (I keep looking for more space where to put the
new windows), but this also may be a matter of getting used to it.

Also, this adds a new dependency to CHICKEN: tcl/tk+wish.  I don't mind
it much because it's an optional dependency, but maybe we can make the
installation of this script into bin (adding it to $PATH) optional to
make the life of packagers easier?  Finally, the "wish" command should
probably be a variable so that packagers can control which version and
the full path of wish to use without having to patch the build system.
I think just "wish" is a fine default of this variable, though.


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]