Started using the Cloud9, for small practices with Nodejs, my apps are always very simple.
I noticed, that on the first time I launched the workspace, terminal works fine and responds immediately. But after a few executions or few minutes, it starts freezing and my typing responds in a few seconds, but not immediatelly.
I am using the free account. But my performance(CPU, RAM) parameters(in the top right corner) are absolutley okay.
So is it a c9.io server trouble? Or it is about javascript in my browser? And how can I make my work easier there?
updt1: Text editor area and workplace navigation area works absolutley fine. The only thing works badly - terminal.
updt2: When I am opening a new Terminal it works fast again.
I had the same issue and noticed when the terminal was freezing, there was a message "Updating Git..." in the lower left of the screen. Anytime git does an auto-refresh, it seems to hang up the terminal. If you don't need the git autorefresh feature, you can turn it off as follows.
In Preferences, look under Extensions / Git, there is a setting "Git: Autorefresh". Turn it off.
Ideally, this is something AWS should be able to fix. This is just a work-around.
Related
We got users complaining that accessing remote client on Remote Desktop does not bring up anything. When I try logging in to its Azure AVD, it opens up with a black screen and disappears in a second.
A simple start and stop on Azure portal seems to have fixed the problem. A restart did not fix it though. But, I am not sure why it happened in the first place and couldn't find a reason for it. Could anyone offer some suggestions please?
I tried to reproduce same in my environment. I got same error.
To resolve this issue, try the below.
The reason of this issue is slow sign-in process A black screen will appear for a while, until the regular desktop appears.
When the back screen shows to return to the previous screen, press CTRL + ALT + END. This launches Task Manager you will see the Desktop right away after Task Manager is called like below:
Make sure to disable the Bitmap Caching on the Remote Desktop Protocol (RDP) client like below.
Persistent bitmap caching is the combination of memory caching and glyphs. It will be reused throughout client sessions and also provide a bigger amount of cache space, which will result in a black screen.
And try to adjust Display size of your remote host's display like below:
Now I am able to connect RDP without any issue like below.
I'm using pgAdmin 4 (v. 6.12) on Windows 10.
Since (I believe) version 6.10 I've noticed that autocomplete always shows up. I tried to change preferences settings to only show it on Ctrl + space:
But it made no difference - autocomplete is always shown.
Then I've noticed, that some other settings are not respected, for example insert bracket pairs:
This is how editor looks just after typing opening bracket:
This is very annoying. I've completely removed previous installation of pgAdmin: uninstalled it, deleted all files and folders with pgAdmin in name and did the same in Windows registry. But new installation behaves the same.
New installation was made only for my user account, not for Anyone who uses this computer option.
Like you, I was also unable to turn off autocomplete-on-type after installing 6.12.
When using the web client, I was able to log out and log back in to solve it.
UPDATE from comments: using the Windows application, Adam was able to clean session data from the registry, open the editor window, change settings, close editor window, change settings… And it started to work again.
More details...
It happened to me in Ubuntu when I first upgraded to 6.12 and restarted the server, while the client was connected. The web client appears to have held on to a session that at first seemed to work. Once I logged out and log back in, my autocomplete-on-type OFF setting was respected again.
I agree that this bug is completely frustrating. I'm not sure why anyone would want the autocomplete-on-type setting enabled, pgadmin4 is unusable with it on.
I have my work computer which is a Windows 10 Pro and my laptop is a Windows 10 Home. Working on the same project on both: push and pull to Git. Learning React through Udemy. Both computers using Chrome. Both using Bash on Ubuntu on Windows with latest updates. Both using ConEmu for the console. Both npm -v = 3.10.10. Both node -v = 6.11.2. Hardware is different obviously, but not sure that is relevant and worth listing.
Anyway, this starter project I am playing around with, when I make changes to it and npm start is running, you can see activity in the console, hit refresh in the browser, and any changes made will be reflected.
On the laptop, this process does not work. Make change, save, no activity in console, refresh in browser does not reflect the changes. Have to restart npm start for changes to be reflected. A little irritating to say the least.
Anyway idea what might cause this? Really haven't come across anything in my Googling efforts.
If you are using npm in WSL2.0 for development, please refer the last point in this-
https://create-react-app.dev/docs/troubleshooting/#npm-start-doesnt-detect-changes
While WSL1.0 doesn't use a VM, WSL2.0 does use a lightweight VM, so adding
CHOKIDAR_USEPOLLING=true
in a .env file in the project directory fixed the problem.
On a sidenote, you might wanna take a look at this
Client side
To ensure client side changes aren't being cached, you can open devtools > Network, and check "Disable cache". After enabling this, you won't have anything in the cache as long as devtools is open.
Alternatively, you can use incognito / private browsing mode to prevent the cache from holding on to things.
Server side
I'm sure you've realized that it's a pain to restart your server every time you want to see your code update. There are several tools that will detect file changes and handle restarting the server automatically.
PM2
Nodemon
Forever
I just add file .env and inside FAST_REFRESH=false.
For me, working in Windows, WSL2 caused this not to work. Running npm start in Command Prompt, not WSL solved this issue for me.
I have an MVC3 app that's been working for quite a while and today began crashing anytime I launch a debugging session with IE as the initial browser. If my initial browser is Chrome or FF - no problem. Further....if I open the site with IE _after it's been launched to one of these other browsers, no problem. The debugger's break points respond just as expected. So that's pretty strange, yes?
I can F10 without hitting any problems until the point where the browser is invoked and, up to this point, haven't been able to catch the last couple lines in VS's output windows - it crashes and restarts without giving opportunity to copy any of that output.
Event viewer shows:
Fault bucket 3561940412, type 5
Event Name: CLR20r3
Exception code: 0xe0434352
(there's more erreta if you'd like deeper details) - searching against those codes looks like it's a fairly general/generic error.
I've stepped out to the file system and deleted the .obj and .bin folders for all the projects in the solution, rebooted a couple times, and am in the process of getting on with my life cuz, as of right now, this is easy enough to work around.
I suppose i could delete windows temp files and check again. Any other thoughts?
I want to launch the browser in a different process when a particular link is clicked on the page. When I checked the net I found the following tip: http://www.dslreports.com/faq/3849 . But there we have to change the registry. Is there any simple way of doing this without touching the registry?
If you use the Google Chrome browser, each new window or tab runs in a separate process. Internet Explorer version 8 will do the same (it's currently in the second beta round).
Earlier versions of IE will run a new window in a separate process if it is launched from, say, the Start menu or the command line, or a link in an email (but not by clicking a link within IE). I imagine you could create a proxy that the client would run through, which would intercept the links you care about and launch them by running a command line request. That seems like more trouble than mucking with the registry though (assuming that registry change still works -- looks like your link is from 2002).
I don't believe this is possible unless you change the client computer setup or software it's running.
Why do you want to do this?