I'd like Flash Builder to kill previous run instances when I run/debug.
It's driving me nuts that I can easily accumulate multiple instances of my project running outdated code if I don't go through and kill them individually each time I run.
Thank you
This is the best answer I was able to find thanks to Lee Burrows:
There is an unbound keybinding called "Terminate and Relaunch" in the general preferences which will terminate the run/debug that is currently connected to the debugger and start a new instance. So if you only use this you can avoid accumulating outdated instances.
Putting this as an answer, but I hope someone can make something that doesn't require a change in flow (still be able to use the debug button), and this will also not kill multiple instances if that somehow still happens.
Related
VScode displays this status when I open it:
Installing Kotlin Language Server...
It takes a long time to go away. It also seems to make it impossible for me to debug my Android projects.
How can I know how long it will take to complete?
Is it possible and safe to cancel the operation?
I don't believe I use Kotlin in my projects, so I don't think I need it.
update:
Restart computer not solve this. it still become Installing.
Is it possible to show progress (like percent: 20%) ? I waiting for a while now, but I don't know when it can be finished.
For me made Disable the Kotlin extension in vscode make the error go away :)
Currently experiencing very slow debug start up times (between 25-45 seconds) with idea CE 14.1.5. To reproduce:
Make change in code that will cause javac to be invoked.
Hit debug.
Status bar shows "Make" and entire IDE hangs.
I'm using a 2015 Macbook pro and Java 1.8.0_60 64bit.
After profiling with advice from above, I tracked it down to this issue:
IntelliJ freezes for about 30 seconds before debugging
Which in turn points to an issue with InetAddress.getLocalHost() on *nix. Following the advice in this linked post certainly helped it go away:
InetAddress.getLocalHost() throws UnknownHostException
I had similar problems of starting debugging application and tried different workaround tips to figure it out, but in my case i had a lot of forgotten breakpoints marked in application and removing them all application starts and performs lightening fast.
So, my advice remove all the breakpoints from the code at least at application startup.
You should assign more memory. This almost always reduces lagging / hanging issues. You can find a guide how to change this setting in IntelliJ manual.
Suppose I am running a Sikuli program and I want to pause the program at a particular point and then after sometime I want to resume the program from that point where I paused, without affecting the process. And then I want to stop the process and exit from it. The point where I stopped till that it should be saved. Is it possible in Sikuli? If yes, then how?
Press Alt+Shift+c to kill a running Sikuli script.
No, Sikuli has no built-in capability to manage this for you. However, you can write all of these capabilities into your script or otherwise get them.
Pausing an resuming is most easily done on the Unix command-line, where you can use control-z to suspend a program and fg to resume it. Windows has similar capabilities. Look for "suspend and resume process " to find some ways of doing this (there are many).
Exiting from a program and then being able to re-start the program and have it resume (roughly) where it left off is called "checkpointing". The checkpointing packages I know of are intended for distributed computing and would probably be overkill for what you're doing, but you could take a look at the Wikipedia entry for suggestions. I suspect that implementing it yourself will be the easiest way to go.
For help with either of these topics, I recommend starting a new question specifying the language you're using (Jython or Java) and the operating system (Unix or Windows). The questions and answers to these aren't related to Sikuli.
For pause, you can use wait commands; if you want to resume, you need to have flags that you set at the beginning of the script, and change accordingly to what you want to wait for.
For closing the script; you can use the Type command wherever you want the script to quit; which is the equivalent of pressing CMD-Shift-C when using the IDE
type('c', KeyModifier.CMD + KeyModifier.SHIFT)
Hope this helps
I'm writing an ant script to rebuild our database i.e. dropping everything and rebuilding from scratch. The problem our DBA adds a Y/N prompt before executing the rest of the script, and therefore we can't call this from an automated build process.
Does anyone have any suggestions to circumvent the Y/N prompt? Obviously we could create separate scripts, one for the DBA's and one for the automated build - but this requires maintaining both. We're running on Windows so it's not as easy as using sed to strip out the prompt...but I'm thinking something along those lines.
Not sure if that's clear enough but hope you can help.
Cheers.
Maybe Expect would help?
http://en.wikipedia.org/wiki/Expect
Seems like the DBA should be thinking more automation and make the script not pop up a gui yes no dialog. How about they make the yes no a command line option. I think you can jump through hoops to get past this, but push the work on the part of the process that needs to be reworked.
Take a look at AutoIT
This will let you possibly find the dialog and the yes button and automate the clicking. But I still say the DBA should move away from the GUI for this yes no input.
Whether this is possible I don't know, but it would mighty useful!
I have a process that fails periodically (running in Windows 2000). I then have just one chance to react to it before having to restart it and painfully wait for it to fail again. I didn't write the process so don't have the source to debug. The failure is seemingly random.
With a snapshot of the process I could repeatedly and quickly test reactions to the failure.
I had thought of running inside a VM but this isn't possible in this instance.
EDIT:
#Jon Cage asked:
When you say a snapshot, you mean capturing a process when it's about to fail (including memory, program state etc. etc.) ...and then replaying it's final few seconds repeatedly to see what effect it has on some other component?
This is exactly what I mean!
I think minidump is what you are looking for.
You can also used Userdump:
The User Mode Process Dumper
(userdump) dumps any running Win32
processes memory image (including
system processes such as csrss.exe,
winlogon.exe, services.exe, etc) on
the fly, without attaching a debugger,
or terminating target processes.
Generated dump file can be analyzed or
debugged by using the standard
debugging tools.
This article shows you how to use it.
My best bet is to start the process in a debugger (OllyDbg being my preferred tool).
The process will pause on an exception, and you can try to figure out what happened shortly before that.
This needs some understanding of assembler and does not allow to create a snapshot of the process for later analysis. You would need to write your own debugger for that - it should be theoretically possible.