Jython non-interactive command line quick as in runsikuli -i ? (Ubuntu 16.4)

Asked by tofti on 2018-07-06

being very newbie to Jython and SikuliX,
a) I installed Sikulix via java -jar ../sikulixsetup-1.1.2.jar options 2 4.3 on Ubuntu 16.4
 java -jar jython-installer-2.7.0.jar -s -d /usr/local/lib/jython
-with jip according to the manual,
b) the sample script is to click the 9 button on the xcalc calculator
cat neun2.py
import org.sikuli.script.SikulixForJython
from sikuli import *
c)I achieved execution:

1) slow (around ten seconds and do not know if profiting from jython install, because before I counted 25 or even 56 seconds)
 ../runsikulix -r ../neun2.sikuli/
2) quickly (less than a second) but unfortunately not non-interactively:
 ../runsikulix -i
 >>> execfile("neun2.py")

slow as 1) -after a jip install according to the manual- I came to:
  java -cp "$JYTHONDIR:$SIKULI" org.python.util.jython -Dpython.cachedir="/tmp/stest/"./neun2.py

Now I would like to run the script quickly like 2) but non-interactively, via Jython command line such as ( 3) )for quickly testing meanwhile doing the coding.

Is that possible at all? How then?
I assume "runsikulix --server" could be the way to go. Am I right?

Thanks a lot for answers or suggestions.

Ps: I worked through to the manual chapter until:"Access Python packages from SikuliX scripts run by SikuliX (GUI or command line)". Regarding the later chapters I am unsure if I needed them for my purpose.

Question information

English Edit question
Sikuli Edit question
No assignee Edit question
Solved by:
Last query:
Last reply:
RaiMan (raimund-hocke) said : #1

Yes, you are on the right track.

The cause for the delay at startup of running a script form commandline is the SikuliX internal init of the Jython/Java environment, that depending on power and memory takes about 5 seconds (and may take more if the content of internal caches has to be renewed).

This delay can only be eliminated, if you run a script in an already initiated environment like
- SikuliX/Jython interactive using runscript() or execfile()
- running scripts in the SikuliX IDE
- using the experimental runserver
- setting up your own solution (e.g. using the hotkey feature or other mechanisms, that trigger a runscript())

- SikuliX experimental run-server feature
Be aware: currently not documented and not fully tested
The server is started using
runsikulix -s
you should get something like
[info] RunServer: Starting: trying port: 50001
[info] RunServer: now waiting on port: 50001 at

then you can issue requests with some client (like curl from commandline):
- set the folder where the scripts are found
- set an image path
- run scripts

I will check the status of the feature during the next 24 hours and put some info into the docs.

You might already now start experiments, If you are able to read Java code:

the client requests are handled in the internal class HandleClient method run().

RaiMan (raimund-hocke) said : #2

just found the old docs on the old webpage.
might be helpful:

the sections:
Experimental: Play with the RunServer
Experimental: Use the RunServer - run scripts from anywhere with zero-delay

I will move it to the docs after having tested the features the next days.

RaiMan (raimund-hocke) said : #4

completed the docs (first version ;-)

pls. have a look and comment

Best RaiMan (raimund-hocke) said : #5

you should use the nightly 1.1.3 build #35

tofti (tomfeld) said : #6

Hi RaiMan,
I see you had a whole effort, big thanks yet!
Hopefully in the course of the day I can learn the installs and shall come back with the requested feedback.

tofti (tomfeld) said : #7

here my late comment:
the docs are quite instructive about how to run the server, because we read it on a browser, that is a http client.


I missed, however, a hint on how run a script (or the other setup steps) non-interactively.

Solution/work around found:
teaches how to trigger a http session on key and from command line. So

(echo "open localhost 50001"; sleep 0.1; echo "GET /run/neun2 HTTP/1.1"; echo "Host: localhost";echo; echo;sleep 0.2;)|telnet

Maybe this is hack,
but: This worked for me,
- on a first shot to the production release 1.1.2, that is even not recurring to the nightly builds as proposed.
Supposing the same with the other server setup steps, the problem could be considered solved so far.
Thanks a lot for your help.

tofti (tomfeld) said : #8

Thanks RaiMan, that solved my question.