Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 14 00:28
    halirutan commented #151
  • Feb 14 00:23
    halirutan commented #151
  • Feb 13 11:30
    halirutan commented #151
  • Feb 13 11:09
    szhorvat commented #151
  • Feb 13 11:08
    szhorvat commented #151
  • Feb 13 10:57
    halirutan commented #151
  • Feb 13 09:02
    szhorvat edited #151
  • Feb 13 08:45
    szhorvat assigned #151
  • Feb 13 08:45
    szhorvat opened #151
  • Feb 08 19:53
    lynchs61 commented #150
  • Feb 08 19:33
    szhorvat commented #150
  • Feb 08 18:30
    halirutan commented #150
  • Feb 07 14:16
    GiovanniBordiga closed #149
  • Feb 07 09:30
    GiovanniBordiga commented #149
  • Feb 07 09:12
    halirutan commented #149
  • Feb 06 22:46
    lynchs61 opened #150
  • Feb 06 07:36
    GiovanniBordiga commented #149
  • Feb 06 01:13
    halirutan commented #149
  • Feb 05 16:55
    GiovanniBordiga edited #149
  • Feb 05 16:55
    GiovanniBordiga assigned #149
Szabolcs Horvát
@szhorvat
Personally, I find debugging in Mathematica convenient.
Oftentime, all that’s needed is clicking the message menu and choosing “Show stack trace"
What an IDE like Workbench or IntelliJ could provide would be a better association between break locations in the code, and source file lines. This would indeed be a small convenience
Unfortunately, the inner workings of the debugger are not documented
It would need to be reverse engineered before it could be integrated into IntelliJ
Szabolcs Horvát
@szhorvat
In my personal opinion, that is not worth the effort (there’s stuff that could be added to the plugin that is more practicall useful and much less work to implement)
@jportway Can you read the post I linked, give that workflow a try, then let us know what exactly is painful about the debugging process?
Patrick Scheibe
@halirutan
@jportway To give a somewhat more detailed explanation, we would need to break the tasks apart and ask why the plugin doesn't support
  • running packages from within the IDE
  • debugging code with break points
  • having a REPL where you evaluate code
Patrick Scheibe
@halirutan
For the last point, the simple reason is that Wolfram code relies so much on the front end. Formatted expressions, images, graphics, graphs, dynamics, and nowadays all the fancy rendering of entities, neural networks, interpolation functions, and whatnot rely on the Mathematica front end. For instance, the whole Manipulate/Dynamic stuff happens entirely in the front end and its implementation is hidden. So while I could implement a simple REPL that lets you put ASCII commands in and returns ASCII output, that wouldn't be helpful to most people. There are so many issues that cannot be solved easily that I don't even know where to start:
Patrick Scheibe
@halirutan
  • while it would (and is) possible to support some of Mathematica's special characters like \[Alpha], many of their symbols are specifically designed for Mathematica and not publicly available UTF characters
  • displaying a 3D graphics for instance would require re-implementing all graphical primitives so that they can be displayed as e.g. OpenGL 3D graphics. But e.g. the placement and calculation of correct axes and ticks is hidden and one would need to reverse-engineer it
  • the fancy display of graphs or all the dynamic content that is used to show e.g. the progress of NetTrain cannot be replicated without basically re-implementing everything the front-end does
I am very skeptic how useful a REPL with simple text-output would be and this is one reason why I haven't worked on this.
Patrick Scheibe
@halirutan
"Running a package" from the IDE means to me that you can click a button and the package is loaded in Mathematica where you can test it. However, the way the Wolfram Workbench does this is not documented. In the past, I spent some time digging for a good solution and I believe I might have found a way that makes communication of IDEA with a running Mathematica possible, but atm it is just not worth the effort. There are too many things that still wouldn't work. For instance what about "building documentation". This has been a pain for years as many who tried to build docs for their packages can assure you. Especially documentation that works in several different Mathematica versions seems to be a pain.
Patrick Scheibe
@halirutan
Debugging Wolfram code like you would do it in C, Java, ... is a whole different beast. The notion of "a line of code that contains an instruction you can stop at" just doesn't exist. Mathematica evaluates expressions over and over again until it doesn't change any more. Furthermore, Wolfram never bothered to provide a good and documented way of inserting debugging information (like line-numbers) into code that can later be used to break at this point. This, however, is exactly what the Mathematica does internally when you debug code in the front end. It is the reason, why you need to turn on debugging before you evaluate the functions you want to debug. Mathematica tags all occurring expressions. If you are curious, you can use the LinkSnooper where you can see the communication between the front end and the kernel, turn on debugging and define a simple function.
What you see is that the expressions that are sent to the kernel for evaluation look like this (for f[x_] := x^2):
BoxData[RowBox[{TagBox[RowBox[{"f", "[", "x_", "]"}], DebugTag[87393]], ":=", TagBox[RowBox[{"x", "^", "2"}], DebugTag[87409]]}]]
This is why the debugger feels so weird when you come from a different language and you have to break at "expressions" rather than lines. The notion lines is lost.
I don't need to say that none of how the debugger really works is documented except in posts like the one Szabolcs linked to.
Patrick Scheibe
@halirutan
There is no way I can implement this without decompiling code of the Workbench which of course would not only mean an awful lot of work on my end, but it also would break a thousand laws.
And believe me, I have tried to ask for the Workbench code with what I think good arguments.
Szabolcs Horvát
@szhorvat

