I wrote the code as follows:
func main() {
fmt.Println("111111111111111111111111111111111111111111111111111111111111" +
"1111111111111111111111111111")
}
Though I have unselected the checkbox of "use soft wraps in console":
The output in GoLand console is:
The output in windows cmd is:
What can I do to show the whole long line in GoLand console, just in windows cmd?
This is because GoLand 2020.1 enabled pty on Windows but default and old settings were not correctly migrated.
Before doing the workaround below, upgrade to 2020.1.2, which should solve the issue. If it doesn't, then proceed with the workaround below.
Disable go.run.processes.with.pty registry key in Ctrl+Shift+A | Registry... and this will be solved.
For more details, see the related issue.
Related
What:
After updating to pretty much all Cypress versions 10.x.x, WebStorm stopped or Cypress stopped opening the correct line number for the below scenarios:
Issue:
Where a test would fail an assertion etc. with link to the line in IDE.
Open In IDE inside specific spec it block .
Inside SCREENSHOT: FAILED_LINE_NUMBER it brings me to that line however that's not the line the test actually failed at.
Similar situation when I click on the link pointed out inside SCREENSHOT: GENERIC_BODY_OPEN_IN_IDE -- clicking the link doesn't bring me to the correct it block.
I am fairly certain this is user error but cannot figure it out.
Setup:
Windows 10
Cypress 10.0.3
WebStorm v221.5921.27
cypress runner > Settings > Device Settings > External Editor = Custom C:\Users\me\AppData\Local\JetBrains\Toolbox\apps\WebStorm\ch-0\221.5921.27\bin\webstorm64.exe
Things I have tried:
Wiping cache inside C:\Users\me\AppData\Local\Cypress\Cache and then running npm i cypress
Reinstalling WebStorm
Images:
FAILED_LINE_NUMBER
GENERIC_BODY_OPEN_IN_IDE
I installed the latest version of RStudio (RStudio 1.1.423 - Windows Vista / 7/8/10).
I'm trying to publish to RPubs, but in Global Options does not appear the option for Rpubs.
When I request Publish Document, the following error appears: Error occurred while executing method.
Rprofile:
I entered the command: options (rpubs.upload.method = "internal") at line 25 of Rprofile, but it did not resolve.
The solution is provided by a careful rereading of http://rstudio-pubs-static.s3.amazonaws.com/25030_8e9c9ffc3b3c423d9381d81543423502.html
"Put in options(rpubs.upload.method = “internal”) and no other text at all". Meaning that this line of code is the only code present in the .Rprofile file.
Previously I had been adding the line to a copy of the rest of the Rprofile text. The unnecessary code was the culprit.
I had the same error before. Turns out it was due to having an accent mark in a folder name from my directory (í). I just modified that one folder name and it worked fine.
How to specify the path of generated debug binary file when debug go-lang in vs-code?
I have tried modify launch.json file but not work.
I can debug go programs well now in vs-code, the only problem is each time i finish debug, a debug binary file was generated under my project directory, like the picture below.
I want to know can i specify the directory of generated debug binary file?
I am on mac screen shot of my problem:
This is followed by vscode-go issue 1345: "Delete binary files created by delve after closing the debug session"
delve is the debugger for Golang, or at least it's the one that the Go extension uses.
When you debug something with delve, it creates a large binary file in the current directory. If you debug a main function (dlv debug), you get 'debug'. If you debug a test function (dlv test), you get 'debug.test'.
In normal delve usage, when you're done, you quit delve. Delve then deletes this file. Apparently VSCode gracelessly terminates (SIGKILL?) delve, which means the file sticks around.
So this is studied, but not yet resolved.
Update July 2018: Ramya Rao adds in this issue:
I finally have an update!
Turns out there is a command called Detach that can be called on the delve server which will result in the required clean up of the debug binary that gets generated.
To get this fix before the next update to the Go extension (which will be either Friday or early next week), please follow the below:
Download https://github.com/Microsoft/vscode-go/blob/master/Go-latest.vsix
Run code --install-extension Go-latest.vsix
If the above fails with Error: end of central directory record signature not found, then clone this repo (vsgo) and use the Go-latest.vsix file from the cloned repo
Reload VS Code
The fix worked for me as long as the program being debugged wasn't spawning processes of its own like a web server for which I have logged an upstream issue with delve.
I'd appreciate it if folks here can give the fix a try and share any feedback.
The change you need to do to provide an output path for the generated debug binary is in the launch.json file.
Use the property output in your debug configuration.
Please don't modify the package.json file.
This debug file was generated by delve when debugging and should be deleted after debugging, this seems to be bug of go extension of vs-code, see the link here
I have added the following configuration option into my C++ code in OMNT++:
Register_PerRunConfigOption(CFGID_LOGEVENTS, "logevents", CFG_BOOL, "false", "log scheduler events");
I specify the 'logevents' in my Config <name>, and I can use it without any issues. The problem is with the ini error checking:
Apparently it does not recognize the newly added config option and shows an error. As a temporary workaround, I am using **.logevent = false in order to change error into warning.
Is this a known issue ?
Every time I run my project, the following error window pops up which is annoying!
Error exist in required project(s): Proceed with launch ?
Is there any ways to fix the error or at least suppress it?
Actually, this is not an error. It only means that IDE does not recognize this option. Your option is added correctly. Build your model using Qtenv or Tkenv and run it, then choose from the menu: Inspect | Available Components | Supported configuration options - the option logevents will be visable.
My VS Code integrated terminal is only toggling up for a second then disappearing with the command Ctrl+`(Tried to change it - still not working :)),
showing the Integrated terminal exited with code 1 error.
Any ideas for fixing it?
I had the same problem on Windows 10. The problem was that I had VSCode running in compatibility mode (Windows 8). If that is that case for you, just uncheck "Run this program in compatibility mode for" checkbox in Compatibility tab of the VSCode properties, click in OK and restart VSCode.
I had the same problem just a few minutes ago, in my case this error was a path consequence, my windows user folder has an accent (c:/users/josé /..) , so, just try to move your project into another folder, like "C:/projects".
Current Solution is using a none-English named Folder as project Folder.
Here is my research:
default value "terminal.integrated.shell.windows": "C:\\WINDOWS\\system32\\cmd.exe"
Following is the debug info in VScode:
terminalInstance.ts:55 Integrated terminal exited with code 1
(anonymous function) # terminalInstance.ts:55
emitTwo # events.js:100
emit # events.js:185
ChildProcess._handle.onexit # internal/child_process.js:204
Following is debug info in Atom:
C:\Users\mzvast\AppData\Local\atom\app-1.9.1\resources\app.asar\src\task.js:52
Unable to start terminal process. Win32 error code: 267 Error: Unable
to start terminal process. Win32 error code: 267
at Error (native)
at Server. (C:\Users\mzvast.atom\packages\platformio-ide-terminal\node_modules\pty.js\lib\pty_win.js:67:9)
at emitOne (events.js:90:13)
at Server.emit (events.js:182:7)
at Pipe.onconnection (net.js:1439:8)
(anonymous function) #C:\Users\mzvast\AppData\Local\atom\app-1.9.1\resources\app.asar\src\task.js:52
(anonymous function) #C:\Users\mzvast\AppData\Local\atom\app-1.9.1\resources\app.asar\src\task.js:126
module.exports.Emitter.simpleDispatch # C:\Users\mzvast\AppData\Local\atom\app-1.9.1\resources\app.asar\node_modules\event-kit\lib\emitter.…:25
module.exports.Emitter.emit # C:\Users\mzvast\AppData\Local\atom\app-1.9.1\resources\app.asar\node_modules\event-kit\lib\emitter.…:125
(anonymous function) # C:\Users\mzvast\AppData\Local\atom\app-1.9.1\resources\app.asar\src\task.js:78emitTwo
# events.js:100
emit # events.js:185
handleMessage # internal/child_process.js:718
channel.onread # internal/child_process.js:444
The win32 error code 267 seem to be,according to microsoft:
ERROR_DIRECTORY
267 (0x10B)
The directory name is invalid.
Close vscode, create a new folder somewhere on your pc, but not inside the directory which was previously opened with vscode. Open this new directory with vscode and then try opening your terminal. If your terminal opens, then the problem was with your previous directory. This happened with me, the directory didn't exist but was listed in my file explorer. Now, whenever your start your terminal, it will start with the same directory which is opened in your vscode. In this case, the directory didn't exist or had same issues, hence the problem.
Important!!
First, try this method.
Create a dummy directory anywhere on your PC, except the present directory that
is open in your Explorer.
Save any thing that is open.
Open the dummy directory that you created File > Open a folder > 'Your Folder'
Try opening integrated terminal using View > Terminal.
If this works, then there's a problem with the directory. Create a new directory and migrate all files to that directory.
If not, then try changing the settings listed here in other answers or check whether VSCode is running in Compatibility Mode or not.
I had the same Exit code 1.. And found the solution as below..
Open the settings on Visual Studio Code and click Edit in settings.json as marked:
Change the terminal.integrated.shell.windows settings on the red marked line as you see:
just uncheck "Run this program in compatibility mode for" checkbox in Compatibility tab of the VSCode properties, click in OK and apply and restart VSCode.