While using NetLogo 6.2.2 and Mathematica 13.1 in Mac OS 10.14.6 Mojave: When a NetLogo process is started by Mathematica, it's usually true that aborting the calculation (cmd-.) or quitting the Mma kernel stops that process (and quitting the kernel also shuts down the NetLog instance). What's new to me (since just a few months ago, I think) is the case of the Mma link being in an the infinite loop: I haven't found a way to recover from that. Neither of the two actions works, nor does quitting Mma. The only way I've found to stop the NetLogo instance that Mathematica created is to restart my machine. (I'm not sure which processes I'd have to ask the OS to kill, but the couple candidates that I tried didn't help.)
Here's how I got into the situation: Using the NLDoReportWhile[] command with a while condition that is always true. So, it's not actually the NetLogo code that is creating the infinite loop, it's the NLDoReportWhile[] command. This seems like a case where I wouldn't even have to quit the kernel; a simple abort of the Mma evaluation would work. Right? Again, I believe that I've used the Mathematica abort in the past to deal with this, but it's not working now. So it seems like a new miscommunication between Mathematica and NetLogo.
Related
I have a new Win10 laptop. I've installed lots of software, including a 25-year-old Codewright editor that I've customized up the wazoo, and that I've been installing on all my machines for, well, 25 years. After working for a few days, it suddenly stopped, and reinstalling it didn't fix it. On startup, it puts up a small splash window, and normally opens the main window a half a second later (that took more than 5 seconds 25 years ago). It's not using any CPU, and there's nothing I can do but kill the process.
In the past, I've occasionally got my system into a state where Codewright would hang on loading, due to some other program that hadn't terminated correctly, and it was unfrozen by killing off that other process. So that's reason to believe that Codewright is waiting at some global lock which some other malfunctioning software is holding. So I have two questions:
Does this ring a bell? Is there some known failure mode where a program putting up a splash window then switching to another window can be prevented by something else going on the system?
Is there a way to diagnose this, perhaps by finding out what system call it's hanging inside? I tried dtrace.exe, started Codewright, and then stopped tracing, and it produced a 3GB XML file, which is quite a haystack. There's a way to filter it by PID, but since this is a startup problem, I have no idea what the PID will be. Is there a better tool for doing this, or some more appropriate dtrace feature that I missed?
The comment about using the Task Manager to create a dump file actually led me to notice that there is an Analyze Wait Chain function there that I had never seen before, since I haven't used Task Manager much since I switched from Win7. This gave me exactly the answer I wanted. My editor was waiting for something that was being held by some NVIDIA GeForce Experience module. Since I don't use that, I uninstalled it, and I'm back up and running. Thanks for the tip.
I'm looking for a function which will get called when a macOS machine wakes up from sleep.
What are some ways to achieve this?
I'm looking to run code in my Swift application when the computer awakens. I'm trying to open a new websocket when this happens. If I open the lid -> new websocket, if I press the any key -> new websocket.
What I've found useful so far is this which stems from what #Rob Napier has suggested (didWakeNotification)
You'll need to give more information than this. Is this an user-level (GUI?) application that will be running when the machine goes to sleep? Is this a daemon? Do you expect your program to be launched if it isn't already running? Is the program sandboxed? Do you expect to have root access? What if no one is logged in? "Wakes up from sleep" has many subtle corner cases (for example, it includes a "dark wake" mode which are not quite sleep and not quite wake).
That said, the high-level answer is "observe NSWorkspace.didWakeNotification" and the low-level answer is "call IORegisterForSystemPower." But whether either of those help you depends a lot on what problem you're solving.
I recently switched to Ocaml 4.03.0 (installed using Opam) and started seeing erratic behaviors from ocamldebug on examples that previously went through without any problem.
In specific, I load up the byte code into ocamldebug, set arguments and run it. I don't set any breakpoints, I just want the debugger to hit an assert failure that both byte code (outside the debugger) and native code hit. Instead of reaching the assert, ocamldebug stops after running for a while saying
Lost connection to process 1234 (active process)
between time x and y.
Segmentation fault (core dumped).
Restart from time z to get closer of the problem? (y or n)".
If I try to get closer the problem by saying "n" then running again, this problem keeps repeating.
Apart from minor changes to my code (like additional print statements) nothing has changed in my set up except the Ocaml version. A collaborator of mine also has this problem, both with Ocaml 3.12.0 (installed from sources) and 4.03.0 (installed from Opam).
Why is this happening? And is there fix to this? Any insight into this is much appreciated. Thanks!
I have some issues when using the Ipython interpreter in Windows (I use Anaconda). After a few minutes (and expecially after plotting graphs), the interpreter turns extremely slow (it writes about 1 letter/second, even when I paste the commands).
Moreover, the keyboard interruption sometimes sends me directly to the Windows interpreter (instaed of just interrupting the current task).
However, the processing time doesn't seem to be longer than usual, and I just have to quit Ipython and restart it (wothout closing the terminal) for the interpreter to work properly again. But, still, it comes back every time !
Do you know how I can fix this ?
For some reasons I had to uninstall/reinstall homebrew on my MacBook Pro (OS X 10.9).
I wanted to reinstall swi-prolog via homebrew (like I did the first time). The installation process worked without any visible issue, but now every time in want to run swi-prolog in my terminal this message appears: "Abort trap: 6"
I have no clue of what that means. There is a lot of things about this message on the internet but I can't relate them with my issue.
Could you help me?
For some reason it seems that the symbolic link doesn't work correctly. In my version of swi-prolog I had to type the full path to get it to run correctly, for example:
/usr/local/Cellar/swi-prolog/6.4.1/bin/swipl
Remember to keep in mind that your version number could be different than what I have listed above.
This became extremely tedious however to remember when having to type it every time I wanted to use Prolog, so I was able to add it as an alias with this command:
alias prolog='/usr/local/Cellar/swi-prolog/6.4.1/bin/swipl'
From that point on in the current terminal session, I was able to open it by just typing:
prolog
This way is obviously much easier, however you need to remember to change the alias if the version also changes.
The command "prolog" can of course be exchanged with any command you wish to use.
Keep in mind, if you want this command to be more permanent (as in after you close the terminal window), you will need to also add the above alias command to the ~/.bash_profile file so it runs on startup.
Hope this helps!
if i am not mistaken, swi-prolog required x11 to run but now in mac 10.9, there were no x11 anymore instead of xQuartz.
i am not sure if this is the real problem now.