Neovim LSP: pyright server does not dynamically regognize changes in sub folders - python-3.x

I setup Neovim LSP using the nvim-lspconfig and the lsp-installer where I also installed the pyright server.
Without any further configuration it worked out of the box. However when I have a class in a subfolder and add a new method, pyright does not recognize this method when I want to access it in a different file. When I restart neovim, or open and close the file, pyright suddenly recognizes the newly added method.
I also tried :LspRestart with no effect.
I tried to add some settings to the pyright server:
return {
settings = {
python = {
analysis = {
autoSearchPaths = true,
diagnosticMode = "workspace",
useLibraryCodeForTypes = true,
}
}
},
}
But this also had no effect.
:LspLog also does not show anything which could point to the issue:
[START][2022-07-15 11:11:05] LSP logging initiated
[WARN][2022-07-15 11:11:09] ...lsp/handlers.lua:109 "The language server pyright triggers a registerCapability handler despite dynamicRegistration set to false. Report upstream, this warning is harmless"
[WARN][2022-07-15 11:11:09] ...lsp/handlers.lua:456 "stubPath typings is not a valid directory."
[WARN][2022-07-15 11:11:20] ...lsp/handlers.lua:109 "The language server pyright triggers a registerCapability handler despite dynamicRegistration set to false. Report upstream, this warning is harmless"
I also could not find any setting regarding to this issue here which could solve this.
Since I am new to python, the way I import and structure classes might not be common and might be an issue which could cause this problem.
As a main entry point I have main.py in the root folder
All other source files are in a program/ folder which does not have a __init__.py
Inside program/ there are folders which each have a __init__.py file f.e. core/
core/__init__.py:
from .myClass import myClass
and in main.py I import it like this:
from subfolder.core import myClass
myClass.newMethod() # this is only recognized by lsp/pyright after the file is closed and reopen
Is the issue a bug in pyright (not likely I guess), a missing setting or my strange folder/import structure?

Can you try this: create (or modify) pyproject.toml, put it in the project root directory. Inside pyproject.toml, add the following lines:
[tool.pyright]
extraPaths = ["program/core" ,"program/directory_2", "program/directory_3"]
The idea is that you have to add the sub directories manually, which is really tedious but at least it works in my case.

Related

Win10: ASDF can't load system (ASDF_OUTPUT_TRANSLATION error)

