sikuli-driver team mailing list archive

[janet <696822@xxxxxxxxxxxxxxxxxx>]

Since rc-2 was released, I've been meaning to write a quick comment and
express my appreciation of all the work you have done on Sikuli-X.

This feature in particular is hugely helpful to me.  Today, trying to
figure out how I could create a subset test suite, picking and choosing
unittests from my various .sikuli suites, I found I can use this
command.

java -jar $SIKULI_HOME/sikuli-script.jar sg2_search.sikuli
Miro_Suite.test_82


Also - I've started working to get my scripts to run on linux as well.  Just needed to make a few minor tweaks and have found it to be rocket fast. 

So awesomely simple.  So Thanks, thank you and Thanks! to everyone on
your team.

-- 
You received this bug notification because you are a member of Sikuli
Drivers, which is subscribed to Sikuli.
https://bugs.launchpad.net/bugs/696822

Title:
  [request] want a real standalone sikuli-script.jar

Status in Sikuli:
  Fix Released

Bug description:
  scope: Sikuli X on all platforms.

  --- Request:
  Available with the downloadable package I want to have a fully self contained sikuli-script-standalone.jar. No fiddling around with dynamic link libraries and system path's. It should just be sufficient to have it in the java class path and if needed in the python path (sys.path, the need to say sikuli-script-standalone.jar/Lib is acceptable). from sikuli.Sikuli import * should then be all I have to do.
  Possible Solution: pack ALL needed native libraries in the jar file and copy them as needed at runtime into the appropriate temp folder so they can find themselves automatically. It should be one .jar for all platforms to be able to pack it together with the scripts.

  --- Current Situation:
  When you decide (based on whatever reasons) to not use the Sikuli IDE to edit, run and debug your scripts, you only need two resources from the package you download from Sikuli home:
  - the folder that contains the native libraries (openCV (has to be installed seperately on Linux) and some system specifics)
  - sikuli-script.jar

  With some practical differences on the platforms you have to take care:
  - that Sikuli finds the native libraries (mainly using path specifications in system path)
  - to have sikuli-script.jar in the java class path
  - to have sikuli-script.jar/Lib in the Python path (sys.path)
  - to say "from sikuli.Sikuli import * " in your main module and all imported modules using Sikuli features
  - preserve the .sikuli/.skl folder structure if you want to use the new import/imagePath feature

  (I know, that there are currently problems with 64-Bit environments,
  but this has nothing to do with this principal approach)

  This is all you need for the Python level. 
  If you want to use Sikuli features on the Java level, it is principally the same (but no need for Python path, Sikuli features are imported using org.sikuli.script.*)

  Having this prepared you can use IDE's like NetBeans or Eclipse (you
  might need plugins for Python) to edit, run and debug your scripts and
  run your scripts using plain Jython or Java.

  With the new features of Sikuli X it is now possible to manage your
  image libraries and some related scripts with Sikuli IDE, but
  completely using e.g. NetBeans to do the programming (edit, run,
  debug, ...) of your workflows and/or test suites.

  --- Current technical solution regarding the dynamic libraries:
  When the initialization logic in sikuli-script.jar (triggered with the first import sikuli.Sikuli) realizes, that it is not running in the IDE context, it copies some proxy dynamic libraries contained in sikuli-script.jar to a temp directory, that in turn will try to find the other above mentioned native libraries. this location is maintained in the java system property java.library.tmpdir and can be set by the script before the first import of Sikuli features.

  On Windows currently it is sufficient to add the following to the system path:
  path-to-the-folder-containing-the-dynamicLibraries;path-to-java\jre6\bin

  On Linux it should be similar

  On Mac you have to  manipulate the jnilib's and dylib's to contain the
  correct pointers to each other, depending on the location of the
  libraries (if interested contact me directly). the most flexible way
  is to use the directive @loader_path.

  --- Specifying sikuli-script.jar/Lib in IDE's
  in some IDE/platform combinations it is not possible to specify this in the settings panels. 
  Then you have the following choices:
  - in your main script modify sys.path before the first import of Sikuli features
  - edit the relevant configuration file by hand: (Netbeans: User folder .netbeans/build.properties, Eclipse: I do not know ;-)