Message Boards Message Boards

6
|
17563 Views
|
12 Replies
|
36 Total Likes
View groups...
Share
Share this post:

Is there a real debugger in Mathematica?

Posted 10 years ago

To my surprise I realized Mathematica doesn't have a proper debugger -> I can write only toy small programs without an easy way to debug the code

I searched The internet and I found Workbench tool ....which is not free !!! How am I supposed to use the tool in the first place if I cannot develop any decent size program? Is this a bad joke ?

POSTED BY: bogd timo
12 Replies

I just watched the video about simple debugging in Workbench. Something similar would do nicely for Mathematica.

The video uses examples from Mathematica 7, so it is pretty old. I would hope that new videos for Workbench 3 will be prepared. Perhaps as part of this project, videos about debugging in general would be done.

Incorporating the example and tips from this discussion, plus tips from others who are expert in debugging using the tools in Workbench and Mathematica would go a long way to getting the rest of us up to speed, and perhaps more people would use the debugger.

I find John's illustrative example and Szabolcs' tip to be instructive and perhaps enough to get me over the hurdle of trying to use the debugger instead of the expedient use of Print[].

I believe that learning the debugger is a case in which "watching an example" may be better than "reading the doc".

A 5-10 minute screencast of the debugger in action would likely benefit many users. I hope that someone who uses the debugger frequently might contribute one...

POSTED BY: W. Craig Carter
Posted 10 years ago

I inquired of tech support about this debugger some time ago, asking for a source of information on its use. The response I got was that they really intended Workbench for that purpose, and had no further information. This led me to believe it was an early idea and now abandoned, but with a vestigial remainder.

If anyone gets a better answer, I would really like to see it posted here.

POSTED BY: David Keith