Update 2
I think #faré is right, it's an output translation problem.
So I declared the evironment variable ASDF_OUTPUT_TRANSLATIONS and set it to E:/. Now (asdf:require-system "my-system") yields a different error: Uneven number of components in source to destination mapping: "E:/" which led me to this SO-topic.
Unfortunately, his solution doesn't work for me. So I tried the other answer and set ASDF_OUTPUT_TRANSLATIONS to (:output-translations (t "E:/")). Now I get yet another error:
Invalid source registry (:OUTPUT-TRANSLATIONS (T "E:/")).
One and only one of
:INHERIT-CONFIGURATION or
:IGNORE-INHERITED-CONFIGURATION
is required.
(will be skipped)
Original Posting
I have a simple system definition but can't get ASDF to load it.
(asdf-version 3.1.5, sbcl 1.3.12 (upgraded to 1.3.18 AMD64), slime 2.19, Windows 10)
What I have tried so far
Following the ASDF manual: "4.1 Configuring ASDF to find your systems"
There it says:
For Windows users, and starting with ASDF 3.1.5, start from your
%LOCALAPPDATA%, which is usually ~/AppData/Local/ (but you can ask in
a CMD.EXE terminal echo %LOCALAPPDATA% to make sure) and underneath
create a subpath config/common-lisp/source-registry.conf.d/
That's exactly what I did:
Echoing %LOCALAPPDATA% which evaluates to C:\Users\my-username\AppData\Local
Underneath I created the subfolders config\common-lisp\source-registry.conf.d\ (In total: C:\Users\my-username\AppData\Local\config\common-lisp\source-registry.conf.d\
The manual continues:
there create a file with any name of your choice but with the type conf, for instance 50-luser-lisp.conf; in this file, add the following line to tell ASDF to recursively scan all the subdirectories under /home/luser/lisp/ for .asd files: (:tree "/home/luser/lisp/")
That’s enough. You may replace /home/luser/lisp/ by wherever you want to install your source code.
In the source-registry.conf.d folder I created the file my.conf and put in it (:tree "C:/Users/my-username/my-systems/"). This folder contains a my-system.asd.
And here comes the weird part:
If I now type (asdf:require-system "my-system") in the REPL I get the following error:
Can't create directory C:\Users\my-username\AppData\Local\common-lisp\sbcl-1.3.12-win-x86\C\Users\my-username\my-systems\C:\
So the problem is not that ASDF doesn't find the file, it does -- but (whatever the reason) it tries to create a really weird subfolder hierarchy which ultimately fails because at the end it tries to create the folder C: but Windows doesn't allow foldernames containing a colon.
Another approach: (push path asdf:*central-registry*)
If I try
> (push #P"C:/Users/my-username/my-systems/" asdf:*central-registry*)
(#P"C:/Users/my-username/my-systems/"
#P"C:/Users/my-username/AppData/Roaming/quicklisp/quicklisp/")
> (asdf:require-system "my-system")
I get the exact same error.
I don't know what to do.
Update
Because of the nature of the weird path ASDF was trying to create I thought maybe I could bypass the problem by specifying a relative path instead of an absolute one.
So I tried
  (:tree "\\Users\\my-username\\my-systems")
in my conf file. Still the same error.
Ahem. It looks like an output-translations problem.
I don't have a Windows machine right now, but this all used to work last time I tried.
Can you setup some ad hoc output-translations for now that will make it work?

Unable to load so file from Java in Eclipse On Ubuntu

I have some code that tries to load a C library as follows :-
public ThreadAffinity() {
ctest = (CTest) Native.loadLibrary("ctest", CTest.class);
}
However I get the following error when trying to build the project; The error I get is as follows :-
UnsatisfiedLinkError: Unable to load library 'libctest': liblibctest.so: cannot open shared object file: No such file or directory
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:166)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:239)
at com.sun.jna.Library$Handler.<init>(Library.java:140)
at com.sun.jna.Native.loadLibrary(Native.java:393)
at com.sun.jna.Native.loadLibrary(Native.java:378)
at com.threads.ThreadAffinity.<init>(ThreadAffinity.java:11)
at com.threads.ThreadAffinity.main(ThreadAffinity.java:45)
The current working directory is the root of the project and thats where the so file is located. I also tried modifying the LD_PRELOAD variable to point to my so file; however the error persists.
It works just fine on my OSX where the dylib is located exactly where the so file is currently(project root).
What am I doing wrong?
From the exception:
UnsatisfiedLinkError: Unable to load library 'libctest': liblibctest.so: cannot open shared object file: No such file or directory
It implies you used something like:
public ThreadAffinity() {
ctest = (CTest) Native.loadLibrary("libctest", CTest.class);
}
and not:
public ThreadAffinity() {
ctest = (CTest) Native.loadLibrary("ctest", CTest.class);
}
hence you see the JNA added prefix of lib and postfix of .so added to libctest (liblibctest.so)
LD_PRELOAD is used when you want to prefer one particular version of the same shared library over another, which doesn't apply here.
Define jna.library.path to point to your project root, and JNA should be able to find it.
Also make sure your library has been built as libctest.so and wasn't inadvertently named libctest.dylib.

how to make tornado auto restart when certain files changes

I'm using Tornado working with Python 3 and Linux server, when I edit and save some text or XML files I want Tornado to restart itself. I checked the document and found the autoreload module and the watch function here.
It seems it only worked for pyo files. What can I do if I want it to reload when a certain URI is modified?
Setting the debug flag to True in settings forces Tornado to reload whenever a file is modified or whenever a URI is changed in app.py (or where ever you have defined your handlers). Tornado also automatically reloads template files so any changes in there will be seen instantly.
settings = {
'debug':True,
# other stuff
}
tornado.web.Application.__init__(self, handlers, **settings)
the file added must be an absolute path.
def addwatchfiles(*paths):
for p in paths:
autoreload.watch(os.path.abspath(p))
addwatchfiles('config.xml')
config.xml is at the same directory in where the server's python file start at.
You need to turn autoreload on:
tornado.autoreload.start()
tornado.autoreload.watch('myfile')
Complete example at https://gist.github.com/renaud/10356841

Warbler config.java_classes and log4j.properties

I'm packaging up a rails app with warbler and I want app specific logging. I've added the log4j and commons-loggin jar to the WEB-INF/lib directory, and I want to add log4j.properties to the WEB-INF/classes directory. The problem is, I also want environment specific logging, so my staging/production use different properties (ie. INFO instead of DEBUG) than my devel. I can't just do a:
config.java_classes = FileList["lib/log4j-#{RAILS_ENV}.properties"]
because Tomcat seems to look for the specific file log4j.properties. Is there any way to get warbler to rename this file to just log4j.properties? Or is there a better mechanism for app specific, environment specific logging?
And for the final answer. RAILS_ENV doesn't seem to work in warbler, but looking through the docs on warble config, there's a webxml attribute that contains rails.env, modifying my code to pull the file like:
config.java_classes = FileList["lib/properties/log4j.properties.#{config.webxml.rails.env}"]
Worked like a charm!
Guess I should just read further down in the warble file itself. You can configure pathmaps for the java_classes. Here's what I used:
config.java_classes = FileList["lib/properties/log4j.properties.#{RAILS_ENV}"]
config.pathmaps.java_classes << "%n"
The only problem I've found is that this doesn't actually put the log4j.properties in the WEB-INF/classes directory anymore. It now puts it in the Root. Seems odd that it specifically says in the docs:
One or more pathmaps defining how the java classes should be copied into WEB-INF/classes
I wouldn't think I'd have to add in that WEB-INF/classes path manually but I did. So finally then, this worked:
config.java_classes = FileList["lib/properties/log4j.properties.#{RAILS_ENV}"]
config.pathmaps.java_classes << "WEB-INF/classes/%n"
using the files log4j.properties.#{RAILS_ENV} in the lib/properties directory

How do you get the path of the running script in groovy?

I'm writing a groovy script that I want to be controlled via a properties file stored in the same folder. However, I want to be able to call this script from anywhere. When I run the script it always looks for the properties file based on where it is run from, not where the script is.
How can I access the path of the script file from within the script?
You are correct that new File(".").getCanonicalPath() does not work. That returns the working directory.
To get the script directory
scriptDir = new File(getClass().protectionDomain.codeSource.location.path).parent
To get the script file path
scriptFile = getClass().protectionDomain.codeSource.location.path
As of Groovy 2.3.0 the #SourceURI annotation can be used to populate a variable with the URI of the script's location. This URI can then be used to get the path to the script:
import groovy.transform.SourceURI
import java.nio.file.Path
import java.nio.file.Paths
#SourceURI
URI sourceUri
Path scriptLocation = Paths.get(sourceUri)
Note that this will only work if the URI is a file: URI (or another URI scheme type with an installed FileSystemProvider), otherwise a FileSystemNotFoundException will be thrown by the Paths.get(URI) call. In particular, certain Groovy runtimes such as groovyshell and nextflow return a data: URI, which will not typically match an installed FileSystemProvider.
This makes sense if you are running the Groovy code as a script, otherwise the whole idea gets a little confusing, IMO. The workaround is here: https://issues.apache.org/jira/browse/GROOVY-1642
Basically this involves changing startGroovy.sh to pass in the location of the Groovy script as an environment variable.
As long as this information is not provided directly by Groovy, it's possible to modify the groovy.(sh|bat) starter script to make this property available as system property:
For unix boxes just change $GROOVY_HOME/bin/groovy (the sh script) to do
export JAVA_OPTS="$JAVA_OPTS -Dscript.name=$0"
before calling startGroovy
For Windows:
In startGroovy.bat add the following 2 lines right after the line with
the :init label (just before the parameter slurping starts):
#rem get name of script to launch with full path
set GROOVY_SCRIPT_NAME=%~f1
A bit further down in the batch file after the line that says "set
JAVA_OPTS=%JAVA_OPTS% -Dgroovy.starter.conf="%STARTER_CONF%" add the
line
set JAVA_OPTS=%JAVA_OPTS% -Dscript.name="%GROOVY_SCRIPT_NAME%"
For gradle user
I have same issue when I'm starting to work with gradle. I want to compile my thrift by remote thrift compiler (custom by my company).
Below is how I solved my issue:
task compileThrift {
doLast {
def projectLocation = projectDir.getAbsolutePath(); // HERE is what you've been looking for.
ssh.run {
session(remotes.compilerServer) {
// Delete existing thrift file.
cleanGeneratedFiles()
new File("$projectLocation/thrift/").eachFile() { f ->
def fileName=f.getName()
if(f.absolutePath.endsWith(".thrift")){
put from: f, into: "$compilerLocation/$fileName"
}
}
execute "mkdir -p $compilerLocation/gen-java"
def compileResult = execute "bash $compilerLocation/genjar $serviceName", logging: 'stdout', pty: true
assert compileResult.contains('SUCCESSFUL')
get from: "$compilerLocation/$serviceName" + '.jar', into: "$projectLocation/libs/"
}
}
}
}
One more solution. It works perfect even you run the script using GrovyConsole
File getScriptFile(){
new File(this.class.classLoader.getResourceLoader().loadGroovySource(this.class.name).toURI())
}
println getScriptFile()
workaround: for us it was running in an ANT environment and storing some location parent (knowing the subpath) in the Java environment properties (System.setProperty( "dirAncestor", "/foo" )) we could access the dir ancestor via Groovy's properties.get('dirAncestor').
maybe this will help for some scenarios mentioned here.

Resources