Keysharp - the resurrection of IronAHK

Talk about things KeySharp, some related to AutoHotkey or C#
User avatar
mfeemster
Posts: 104
Joined: 24 Apr 2020, 18:30

Re: Keysharp - the resurrection of IronAHK

18 Sep 2021, 00:24

I'm back with a big update. Before I get into it, I am pushing back the initial publication of the code from October to November/December. These last few parts are proving to be rather difficult.

#directives are done, with support for inline variables such as:

Code: Select all

#Include "%A_ScriptDir%"

These #directives also include some new ones that are not present in AHK. They allow you to set the various Assembly Info fields that C# supports included in this example:

Code: Select all

#ASSEMBLYTITLE This is a title!
#ASSEMBLYDESCRIPTION This is a description!
#ASSEMBLYCONFIGURATION This is a config!
#ASSEMBLYCOMPANY This is a company!
#ASSEMBLYPRODUCT This is a product!
#ASSEMBLYCOPYRIGHT This is a copyright!
#ASSEMBLYTRADEMARK This is a trademark!
#ASSEMBLYVERSION 9.8.7.6

Functions are done with support for global, local, and static variables, as well as parameters and default parameters. Nested functions are not supported yet, I will punt on those until later.

All of the above have been unit tested.

I will work on Labels/goto next.


In addition to the above, here is a detailed technical update about what else I've been working on. Keep reading if you enjoy the nitty gritty details.

I've made some fundamental changes to how variables are handled. The code I inherited from IronAHK kept all variables in a map, and looked them up via string. So to get the value of your variable x, the generated code would be Vars["x"].

Inside the [] operator was a lock, and a map (Dictionary<K, V> in C#) lookup. While this normally wouldn't matter, if you were doing millions of variable accesses, it would impact performance.

In addition, it tried to manage scope with a complex string/naming scheme where each scope level was delimited by a period '.'

So if you had a variable x in a function named func(), it would be referred to as "func.x"

The pro of this design was that all variables were %dynamically% accessible.

I started running into problems when implementing the global/local/static variables in functions. So I pivoted and decided to completely redo how variables are declared, read from and written to.

Variables are now just normal C# variables of type object. So if you declare

Code: Select all

x := 3
in your script, it will translate to the following line in C#:

Code: Select all

object x = 3;
This should greatly enhance performance, and also will relieve me of having to manage the scoping/lifetime behaviors of each variable. The built in C# language rules will handle that now.

The downside is that variables will now only accessible by dynamic lookup if they are global. Function variables will no longer be accessible dynamically. For example:

Code: Select all

x := 11
y11 := 99
y%x% := 123
Will work fine if those are global variables. The result is that y11 would have the value 123.

However, y%x% will not work if they are function variables, such as:

Code: Select all

func()
{
	x := 11
	y11 := 99
	y%x% := 123
}
The reason being is that C# cannot look up local function variables by name using reflection.

I hope this is not a deal breaker.
Last edited by mfeemster on 18 Sep 2021, 12:37, edited 1 time in total.
ahk7
Posts: 572
Joined: 06 Nov 2013, 16:35

Re: Keysharp - the resurrection of IronAHK

18 Sep 2021, 02:43

mfeemster wrote:
18 Sep 2021, 00:24

Code: Select all

#ASSEMBLYTITLE This is a title!
#ASSEMBLYDESCRIPTION This is a description!
#ASSEMBLYCONFIGURATION This is a config!
#ASSEMBLYCOMPANY This is a company!
#ASSEMBLYPRODUCT This is a product!
#ASSEMBLYCOPYRIGHT This is a copyright!
#ASSEMBLYTRADEMARK This is a trademark!
#ASSEMBLYVERSION 9.8.7.6
As I'm not familiar with ASSEMBLY - How are these different to those used for ahk2exe? https://www.autohotkey.com/docs/misc/Ahk2ExeDirectives.htm#SetProp
User avatar
joedf
Posts: 8937
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: Keysharp - the resurrection of IronAHK

18 Sep 2021, 08:14

Cool, but as @ahk7 mentioned. I believe our current ahk2exe-setprop meets this feature.
Ideally, if this new interpreter is compatible with the current ahk2exe.ahk script, then ahk2exe could "compile" itself and other keysharp scripts. :thumbup:
That is unless some differences are intended. :think:
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]
User avatar
mfeemster
Posts: 104
Joined: 24 Apr 2020, 18:30

Re: Keysharp - the resurrection of IronAHK

18 Sep 2021, 11:13

ahk7 wrote:
18 Sep 2021, 02:43
mfeemster wrote:
18 Sep 2021, 00:24

Code: Select all

