AutoHotkey Community

AHKU = AHK + AHK_L additions + AHK_U additions

In order to make one single version, they need to talk to Chris first.

(It's been up for a while, but I forgot to post.)

Also, github/Lexikos/AutoHotkey_L.

Hi,

I have some troubles with your repository when I want to merge your branch into AutoHotkeyU. Could you apply core.autocrlf = true on it?
It's very hard to keep the EOL usage of the files in a project consistent without this setting. Sometimes the things went even worse: a file contains both LF and CRLF for some reasons.

I avoided it because when I began importing each revision, it would tell me every line of every file had changed. My understanding was that it is supposed to keep CRLF in the working copy and LF in the repository. Most of the files I was copying in should've been identical to the working copy.

I tried enabling autocrlf just now (in my local repository only); strangely, from the latest commit it "replaces" only script_object.cpp.
(I'd also moved a couple lines and deleted some commented code.)

If I checkout an arbitrary commit (like L10 or L40), it immediately shows every line of every file has changed. If I then try to checkout some other commit, it complains that I've made changes to the working copy.

Any suggestions?

@Lexikos
If you want to modify the history commits, you could use git-filter-branch. Thanks for the repository was just created, it could be considered safe to do (or other developers can't push/pull the repository after you modify the commits).

Here is how I done it (in the bash shell).

Convert the files by dos2unix utility.


Now you could check the correctness of the result. If everything looks fine, just drop the backups.


(Optional) cleanups


I recommend you clone the repository first, and then doing the above steps in the newly created repository. Finally, use "git push -f --all ; git push -f --tags" to push the changes back.

I'm not sure I accept this as a "solution." I will think more about it. I'm familiar with filter-branch, having used it repeatedly while importing my archives into git; but thanks for the git scripts.

Thanks jackieku, the scripts were very helpful. Although I didn't like the idea of git messing with the files, it seemed a necessarily evil once I realised autocrlf is enabled by default in new repositories. Anyway, my github repository has been updated with (autocrlf-friendly) `n-only files. I also took the opportunity to remove Test.ahk and rename AutoHotkey_L.sln/vcproj back to AutoHotkey.sln/vcproj in the applicable commits.

Lexikos, welcome to git
My vote is to keep the numbering. I use a number followed by a descriptor in my tags. This is the shell script i use:
I like the idea of having a A_AhkBuild (e.g. a git commit id). This could also be used as a security feature to make sure the autohotkey executable that is being used is authentic.

As far as checking for ahkl, ahku, ahkn/dll, or a specific combination there of, it may be better for the users to check for specific features instead of version numbers... test for existence of some builtin function, builtin variable, etc...

I was just starting to use objects, ran into an issue derefrencing object members in continuation sections.
the following:
fails on two levels:
1. can't assign to objects using "=", and continuation sections can't be assigned with a ":="...
2. how do you deref a object.member in a continuation section ?

For now, I guess I will use temporary variables...

How so? A_AhkBuild could contain anything, and the real source code could easily differ from the commit it identifies. While it probably couldn't be done at run-time, using a commit ID would allow the user to determine exactly what features it has, who authored it, etc.
That isn't always feasible. For instance, I've used L<num> from A_AhkVersion in LowLevel to determine if a compatible version is in use; i.e. the linked list of functions is available. There is no other way in this case.
What about differences in behaviour of functionality existing in multiple branches?
That syntax is valid only in expressions. That is not an expression. Contiuation sections have nothing to do with it, as they're merely a way of merging source lines at load-time.

They certainly can.
Use an expression.
I've thought about supporting objects (and perhaps arbitrary expressions) between percent signs in "traditional" syntax, but I think it would require fairly extensive changes.
Part of my concern was about whether to include numbering in the executable itself, as currently I have to (rather, my script has to) modify the source to update the revision number. OTOH, if it was based on a resource or the version info contained within the executable, it might be better as no source code changes would be required. (Only the compiled binary would be modified.)

Additionally, with the "proliferation" of custom builds, version numbers for individual builds become less meaningful.

One of the nice things objects makes possible is the ability pass around binary values through expressions. Unfortunately the & operator, and numput, numget don't work with object.member . Lexikos, do you plan on adding support for these?
Also, do you plan on adding support for deep copying objects?

arbitrary expessions between %% signs would be interesting, essentially enabling lisp like macros.
Could it be implemented by just expanding it internally to two lines as follows: would become:

Address-of does not work as it is not a variable. NumGet and NumPut work just fine if object.member returns an address, which is the most logical way to use it.
Not specifically. I plan to add functions for enumerating the keys/values contained within an object. This would allow a copy routine to be written in script, and many other things.
I had decided not to implement it in expressions as there are too many ways it could be implemented. I specifically mentioned traditional syntax in my previous post. This would be simple by comparison; the text outside the percent signs would be translated to literal strings/concatenations and the sub-expressions would be used as-is.

According to your example, the expression between percent signs would be used to calculate the variable or function name. For instance, calling a function explicitly by name stored in an object:
This could be implemented by a bit of clever pre-processing - all expressions are currently pre-processed into postfix form at load-time. a[b] would remain part of the overall expression, but its result would be used to determine which function to call. Above, the postfix form of the first line could be expressed as follows:

• Push t (onto the stack).
  Stack: t
• Push a.
  Stack: t, a
• Push b.
  Stack: t, a, b
• Call ObjGet with two parameters.
  (Parameters are popped off the stack and the return value is pushed onto the stack.)
  Stack: t, (result of ObjGet)
• Assign.
  (Both operands - the destination var and value to assign - are popped off the stack, and the destination var is pushed back onto the stack.)
  Stack: t
• Resolve func named %t% and replace ¿ below with a func reference.
  (This uses the same "operator" as a dynamic variable reference, but updates the associated function-call "operator" rather than finding and pushing a variable onto the stack. A reference to variable t is stored statically in the expression by load-time pre-processing.)
  Stack: t
• Call ¿ with no parameters.
  Stack: t, (result of ¿)
• Pop the return value off the stack and discard it. This is the only run-time effect of the comma operator. Although var x is still on the stack (as the result of the assignment), since this is a standalone expression it is discarded once expression evaluation finishes.

This approach was easy to implement and is fairly efficient, but isn't suited for arbitrary sub-expressions. Introducing a separate "operator" for dynamic function calls would allow function names to be calculated with arbitrary sub-expressions. For instance, the postfix form of the second line above could be expressed as follows:

• Push a.
  Stack: a
• Push b.
  Stack: a, b
• Call ObjGet with two parameters.
  Stack: (result of ObjGet)
• Pop into ¿, find function named by ¿ and call it.
  Stack: (result of ¿)

It is simple in principle, but this only covers vaguely how it would work at run-time. Making the necessary changes to load-time pre-processing would probably be more difficult (but not necessarily more difficult than splitting the expression into two lines).


However, what I had in mind was something significantly more powerful and complicated: allow text substitution within the expression itself. For instance, where x evaluates to "a,b,c", the following would pass variables a, b and c as parameters to function F:
After thinking of various ways it could be done, I decided that it would be best to not support this syntax, but something more conventional instead: Eval().
Code like this has been written in the past, using the now-defunct __expr from LowLevel.

I vote for Eval().

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

How are we supposed to ever work with binary values? What if you use binary fileread into object.member, how do we access the value. Object.member walks and quacks like a variable everywhere else, unless it is explicitly initialized as an object separately. Please reconsider supporting binary values in object.members atleast to the same extent as official ahk.
Eval() would be fantastic!

Go ahead and try.
Except for OutputVars, ByRef parameters, traditional assignment operator, condensed assignment operators (+= .= etc.), (lack of) naming restrictions, use in %traditional% or double%deref% syntax ... Did I leave anything out? x.y and x.y:=z are only syntax sugar for internal functions ObjGet() and ObjSet().
I'm not sure what you mean. Storing an object in an object.member is hardly different from storing an object in a variable.
I originally supported _GetAddress and _Get/SetCapacity on "string" fields of objects, but removed them to simplify as they offered very little over storing a pointer in the field. In hindsight, I suppose there are some advantages:

• Allocating memory is more concise and less prone to error.
  
  Code:
  obj._SetCapacity("data", 1024)
  ;vs
  obj.ptr := DllCall("GlobalAlloc", "uint", 0, "uint", 1024)
  
• No need to define a __Delete handler for each object type (unless the binary data contains pointers to other "unmanaged" binary data) as fields are already freed on release of the object.
• Also no need to specify each field that needs to be cleaned up, which makes it more maintainable.
• Data size is easier to get:
  
  Code:
  size := obj._GetCapacity("data")
  ;vs
  size := DllCall("GlobalSize", "uint", obj.ptr)
  

...and disadvantages:

• Retrieving the pointer is less concise. (I suppose this adds up if the pointer is retrieved more often than assigned/allocated/resized.)
  
  Code:
  ptr := obj._GetAddress("data")
  ;vs
  ptr := obj.ptr
  
• obj.data won't return anything useful (unless the binary data has an initial string component).

However, this could all be implemented generically in script (for reuse by other scripts), including letting obj.data return the pointer via __Get. This script implementation could have additional functionality, which would perhaps be too rarely used to build in.

Why wouldn't you just use ptr, instead of retrieving it with _GetAddress over and over again? or you could just do this once:
I request you bring back the 3 functions.
Thanks.