Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

AutoHotkey_L v1.1.05 beta: faster RegEx and more


  • Please log in to reply
37 replies to this topic
Tuncay
  • Members
  • 1945 posts
  • Last active: Feb 08 2015 03:49 PM
  • Joined: 07 Nov 2006
Are the super global class variables like regular variables? I can overwrite the super global and then it simply does not work anymore?? If so, then any mechanism to prevent overwriting class variables would be nice, in example to catch them as warnings at least. Otherwise, it is very unsecure. Previous version complains with #Warn about usage of uninitialized variable, where the new beta 3 does not.
; AHK v1.1.05.00-beta3
#NoEnv
SendMode, Input
SetWorkingDir, %A_ScriptDir%

msgbox % func1() ; Shows "AutoHotkey"
Test := "hello"
msgbox % func1() ; Shows an empty string.

class Test
{
    __New()
    {
        this.ahk := "AutoHotkey"
    }
}

func1()
{
    obj := new Test()
    return obj.ahk
}

No signature.


Uberi
  • Moderators
  • 1119 posts
  • Last active: May 02 2015 06:05 PM
  • Joined: 23 Aug 2010
Made some quick, non-rigorous benchmarks of the Unicode version compared to the ANSI version. Amazingly, the Unicode version showed results almost twice as fast as the ANSI version!

Benchmark 1.1.05.00

To compare this with previous versions of AHK, here's the Regular Expressions section from the AHK v1.1.04.00 benchmark:

Benchmark 1.1.04.01

Impressive speedup!

I'll run the more comprehensive benchmark suite when the stable version comes out.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

is there any way to create a Super-global variable while inside a function?

Super-global variables cannot be created at run-time, but in most cases I suppose you could just put the declaration outside the function. It doesn't need to be "executed".

Are the super global class variables like regular variables?

They're not like regular variables. They are regular variables, just as class objects are regular objects. It would be more feasible to add warnings for (or some way of detecting) when an invalid value is passed to new.

If so, then any mechanism to prevent overwriting class variables would be nice,

A script may wish to modify them by design.

Previous version complains with #Warn about usage of uninitialized variable, where the new beta 3 does not.

You are mistaken. If your example was meant to demonstrate your point, please note that Test is not uninitialized - it has been assigned an object, and then a string.

Amazingly, the Unicode version showed results almost twice as fast as the ANSI version!

That doesn't seem right. What's "blank run"? An empty loop? Running 1,000,000 iterations isn't enough to get a consistent reading. On my system, (100 million iterations of) a blank loop on the Unicode 32-bit version takes 8% longer than the ANSI version and 4% longer than the Unicode 64-bit version. Your "v1.1.04.01" results for RegEx look very similar to your "v1.1.05.00 ANSI" results...

Uberi
  • Moderators
  • 1119 posts
  • Last active: May 02 2015 06:05 PM
  • Joined: 23 Aug 2010

Amazingly, the Unicode version showed results almost twice as fast as the ANSI version!

That doesn't seem right. What's "blank run"? An empty loop? Running 1,000,000 iterations isn't enough to get a consistent reading. On my system, (100 million iterations of) a blank loop on the Unicode 32-bit version takes 8% longer than the ANSI version and 4% longer than the Unicode 64-bit version. Your "v1.1.04.01" results for RegEx look very similar to your "v1.1.05.00 ANSI" results...


Thanks for pointing that out. Yes, blank run (control group) is an empty loop. As for the similarity between v1.1.04.01 and v1.1.05.00a results, I will investigate that when Stable comes out (I am nearly certain I have used the correct versions for the benchmark script, however).

Until then, I'll go by your results :).

Tuncay
  • Members
  • 1945 posts
  • Last active: Feb 08 2015 03:49 PM
  • Joined: 07 Nov 2006

A script may wish to modify them by design.

But the special var can be overwritten silently by end user, from any function.

You are mistaken. If your example was meant to demonstrate your point, please note that Test is not uninitialized - it has been assigned an object, and then a string.

The point of that example was to demonstrate that a user working on global space can unintended overwrite the class object, while working with global variables. And no hint is given to the user, which can lead to horror debug scenarios.

AutoHotkey can explain better than my English capabilities could:
; AHK v1.1.05.00-beta3
#NoEnv
SendMode, Input
SetWorkingDir, %A_ScriptDir%

msgbox % func1() ; Shows "AutoHotkey"
msgbox % func2() ; Overwrite.
msgbox % func1() ; Shows an empty string.

