AutoHotkey Community

Nice.

I wait for dynamic code insertion

Btw, do you (still) plan to let us iterate global/local variables ?
I needed that bunch of times.

Thx.

_________________

Local variables can already be enumerated, as I demonstrated earlier.

LowLevel does not and will not have access to the script's list/array of global variables. Since ListGlobalVars only gets the ListVars text, I think including it in LowLevel would not be appropriate.

Only ? Well, in AHK, almost everything is only text.

Anyway, I would like other way to get variables, that doesn't depend on redirection of OS API (although hacks like this are awesome)

Btw, the way you post it, can produce bad side-effects if some process jumps in the middle of redirection. So it should look like this:



Then, we have problem number 2:


which means that above function can not handle more then 16.347 variables user created which really makes it insufficient for large arrays, I can easily make more in simple tests...

Also, I dont' know if above code can be seen as "potentialy harmfull operation" by some software, or even OS itself (probably not).

So, you should make this available in lowlevel if possible. Something like above, maybe a bit more flexibile, like some basic filtering, ability to get only local or global variables etc...

_________________

And yet, there is problem number 3 - if variable has `r`n in its contenst it may produce side effects, for instance:



This can generaly be solved by checking each line to see if it is variable (using your lowlevel module, or using SKAN's method with fixed pointer IIRC) but this will slow down things and will also in second case create bunch of empty variables....

_________________

All good reasons not to include it in LowLevel. I consider any discussion of the drawbacks of ListGlobalVars off-topic.
What I mean is it has no real relation to the purpose or theme of LowLevel.
As I have said, LowLevel does not and will not have access to the script's list/array of global variables. Not because I don't want it; because it isn't possible, since AutoHotkey normally accesses it via a member of the Script class, which can only be referenced through a global (C++) variable.

Variable dereferences may be discovered by using __getFirstLine (or __findFunc/__findLabel) and NumGet, referring to lowlevel_outline.txt (Line, ArgStruct, DerefType.) See, for example, __getBuiltInVar. This method won't work for double-derefs/arrays. Would a function with this limitation be useful?

Thanks for this new set of toys. Very, very useful indeed!

So I'm just now getting a chance to play around with them.. & I found that I can't utilize pScopeFunc for internal commnads that fill arrays (RegExMatch).
I'm not sure if this is what you were referring to here.. as I am ignorant of what double/triple derefs are by definition. I did try searching around a bit- but didn't get too far

Is this limitation here to stay.. or this issue one that will most likely go away as your module matures

Thanks in advance..

_________________
.o0[ corey ]0o.

I hadn't thought of that. Array-creating functions/commands create local variables in the function that called them, if the base variable is local. Since the expression is executed in __expr_last(), that is where the array variables are created.

It might be possible to "synchronize" __expr_last and pScopeFunc, similar to how __getVarInContext works. However, this could only happen before or after executing the expression. In the worst case, the expression creates too many variables, causing the variable list to be reallocated, then recurses into scope func (either the expression or an interrupting thread might call it.) If the function tried to access the now-deleted variable list (i.e. by using a double-deref or ListVars), AutoHotkey would crash.

I suppose the variables could be manually copied from __expr_last, but there'd be no way of knowing which variables were created by the current expression, since variables can't be deleted. It would also leave junk in __expr_last, and the variables wouldn't be accessible by the scope func if it recurses before the expression completes.

The safest workaround is to declare 'Match' as global, or use global scope. ('Match1', 'Match2', etc. must also be declared global if you wish to access them in script.)

It will stay until I write dynamic code-insertion methods. Then you'll be able to insert the expression into the scope func itself. (__expr might always have the limitation, though.)

My vote: I like __underscores

@lexikos

please use a short & standard lib prefix and _


this is a FUNDAMENTAL and BREAKTHRU function...

should be easy to use, and safe function name wise.


even

LEX_xxx


or

my own favorate

eval_(



anyhow. my 2cents

_________________
Joyce Jamce

I voted for first option. __ in all other languages signify some form of low level thing. If I have to choose anything else it would be LL_

_________________

I also voted for the first option: keep __prefix. If this script is used to evaluate dynamic expressions (~popup calculator) it is much easier to remember not to use double underscore prefixes in user expressions, than some other restrictions, like LL_...

I've made a few modifications/additions to pave the way for additional code generation functions.

Planned functions:

• Execute a command dynamically. Probably as __exec, __cmd or __eval_cmd (__expr would become __eval_expr in this case.)
• Execute a block of script dynamically. Probably as __execScript. Would it be worth having __expr and __exec once this is implemented?
• Code generation functions - i.e. generate a simple command or function call, or complex script, for insertion into the script. This may form the backbone of __expr, __exec and __execScript.

I also discovered the \xXX regex escape sequence, so extended ANSI characters (\x80-\xFF) are now supported in variable names.

What is wrong with this script?
If a quoted string contains a comma, strange things happen.

Usually if there is an error, it will set ErrorLevel to descriptive error text. In this instance, it says "Too many parameters passed to function "Msg"." Function derefs need to know how many parameters are being passed. The code that determines this apparently does not check for quoted literal strings.

I've updated both the release and test builds.