So, created this issue https://github.com/gambit/gambit/issues/283 , refering to this email also. Discussion can continue here or in the issue.
I guess ultimately maybe someone could make a patch to Gambit, Marc does not need to make it, however, this is a quite wide-spanning thing so I think at the very least Marc's comments would be decisive... anyhow everyone please share what you think.
This just looks like a very small problem with proportionally paramount consequences, so I hope we can address it around now.
2017-07-25 17:57 GMT+08:00 Adam adam.mlmb@gmail.com:
Hi Marc!
The following topic has been important since a long time. I think there are like 10 bumps in the mailing list on this one for many years.
Maybe it was bumped so many times on the ML that if you answered at some point I might even have missed that response. Now to get to the bottom with this:
Your complete response on this one would be very valuable.
Gambit debugging can regard both interpreted and compiled modes. There's intra-Gambit debugging (singlestepping, ,bt , pp etc.), and there's extra-Gambit debugging (GDB bt , core files, etc.).
Let's categorize the more subtle debugging options such as the "console" file output and any debug output in the memory subsystem etc. as extra-Gambit here too.
Gambit's intra-Gambit debugging of interpreted code is always enabled in the default distro.
The remainder of debugging functionality is off by default, and enabled by the --enable-debug option to ./configure .
--enable-debug unfortunately is a double edged sword, it will give you some nice debugging stuff - and it will crash your whole operating system given the "right" parameters, which are very easy to run into without in any way having aimed at them intentionally.
The things I am aware that --enable-debug does are:
- It enables C-level debugging symbols, i.e. adds "-g" or the like to
gcc/the C compiler.
- It enables debugging information for compiled code, within the Gambit
environment, so that |pp|, |bt| etc. will show code instead of nothing/just #<procedure 123>.
- It enables debugging information for compiled code, on the level of the
C code, so that GDB/the C-level debugger, will show Scheme code too (right?)
It enables the production of the
Some more stuff maybe?
The disaster happens in 4. : your "console" file will fill the disk which causes system havoc, and "rm console" will not fix the problem as the OS will unlink the file at first when you close Gambit, duh!
However, to the best of my awareness, there is no way to enable/disable the debugging options with any granularity at all. The only convenient option below the disastrous "--enable-debug", is "CC_FLAGS="-g" ./configure", which enables too few options and hence is unsatisfactory.
This overall gives me the impression that the debugging options have not been tailored to match the needs for users (i.e. for helping users debug their code) but for Gambit development (for helping resolve internal Gambit bugs and aid Gambit system development).
What I would like here is simply to be able to enable/disable these five individually.
In normal cases, I want 1-3 to be enabled, and all else disabled.
I consider 4-5 to be for debugging of the Gambit system itself, only.
Probably normally, I'd actually make 1 going via CC_FLAGS as I want to choose the C compiler's -O option myself, and then use the specific ./configure arguments for enabling 2 and 3 only - and hence implicitly keep the feared 4 (and any 5 that I wouldn't want anyhow), disabled.
Would you be able to implement this this year?
Any comments from other users would also be much appreciated.
Thanks!