I have enabled WSL 2. I have also installed VcXsrv (I think its also called Xlaunch?).
I opened the settings and overrode these properties for XLaunch.exe as shown below:
After that I clicked XLaunch.exe and added -ac in one of the boxes as shown below and then pressed OK. This launched an instance of XLaunch/VcXsrv in my system tray.
Now I opened my terminal (in WSL 2) and git cloned the demo Electron app from their website. After running npm install and npm start, I see a window, but the icons are large.
I also tried adding these environment variables to my shell rc (I am using fish shell).
set -x DISPLAY {mywslip}:0
set -x LIBGL_ALWAYS_INDIRECT 1
set -x GDK_SCALE 2
set -x GDK_DPI_SCALE 0.5
But even after this, Electron app's icons and text is a little bit large. To confirm if this was an Electron issue, I did npm start in my host machine (i.e., using Windows cmd meaning I ran it not in WSL 2, but on host windows machine itself). However in this case, it works perfectly fine, icons are perfectly scaled.
I think I need to play around with these environment variables, but is there an automatic fix without my having to guess the numbers for GDK_SCALE etc?
Note: I have a normal 1920 x 1080p resolution laptop with me.
Related
Im working on Ubuntu 20. I've installed docker, nvidia-docker2. On Pycharm, I've followed jetbrain guide, but in the advanced steps it isn't consistent with what I see in my setup. I use PyCharm Proffesional 2022.2.
In this step:
in the run options I put additionally --runtime=nvidia and --gpus=all.
Step 4 finishes as same as in the guide (almost, but it seems that it doesn't bother anything so on that later) and on step 5 I put manually the path to the interpreter in the virtual environment I've created using the Dockerfile.
In that way I am able to run the command of nvidia-smi and see correctly the GPU, but I don't see any packages I've installed during the Dockerfile build.
There is another option to connect the interpreter a little bit differently in which I do see the packages, but I can't run the nvidia-smi command and the torch.cuda.is_availble return False.
The way is instead of doing this as in the guide:
I press on the little down arrow in left of the Add Interpreter button and then click on Show all:
After which I can press the + button :
works, so it might be PyCharm "Python Console" issue.
and then I can choose Docker:
which will result in the difference mentioned above in functionality and also in the path dispalyed (the first one is the first remote interpreter top to bottom direction and the second is the second correspondingly):
Here of course the effect of the first and the second correspondingly:
Here is the results of the interpreter run with the first method connected interpreter:
and here is the second:
Of the following code:
Here is the Dockerfile file if you want to take a look:
Anyone configured it correctly and can help ?
Thank you in advance.
P.S: if I run the docker from services and enter the terminal the command nvidia-smi works fine and also the import of torch and the command torch.cuda.is_available return True.
P.S.2:
The thing that has worked for me for now is to change the Dockerfile to install directly torch with pip without create conda environement.
Then I set the path to the python2.7 and I can run the code, but not debug it.
for run the result is as expected (the packages list as was shown before is still empty, but it works, I guess somehow my IDE cannot access the packages list of the remote interpreter in that case, I dont know why):
But the debugger outputs the following error:
Any suggestions for the debugger issue also will be welcome, although it is a different issue.
Please update to 2022.2.1 as it looks like a known regression that has been fixed.
Let me know if it still does not work well.
Jupyter Lab application features nice Terminas with in-browser terminal shell that support colours, navigation keys, and pretty much all standard features of a terminal application. In this question I mean /lab app, not classic Notebook (/tree) app.
If I launch Jupyter server using this Docker image it works great. I need to build my own image, and preferably not based on that. I do it simply as documented:
docker run -it --rm -p 8888:8888 -v "$PWD":/jupyter python:3.8 bash
# pip install jupyterlab
# jupyter lab --config=/jupyter/jupyter_notebook_config.py
The above is assuming I have a jupyter_notebook_config.py in the current directory:
c.NotebookApp.ip = '0.0.0.0'
c.NotebookApp.port = 8888
c.NotebookApp.password = 'sha1:<salt>:<hash>'
c.NotebookApp.allow_password_change = False
c.NotebookApp.allow_root = True
c.NotebookApp.open_browser = False
Everything works, but Terminal performs very poor, it does not support colours and send codes (like ^[[A, ^[[B) instead of arrow keys. Line-by-line investigation of the Dockerfile is not so exciting endeavour, may be somebody can point me to what I am mising?
EDIT: I was little bit wrong about colours (was confused by the default green prompt in the jupyter/base-notebook image) and the overall issue description. The root cause was that the shell that is started in my image is sh while in the official image it is bash. But nevertheless Terminal is not fully functional, e.g. if I launch nano, it starts only in 80x25 characters area and does not stretch to the actual size of the terminal). Arrows work in nano though.
So I figured out the reason. Apparently the Terminal web app just replicates the behaviour of the default shell of the user under which Jupyter is run. In this image they enable colouring in .bashrc template and then create a new user specifying a shell for him (lines 52 and 59).
EDIT: also SHELL=/bin/bash must be set in environment.
I am using the following shell script for to get the focus on a specific chrome window:
#!/bin/sh
WIDId=`xdotool search "Test page"`
xdotool windowactivate --sync $WIDId
sleep 2
xdotool windowactivate $WIDId
xdotool key --clearmodifiers ctrl+a
It works when running normally but fails when running chrome using xvfb.
In xvfb it is unable to find the windowID.
I need it to get working with xvfb.
It worked even without using windowactivate because I opened just one window that needed focus.
i configured out jenkins in way that it was launched under my account but when i build a project for my unit tests with KIF framework, Jenkins launches iPad simulator with black screen and nothing happens (jenkins also doesn't provide any useful information).
Can anyone advice to solution of this issue?
Please note that everything works just fine from command line.
Finally, i've found the solution need to use iPad Retina or iPad Retina (64-bit):
-destination OS=7.0,name=iPad Retina
So, the last supposed suggestion doesn't work either - need another solution.
Just ran into this myself. Following up on user2738882's self-answer, I have a fix for the pitfalls his solution has:
He's correct that it was occurring due to Jenkins being run as a launch daemon process. Daemon's are launched at start without login, but they aren't intended to have access to the UI. This is what causes the issue.
Unfortunately Jenkins defaults to installing as a launch daemon if you install via the Archive (.war).
The solution I went with is to move it over to a launch agent. To do so follow these steps:
sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
sudo cp /Library/LaunchDaemons/org.jenkins-ci.plist /Users/<Path to Jenkins User>/Library/LaunchAgents/org.jenkins-ci.plist
Right click - > Get Info on the org.jenkins-ci.plist file
Change the read write permissions to all users (bottom)
Modify the plist file to change GroupName key value from "daemon" to "agent"
Right click -> Get Info again
Reset the file access to as it was before
sudo launchctl load /Users/<Path to Jenkins User>/Library/LaunchAgents/org.jenkins-ci.plist
The drawback of this approach is launch agents don't start until the user they're associated with logs in. In order to accommodate this I've configured my Jenkins user to login when the server starts up. To do this:
Open System Preferences
Open Groups & Users
Login Options
Set your Jenkins user as the Automatic Login:
This is obviously a security concern, but these machines should only ever be accessible on your local network and in a secure location anyway. Regardless I set the machine to show a screensaver as quickly as possible with a login.
The work-around that I see is that you can create AppleScript, which will run a simulator using terminal. Example:
do shell script "script"
where, script is your terminal command.
After script is created, add build step 'Execute shell script' to jenkins and write script which will run your AppleScript.
Example:
open /Applications/MyScript.app
The issue was in Jenkins and it was solved in the following way:
Stop the jenkins daemon via command:
sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
Start Jenkins as process via command:
sudo nohup java -jar /Applications/Jenkins/jenkins.war --httpPort=8080 --ajp13Port=8010
And it works perfectly!
But there is a pitfall, after launching Jenkins under your user, all jobs disappear and you need to create it once again.
I have code
system("reboot")
The reboot command works in the terminal, but even if I run the app as root, the operation is still denied. Has anyone found any way that works, or can explain a bit about SBSetting's reboot, which makes me curious?
I have finally found a way to programmatically restart an iOS device without rooting a device!!!!
The command line tool to restart an iOS device is called libimobiledevice:
http://krypted.com/mac-os-x/use-libimobiledevice-to-view-ios-logs/
It is truly amazing. One snag I ran into while installing was trying to install this line:
brew install -v --devel --fresh automake autoconf libtool wget libimobiledevice
However I got around the install problem by running this line:
brew install -v --fresh automake autoconf libtool wget libimobiledevice
After that problem, I followed the rest of the instructions and voila!
Most of the commands can be found on this page:
http://krypted.com/uncategorized/command-line-ios-device-management/
The magic command that restarts the iOS device is:
idevicediagnostics restart
What is truly amazing about this tool is not only restarting an iOS device but also outputting iOS device logs to mac's terminal app using the following command:
idevicesyslog
I figured out a way to do it, although it's a bit convoluted. The problem is that even if you setup your app to run as root, when you make system() calls, you're apparently still limited to user mobile privileges. Since mobile cannot call reboot (successfully), this doesn't work.
The way I got around this problem is to take advantage of a new feature that SBSettings supports. SBSettings has a privileged daemon process that runs. It allows you to plug in your own commands, by simply writing a script (or other executable) and dumping it in the appropriate directory (/var/mobile/Library/SBSettings/Commands). Once you then restart the sbsettingsd process, you can get it to run your script by posting a notification. If you name your script
com.mycompany.reboot
then from within your app, you can execute this code:
#import <notify.h>
notify_post("com.mycompany.reboot");
Then, you make com.mycompany.reboot a simple shell script like this:
#!/bin/sh
reboot
And make sure to chmod 755 on your com.mycompany.reboot script. The full details of this SBSettings command feature can be found here:
http://thebigboss.org/guides/sbsettings-toggle-spec (see Calling External Functions and Scripts ...)
Anyway, it does require your app to depend on SBSettings, but it's a free app, and most users would probably want to have it anyway. For now, it accomplishes the goal of rebooting (or anything else that requires root access) programmatically, via notify_post().
This answer might feel hacky to some but I have not found a better solution on how to restart an iOS device that has not been jailbroken so here goes my answer:
In order to restart a device from the command line I do some prep work:
Connect device to computer
Add iTunes shortcut to your dock
Select spotlight and search for an application called Automator [must have Xcode installed in order to launch Automator!]
When Automator launches, select the Application option
Select the record button to start recording following actions
Select the iTunes shortcut
Select your device from the Device options
Select the Restore Backup... button
Select the Restore button
Select the stop button on the Automator app to stop recording.
From the Automator application, select File from the top bar and Save your newly recorded app to a location of your choosing
At this point you have an app file that will execute the steps mentioned above. I tend to leave iTunes open as it will always have the iOS device hooked up and ready to be accessed. When iTunes is closed and relaunched, the device takes time to fully connect with iTunes and this tends to break the flow of the Automator app.
At this point I can go into a terminal, go to the location of the app file and run the following command [EXAMPLE]:
open automator.app
(replace 'automator.app' with the name of your file)
If you are like me and your are running this command in jenkins, you will need to run the following commands:
open [location]/[your_app_name.app]
sleep 30
For some reason, the automator app needs the sleep time to complete all the recorded actions.
Also, I am sure you can also write an applescript to do all of this but I hate applescript and took the easy way out!
did you try NSTask: Execute a terminal command from a Cocoa app
This is not possible if the app is running in its sandbox. on a jailbroken phone you might be able to execute the reboot shell command.