How to run sikulix from cli using already running IDE?

Asked by Barak on 2018-01-22

I am running sikulix from cli using `-r` and it works great. However every time when I run the script, it always starts a new IDE and takes 5+ seconds for initialization. Is there any way to reuse current running IDE instance when I run script?

Question information

English Edit question
Sikuli Edit question
No assignee Edit question
Solved by:
Last query:
Last reply:

This question was reopened

Barak (barak.shirali) said : #1

My system - Windows 10, OsX 10.13
Sikuli - 1.1.1

RaiMan (raimund-hocke) said : #2

when you use runsikulix.cmd -r no new IDE is started, it just loads and runs the script.

the startup delay is due to the preperation of the Jython environment and has to be accepted.

you can try with the experimental runserver
further down the page

or this

Barak (barak.shirali) said : #3

Thanks for your answer. How do you set relative path to the script server?

Barak (barak.shirali) said : #4

And on Windows?

Barak (barak.shirali) said : #5

And how can I pass arguments and get logs? (-C when I run as command)

RaiMan (raimund-hocke) said : #6

--- runserver
as mentioned: experimental.
You either have to get on the road with the mentioned page or you have to leave it alone.
parameters are not supported (use option files instaed)
logs can be redirected to a file (see docs)

--- about running scripts from within scripts
using this feature combined with a hotkey setup you might build your own "runserver".

Barak (barak.shirali) said : #7

I appreciate your quick reply. It seems like I have to run scripts from within scripts.

Could you elaborate about building my own "runserver" with hotkey setup? How can I choose script name, send parameters to the included scripts, and get console output?

RaiMan (raimund-hocke) said : #8

yes, a middle-sized challenge ;-)

workflow idea with hotkey:
-- trigger script:
- accepts scriptname and parameters
- writes a line to a file with these information
- issues hotkey

-- serverscript
-- waits for hotkey
-- reads the one-line file
-- builds the run command and runs it

workflow idea file only:
-- trigger
create a one-line-file with scriptname and parameters

-- serverscript
-- wait for file to exist
-- reads the one-line file
-- delete the file
-- builds the run command and runs it

there are of course other option for the trigger-server-communication-file

Barak (barak.shirali) said : #9

That makes sense. How can I make the script not exit and listen for hotkey? Should I use infinite Delay() loop?

RaiMan (raimund-hocke) said : #10

yes, a wait loop.

here is a relatively complete example

### hotkey setup section ###

# variants to end the script
Env.addHotkey("x", KeyModifier.ALT+KeyModifier.CTRL, lambda e: exit())
Env.addHotkey("q", KeyModifier.ALT+KeyModifier.CTRL, quit)

def quit(event):
  print "handler quit ctrl-alt-x"
  global running
  running = False

# basic hotkey definition with a related handler name
Env.addHotkey("c", KeyModifier.ALT+KeyModifier.CTRL, handlerC)

def handlerC(event):
  print "handlerC: seconds since start:", int((time.time() - start))

# at hotkey press a function will be called whose name is currently held by variable todo
Env.addHotkey("v", KeyModifier.ALT+KeyModifier.CTRL, lambda e: todo(e))

def handlerC1(event):
  print "handlerC1: seconds since start:", int((time.time() - start))

todo = handlerC # default at start of script

# at hotkey press the function handlerParam will be called
# with a parameter value currently held by global variable start
Env.addHotkey("b", KeyModifier.ALT+KeyModifier.CTRL, lambda e: handlerParam(start))

def handlerParam(begin):
  print "handlerParam: seconds since start:", int((time.time() - begin))

### main workflow start ###
start = time.time() # a global variable used in the handlers
count = 0

running = True
while running: # will end the loop if running is False

  wait(1) # some timeconsuming stuff here

  # one can always check in between and leave the loop
  if not running: break

  wait(1) # some timeconsuming stuff here

# changes the handler for hotkey v after about 20 seconds
  count += 1
  if count > 10: todo = handlerC1

# here might be some postprocessing before script finally ends
# you might remove your hotkeys before, to avoid interference by the handlers
print "PostProcessing"

Barak (barak.shirali) said : #11

Thank you for your great script. It still doesn't make sense how to trigger hot key or passing over param to central script from other application. However I bet that's my job to figure it out :)

Thanks again for your help, and writing great library!

Barak (barak.shirali) said : #12

Thanks RaiMan, that solved my question.

RaiMan (raimund-hocke) said : #13

Since I am not sure about your final intention, something to think about:

If it is more interactively, what you plan to do (sitting there, watching the workflow and doing some actions to trigger scripts), then the hotkey solution might be appropriate.
Just implement the file read/write and run trigger in the hotkey handler.

If it is more about self-running automation, then the file only solution might be more appropriate.

Generally I guess, you have delegated different tasks to different scripts and now want to generate some workflows from these building blocks. If this is true, then the appropriate solution would be to implement the features in functions inside the scripts, import the scripts and call the functions from a main script, that represents the workflow(s). This way you have everything within the Jython scope and no problems with startup of scripts.

Barak (barak.shirali) said : #14

I have a side question. Do you have plan to add argument/output feature to the experimental server?

Barak (barak.shirali) said : #15

RE: "implement the features in functions inside the scripts, import the scripts and call the functions from a main script, that represents the workflow(s)"

I am also considering to write main script, but that still requires initial start up time.

RaiMan (raimund-hocke) said : #16

Sorry, no.
This version 1.1.x experimental server is a dead-end (hence not in the official docs).

But if it is on the same machine, what you are doing, then it should not be a problem, to implement this handling as mentioned before in your scripts.

The mentioned file-only method could even be implemented based on the import feature with the trigger file being an appropriate script

scriptname = foobar
parameters = [..., ...]

import trigger
runScript(trigger.scriptname, trigger.parameter)

RaiMan (raimund-hocke) said : #17

--- I am also considering to write main script, but that still requires initial start up time.
... yes of course, but only once a day or longer time ;-)

Barak (barak.shirali) said : #18

Gotcha. That means wait loop to watch the files and start scripts if any change detected, right?

RaiMan (raimund-hocke) said : #19


Good luck.

Barak (barak.shirali) said : #20

I tried runScript and it worked well. The only problem I have is that `exit(result)` in sub-scripts causes error. Is there any workaround to return value to main script gracefully?

RaiMan (raimund-hocke) said : #21

please info about the error.

Maybe I can fix it.

A workaround would be to write something to a file in the sub and read it in the main.

Barak (barak.shirali) said : #22

Maybe it's my fault. I tried to exit with string value.

Best RaiMan (raimund-hocke) said : #23

yes, not allowed - must be a number

Barak (barak.shirali) said : #24

Thanks RaiMan, that solved my question.