Racer v2.1.21 does not autocomplete code if I don't specify the full path to the part in Rust prelude.
There is no output when I run this command in a terminal:
racer complete Vec::
But in this case racer returns autocompletion for Vec:
racer complete std::vec::Vec
Related
Here in VSCode whenever I write the following line from . import dispatcher pylint always gives error statement saying Attempted relative import beyond top-level package.
But when I run the module using this command: python -m src.train the program runs without flashing any error. Here is the screenshot from the VSCode editor:
Does someone know who to solve this thing in VSCode?
Just add an empty __init__.py file of the folder that contains your dispatcher.py file, then all the .py files under the folder, as whole, should be recognized as a package. And the lint error should dismiss.
I've been a WebStorm user for a long time and have just shifted to VS Code. One of the WebStorm features I like that I can't seem to find in VS Code is the ability to warn me if an import path is wrong. For example:
import { MyModule } from '../MyModulee';
Assuming the directory name is really MyModule WebStorm would warn me that the path could not be found. Is there a comparable extension for VS Code to do this?
Is it possible to make a vscode extension made of mjs files?
because I tried to make an extension with mjs files only, in order to have full es6 features without TypeScript.
But it does not run:
If I make the extension with $ vsce package it does not give any error but it makes an extension that does not work when installed: the contributions that I've put in the package.json are present but vscode shows an error popup that says
Activating extension 'my.ext' failed: Must use import to load ES Module: c:\vsext\extension.mjs.
and every command I try to run gives an error
command 'my.cmd' not found
If I run the extension on the debugger, and the breakpoint on uncaught exception option flagged, it breaks on /src/vs/workbench/api/node/extHostExtensionService.ts:88.
After further search, I noticed that this exception is generatend when the script tries to load the first mjs module.
there is something I can do in order to include my mjs library files?
I think that this behaviour could also impact the use of npm modules with mjs files.
EDIT
Found (kind of) a way using esm:
The idea is to use esm to handle es6 imports and share the vscode object between imported modules
this could seem quite tricky but when I tried to just import * as vscode from "vscode" im my mjs files, vscode complained that can't find module vscode.
so I've done the following
add 'esm' as dependency
in all the files where vscode is used, remove the import of vscode and add something like this function
var vscode; // will store vscode obj
export function IMPORTVSCODE(vscodeInstance){
vscode = vscodeInstance
}
create a init file where you require vscode (with node native require) and your main module (with esm require)
in the init file call main.IMPORTVSCODE(vscode)
on all the files A that imports a file B that need vscode, before use the exported stuff from file B, call B.IMPORTVSCODE(vscode)
for example
// init.js
const vscode = require("vscode")
const esm = require("esm")(module/*, options*/)
const main = esm("./main.mjs")
main.IMPORTVSCODE(vscode)
module.exports = main
// main.mjs
import * as other from "./other.mjs"
var vscode; // will store vscode obj
export function IMPORTVSCODE(vscodeInstance){
vscode = vscodeInstance
}
function activate(){
other.IMPORTVSCODE(vscode)
other.methodThatNeedsVscode()
}
// other.mjs
var vscode; // will store vscode obj
export function IMPORTVSCODE(vscodeInstance){
vscode = vscodeInstance
}
export function methodThatNeedsVscode(){
vscode // ...use vscode
}
My extension runs fine now!
But I think that better ideas could be found, so if somebody has some finest solutions, please share them
I'm using spark-2.3.0-bin-hadoop2.7 and sparkling-water-2.3.5 on Windows 10 64 bit.
I've taken the following steps and looking for help for the Steps 4 and 5.
Step 1: Run Spark shell by executing bin/sparkling-shell. Fine
Step 2: At scala prompt (Fine)
scala> import org.apache.spark.h2o._
scala> val h2oContext = H2OContext.getOrCreate(spark)
scala> import h2oContext._
Step 3: - openFlow command at scala prompt to open Flow UI in the browser. Fine.
Step 4: At scala prompt (Not working)
scala> openSparkUI command at scala prompt to open the Spark UI in the browser
- error: not found: value openSparkUI
Step 5: Looking for an editor to write scala code and how to submit that code at scala prompt
openSparkUI used to exist around 2015, but has since been removed. As noted in the question h2oContext.openFlow is still functional and an available option (type q to convert a cell to a scala cell in flow, type h to see the the full keyboard shortcut list - note: keyboard shortcuts only work if you are not in editor mode and typing within a cell).
Other possible interfaces for Scala code include Jupyter notebook and Zeppelin.
I think there is a bug with respect to how PyDev (version 4.6) recognizes intra-package imports when selecting Grammar 3.x for the project preferences. I have a project like this:
foobar
mypack
__init__.py
mod1.py
mod2.py
mod2.py simply says
from mod1 import fun1
mod1.py simply says
def fun1():
print("Hey we are in fun1 in mod1")
If the project Python project preferences are set to use Grammar 3.0-3.5, with a Python 3.4 interpreter, and I open up mod2.py the line from mod1 import fun1 is highlighted with an error Unresolved import: fun1. If I change the Python project preferences to use Grammar 2.7, close the file mod2.py and reopen it, the error disappears. Just by changing the grammar back and forth, and closing/reopening the file, I can make the error appear/disappear.
So it seems that setting the Grammar to 3.x in PyDev causes intra-package imports to be incorrectly flagged as having an import error.
Any suggestions?
PyDev is doing right... on Python 3, relative imports must be written as:
from .mod1 import fun1
If the import doesn't start with a dot, it'll consider it an absolute import (and will properly show the error for you as with that absolute path the imported file cannot be resolved).
So my real issue was getting PyDev to not report errors about the imports, and to be able to debug modules buried in packages that have a main() in there for debugging. The solution for me was to use relative imports (as said in Fabio's answer), and then to do the following for debugging purposes. Let's say I want to run a module pack1.subpack2.subpack3.subpack4.modtodebug using PyDev, that has relative imports, and has a main() function. At the top level of my project, I have a module debugmain.py that reads
from pack1.subpack2.subpack3.subpack4.modtodebug import main as debugmain
if __name__ == '__main__':
debugmain()
I then have one run configuration for debugmain.py and each time I want to debug a different module, I just have to edit the code in debugmain.py to point to that module.
I hope this helps someone else with this kind of problem.