#ASSEMBLYTITLE This is a title!
#ASSEMBLYDESCRIPTION This is a description!
#ASSEMBLYCONFIGURATION This is a config!
#ASSEMBLYCOMPANY This is a company!
#ASSEMBLYPRODUCT This is a product!
#ASSEMBLYCOPYRIGHT This is a copyright!
#ASSEMBLYTRADEMARK This is a trademark!
#ASSEMBLYVERSION 9.8.7.6
As I'm not familiar with ASSEMBLY - How are these different to those used for ahk2exe? https://www.autohotkey.com/docs/misc/Ahk2ExeDirectives.htm#SetProp
Good point. Yes, these are similar and there is overlap. But the directives I listed will also be put into a special informational area in the exe for .NET programs.

https://docs.microsoft.com/en-us/dotnet/api/microsoft.visualbasic.applicationservices.assemblyinfo?view=net-5.0

It's not that important, and SetProp() will also do what most people need. This is just specific to .NET.
User avatar
mfeemster
Posts: 104
Joined: 24 Apr 2020, 18:30

Re: Keysharp - the resurrection of IronAHK

18 Sep 2021, 11:18

joedf wrote:
18 Sep 2021, 08:14
Cool, but as @ahk7 mentioned. I believe our current ahk2exe-setprop meets this feature.
Ideally, if this new interpreter is compatible with the current ahk2exe.ahk script, then ahk2exe could "compile" itself and other keysharp scripts. :thumbup:
That is unless some differences are intended. :think:
There will be slight differences. This project is not ahk2exe, it's something entirely different. It's a C# port which is intended to be cross platform, named Keysharp.

I do envision eventually adding support for a script to be able to compile another script. But that's a ways in the future.
User avatar
mfeemster
Posts: 104
Joined: 24 Apr 2020, 18:30

Re: Keysharp - the resurrection of IronAHK

19 Sep 2021, 15:08

Labels, including inside of switch/case statements, are done.

Note, this is the V2 style of labels where they behave just like labels in every other normal language. I am NOT supporting the V1 style where they are sort of pseudo-functions.
User avatar
mfeemster
Posts: 104
Joined: 24 Apr 2020, 18:30

Re: Keysharp - the resurrection of IronAHK

26 Sep 2021, 11:11

DllCall() is done, except for usage with COM because I haven't done COM yet.
burque505
Posts: 1731
Joined: 22 Jan 2017, 19:37

Re: Keysharp - the resurrection of IronAHK

26 Sep 2021, 16:55

@mfeemster, that is great news indeed.
Thanks once again for all your work.
Regards,
burque505
User avatar
tank
Posts: 3122
Joined: 28 Sep 2013, 22:15
Location: CarrolltonTX
Contact:

Re: Keysharp - the resurrection of IronAHK

26 Sep 2021, 18:01

com makes no sense outside of windows. just my 2 cents.

also please msg me when you post code i very do mch want to feature it and offer direct hosting for downloads. we all accept that initial versions arent ready for primetime. but the more exposure the better.

in all things i humbly draw attention that asside from the winforms topic. the appeal of ahk is to non programers. simplified easy to understand
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;
Telegram is the best way to reach me
https://t.me/ttnnkkrr
If you have forum suggestions please submit a
Check Out WebWriter
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Keysharp - the resurrection of IronAHK

27 Sep 2021, 13:29

In regards to COM, what I've seen done in other cross-platform programming languages is taking a modular-like approach. Code that would be specific to Windows could be in its own modules or units (terminology used is different in various languages) that can be imported, kind of like the UDF (User-Defined Function) or #Include concept, except more fundamental to the structure of the language. So there could possibly be a Windows, Linux, or macOS module or unit that is used via some type of import mechanism. Maybe something to look into, as to how such is implemented in various languages.
User avatar
tank
Posts: 3122
Joined: 28 Sep 2013, 22:15
Location: CarrolltonTX
Contact:

Re: Keysharp - the resurrection of IronAHK

27 Sep 2021, 17:32

you dont understand what COM is. COM is exclusively a microsoft concept. the manner in which you can or cant connect to a running process for other OS is so different that it has no place in a cross platform scripting solution.
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;
Telegram is the best way to reach me
https://t.me/ttnnkkrr
If you have forum suggestions please submit a
Check Out WebWriter
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Keysharp - the resurrection of IronAHK

27 Sep 2021, 20:01

Apologies if any mistaken impressions or interpretations were given. Wasn't presenting that COM isn't from Microsoft nor that COM was to be used on other OSes. Instead was referring to how other languages have code and specific syntax for various other different OSes contained in different modules or units. For example, if wanting to use something that is only done on Window OSes, there could be a module or unit called Windows for such. I have used such languages, but won't drag that into this discussion. Was simply bringing up the concept of it.

