Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 16 21:59
    halirutan closed #148
  • Jan 16 21:59
    halirutan commented #148
  • Jan 16 17:22
    mgroth0 edited #148
  • Jan 16 17:22
    mgroth0 assigned #148
  • Jan 16 17:22
    mgroth0 opened #148
  • Dec 28 2019 22:09
    MrHirenP edited #147
  • Dec 28 2019 22:06
    MrHirenP edited #147
  • Dec 28 2019 22:06
    MrHirenP assigned #147
  • Dec 28 2019 22:06
    MrHirenP opened #147
  • Dec 27 2019 20:25
    halirutan labeled #146
  • Dec 27 2019 20:25
    halirutan commented #146
  • Dec 27 2019 14:12
    GalAster assigned #146
  • Dec 27 2019 14:12
    GalAster opened #146
  • Dec 25 2019 16:47
    edwardtao closed #145
  • Dec 25 2019 16:47
    edwardtao edited #145
  • Dec 25 2019 15:57
    edwardtao assigned #145
  • Dec 25 2019 15:57
    edwardtao opened #145
  • Dec 03 2019 15:30
    halirutan closed #143
  • Dec 03 2019 15:30
    halirutan commented #143
  • Dec 03 2019 13:05
    halirutan commented #143
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?
Gerli
@gerli
Sorry, the other way around -- it's detecting the functions from MyContextObject.m (so the file that is later in alphabetical ordering) but not from MyContextComputation.m
Gerli
@gerli
And in a different project that I have, I also have the same context used across multiple files and I'm using the same private symbol in multiple files (defined in one and used in many) -- is there any way to get the correct linking working here at all?
Gerli
@gerli
I found an answer to that last question myself -- it works if I add a usage message to the private function (easy enough to do and makes sense)
Gerli
@gerli
And I figured out the first question too -- the two different files thing is a red herring. In the MyContextComputation file I don't have explicit symbol::usage = ... settings, I've factored it out into a addUsageMessage[symbol, "substring used in a template"] because I have quite many very similarly structured functions and I wanted a nice long usage message for all of them. And I guess the linking relies of this symbol::usage = ... line, yes?
Patrick Scheibe
@halirutan
@gerli To give some context: It's not possible to do correct resolving of symbols because for that, one would need to evaluate the code. Only when the kernel runs the code, we can be certain which symbols resolves to which definition. This is not possible in the IDE and we need to make crude assumptions to get a practical solution. Even getting the context of a symbol right is tricky at best and impossible in other cases.
What the plugin does is looking for symbol::usage = as you have correctly determined. This leads to the following things
  1. You need to give a symbol a usage message if you want it to be found in a different file
  2. Since I'm not checking the context where a symbol lives, you can also give private symbols a usage message and it will be found in a different package. So you have to be careful to import the correct context.
  3. If you have symbols that don't do anything (think of Node or Leaf in a tree) and IDEA warns you that it doesn't find a "definition", you can simply give it a usage message to make it resolve (which is both good programming style and informative for people reading your code)
Gerli
@gerli
Makes sense, thanks for the clarification!
Gerli
@gerli

Whether I defined this with or without full context in knownSymbols.m, it’s not recognized when written with full context in MATLink.m

This is from a discussion in October. I'm stumbling on this same issue -- symbols that I reference with their full context (usually because of pulling in symbols from a private context of some file) don't get the linking, even if I add a usage message explicitly with the full context. Should I create a bug report for it?

Patrick Scheibe
@halirutan
@gerli No need for a bug-report, because I'm aware of this and unfortunately, it's exactly where reality hits the hardest. To be specific: If you enter Foo`bar`fun[3] then of course the plugin knows that you mean fun in the context Foo`bar` . However, at the position where you defined fun[x_]:=.. inside your package, I would need to evaluate the whole code to find that when the symbol fun is put into the symbol-table, it is put into the context Foo`bar` .
Also, the new style package format makes this entirely hidden from the user and the rules what is done to $Context and $ContextPath during loading of a file changed with the Mathematica version.
Patrick Scheibe
@halirutan
To give an unrealistic example, why it is required to really have a Mathematica Kernel that runs the code in order to know where a symbol lives look at this:
myContext = "C" <> ToString[1 + 1] <> "`";
Begin[myContext];
var = 3;
End[]
While this example is extreme and no one would do this in practice, we have similar things all over the place that might look innocent at first. Consider for instance the commonly used idiom
If[isMessageDefined, func::usage = "blub"]
which is often used at the top of packages. Evaluating the If and knowing that the usage message of func is defined makes all the difference between exporting a symbol from a package.
Patrick Scheibe
@halirutan
In conclusion, only by inspecting the code and not evaluating it, we will not be able to know exactly in which context a symbol lives and the plugin simply assumes that definitions are available with their name without looking at the contexts.
Gerli
@gerli
@halirutan sorry for the late reply but I mean that would you expect the current linking to work if you have the full context in the usage message definition, ie
Foo`bar`fun::usage = "fun does this"
Szabolcs Horvát
@szhorvat
Just updated to IDEA 2019.3, nice to see that the plugin had an immediately available update too!