blog.plee.me About software, technology and random things

7Sep/170

Open PhpStorm From Windows Explorer Context Menu For Directories

Hello!

If you are a bit lazy like me and just want to simply open PhpStorm from the directory that you've currently navigated to in Windows Explorer, you can use this .reg file to add the registry entries for the entry in the context menu.

Warning: This involves messing around a bit with the registry. Please make sure you understand what you are doing!

This .reg file assumes that the path to your PhpStorm installation is C:\Program Files (x86)\JetBrains\PhpStorm 2017\. If it is not, just search and replace every occurrence of the path in the .reg file with the one that applies for you. Remember to escape backslashes with a backslash!

Windows Registry Editor Version 5.00

[-HKEY_CLASSES_ROOT\*\shell\Aphpstorm]
[-HKEY_CLASSES_ROOT\Folder\shell\Aphpstorm]
[-HKEY_CLASSES_ROOT\Directory\Background\shell\Aphpstorm]

[HKEY_CLASSES_ROOT\*\shell\Aphpstorm]
@="Open Directory in PhpStorm"
"Icon"="C:\\Program Files (x86)\\JetBrains\\PhpStorm 2017\\bin\\phpstorm64.exe"

[HKEY_CLASSES_ROOT\*\shell\Aphpstorm\command]
@="C:\\Program Files (x86)\\JetBrains\\PhpStorm 2017\\bin\\phpstorm64.exe \"%1\""

[HKEY_CLASSES_ROOT\Folder\shell\Aphpstorm]
@="Open Directory in PhpStorm"
"Icon"="C:\\Program Files (x86)\\JetBrains\\PhpStorm 2017\\bin\\phpstorm64.exe"

[HKEY_CLASSES_ROOT\Folder\shell\Aphpstorm\command]
@="C:\\Program Files (x86)\\JetBrains\\PhpStorm 2017\\bin\\phpstorm64.exe \"%1\""

[HKEY_CLASSES_ROOT\Directory\Background\shell\Aphpstorm]
@="Open Directory in PhpStorm"
"Icon"="C:\\Program Files (x86)\\JetBrains\\PhpStorm 2017\\bin\\phpstorm64.exe"
;"NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\Directory\Background\shell\Aphpstorm\command]
@="C:\\Program Files (x86)\\JetBrains\\PhpStorm 2017\\bin\\phpstorm64.exe \"%V\""

Instructions: Just copy the text into a text file, save it as a file with the .reg extension (e.g. "phpstorm.reg") and execute it via double-click. When asked if you want to continue modifying the registry, confirm with "Yes".

Note: You might wonder why the registry paths contain a segment called "Aphpstorm" instead of "phpstorm" (or anything else). This is so that this entry takes alphabetic precedence over other entries and it is sorted further up. It will not influence the text displayed in the context menu.

Unfortunately I do not know the exact source for this neat little trick because I got this from a colleague at work.

If you wish to revert these changes at some point, just do what the first three instructions in the .reg file do: delete the 3 appropriate keys in the registry.

I hope this is useful to you! It sure is for me.

Thanks for reading!

7Jun/150

Memory Leaks / Problems with Long-Running Symfony / Doctrine Console Applications

Hi!

I recently built several console applications that have to keep running as daemons as part of a more complex website. As soon as I added Doctrine for its highly comfortable ORM functionality, I noticed a significant increase in the applications' memory usage, which made sense because it would load Doctrine's code in order to use it. The worst part of it, however, was that the processes kept eating up more and more memory the longer they ran and with each Doctrine query they executed. Finally the processes ended up being killed by Linux's OOM Killer due to the high amount of memory that they wanted allocated for them.

Clearing the Doctrine Entity Manager ($entityManager->clear()) and triggering PHP's garbage collection manually did not help at all. So I assumed it had something to do with the data that Doctrine accumulates in the background.

During my research I finally stumbled upon this Stack Overflow question: Memory leaks Symfony2 Doctrine2 / exceed memory limit

Apparently, Doctrine uses an SQL Logger to log each and every query it uses when running in debug mode.

Due to the nature of Symfony console applications starting up in the dev environment by default when launching them from the command line, it also kept enabling the debug mode. That in turn enabled the SQL Logger which gathered more and more data and kept it in memory.

I decided to launch the processes by simply manually disabling the debug flag. Using the dev environment is not a problem for me, so I just did the following:

$ php app/console custom:command --no-debug

You could also set the environment variable SYMFONY_DEBUG to 0 before launching the command without the --no-debug flag, as it also respects its value - refer to app/console's source code.

Alternatively, you could start it in a non-dev environment:

$ php app/console custom:command --env=prod

or

$ php app/console custom:command -e prod

or just set the environment variable SYMFONY_ENV before launching it.

This way, the SQL Logger is not enabled.

My processes have been running at stable memory usage size ever since.

Another way would be to deactivate the SQL Logger in the code by principle, but that would be defeating the purpose of the nice built-in features of enabling/disabling the debugging mode, so I rather chose the first path. It might come in handy sooner or later after all, and reverting those changes just to re-enable the SQL Logger would be an unnecessary pain.

I hope this was helpful to you. It certainly took me some time to get behind it.

8Jun/090

Compiling PHP 5 with IMAP support on SuSE / openSUSE Linux

If you get the following configure error:

configure: error: utf8_mime2text() has old signature, but U8T_CANONICAL
is present. This should not happen. Check config.log for additional
information.

It's probably because you're missing either the libc-client-devel package or imap-lib and imap-devel. Fire up yast and install those. You should be good to go now 🙂

(I have openSUSE 11.0 and it doesn't have the libc-client-devel package, but I read about it on another page and thought I'd add it, just to be safe 🙂 )