At the moment, we do know that Keysharp is to be cross-platform, but we don't know specific implementation details. So leaving that for mfeemster to address such, or not, as he pleases.
Last edited by SOTE on 27 Sep 2021, 20:07, edited 1 time in total.
User avatar
tank
Posts: 3122
Joined: 28 Sep 2013, 22:15
Location: CarrolltonTX
Contact:

Re: Keysharp - the resurrection of IronAHK

27 Sep 2021, 20:03

ok, well would u concure that perhaps acknowlege maybe it isnt initial release worthy
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;
Telegram is the best way to reach me
https://t.me/ttnnkkrr
If you have forum suggestions please submit a
Check Out WebWriter
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Keysharp - the resurrection of IronAHK

27 Sep 2021, 20:20

tank wrote:very do mch want to feature it and offer direct hosting for downloads
Awesome! Of course I can only speak for myself, but would think the AHK community agrees and thanks you.
tank wrote:...the appeal of ahk is to non programers. simplified easy to understand...
I agree with you on this. One of the great strengths of AHK is its ease of use and being easy to understand. Maybe mfeemster will give his thoughts on such.
User avatar
mfeemster
Posts: 104
Joined: 24 Apr 2020, 18:30

Re: Keysharp - the resurrection of IronAHK

28 Sep 2021, 11:39

I am encouraged by everyone's enthusiasm, but let's not jump the gun just yet.

-Yes, there are parts of AHK that are totally Windows specific, for example COM as well as the registry. I've thought about this on and off. What should be done when someone tries to make a registry call on Linux? Should the function not exist, thus giving a compiler error? Should it exist, and thus compile, but then throw an exception when called? Should it exist, compile, run and just do nothing? I haven't decided yet, we'll need to figure that out when the time comes. Right now, the focus is getting this running on Windows, so let's not get distracted.

-As for implementing it, don't concern yourself with that. I'll either do some type of interface/class hierarchy or I'll just use #define to remove OS specific code on OSes where it doesn't belong. Either way, don't worry, I'll handle that when the time comes.

-As for language simplicity, I am implementing the AHK language, so if you think that is sufficiently simple, then Keysharp will be simple too, because it's the same spec. There are a few minor differences, but I will document those when the time comes. For now, I do have a few parsing issues. The code prefers parens on function calls, and gets confused when they don't exist. This is probably fixable, but I thought I should note it and get some input from you. What should this do:

Code: Select all

MsgBox this is some unquoted text
vs

Code: Select all

MsgBox "this is some quoted text without parens"
vs

Code: Select all

MsgBox("this is some quoted text with parens")
Right now, the parser prefers the last one. I would note that most of the V2 documentation shows the example calls like that.

In other news, NumPut() and NumGet() are done, and I am continuing to work on the remaining pieces.
User avatar
kczx3
Posts: 1640
Joined: 06 Oct 2015, 21:39

Re: Keysharp - the resurrection of IronAHK

28 Sep 2021, 13:47

I always use the last variation and always prefer that. The first should throw a warning I'd guess since it would try to concatenate variables of those names together via auto-concat. Your parser would be simpler to just not support the command-style function calls though.
burque505
Posts: 1731
Joined: 22 Jan 2017, 19:37

Re: Keysharp - the resurrection of IronAHK

28 Sep 2021, 15:31

I would be more than happy with just the last variation, although it would be nice to have the other options.
Would something like this be possible, I hope?

Code: Select all

myVar := "random content"
MsgBox("This message contains " myVar ".")
Or maybe this?

Code: Select all

myVar := "random content"
MsgBox("This message contains " + myVar + ".")
User avatar
boiler
Posts: 16709
Joined: 21 Dec 2014, 02:44

Re: Keysharp - the resurrection of IronAHK

28 Sep 2021, 16:22

burque505 wrote: Or maybe this?

Code: Select all

myVar := "random content"
MsgBox("This message contains " + myVar + ".")

Why not stick with AHK's (optional) concatenation operator like below?

Code: Select all

myVar := "random content"
MsgBox("This message contains " . myVar . ".")
burque505
Posts: 1731
Joined: 22 Jan 2017, 19:37

Re: Keysharp - the resurrection of IronAHK

28 Sep 2021, 16:30

That would be fine too, of course!
User avatar
mfeemster
Posts: 104
Joined: 24 Apr 2020, 18:30

Re: Keysharp - the resurrection of IronAHK

29 Sep 2021, 14:59

At the moment, the following two work:

Code: Select all

MsgBox("This message contains " myVar ".")

Code: Select all

MsgBox("This message contains " . myVar . ".")
Let's not get sidetracked on this any further for now. I will continue working on implementing the remaining parts of the spec I have left.

Return to “KeySharp”

Who is online

Users browsing this forum: No registered users and 1 guest