I'm interested in making little games with Erlang. I've made a super basic NIF binding to SDL in order to test this out. When I try to open a window with SDL, however, I get this error message:
Error creating window: NSWindow drag regions should only be invalidated on the Main Thread!
(This is on MacOS btw, hence the NSWindow)
How do I ensure that my Erlang code runs on the "main thread"?
I've tried it with running Erlang with SMP disabled, which my understanding was that then it'd run single-threaded. But I still get the same error.
Related
Is there is a way for debugging Delphi program in Rad studio with graphic output?
This means even graphic output(the command that has graphic output like print or shows a message and ...) run step by step.
For example inside loop command, we put print or add an item into list view and if we debug this part we can see the result in the form step by step? each turn of the loop show one print or adding to the list separately(by pressing F7 or F8 for debugging)
I hope I have asked my questions correctly.
Thanks
Is it possible to Debug Delphi applications in the way you describe? I'm afraid it is not.
Why not? Both application logic and UI rendering are done within the main thread. And when you set a breakpoint at certain line of code it stop the execution of the entire thread that the code is being executed from.
Since most if not all of your code is ran from main thread setting a breakpoint halts execution of the entire main thread of the application and thus prevents application windows to be redrawn.
In fact since redrawing of windows content is done during idle time of your application it means that running any long loop inside main thread means that the application UI will be updated only when the loop is finished.
You could theoretically force your application to update its UI on each loop cycle by calling Application.ProcessMessages before halting the code on a specific breakpoint.
But using ofApplication.ProcessMessages is not recommended as it could lead to scenarios where messages are not handled in expected order and thus could potentially cause you more problems elsewhere.
Also calling Application.ProcessMesages could seriously affect your application performance so if you decide to use it only use it for Debugging purposes.
I'm doing Dart FFI development in IntelliJ to create bindings to a native library. While trying to get the bindings right, I seem to be messing up some internal memory of this library. After making corrections to my code, the library is still in an inconsistent state due to my earlier errors. This is because the updated code is run inside the same instance of the DartVM as earlier: IntelliJ doesn't restart it, it reuses it. The only way to get back to a consistent state is to restart IntelliJ, which is quite annoying.
Is there a way from inside IntelliJ to only restart the DartVM used to run my program? I've not been able to find any way...
It's not quite clear which Dart VM you want to restart.
There's only one long-living Dart VM, it's Dart Analysis Server, the tool from the Dart SDK that is responsible for code highlighting, completion, and other code insight features in the IDE editor. To restart it click the corresponding button in the Dart Analysis tool window, or open Find Action and search for 'Restart Dart Analysis Server'.
Speaking of running your application, IDE doesn't reuse any running VM. Which run configuration type do you use to start your app: Dart Command Line App or Dart Web App (see Run -> Edit Configurations)? Both have the 'Stop' button in the Run tool window in case you application doesn't terminate normally itself.
More details about the problem (probably with screenshots) will help us to give a better answer.
occassionally, and without a specific pattern, I run into a situation where the rascal interpreter does not proceed with a debugging session. In the progress window, I get the message:
Reconnecting importers of affected modules: running command.
However, the progress bar remains static. What is causing this to happen? I cannot seem to rid this even if I restart eclipse. It usually starts happening after I start a debug session in a buggy code, then insert a few breakpoints.
Although this is not really a coding question; it may be this is the same UX feedback problem that I've experienced. Since Eclipse Luna and the latest Keppler updates, only when you go into the Debug perspective you see that Rascal is pausing on a breakpoint and the cursor jumps to the right editor. From that view you can then press the Run button to continue finishing the run.
Sometimes I'm trying to track down a really rare bug in an iOS app. I'll hit it in the debugger after hours of trying to repro only to have xcode or lldb crash on me while I'm debugging (usually if I'm stepping through C++ code). This is beyond infuriating.
With gdb you can use generate-core-dump to create a core dump of the file so that I can re-load it in gdb and at least look at all of the memory. What I want is the ability to do something similar in lldb so that when xcode crashes (as it always tends to do at the worst times) I can recover my debugging session without having to reproduce the crash.
The app is running on a non-jailbroken iPhone, so I don't have much access to the OS to do something like dump the memory from there.
One possible answer is to just use gdb instead of lldb, but I think that causes some other problems that I'm not remembering at the moment, plus it doesn't have some of the features that are useful in lldb.
UPDATE: Xcode 6, released fall of 2014, includes a new process save-core command in lldb -- lldb can now generate a coredump of a user process. e.g. (lldb) process save-core /tmp/corefile and wait a little bit.
The original answer for Xcode 5 and earlier lldb's, was:
This feature isn't implemented in lldb yet. This feature isn't implemented in the Apple version of gdb, either, for that matter.
While not a commonly requested feature, it is something other people have said would be useful as well. Hopefully someone will be sufficiently motivated to add that capability to lldb. I'm not sure how well it would work on an iOS device because it's going to involve gigantic amounts of data being transferred up to the Mac over a protocol that isn't very efficient for large data transfers - I expect it would be remarkably slow.
The core file can be opened with lldb -c /tmp/corefile
It's worth noting that the process explorer tool for iOS can generate core dumps of any PID (assuming you have root or it's the same UID as you), without impacting the process.
I want to debug App2.exe, which is started by App1.exe. If App2.exe were a dll I could specify a host application, but this doesn't seem to work with an .exe.
I now use 'attach to process', but this is useless if App2.exe crashes before I do that.
Is there a way to do this with having to attach to the process manually?
Set the "debug spawned processes" debugging option. It is off by default. When App1 starts the new process, the debugger will pause. If the debugger isn't already attached to the new process automatically, attach to it, and then resume running it.
No, but there might be a way to get it to attach properly. Find something that you know will happen in App2 soon before the crash point, and have it pop up a modal dialog box at that point. Then it won't continue until you dismiss it, giving you time to attach the debugger.
I guess you could launch app2.exe yourself and pass any necessary command line parameters to it.
If you're using windows, there is a built in support for it.
basically, you can tell the windows loader to launch some other process whenever a specific process is launched. for example, you can tell windows to always launch winword.exe whenever you click on notepad.exe
you can use this ability in order to automatically launch a debugger whenever you start your process (this is why this feature was originally introduced, however you are not restricted to launch only debuggers :))
You can read exactly how to do it here.
You can also download the debugging tools for windows package and use GFlags to do it for you.
If both apps are yours and you have the code than I propose the following:
Make a debug mode for both apps. Use external inc file for instance
Start two IDEs and load each app in its own IDE. Build in debug mode
If done right you can now debug the internal communication between apps
I have a project where a server spawns multiple exe worker processes that host each its own dll module. I have a debug mode in which I can specify which dll will be loaded and I can have both processes running and communicationt in between from IDEs. It is the best way I have found so far.