I have a simple test that takes the parameter --test from command line and compares it. It works just fine in command line, but when I use pycharm it is no longer working (will not take the parameter from command line in my configuration set up in pycharm.
enter image description here
I guess, there is something wrong with my pycharm set up, but I can't figure out what it is...
I have found where and how to set up the configuration, but it's just not working...are the command line parser.addoption parameters added in the parameters window of the configuration?
is the syntax --test test_type_name or --test="test_type_name" I have tried them all...
Using a community version of pycharm
Never mind, I had to put them in additional arguments window instead of Parameters, I thought I had tried it and it didn't work before. I also had an old version of pycharm, from last year - could have had a bug in it, I have since updated to something newer and it works.
Related
I cannot load or run my tests, from within VS Code.
I'm a new user to Elixir, and to VS Code. I'm running Lubuntu 21.10 (Impish). I've downloaded Erlang/OTP 25 (.deb), and Elixir 1.14 (precompiled binary in /usr/share/elixir), and can get anything I need running in a Bash terminal. Again, in a standard QTerminal window,
erl, iex, mix, elixir, etc. all work fine.
In VS Code, however, I get some errors. I feel stupid, but I'm coming from Sublime Text, so please forgive me.
In the left pane of VS Code, ExUnit shows an error (red):
Clicking on this error gives me this, on the bottom right pane. The command line options, passed to mix test, seem to be the default configuration:
This result is bizarre to me, because I can open the integrated terminal, execute /bin/sh, and then run the exact mix test line that's displayed:
/usr/share/elixir/bin has been added to my PATH variable, in ~/.bashrc, ~/.profile, and /etc/environment.
However, I am further confused by all tests being excluded, and wonder if there's some connection to the core issue:
Note that I can run my tests just fine, using different command line options. I've tried adding tags, but that didn't fix the problem.
I tried Google'ing this, and played around with my settings. Here is what I have configured in the "User" settings.json, and I made sure nothing overrides this in "Workspace" settings:
Changing the useNativeTesting setting doesn't solve the problem.
On another (?) note, I get a "failed to run elixir" upon VS Code startup:
Again, I have no problem running commands from a Linux terminal, or from a terminal within VS Code.
Plot twist: If I remove the precompiled Elixir 1.14, and downgrade to an older version, via apt, the problem goes away. But Lubuntu 21.10 doesn't offer Elixir 1.14, and I'm really into using the new dbg() feature.
But for now, I cannot load or run my tests, from within VS Code, apparently because Mix cannot be found.
Thanks to Daniel Imms, from the VS Code team, for answering my question on Twitter:
"Try moving where ever you init mix and elixir (.bashrc?) into your .bash_profile and then logging out and in again or restarting. I'm guessing it's in your bashrc which doesn't run in non-interactive sessions like in tasks."
enter image description here
Can anyone say how to debug it
It seems like your kotlin directory is not added to your PATH variable thus the extension/terminal may not know what to execute, when trying to execute kotlinc.
The easiest way to resolve this issue is by adding the path to your kotlin directory (path/to/your/kotlin/bin) to your PATH variable
(see here), if you are on windows, or here, if you are on a linux system.
You can check, if it works by opening a command line window and trying to execute
kotlinc -version
However, as it seems like you are using Code-Runner extension in vscode, you can also update your settings.json file:
reference here.
I'm new to zsh, just switched over from fish. I'm trying to get autocomplete working so it displays argument/flag options for commands upon pressing tab.
Currently this works, but it only appears to work for built in commands. For example, it works for ls, grep, git, etc. but does not work for programs I have added myself. For example, fd-find, exa, and nvm all do not work.
For nvm, I have enabled the nvm plugin using Oh My Zsh. I know the plugin is working in general, because nvm itself is working (and it wasn't before enabling the plugin).
For fd-find, I see the auto-completion file in /usr/share/zsh/vendor-completions/_fd
For exa, I manually downloaded and placed the autocompletion file in /usr/local/share/zsh/site-functions/_exa as instructed by the site.
All 3 of these programs do not show me the typical arguments/flags autocomplete menu the way built in commands do. I'm not sure what is wrong.
I echoed the fpath environment variable to make sure /usr/local/share/zsh/site-functions was in there. It is, along with /usr/local/share/zsh/site-functions/
When I run which nvm, I get:
_nvm () {
# undefined
builtin autoload -XUz
}
Which is actually what I get for all of _nvm, _exa, _fd.
Not sure what else to try.
Any suggestions for how to get autocomplete working properly?
Other info: I'm on a System76 Darter Pro laptop running Pop!_OS.
I found a fix that worked for me. After searching through zsh issues related to autocomplete on github, this solution worked for me. Credit was given to the original source of the solution on stackexchange.
The solution was simply to remove all zcompdump files:
rm ~/.zcompdump*
After running the above command, autocomplete works and expands out the possible flags/arguments for non-builtin programs!
I'm using Python 3.8 on VScode, but I can't seem to get the program to write anything in output, even with simple commands like: print("Hello world!"). It shows up in the terminal well enough, so the code shouldn't be the problem. Do i need to fix anything in the setting to make it show the output?
1: Picture of terminal:
Please could you check your user settings.json and workspace settings.json for the existence of a setting for terminal.integrated.shell.*.
I believe you may have changed the shell to use command prompt instead of powershell.
Also, please could you provide some screenshots of the terminal
And any errors logged in the console widows (go to Help->Toggle Developer Tools)
i have this issue (https://github.com/sbt/sbt/issues/562)
basically when I try to get a console it says:
[ERROR] Failed to construct terminal; falling back to unsupportedjava.lang.IllegalArgumentException: Invalid terminal type: jline.UnixTerminal
also you cant use backspace
you basically cannot use sbt in cygwin (in dos is fine but cygwin is a much nicer environment)
and have voiced my concern there
i have tried several workaround i found on the net but they are all for old releases and no use now
was just wondering if you know of any workaround?
thanks
The following works for me (mostly, see note at bottom):
Use the mintty shell. I believe this is the default shell for new cygwin installs but has been included as an alternative for a while. If mintty.exe exists in your <cygwin home>\bin folder then it's ready to use, else it can be installed through the typical cygwin package selection from the setup.exe.
Open a mintty window, right click anywhere, go to Options... -> Keys, and make sure Send Backspace as ^H is checked. This will allow the REPL to correctly interpret backspaces.
For just running the Scala REPL that should be all you need, but attempting to run sbt console can still produce that exception. To get past that, run sbt without any arguments to get to the sbt prompt. From there execute:
eval System.setProperty("jline.terminal", "scala.tools.jline.UnixTerminal")
then
console
or, as a single command (with both semi-colons being important):
; eval System.setProperty("jline.terminal", "scala.tools.jline.UnixTerminal") ; console
From what I can tell, this is caused at least in part by the Scala REPL and the sbt prompt using incompatible versions of JLine. In particular, it looks like the Scala REPL created their own wrappers around the library and are using that while sbt is using the JLine library directly.
Note
One limitation that I continue to run into is that the REPL wraps at column 80 even if the shell window has more horizontal space. Not only that, but when the REPL wraps like this it overwrites the same line rather than advancing to the next, and pulling long lines from history ends up pushing the cursor above the line you're actually editing.