@JoeWinograd
Oh yeah, should be DDL (darned spell checker!j
Upcoming Ahk2Exe Changes (2024)
Re: Upcoming Ahk2Exe Changes (2019)
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
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
Re: Upcoming Ahk2Exe Changes (2019)
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.
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]
Re: Upcoming Ahk2Exe Changes (2019)
@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?
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
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
Re: Upcoming Ahk2Exe Changes (2019)
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
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.
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
Re: Upcoming Ahk2Exe Changes (2019)
@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
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
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
Re: Upcoming Ahk2Exe Changes (2019)
@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
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
Re: Upcoming Ahk2Exe Changes (2019)
@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
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
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
Re: Upcoming Ahk2Exe Changes (2019)
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.
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
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
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
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
not necessarily, there are many ways to skin a cat
Re: Upcoming Ahk2Exe Changes (2019)
@guest3456
Ok, I can understand the flow you outlined
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
Ok, I can understand the flow you outlined
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
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
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
Re: Upcoming Ahk2Exe Changes (2019)
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
Re: Upcoming Ahk2Exe Changes (2019)
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.
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.
Re: Upcoming Ahk2Exe Changes (2019)
@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
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
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
Re: Upcoming Ahk2Exe Changes (2019)
It might pay to add /cp 65001 to your parameters to ensure the script is processed as UTF-8.lexikos wrote: ↑12 Oct 2019, 19:56@TAC109
The release script compiles Ahk2Exe like this:I suppose that should work.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%
If someone updates the AutoHotkey/Ahk2Exe repo, I will just have to adjust the 'origin' remote in my local configuration.
...
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
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
Re: Upcoming Ahk2Exe Changes (2019)
@TAC109 This desync is most likely due to the rebase and different merges I did... The forks were no longer in sync with yours... :/
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]
Re: Upcoming Ahk2Exe Changes (2019)
@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.
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
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
Re: Upcoming Ahk2Exe Changes (2019)
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
if joedf rebased the main repo, then your repo would be out of sync regardless.TAC109 wrote: ↑03 Nov 2019, 21:02However, 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?
deleting your feature branches shouldn't matter for keeping your master in sync
Re: Upcoming Ahk2Exe Changes (2019)
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.
Re: Upcoming Ahk2Exe Changes (2019)
@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... ?
@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... ?
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]
Re: Upcoming Ahk2Exe Changes (2019)
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
Re: Upcoming Ahk2Exe Changes (2019)
@joedf
@lexikos
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).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?
@lexikos
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
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 251 guests