Yeah, it’s a bit weird haha. You can also add specific functions, e.g. adding “-testpkg.f2”, so you don’t have to treat the entire module as interpreted. edit: upon further testing, this doesn’t seem to work as expected…
I’m also sometimes facing an issue that breakpoints persist after removing them. But if you remove them by unticking the breakpoint here:
This runs so much faster in your example. For me it does not work. Still extremely slow. I added ALL_MODULES_EXCEPT_MAIN and did “Apply default compiled modules/functions”.
How is it even possible that it differs from user to user? I am using a very powerful pc that blasts through other applications easily…
Each time I click on Run Debug (F5) I can go get a coffee until it even stops at a debug point placed in the first line.
When run as a script, you are working with global variables which will be slower. If you put the bulk of your computation inside a function (like p_f did), so you are instead working with local variables, you should see a speed improvement.
Note that to debug after doing this you will either click “Run Debug” on a file which contains the line myplottingfunc() or type @enter myplottingfunc() into the REPL. (You start debugging at the call site not at the function definition.)
I remember using Borland’s languages complete with IDE and debugger to code C/C++, Pascal, and Delphi which compiled to exe files. I could set a break point by clicking on a line in the editor and see the values of variables that I’d selected or add some to monitor. I could even set conditional breakpoints. There was little need to create a subset of data to keep the compiler/debugger working at an acceptable speed.
Yes, that was nice, but they are also prohibitive expensive. Writing good debuggers is something difficult to find open source programmers for who do it in their spare time.
Visual Studio is free and does just that. But apparently, the Julia internals make it difficult to create efficient debuggers.
Not true. Visual studio code provides a framework for an IDE, it does not provide any debugger. You still need a language specific debugger, and a plugin that provides a GUI for this language specific debugger. These have been written for old languages like C++ by companies with big pockets, but not so much time and money was yet invested into the Julia specific components yet.
By the way, Visual Studio is not free at all.
Yes, it is free. I use it a lot.
Free for non-commercial use ≠ Free
99 EUR per month for the cheapest license, still cheaper than Borland Delphi, which starts at 2000 EUR for one year, in both cases comparing the professional license.
The VS code license says:
An unlimited number of users within an organization can use Visual Studio Community for the following scenarios: in a classroom learning environment, for academic research, or for contributing to open source projects.
OK, if that makes you happy.
Yes, I find it import that people understand that someone has to invest time and effort in creating a good IDE or IDE plugin and a good debugger. If we find 500 people who want to pay 1000 EUR for a good Julia debugger with good IDE integration I would try to make it happen. If not I try to contribute to the open source development in my spare time.
Language semantics and usage allowed functions to be compiled in advance, albeit bogged down by debug information. Even with metaprogramming and generics, if you’re debugging an executable then you have the guarantee that you compiled whatever you needed. Like other interactive languages, Julia lacks those nice guarantees and relies on skipping over optimized compiled code to offset the performance hits of interpretation.
It’s also worth pointing out Julia’s relative youth. Prior to v1 stabilizing the language, developing a debugger would be a temporary experiment at best. By that time, MATLAB’s debugger was already mature, and that’s coming from someone who had many gripes with it.
It can be equally true for a debugger to be easily accessible AND its developers be backed by a business, I think we can agree to agree on the facts, if not semantics.
I have to admit that using the VSCode UI to launch the debugger is slow. However, when I use @enter function_to_debug(params), the debugger is very usable and sufficiently fast. I have sometimes to play with compiled modules but very rarely. I don’t know if it’s related to my workflow.
At some point, Borland started selling “Borland” versions of full featured compilers with IDE, GUI, etc. and “Turbo” that were less expensive and missing some of the features like a GUI designer. The Turbo versions, and in the earlier days the Borland versions, were very inexpensive because Borland had to compete with Microsoft. I bought Version 1.0 of Turbo Pascal for something like $19 or $39 dollars which I used to write statistical software that I sold in Byte and the Journal of the American Statistical Association.
When saw the first ad for Turbo Pascal, I called Borland and asked how they could make all these claims of doing a better job than Microsoft. I talked with Philippe Kahn, which shows how small they started. He said, “we know how to write compilers.”
