Upcoming Ahk2Exe Changes (2024)

Post your working scripts, libraries and tools for AHK v1.1 and older
TAC109
Posts: 1098
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

02 Nov 2019, 20:43

@JoeWinograd
Oh yeah, should be DDL (darned spell checker!j
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
User avatar
joedf
Posts: 8940
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

02 Nov 2019, 20:53

My email, pm or here is all fine. Sorry I wasnt too active online today. Either way, no worries. Keep doing what you need to. I will do a merge and fix conflicts when you're ready. :+1:
Image Image Image Image Image
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
TAC109
Posts: 1098
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

02 Nov 2019, 20:58

@guest3456
I’m using GitKraken on my PC. (I’m a git bunny!)

How come it is so hard to sync back to AutoHotkey/Ahk2Exe ? I thought it would be straight forward.

On a related note I’ve previously forked Lexikos/AutoHotkey-L-Docs and made numerous changes (and commits) to my copy to add Compiler Directives. Is there going to be a problem there as well?
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: Upcoming Ahk2Exe Changes (2019)

02 Nov 2019, 21:09

TAC109 wrote:
02 Nov 2019, 20:58
@guest3456
I’m using GitKraken on my PC. (I’m a git bunny!)
i'm sure theres a way to do it with that client, but what i suggested is nonstandard, to try to get you up and running again, so the options are probably hidden
TAC109 wrote:
02 Nov 2019, 20:58
How come it is so hard to sync back to AutoHotkey/Ahk2Exe ? I thought it would be straight forward.
its pretty straightforward in my mind, but i've been using git for a few years already. i mean if you have write access to the AutoHotkey main repo, you could just push your changes directly, and bypass any and all pull requests. that's usually not recommended, because usually you'd want other people to review your changes before accepting them into the main repository.

everything is hard when you're first learning it. But I promise you that git is worth it.
TAC109 wrote:
02 Nov 2019, 20:58
On a related note I’ve previously forked Lexikos/AutoHotkey-L-Docs and made numerous changes (and commits) to my copy to add Compiler Directives. Is there going to be a problem there as well?
they will be problems if you don't know what you're doing. it looks like you again committed all your changes directly to your master branch. you may run into problems because some of those changes are not related to each other. you really should be using a separate branch for each logical group of changes

TAC109
Posts: 1098
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

02 Nov 2019, 21:21

@joedf
I sent you a message via your web page. AutoHotkey pm's to devs are blocked somehow - they just go into a black hole.

Thanks for your offer, but I’d also like to learn how to do this myself, as well. So hopefully you can hand-hold while sorting things out. (Btw, I’d prefer to keep the commits separate on AutoHotkey, and not all amalgamated into one.)

Cheers
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: Upcoming Ahk2Exe Changes (2019)

02 Nov 2019, 21:27

@TAC109 try this:

1. copy those last 2 files from your last commit and put them in another folder safely
2. delete your fork on github.
3. re-fork the AHk2Exe again to your github account
4. clone your fork to your local machine using kraken or whatever
5. CREATE A NEW BRANCH on your local machine
6. paste your 2 files back in, then create a new commit to this separate branch
7. push this new branch to your personal github fork
8. create a PR to the AHK repo and specifically choose your new branch
9. delete the old #59 PR

TAC109
Posts: 1098
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

02 Nov 2019, 23:10

@guest3456
Thanks for your instructions. I was thinking I would have to do something like this. I’ll try it out tomorrow.

Some questions if you don’t mind:
So over time I push many commits to the new branch on GitHub/TAC109.
What happens when I push (pull?) to AutoHotkey? Should I merge back to master first?
What about subsequent commits? Use the same branch?

After any commits to AutoHotkey, should I delete TAC109/Ahk2Exe and refork from AutoHotkey?
(Surely it should be easier than this!)

I’m also concerned about the documentation fork. Any advice for this?

(Is my basic mistake that I didn’t branch first?)

TIA
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: Upcoming Ahk2Exe Changes (2019)

02 Nov 2019, 23:35

TAC109 wrote:
02 Nov 2019, 23:10
Some questions if you don’t mind:
So over time I push many commits to the new branch on GitHub/TAC109.
In your new branch, you should only make commits relevant to the logical change that you're doing. So for example, your latest commit is called "Change GUI compress to DLL". If that is a full logical change, then perhaps you only have one commit for that branch.
TAC109 wrote:
02 Nov 2019, 23:10
What happens when I push (pull?) to AutoHotkey? Should I merge back to master first?
You will have your local branch on your machine. Suppose we name it "gui-compress-dll". You then push this branch from your machine onto your github account, so that there will be a copy of the branch on github. This will show on the branch dropdownlist on the left side of the main repository page. For example, right now on your repo, you only have one branch called "master". After you push your new "gui-compress-dll" branch from your machine to github, it will show there in the dropdown too.

THEN, you go to the AutoHotkey/Ahk2Exe repo, and create a new Pull Request, and make sure you are requesting to pull FROM your "gui-compress-dll" branch, and it will only include the commits from that branch, and TO the 'master' branch on the AutoHotkey/Ahk2Exe repo
TAC109 wrote:
02 Nov 2019, 23:10
What about subsequent commits? Use the same branch?
only use the same branch if they are on the same topic. otherwise, checkout back to master, and start a new branch for a new logical feature
TAC109 wrote:
02 Nov 2019, 23:10
After any commits to AutoHotkey, should I delete TAC109/Ahk2Exe and refork from AutoHotkey?
(Surely it should be easier than this!)
Correct, so since you are now doing all of your local work in individual branches, that means you will keep your master branch clean and untouched. And so each time you want to keep your local copy in sync, you just pull from github.com/AutoHotkey/AHk2exe master and it will sync your local copy with the upstream copy. now your local master will be the same as the AutoHotkey/Ahk2exe master, which is what you want. (the copy on YOUR github fork will be behind at this point, but you can push your master from your machine onto your github fork). and now your local master will be up to date, and you can branch off knowing that your branch will be from the latest tip
TAC109 wrote:
02 Nov 2019, 23:10
I’m also concerned about the documentation fork. Any advice for this?
well you've made 4 commits to your docs fork, and it looks like the 4 commits are unrelated (maybe 2 are related), so yeah you may have some trouble. all is not lost, you can move things around if necessary. but if you try to create a Pull Request with all 4 of those commits, your PR would be titled something like, "few random changes by TAC" which makes the code review difficult, since its all unrelated
TAC109 wrote:
02 Nov 2019, 23:10
(Is my basic mistake that I didn’t branch first?)
not necessarily, there are many ways to skin a cat

TAC109
Posts: 1098
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

03 Nov 2019, 00:33

@guest3456
Ok, I can understand the flow you outlined :D

But how does the branch get merged back to master on GitHub/TAC109? Does that happen automatically on the subsequent pull from AutoHotkey?

Thanks again for all your help :thumbup:
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: Upcoming Ahk2Exe Changes (2019)

03 Nov 2019, 00:39

TAC109 wrote:
03 Nov 2019, 00:33
But how does the branch get merged back to master on GitHub/TAC109? Does that happen automatically on the subsequent pull from AutoHotkey?
no.. the branch never gets directly merged into your github fork. you merge your branch into the master branch of github/AutoHotkey through a pull request. and then you just update your local master by pulling from github/AutoHotkey onto your local machine. then if you want to, you can push from your machine's master onto your github account master

... but it doesn't even matter. the main repo is the github/AutoHotkey one, so you can simply think of your fork as a work in progress, that's why it doesn't really matter if it gets deleted or not, as long as you have all your work saved locally in its own branches. then you could also think of your github account as a backup to your local copy, where you'd want to be doing regular pushes to it in case your machine crashes, or in case you make a mistake on your local machine

but sure you can keep your fork up to date yourself and merge in your changes, either through a direct merge or through a pull request on your own fork repo. and i guess if github/AutoHotkey doesn't accept your pull request, because they don't want your changes, then you'd want to do that too for your own users. its really up to you how you want to do it. just make sure that you keep your work in its individual feature branches so that the pull requests can be diff'd cleanly

github has lots of help docs like this:
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests

but git is very powerful just to use for your own local development as well.. i pretty much never start coding without being in a git repo anymore



edit/
i forgot to mention, if you have access to github/AutoHotkey, you could bypass your fork altogether, and you could simply create branches directly in that main repo, and then PR from those branches. that's probably not the best practice, but this isn't a huge project so it probably doesn't matter

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

03 Nov 2019, 02:23

Regarding pull requests for the docs (and only the docs), I'm not very concerned about separating different logical changes into branches. Separate commits is sufficient. I'm not even concerned about the pull request description. Ragnar usually makes a bunch of unrelated changes and submits one pull request with just "Changes".

However, if a pull request contains changes I don't want, I might reject the whole lot.

Your current 4 commits seem okay, and all seem to be for the same purpose anyway.
TAC109
Posts: 1098
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

03 Nov 2019, 21:02

@lexikos
Thanks, I’ll just carry on as I am now updating the master.

@guest3456
Thanks for your help.
I’ve sorted out the earlier 'pull' problem and have been able to pull commits from TAC109 to AutoHotkey/Ahk2Exe successfully.

However, trying to get these commits back into TAC109/AutoHotkey master hasn’t been working smoothly.
I’ve ended up deleting the TAC109 fork and re-forking, which is rather a pain as GitKraken then barfs and I have to delete my local Ahk2Exe and reconnect it to TAC109 and sync again.

Back when pulling from TAC109 to AutoHotkey/Ahk2Exe, after completing the commit I’m given the option to delete the branch, which I’ve done. Is this where I’m going wrong?

Cheers
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
TAC109
Posts: 1098
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

03 Nov 2019, 21:16

lexikos wrote:
12 Oct 2019, 19:56
@TAC109
The release script compiles Ahk2Exe like this:

Code: Select all

    Ahk2ExeCmd = "%A_AhkPath%" "%Ahk2ExeDir%\Ahk2Exe.ahk"
...
    git("pull origin master", Ahk2ExeDir)
    RunWait %Ahk2ExeCmd%
        /in "%Ahk2ExeDir%\Ahk2Exe.ahk"
        /out "%InstDir%\include\Compiler\Ahk2Exe.exe"
        /bin "%InstDir%\include\Compiler\Unicode 32-bit.bin"
        /icon "%A_ScriptDir%\ahk2exe.ico"
        , %Ahk2ExeDir%
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.
...
It might pay to add /cp 65001 to your parameters to ensure the script is processed as UTF-8.
Cheers
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
User avatar
joedf
Posts: 8940
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

03 Nov 2019, 21:53

@TAC109 This desync is most likely due to the rebase and different merges I did... The forks were no longer in sync with yours... :/
Image Image Image Image Image
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
TAC109
Posts: 1098
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

03 Nov 2019, 23:04

@joedf
No, I first took a copy of my old Ahk2Exe for posterity (called it Ahk2ExeT), then forked your AutoHotkey/Ahk2Exe to TAC109, so it’s your one I’m making changes to.

Thanks anyway.
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: Upcoming Ahk2Exe Changes (2019)

03 Nov 2019, 23:40

joedf wrote:
03 Nov 2019, 21:53
@TAC109 This desync is most likely due to the rebase and different merges I did... The forks were no longer in sync with yours... :/
there shouldn't have to be rebases if the PRs are done correctly, but i see this one had an extra merge commit attached that you probably wanted to remove:

https://github.com/AutoHotkey/Ahk2Exe/pull/61
TAC109 wrote:
03 Nov 2019, 21:02
However, trying to get these commits back into TAC109/AutoHotkey master hasn’t been working smoothly.
I’ve ended up deleting the TAC109 fork and re-forking, which is rather a pain as GitKraken then barfs and I have to delete my local Ahk2Exe and reconnect it to TAC109 and sync again.

Back when pulling from TAC109 to AutoHotkey/Ahk2Exe, after completing the commit I’m given the option to delete the branch, which I’ve done. Is this where I’m going wrong?
if joedf rebased the main repo, then your repo would be out of sync regardless.

deleting your feature branches shouldn't matter for keeping your master in sync

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

04 Nov 2019, 03:54

TAC109 wrote:
03 Nov 2019, 21:16
It might pay to add /cp 65001 to your parameters to ensure the script is processed as UTF-8.
That would make the compilation behaviour inconsistent with the default behaviour of AutoHotkey.exe. Anyone should be able to run the Ahk2Exe source files with a default AutoHotkey installation (or at least AutoHotkeyU32.exe without command line switches) and have all characters (such as the © on the GUI) render correctly. In other words, all source files should be pure ASCII or UTF-8 with BOM.

A search of my Ahk2Exe source files for non-ASCII characters pulls up only Ahk2Exe.ahk, which is correctly encoded as UTF-8 with BOM.

And it's /cp65001, not /cp 65001.
User avatar
joedf
Posts: 8940
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Upcoming Ahk2Exe Changes (2019)

04 Nov 2019, 10:14

@guest3456 Thanks for the insight. Yes, I had rebased after talking with fincs when we talked about merging the large change.
@TAC109 I see, I am glad to see things are working now. Also, I'm not sure if BinMod.ahk should be included if it's a "separate" tool. Unless it's impossible to make it into one? Or at least, the Directive with a path for BinMod should be something more mnemonic?
@lexikos I think TAC109 meant the /cp switch for Ahk2Exe, I don't remember implementing it with a no-space option... ? For AutoHotkey, I do know it's /cp65001. unless I am getting confused myself... ? :crazy:
Image Image Image Image Image
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: Upcoming Ahk2Exe Changes (2019)

04 Nov 2019, 12:13

joedf wrote:
04 Nov 2019, 10:14
@TAC109 I see, I am glad to see things are working now. Also, I'm not sure if BinMod.ahk should be included if it's a "separate" tool. Unless it's impossible to make it into one? Or at least, the Directive with a path for BinMod should be something more mnemonic?
these kinds of discussions should take place on the github pull request, that way everything gets discussed beforehand, and changes and updates can take place within TAC's personal branch before it gets merged. etc. but @TAC109 you might not want to automatically accept your PR into the AutoHotkey repo until someone takes a look and comments, or allow joedf to make the final approval to merge the PR, or whatever. no biggie since TAC is just learning. just giving some more examples of how things can work

TAC109
Posts: 1098
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: Upcoming Ahk2Exe Changes (2019)

04 Nov 2019, 17:48

@joedf
joedf wrote:
04 Nov 2019, 10:14
...
@TAC109 I see, I am glad to see things are working now. Also, I'm not sure if BinMod.ahk should be included if it's a "separate" tool. Unless it's impossible to make it into one? Or at least, the Directive with a path for BinMod should be something more mnemonic?
Re BinMod.ahk: My plan is to reference it in the Compiler Directives, PostExec documentation as an example, with a link to the source itself on GitHub. The source needs to be hosted somewhere, and this seems to be as good a place as any. The help chm already has links to the Ahk2Exe source on GitHub (which I’ve updated to point to the AutoHotkey location, btw), and the error codes (also updated).


@lexikos
joedf wrote:
04 Nov 2019, 10:14
...
@lexikos I think TAC109 meant the /cp switch for Ahk2Exe, I don't remember implementing it with a no-space option... ? For AutoHotkey, I do know it's /cp65001. unless I am getting confused myself... ? :crazy:
To clarify; for AutoHotkey it’s /cp65001, but for Ahk2Exe it’s /cp 65001. I have suggested adding this parameter to your script because I have been having difficulty getting the AutoHotkey.ahk UTF-8 BOM marker to stick on GitHub for some reason. (May be finger trouble on my part? I’ll investigate further.) Anyway adding this parameter would ensure that Ahk2Exe would be compiled correctly when creating new releases.
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe

Return to “Scripts and Functions (v1)”

Who is online

Users browsing this forum: No registered users and 122 guests