Writing AHK Interpreters for Mac - Any plans for the future / current projects? And other Qs...

Get help with using AutoHotkey (v1.1 and older) and its commands and hotkeys
User avatar
Tigerlily
Posts: 377
Joined: 04 Oct 2018, 22:31

Writing AHK Interpreters for Mac - Any plans for the future / current projects? And other Qs...

11 Mar 2019, 21:29

Hello AHK Community :D

It seems that this is an issue with AHK - that it does not support other OS than Windows. Curious about why mostly all other programming languages have an interpreter for Mac, but AHK does not. It would seem that having this sort of support would help keep AHK more competitive, and without this support, AHK may never actually be as popular in terms of number of users as say.. Python?

I know that AHK is supported purely by users - I'm curious how other programming languages made that "jump" from being solely supported by users, to being able to actually hire employees to continue to develop and maintain the more mainstream languages (Java, Javascript, Python, C, C+, C#, etc.)?

While I'd love to develop an AHK interpreter for Mac, doing something like that is way over my head and I wouldn't have a clue on where to start (other than downloading AHK's source code, learning C++, and studying it). Maybe in the future when I have more knowledge, I could do this.

I'm curious, how would other programming languages that only have interpreters that support the Windows OS make that jump to also support Mac? From my understanding, C++ interpreters are supported on Mac. Is it because the underlying framework of the Mac OS is set up so different than Windows OS that it takes considerable amount of planning, time, and testing to "match up" Windows automation programming in C++ to create the equivalent output using with Mac automation programming in C++?

I wish had more support on other OS, for the sake of compatability, sharing, etc. I often have many friends and collegues who only use Mac, so I can't write any code for them in AHK. I recently heard of a business who somehow used Lua scripting in combination with AHK to provide AHK programming in Mac, but I don't know the fine details of that or how accurate it is.

I would love to somehow bridge this barrier / gap for AHK at some point... Are there any plans for the future to create this sort of support? Reading around recently it appears there are not many people actively working on AHK source code development, wish there was a way to jumpstart that current developer deficiency.


All insights, opinions, comments, and facts related to this are happily welcomed. :rainbow:
-TL
User avatar
Tigerlily
Posts: 377
Joined: 04 Oct 2018, 22:31

Re: Writing AHK Interpreters for Mac - Any plans for the future / current projects? And other Qs...

20 Mar 2019, 13:21

8-) :?: :?: Wondering if anyone has any insights, opinions, comments, facts regarding this topic. :idea: :thumbup:
-TL
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Writing AHK Interpreters for Mac - Any plans for the future / current projects? And other Qs...

21 Mar 2019, 20:33

I think this issue centers around the language that developers know, what tools they use, and interest. For AutoHotkey to be on the macOS, Linux, or Android, the developer would debatably have to be using a version of AutoHotkey compiled with GCC or Clang. Visual Studio has the capability to do this, but the developer would have to be familiar with those platforms, as oppose to simply just using the Windows OS. Debatably, it might be better to use GCC as oppose to Visual Studio, but that's hard to say. Likely a very experienced or very talented programmer would be in the best position to decide such.

The next issue is the C++ language as oppose to other languages like C#, Java, Object Pascal, or Red. Arguably, the tools that C++ programmers often use, don't lend themselves to cross-platform and cross-compiling like what are present in other languages. Since AutoHotkey's interpreter is written in C++, it would take a tremendous effort to translate it into a different language. The developer would likely need to be good at multiple programming languages, such as C++ and C# or Object Pascal, for example. Though there are possible other solutions. Such as only porting over only a small section of AutoHotkey code (a smaller and more limited interpreter) or writing a transpiler (which could translate AutoHotkey code to a language other than C++ and cross-compile for a different OS). This also includes that the code in the interpreter to do a particular task in the different OS, could be much different from the C++ code for the Windows OS. So more than just translating, but writing lots of new code.

Lastly, the AutoHotkey community would need a developer with the required skill set, who would be interested in taking on such a project and making an interpreter for a different OS. A possibility, if a particular person or group wants a new interpreter on a different OS, is to openly solicit a developer to do such. Possibly using other boards, in addition to this one, or blogs. AutoHotkey appears to have a significant presence on Reddit and other places.
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Writing AHK Interpreters for Mac - Any plans for the future / current projects? And other Qs...

22 Mar 2019, 05:42

evilC wrote:
22 Mar 2019, 05:33
AHK is basically a wrapper around the Win32 APIs
As such, it's fundamentally pointless to try and implement it on Mac, because most of the mechanisms it uses simply don't exist on Mac
I don't think that's true, because that is looking at the AutoHotkey language as equivalent to the C++ interpreter for the Windows OS.

You can have commands such as Run or Loop using completely different code for an interpreter, for the macOS. As far as the AutoHotkey script and language used, it would be the same. While the code used for the macOS interpreter can be completely different and not based on the Win32 API. Though you would have to decide what AutoHotkey language you want to use on different OSes.

