There are some test cases when we need to connect Puppetry to an already ruining instance of chrome. For example you cannot solve reCaptcha with automated tests, but you can do it manually and run the tests on the affected Chrome instance.
So how can we do it?
In order to connect we need to start Chrome in command-line with remote-debugging-port parameter.
Window:
start chrome.exe –remote-debugging-port=9222 --user-data-dir=remote-profile
macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --no-first-run --no-default-browser-check --user-data-dir=$(mktemp -d -t 'chrome-remote_data_dir')
Linux
google-chrome --remote-debugging-port=9222
Next we navigate in the started browser to http://127.0.0.1:9222/json/version. On the page we can see a JSON object.
We need to copy the value of webSocketDebuggerUrl property.
In Puppetry we open "Run Tests" modal window (F6), switch to "Browser options" tab and paste the saved value into "WS Endpoint" input.
Now we can press "Run".
Related
I am using following code: It works good on local system and one unix server, but fails on another server. Any idea what I might need to do
> library(chromote)
> set_default_chromote_object(
Chromote$new(browser = Chrome$new(args = "--no-sandbox"))
and I am getting following error:
Chrome debugging port not open after 10 seconds.
Two things you can check:
On the server in question, start chrome and go to chrome://version/ . Search the Command Line: section and make sure --enable-logging is in there.
Strat R on the server in question, and do:
library(chromote)
debug(chromote:::launch_chrome)
Now run that R-code in as normal and when it stops and waits for input, hit n and then enter and repeat hitting enter until you get to the lines you link to on github. After line 87 when output gets defined, type output on the terinal and hit enter. Inspect the output and make sure that it actually conatins the lines DevTools listening on ws:// . If it does not, see if there are other ways that logging text identifies the port it listens to. If so, I would git clone that package, go in and change the way it discovers the port number and modify the package that runs for that server.
Running Chrome without X server
There are two viable options here:
vnc
X.org dummy driver
Here is the VNC recipe:
1: VNC
a. sudo dnf install tigervnc-server (for centos 8), sudo yum install tigervnc-server (for centos 7)
b. vncserver :1 (or some other suitable number)
c. DISPLAY=:1 R # and run R code to launch chrome etc.
Now you can connect from your client and see that chrome runs as it should:
vncviewer centos.ip.address:1
2: X.org dummy
I have never done this myself, but in theory it should be straight forward if you read docs and follow a tutorial.
I am trying to run gym-gazebo on Google Colaboratory.
There is a problem to run gazebo server (gazebo without gui) on Colab.
There was warning on display: Unable to create X window. Rendering will be disabled but I think I fix it.
There also warning about sound card. not sure it related Unable to open audio device,
And there warning about conversion Conversion of sensor type[depth] not supported
Here is an example
Can you help?
In order to run gazebo in a headless mode you need to run gserver executable, instead of gazebo. Not sure which one is used by the gym-gazebo toolkit.
In order to still do rendering in gazebo server (e.g. camera view) you would need to use Xvfb (X Virtual Frame Buffer). It is an X server that can run on machines with no display hardware and no physical input devices. It emulates a dumb framebuffer using virtual memory.
For your specific colab notebook I have changed last cell by adding
get_ipython().system_raw('Xvfb :1 -screen 0 1600x1200x16 &')
in order to create virtual display and added DISPLAY=:1.0 to the beginning of the last line, so it looked as follows
DISPLAY=:1.0 python gym-gazebo/examples/turtlebot/circuit2c_turtlebot_camera_dqn.py
DISPLAY=:1.0 tells X Window client used by gazebo to use virtual display we have created instead of default one :0.
A complete installation of Gazebo on colab and running it in headless server mode with rendering capability can be achieved the following way:
!curl -sSL http://get.gazebosim.org | sh # Install gazebo
!apt-get install -y xvfb # Install X Virtual Frame Buffer
get_ipython().system_raw('Xvfb :1 -screen 0 1600x1200x16 &') # create virtual display with size 1600x1200 and 16 bit color. Color can be changed to 24 or 8
!source /usr/share/gazebo-9/setup.sh && DISPLAY=:1.0 gzserver --verbose # Run gazebo and tell X client to use our virtual DISPLAY :1.0
There is also a way to run full gazebo in simulator with gzweb as a head and link to it using ngrok.io explained here as a fully working notebook. https://colab.research.google.com/drive/1A-miW8cTRKzs7B0m1m4enfiFySzBhsgN
You would need to authenticate to ngrok using your auth token which can be created at ngrok.com in order to connect, because it is lunch as background and doesn't print to cell
!./ngrok authtoken <token>
On the console.. I get the following -
Usage: java [-options] class [args...]
(to execute a class)
or java [-jar] [-options] jarfile [args...]
(to execute a jar file)
where options include:
-cp -classpath <directories and zip/jar files separated by ;>
set search path for application classes and resources
-D<name>=<value>
set a system property
-verbose[:class|gc|jni]
enable verbose output
-version print product version
-version:<value>
require the specified version to run
-showversion print product version and continue
-jre-restrict-search | -no-jre-restrict-search
include/exclude user private JREs in the version search
-agentlib:<libname>[=<options>]
load native agent library <libname>, e.g. -agentlib:hprof
see also, -agentlib:jdwp=help and -agentlib:hprof=help
-agentpath:<pathname>[=<options>]
load native agent library by full pathname
-javaagent:<jarpath>[=<options>]
load Java programming language agent, see java.lang.instrument
-? -help print this help message
-X print help on non-standard options
-splash:<imagepath> show splash screen with specified image
-ea[:<packagename>...|:<classname>]
-enableassertions[:<packagename>...|:<classname>]
enable assertions
-da[:<packagename>...|:<classname>]
-disableassertions[:<packagename>...|:<classname>]
disable assertions
-esa | -enablesystemassertions
enable system assertions
-dsa | -disablesystemassertions
disable system assertions
Eventually the server doesn't start and gets stopped after time-out. The Server was working fine. However, I wanted to restart it. I stopped the server completely and tried starting it. Since then I am facing this issue.
You can check the script that is getting executed when you right click and start the server.
Check if there are any unwanted entries in the java options which does not confirm to the java command line.
I cannot run a script in Eclipse that works perfectly in a terminal.
It seems that Eclipse console cannot support some functions. I am looking for a workaround to be able to debug the script using Pydev.
Is it possible to set PyDev to use for example /usr/bin/gnome-terminal instead of the Eclipse native console ?
Otherwise it there a way to define a wrapper as a python interpreter for PyDev that will launch an terminal external to Eclipse (I've tried but failed on that).
Thank you
Nga
Right now, curses-based apps really don't run well inside Eclipse/PyDev, so, you must really launch it externally. To debug you can use the remote debugger: http://pydev.org/manual_adv_remote_debugger.html
If you use Aptana Studio, there's a terminal view which should emulate a terminal better... try running python (i.e.: running your program) from inside that view. If it does work properly there, maybe I could check a way to better integrate there and launch directly in that view.
Thank you for your reply. I have finally defined kind of a wrapper as a bash script calling python in a xterm. Pydev is checking some configuration by calling eclipse/plugins/org.python.pydev_2.4.0.2012020116/PySrc/interpreterInfo.py so the script first echo the format expected by PyDev. here is the script "
#!/bin/bash
# dummy return for Eclipse Pydev - respect interpreter info format
echo "EXECUTABLE:/home/user/python_custom/python_xterm|
|/home/user/eclipse/plugins/org.python.pydev_2.4.0.2012020116/PySrc
|/usr/lib/python2.5
|/usr/lib/python2.5/plat-linux2
|/usr/lib/python2.5/lib-tk
|/usr/lib/python2.5/lib-dynload
|/usr/local/lib/python2.5/site-packages
|/usr/lib/python2.5/site-packages
|/usr/lib/python2.5/site-packages/Numeric
|/usr/lib/python2.5/site-packages/PIL
|/usr/lib/python2.5/site-packages/gst-0.10
|/var/lib/python-support/python2.5
|/usr/lib/python2.5/site-packages/gtk-2.0
|/var/lib/python-support/python2.5/gtk-2.0
|/var/lib/python-support/python2.5/HTMLgen
|/var/lib/python-support/python2.5/pyinotify
|/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode
|/usr/lib/site-python
#
$
|__builtin__
|__main__
|_ast
|_codecs
|_sre
|_symtable
|_types
|errno
|exceptions
|gc
|imp
|marshal
|posix
|pwd
|signal
|sys
|thread
|xxsubtype
|zipimport
"
# activate scrollbar -sb with 6000 lines
# allow logging -l with filename log_$NOW
xterm -g 150x100+0+0 -sb -sl 6000 -si -hold -e "python $*"
that does the job, and I can use Pydev and its debugger
I've built a simple test app with clutter: A stage with two ClutterText actors to display two words. It works OK when I run it from within gnome but running it from the tty (not gnome-terminal or xterm) with xinit my_app_binary I get an error:
failed to create drawable
Unable to initialize Clutter: Unable to select the newly created GLX context
Window manager error: Unable to initialize Clutter
If I run xinit gnome-terminal from the same tty everything works, gnome-terminal shows up in a black screen. That's the same I want to do with my app.
Is there anything I can do to overcome this error?
All the above are tested in Linux Mint 12. After normal boot I switch to a tty (ALT-F1) and stop lightdm (sudo /etc/init.d/lightdm stop).
Thanks!
EDIT: running as root everything works, so the question is: how to run it as a regular user?
Be sure to set the DISPLAY-var - add it in front of your command
DISPLAY=:0.0 /path/to/myapp
Sometimes this is an access-rights problem - the app should be started with the user who started the X-server
su user-started-x -c 'DISPLAY=:0.0 /path/to/myapp'