class Test
{
    __New()
    {
        this.ahk := "AutoHotkey"
    }
}

func1()
{
    obj := new Test()
    return obj.ahk
}

func2()
{
    Test := "hello"
}
Lock and unlock features for variables comes to my mind.
Maybe such class variables should be super global only inside the class? Otherwise, we have to care about too many super globals if we have many classes. You never know what class you could need later and maybe you forget what variables you have used in your big program, even in functions.

No signature.


jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009

... a user working on global space can unintended overwrite the class object, while working with global variables ... Lock and unlock features for variables comes to my mind.

Moreover, a function could overwrite any super-global variable unintentionally. My thought is to have variables be super-global based on a naming prefix. For example, in ruby an variable that begins with a $ is global. This would also allow a function to create a super-global variable. As far as class/prototype objects, I'd like to see the functionality for an object to prevent itself from being deleted - perhaps a locking feature like Tuncay suggested.

EDIT

If you want to prevent an object reference from being removed from a variable, what you really want is to prevent assignment of the variable.

Yep - that's what I was trying to get at.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
I'm against any such (lock/unlock) features if they would require extra checks for every variable assignment. However, I've realized that the majority of cases could probably be detected at load time (which would be more effective anyway), so I'll look into adding optional warnings. On the other hand, I believe it is the class author's responsibility to use a name that isn't likely to be used by the user - better to avoid the conflict than require them to choose a different name. It is apparent (from multiple threads in Ask for Help) that users don't want or expect to have to declare the class in each function they use it from, which essentially means they expect it to be super-global.

You are mistaken. If your example was meant to demonstrate your point, (...)

The point of that example was (...)

Okay - your example wasn't "meant to demonstrate your point", so you can ignore the rest of my statement.

Maybe such class variables should be super global only inside the class?

That would almost entirely defeat the point.

Otherwise, we have to care about too many super globals if we have many classes.

So don't "have many classes"; or don't put them all in the global space. Nested classes don't need global variables.

I'd like to see the functionality for an object to prevent itself from being deleted

An object will only be deleted if you have no references to it, in which case there's no point keeping it around. If you really want to, you can prevent deletion by keeping a reference to the object somewhere or by calling ObjAddRef. However, that won't help in this case. Each object derived from a class object holds a reference to that class object (in base). When references to an object exist, the object will not be deleted.

If you want to prevent an object reference from being removed from a variable, what you really want is to prevent assignment of the variable.

My thought is to have variables be super-global based on a naming prefix. For example, in ruby an variable that begins with a $ is global.

I despise such prefixes.

Tuncay <mobile>
  • Guests
  • Last active:
  • Joined: --
I can see coming that many users will be against super globals. Would be a new #NoSuperGlobals directive feasable? (Or choose another name.)

It should be noted in the documentation, that a class user is self responsible not to overwrite the class variable. And may be a recommendation about naming classes could be given, so that we can build an infastructure without to care future, as nobody would use variables with that prefix to prevent unwanted things.

Prefixes let the source look more cryptic, yes, but in this case they are needed. Again, only by recommended convention as best practice.

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
How about making class variables visible only to the new operator? Other point: If they were stored separately from other superglobals they could simply not be accessed in assignments.

  • Guests
  • Last active:
  • Joined: --

How about making class variables visible only to the new operator?

Sounds good to me.

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
They would still have to exist as global variables though so you can access their static properties.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
Beta 4:
[*:25bvs215]Fixed match-so-far unavailable in callouts with O) option.
[*:25bvs215]Fixed GuiControlGet "validating" the wrong parameter at load-time.
[*:25bvs215]Fixed COM errors throwing exceptions even when TRY isn't used.
[*:25bvs215]Fixed a bug affecting scripts which use a single variable in one arg and reallocate it via an expression in a subsequent arg.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
Beta 5:
[*:2lik1gji]Fixed 'throw' in a regex callout not causing matching to abort.
[*:2lik1gji]Changed 'throw' to allow its arg to be omitted - throws an Exception object.

Tuncay
  • Members
  • 1945 posts
  • Last active: Feb 08 2015 03:49 PM
  • Joined: 07 Nov 2006
Thx to working on throw, especially about the RegEx callout thing. But I am not fully understanding what you mean by "not causing matching to abort". Do you mean the RegEx works even if an throw is used in Callout function?

No signature.


Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
If you run my example with beta 4, you will see that even though the first callout throws an exception, the second callout is called and throws another exception, overwriting the first. When RegExMatch completes, execution is transferred to the CATCH block.