I am running flashdevelop on windows 10 . when I first tried to test my project for flash I had an error telling me there was no program associated with SWF files so I manually associated SWF with the flash stand alone debug player.
Now the debug is working but I noticed in the task manager after testing many times there are many instances of neko.exe running, how can I fix this ?
Does this happen if you
openfl test flash from the command prompt?
I’ve noticed this too. They just don’t close and you get the process trees for each compile hanging around after they are needed. I end up using Sysinternals process explorer to shut them down because after some hours they accumulate and it starts bogging the system down. I don’t get the same issue with windows native compile or android.
I noticed it too , half of the compiles are from Haxe Develop and others half are from Command line.
yes it does, neko wont close. so not a flashDevelop Setup issue . hmmm
On Windows here, when I run
openfl test flash on a test project, I see three
neko.exe entries in Task Manager. When I close Flash Player, then hit
C in the command prompt to exit, the
neko.exe entries disappear from the Task Manager.
Could you describe what steps keep a
neko.exe process open for you on Windows, from the command-line? Thanks
righhhhtttt…I was doing everything you said except I don’t close the command prompt. I was just closing the flash player.
If I do as you did all instances of Neko are closed then I need to manually close the player.
If I test from FlashDevelop no command window is opened though …
When we run the Flash target, we launch the player, then start following trace messages.
Perhaps FlashDevelop ignores out trace output, and is not closing our process down properly. Perhaps you could add
-notrace in the target drop-down (so it says
flash -notrace) and see if that helps at all? I think FlashDevelop uses its own system for outputting Flash Player output anyway
That worked! thank you
not really sure what that meant… I’m still getting trace messages too .
Here’s my guess
lime build flash compiles our SWF, then (I assume) FlashDevelop uses
lime run flash to launch it.
run command is “run and trace”, unless you add
-notrace. FlashDevelop assumes we don’t handle traces (or at least, does not pipe our output to the Log panel) but somehow is not closing our process cleanly. Old versions of OpenFL didn’t have support for Flash log output, so
openfl run flash would actually exit.
Four possible fixes exist here, long-term:
1.) FlashDevelop uses our log output (this would allow for log output on release builds as well as debug, which would be nice)
2.) FlashDevelop closes our process more cleanly, preventing the excess processes over time
3.) FlashDevelop hard-codes
-notrace when it runs the Flash target
4.) We see if FlashDevelop defines any special environment variables when our tools are run, so we can disable tracing internally when building in that environment
Would be great to have a long-term fix, but in the short-term, it’s great to know that entering
flash -notrace in your target drop-down fixes it for now
Do you also get lots of haxelib.exe processes that wont close?