Hi,
I have started using the debugger. I have some questions / notes.
Is there a way to map deleting watches to a different key than delete? I do not have one in my keyboard layout and do not see any related entry in keybindings menu.
After clearing an expression, old value remains visible in ‘Value’ column. Is it intended? I would expect the entry to be deleted.
I am using Linux and a tiling window manager — bspwm. When I close codeclap's window, it fails. It prints
and exits with error code 1. In such cases not all settings are saved, e.g. new keybindings.
(I have not seen problems when closing the program by sending SIGTERM signal).
Before understanding what was the cause, it happened to me a few times. Sometimes on restart the program gave me an option to “try to restore settings” (or something like that, I do not remember exactly). One time the program would not start, crashing each time, so I had to delete it and start with a new instance.
Some symbols seem to be missing — constants like XCB_VISUAL_CLASS_TRUE_COLOR are “undefined” (they show fine in gdb).
When I use embedded stepping the debugger does not always follow the current line, so it disappears from the visible region.
Stepping into sometimes does not stop the program. I am able to reproduce this with code below (g++ -gdwarf -O0)
I do not know if these issues have been reported previously, if so sorry for wasting time.
I have started using the debugger. I have some questions / notes.
Is there a way to map deleting watches to a different key than delete? I do not have one in my keyboard layout and do not see any related entry in keybindings menu.
After clearing an expression, old value remains visible in ‘Value’ column. Is it intended? I would expect the entry to be deleted.
I am using Linux and a tiling window manager — bspwm. When I close codeclap's window, it fails. It prints
X connection to :0 broken (explicit kill or server shutdown).
and exits with error code 1. In such cases not all settings are saved, e.g. new keybindings.
(I have not seen problems when closing the program by sending SIGTERM signal).
Before understanding what was the cause, it happened to me a few times. Sometimes on restart the program gave me an option to “try to restore settings” (or something like that, I do not remember exactly). One time the program would not start, crashing each time, so I had to delete it and start with a new instance.
Some symbols seem to be missing — constants like XCB_VISUAL_CLASS_TRUE_COLOR are “undefined” (they show fine in gdb).
When I use embedded stepping the debugger does not always follow the current line, so it disappears from the visible region.
Stepping into sometimes does not stop the program. I am able to reproduce this with code below (g++ -gdwarf -O0)
1 2 3 4 5 6 7 8 | #include <cstdio> int main(int argc, char **argv) { (argc != 0) ? (void)0 : (printf("AAA"), (void)0); // Stepping into this expression does not stop the execution of the program int x = 6; int y = 7; y *= x; } |
I do not know if these issues have been reported previously, if so sorry for wasting time.
Edited by TorquePentagram
on
Reason: Initial post
Hello,
don't worry having a few duplicates is always better than not having feedback for potential problems.
You are right that using the delete key is the only way at the moment. For the next update I will make this one changeable as well as add an "delete" option to the context menu of expressions and breakpoints.
This is intended but more or less a side-effect from the last change to show old knowns values in grey when for example an variable goes out of scope. When manually editing the field it could be better to just forget the old value.
The effect you describe sounds a bit as if codeclap starts to persist to disk but gets interrupted mid way. I will have to check what happens when closing a window with bspwm or a tiling wm in general and how to handle this correctly.
I will have a look at these two.
Can confirm that this also happens for me. This is probably because of the conditional jump on the same source line as the call and codeclap making a wrong assumption about the control flow in this case. Therefore basically trying to run to an instruction that is never reached.
I think that we can get most of this sorted for the next minor update. This shouldn't take too long since there is a planned bugfix release for 0.9.7.
don't worry having a few duplicates is always better than not having feedback for potential problems.
Is there a way to map deleting watches to a different key than delete? I do not have one in my keyboard layout and do not see any related entry in keybindings menu.
You are right that using the delete key is the only way at the moment. For the next update I will make this one changeable as well as add an "delete" option to the context menu of expressions and breakpoints.
After clearing an expression, old value remains visible in ‘Value’ column. Is it intended? I would expect the entry to be deleted.
This is intended but more or less a side-effect from the last change to show old knowns values in grey when for example an variable goes out of scope. When manually editing the field it could be better to just forget the old value.
I am using Linux and a tiling window manager — bspwm. When I close codeclap's window, it fails.
The effect you describe sounds a bit as if codeclap starts to persist to disk but gets interrupted mid way. I will have to check what happens when closing a window with bspwm or a tiling wm in general and how to handle this correctly.
Some symbols seem to be missing — constants like XCB_VISUAL_CLASS_TRUE_COLOR are “undefined” (they show fine in gdb).
When I use embedded stepping the debugger does not always follow the current line, so it disappears from the visible region.
I will have a look at these two.
Stepping into sometimes does not stop the program. I am able to reproduce this with code below (g++ -gdwarf -O0)
Can confirm that this also happens for me. This is probably because of the conditional jump on the same source line as the call and codeclap making a wrong assumption about the control flow in this case. Therefore basically trying to run to an instruction that is never reached.
I think that we can get most of this sorted for the next minor update. This shouldn't take too long since there is a planned bugfix release for 0.9.7.
Thanks. I look forward to this version then.
I have located another problem. It seems that lambdas are not handled correctly. With the code (g++ -O0 -gdwarf)
variables ‘Lambda’ and ‘C’ are not accessible through expressions window — they are displayed as “undefined”. Interestingly, correct values are shown inline in the source code window. It also does not happen if the lambda is not called.
It is rather annoying, as (probably) due to this I cannot see a number of local variables in my code and have to fallback to gdb in such cases.
1 2 3 4 5 6 7 8 9 10 11 12 | int main() {
int A;
A = 3;
int B = 8;
const auto Lambda = []{
};
Lambda();
int C = 6;
C += 2;
}
|
variables ‘Lambda’ and ‘C’ are not accessible through expressions window — they are displayed as “undefined”. Interestingly, correct values are shown inline in the source code window. It also does not happen if the lambda is not called.
It is rather annoying, as (probably) due to this I cannot see a number of local variables in my code and have to fallback to gdb in such cases.
Edited by TorquePentagram
on
TorquePentagram
variables ‘Lambda’ and ‘C’ are not accessible through expressions window — they are displayed as “undefined”. Interestingly, correct values are shown inline in the source code window.
Thanks for reporting this. I am seeing this as well and should be able to get this fixed for the next update. If nothing unexpected happens that one should be available roughly on Sunday.
Most if not all of your issues should be fixed with this update. I wasn't able to see a clear reason that would cause a faulty or partial configuration to be stored that fails to start up correctly. I don't see how "X connection to :0 broken" could have caused this. So this may still be present but I haven't heard of this as being a common issue.
Great, thanks.
I will keep an eye on this corrupted configuration. I will inform you if this continues to happen, or I am able to reproduce it. However, I think has rather low priority, unless it happened each time, so no configuration change would be possible.
(And there is no need to thank me for bug reports. I mean, I am the one who gets something from this. It seems that Codeclap is going to be quite usable, much more than gdb, if some more work is put into it, so there really is no reason for me not to report problems.)
I will keep an eye on this corrupted configuration. I will inform you if this continues to happen, or I am able to reproduce it. However, I think has rather low priority, unless it happened each time, so no configuration change would be possible.
(And there is no need to thank me for bug reports. I mean, I am the one who gets something from this. It seems that Codeclap is going to be quite usable, much more than gdb, if some more work is put into it, so there really is no reason for me not to report problems.)
Edited by TorquePentagram
on
Speaking of unexpected. There were still problems with the recent llvm integration on Linux but hopefully those should be gone for good now.
An updated snapshot build 0.9.7-20210414 is now available that is close to the upcoming 0.9.7.1. From what I know there are still problems with variable lookup inside closures when compiled with clang (which I want to fix for the final update) and keeping breakpoints across runs inside closures also doesn't work right now (which I hope to fix but which may be moved to 0.9.7.2).
// update
Expressions may not work at all in this snapshot (depending on the system), probably still llvm problems to fix.
// update2
0.9.7-20210415 is available addressing the previous issue
An updated snapshot build 0.9.7-20210414 is now available that is close to the upcoming 0.9.7.1. From what I know there are still problems with variable lookup inside closures when compiled with clang (which I want to fix for the final update) and keeping breakpoints across runs inside closures also doesn't work right now (which I hope to fix but which may be moved to 0.9.7.2).
// update
Expressions may not work at all in this snapshot (depending on the system), probably still llvm problems to fix.
// update2
0.9.7-20210415 is available addressing the previous issue
Edited by spx
on
Another thing. In the view menu there is a “keep source view X lines ahead” option. I am not sure if I understand it correctly, but if it refers to the margin after which the source is automatically scrolled, then it does not seem to work. With the code
the focused line goes outside the visible window, before the source is scrolled.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | int main() {
int a = 3;
a *= 6;
a *= 6;
a *= 6;
a *= 6;
// ...
a *= 6;
a *= 6;
a *= 6;
a *= 6;
a *= 6;
a *= 6;
a *= 6;
a *= 6;
}
|
the focused line goes outside the visible window, before the source is scrolled.
Edited by TorquePentagram
on
I have returned to work on c++ project. I have some problems with codeclap 0.9.7.1 (mainly with inability to display some expressions) and hoped that maybe the next version solves them. However, according to the roadmap it seems that the release has been delayed for some time. I want to ask when the release can be expected.
Never mind, it seems that either I have misread the release date or it has been postponed and I have not noticed.
Edited by TorquePentagram
on
TorquePentagramI have returned to work on c++ project. I have some problems with codeclap 0.9.7.1 (mainly with inability to display some expressions) and hoped that maybe the next version solves them. However, according to the roadmap it seems that the release has been delayed for some time. I want to ask when the release can be expected.
Never mind, it seems that either I have misread the release date or it has been postponed and I have not noticed.
You were right. The roadmap has changed a bit but wasn't yet updated at the time of your post. Due to some time constraints at the moment the 0.9.7.2 release will be skipped as such and I will again start to upload regular snapshots builds (mostly automated) very soon. Once the infrastructure is there I probably won't stop those snapshots even after the next full update.
I am really bad at estimating exact dates at the moment but I hope to have this done and the first snapshot available by Tuesday.