How to get Linting in VSCode for Julia - visual-studio-code

I think Julia is a great Language, but I find that there is a total lack of any error detection in VsCode.
Look at this code example:
I would expect that red squiggly lines show up in these places:
StructABCNotDefined is not a valid type
|> operator not defined for Integers
Should not be able to call fun with a String as an argument
fun does not return something of type StructABCNotDefined
Without proper type checking working it's a total mess like python only that it runs a bit faster. What am I doing wrong? Is it possible to setup VsCode to have these type checking abilities for Julia?

The Julia VSCode extension highlights at least some of your issues.
Note that linting is only active when the Julia file is inside a workspace (see https://github.com/julia-vscode/julia-vscode/issues/1105).
With JET.jl more issues can be identified:
julia> #report_call fun(5)
═════ 2 possible errors found ═════
┌ # c:\Users\d90394\Downloads\Untitled-1.jl:2 NonExistingStruct
│ `Main.NonExistingStruct` is not defined
└─────────────────────────────────────────────
┌ # c:\Users\d90394\Downloads\Untitled-1.jl:2 n |> 2
│┌ # operators.jl:911 f(x)
││ no matching method found `(::Int64)(::Int64)`: f::Int64(x::Int64)
│└────────────────────

Related

VSCode peek variable declaration for unsupported languages

Is it possible in VSCode to peek the declaration (or first mention) of a certain variable in unsupported languages?
I work a lot with Matlab, and in long scripts it would be helpful if I could have a little peek window (as in e.g. C, Python) to see the first definition of the variable. Of course this variable could have been changed in the script (and without proper symbols there is probably not really a way to detect this), but let's assume that it isn't.
To illustrate what I mean with a Python example:

Emacs Typescript error line format output - User defined option?

We've started using TypeScript along with Emacs as thats our editor of choice.
One issue we have found is that the TypeScript error line format doesn't appear to be compatible with the Emacs compilation mode error handling.
e.g.
If we compile a C program and introduce a deliberate error we get
t1.c:6:5: error: use of undeclared identifier 'a'
If we do the same for the TypeScript compiler we get (ignore the message, its the format thats important)
utilities.ts(13,18): error TS2384: Overload signatures must all be ambient or non-ambient.
Emacs can handle the first type of error message using the key command ESC-g n and will move the main editor window to the error.
Emacs cannot handle the second error line format.
We have hacked together a workaround by wrapping the TypeScript compiler in a Perl script and got the Perl script to reformat the lines appropriately. This works but is a bit of kludge and it would be nice if TypeScript had a little more flexibility.
We were wondering if there is a flag or some way to change the Typescript error output to a format that is compatible with Emacs.
The t1.c:6:5: ... format is actually the official format documented in the GNU Coding Standards, so I think you should contact the authors of the Typescript compiler and ask them to change the format of their error messages.
In the mean time, you'll want to tweak compilation-error-regexp-alist to explain to compile.el how to recognize Typescript's error messages.
Probably something like
(eval-after-load 'compile
(add-to-list 'compilation-error-regexp-alist
'("^\\([^(\n]+\\)(\\([0-9]+\\),\\([0-9]+\\)):" 1 2 3)))
might get you started. If some of the messages are not actual errors but more like warnings or side-information, you can refine the above. See C-h v compilation-error-regexp-alist RET for details of the format.
You can also turn off the pretty mode by running something like tsc --pretty false app.ts and then emacs compile mode will start to recognize the error output.

How to make Merlin (OCaml) ignore some lines?

I use Merlin with Emacs to edit OCaml code. It normally works perfectly fine, but I wound the following problem:
I'm need to use a package, built by someone else, that adds to OCaml some keywords not native to the language. Since I use the package to compile the code, compilation works great. On the other hand Merlin goes crazy and thinks that the new keywords are an error. Luckily the new keywords only appear at the beginning of a line, so my code looks something like this:
let square x = x * x;;
let rec fact x =
if x <= 1 then 1 else x * fact (x - 1);;
FOO "This syntax is not standard Ocaml" square fact;;
Where FOO is the new keyword. Merlin will complain and say Unbound constructor FOO. So the question is, can I make Marlin ignore that line? OR can you think of a hack to wrap the syntax in something Merlin won't complain about?
Merlin doesn't and will not (afaik) support arbitrary syntax extensions, but they do have parsing hacks for most commonly used camlp4 extensions like pa_lwt, pa_macro, etc. Also newest merlin versions will skip unknown lines and recover parsing, so that 'go-to-definition' and type throwback work on other parts of the file not modified by syntax extensions.
An alternative, although quite different, but that offers a subset of the functionalities of Merlin (completion and documentation from libraries, navigating around files), is ocp-index.
Ocp-index doesn't interpret or type your current file (it only scans it for opens and the like), so it won't be troubled by arbitrary extensions.

In a function show passed arguments in a different color [duplicate]

In Emacs, is it possible to mark all variables of different data types with different colors? e.g. if I have the following variables in C/C++ my program
int i,j;
float g,h;
char a,b;
Then throughout the source code i and j would be marked as red, g and h as green, a and b as blue.
I am not sure how useful this will be in future, but I feel it would help me while reading code,
and be a good alternative to the Hungarian notation(not that I use this notation :D).
No. Emacs has no idea about the type of a specific expression; doing this would be tantamount to writing a significant part of a C compiler in ELisp.
However, there is a light at the end of the tunnel.
E.g., if you edit OCaml code using tuareg-mode, you can ask Emacs about the type of any expression because the ocaml compiler provides that information; thus you should be able to ask it to highlight variables by type. This is the path to follow.
Alas, gcc does not provide that information; however, its extensiongccxml does.
Also, other C compilers, e.g., clang, provide that information out of the box, and there is a new file semantic-clang.el which relies on those features (although for completion only, not for syntax highlighting).
So, nothing out of the box for you here, but if you are willing to use clang instead of gcc and contribute to the CEDET development, you might get what you want.
No, it's not possible to selectively assign a given color to a given variable in emacs (or just for one given program).
However, if it's just syntax highlighting you are looking for, of course, emacs will highlight most languages, and you can even create syntax highlighting for languages emacs would not know about.
Ex. Smali: https://github.com/strazzere/Emacs-Smali

How can I reference #defines in a C file from python?

I have a C file that has a bunch of #defines for bits that I'd like to reference from python. There's enough of them that I'd rather not copy them into my python code, instead is there an accepted method to reference them directly from python?
Note: I know I can just open the header file and parse it, that would be simple, but if there's a more pythonic way, I'd like to use it.
Edit:
These are very simple #defines that define the meanings of bits in a mask, for example:
#define FOO_A 0x3
#define FOO_B 0x5
Running under the assumption that the C .h file contains only #defines (and therefore has nothing external to link against), then the following would work with swig 2.0 (http://www.swig.org/) and python 2.7 (tested). Suppose the file containing just defines is named just_defines.h as above:
#define FOO_A 0x3
#define FOO_B 0x5
Then:
swig -python -module just just_defines.h ## generates just_defines.py and just_defines_wrap.c
gcc -c -fpic just_defines_wrap.c -I/usr/include/python2.7 -I. ## creates just_defines_wrap.o
gcc -shared just_defines_wrap.o -o _just.so ## create _just.so, goes with just_defines.py
Usage:
$ python
Python 2.7.3 (default, Aug 1 2012, 05:16:07)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import just
>>> dir(just)
['FOO_A', 'FOO_B', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '_just', '_newclass', '_object', '_swig_getattr', '_swig_property', '_swig_repr', '_swig_setattr', '_swig_setattr_nondynamic']
>>> just.FOO_A
3
>>> just.FOO_B
5
>>>
If the .h file also contains entry points, then you need to link against some library (or more) to resolve those entry points. That makes the solution a little more complicated since you may have to hunt down the correct libs. But for a "just defines case" you don't have to worry about this.
You might have some luck with the h2py.py script found in the Tools/scripts directory of the Python source tarball. While it can't handle complex preprocessor macros, it might be sufficient for your needs.
Here is a description of the functionality from the top of the script:
Read #define's and translate to Python code.
Handle #include statements.
Handle #define macros with one argument.
Anything that isn't recognized or doesn't translate into valid
Python is ignored.
Without filename arguments, acts as a filter.
If one or more filenames are given, output is written to corresponding
filenames in the local directory, translated to all uppercase, with
the extension replaced by ".py".
By passing one or more options of the form "-i regular_expression"
you can specify additional strings to be ignored. This is useful
e.g. to ignore casts to u_long: simply specify "-i '(u_long)'".
#defines are macros, that have no meaning whatsoever outside of your C compiler's preprocessor. As such, they are the bane of multi-language programmers everywhere. (For example, see this Ada question: Setting the license for modules in the linux kernel from two weeks ago).
Short of running your source code through the C-preprocessor, there really is no good way to deal with them. I typically just figure out what they evalutate to (in complex cases, often there's no better way to do this than to actually compile and run the damn code!), and hard-code that value into my program.
The (well one of the) annoying parts is that the C preprocessor is considered by C coders to be a very simple little thing that they often use without even giving a second thought to. As a result, they tend to be shocked that it causes big problems for interoperability, while we can deal with most other problems C throws at us fairly easily.
In the simple case shown above, by far the easiest way to handle it would be to encode the same two values in constants in your python program somewhere. If keeping up with changes is a big deal, it probably wouldn't be too much trouble to write a Python program to parse those values out of the file. However, you'd have to realise that your C code would only re-evaluate those values on a compile, while your python program would do it whenever it runs (and thus should probably only be run when the C code is also compiled).
If you're writing an extension module, use http://docs.python.org/3/c-api/module.html#PyModule_AddIntMacro
I had almost exactly this same problem so wrote a Python script to parse the C file. It's intended to be renamed to match your c file (but with .py instead of .h) and imported as a Python module.
Code: https://gist.github.com/camlee/3bf869a5bf39ac5954fdaabbe6a3f437
Example:
configuration.h
#define VERBOSE 3
#define DEBUG 1
#ifdef DEBUG
#define DEBUG_FILE "debug.log"
#else
#define NOT_DEBUGGING 1
#endif
Using from Python:
>>> import configuration
>>> print("The verbosity level is %s" % configuration.VERBOSE)
The verbosity level is 3
>>> configuration.DEBUG_FILE
'"debug.log"'
>>> configuration.NOT_DEBUGGING is None
True