Any dependency on <base> pseudo-property?

[Lexikos]

Does the extension have any features or behaviour dependent on the existence of the .<base> pseudo-property?

(This debugger-only property retrieves an object's base, but unlike .base, any child properties are evaluated in the context of the original object, not the base. So x.<base>.<base>.y functions like super.y within the class of x.)

The reason I ask is that I am considering removing it to reduce code size, after making it mostly redundant.

A problem with v2.1-alpha.9 and earlier is that some objects have useful properties that are implemented as getters, and inspecting these properties requires expanding <base>, sometimes multiple times. This problem is compounded by typed properties, which are always defined in a prototype and therefore never own properties of the instance/struct.

I've been working on solving this by implementing an enumerator which returns inherited properties alongside own properties, and then utilizing that in the debugger engine. For example, Map('a', 'Alpha', 'b', 'Binary') gives this (with vscode-autohotkey-debug and my current AutoHotkey build):

Capacity: 2
CaseSense: "On"
Count: 2
["a"]: "Alpha"
["b"]: "Binary"

In order for x.<base> (where not followed by .something) to have its previous behaviour, a mechanism must exist to override this, otherwise dynamic properties are omitted because they cannot be evaluated. It would be similar to something like Map().base.Count, which invokes the getter for Count but passes it the Prototype and not the map. In most cases any properties returned under .<base> will be redundant; it would be useful only for overridden/shaddowed properties.

As of yet I have not removed the code for evaluating x.<base> or x.<base>.y, but I think the former isn't working well because the mechanism described above doesn't exist. So I was leaning toward removing it entirely, but it looks like this extension might depend on it for some things.

• getInheritedChildren - not sure how this is used, but I'm guessing it will be redundant when inherited properties are returned directly. You might be able to detect whether it is needed based on whether a <base> sub-property was returned.
• safeFetchProperty - shouldFixBug replaces base with <base> under certain conditions. When is this needed? I couldn't think of any instance where it would actually be correct. For instance, with m := Map(), the script cannot do m.base.Count; the correct result is to throw, so the debugger showing 0 is misleading. (Side note: It also mangles parts of the property name that contain "base", like "abased".)
• I think formatProperty filters out <base>, which should just have no effect if that property wasn't returned.
• I think evalExpression is using <base> to retrieve the class name of each prototype for your is operator. The same could be done with base, but that would fail if the script overrides it. It's probably a good enough reason to at least support x.<base>.y (which still works in my current build).

Have I missed anything that might depend on either of the following?

• x.<base> returning properties with getters.
• x.<base>.y evaluating getters with x as this.

[zero-plusplus]

The premise is that this extension is the first program I have completed, so it is littered with unreasonable solutions (This is why v2.0.0 is being rewritten).

---

Answer from here.

I agree with removing <base>.
vscode-autohotkey-debug v2.0.0 will be implemented without <base>.

However, they may use as a workaround to support previous versions.
If used, I would implement it in a way that it is not mixed in with the main process.

---

PS.
@Lexikos

I should mention that I never use <base>, but I might divert this syntax.

Specifically, the usage is like <hitCount>. The next analyser will be based on AutoHotkey expressions, so the previous metavariable syntax such as {hitCount} cannot be used.

The <base> syntax is independent of the AutoHotkey syntax and is therefore useful for metavariable-like usage.

If you plan to use this syntax in AutoHotkey in the future, this idea is forfeited.

[Lexikos]

I found that after some refactoring (AutoHotkey/AutoHotkey@89994ea), supporting the previous behaviour of x.<base>.y evaluating like super.y is simple and with practically no increase in code size. Removing <base> altogether prevents v1.11.0 of the extension from retrieving x.base or x.__class and only reduces compiled code size by less than 400 bytes. According to my brief testing, if I remove <base> from the sub-properties of an object but keep support for querying it directly, the extension will still show the base and __class properties, and it only costs 100 bytes.

However, it breaks the is operator in breakpoint conditionals. I guess this is because the existsProperty check in evaluate fails when the property isn't listed by its parent.

[Lexikos]

MsgBox.Bind("Text")("Title") is mechanically the same as a["Text"]["Title"]

They are similar in that they are parsed sequentially (whereas x(y()) will be parsed recursively), but they are not the same. a("Text") and a["Text"] differ only in that the flags specify an invocation mode of call for one and get for the other. In future versions, a.b("Text") and a.b["Text"] will similarly differ only by flags, but v2.0.13 and v2.1-alpha.9 do not support parameters, so in those and earlier versions, a.b["Text"] invokes .b and __Item["Text"] instead of .b["Text"]. (If b doesn't accept parameters, the object will recursively invoke __Item so the result will be the same.)

This variable ... can only be accessed using an address.

I'm not sure what you mean. If a variable is exposed to the client, what is the difference between an address and a numeric name? How would the client discover the address of this variable? Why reference an internal variable by address when we can reference an object by address?

[Object(address)] is used as a way to express an object key, and to support this, x[Object(address)] (where address is literally an integer) produces an object reference as a parameter to the getter/setter of x.__Item. For example:

class __DebugArg {
    static __Item[v] => v
}

With this, property_get -n __DebugArg[Object(123)].x should retrieve the x property of the object whose address is 123. With the ability to call functions, you could instead do property_get -n ObjFromPtrAddRef(123).x.

However, if the object has been deleted, the behaviour will be undefined (it may cause the program to become unstable, or have unpredictable effects). For instance, for a property like x => {...}, the engine would write the object's property XML into the response buffer and then release the reference, deleting the object.

Suppose that you have something like this in the script:

(Any.DefineProp)(Any.Prototype, '__DebugRef', {get:
    (v => (IsObject(v) && ObjPtrAddRef(v), v))})

Then property_get -n A_Args.__DebugRef should return the value of A_Args, but if it is an object, it will increment the reference count as well. Of course, this means that you must manually release the reference, so you need a way to call ObjRelease. For current versions, you can indirectly call a function via a property getter such as:

Func.Prototype.DefineProp('__DebugCall', {get: __DebugCall})
class __DebugCall {
    __new(function) => (this.function := function)
    __Item[v]       => (this.function)(v)
}

property_get -n ObjRelease.__DebugCall[123] will release the object at address 123.

However, now an object's reference count will be incremented every time its properties are enumerated by the debugger, which is obviously bad. To prevent that, you can trick the debugger (and OwnProps) into skipping the property by redefining MinParams. This will only shadow the real parameter count, so will not affect the actual function call.

(Any.DefineProp)(Any.Prototype, '__DebugRef', {
    get: (v => (IsObject(v) && ObjPtrAddRef(v), v))
        .DefineProp('MinParams', {value: 2})})

For __DebugCall, defining static MinParams := 2 should have the same effect.

This gives you a means of controlling how long an object is retained, but if you use it, you become responsible for releasing the references when appropriate. For references used within an expression, this would naturally be done at the end of evaluating the expression.

Rather than dealing with reference counting directly, it could retain values as properties or array/map elements within the script process.

a special variable that persists only while the debugger is breaking.

If you are evaluating x(Array()) as Array() and then x(Object(123)), you need the Array to persist at least between the two property_get calls. It is sufficient for the engine to retain the last reference it returned to the client. But if x(Array(), Map()) would evaluate Array(), then Map(), then x(Object(123),Object(456)) (or equivalent using Bind), you need both the Array and the Map to persist.

This is one of my ideas: instead of releasing it immediately, the engine retains a reference to each object that it returns as a root property. If it does not make this accessible to the client, how it is stored is unimportant. What matters is the guarantee that any root object will persist while the debugger is breaking, so the client can safely reference it by address.

If the references persist only while the debugger is in a break state, you must make sure to put it into a break state before beginning evaluation.

Object addresses are also returned within property names, and the client implicitly queries these with property_get. In theory, I think that this may cause instability if the client queries a property after the key object is deleted. Refreshing the parent property first would avoid this (and your extension might already do that, for all I know).

I don't know if this is possible due to the dbgp specification, but if this object can be assigned to a variable specified with this address in property_set, then expressions like a := {} can be evaluated, can't they?

How will a special variable help?

What we need is a way to specify that the value of property_set is an object. There is the data type "object", but the specification does not appear to cover the encoding of data except to say that the data of any command (after --) must be base64-encoded. The data could be anything, and engines are expected to have different data types.

I think we need only be concerned with:

• In the engine, what engine-specific behaviours might conflict with clients which conform to the specification.
• In the client, how the supported engine(s) behave and will be guaranteed to behave in future versions.

For instance, under what circumstances would an existing client send property_set -n a -t object -- address (with address being a base64-encoded address)? If that would never happen, it would be safe for me to implement. If I give you the guarantee that it would be supported, then it would be safe for you to use. (This is hypothetical for now.)

I think that other engines don't need anything like this because they have eval. I have been putting off implementing it until the code can be revised to support it properly; in particular:

• Allowing the memory used by an expression to be freed after it is evaluated.
• Handling errors safely; i.e. not leaving incomplete Lines, functions or classes in the code when there's a syntax error (normally the program exits).

I considered implementing eval in the debugger even with these caveats, but I think properly implementing a small subset of expressions might be better. I will consider implementing eval -- a := Object() on top of the property parsing code, since it's basically the same as parsing properties within property parameters.

I am thinking that this will be supported:

• Calling functions.
• Any number of parameters. It is simple to use Bind to pass multiple parameters to a Func (or any function object with ObjBindMethod(Object(...)).Bind(...)(...)), but it is more difficult to do with a property getter. It requires getting the property getter function, which requires working out which base it is defined in.
• Recursively parsed property names within parameters.
• Direct assignments.

However, if I implement partial eval, I think it had better evaluate as an expresion would. Property names currently use """" for a literal quote mark and Object(123) for objects by address, but in a v2 expression it needs to be "`"" and ObjFromPtrAddRef(123). Property names could be returned this way and pass back to property_get, but I assume your code for evaluating x[y] and similar would rely on the current v1-like syntax.

I have also been considering whether function calls should be disabled in property_get. Depending on how clients use property_get, there is higher risk of unexpected side-effects from calling a function than from getting a property.

The { key: "value" } is actually converted to an Object("key", "value") and executed.

I assume you mean by your extension. Note that Object("key", "value") is purely a v1 construct. The __new and static Call methods of Object would be inherited by all classes by default, so they do not accept parameters.

Debuggers such as node.js have a useful feature to display the return value at the last step of a function, and this special variable may allow you to implement this as well.

I have seen this in other debuggers and it is on my list of debugger features to potentially implement. I don't see how the special variable you have suggested would be used for this. The client needs a way to query for the return value (I pictured <return>), and the engine needs to get the actual return value of the function, not the last object the debugger returned.

[zero-plusplus]

I do not have sufficient knowledge of both English and programming, so my suggestions may contain mistakes. I should mention ahead of time that this is a machine translation, so the English may be strange.

The return value is normally released immediately unless it is assigned to a variable, but with property_get it cannot be released because it may be used on the client side.

This is the problem, right?

My proposal is that it would be better to have a different life cycle than the AutoHotkey variable and manage the return values that occur for debugger convenience as different from it.

I called this variable with a different life cycle a special variable for convenience.

I think the timing for releasing special variables should be at the point when the stack frame at the time of evaluation has disappeared.
Because local variables at the time of evaluation will not be accessible at that time.

---

I have seen this in other debuggers and it is on my list of debugger features to potentially implement. I don't see how the special variable you have suggested would be used for this. The client needs a way to query for the return value (I pictured ), and the engine needs to get the actual return value of the function, not the last object the debugger returned.

I was talking only in terms of the commonality of function return values and did not think deeply about it.

[Lexikos]

Is your proposal this?

• Any object returned by the debugger will not be released until the current function returns.
• Objects will be referenced by address.

If so, the talk of special variables is just a distraction. A variable's lifecycle and an object's lifecycle are not the same. No matter what else you do with the object, its lifecycle is controlled purely by its reference count. As I demonstrated, you can control its lifecycle with only its address, not using any variables. A variable would just be a means of retaining a reference and indirectly releasing it when the variable is freed.

The client frequently queries properties automatically and sometimes unpredictably. It would not be acceptable for this to automatically extend the lifetime of a queried object to the end of the function, because the script may be designed to rely on side-effects of __Delete. However, if the debugger is in a break state, it can be expected that no code will execute, so releasing objects when the next continuation command is issued would be acceptable.

As a special case, it might be more acceptable to extend the lifetime of an object if its reference count is exactly 1 (meaning the debugger has the only reference). However, there might be cases where it would be unexpected, such as if it was the return value of a function called for its side-effects and not something the client is specifically expecting.

Supporting nested property names and multiple parameters turns out to require basically rewriting the core of property_get, so I am thinking that it will be done in the v2-1.alpha branch. I've more or less completed it and will commit it soon.

With these capabilities, evaluating ObjPtrAddRef(Array(x.y, z)) would return the address of an array with the values of the two properties, which can be any type. Then you can collectively release those values with ObjRelease(123) where 123 is the address of the array. If you want the values of the array to be returned in the same query, you can wrap it in ObjFromPtrAddRef(...) (currently this additional reference would be released immediately).

Rather than implementing DBGp expr (eval limited to expressions) and making it forward-compatible with proper eval, I think that I will implement property_set -t property -n property_to_set -- property_with_value. With either this or expr, you could instead assign a value or array to a hidden variable of your own creation. If the variable is local, the values would be released when the function returns or when you reassign it.

[zero-plusplus]

A variable's lifecycle and an object's lifecycle are not the same. No matter what else you do with the object, its lifecycle is controlled purely by its reference count.

There was a misunderstanding about variable and reference counters.

It would be acceptable to release the object when the next continuation command is issued

As a special case, it might be more acceptable to extend the lifetime of an object if its reference count is exactly 1 (meaning the debugger has the only reference)

Is this lifetime extension assumed to last until the end of the program?

Supporting nested property names and multiple parameters turns out to require basically rewriting the core of property_get, so I am thinking that it will be done in the v2-1.alpha branch. I've more or less completed it and will commit it soon.

Good news.

I'm prioritising creating a minimal debugging facility so that I can try out the new property_get, but I may ask a few questions as I don't yet know some aspects of the v2 specification.

[Lexikos]

Is this lifetime extension assumed to last until the end of the program?

It was hypothetical and not likely to be implemented.

I may ask a few questions

Feel free to ask any questions, but I may not respond promptly as I do not check my GitHub notifications regularly.

[zero-plusplus]

@Lexikos

I am working on a small patch to support v2.0.14 first, as I want to take the time to do a major update.

One problem I am currently having is that I cannot get each field of an object or instance such as obj := { a: 'a', b: 'b', c: 'c' }.

Elements of Arrays and Maps can be retrieved without any problems.

What query should I pass to property_get to get the fields a, b and c?

[Lexikos]

A bug in the page handling in v2.0.14 causes it to not return properties.

Property enumeration behaviour is changed in v2.1-alpha.10, but it does not require any changes in the extension, as far as my testing could reveal.

[zero-plusplus]

Thank you for the explanation. I had mistakenly thought that the changes had to be addressed on the extension side.

Since v2.1-alpha.10 also means no disruptive changes, I will return to the development of vscode-autohotkey-debug v2.0.0.

---

I have a question about the debugger specifications, may I create a new discussion and ask it there?

I need to understand the exact specifications to realise an idea.

I am writing here in the future with ideas for new features of the debugger adapter and suggestions on how to implement them, so if you see any problems, please let me know.

[Lexikos]

v2.1-alpha.13 will include some more changes which may affect the extension, but do not really require any changes, as far as I can tell.

AutoHotkey/AutoHotkey@f28e2232 changes all non-Object classes to delegate to Object for listing properties, so the debugger is consistent with the script (e.g. HasProp), except for ComObject. For ComValue and its subclasses, vscode-autohotkey-debug v1.11.0 was previously limiting itself to querying Value and VarType because those were listed (as demonstrated in #326), but now it instead limits itself to the actual properties which are defined by the prototypes.

AutoHotkey/AutoHotkey@d0a5aa9d changes the debugger to return classname="SomeClass.Prototype" instead of classname="Prototype" for class prototypes. This makes it easier to see which prototype you're looking at. It can be thought of as a unique type distinct from instances of SomeClass and prototypes of other classes.

AutoHotkey/AutoHotkey@73d9a398 changes the debugger to omit __Class and Base from all property listings, even when querying a prototype object directly. This was the simplest way to avoid showing __Class when querying a VarRef or ComValue, since the enumerator wouldn't detect them as inherited. Showing the class name via __Class is now redundant, and <base> is still listed.

I initially avoided changing classname="Prototype" because I didn't understand how it would impact vscode-autohotkey-debug, but it looks like the only part of the extension relying on it was the faulty workaround. This change fortunately causes existsProperty to return true for any inherited property even if that property isn't listed, because it does a direct query after finding that a.<base> is not a "Prototype". This means that a is b still works for all cases that matter, as far as I can tell.

a is Any no longer works, but has no practical use anyway. Where a.<base>.<base> is Any.Prototype, the extension won't query a.<base>.<base>.__Class because it can't find __Class in a.<base>.<base>, and the check for inherited properties fails because a.<base>.<base>.<base> doesn't exist.

I also note that a is String did not and does not work. As far as I can tell, vscode-autohotkey-debug v1.11.0 requires the v1-style a is "String". I assume it is the same for a is Primitive, a is Number, etc.

For v2.1, I think you can use something like HasBase(SomeProperty,SomeClass.Prototype) for type checks. Check the classname attribute of SomeProperty for a .Prototype suffix to exclude prototypes.

[zero-plusplus]

AutoHotkey/AutoHotkey@d0a5aa9d changes the debugger to return classname="SomeClass.Prototype" instead of classname="Prototype" for class prototypes. This makes it easier to see which prototype you're looking at. It can be thought of as a unique type distinct from instances of SomeClass and prototypes of other classes.

I like this change because I was trying out a notation like Prototype<Map> so that I could see which prototype it was in the variable value preview of the <base> in v2.0.

I initially avoided changing classname="Prototype" because I didn't understand how it would impact vscode-autohotkey-debug, but it looks like the only part of the extension relying on it was the faulty workaround. This change fortunately causes existsProperty to return true for any inherited property even if that property isn't listed, because it does a direct query after finding that a. is not a "Prototype". This means that a is b still works for all cases that matter, as far as I can tell.

This is the part I have to take care of in implementing vscode-autohotkey-debug v2.0.0.

I also note that a is String did not and does not work. As far as I can tell, vscode-autohotkey-debug v1.11.0 requires the v1-style a is "String". I assume it is the same for a is Primitive, a is Number, etc.

For v2.1, I think you can use something like HasBase(SomeProperty,SomeClass.Prototype) for type checks. Check the classname attribute of SomeProperty for a .Prototype suffix to exclude prototypes.

Initially, the plan was to limit the functions of the evaluator (AELL) to only proprietary ones, but now that it is possible to directly execute AutoHotkey functions, the plan needs to be changed significantly

I am really glad that the debugger's performance has increased and that there is more I can do.

Everything that can be replaced is based on v2 functions, but if there are functions that cannot be replaced, AELL's own functions may be needed.

If a AELL function is needed, I need to think about how to call it.

Using a AELL syntax like $FuncName() will affect the syntax that you add in the future, so idea is to evaluate the AELL function name and if it does not exist (undefined), call the AELL function on the debug adapter side.

This is because I thought it would have less impact as the behaviour would be similar to loading an AutoHotkey file with its function via /include.

Please let us know if you have any other good ideas.