autoKey often stops working if i press my script shortcut F12
about every 70%. And about every 50% of them the icon gets red and autoKey is freezing. CPU load grows a little bit.
Its difficult to say what may the reason it.
The script (gist is a bit large. About 500 lines and offered on github.
I debug by sending while i recording my desktop to video file (youtub LKl4Ufhh3P8 ).
it open via wine a menu (autoHotKey script called lintalist) and catches the changed clipboard and writes it out.
When I restart the autoKey script it runs a couple of times (maybe three or five times). I inserted 100 milliseconds as a pause at various points. Since then, I don't have to restart the operating system, only kill the script when it freezes.
any idea what to try?
for debugging i use such little helpers:
import subprocess
doPopupNotify_howItWorks_counter = 0
doPopupNotify_howItWorks_firstNr = 15
doPopupNotify_howItWorks = True
def popupNotify(text):
subprocess.Popen(['notify-send', text]) # will be showed right top
def popupNotify_howItWorks(text):
global doPopupNotify_howItWorks, doPopupNotify_howItWorks_counter
if not doPopupNotify_howItWorks:
return
doPopupNotify_howItWorks_counter = doPopupNotify_howItWorks_counter + 1
if doPopupNotify_howItWorks_counter < doPopupNotify_howItWorks_firstNr:
return
subprocess.Popen(['notify-send', str(doPopupNotify_howItWorks_counter) + ") " + text]) # will be showed right top
time.sleep(.2)
System
Operating System: Kubuntu 20.04
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
Kernel Version: 5.4.0-52-generic
OS Type: 64-bit
autoKey gtk 0.95.10
These problems have not disappeared for a few days as a result of the following changes:
The solution described above uses the clipboard and keyboard together with Linux and Windows (Wine) conveyed via two scripting languages.
Apps:
clipboard ⇄ AutKey ⇄ AutoHotKey ⇄ Lintalist
operating systems:
clipboard ⇄ Kubuntu ⇄ WineHQ 1
Errors are more common in non-closed systems. Therefore, for example, such errors are typical (still open problem at 2020:11:12 in autokey):
"Hotkeys get lost when triggered frequently"
change from autokey-gtk to autokey-qt for systems using a Qt-based desktop environment such as KDE Plasma, Lumina, etc. For that there are different possibilities (github: install using pip3). I've used i used:
sudo apt-get remove --auto-remove autokey-gtk
sudo apt -y install autokey-qt
changed in AHK-Souce
ClipboardFirst := RTrim(LTrim(Clipboard, " `n`t:")," `n`t")
to
ClipboardFirst := RTrim(LTrim(Clipboard, " `n`t`r:")," `n`t`r")
The autokey icon still sometimes turns red, but the CPU load does not grow much and the system no longer freezes.
1: Wine is a free implementation of Windows on Linux.
Kubuntu Version 20.04
AutoKey Version 0.95.10
Python Version 3.8.5 (default, Jul 28 2020, 12:59:40) [GCC 9.3.0]
wine-5.0.1
Related
I have multiple installations of Eclipse(2021-12) + PyDev(9.3.0.202203051235) all using Iron Python(2.7). All running on Windows 10. They all run the scripts as expected, but one installation has a much more robust console output when debugging, almost like a tracing option is enabled. I've tried reinstalling, deleting workspaces, deleting '.metadata' folders, etc. All the project settings seem identical.
Any ideas how to minimize the console output? Something in registry?
Expected Console output:
pydev debugger: starting (pid: 15312)
Actual Console output:
1.99s - Using GEVENT_SUPPORT: False
0.00s - Using GEVENT_SHOW_PAUSED_GREENLETS: False
0.00s - pydevd __file__: C:\\Eclipse-2021-12-R\plugins\org.python.pydev.core_9.3.0.202203051235\pysrc\pydevd.py
0.11s - Initial arguments: (['C:\\Eclipse-2021-12-R\\plugins\\org.python.pydev.core_9.3.0.202203051235\\pysrc\\pydevd.py', '--multiprocess', '--protocol-http', '--print-in-debugger-startup', '--vm_type', 'python', '--client', '127.0.0.1', '--port', '60413', '--file', 'C:\\Test.py'],)
0.00s - Current pid: 8884
pydev debugger: starting (pid: 8884)
Those should only appear if you add an environment variable asking it to be shown.
i.e.: Something as:
PYDEVD_DEBUG=1
PYDEV_DEBUG=1
Maybe you have such an environment set in your launch configuration or interpreter configuration or elsewhere in your system?
You may want to check the os.environ of the running program to see what's set there.
I am on linux ubuntu and target is a PIC18F47J53.
I basically want to program the chip and then let it run, using command lines and using pickit4.
using ipecmd (from mplab x ide v5.45), this is my command:
/opt/microchip/mplabx/v5.45/sys/java/zulu8.40.0.25-ca-fx-jre8.0.222-linux_x64/bin/java -jar /opt/microchip/mplabx/v5.45/mplab_platform/mplab_ipe/ipecmd.jar -TPPK4 /P18F47J53 -M -F"/path_to_myfile.hex" -W
This is my output
DFP Version Used : PIC18F-J_DFP,1.4.41,Microchip
*****************************************************
Connecting to MPLAB PICkit 4...
Currently loaded versions:
Application version............00.06.66
Boot version...................01.00.00
Script version.................00.04.17
Script build number............db473af2f4
Tool pack version .............1.6.961
PICkit 4 is supplying power to the target (3.25 volts).
Target device PIC18F47J53 found.
Device Revision Id = 0x1
*****************************************************
Calculating memory ranges for operation...
Erasing...
The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0x3ff
program memory: start address = 0x1fc00, end address = 0x1fff7
configuration memory
Programming/Verify complete
Program Report
30-Jan-2021, 12:54:41
Device Type:PIC18F47J53
Program Succeeded.
Operation Succeeded
All good, and takes about 12 seconds, however, after that the pickit4 turns off the power target, and the pickit LED is BLUE (I guess state "ready")
The main question is how can I let the pickit4 powering the boards? any specific parameter? (I cannot find on the readme.html)
If I use MPLAB X IPE GUI to program, the programming is much quicker (3 or 4 seconds), the pickit LED is YELLOW and the target is left powered on. (I selected "release from reset")
I have tried to get the log out with as many details as possible, but I cannot see the commands sent to the pickit4.
Any idea? thanks
I realize that it's been a while since you asked, but i put the answer here for anyone who needs it. Add -OL to your command line options.
I am trying to run some code with pybullet. I am on windows 10, have the latest vscode, and I am using WSL remote on vscode with ubuntu 18.04 LTS. I have a GTX 2070 graphics card. I just want to see this work, I've been trying to fix it for the last 3 hours.
First, here is the code I am trying to run in WSL:
import numpy as np
import pybullet as pb
physicsClient = pb.connect (pb.GUI)
#load plane
import pybullet_data
pb.setAdditionalSearchPath(pybullet_data.getDataPath())
planeId = pb.loadURDF('plane.urdf')
#load visual shape
visualShapeId = pb.createVisualShape(
shapeType=pb.GEOM_MESH,
fileName='random_urdfs/000/000.obj',
rgbaColor=None,
meshScale=[0.1, 0.1, 0.1])
collisionShapeId = pb.createCollisionShape(
shapeType=pb.GEOM_MESH,
fileName='random_urdfs/000/000_coll.obj',
meshScale=[0.1, 0.1, 0.1])
multiBodyId = pb.createMultiBody(
baseMass=1.0,
baseCollisionShapeIndex=collisionShapeId,
baseVisualShapeIndex=visualShapeId,
basePosition=[0, 0, 1],
baseOrientation=pb.getQuaternionFromEuler([0, 0, 0]))
I get no errors, but the X server window will pop up (black) and close immediately. I read that you need to disable your GPU with WSL, but I am scared of messing up my PC. I would only want to disable it for when I need to see graphics / use the X server, not for all WSL applications.
Here is what shows in my bash script:
user#DESKTOP-######:~/program$ python3 openAI.py
pybullet build time: Sep 22 2020 00:54:31
startThreads creating 1 threads.
starting thread 0
started thread 0
argc=2
argv[0] = --unused
argv[1] = --start_demo_name=Physics Server
ExampleBrowserThreadFunc started
X11 functions dynamically loaded using dlopen/dlsym OK!
X11 functions dynamically loaded using dlopen/dlsym OK!
Creating context
Failed to create GL 3.3 context ... using old-style GLX context
Indirect GLX rendering context obtained
Making context current
GL_VENDOR=NVIDIA Corporation
GL_RENDERER=GeForce RTX 2070 SUPER/PCIe/SSE2
GL_VERSION=1.4 (4.6.0 NVIDIA 451.67)
GL_SHADING_LANGUAGE_VERSION=(null)
pthread_getconcurrency()=0
Version = 1.4 (4.6.0 NVIDIA 451.67)
Vendor = NVIDIA Corporation
Renderer = GeForce RTX 2070 SUPER/PCIe/SSE2
Segmentation fault (core dumped)
user#DESKTOP-######:~/program$
#Emilio, I have got this working without any changes to the GPU, using the following process:
I used the VcXsrv application set up in the same way as this tutorial : https://jack-kawell.com/2020/06/12/ros-wsl2/ where crucially Native openGL is unchecked.
Export your ip address as in the tutorial, however instead of 'export DISPLAY={your_ip_address}:0.0', go to the VcXsrv window (which should be blank at this point) and replace :0.0 with whatever number of display is given. So for Display DESKTOP-1234AB:1.0 you would enter 'export DISPLAY={your_ip_address}:1.0'
In the linux terminal enter: export LIBGL_ALWAYS_INDIRECT=0
You can check that this has made an effect by entering: glxinfo
Which should print out:
direct rendering: yes
When you run your python program it should open up in the VcXsrv window. For me there was no cursor visible but I could still interact with the object as if I did have a cursor.
I downloaded and installed the latest Ma version of Maxima from source forge. When I try to launch it, I get
“Maxima.app” is damaged and can’t be opened. You should move it to the Trash.
This happens with both available versions, the one with VTK and the one without VTK.
How can I get it running?
I have MacOS 10.12.6
and both versions are here:
https://sourceforge.net/projects/maxima/files/Maxima-MacOS/5.40.0-MacOSX/
Others have run into the same problem. I don't use MacOS so I'm not sure what the problem is. Anyway, take a look at this bug report: #3316: Maxima VTK for Mac 5.40 is corrupt. The person who submitted it reported they got it working by following the advice in the comments.
See also thread 39: https://sourceforge.net/p/maxima/support-requests/39/
This is a really important thread to the larger MacOS community.
I have a MacBook Pro running OS X El Capitan, which is locked down a few versions back from the current MacOS Mojave.
I spent an entire night trying to get every wxMaxima from 5.36 to 5.42 running without success - even compiling from sources.
In desperation I found the thread 39 and entered the line:
(setf sb-impl::default-external-format :utf-8)
into a ~home/.sbclrc file (/Users/myName/.sbclrc). It was only then that the GUI and the Maxima engine could connect and a normal session could be established. Maxima, its maintainers and its users are too important a world resource to be stymied by such an esoteric and non-obvious bug.
A user encountering this bug will first go into the preferences menu and start trying to make sure that the file addresses and port numbers are correct, but experimentation can corrupt these and lead to other problems.
In my case following excerpt from https://sourceforge.net/p/maxima/mailman/message/35910588/ helped:
(0) Double-click the icon of "Terminal.app" in the folder "/Applications/Utilities", then the command-line-user-interface window is opened.
(1) Move the current working directory to the location of the disc image with the command "cd". (e.g. "Downloads" folder)
$ cd $HOME/Downloads
(2) You can check the attribute with the command "ls -l#":
(You will be able to find "com.apple.quarantine" which is the name of the attribute.)
$ ls -l# ./*.dmg
-rw-r--r--# 1 name staff 471227521 6 24 23:17 ./Maxima-5.40.0-VTK-macOS.dmg
com.apple.quarantine 62
(3) Remove the attribute "com.apple.quarantine" with the command "xattr -d com.apple.quarantine ./*.dmg":
$ xattr -d com.apple.quarantine ./Maxima-5.40.0-VTK-macOS.dmg
(4) Verify that the attribute "com.apple.quarantine" was removed:
$ ls -l# ./*.dmg
-rw-r--r-- 1 name staff 471227521 6 24 23:17 ./Maxima-5.40.0-VTK-macOS.dmg
(5) Double-click the icon of the disc image file to open.
After that, you should install Maxima.app into your "Applications" folder ("/Applications"). And you should drag the Launchers icon from the disc image to another place of your filesystem. You can install launchers to anywhere you like.
Then you will be able to launch Maxima with Maxima.app or launchers.
Title says it all. How can I handle or catch a SIGINT in julia? From the docs I assumed I just wanted to catch InterruptException using a try/catch block like the following
try
while true
println("go go go")
end
catch ex
println("caught something")
if isa(ex, InterruptException)
println("it was an interrupt")
end
end
But I never enter the catch block when I kill the program with ^C.
edit: The code above works as expected from the julia REPL, just not in a script.
I see the same behavior as alto, namely that SIGINT kills the entire process when my code is run as a script but that it is caught as an error when run in the REPL. My version is quite up to date and looks rather similar to that of tholy:
julia> versioninfo()
Julia Version 0.3.7
Commit cb9bcae* (2015-03-23 21:36 UTC)
Platform Info:
System: Linux (x86_64-linux-gnu)
CPU: Intel(R) Core(TM) i7-3610QM CPU # 2.30GHz
WORD_SIZE: 64
BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Sandybridge)
LAPACK: libopenblas
LIBM: libopenlibm
LLVM: libLLVM-3.3
Digging through the source, I found hints that Julia's interrupt behavior is determined by an jl_exit_on_sigint option, which can be set via a ccall. jl_exit_on_sigint is 0 for the REPL, but it looks as if init.c sets it to 1 when running a Julia program file from the command line.
Adding the appropriate ccall makes alto's code works regardless of the calling environment:
ccall(:jl_exit_on_sigint, Void, (Cint,), 0)
try
while true
println("go go go")
end
catch ex
println("caught something")
if isa(ex, InterruptException)
println("it was an interrupt")
end
end
This does seem to be a bit of a hack. Is there a more elegant way of selecting the interrupt behavior of the environment? The default seems quite sensible, but perhaps there should be a command line option to override it.
For julia >= 1.5, there is Base.exit_on_sigint. From the docs (retrieved on 20220419)
Set exit_on_sigint flag of the julia runtime. If false, Ctrl-C (SIGINT) is capturable as InterruptException in try block. This is the default behavior in REPL, any code run via -e and -E and in Julia script run with -i option.
Works for me. I'm running
julia> versioninfo()
Julia Version 0.3.0-prerelease+695
Commit 47915f3* (2013-12-27 05:27 UTC)
DEBUG build
Platform Info:
System: Linux (x86_64-linux-gnu)
CPU: Intel(R) Core(TM) i7 CPU L 640 # 2.13GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
LAPACK: libopenblas
LIBM: libopenlibm
but I expect it's not necessary to be fully up-to-date for this to work (I'd guess 0.2 should be fine too).