sikuli-driver team mailing list archive

[RaiMan <question271271@xxxxxxxxxxxxxxxxxxxxx>]

Question #271271 on Sikuli changed:
https://answers.launchpad.net/sikuli/+question/271271

    Status: Open => Answered

RaiMan proposed the following answer:
This problem exists for every not-Java-aware programming or scripting
language (C-Python, C-Ruby, C++, C#, .NET to only name the most often
mentioned together with the request to somehow access the SikuliX API).

In each case you only have these options:

1. rewrite the needed features with the language/framework of your
choice (your request)

2. use some bridging solution, to access the SikuliX API available in
the classpath of a running JVM

3. run SikuliX as some service, that accepts execution requests for
SikuliX features or run snippets written in supported script languages
(currently Python, Ruby and JavaScript)

4 run SikuliX scripts in a separate process like from command line
(accepting the startup delay)

BTW: the startup delay when running a script from commandline is up to
about 80% due to the startup of the Jython interpreter preloading the
SikuliX classes from the Java API (in version 2 I will try to reduce
that somehow).

at 1. I will not do that. I will stick with Java, since this promises a
very, very high level of system independence and libraries for nearly
everything are available too. But if you want to do that, feel free to
do it. If you have questions about anything in the current
implementation come back at anytime (I personally would never do it this
way, since it would mean to reinvent the wheel ;-)

at 2: for Python there is a promising project, that allows to directly
access Java classes from Python. I am watching this project and will
test it during my development of version 2 the next months
(https://github.com/kivy/pyjnius). This might be more efficient than
solution 1, since you only have to define the API (which in turn might
be realized to 95% by reflection).

at 3: I have an experimental server available, that runs scripts without
delay (like in the IDE) using a HTTP/Rest Protokoll, which has the on
top goody, that the server could run anywhere in the HTTP-net.
(http://www.sikulix.com/support.html towards end of page). This server
solution will be the standard scriptrunner in version 2, that can be
used tightly coupled (runner API) in Java-aware environments or via the
HTTP/Rest API in any other case including remote runs.

at 4: no comment ;-)

Hope this helps to make your decision how to proceed.

-- 
You received this question notification because your team Sikuli Drivers
is an answer contact for Sikuli.