Hello! I've just become a patron. Hope the project keeps moving forward nicely. I'm hoping to use it here soon when I go to do a Linux port of Const Port. I'll let you know if I encounter any problems then.
I wanted to ask quickly if there was any plan for an OSX version of c[ode]clap? I know it's probably not exactly the #1 priority on your list of things to do but if it is in your sights for later it would be nice to know.
Also, if you're interested in a little outside help I'd be happy to help however I can. For example, creating an OSX version would be something I could look into ;) I've never done a real port before but I'm going through implementing a OSX platform layer for Const Port right now. I know implementing another person into the project is not the easiest thing, especially at these early stages of development, but if you're at all interested, or have any questions for me, you can email me at [email protected]
I look forward to seeing where c[ode]clap goes!
-Taylor Robbins
I wanted to ask quickly if there was any plan for an OSX version of c[ode]clap? I know it's probably not exactly the #1 priority on your list of things to do but if it is in your sights for later it would be nice to know.
Also, if you're interested in a little outside help I'd be happy to help however I can. For example, creating an OSX version would be something I could look into ;) I've never done a real port before but I'm going through implementing a OSX platform layer for Const Port right now. I know implementing another person into the project is not the easiest thing, especially at these early stages of development, but if you're at all interested, or have any questions for me, you can email me at [email protected]
I look forward to seeing where c[ode]clap goes!
-Taylor Robbins
Feel free to not only post about problems you may encounter but I'd also love to here if you are missing some functionality that may have helped you out in certain situations. There are still features missing but it doesn't hurt to emphasize the need for something instead of forgetting about it.
Ideally my "ultimate goal" is to have c[ode]clap available on all major platforms. I started with Linux because this is the platform that in my opinion has the biggest need for something like this and also reflects my personal requirements. I've played around a bit with which parts of the debugging core would have to be ported in order to support mingw64 Windows (which basically just removes the requirement for pdb in favor of DWARF); iinm OS X uses DWARF as well so the effort should be similar, probably a bit less because the BSD roots of OS X should be more similar to Linux.
I will definitely keep your offer in mind. But (as per current plans) I will not consider compatibility to other platforms until a more substantial portion of the basic functionality is implemented and out-of-process debugging is supported which will bring a much better way to support different OS call, binary format and debugging format interfaces. Very likely this would also be required to provide a good way to integrate "external" extensions to these functions.
In any case the project will definitely move forward and I will give my best to be as flexible as possible in this process.
Ideally my "ultimate goal" is to have c[ode]clap available on all major platforms. I started with Linux because this is the platform that in my opinion has the biggest need for something like this and also reflects my personal requirements. I've played around a bit with which parts of the debugging core would have to be ported in order to support mingw64 Windows (which basically just removes the requirement for pdb in favor of DWARF); iinm OS X uses DWARF as well so the effort should be similar, probably a bit less because the BSD roots of OS X should be more similar to Linux.
I will definitely keep your offer in mind. But (as per current plans) I will not consider compatibility to other platforms until a more substantial portion of the basic functionality is implemented and out-of-process debugging is supported which will bring a much better way to support different OS call, binary format and debugging format interfaces. Very likely this would also be required to provide a good way to integrate "external" extensions to these functions.
In any case the project will definitely move forward and I will give my best to be as flexible as possible in this process.
Thanks for the reply!
I didn't realize OSX uses DWARF. That would make it a bit harder to port. In that case I agree that Linux needs it the most and it's probably not worth doing any other platforms atm.
I will keep a list of bugs/notes/missing features when I go to use it (in the next couple weeks probably) and then post a review when I get there.
Good luck on the project!
-Taylor Robbins
I didn't realize OSX uses DWARF. That would make it a bit harder to port. In that case I agree that Linux needs it the most and it's probably not worth doing any other platforms atm.
I will keep a list of bugs/notes/missing features when I go to use it (in the next couple weeks probably) and then post a review when I get there.
Good luck on the project!
-Taylor Robbins
sorry for not being clear. DWARF is also what Linux uses for debugging information and what can be used on Windows when using mingw64.
There is some information about OS X written here https://lldb.llvm.org/symbols.html.
But of course there are still lots of differences. The system interface (kernel), the binary format, maybe the calling convention (I know/have read that it has some differences on Windows), apparently storage of the debugging symbols.
There is some information about OS X written here https://lldb.llvm.org/symbols.html.
But of course there are still lots of differences. The system interface (kernel), the binary format, maybe the calling convention (I know/have read that it has some differences on Windows), apparently storage of the debugging symbols.
Edited by spx
on
Hello, sorry for reviving old thread, but I have some feedback on the OSX version (0.8.43) and it seems to fit well here.
The core functionality is there - the executable launches, can be stepped through. However, the application is not really usable for any real debugging yet. Following points are in no particular order:
If those problems were fixed and there was more documentation, I can imagine using codeclap for regular work - it seems intuitive, stable and fast enough. (I'd also appreciate a more button-oriented UI, but I might be in a minority with this opinion and the current state is good enough.)
The core functionality is there - the executable launches, can be stepped through. However, the application is not really usable for any real debugging yet. Following points are in no particular order:
- Almost all actions produce default OS "bell" sound, which gets old pretty quickly
- UI reacts only to full trackpad clicks, "taps" are not enough. Not sure how is that possible, all other applications respect the OS setting to treat taps as clicks (though Firefox has sometimes similar problems on some buttons, not sure what is going on there).
- Source and symbols don't load. I can manually force some files to open, sometimes, but in general, there are no source files. LLDB (and its frontends) don't have problems on the same executable. Since the symbols are missing, stacktraces only contain the current instruction pointer and the library name. Sometimes a notification that "main" has been found pops up and offers to run to it, however it doesn't stop at "main" and keeps running through the application.
- Scrolling is not very smooth (although this seems to be a problem with input, not with general application responsiveness). Sometimes it breaks, so that scrolling up (towards line 1) works only for a few lines and then stops (starting to scroll up again does nothing until I've scrolled down a bit, then it works again but only for a few lines again), but scrolling down works always. Scrollbars would be nice to see the approximate location in the file. EDIT: It turns out, that this isn't limited to just mouse/touchpad scrolling - arrow keys exhibit similar behavior - only down arrow works.
- Pausing all threads (which works perfectly btw.) causes all threads to open in the source view, which is not that useful when the application has more than a couple of threads, because each source "tab" is only a few characters tall.
If those problems were fixed and there was more documentation, I can imagine using codeclap for regular work - it seems intuitive, stable and fast enough. (I'd also appreciate a more button-oriented UI, but I might be in a minority with this opinion and the current state is good enough.)
Edited by Jan Polák
on
Almost all actions produce default OS "bell" sound, which gets old pretty quickly
This slipped through for quite some time as I have all of those sounds disabled. But will finally go away with the next update.
UI reacts only to full trackpad clicks, "taps" are not enough. Not sure how is that possible, all other applications respect the OS setting to treat taps as clicks (though Firefox has sometimes similar problems on some buttons, not sure what is going on there).
The main problem here is probably that "tap to click" on macOS behaves only as a "click" event without any involvement of "mouse down" or "mouse up". I will look into fixing this without changing too much in the input handling.
Source and symbols don't load. I can manually force some files to open, sometimes, but in general, there are no source files. LLDB (and its frontends) don't have problems on the same executable. Since the symbols are missing, stacktraces only contain the current instruction pointer and the library name. Sometimes a notification that "main" has been found pops up and offers to run to it, however it doesn't stop at "main" and keeps running through the application.
lldb is definitely more "intelligent" in finding debug information. codeclap currently scans the directory of the module for any .dSYM with a matching UUID which hopefully is the cause for your problems. The next update will improve in finding debug information and should be more on par with lldb.
Scrolling is not very smooth (although this seems to be a problem with input, not with general application responsiveness). Sometimes it breaks, so that scrolling up (towards line 1) works only for a few lines and then stops (starting to scroll up again does nothing until I've scrolled down a bit, then it works again but only for a few lines again), but scrolling down works always. Scrollbars would be nice to see the approximate location in the file. EDIT: It turns out, that this isn't limited to just mouse/touchpad scrolling - arrow keys exhibit similar behavior - only down arrow works.
Scrolling will be a lot better with debug information. I've seen a few remaining problems when viewing a plain assembly region without debug information which should also improve over time but codeclap is intended as a source-level debugger. Scroll bars will be included in the next update.
Pausing all threads (which works perfectly btw.) causes all threads to open in the source view, which is not that useful when the application has more than a couple of threads, because each source "tab" is only a few characters tall.
This will also change soon and codeclap will behave more expected. Panels will not open on a thread basis, provide tab support and the ability to reorder more freely.