AutoHotkey Community

@JoeWinograd
Thanks Joe.
Btw the title bar legend contains the version of AutoHotkey that Ahk2Exe was complied with (still the previous version)
Cheers

Ah, got it...and I can see that you used some of your own Directives. Nice!

Yes, an interesting side effect is that Ahk2Exe must be compiled by itself!
(At least until it becomes included in the main downloads.)

until it becomes included in the main downloads

Looking forward to that...where does that effort stand?

Well, I’ll let the dust settle with yesterday’s update, then if all remains quiet I’ll have a chat to @lexikos and @joedf to sort something out.

Sounds good!

New version available:-

Beta_7, 8 October 2019 -

• A leading 'U_' (without quotes) is now accepted in the 'name' parameter of 'Let' and 'Obey' directives.

@lexikos
I have no more enhancements for Ahk2Exe and it seems to be stable. I’m happy for the GitHub Edge branch of TAC109/Ahk2Exe to be included with the next version of AutoHotkey if you are ok with this. (The Compiler must be compiled with itself as it contains Compiler Directives. It will take the version of the AutoHotkey 'Unicode 32bit.bin' file it is compiled with. The GitHub Edge branch does not have the 'beta' heading information in the GUI.)

There will be work needed to update the help information and I’m happy to do my part with this. The Compiler Directives page will need to be inserted and adjusted, and the new Ahk2Exe parameters specified.

If you’re happy with this we can move ahead and get these enhancements incorporated.

@joedf
The 'official' GitHub repo will need to be updated at some stage and the Edge branch merged with Master.

Cheers

@TAC109
The release script compiles Ahk2Exe like this: I suppose that should work.

If someone updates the AutoHotkey/Ahk2Exe repo, I will just have to adjust the 'origin' remote in my local configuration.

To be frank, I'm not interested enough in compiling to do any testing or documentation. I trust that you and other users have tested it well enough. Please submit a pull request for the documentation, at your leisure. The new features should be tagged with <span class="ver">[v1.1.32.00+]</span> (or without .00). You may search for similar tags for reference if you are unsure how exactly to place it.

@TAC109
@lexikos
Sounds good, I will start importing over the new changes from TAC109/Ahk2Exe.

EDIT: I've resolved the merge conflicts, I had to squash and merge since the history was different because of the rebase...
Anyway, edge (now removed) has been merged into master:
https://github.com/AutoHotkey/Ahk2Exe

@joedf
Is that how git is supposed to be used? Just throw everything in as one huge commit?

Edit: I merged the Edge branch to Master on my repo and I see that it also shows as one large commit.
Thanks for your work with this

I did it using git directly, and had issues with the rebase last time so maybe some of the history isn't 100% but merges are usually lumped into one commit, depending on what you do. Main thing is now the repo is up to date, and a big thanks to you for your hard work on this!

Merges are not usually lumped into one commit - a real merge commit has multiple parent commits, and usually does not contain copies of the comments from previous commits. The history is preserved by retaining references to commits from both branches (hence multiple parents). Each line of code can be traced beyond the merge commit, to the commit that last modified it, except for lines that must be modified to resolve merge conflicts. That can sometimes tell who wrote the line, when and why (for instance, which bug fix or feature it relates to).

By contrast, a squashed merge will show all these lines were changed at the time of the merge, by whoever performed the merge, and relate to any one of dozens of comments that were squashed into the merge message.

The description for merge --squash strongly implies that what it does is not a merge; just has the same effect (on the content, obviously not the commit history).

Yes that's correct. I was thinking of PRs but then that's true... The other commits are preserved too... :/ I didn't do a normal merge... The history of both repos were out of sync, it was simpler to squash merge from where I had rebased it.
Essentially, the second half of TAC109's commit's were lumped into one-ish. I think I was a little confused when I was merging

I made a "manual" PR which was merged:
https://github.com/AutoHotkey/Ahk2Exe/pull/56

Hi TAC,
I just updated to your v1.1.30.03_Beta_7 (works perfectly, btw) and noticed that the released v1.1.31.01 Ahk2Exe.exe is 866kb while yours is 357kb. I'm curious why there is such a big size difference. Thanks, Joe

@JoeWinograd
The new versions I released as beta were compressed with Mpress, whereas the old version in 1.1.31.01 is uncompressed. (Thought to reduce the possibility of being flagged as a virus?)
Cheers

My impression was always that compressing actually raised the likelihood of false positives (at least, back in the day), although I have no recent data to back this up.

Yes, that was my point, probably expressed badly. The live version is uncompressed, possibly to avoid being flagged as a virus.

@joedf
Joe, I’ve just compared the AutoHotkey/Ahk2Exe source with mine and found that there are essentially no differences. (There was a small difference in Ahk2Exe.ahk at around line 205, but this did not affect the logic.)
Good work!

Thanks for the explanation, TAC. Regards, Joe