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.
Related
This is what I am doing:
Make a file or use an existing file.
Emacs filename.txt.
Type some new text into the file.
Save file.
After step 2, I receive an error after the emacs editor window pops up.
Here is the error:
2022-01-19 22:11:53.935 Emacs-x86_64-10_14[33893:994906] It's not
legal to call -layoutSubtreeIfNeeded on a view which is already being
laid out. If you are implementing the view's -layout method, you can
call -[super layout] instead. Break on void
_NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future.
I have already tried updating emacs and that didn't help, and googling didn't give me an answer. Currently, I have GNU Emacs 27.1 version.
How do I fix this error?
As far as I know you shouldn't need to "fix" the error at all and it won't cause any problems while you're actually running Emacs. In fact I'm somewhat surprised you see it at all.
I was only able to see the error (in both Emacs 27 and in pretest-28.0.90) only by running the Emacs binary (eg. ./Emacs-27.app/Contents/MacOS/Emacs) directly from a terminal, which isn't the normal way of starting Emacs on macOS. If you just run Emacs by starting it from Finder, the Dock, or via the "open" utility then you shouldn't see the error at all, and it shouldn't cause any problems.
The whole point of keyboard interaction (and emacs in particular) is that there's no need to touch the mouse. It's possible to log in (using e.g. ssh) and edit remotely, with no gui (so no way to drag and drop), and this is the 'normal' way of invoking emacs. Run 'emacs --help' from the command line to see a bunch of options. In particular see 'emacs --no-window-system' which uses a raw terminal even when a gui is available (no error message appears when it's run this way).
The gui however adds font and image support, which can be useful if you're sitting at the machine. The error message you get when you invoke 'emacs' from the command line in its default mode, with no arguments, is a diagnostic describing a bug in the mac gui implementation.
The error's still there if you start emacs through the finder; you can see that by running (e.g.)
$ open /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14
which both opens an emacs gui and a terminal window containing the program's text output.
As it says in the message, 'this may break in the future'; it's not helpful to say 'you're using it wrong.'
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
...
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.
I have sort of an unorthodox question/idea. I have a hydrological modeling program that is a bit buggy. I do not have access to the source code. This modeling program runs 24/7 and periodically produces assertion errors (and sometimes runtime errors) and a resulting pop-up window. Often it produces a "Send Error Message/Don't Send" pop-up only. See attached .jpgs for examples.
These windows halt all further program execution until it is dismissed (by clicking "Ignore" "Don't Send" or "OK" respectively). The assertion errors do not appear to affect program function. From the investigating I've done on dbheap.c it is likely an issue with the modeling program deallocating memory improperly at the end of a run.
I would like the program to always continue running and producing its forecasting export products even in the event of one of these errors (which, again, appear to have no effect on program function). I would like to dismiss these pop-up windows from outside the application (via a script) so that they do not halt program execution. Does Windows have a means for monitoring and/or dismissing program generated pop-ups from outside the application?
You could write a simple application which forces the application to do things. With Winspector/Spy++ or Winsight you can see all the objects in a windows application. You could check periodically for a popup and then click a (maybe always the first) button. Windows has a API/syscall and with it, it is possible to send a message to a window (handle) of your choice (http://msdn.microsoft.com/en-us/library/windows/desktop/ms644944(v=vs.85).aspx).
I'm using PyDev in Eclipse as my Python editor. It's fine in terms of feature set. Everything works fine except for one very annoying thing:
Code completion itself works fast. When I press Alt+Space, the window pops out almost instantly and all the options are there. The option at the top is selected. Then comes the trouble. The detailed description won't appear until about 5-10 seconds. All this time CPU is working at maximum load and the interface is not responding. All the processor is consumed by the Eclipse Java process (the spawned Python process seems idle). Then a yellow window pops up, and all it contains is just a Python code of a selected function/variable. All consecutive details are displayed instantly. The procedure repeats when I close the completion window (for example by accepting one of the options and asking for completion again). This drives me crazy.
I've tried so far:
creating a whole new workspace,
creating an Eclipse/PyDev project from scratch,
tweaking JVM to make sure it has loads of memory,
making sure the right JVM is chosen (the latest Oracle JVM available),
making sure Python process communicates freely with the Java instance (I read about possible problems with that, but it seems not to be the issue).
making sure all the installed plugins are up to date.
The version I use is Eclipse Helios, because the last time I checked certain extensions weren't yet ported to the latest one.
Has anyone observed a similar issue? Was anyone able to get around it? General ideas on how to debug it and file a sensible bug report possibly? Other things worth checking for.
Any workaround less drastic than turning completion off completly?
Thanks!
EDIT:
I've also noticed a problem with a similar popup window in HTML/CSS editor. It looked somewhat similar (a yellow window, with some text inside) and it also took ages to display. Don't really know if that is related, but could be.
EDIT(2):
Ok, No I've started with a fresh install of the newest Eclipse Indigo, without any additional plugins apart from PyDev and the issue remains. Seems like I'll have to look for a new IDE.
What version of Java are you using?
If you are on Windows 7, later versions of Java (I think 6+) will default to IPv6.
This is probably causing the problem as Python maybe wanting IPv4.
Anyway, since I had this problem I tried disabling
PyLint
Code Analysis
but it was still hanging.
Pal's answer about "ipv4 utilization" triggered my memory about another problem I had solved by "preferring" IPv4.
See http://docs.oracle.com/javase/1.4.2/docs/guide/net/ipv6_guide/
What you want to do is to edit your eclipse.ini and add "-Djava.net.preferIPv4Stack=true" in the vmargs section
-startup
plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
...
-vmargs
-...
-Djava.net.preferIPv4Stack=true
...
I no longer get hangs.
Is there any chance you can provide the code that's making that happen (and add it to a bug report see: http://pydev.org/about.html for links)?
I use PyDev daily with some very large projects and don't have that problem, so, it may be some specific construct or scenario in your code -- or maybe you just haven't given Eclipse enough memory (which would make the garbage collector work much more), in which case, take a look at: What are the best JVM settings for Eclipse? (in specific, raise your -Xmx flag, although you can probably use the other tips there too).
If you can't provide a reproducible scenario, the other choice would be getting a profiler (i.e.: YourKit java profiler has a 15 days free which would help in this case), running that use-case in the profiler and passing a snapshot of what's happening in this situation (if that's the case, please open a bug report at pydev.org and I can help you there).
I got this from pydev.org FAQs and it works fine for me.
When I do a code-completion, PyDev hangs, what can I do?
PyDev does most of its things in the java side, but some information can only be gotten from the python side (mainly builtins), so, in order to get that info, PyDev creates a shell and communicates with it through sockets.
The main problems when that happens are:
There's a firewall blocking the communication to the shell
In Linux, some kernels do not allow ipv4 utilization, which may make PyDev fail.
To enable it, do: echo 0 > /proc/sys/net/ipv6/bindv6only
The timeout to connect is too smal.
It depends upon the "Timeout to connect to shell" in the code-completion preferences (window > preferences > PyDev > Code completion)
If nothing works, please report a bug (also, check if there is anything on the error log (window > show view > PDE Runtime > Error log) and on the eclipse '.log', which is located at the .metadata folder of the workspace location.