What remains the same is the AutoHotkey language used, not that C++ code used on the Windows OS must be the same code used on the macOS. A person needs to change their thinking about what is AutoHotkey. It's about making the AutoHotkey language exportable to different OSes versus making the same C++ code used for the Windows OS exportable to different OSes. One is much more possible than the other.

Also, various programming languages lend themselves better to cross-platform and cross-compiling. Examples- C#, Object Pascal (FPC, Free Pascal Compiler), Java, Python, Red, etc... Though it's not to say that using C++ is not possible, it's more about the tools that are available.
Last edited by SOTE on 22 Mar 2019, 06:00, edited 1 time in total.
User avatar
evilC
Posts: 4822
Joined: 27 Feb 2014, 12:30

Re: Writing AHK Interpreters for Mac - Any plans for the future / current projects? And other Qs...

22 Mar 2019, 05:58

SOTE wrote:
22 Mar 2019, 05:42
I don't think that's true, because that is looking at the AutoHotkey language as equivalent to the C++ interpreter for the Windows OS.
There is no such thing as a C++ interpreter, C++ is compiled

Cross-platform AHK has been tried before (See IronAHK) and didn't really get anywhere
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Writing AHK Interpreters for Mac - Any plans for the future / current projects? And other Qs...

22 Mar 2019, 06:09

evilC wrote:
22 Mar 2019, 05:58
SOTE wrote:
22 Mar 2019, 05:42
I don't think that's true, because that is looking at the AutoHotkey language as equivalent to the C++ interpreter for the Windows OS.
There is no such thing as a C++ interpreter, C++ is compiled

Cross-platform AHK has been tried before (See IronAHK) and didn't really get anywhere
Various other languages are able to make a compiled executable, which can act as an interpreter. Object Pascal, Red, C#, etc...

AutoHotkey scripts are interpreted. https://en.wikipedia.org/wiki/Interpreter_(computing). Your AutoHotkey scripts are not a real compiled C++ executable. It's possible for an AutoHotkey script to use an interpreter, other than a C++ one.

IronAHK was not completed, because the developer disappeared. However, he did make working code and proved the concept (https://github.com/Paris/IronAHK). That the developer stopped working on it, appears to be for other reasons than simply technical, like contentious or combative relationships. The story of IronAHK's developer is quite complicated, just by the parts that are available on the Internet. Also, C# is more developed and much more cross-platform than it was 10 years ago. Refer to Xamarin (https://visualstudio.microsoft.com/xamarin/) and .NET Core (https://dotnet.microsoft.com/download), which are for making apps on the macOS, Linux, and Android.
gregster
Posts: 8916
Joined: 30 Sep 2013, 06:48

Re: Writing AHK Interpreters for Mac - Any plans for the future / current projects? And other Qs...

22 Mar 2019, 06:19

Disappeared? That's one way to call it. To me, it looked like he was busy ruining the original forum - what in the end caused the split at the time and the creation of the AHK foundation.
(and of course running his game cheat company - or whatever).
Someone would have picked up IronAHK, if it would be easy. They can still do... its license seems pretty open.
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Writing AHK Interpreters for Mac - Any plans for the future / current projects? And other Qs...

23 Mar 2019, 07:54

gregster wrote:
22 Mar 2019, 06:19
Disappeared? That's one way to call it. To me, it looked like he was busy ruining the original forum - what in the end caused the split at the time and the creation of the AHK foundation.
(and of course running his game cheat company - or whatever).
Someone would have picked up IronAHK, if it would be easy. They can still do... its license seems pretty open.
You are correct about the license for IronAHK (https://github.com/Paris/IronAHK/blob/master/license.txt). It's wide open, and is kind of equivalent to a MIT License. Debatably, C# might be considered cross-platform enough for the macOS, Linux, and Android. But the next things to consider are:

1) Are there any volunteer C# developers willing to take it on?

2) A new fork would need to be created on GitHub, so that developers can actively contribute.

3) Are any of the past IronAHK contributors willing to contribute to a new fork?

There were several other contributors to the IronAHK project. Link- https://github.com/Paris/IronAHK/graphs/contributors

Of these, IsNull stands out. It appears he's still quite active on GitHub. https://github.com/IsNull

He is also a member of the AutoHotkey forum, but hasn't posted in quite a long time.

This is not to say that IsNull must be involved, just that he might be more familiar with the source code. However, some other developers could step in and figure it all out.

4) Probably the C# language is the best candidate, because those familiar with C++ will likely pick it up the fastest, as oppose to other programming languages.

After C#, probably the next candidate seems to be Object Pascal (as there are a lot of free tools for it), but the language difference could create greater hurdles. Though arguably, if going the Object Pascal or something a bit more radical like Red, a transpiler (AutoHotkey script translated directly into the code of a different language) might be the best way to go.

5) Rebooting or forking IronAHK might be the most feasible, and something to look into very deeply before trying anything more radical, as there is already a lot of code written. https://github.com/Paris/IronAHK

Return to “Ask for Help (v1)”

Who is online

Users browsing this forum: garry, Google [Bot], marypoppins_1, Rohwedder, RussF and 148 guests