I have a large (> 25k) app that I've been developing in Scala/Akka/Play for a couple of years now. I'm in the process of upgrading it to the current version of the world (everything was a major version or two behind), which means getting it running in Activator. I'm gradually wrestling my way through that, but I'm somewhat stymied by the fact that Activator's "compile" window is very short -- only a few screens long -- so most of my 50-some-odd remaining compile errors are scrolling off the top. I'd really like to be able to read the entire thing, since I assume that most of these are knock-on errors, and only a few are really significant.
Where does the actual compile log go? How can I get to the whole thing?
It sounds like you're trying to use the UI mode when you were happy with the command line mode in Play 2.2; the command line mode is still there, see http://typesafe.com/blog/typesafe-activator---an-update-and-roadmap-preview for some background. Just run "activator" instead of "activator ui". The UI mode is not something that's "production hardened" yet, it is primarily intended for tutorials (though we are working to change that).
That said the compile log should not be truncated in the UI and we appreciate bug reports at https://github.com/typesafehub/activator/issues including one about this truncation.
Related
I'm using DrRacket to develop R6RS programs but I often see a bug where DrRacket hangs when either clicking on Check Syntax or Run. For example when checking syntax the message 'Check Syntax: expanding expression' is displayed at the bottom of the DrRacket window but no progress is made. Clicking on Stop shows the error message
C:\Program Files\Racket\collects\compiler\cm.rkt:213:2: user break
As far as I've been able to tell the problem always happens when running a program that imports a user library. I'm able to run the user library directly but for some reason there a problem when importing that same library into a program. I'm also able to use raco make on the same program without any issues, so I don't think there is any problem with the code.
A few more details. When I see this problem the Windows Task Manager shows that DrRacket is consuming no CPU (although a lot of memory). The memory use indication at the bottom right of the DrRacket window is ticking over, showing that DrRacket has not completely frozen. This feels like a thread deadlock situation to me. I have the latest version of DrRacket (8.7).
Any solution or workaround would be appreciated.
I have encountered a critical issue that Unity Editor freezes. I've spent many hours debugging step by step of my codes but still can't find where the problem is. So I think maybe I should try thinking from another angle, generally speaking what reasons would cause Unity Editor freezes and not responding?
I can't find a general case discussion about this topic.
From my experience, infinite loop is one reason for sure. Deadlock is critical issue, but not sure if it causes Unity Editor freezes. Unity Editor bug that I encountered only makes the whole editor crashes, instead of freezing. Any other experiences are welcomed. Thank you!
In such case, what kind of tools or methods could I use to debug it? Right now since the editor freezes I can't use "print" to find out what happens after it freezes. So I use Visual studio to debug the Editor thread, in this way I can see all the prints that I wrote. It appears the game is still running, only the editor not responding. And I can use VS click "attach to Unity and play" and put some debugging points, then debug step by step.
The first thing that I would check out is for an infinite loop. At the hang/freeze moment, you can attatch the debugger of your choice and pause the execution. In the case that it is an infinite loop that it is executing, at the exec time pause you might find the execution in a forever running while (true) {...}
Other thing that I would check is the plugins in use. Several Unity plugins like Parse, FMOD, UMP (Universal Media Player), ZFBrowser, or Embedded Browser are using native threads. It’s an issue when a plugin ends up attaching a native thread to the runtime, which then does blocking calls to the OS. This means Unity can't interrupt that thread for the debugger (or domain reload) and hang. Source
To check that you can check the active threads in the visual studio command window af the freeze is reproduced:
View->OtherWindows->CommandWindow and type in this command:
Debug.ListCallStack /AllThreads /ShowExternalCode
In the stack you can check if some thread is there with no need, or if its related with the plugins mentioned above.
Also an interesting point is to check in the windows task manager (in the case that you are using windows) if the CPU usage is to 0%. It can lead you to the type of hang that is taking place.
Good luck.
Edit: I forgot to mention, you need to check also the unity logfiles
I notice this all the time, and its super frustrating.
Unfortunately, this could be any number of issues. I notice this issue most often when working in projects that are made for the Universal Windows Platform.
Try using the Task manager to monitor specific processes / threads running.
Some follow up questions:
What platform is your project currently targeting?
What version of Unity are you running? Have you tried other versions?
What are your computers specs? Is the OS up to date? Graphics Drivers?
Does it happen (or happen more often) when an external code editor is open? Perhaps try going to Preferences>External Editor > Regenerate Project files.
Are you using Unity Collab by chance? I've had issues where collab is stuck trying to communicate with Unity Servers / looking for changes. Try logging out of your Unity account through the editor, and log back in.
Have you tried looking for a Unity editor crash dump, or error log files? I think they can be found here C:\Users\username\AppData\LocalLow\Unity by default. Those files may give you more specific data concerning your problem.
Unity's new versions are getting more slower and slower. From my experience 2019 versions are the best and more stable.
I solved my issue. It's fundamentally an infinite loop.
It's not a simple case such as "while(true)". I'll try to explain.
My game was a PvP game, and I'm making a local AI. Usually my design pattern works fine, however I just turned off the simulation of "AI thinking time", and since the AI codes and server codes all run in local mode, the transmitting of data between server and client are replaced by local method call(meaning instantly executed before everything else).
There is a loophole in my server code. I use "Update" and a flag on server to change a specific game state, however in this particular case, it got into an infinite loop because the local method call is executed before the "Update". And because my AI now doesn't need real time to "think", it "acts" and transmits the event data to server right away. And since the transmitting doesn't need time any more, it calls the server method instantly, hence forming the infinite loop.
Bounty Update
I am leaving the question essentially the same, but I just want to point out at the beginning here that I'm most interested in help trying to get the socket between flash (Adobe Animate) and the native debugger working again, as I believe that is the issue I'm having. Or is it a socket between flash and Windows?
Original Question
I've apparently turned something off? Even when I write really bad code (like trying to call a function that isn't there or divide an integer into a fraction), the flash player boots, shows a background color and stops there. No messages in the output window or compiler errors window. If I fix my code, it all runs fine, but for about 30 minutes (ever since I started trying to work with bitmaps for a sprite sheet) I get no runtime errors no matter what kind of mistake I type in my code. Anyone know how to turn it back on?
I've checked my actionscript settings and I have both warning mode and strict mode checked on.
Could it be a socket issue? I admit I have little to no experience working with sockets and only a surface understanding of what that even means. I've added the socket tag. If someone can see that this is clearly nothing to do with sockets, by all means, I'll remove the tag.
UPDATE: 6/22/16
I just reinstalled Adobe Animate CC 2015.2 and no change. I'll try compiling it in flash builder when I get a chance to help pigeon hole the problem. (Edit 6/24: flash builder worked! But my trial version expired the next day so is no longer a viable option).
And I just tried something in the command prompt in Windows 10 as an administrator:
netsh winsock reset catalog
netsh int ip reset reset.log hit
which I found another user on flashdevelop.org used to fix a similar issue, but no change.
And I just tried debugging in Flash Builder. It worked fine (debugger caught bugs) but my trial version expired the next day.
update 6/24
I've tried launching debugger for AIR from within the Adobe Animate CC IDE and it works fine if there are no bugs; it fails to do anything visible (no Iphone emulator, no swf window) if I put a typo or error in the code.
I also just deleted winsock and winsock2, rebooted Windows, then reinstalled winsock and winsock2. No change.
update 6/25
Just tried a system restore in Windows to set all my files and settings and drivers etc. to the way it was a week and a half ago... Also completely uninstalled all Adobe products and reinstalled. No change. I can only imagine that wiping my hard drive and reinstalling Windows would do the trick, but come on, it hasn't come to that has it?
As VC.One suggested, I checked the compile error window (cannot believe I didn't check before! Maybe when I checked before there were no compile errors... Only runtime errors?) and the errors are showing up there. Does this mean that it's catching compile errors but just not runtime errors?
When you force/test a runtime error... make sure you check
Compiler Errors (ALT+F2) and also Output (F2). By Output I mean the window that shows traces (and runtime issues). One of those two should have some feedback for you.
A possible solution is to save a new Workspace. So with those windows for Compiler Errors and Output both open (or tabbed, I tab them next to my Timeline) go to Window (in top options like File/Edit/Debug etc) and choose Workspace, then into that you choose New Workspace. Give it a name in the pop-up and okay everything.
Flash should always load that current workspace (next time, go to Workspace option again, check that your specified workspace [by name] has a tick next to it...).
Possible pitfalls:
1 - Use the debug player
2 - Make sure there isn't somewhere a try/catch enclosing the portion of code that triggers the event that may lead to an error
3 - Socket issue: may be exported in debug mode but swf cannot connect to debugger (it waits in a blank state for 60 seconds I guess)
4 - Does it compile ok? If there are compilation errors you may get an SWF anyway but then it will not start
...
Ok
SO recently I've being having a lot of trouble with an application working in debug mode but not working in distribution mode.
Is it possible to use xcode debugging tools such as break points and variable tracing with an adhoc distribution build of an app?
If it's not how would one usually go about debugging such a thing?
Assuming that your crash logs aren't giving you any clues (you'll need to hook up to the device to get them) there are lots of things you can do.
But I'd start by looking at the crash logs ... the clues will be there and don't forget Apple make distribution crash logs available to you through iTunesConnect.
1) Copious logging is one thing. Lots of developers use a switch so that in debug, logs go to the console but for other builds they are dropped. Consider a different option where you log to a file instead. You could then push the log files to a remote server for debugging. It's a bit of a slog to set this all up, but once you've done it, you'll wonder how you ever lived without it.
2) Another option is to use Flurry and log events when you detect that things have gone wrong. This can cover more controlled problems when things aren't as expected rather than random crashes. This can be a useful feature for released apps provided your terms and conditions are clear about what data you are logging and why.
3) Make sure you do a clean build, I'm sure you've already done this, but sometimes it clears these issues.
4) Are you using external libraries / modules? I've come across issues with older versions of TT where the arm6/7 build settings were wrong and this was causing issues for distribution builds. Basically check through the build settings for each profile and make sure it is what you expect.
5) Suspect a race condition. In distribution mode (often because the logging is turned off) you will find that your application runs a little bit faster. That can reveal timing issue bugs in badly written code.
So yes ... there is a lot you can do ... you just can't attach the debugger ;-)
Not possible to debug an application in distribution mode.
The build configuration difference between Distribution, Debug, and Release is really whatever parameters you have set for that in XCode. If your Distribution config is giving you problems and the release isn't, the easiest way to fix it is to go back through Apple's steps on copying the Release config and making the changes to make it a Distribution config, like you did originally.
The alternative is to go through every line of the configurations for Release and Distribution and find what's different. The other way is a LOT faster. :)
Very often, when I run my unit tests for my iPhone project, XCode feels like making the actual errors disappear from the errors and warnings group. These errors are often under the general sub-item of that group, and often when I need to read the text of the error in detail, all errors disappear and all I have left are the build warnings. Has anyone else seen this behavior and is there a way to fix it?
Edit: I forgot to mention; this seems to happen when i have errors that are not tied to any file (it says Line Location:0 in the second column of the error list). If there aren't any errors there (when generally the only errors are failed assertions) then it seems to work ok.
I haven't seen this behavior but what you describe sounds like a bug to me. You should submit it to apple.
It's hard to follow what you're talking about. What I can deduce is that you:
Build a Unit Test target
See the Errors and Warnings in an item in the Build Results window
Do something you don't explain to "read the text of the error in detail"
See the errors disappear (from the build results window?) but the warnings remain
It would help to see a screen shot of your project when it's doing what you want, before the errors disappear, and to learn what you are doing right before they go away.
This is probably happening because you have multiple targets with dependencies.
One target is dependent on another (usually unit tests) and the unit tests get built and their warnings/errors show up. Then, the main target gets built and its warning/errors show up. Since they are different targets, they second batch shows up over the first batch.
Assuming this is the problem, you can see the first batch by manually changing your target temporarily.