I am not sure if this is desired behaviour, but PhpStorm (8.0.3) proceeds to index all files and directories each time I open the IDE. The indexing takes too long - half hour and more. During that time I'm not able to access many configuration options or use "Go to definition" option.
It is very irritating. Shouldn't PhpStorm somehow cache the indices so that it does not go through the whole process over and over again?
It seems that the problem grew over time and at this time it totally paralizes my ability to work on projects.
Is there a solution to it that you know of?
is this problem still current? It's more than year since question, so it could be fixed already.
There is no reliable way to say why it's happenings without seeing the logs.
You may try this:
Close IDE (or this project at least)
Backup and delete .idea subfolder (this project settings)
Launch IDE and using "Open" point to the project root -- IDE will create new project from those files
Reconfigure your project as needed
Restart IDE / close-reopen project (do what you did in the past where it lead to project re-indexing)
It's better now?
If yes, and you have not re-configured ALL aspects of the project yet -- then you may re-use some of the files from previously
made backup (while IDE/project is closed, of course)
Try right-clicking file -> invalidate caches and restart. It worked for me!
File ==> Manage IDE Settings ==> Restore Default Settings
And now it loads rapidly
I had the same problem after searching a while I understood that .gitignore plugin caused it.
After disabling mentioned plugin ide backed to work correctly again.
Related
Would it be possible to upgrade from MediaWiki from 1.15 to the latest stable version without losing data? I believe I will have a problem with database tables and extensions.
Thank you in advance
From personal experience I would recommend to take it easy and upgrade one major version at a time, especially when you do not have much experience with the process. This bite size approach will take longer but in return you will:
have to deal with fewer issues every time something is not right,
gradually update the LocalSettings.php as you go along every time moving it from the current to new release,
familiarise yourself with the Release Notes for each version - they contain notes on the configuration and breaking changes among other things, and finally
get comfortable with the process.
This approach helped me when I was upgrading from 1.27.3 to 1.31.8 first time in years. I came across problems at least twice and could not find relevant information on how to deal with them. The most annoying was no feedback from the update.php script or blank page when trying the new installation.
Below I include notes from my experience with updating MediaWiki in case that's of any help to anyone facing a big upgrade. These are just main points, so read the official Upgrading page too.
Installation
Don't extract a MediaWiki release archive into the existing wiki installation directory. Move the old instance to some backup directory and start afresh. Also make a back-up of the database.
Create a copy of LocalSettings.php from the original installation and comment out all custom extensions and skins as they will no longer be present.
Now as you bump the versions up:
Copy LocalSettings.php from the previous instance to the directory created while extracting a release archive. There does not seem to be a way to generate a fresh default LocalSettings.php during an upgrade, which would prevent some of the problems.
Run update script in the maintenance directory. There should be some output:
$ php update.php
MediaWiki 1.31.8 Updater
...
If there is no output at all that means there is likely a problem somewhere in the LocalSettings.php configuration. See the Debugging section below.
You should be able to access the wiki now.
Get a release archive of the next major version, read the Release Notes and repeat the steps.
Once you reached the target version you can gradually copy over all the custom changes from the old wiki (extensions, modifications, images, skins etc.) remembering to enable them in LocalSettings.php.
Keeping MediaWiki under version control makes it much easier to keep track of any customisations. Just make sure you keep the repository inaccessible to the world.
Debugging
In order to debug enable the following settings in LocalSettings.php:
$wgShowExceptionDetails = true;
$wgShowDBErrorBacktrace = true;
$wgShowSQLErrors = true;
Now go to the installation page https://.../mw-config/ (adjust the URL to match your set-up) and you should see some errors that might indicate what is wrong. For example, some skins or extensions from the older version may not supported any longer and you have to disable them in LocalSettings.php.
Once the configuration has been updated try again until you get to the web installer.
Once you managed to get to the web installer page stop there and try again with update.php script. It should work now. Close the web installer, there won't be any need to run it now.
Once update.php has finished you should be able to access the wiki. Disable the debug settings in LocalSettings.php.
In theory, yes - the update mechanism is a big array of database migration scripts, which gets expanded when you upgrade the code, so the number of versions doesn't really matter. In practice, that's a long way to go, so it's very unlikely anyone else has tested that specific upgrade path. Make sure to backup first.
One notable exception is HitCounter data, which does get dropped, as that functionality was removed from MediaWiki. See that page for workarounds.
I've tried gradlew html:clean and then gradlew html:dist
however, it never uses the newest code. It will continue to grab the code from somewhere else and compile older versions of it. I got it to use the newest code once but I am not sure what I did to get it to do that. I'm not sure what files to post here to help.
For development, there are two ways possible:
If you don't need to debug and did not already compile: Use html:clean and html:superdev and make sure to delete the browser cache => You will get a fresh version of your game
If you need to debug or the game is already running: Use html:superdev if you did not already, head to localhost:8080/html, click the button to enter superdev mode (at the upper left corner) and hit recompile => You will get a fresh version of your game ready for debugging
For releasing an update of your game:
You need to enforce that all users get a fresh copy of your game. You cannot rely on all users deleting their browser cache, therefore you need to use other tricks for that (changing the directory of the game for every build, using HTTP headers...). I recommend you to use game hosting sites like GameJolt ot itch.io. They do this magic for you, and are trusted sites by players.
I found out the answer was to Shift-F5 to hard refresh the page. Chrome was caching the old info.
I have numerous programs that launch the current web browser on constructed HTML files, and it needs to open in a new window. Many places in the registry reference chrome.exe. There are so many it's hit or miss editing each to have "--new-window". I renamed chrome.exe to chrome_original.exe and replaced chrome.exe with a program I made. What my program does is pass command line arguments to chrome_original.exe, adding "--new-window" if not already present. A config file is read for options. For instance I can keep a log of invocations. There are times when adding "--new-window" is not appropriate, which can be determined by examining the log.
On my development machine the strategy works excellent, but on other machines it doesn't. On the other machines chrome loads, but just sits there with the wheel spinning. Does it test to see if the exe being run is chrome.exe? Why does it work on my development machine?
If chrome updates itself with a new version, putting things back like they were, when I redeploy my exe it will take care of that.
I need to get this working if anyone has an idea why chrome will just sit with the wheel spinning and not load a page. Thanks
To analyze the problem I recommend that you install Process Explorer from www.sysinternals.com.
There should be no Chrome "sitting around with the wheel spinning".
In Process Explorer find out which is the process, double click it and in the first tab in the window that opens you see the command line.
Compare it with the command line on the computer where it works.
Process Explorer gives you much more information, like for example the environment variables. I saw in the case of Firefox that Environment variables may be very relevant. For example when you start Firefox by your program and do not set the working directory correctly it may hang.
I resolved my issue. Chrome also runs as a background process, sitting in the tray, utilizing the same exe. When loaded, the exe file is not held open. Having the exe already loaded as one file name, then loading again as a different file name, no doubt causes confusion. What was already loaded needed to be unloaded, first. In addition, the auto start registry key value needed to be updated with the new exe file name.
I have yet to see what will happen when chrome updates itself automatically with a new version. There's a good chance the launching utility will be overwritten. Some tweaking will need to be done.
Using a launcher for chrome to intercept invocations works really well and is a good approach to always having a new window when one is wanted.
I am looking to ungracefully kill a program (Chrome) in Windows 7. Chrome has a read-lock on a .tmp file that I want to make a copy of. If I exit Chrome gracefully Chrome deletes the .tmp file as it exits.
How can I immediately kill the program without letting chrome delete my file?
It probably uses a WinAPI temporary file, so you can't:
Check http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx
Specifying the FILE_ATTRIBUTE_TEMPORARY attribute causes file systems to avoid writing data back to mass storage if sufficient cache memory is available, because an application deletes a temporary file after a handle is closed. In that case, the system can entirely avoid writing the data. Although it does not directly control data caching in the same way as the previously mentioned flags, the FILE_ATTRIBUTE_TEMPORARY attribute does tell the system to hold as much as possible in the system cache without writing and therefore may be of concern for certain applications.
You're best best is to try to copy the file while chrome is still running...
Or put a wrapper between chrome and WinAPI to override the CreateFile call so it doesn't create it as a temporary file.
First, in Chrome, use the shortcut key "Shift+Esc" to pop up the Chrome's Task Manager and kill any other processes than "Browser" (the only one that can't be killed using that).
Then, open Windows Task Manager and kill the only one "chrome.exe" that is left behind.
Download a software called unlocker from google.
http://www.filehippo.com/download_unlocker/
Go to start -> search from "chrome" and go the file location. Generally this
C:\Users\\AppData\Local\Google
Right click on google folder and click unlocker. Click all the open handles and then start the chrome. It works!!
This is an odd freeze. When I switch from source view to design view for an HTML or ASPX file, the client area freezes, but I can still click on other tabs and menus.
What am I missing here? Really don't feel like reinstalling VS2008.
I had the same problem, and found one resolution.
In VS 2008, In a page that was using a master page, the either frequency while working in source view or switching to design view, IDE would freeze for 10-20 seconds.
In my master template, I had references to the Google hosted JQuery, Jquery UI, and one or two more scripts off site. These were placed directly in my master page's head section.
I downloaded the js and then by deleting any offsite references, my IDE would be smooth again in both design and source mode.
I also discovered I could put the scripts inside my ToolkitScriptManager (I'm using AjaxControlToolkit) and added the Mode="Release", and could place the http://www.google.com references for the scripts. The IDE is still working fine for me.
This is often due to the Design mode downloading external resources that are timing out. As #JonK mentioned, for him it was jQuery references. I have seen this when the ConnectionString was set to production databases that could not be accessed on my development machine, even though I wasn't debugging (running) the site only editing code, it would still try to connect and because it couldn't it would stall waiting for the timeout.
VS2008 is mostly single-threaded for UI operations like this, so if it is downloading a slow or non-existent network path it hangs like this.
VS2008 can make all kinds of network requests, so these two examples may not solve it for you. The best way I have found to diagnose the problem is to use the Microsoft tool Process Monitor, filter by the Process webdev.exe, and watch for I/O requests that are long running and/or throwing errors. In my case, I could find the place that was having a problem because there would be a 20 second gap in between the hundreds of I/O entries in Process Monitor. Then, just back-tracked from when that gap began and I eventually found the request that was causing the problem.
This may not be possible for you, but if you can, an upgrade to VS2010 would help; it does a much better job of running process on multiple threads in more places so you don't have to worry about this as much.
Have you tried restarting your computer and then reopening your project?