AutoHotkey Community

[Chris]

Thanks for the report and the location of the problem.

The compiler/BIN file has been fixed so that SetFormat disables the caching of binary numbers in variables. This makes compiled scripts behave the same as non-compiled scripts.

To use the new version, unzip the following file in your \Program Files\AutoHotkey\Compiler folder:
www.autohotkey.com/misc/AutoHotkey-Pre-1.0.48-BIN-new3.zip (240 KB)

[Laszlo]

With this AutoHotkeySC.bin the exe file is twice larger than before (420KB instead of 210KB). Do I need to do something to enable compression?

[tank]

http://www.autohotkey.com/forum/viewtopic.php?p=247351#247351
seems the problem i describe here happens in the non compiled script with the beta
_________________

We are troubled on every side‚ yet not distressed; we are perplexed‚
but not in despair; Persecuted‚ but not forsaken; cast down‚ but not destroyed;

[Colorize]

I just wanted to report a bug. It seems that in the following code, two weird greenish lines appear for some unknown reason. The bug occurs only when using the beta EXE and BIN.

The code:

[Lexikos]

Binary integers are cached at load time for literal integers in expressions. Since the presence of SetFormat, Integer disables write-caching of binary integers in variables, when the binary integer is assigned to the parameter x, it is assigned as both a binary integer and a numeric string in the current format. In other words, x contains the string "16777215" or "15728640" instead of "0xFFFFFFFF" or "0xF00000". Since the "0x" prefix isn't required for colour codes, the decimal integer (or part of it) is interpreted as a hexadecimal colour code, resulting in the off coloured lines.

One solution may be to add (in the AutoHotkey source) a function which would:

• be used only to assign a literal integer to a variable,
  
• would cache a binary integer in the variable as before,
  
• but would also store the original numeric string in the variable if (write-)caching is disabled.
  

There are at least two workarounds:

• Pass parameters which aren't in the current numeric format as strings instead of literal numbers.
  
• Force each parameter into the correct format.
  

[Chris]

Thanks for that analysis.

However, I don't fully understand the subtlety of it; so if you think this issue represents a significant incompatibility, I think the source code should be fixed (at least if there's a reasonable way to do so without giving up too much). On the other hand, if this issue is something extremely rare and fixing it would sacrifice performance, maybe nothing should be done.

[Laszlo]

[Chris]

There are no large optional components. In fact, the SC/bin file barely changed from one version to the next because I only included the small section of code that recognizes SetFormat and turns of the caching of binary numbers.

Perhaps this is a bug in UPX itself -- maybe it encounters some unusual pattern of characters that causes it to fail to compress the file. You could try the latest version of UPX from http://upx.sourceforge.net/

If that doesn't help, you might try temporarily renaming your UPX and compiling the script again. If the resulting file size is almost exactly the same as the one with UPX enabled, that would seem indicate that UPX gives up early when trying to compress this particular file.

[Lexikos]

[Laszlo]

[Chris]

Here is a new beta version that improves the speed of thread creation and fixes all the bugs in the Bug Reports forum that were readily fixable.

If you get a chance, please test it with your most demanding scripts, especially ones that create many threads such as complex GUIs, SetTimer, OnMessage(), and the slow mode of RegisterCallback() (e.g. subclassing).

Here is the new AutoHotkey.exe. If you wish, you can rename or move your original AutoHotkey.exe and put this one in its place: www.autohotkey.com/misc/AutoHotkey-Pre-1.0.48-new4.exe (238 KB)

For those who would like to compile scripts with this release, unzip the following file in your \Program Files\AutoHotkey\Compiler folder:
www.autohotkey.com/misc/AutoHotkey-Pre-1.0.48-BIN-new4.zip (240 KB)

Please let me know if you find any problems with it.

[bmcclure]

Working great for me so far with my development versions of SteamWin, SteamLab, and FOMS.

And maybe it's just my anticipation because of your announcement, but SteamWin GUI windows (custom GUIs with a lot of timers and hotkeys) seem to be more responsive and perform better overall now.

I'm really liking the beta version so far.

Thanks, Chris!
_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

[Laszlo]

5 large scripts, one with over 20 threads work flawlessly, also in compiled form. They seem to be faster, too, but it is hard to measure.

[Sean]

Thanks Chris, NumPut now works like a charm with Uint64.

BTW, I couldn't test the beta versions extensively, so I've been waiting for Lexikos' additions to be incorporated into it. Although Assume Static and the more flexible dynamic function calls are crucially used, they aren't used heavily so I can temporarily replace them with ones compatible with the beta versions. However, While loop has been used so widely I didn't dare to replace them, and gave up using the beta versions.

[Chris]

Thanks Sean, Laszlo, bmcclure, and everyone else who has done some testing.

I forgot to mention that somewhere along the way, the SetFormat command was enhanced with a "fast mode" that avoids disabling the caching of binary numbers. For more details, see www.autohotkey.com/docs/commands/SetFormat.htm#Fast