The 2024 Wheel Reinvention Jam just concluded. See the results.

beta 0.9.5.2

spx
0.9.5 is now available for Windows and Linux.

macOS is missing for now which wasn't really intended and I will try to fix this within the upcoming days. At the moment the only working build is signed but can't be notarized by current standards. Meaning that running it when flagged "com.apple.quarantine" may be harder but I have to check that. Unfortunately I can't get the task_for_pid entitlement to work when signing and notarizing with the correct options. macOS then fails to check the signature on startup (thereby forcefully killing it) even when it is perfectly valid from what I see. If there is someone here who may be able to give insight into this I am happy for any help.

This release is labeled as beta, meaning that chances are good that it will work for small to medium sized projects rather well.

Support for unlinked debug information like fastlink should be considered experimental, however that code is passing the same tests as everything else so there is a good chance it will work.

If anything doesn't work please don't hesitate to contact so that your issues can be fixed for the next upcoming update or a smaller fix if applicable. While most basic functionality in codeclap is tested via automated tests, some features aren't that easy to be tested outside the actual interface and it is also hard to keep track of all of them by hand. There have been quite a lot of changes (for example rendering on Windows is now fully D3D11, Metal on macOS and OpenGL 3 on Linux) and it is easy to break something for individual use cases.

The full changelog is available here: https://issues.codeclap.cc/changelog_page.php?version_id=15
Known issues and planned features: https://issues.codeclap.cc/roadmap_page.php?version_id=3


So what's up next.

Cleanup and bugfixes
The focus of codeclap in regards to support for different operating systems and formats has shifted quite a bit since the initial incarnation. For the next update one big focus is to unify the handling of different platforms as much as possible to avoid breaking individual platforms. Adding another variable (x64/ARM architectures) makes this even more important.

Project navigation
Currently codeclap works well when navigating in few files at a time and jumping between functions (using "jump to any") while debugging. However keeping track of a lot of open files and the directory structure within the "project" (as a term for the binary that is executed and all linked debug information and source files) isn't very comfortable. 0.9.8 should support this better by providing a "project explorer" like the one in every IDE.
There are also definitely a few usability issues remaining and I will keep an eye on how to make codeclap as easy to use as possible.

Support for other architectures
If nothing goes wrong codeclap will become capable of supporting additional architectures besides x64. I will start with this rather soon by porting to ARM64/AArch64 on Linux. The goal after that is to provide support for ARM-based macOS as soon as possible (which is the main reason to start working on this now).

Free evaluation version
There will be a free evaluation version at some point after 1.0. However it is not yet clear in which way this version will be different from the full "pay to use" release. If you are unsure if codeclap will reach a point where it is really worth the price for you I'd highly encourage you to wait for the free version, try it out and then decide. However if you basically can't wait to try out every single update and want to support this project and its goals then you are at the right place. Of course there is a large space in between these two sides and there you just have to decide for yourself.

Happy coding and stay safe

Comments

Awesome, more codeclap is coming :D
albatros
Awesome, more codeclap is coming :D


well there were a few last-minute issues on Linux that I didn't notice before (ptrace is a bit of a hassle). However those should hopefully be sorted out now.
I can also now take a look at your feedback for potential improvements for the next update.
Congrats on the release, I have been following the bug tracker for a while now and have been looking forward to it.


Is there any way to enable additional debug information for codeclap itself? Unfortunately I keep getting a Segmentation fault when starting a configuration.

I am adding the configuration by dragging and dropping the executable, it runs normally for a few times then I suddenly get the segmentation errors when starting. The only settings that I have changed are the dpi settings and "Break at function/file:line:" for that configuration. Both seem to work correctly. I am still trying to find the exact steps to reproduce it.

Segmentation fault remains even when creating a new configuration, the only way I have been able to resolve it is by deleting the entire codeclap directory and restoring it.

Arch Linux x86_64
Kernel 5.7.9-arch1-1
gcc 10.1.0

Edit: I am able to reproduce it now.
1 - Add new configuration by dragging and dropping.
2 - Break at function/file:line: 'main'
3 - Change dpi to use custom value - 128 ( any value seems to cause the issue )
4 - Start this configuration - First time runs correctly.
5 - Start this configuration - Second time and all others will cause a segmentation fault.

Note - When using the default dpi I am able to start the configuration multiple times without any errors.
Note - Issue will happen even when changing the dpi during the first startup.

@joe513
thanks for the report. On Linux the easiest way to report crashes is to simply run the program under a debugger and to either send me the stacktrace from the faulting thread, all threads or possibly a small core dump generated by gdb/clang or the kernel.

However I think that I am able to reproduce what you describe. Seems "break at function" can cause some inconsistent state after a few runs. Can you try "Windows > Reset panel layout" to see if this fixes the problem? If not your problem may be a different one.
Thanks for the quick reply.
I updated my original post with exact replication steps.


"Windows > Reset panel layout" does work, but only once. If I do not use this in between each start the issue returns.

Edit: trace
Thread 7 "codeclap" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffabbf9700 (LWP 193202)]
0x00000000004a7c81 in RecursiveDeleteFrontendBuffer ()
(gdb) bt
#0 0x00000000004a7c81 in RecursiveDeleteFrontendBuffer ()
#1 0x00000000004a7f20 in ReplacePanel ()
#2 0x0000000000523058 in EnsureBufferForTask ()
#3 0x000000000056f070 in DebuggerProcessTaskState ()
#4 0x000000000056af1a in ProcessWorkItem.constprop.319 ()
#5 0x0000000000572ff6 in DebuggerMainLoop ()
#6 0x00007ffff7c32422 in start_thread () from /usr/lib/libpthread.so.0
#7 0x00007ffff7b61bf3 in clone () from /usr/lib/libc.so.6
indeed this is the same issue i saw. for me it is quite rare (but a lot more common with break at function) but critical enough to be fixed in a ".1" later today.

I will also add the macOS build with this update. It should work but will require to manually remove the "com.apple.quarantine" attribute. Looking for a different solution will require a bit longer.
joe513
"Windows > Reset panel layout" does work, but only once. If I do not use this in between each start the issue returns.


I've uploaded 0.9.5.1 which should fix this for good. Please report back if this is still an issue for you.
The update doesn't fix a broken state by itself so if your debugger panel is missing or is placed "squished" to the edge of the window, you have to reset it once yourself.

The macOS build is now also available with a small caveat described here (and in the dmg itself).
spx

I've uploaded 0.9.5.1 which should fix this for good. Please report back if this is still an issue for you.
The update doesn't fix a broken state by itself so if your debugger panel is missing or is placed "squished" to the edge of the window, you have to reset it once yourself.


Thanks for the quick fix. Appears to be working correctly now.
0.9.5.2 is now available which among a few smaller improvements contains some fixes for autocompletion on the two input fields that support paths (executable and working directory).

These contain one fix for invalid memory access related to those inputs. For macOS users, the last build managed to misplace the “z” key,.. it is now available again.