% not escaped correctly with type in Sikuli 1.1.0Beta4

[Zed]

There seems to be a regression with regards to the behavior when using type('%') or type('%otherchars'). I keep getting MissingFormatArgumentException or UnknownFormatConversionException when I try to use it like this, even though I'm not using it in the context of string formatting operator or whatnot. Tried escaping it by using type('%%') but it actually types two '%' in this case.

[RaiMan (raimund-hocke)]

Thanks for finding.

This is produced by the action log message, that should not use String.format() in this case.

using ;-)

Settings.ActionLogs = False
type("%")
Settings.ActionLogs = True

avoids the crash.

[RaiMan (raimund-hocke)]

fixed in nightly tomorrow ;-)

[Zed (zh2eou)]

Awesome, thanks! By the way, it seems like the performance gas greatly
improved in this version compared to before. Not sure if you've done some
optimization but I'm really enjoying it for some time critical tasks.
On Aug 8, 2014 4:55 PM, "RaiMan" <email address hidden> wrote:

> fixed in nightly tomorrow ;-)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1354589
>
> Title:
> % not escaped correctly with type in Sikuli 1.1.0Beta4
>
> Status in Sikuli:
> Fix Committed
>
> Bug description:
> There seems to be a regression with regards to the behavior when using
> type('%') or type('%otherchars'). I keep getting
> MissingFormatArgumentException or UnknownFormatConversionException
> when I try to use it like this, even though I'm not using it in the
> context of string formatting operator or whatnot. Tried escaping it by
> using type('%%') but it actually types two '%' in this case.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/sikuli/+bug/1354589/+subscriptions
>

[RaiMan (raimund-hocke)]

thanks for feedback.

performance improvements mainly come from 2 design changes:
- image handling with a cache, so that images are only loaded from file the first time, subsequent uses are served from the in memory cache
- an image memorizes, where it was found the last time. If searched again, this location is checked first. If still there, this might cut down search times on repeated searches to 1/10 (e.g. 30 msecs instead of 300 msec)

The last feature especially eliminates the extra search time of the unnecessary second search in cases like

wait(image, time)
click(image)

or
if exists(image):
    click(image)

This is typically seen in snippets from people new to Sikuli (and surely motivated by the command bar in the IDE) and often even with 2 different captures.

total time (taken the above example) before 600 msec now 330 msec

until 1.0.1 you had to use:

wait(image, time)
click(getLastMatch())

or even
wait(image, time)
click()

The next improvement will come from implementation of more parallelism to utilise modern multicore systems.