I've had a problem since version 6
When we set this to opcache, it won't be saved on the next restart we see it says unsaved changes want to start? if you say yes it will still load opcache but as soon as you save it, it will be off again.
That actually means it was saved but cause of a bug, Mamp Pro UI isn't able to load that to its own UI.
So how to get rid of that warning everytime we restart the system or mac itself?
As I mentioned this is a bug in MAMP PRO making mamp unable to understand that opcache is actually on, it thinks it's off and when you save the changes it will literally get off. We can leave that to off, but enable opcache ourselves, that way everything will be solved.
First click on Open template so you can open php.ini for your current php version.
First copy the whole content of this file and get yourself a backup of it.
in the opened editor you can search for opcache and you'll find a section about it, comment it all and enable the options you want, make sure you set opcache.enable=1
[opcache]
;MAMP_OPcache_MAMPzend_extension="/Applications/MAMP/bin/php/php8.1.1/lib/php/extensions/no-debug-non-zts-20210902/opcache.so"
; Standard settings, see below for detailed explanation
; opcache.enable=1
; opcache.enable_cli=1
; opcache.memory_consumption=128
; opcache.interned_strings_buffer=8
; opcache.max_accelerated_files=10000
; opcache.revalidate_freq=2
; opcache.fast_shutdown=0
; opcache.jit_buffer_size=100M ; needs opcache.enable=1
; opcache.jit=1255
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=80
opcache.max_accelerated_files=100000
opcache.enable_cli=0
opcache.jit_buffer_size=150M ; needs opcache.enable=1
opcache.jit=1255
Now from the second line of the above block, you can find
;MAMP_OPcache_MAMPzend_extension="/Applications/MAMP/bin/php/php8.1.1/lib/php/extensions/no-debug-non-zts-20210902/opcache.so"
That's what we need to enable opcache manually just omit ;MAMP_OPcache_MAMP and you'll get something like
zend_extension="/Applications/MAMP/bin/php/php8.1.1/lib/php/extensions/no-debug-non-zts-20210902/opcache.so"
Great, all you have to do now is to put this at the end of your editor.
Close the editor and save it, now turn off the opcache in the UI if it's on, and you'll still have it on, you won't get an annoying warning and saving won't turn it off anymore.
If you ever wanted to disable opcache just comment that last line that you added in the editor.
Related
I've just updated a major C++ project from VS2010 to VS2019, and I'm having problems getting Edit and Continue to work like it used to, specifically in relation to the 'Require source files to exactly match the original version' setting (which I will refer to as the 'require match' setting, because it's shorter).
I'm used to running my program, making changes to the source code while it's running, then setting a breakpoint to catch the running application just before the changed code. When the breakpoint is hit, I could hit F5 to rebuild and continue.
In VS2019, it seems that Edit and Continue will not work without the 'require match' setting, but setting breakpoints in existing code cannot be done with 'require match' once any changes are made.
There's a couple of workarounds, but none are ideal. It's possible to turn on "require match" to build and run the program, then after some code changes are made, turn it off to set the breakpoint, then turn it back on again for the rebuild and continue. That's a huge pain. It's possible to use pause and continue to force a rebuild of any edits, but this only works if the code change is complete enough to build. If I want to break to inspect a variable, this doesn't work. Once or twice I did manage to set a breakpoint on changed code, and it automatically went to the stale code, which is acceptable, but I can't get this to happen now. Also, now I have breakpoints that are showing as valid on edited code that has been rebuilt and I know is running, but the breakpoints are not being hit.
Any solutions here, or does Edit and Continue simply not work as well as it used to?
Here's some pictures...
Firstly, while my program is running, I made some change to surfdraw_panels.cpp, then went to add a breakpoint. It shows the following message...
Then loads up a [stale] version of the code, with the breakpoint set in the stale code...
Other times, when I make a change, I get a different result, and it won't allow me to set a breakpoint at all... In VS2010, it was possible to turn off the 'require match' setting and still use 'Edit and continue', but VS2019 will not allow this, even though it is still the recommended 'solution' in the message!
Github project that shows the issue is below. It's a simple MFC app, dialog based, created by the new project wizard in VS2019. There is a single button on the dialog, and some simple code to do something in the button. To recreate the problem, start the app in the debugger, then make a change to OnBnClickedButton1(), and then try to set a breakpoint.
https://github.com/surfdabbler/MFCApplication1
Not quite understand your specific situation and operation, because there are not some pictures and code to explain the issue in detail.
But this function which I used could break into the changed code during debugging with require match option. You should move your cursor back to the changed code and then Debug the below code step by step. And when you move the cursor back to the changed code, vc++ project will rebuild the changed code automatically and you do not have to stop debugging and restart build.
Update 1
I also faced the same behavior in my side. And since we could not handle the issue here any more, I reported the issue on our DC Forum.
You can vote it and add any comments if I did not describe the issue in detail so that it will get more Microsoft's attention. And I hope the Team will give you a satisfactory reply.
Last weekend my iMac stopped working (sorry forget the symptom details). I tried Disk Utility but it was unable to fix the issue. After I restarted in recovery mode I was able fix the SSD and HD partitions but ended up with a third item. My fusion drive seemed to be split. I found an Apple Support document: https://support.apple.com/en-us/HT207584 and ran 'diskutil cs create Macintosh\ HD disk0 disk1' from the terminal. This seemed to fix the drive.
I was able restore from Time Machine back-up. Got my old mail from BackBlaze. Seemed OK. However, downloaded files (with Safari) gave an error "File damaged and can't be opened. Drag to Trash". I found a fix for file-by-file repair, i.e. xattr -cr Path-to_file. Seemed to work but tedious and didn't really fix the problem. I thought I might make an Automator Folder action to fix the apparent problem with the extended attributes (addressed by the xattr) command. However, when I dragged an (any?) action into the workflow pane I get an error "The action 'Ask the Finder Items' was not loaded because it was detected as malware.
I'm starting to think there is a global permission flag that needs to be flipped.
Any suggestions ideas. Thanks.
Update of sorts. Other files restored from Time Machine are complaining to be damaged not just new downloads.
As reported elsewhere I replaced the file /var/db/gkopaque.bundle with the same file from my laptop via Airdrop. So far so good. Files can be opened. Automator also seems to be working.
I'm hoping someone can help me out.
I often find myself wanting to print figures in separate windows in iPython Notebook and within my browser when writing code and analysing figures, but keep running into a problem.
I noticed that if I add "%matplotlib inline" to my code somewhere to print the plots in the browser, but then remove it, the code continues to print the plot in the browser and not open in a new window. The only way around this I find is to just close the notebook and reopen it entirely from the command line.
Does anyone know of a simple "%" argument to place in the code that will reset it so that it prints plots to separate windows?
Just removing %matplotlib inline will not remove the effect the command had - which is in effect until the kernel is restarted (through notebook's menu) or until another gui is explicitly called (like %matplotlib qt or another one depending on your environment). See more in the docs.
Since some days I am having strange problems related to JetBrains Webstorm. I have set some breakpoints in index.html (some javascript functions defined in script tags), but when I debug an application, I see app stopping on different points, or pretending to stop on lines not existing in file index.html (line 272, in a file with 270 lines).
Who knows what is happening? invalidating cache and restarting don't have any effects. The only things to do is to remove all breakpoints and set them again: for the first time, it works as expected, but on next times it doesn't work at all.
It seems that this happens after I made a little mistake. When you rerun a app already running, usually Webstorm ask you if you want to stop currently running instance and starts new one; I was wrong, and I checked "Don't ask again" checkbox, so this popup doesn't show anymore. How can I restore original behaviour?
To restore original behavior (showing a dialog on restarting current debug session), remove <property name="restartRequiresConfirmation" value="false" /> key from .idea/workspace.xml.
the breakpoints issue is likely caused by having several embedded script tags in .html - see WEB-14466
Question has been asked before and I see bug report on ddd newsgroups but none of the suggested solutions work for me.
It comes up but when you try doing anything like opening a file it hangs with the message "waiting until GDB gets ready."
A crucial fact, reported by others too, is that it works fine for some users and not others. I've compared the environments and can't find any significant differences. Any suggestions will be most appreciated.
Encountered this problem too. The easy solution as posted above is to delete the init file in the ~/.ddd/ directory.
But that means all your customizations will be gone. So I started hunting for the real cause. I observed that the problem only occurs after I have used the "GDB Settings" dialog. Once you opened this dialog the init file mentioned above will grow because a lot of gdb settings will be stored there.
After shrinking those additional lines step by step I found the "offending line".
The problem is caused by the setting for extended-prompt. After opening the GDB settings dialog this line will read like
set extended-prompt not set\n\
This "not set" is what gdb will report on "show extended-prompt". Unfortunatley "set extended-prompt
is sort of buggy in gdb, so if I enter "set extended-prompt not set" in a gdb running from a shell without ddd involved gdb will lockup as well.
It looks like the only safe way of setting the extend-prompt is when it contains the string "(gdb)". So I modified the offending line in the init file and now it reads like this:
set extended-prompt (gdb) \n\
With this setting I do not encounter the problem any longer. Hope that helps in your case too.
Removing ~/.ddd seams to solve the problem.
Doing a Ctrl+D, then choosing "Restart DDD" seems to work for me.
The problem arises when opening the GDB Settings... window, even without touching any setting.
Because removing the entire ~/.ddd/ configuration directory every time is not a way to go if you have customized your DDD environment, I have found a solution to fix the ~/.ddd/init file that could help you too without removing the entire configuration.
Close DDD and open with your text editor the file
~/.ddd/init
Search the line
set extended-prompt not set\n\
and remove it or replace it with
set extended-prompt \n\
Save and run DDD. It will start as it should.
Because this task can be tedious to repeat every time, especially if you change gdb settings quite often like me, I suggest you to create an alias in your shell environment like this.
alias fix-ddd="sed '/not set/d' -i $HOME/.ddd/init"
This last approach has the advantage that it will work for any bugged setting in the init file, without your specific intervention.
If you don't want to use the cli to fix the init file another approach is to edit the init file as suggested previously and if it happens to you to open for any reason the GDB Settings... panel then remember to disable in the Edit menu the option Save Options and leave it disabled until the next DDD restart.
For the sake of completeness (as stated by #hmogal) hitting
CTRL+d
during the GDB hanging kills GDB and restarts it allowing use DDD. Unfortunately this approach is not a good solution because it erases the entire GDB configuration inside the init file, even settings specifically tuned by you. So pay attention.
Everything tested with DDD 3.2.12.
I think removing the init file inside .ddd will also solve this issue. No need to remove the entire .ddd folder. I tried it and it worked !
Also, if you extensively modify the ddd default options such as Buttons and Graph Displays, you can move your init file to outside this folder and then copy some of the options back to the init file created by ddd by default.
Note: When you restart ddd after removing init file, it will create the default init file.
If the issue persists, the following workaround may help:
open ddd as you would normally (eg. ddd --debugger bashdb script.sh)
type exit in the lower pane of ddd
This seems to kill one instance of bashdb, and then another instance of bashdb seems to run. This 2nd instance of bashdb seems to work fine, with the bash-script source finally appearing in the top-pane and allowing you to step-through and debug.
Using Ctrl+D pops up a dialog box asking to restart GDB which fixes the issue. In my case deleting ~/.ddd or init file in this particular folder didn't help.
Decipher's suggestion of simply deleting the init file worked for me as well.
And for those that don't know, ~/.ddd is the .ddd folder in your home directory.