The debugger in the front end does work. Yes, there are caveats...mostly that the interface is clunky to use. And it should absolutely never, ever used in an attempt to debug generated interfaces (which can compete with the debugger for the kernel's attention, thereby hanging the kernel). But it does work.

Rule #1: The debugger only "knows" about stuff that you evaluated while the debugger was turned on. If you want to walk into a function, you can only do so if that function definition was evaluated while the Evaluation->Debugger option was checked.

Rule #2: The debugger can only walk into code which was evaluated from an open notebook window. So, if you have code in a package, you can open it in the FE and click "Run Package", and so long as that window remains open, you should be able to walk into code in that package. But if you run Get[] on the file instead, the debugger will not be able to help you.

A simple example:

  • Turn the debugger on.
  • Paste the following code: Module[{x = {"Hello", "World"}}, StringJoin[Riffle[x, " "]]]
  • Highlight the Riffle expression, and set a breakpoint using Evaluation->Debugger Controls->Toggle Breakpoint
  • Run. Use the debugger window to open the Stack and Breakpoints windows if they're not already open, and experiment.

Using message breakpoints (controlled from the breakpoints window) can be very useful to track down a message from an unknown source.

POSTED BY: John Fultz

Thanks for the clarification.

I can understand the caveat about debugging generated (graphical) interfaces, but in my experience (not just with Mathematica), debugging the UI is one of the most useful functions of a debugger.

What does Wolfram use internally to debug interfaces? Is is something that you could make available to an advanced mathematica user -- similar to the Workbench? (If I recall correctly, the debugger in Workbench is a bit more robust, and it may have this functionality already.)

I'm not personally a Workbench user, but I do believe that some use it for this purpose.

But most of the time, the code in the interface splits cleanly into code that's managing the interface, and code that's taking inputs from the interface and doing work. The code that's managing the interface doesn't, in my experience, really require much in the way of debugging...the entire experience is already very usefully visual, with hints such as the pink boxes to help you when something is throwing error states internally. As for the remainder of the code, I'm always testing/debugging it outside of the interface first.

I.e., if I'm writing a significant body of code that's going to live inside of a Dynamic, then I'm debugging/testing it outside of the Dynamic first, and I'm writing it in such a way to make that very easy to do. For example, I often see bug reports or complaints that such-and-such doesn't work in a Manipulate. The very first thing I do is to strip the Manipulate off, and see if it works without the Manipulate. And you know what? About 90% of the time, that's where I find the problem.

This leaves one legitimate area of development not very well covered, though, and that's highly responsive UIs. I.e., UIs that shift and change in significant ways in response to how you use them. Perhaps you might find Workbench useful in such areas. I find other means (a combination of LinkSnooper, Assert, various forms of printing/logging, etc.).

POSTED BY: John Fultz

The debugger has a bad reputation that it does not deserve. I use it occasionally and find it very useful. The reason I don't use it a lot is that other debugging techniques can be quite effective in Mathematica, so there's less need for it.

I think the biggest difficulty is that, as John Fultz mentioned, breakpoints only work with code evaluated from an open notebook window. As far as I can tell, this applies only to breakpoints set using the debugger palette though, not other features of the debugger.

In Mathematica there's no direct connection between source files and running code, as in many other languages. Instead definitions exist in memory and can be dynamically modified. This conflicts with the traditional concept of breakpoints, as breakpoints are set in the source file. It's very easy to mess up the connection between the source code typed in a notebook (where the breakpoint is set) and the actual in-memory definition.

The solution I use is to insert the "breakpoints" directly in the definition in the form of failing assertions (e.g. Assert[False]) and set "Break at Asserts" in the debugger. When only using this method of "breaking" evaluation, the debugger is a robust and very useful tool. It can show the stack and lets me look at the values of local variables.

POSTED BY: Szabolcs Horvát

Thanks for pointing this out. I completely missed it.

I'll check it out. While it looks to be a bit spare compared to other modern debuggers, it should meet a need.

It might be nice if Wolfram Research provided a seminar about this, and other more advanced functions for programmers.

Posted 10 years ago

While I haven't used it, under the Evaluation menu for both Mathematica 9 and 10 (and maybe earlier versions) there is the menu item "Debugger". There isn't much in the documentation on this but what features is it missing that keeps it from being a "true debugger" ?

POSTED BY: Jim Baldwin

I have Workbench but have never used its debugging facilities. The one thing I learned from Workbench, using the Workbench editor, is that I tend to have many routines built on Modules that contain local variables that are never used! Of course, they were once used, or intended to be used. I found the same thing looking at another person's extensive code.

The way I develop is to write and evaluate a routine incrementally looking at intermediate output to make certain it's what I was expecting. I also use Print statements, which I later comment out or delete. This always seems to solve any problems.

I also don't think of Mathematica so much as a programming language or what I do as programming. I think of it more as writing definitions of mathematical objects or actions and writing specifications for graphics and dynamic displays. It is the displays that usually involve the longest code. But again incremental development with evaluation and an occasional Print statement always does the job. I don't think I ever have a routine that goes over one screen. These are not toy applications. They do quite a lot, principally because the Mathematica routines, especially the procedural constructs, do quite a lot.

I thought the more advanced debuggers were for large projects involving lower level code such as C++. It would be interesting to know what kind of project you are undertaking that can't be broken into smaller individually developed and tested routines. What is missing might not be as incrementally useful as you envision.

There is new unit testing functionality in Mathematica 10. I have not used it yet, but I plan to.

For Mathematica, I pretty much follow David Park's method of gradually building up functionality. It works very well, and if done properly, reduces or eliminates the need for a low level debugger.

When I started programming, there were no debuggers, at least not in the modern sense. I learned my craft in a way that is not that much different from the way I create Wolfram Language code. It also works well for languages like objective c or ANSI c. Most of the time when I 'needed' a debugger was where I had been sloppy in my coding.

I had a major c project involving thousands of pages of code. It works -- it is a real-time app that is up 24/7 and never crashes. I could rewrite the app using Wolfram language using a hundred pages of code, and I don't think I would need to use a low level debugger at all.

I think that the main point for you would be that Wolfram Language is not like c, c++, FORTRAN, or [insert favorite language here]. If you approach Mathematica the way that you treat these other languages, you will be fighting against the Wolfram Language, not using it to its full potential.

You can use Mathematica as a super graphical calculator and never run into these issues, but you can do so much more if you can undergo a paradigm shift. You may find, as I did, that your coding in c, etc. is improved from this new viewpoint.

You get quite far with Print and Dialog[] statements put into your code.

You could also try this code. Workbench is free if you have Premier Service.

You could also try to use the excellent IntelliJ plugin

But yes, a true debugger and profiler, usable from with the Front End, would be most welcomed. Too bad Wolfram Research seems to be not so much developer oriented anymore as it once was.

POSTED BY: Rolf Mertig
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract