I have remote_autostart disabled and no cookie present:
Still, Xdebug is connecting to my IDE (PhpStorm) at 192.168.22.101:9000 and zero-config debugging works. Why? How do I disable it? (It looks like autostart is somehow enabled and the PHP app is slow.)
My first bet would be that this is not the php.ini you're looking for. If you have CLI and normal php.ini, make sure you have this set up in both. Integrated PHP server counter-intuitively uses web php.ini instead of CLI one.
Next step would be to check whether it's actually xdebug that's causing the issue. I'd do that by disabling the extension alltogether.
Note that xdebug can slow down you app in some cases no matter what just by being enabled.
Next I'd check that xdebug profiler information is not generated. If the app is slow in general it's the profiler. If it just hangs for few seconds and then runs normally it's waiting for remote debugger. Might be a good idea to measure (even by simple means like putting dump on first and last line of code) speed of the app to rule out this possibility.
I have been having exactly the same issue for a few days now. remote_autostart is set to off but it still triggers even on my own <?php phpinfo(); script. The debugging session even starts when using an incognito browser session.
Notice the odd IDE key btw, it is set automatically.
Update: Even with xdebug.default_enable on off, it still activates Xdebug in my IDE.
Related
Following https://docs.hiro.so/smart-contracts/devnet I can't get the command clarinet integrate to work. I have installed Docker on my mac and am running version 0.28.0 of clarinet. Running command within 'my-react-app/clarinet' where all clarity related files live (contracts, settings, tests, and Clarinet.toml).
My guess is it could be an issue with Docker?
The issue was that I downloaded my Devnet.toml file from a repo that was configured incorrectly. The configuration I needed was:
[network]
name = "devnet"
I increased the CPU and Memory in Docker as well.
There is an issue when the command attempts to spin up the stacks explorer, but I was informed that there are several existing issues with the stacks explorer from clarinet integrate at the moment.
Depending on how the last devnet was terminated, you could have some containers running. This issue should be fixed in the next incoming release, meanwhile, you'd need to terminate this stale containers manually.
Apart from Ludo's suggestions, I'd also look into your Docker resources. The default CPU/memory allocation should allow you to get started with Clarinet, but just in case, you could alter it to see if that makes a difference. Here's my settings for your reference:
Alternatively, to tease things out, you could reuse one of the samples (eg: hirosystems/stacks-billboard) instead of running your project. See if the sample comes up as expected; if it does, there could be something missing in your project.
I am writing to ask about --disable-features=SameSiteByDefaultCookies feature which was part of chrome earlier.
I am working with IT MNC and recently we promoted very important functionality to Production. We have started charging customer for this. It is legacy application .
This application can't be tested locally anymore! Earlier we could point out application to lower environment with custom settings in project's config.js file and disabling #same-site-by-default-cookies in Chrome and application could be tested locally. But now we can't!
We tried many different settings and debugged but it could not help !!
It is noted that these settings no longer work in Chrome 94+. These flags are removed entirely.
As per my analysis it is found that application still can be tested locally if we get the portable Chrome. Or older version of Chrome installed in our System. However as per the compliance policy of company and client, we can't get old or portable chrome in system. We have latest version only.
Earlier we used to perform following to run it locally:
Open CMD
cd to Chrome path ( Till Application )
Fire the following command:
chrome.exe --disable-web-security --user-data-dir=C:\XXXX\XXXX\localwlp --disable-features=SameSiteByDefaultCookies"
This would open a new window of Chrome ( Close all before firing the command) and then we could test the application locally.
Anybody is aware about the alternative for this? That would be really helpful. We can't test the application locally so for even small changes, we require to deploy on lower environments which takes a lot of time and also code will work or not can't say.
I look forward to hearing from you all guys.
Thanks,
Kailash Nirmal.
I'm developing a GWT application, and I'm having issues with testing in development mode in eclipse.
When I make changes to the client-side code, I refresh the browser page (F5) to reload the module. Every time I do this (whether the code has changed or not), the Development Tab in eclipse shows a new bullet point with "Module xxxx has loaded". As well, according to Task Manager, every time I do this, the javaw.exe host process increases by about 1MB of memory. Eventually (10-20 refreshes later), the page fails to load and the Development Mode tab shows this error:
Out of memory; to increase the amount of memory, use the -Xmx flag at startup (java -Xmx128M ...)
I can fix this by stopping and restarting the server (not the little refresh button in the Developer Mode tab, but the red stop button), but it then the module has to be revalidated, which takes a while. It seems that eclipse doesn't realize I've finished with the old module when I reload a new one. I'm observing the same behavior with a brand-new GWT project, so I don't think it's my code. Is anyone aware of a way to remedy this?
EDIT: See both answers below for possible solutions.
The default settings gwt dev mode use are the minimum , so you hit an out of memory really quickly.
From this you can see that the permgenspace is to low and if you refresh 20 times in a short periode it will go out of memory.
you can start by using following vmargs :
-Xms512m -Xmx512m -XX:MaxPermSize=256M -XX:+UseParallelGC
But as enrybo pointed out if your application grows it requires more memory:
-Xms512m -Xmx1g -XX:MaxPermSize=256M -XX:+UseParallelGC
There isn't really all that much you can do. As you mentioned you can increase the memory but eventually you'll run into the same problem even with more allocated memory.
I suggest you try to run in Super Dev Mode but in that case you'll need to update the SDK you're using to 2.5.1+. With Super Dev Mode your browser does not need a plugin because it will actually be running true Javascript. You even have the ability to debug in your browser but looking at your Java source (using source maps).
For one of the customers of my company, I have to get Gears working. To explain briefly, they have a site using the Gears local database and now want to really use localStorage (at least for browsers supporting it and still use Gears for the old ones).
To refactor the code and ensure that the HTML5 version works as the Gears version used to work (and that I do not break the existing system is also a plus). And here comes the problem: Gears is not supported anymore and seems unable to install.
My dev' machine is using OSX Snow leopard. I tried the Gears custom installer made by the authors of MailPlane (http://mailplaneapp.com/download/google_gears/) to enable gears on Safari. The installer runs without any issue and I have a "Google Gears settings" entry in Safari's menu. But the code does not work, here's the console output for the database creation code:
> google.gears.factory.create('beta.desktop')
Error
line: 2
message: "'undefined' is not a function (evaluating 'google.gears.factory.create('beta.desktop')')"
sourceId: 419639712
__proto__: Error
(this is the code I got from the customer).
In the console, when I try accessing the Gears factory, I just get a simple html object:
> google.gears.factory
<object style="display: none; " width="0" height="0" type="application/x-googlegears"></object>
In Gears preferencies, there's a site of sites for which I can allow Gears to run, but I can't add localhost there (I can't add anything in fact).
As I can't get Safari/Gears working, I decided to setup a WinXP virtual machine, maybe it would work here.
I was able to download the Gears installer. But this one needs file that have been removed from Google servers (at least I guess, but I don't have any firewall installed so I don't see what could block the installer when getting the files ...).
I also tried old Chrome installers (apparently Gears was shipped in Chrome 12-) but none of the installers work (they just, well, do nothing. I even tried to start them from the command line to expect a bit of output but I got nothing).
Another option would be to get a Firefox gears add-on, but they all seem to have disappeared :/
So, the question (finally): does anyone here still have to use Gears and how do you get it running on new machines ?
Cheers,
Vincent
I think The Google Gears API is no longer available.
Please see https://developers.google.com/gears/ page.
Thanks,
Jigar
I spent some time debugging a SL3 application with VS 2010 in IE9 beta today and noticed a few quirks. Sometimes when launching the Silverlight app in VS it fails to load in the browser, but refreshing with F5 tends to fix the problem. Also, there are sporadic scripting errors that pop up a debug dialog - these also seem to be fixed by refreshing the page. Has anyone run into these problems and found a fix?
EDIT: My most prevalent error is:
Error: ASP.NET Ajax client-side framework failed to load.
I don't understand why, but someone without a name at the Silverlight forums has found a solution that worked for me:
Just add or uncomment this entry to your hosts file (%SystemRoot%\system32\drivers\etc\hosts):
127.0.0.1 localhost
I noticed this as well with Silverlight 4, but also when I start a simple web project.
IE9 has a shorter startup time that IE8. Debugging a Silverlight application starts the development web server to host the http:// site. The time that it took to start up the web server was less than the time to start up IE8 and greater than the time it takes to start up IE9.
#Michael S. Scherotter - It can't be because of the shorter startup time because making the host file change which fixed it for me would have zero impact on app startup time. Something else must be causing the browser and Cassini to not talk to each other correctly.
One other fix, related to the others is to change the StartURL to launch to the loop back address directly, rather than editing the hosts file. So, in one app, I've got this as the start URL:
http://127.0.0.1.:60525/
Of course, to make this work consistently, I've selected a "specific port" in configuration, as 60525 in this case.
(the trailing . after the loop back address is to allow Fiddler to do its magic).