@jportway

There are two issues:

  • Some things are difficult to implement (a few may be possible though)
  • Some things don’t really seem that useful in practice. I think most people ask for them because they come from another language and are used to the workflow of that language (which may be suboptimal for Mathematica)>

Overall, I think it would be useful to get feedback from users like you not only about what they want, but also why they want it.

This is why I asked for more details on why you find debugging painful.
However, to be realistic, debugging would be prohibitively difficult to implement without documentation ...
The other two things were:
  • REPL. I don’t see how this is useful in practice.
  • "Run package.” The the Workbench this just auto-loads the package in a notebook. I can do that manually by evaluating a single cell, so I don’t see any value in it.
That said, I am sure that there are multiple use cases that I did not think of or that never come up for me personally but may come up for you.
That’s why I asked for more information.
Szabolcs Horvát
@szhorvat
@halirutan OCD request: can you add spaces before the | in this window?
image.png
Patrick Scheibe
@halirutan
@szhorvat Hehe.. sure.
Szabolcs Horvát
@szhorvat
Not sure why this is highlighted as unused ...
image.png
Will try to make minimal example later
Patrick Scheibe
@halirutan
@szhorvat Without looking, I can guess the problem: It's inside the definition list (although it's from a different construct).
Please open an issue for that.
Kuba Podkalicki
@kubaPod
@halirutan is it true that the best structure for a github wiki files is a flat list of files? I am trying to link to subdirectories but then it won't open the file within the wiki but as a separate page
Patrick Scheibe
@halirutan
@kubaPod Hmm, are you using normal markdown links or media-wiki link style like [[/images/path/to/image.ext|ALT TEXT]]?
Also, there might be a difference if you use absolute URLs like https://github...
Kuba Podkalicki
@kubaPod
@halirutan I forgot to mention that I am talking about .md content and creating a sidebar from it
[[nested/path]] does not work and direct links open in a new tab
Patrick Scheibe
@halirutan
@kubaPod Well, this is odd because it worked for me. I reworked the side-bar for the JabRef project some time ago.
I'm not sure we had nested content but the links to internal md pages definitely open in the same tab for me.
Kuba Podkalicki
@kubaPod
@halirutan there is a flat list of .md files
I want to keep'em organized in a nested directory structure
Files, not the sidebar content (yet).
Patrick Scheibe
@halirutan
Hmm, that that maybe a good question for SO?
I don't know without trying.
Kuba Podkalicki
@kubaPod
I was surprised how hard it is to find a manual about _Sidebar syntax
Patrick Scheibe
@halirutan
Yep, took me also a while back then.
Kuba Podkalicki
@kubaPod
I think the answer is, you can't keep them in nested dirs if you want links to work well, because something about gollum
Gerli
@gerli
I'm not sure if I'm doing something wrong or there's a bug here (I only just discovered the proper module structure set-up in order for cross-module linking to work)... I have a project with two modules, module B is dependent on module A. Module A uses the same context (MyContext) in two different files MyContextComputation.m and MyContextObject.m. They both have a public section where they declare the usage messages of functions defined in those files. In Module B, functions defined in MyContextComputation.m correctly get underlined as coming from a different file but the functions defined in MyContextObject.m get a wriggly line with "Could not resolve symbol definition". I think the way I have it structured is not entirely unusual (although I don't know if having non-private contexts in multiple files is standard or not). Is this a known limitation, anything else I should try to tickle some indexing or similar?