I'm new to octave, and want to run a few commands on startup automatically every time it opens.
I typed "help startup" and saw "Octave uses the file ".octaverc". I did a bit of searching online at https://www.math.utah.edu/docs/info/octave_4.html, and saw the .octaverc file should be in the following path:
OCTAVE_HOME/lib/octave/VERSION/startup/octaverc
PROBLEM:
In that directory I don't have a startup folder, only "oct" and "site". I do see hidden files, which was my first thought since the file begins with "." character. So I then used Agent Ransack in the directory, and still nothing came up.
QUESTION:
1) Do I have to make the startup folder and octaverc file myself?
2) If so, does one, both or none have to be hidden?
3) Can it be a txt file, or does it have a special extension?
4) Do I just type the commands straight into the file or is there special formatting?
NOTE:
In case I'm going about this the wrong way, there are the operations I'd like to have run on startup:
PS1('>> '), addpath('D:\Users\Me\Desktop'), clc
Thanks ahead of time for the help!!
Possible locations (and their differences) for octaverc files are specified in the documentation.
In short, these are, from more general to specific:
octave-home/share/octave/site/m/startup/octaverc (most generic, for entire system)
octave-home/share/octave/version/m/startup/octaverc (to cover for more than one octave versions installed on the system, possibly requiring different startup scripts)
~/.octaverc (where ~ is unix-speak for a user's home directory -- covering for user-specific startup files)
.octaverc files in any directory, creating specific startup conditions for specific directories
octaverc files are effectively simple script files that are executed from most generic to most specific each time octave starts. Therefore, in the presence of conflicting commands, the more specific file can effectively be used to override the more generic behaviour.
Octave also supports (but does not recommend) the use of the startup.m file, for matlab compatibility.
You might also want to check out pathdef and savepath as well.
As a more general tip, if you ever want to search for a specific keyword from the documentation (e.g. octaverc), you can type this kind of search query in duckduckgo (or google):
octaverc site:https://octave.org/doc/interpreter/
(or just download the documentation as pdf and search the pdf)
Found the solution, the file was in the following path:
OCTAVE_HOME/share/octave/site/m/startup
to find out where OCTAVE_HOME is for you, just type "OCTAVE_HOME" into your Octave command line window.
ANSWERS:
1) You do not have to make a startup octaverc file yourself
2) The file is actually not hidden, so it should be easy to find given you're looking in the right place.
3) The file doesn't have an extension. It's just octaverc.
4) Under the last line of the existing file, you can just append commands as you would type them at the Octave command line window.
the last(7.3.0) octave version placed HERE:/ does not find the THERE:/openEMS/matlab directory even it is already loaded with octaverc or addpath. It keeps looking into the work dir where openEMS is not placed and does not recognize, for instance, the 'physical_constants.m' file.
I am using the following setup
macOS v10.14 (Mojave)
Python 3.7.1
Visual Studio Code 1.30
Pylint 2.2.2
Django 2.1.4
I want to use linting to make my life a bit easier in Visual Studio Code. However, for every import I have states "unresolved import". Even on default Django imports (i.e. from django.db import models).
I presume it is because it is not seeing the virtual environment Python files.
Everything works just fine, but it's starting to get annoying.
The interpreter choices I have are all system versions of Python. It does not seem to see my virtual environment Python at all (it is not in the same directory as my workspace, so that part makes sense).
If I set up the python.PythonPath in the settings.json file, it just ignores it and does not list my virtual environment path as an option. I also tried setting it up in my global Python settings, but it also does not show up.
Is there a quick fix to get it working?
The accepted answer won't fix the error when importing own modules.
Use the following setting in your workspace settings .vscode/settings.json:
"python.autoComplete.extraPaths": ["./path-to-your-code"],
Reference: Troubleshooting, Unresolved import warnings
In your workspace settings, you can set your Python path like this:
{
"python.defaultInterpreterPath": "/path/to/your/venv/bin/python",
}
Alternative way: use the command interface!
Cmd/Ctrl + Shift + P → Python: Select Interpreter → choose the one with the packages you look for:
This issue has already been opened on GitHub:
Python unresolved import issue #3840
There are two very useful answers, by MagnuesBrzenk and SpenHouet.
The best solution for now is to create a .env file in your project root folder. Then add a PYTHONPATH to it like this:
PYTHONPATH=YOUR/MODULES/PATH
And in your settings.json add:
"python.envFile": ".env"
When I do > reload window that fixes it.
Reference: Python unresolved import issue #3840, dkavraal's comment
None of the solutions worked except this one. Replacing "Pylance" or "Microsoft" in the settings.json solved mine.
"python.languageServer": "Jedi"
You need to select the interpreter associated with the virtual environment.
Click here (at the bottom status bar):
And just select the virtual environment you are working with. Done.
Sometimes, even with the interpreter selected, it won't work. Just repeat the process again and it should solve it.
If you have this code in your settings.json file, delete it:
{
"python.jediEnabled": false
}
If you are more visual like myself, you can use the Visual Studio Code configurations in menu File → Preferences → Settings (Ctrl + ,). Go to Extensions → Python.
In the section Analysis: Disabled, add the suppression of the following message: unresolved-import:
I was able to resolved this by enabling jedi in .vscode\settings.json
"python.jediEnabled": true
Reference from https://github.com/Microsoft/vscode-python/issues/3840#issuecomment-456017675
I wonder how many solutions this problem have (or have not), I tried most of the above, nothing worked, the only solution that worked is to set the python language server to Jedi, instead of Microsoft in the settings.json file:
"python.languageServer": "Jedi"
None of the previous answers worked for me. Adding both of the lines below to my settings.json file did, however.
"python.analysis.disabled": [
"unresolved-import"
],
"python.linting.pylintArgs": ["--load-plugin","pylint_protobuf"]
The first line really just hides the linting error. Certainly not a permanent solution, but de-clutters the screen.
This answer gave me the second line: VS Code PyLint Error E0602 (undefined variable) with ProtoBuf compiled Python Structure
Maybe someone who understands Python more than me can explain that one more.
Okay, so 2 years down the line, I have ran into this annoying problem. All I can seen here are some really complicated workarounds. Here are easy to follow steps for anyone else who might just run into this later on:
at the bottom of VS Code where you see the Python version listed, just click there
Select Interpreter windows is going to appear
click on the first option that says "Select Interpreter Path" and navigate to the folder path which has your Virtual Environment
That's all you need to do and avoid tampering with those settings in VS Code which might get very complicated if not handled with caution.
My solution
This solution is only for the current project.
In the project root, create folder .vscode
Then create the file .vscode/settings.json
In the file setting.json, add the line (this is for Python 3)
{
"python.pythonPath": "/usr/local/bin/python3",
}
This is the example for Python 2
{
"python.pythonPath": "/usr/local/bin/python",
}
If you don't know where your Python installation is located, just run the command which python or which python3 on the terminal. It will print the Python location.
This example works for dockerized Python - Django.
I was facing the same problem while importing the project-related(non standard) modules.
Detailed explanation of the problem
Directory structure:
Project_dir:
.vscode/settings.json
dir_1
> a
> b
> c
dir_2
> x
> y
> z
What we want:
Project_dir
dir_3
import a
import y
Here "import a" and "import y" fails with following error:
Import "dir_1.a" could not be resolvedPylancereportMissingImports
Import "dir_2.y" could not be resolvedPylancereportMissingImports
What worked for me:
Appending the top directory which contains the modules to be imported.
In above example add the follwoing "Code to append" in ".vscode/settings.json"
Filename:
.vscode/settings.json
Code to append:
"python.analysis.extraPaths": [dir_1, dir_2]
The solution from Shinebayar G worked, but this other one is a little bit more elegant:
Copied from Python unresolved import issue #3840:
Given the following example project structure:
workspaceRootFolder
.vscode
... other folders
codeFolder
What I did to resolve this issue:
Go into the workspace folder (here workspaceRootFolder) and create a .env file
In this empty .env file, add the line PYTHONPATH=codeFolder (replace codeFolder with your folder name)
Add "python.envFile": "${workspaceFolder}/.env" to the settings.json
Restart Visual Studio Code
To me the problem was related with the project that I was working on. It took me a while to figure it out, so I hope this helps:
Original folder structure:
root/
__init__.py # Empty
folder/
__init__.py # Empty
sub_folder_b/
my_code.py
sub_folder_c/
another_code.py
In another_code.py:
from folder.sub_folder_b import my_code.py
This didn't trigger the intellisense in Visual Studio Code, but it did execute OK.
On the other hand, adding "root" on the import path, did make the intellisense work, but raised ModuleNotFoundError when executing:
from root.folder.sub_folder_b import my_code.py
The solution was to remove the _init_.py file inside the "folder" directory, leaving only the _init_.py located at /root.
This works for me:
Open the command palette (Ctrl + Shift + P) and choose "Python: Select Interpreter".
Doing this, you set the Python interpreter in Visual Studio Code.
None of the answers here solved this error for me. Code would run, but I could not jump directly to function definitions. It was only for certain local packages. For one thing, python.jediEnabled is no longer a valid option. I did two things, but I am not sure the first was necessary:
Download Pylance extension, change python.languageServer to "Pylance"
Add "python.analysis.extraPaths": [ "path_to/src_file" ]
Apparently the root and src will be checked for local packages, but others must be added here.
I am using the following setup: (in Apr 2021)
macos big sur
vscode
Anaconda 3 (for environment)
And I faced this error during starting of the Django.
So, I follow these steps and this error is resolved.
Steps are given in these screenshots:
Open settings (workspace)
Follow this screenshot to open Python Path
Now, click Edit in settings.json
Make path like given in this screenshot /opt/anaconda3/bin/python
5. Now, save this settings.json file.
6. Restart the vscode
Also, intellisense might not work for some time hold on wait for some time and then restart again then vscode reads file for new path.
That happens because Visual Studio Code considers your current folder as the main folder, instead of considering the actual main folder.
The quick way to fix is it provide the interpreter path to the main folder.
Press Command + Shift + P (or Ctrl + Shift + P on most other systems).
Type Python interpreter
Select the path where you installed Python in from the options available.
Changing
Python:Language Server
to 'Jedi' worked for me.
It was 'Windows' initially.
For me, it worked, if I setup the paths for python, pylint and autopep8 to the local environment paths.
For your workspace add/change this:
"python.pythonPath": "...\\your_path\\.venv\\Scripts\\python.exe",
"python.linting.pylintPath": "...\\your_path\\.venv\\Scripts\\pylint.exe",
"python.formatting.autopep8Path": "...\\your_path\\.venv\\Scripts\\autopep8.exe",
Save and restart VS Code with workspace.
Done!
I have a different solution: my Visual Studio Code instance had picked up the virtualenv stored in .venv, but it was using the wrong Python binary. It was using .venv/bin/python3.7; using the switcher in the blue status bar.
I changed it to use .venv/bin/python and all of my imports were resolved correctly.
I don't know what Visual Studio Code is doing behind the scenes when I do this, nor do I understand why this was causing my problem, but for me this was a slightly simpler solution than editing my workspace settings.
In case of a Pylint error, install the following
pipenv install pylint-django
Then create a file, .pylintrc, in the root folder and write the following
load-plugins=pylint-django
I have faced this problem in three ways. Although for each of them a solution is available in the answers to this question, I just thought to put it all together.
First I got an "Unresolved Import" while importing some modules and I noticed that my installations were happening in global pip instead of the virtual environment.
This issue was because of the Python interpreter. You need to select the interpreter in Visual Studio Code using Shift + Ctrl + P and then type Select Python Interpreter. Select your venv interpreter here.
The second issue was: The above change did not resolve my issue completely. This time it was because of file settings.json. If you don't have the settings.json file in your project directory, create one and add the following line in that:
{
"python.pythonPath": "apis/bin/python"
}
This will basically tell Visual Studio Code to use the Python interpreter that is in your venv.
The third issue was while importing a custom Python module or file in another program. For this you need to understand the folder structure. As Python in venv is inside bin, you'll need to specify the folder of your module (most of the time the application folder). In my case it was app,
from app.models import setup_db
Verbally, import setup_db from models.py resides in the app folder.
If you are using pipenv then you need to specify the path to your virtual environment.in settings.json file.
For example :
{
"python.pythonPath":
"/Users/username/.local/share/virtualenvs/Your-Virual-Env/bin/python"
}
This can help.
If someone happens to be as moronic as me, the following worked.
Old folder structure:
awesome_code.py
__init__.py
src/
__init__.py
stuff1.py
stuff2.py
New structure:
awesome_code.py
src/
__init__.py
stuff1.py
stuff2.py
How to avoid warning
Please note that this is just skipping the warning not resolving it.
First of all open visual studio code settings in json and add following arguments after "[python]":{}
"python.linting.pylintArgs": ["--rep[![enter image description here][1]][1]orts", "12", "--disable", "I0011"],
"python.linting.flake8Args": ["--ignore=E24,W504", "--verbose"]
"python.linting.pydocstyleArgs": ["--ignore=D400", "--ignore=D4"]
This has helped me to avoid pylint warnings in VSCode.
I have resolved import error by Ctrl + Shift + P.
Type "Preferences settings" and select the option Preferences Open Settings (JSON)
And add the line "python.pythonPath": "/usr/bin/"
So the JSON content should look like:
{
"python.pythonPath": "/usr/bin/"
}
Keep other configuration lines if they are present.
This should import all modules that you have installed using PIP for autocomplete.
I'm trying to eliminate the console warnings (of deprecation) from the iron-flex-layout element.
When I load my app, I get the following errors in the console:
iron-shadow-flex-layout.html:12 This file is deprecated. Please use iron-flex-layout/iron-flex-layout-classes.html, and one of the specific dom-modules instead
(anonymous)
iron-shadow-flex-layout.html:12
iron-flex-layout.html:14 This file is deprecated. Please use iron-flex-layout/iron-flex-layout-classes.html, and one of the specific dom-modules instead
(anonymous)
iron-flex-layout.html:14
iron-fit-behavior.html:221 /deep/ combinator is deprecated. See https://www.chromestatus.com/features/6750456638341120 for more details.
When I inspect the file paths, I see the following:
http://localhost:8080/bower_components/iron-flex-layout/classes/iron-shadow-flex-layout.html
http://localhost:8080/bower_components/iron-flex-layout/classes/iron-flex-layout.html
http://localhost:8080/bower_components/iron-fit-behavior/iron-fit-behavior.html
I am reluctant to go tinkering around and manually deleting files in my bower_components directory.
So, how can I fix these errors? What is the recommended best practice?
Edit
Here is the deprecated file on Github. Line 14 writes the console warning. But this deprecated file is not being imported anywhere in the app. (I know because I did a global search on the string iron-flex-layout/classes and, separately, on iron-shadow-flex-layout.html). Instead, I have done as the warning suggests; I imported iron-flex-layout/iron-flex-layout-classes.html everywhere instead. But the warning persists nevertheless.
I assume the element owners and Google overlords want to retain the console warnings in place (and not accept a PR which removes it). So, what is the best practice? Live with the warnings? (It doesn't seem quite right to edit my local copy and just comment out the warnings.) Or should I do something else? (Maybe there is another option I'm not aware of.)
Edit2
per #tony19:
I recommend setting a breakpoint in the deprecated file (on the console.log() line) to see who's importing it. – tony19
So now, I'm using this:
https://github.com/PolymerElements/iron-flex-layout/blob/master/classes/iron-flex-layout.html
<script>
console.warn('This file is deprecated. Please use `iron-flex-layout/iron-flex-layout-classes.html`, and one of the specific dom-modules instead');
debugger;
</script>
I'm seeing some information appear when the app reaches the breakpoint. But nothing so far indicates what's causing the import of the iron-flex-layout element. Or what to do to fix it.
Is there a command or something that can log what file imported another file? I've looked all over for how I might accomplish that. Could anyone please describe in detail what that might look like?
The warning indicates that an HTML file in your source or dependencies is importing ../iron-flex-layout/classes/iron-flex-layout.html, which is deprecated. The import must be in your tree somewhere, or else the warning wouldn't appear. I recommend setting a breakpoint on the console.log() line of the deprecated file to track down the offender.
If you're in control of the offending element that imports this deprecated file, you can update the import to use iron-flex-layout-classes.html that the warning recommends. Otherwise, you can petition the maintainer of the offending element to update their dependencies (or submit a PR ;).
I had this same issue today and thought the same thing. However, diving a bit deeper I found a few third party components were using paper-styles/paper-styles which called in iron-flex-layout/classes/iron-flex-layout.html. The reference it'd be there somewhere I'm certain. Hope that helps.
I have two libraries libA and libB.
libA contains a file Action.h
libB contains a file action.h
I want to generate doxygen documentation in the same output directory for both libraries. This directory is to be used in Windows, for which action.html and Action.html is unfortunately considered to be the same file. To prevent this clash, I wish to render the generated files unique by prepending their path names to them.
Therefore, I set FULL_PATH_NAMES to YES.
I expect to see something like libA_Action.html and libB_action.html when I generate the documentation, but I don't! I still see Action.html and action.html. Its as if the FULL_PATH_NAMES parameter does nothing at all. Do I also need to set some other parameter in the Doxyfile to make the FULL_PATH_NAMES parameter work correctly?
You're probably running doxygen twice - one time for each library. If that is the case, doxygen isn't aware of the fact that it might clash with an output from another run, so when it find an existing file, it assumes that it is leftover from a previous run, and overrides it.
Setting FULL_PATH_NAMES doesn't help, as doxygen has no idea that multiple libraries exist, so, as far as doxygen is concerned, the prefix is identical to all files, so even when you adding a force it, it adds nothing (That's probably a bug).
The solution to your problem is setting both libraries as inputs to the same doxygen project.
You can do it by setting INPUT to multiple folders in the configuration file:
INPUT = ...bla\Lib1 \
...bla\Lib2
I am writing a WIX installer and I have a following requirement:
During installation, I need to pass an absolute path to a file (lets call it A) included in my installer to a COM component, which already exists on the hard drive and is a part of another program. I have already written an appropriate Custom Action which expects a path to the file A. I don't want to include A as a file installed in the Program Files folder and removed during the uninstallation process. Instead, I would like to put A only temporary on the hard drive, call my Custom Action which will cause the COM component to use the content of A, and then remove A from disk. Is there an easy way to accomplish this goal?
I have tried to utilize the Binary Table and store A there, however I don't know how to reference A using absolute path. I know I could put A outside of MSI file but I would like to keep every file installer needs in a single MSI.
Any help would be appreciated.
Deleting a file that MSI installed means that MSI will consider it "broken" and try to auto-repair it if called on to do so. That happens automatically in several cases (e.g., advertised shortcuts and COM registration) so I'd recommend against it. Leave the file there instead -- it's done its job and there's no harm in leaving it there.
I would take this approach.
Install the file "A" into any directory. Run your custom action needed to update the COM component. Then run another custom action or modify the currently written one to remove the file after it is no longer in use. This would leave no trace of the file "A" and if you schedule the custom action to only run during the install you won't have to worry about it on uninstall.