For my part I sometimes use gdb to get error stack trace through when compiling/building native ocaml. However, setting breakpoints and/or displaying variable values is not intuitive or well supported it seems. I have seen a few PRs regarding making native ocaml debugging more palatable and user-friendly however not sure when they are going to released.
For the most part I currently use ‘printf’ debugging but it becomes quite tedious since I have to remove the printf when I am finally done debugging and re-add them when I want to debug again. Is there a better approach?
I usually switch to bytecode and use ocamldebug. However this does not always work, as sometimes the bytecode, especially running with the debugger, is so slow. The forward/backward stepping of ocamldebug is great. One thing I have been wanting is a way to drop into a UTop session at a specified point in a program, in order to do interactive inspection including evaluating expressions (which the debugger cannot do).
I also used to use ocamldebug + Emacs, which was quite nice. But after some point it does not show the correct location of execution, so I stop using it and fell back to printf debug
This may have to do with the directory setup for ocamldebug. I found I need to explicitly dig out all directories of the relevant .cmi files within my .opam subdirectories, for all libraries that I want to be able to trace execution in. I then listed these as #directory directives in .ocamldebug.
found I need to explicitly dig out all directories of the relevant .cmi files within my .opam subdirectories, for all libraries that I want to be able to trace execution in. I then listed these as #directory directives in .ocamldebug.
Yeah, I know. But for my case, ocamldebug shows the funny place within a file.
My problem occurs several years ago so it may be already solved, however.
Feel free to open issue reports if (the most recent version of) ocamldebug is not behaving correctly.
Note that there is a chronic lack of people interested in helping maintain and improve ocamldebug; the Coq people are heavy users of it, and they have bugreports and feature requests, but we currently lack the manpower to address some of them. If someone around is an ocamldebug user, and would be willing to invest some effort into looking at the codebase and contributing to it (for example, there is a patchset from whitequark that implements debugging of dynlinked code, but I haven’t been able to find a motivated reviewer yet), that could be very helpful.
I just found http://mshinwell.github.io/libmonda/ but haven’t tried it yet. Not sure if it is up-to-date with regards to 4.05/4.06. This would be very useful tool to have in 4.07 since gdb is quite powerful.
This was before github, so the patch is on Mantis in MPR#6792. The patch was against 4.02, so we would first need someone to port it to a more recent OCaml version (4.05 or 4.06), and to test the result. Unfortunately porting is not trivial because there were other related changes to the runtime in between (some features of the patch are subsumed by work that went into making backtraces work well, if I remember correctly). Once we have got a working patch on a recent OCaml version, we can ask the Coq people to test it and, if it works for them, propose it for upstream inclusion.
This is not easy work, but it would be very helpful to various people.
There is another GPR(https://github.com/ocaml/ocaml/pull/574) which if merged would make a lot of ocamlers happy when debugging. Could we vote - if such a mechanism exists in ocaml - for this feature to be included in 4.07 perhaps.
The best way to vote is to contribute to the PR, either by the actual code or, at least, by reviewing and testing. These are not just empty words, that you may have heard lots of time. When you actually become involved in this PR, you may notice that the developer became much more motivated. It is very dull to develop something, about which nobody cares. So vote by your active involvement. Make a fuss about it, and it will get into the trunk soon.
I generally approve of this message as long as we understand “fuss” as a productive behavior where you make development easier (by reviewing and testing, for example), rather than just noise, which doesn’t necessarily help.
You can vote for whatever you like, but it’s not going to change the man power available to work on OCaml.
True. I was thinking more in terms of motivating the current available man power. The logic being that people who are capable will be (more?) motivated to implement features if they knew/know that the feature is desired/wanted by the community.
When you actually become involved in this PR, you may notice that the developer became much more motivated. It is very dull to develop something, about which nobody cares
Indeed, that has been my experience in my day job too. I am more motivated if the users of our software ask/complain about features, functionalities.
Really? I tend to find those kinds of comments irritating and borderline insulting. Active useful involvement (e.g. helping to review things) is encouraging. Comments describing a specific use case you have for the feature, or an additional bug report that would be addressed by it, can be encouraging. Comments that just say “I want this. Can we get it in the next version?” or “When will this be ready?” just sound to me as “You’re not doing enough free work for me – I demand more of your free time so that this is finished sooner”
With my tongue firmly out of cheek, it is best to not post such style of links from this forum to the OCaml bug tracker.
The PR referenced is complex and multiple years of effort. What would be most useful is to:
read through the last known status posted by the author and attempt to reproduce it. For example, does the Dockerfile that @kayceesrk posted still work with your intended use?
describe your desired usecase clearly, and make an effort to relate it to the last known status. For instance, what do you need “dynload debugging” for, and could you make do without it (e.g. by statically linking the program for development purposes).
Contributing some effort such as the above will help you earn the “we” in “if not could we prioritise this for 4.07 please”.
More generally, this discussion forum is intended as a distillation area for broad-sweeping discussions, from beginner learning to community efforts to design discussions for mutual learning amongst ourselves.
Once a conclusion has been reached regarding something that is concretely actionable in the core OCaml toolchain, it should be posted in a standalone way to the OCaml bug tracker, rather than links to this forum just posted verbatim. I did not intend this forum to become an area for “mob fuss” to add noise to complex language PRs, and would appreciate all of your help in maintaining this ethos and ensuring it remains a constructive force in the OCaml community.
with tongue in cheek … just posted another “fuss” in that GPR. heh!