AutoHotkey Community

It is currently May 27th, 2012, 1:18 pm

All times are UTC [ DST ]




Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 1036 posts ]  Go to page Previous  1 ... 45, 46, 47, 48, 49, 50, 51 ... 70  Next
Author Message
 Post subject:
PostPosted: August 8th, 2010, 3:49 pm 
Online
User avatar

Joined: May 5th, 2007, 7:24 pm
Posts: 1240
Location: Seville, Spain
Ok, the removal of the ANSI 64-bit build seems reasonable now, why port a legacy version of an app to a new platform?

I forgot to point out: A_Is64bitOS was removed during the merge, it's a BIV that contains 1 if the script is run under a 64-bit OS regardless of the AutoHotkey build.

Also, you forgot to bump the revision number in the .chm file & add the changelog.

PD:
Documentation wrote:
and 8 bytes in 64-bit builds.
There's just one 64-bit build ;p

EDIT: RegisterCallback() broken:
New code:
Code:
   ; Set parameters for the upcoming function call
   mov rcx, rsp ; UINT_PTR* aParams - WROONG, now points to return address instead!!
   mov rdx, rax ; RCCallbackFunc* cbAddress

_________________
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]


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 8th, 2010, 11:10 pm 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia
fincs wrote:
I forgot to point out: A_Is64bitOS was removed during the merge,
No, I merged before you added it. I saw it was added, but felt it wasn't worth implementing.
Code:
MsgBox % Is64bitOS()
Is64bitOS() {
    return (A_PtrSize=8)
    || DllCall("IsWow64Process", "ptr", DllCall("GetCurrentProcess"), "int*", isWow64)
    && isWow64
}

Quote:
Also, you forgot to bump the revision number in the .chm file & add the changelog.
My release script does all that, but after it rebuilds the .chm file and installer (oops). [Edit: Hmm, it rebuilds the help file and installer last before uploading. I wonder what went wrong? It wasn't updating the version number in the installer, but the help file should've been up-to-date.]
Quote:
There's just one 64-bit build ;p
...until I rebuild, then there's two, then three, etc.
Quote:
EDIT: RegisterCallback() broken:
Thanks. I should've known there was a reason for that 'add'.
Quote:
New code:
Hardly. You missed the actual fix. :P

I've pushed out the RegisterCallback fix, which also updated the help file and installer (though this fix isn't in the changelog). Thanks.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 9th, 2010, 10:33 am 
Online
User avatar

Joined: May 5th, 2007, 7:24 pm
Posts: 1240
Location: Seville, Spain
Lexikos wrote:
Hardly. You missed the actual fix. :P

"New code" as in code that was merged into AutoHotkey_L. Plus, it's still broken:
Code:
; For the 'mov' further below.
add rsp, 4 ; should be 8

The "1 vs 0 to skip over the return address" comment is no longer needed and "padding+spill area" should be "retaddr+padding+spill area"

_________________
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]


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 9th, 2010, 7:14 pm 
Offline
User avatar

Joined: May 24th, 2009, 5:35 am
Posts: 2099
Location: Iowa, USA
Lexikos wrote:
Merged AutoHotkey64 - COM support and x64 compatibility.
:D Just noticed this - thank you sir. Thank you to Sean & fincs as well.

_________________
Image
Recommended: AutoHotkey_L
Basic Webpage Controls


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 9th, 2010, 9:34 pm 
Offline

Joined: July 30th, 2007, 11:32 pm
Posts: 581
Awesome work Sean and fincs! Not sure what I could do with the x64 build that I couldn't do before, but it's a welcome addition!

Lexikos wrote:
In addition to the new features, I've spent some time better integrating AHKL documentation

Looks good! :D

Are you also going to make an installer for the 64-bit build?


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 10th, 2010, 2:25 am 
Offline

Joined: July 30th, 2007, 11:32 pm
Posts: 581
The link to Variables.htm#PtrSize from the Script Compatibility page is broken. :wink:

Edit - Other questions:
1) Why is cdecl ignored in the x64 build? Does this mean that functions that required cdecl can no longer be called?
2) Is there a performance cost incurred in looking up the value of A_PtrSize. For example, is it worth it to do:
Code:
iStructSize := 4 + A_PtrSize
[... Multiple uses of iStructSize ...]


Edit2:

3) Using the Tab/Tab2 control instantly crashes AHK_L x64:
Code:
Gui, Add, Tab2,, First Tab|Second Tab

It does not happen with x86.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 10th, 2010, 9:57 am 
Online
User avatar

Joined: May 5th, 2007, 7:24 pm
Posts: 1240
Location: Seville, Spain
TheGood wrote:
1) Why is cdecl ignored in the x64 build? Does this mean that functions that required cdecl can no longer be called?
2) Is there a performance cost incurred in looking up the value of A_PtrSize.


1) There's just one (read: 1) calling convention in x64.
2) No, it's as fast as true/false. Same for A_IsUnicode.

_________________
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]


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 10th, 2010, 10:14 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia
TheGood wrote:
Are you also going to make an installer for the 64-bit build?
I'm a bit reluctant to do that since compiling x64-based scripts isn't possible yet. We need to replace the library which is used to embed the script into the exe file.
Quote:
The link ... is broken.
Thanks for reporting it.
Quote:
1) Why is cdecl ignored in the x64 build?
x64 uses fastcall. See Overview of x64 Calling Conventions.
Quote:
Using the Tab/Tab2 control instantly crashes AHK_L x64:
Thanks, I'll look into it.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 10th, 2010, 4:30 pm 
Offline

Joined: March 28th, 2010, 9:02 pm
Posts: 39
Hey, your AHK modification is pure awesome. I just did a modal_vim.ahk port to AHK_L, and it really simplifies the script. You can check it out here:

http://www.autohotkey.com/forum/viewtop ... 231#375231


Report this post
Top
 Profile  
Reply with quote  
 Post subject: fileappend memory leak ?
PostPosted: August 11th, 2010, 12:57 am 
Offline

Joined: August 3rd, 2007, 8:01 am
Posts: 555
Location: Houston, TX
AutoHotkey_L seems to leak more memory compared to official AutoHotkey in fileappend.
FileObject.write(string) works without leaking...
test script:
Code:
loop, 100
s .= "bla "
msgbox begin  ; memory usage according to task manager: ahk: 6044k, ahkl: 6264k
loop, 1000
{
   fileappend, %s%, temp.txt
if (mod(A_Index, 100) == 0)
   tooltip, %A_Index%
}

msgbox written ; memory usage according to task manager:  ahk: 6160k , ahkl: 6896k
return


Report this post
Top
 Profile  
Reply with quote  
PostPosted: August 11th, 2010, 1:15 pm 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia
tinku99 wrote:
AutoHotkey_L seems to leak more memory compared to official AutoHotkey in fileappend.
Thanks. I've found the problem -- the TextStream constructor does mLocale = _create_locale(LC_ALL, ".0"). mLocale is used with _ismbblead_l to support multi-byte characters. However, _create_locale is failing and returning NULL. After a bit of debugging, I found that it doesn't accept 0, CP_UTF7 or CP_UTF8. The following can be found in <Visual Studio dir>\VC\crt\src\getqloc.c (on my system at least):
Code:
    //  verify codepage validity
    if (!iCodePage || iCodePage == CP_UTF7 || iCodePage == CP_UTF8 ||
        !IsValidCodePage((WORD)iCodePage))
        return FALSE;
So to get a valid _locale_t, we'll need to check for cp == CP_ACP and pass GetACP() instead. That's fair enough, but I had to ask myself "How is it leaking memory??". When the code above returns FALSE, _setlocale_nolock returns NULL to _create_locale, which is in setlocal.c:
Code:
    if ((retval->mbcinfo = _calloc_crt(sizeof(threadmbcinfo), 1)) == NULL)
    {
        ...
    }
    _copytlocinfo_nolock(retval->locinfo, &__initiallocinfo);

    if (_setlocale_nolock(retval->locinfo, _category, _locale) == NULL)
    {
        __removelocaleref(retval->locinfo);
        __freetlocinfo(retval->locinfo);

        _free_crt(retval);
        retval = NULL;
    }
The problem here is that it doesn't free retval->mbcinfo, and there's no way for us to do so. Instead we'll need to duplicate the "codepage validity" checks above, avoiding _create_locale in those cases. I searched around a little while for any other references to this problem or somewhere to report the issue to MS, but gave up without finding anything.


I presume when you tested File.Write(), you weren't recreating the object repeatedly. This code exhibits the same memory leak, which makes sense in light of the issue I explained above:
Code:
Loop 100000
    FileOpen(A_ScriptFullPath, 0)
Btw, I found that the following was sufficient for duplicating the problem without actually writing to any file:
Code:
Loop 100000
    FileAppend, 0, nul

Downloads updated; see here for changes.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 11th, 2010, 1:58 pm 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia
In the process of updating the downloads, I pushed out some changes to FileObject that I hadn't intended to release yet as I'm planning to make further changes to both FileObject and FileOpen. The following has been done already:
  • File.Length, File.AtEOF, File.Close and File.__Handle no longer require ().
  • File.Length := newLength is equivalent to File.Length(newLength).
  • File.Pos and File.Position are equivalent to File.Tell().
  • File.Seek(n) seeks relative to the end of the file if the second parameter is omitted and n is negative.
  • File[varContainingMethodName]() is supported.
(The old syntax is also supported.)

Additionally, I intend to add the following:
  • File.Pos := n as an alternative to File.Seek(n).
  • File.Read(Type) and File.Write(Num, Type) or File.ReadType() and File.WriteType(Num), where Type is a NumGet-compatible type name.
For FileOpen, I think that the numeric flags are not user-friendly enough -- even C's fopen accepts a human-readable string. Unless there are better suggestions, my current plan is to interpret non-numeric Flags as follows:
Code:
/*
r       read
w       write
a or +  append  <-- maybe not both; anyone have a preference?
`n      translate between `r`n and `n, equivalent to 0x04 flag
`r      replace `r with `n when reading, equivalent to 0x08 flag
-rwd    lock file for read, write and/or delete access
-       equivalent to -rwd
*/
; Open for appending, lock write/delete but not read:
file := FileOpen(filename, "a-wd")
; Open for reading, don't lock the file.
file := FileOpen(filename, "r")
I think the default should be to not lock the file, partly because (iirc) AutoHotkey uses fopen, which doesn't lock files, but also because it seems more flexible and "-" seems more intuitive than "+" as a "file locking" or "share-mode" flag. rw would either be equivalent to 0x03 (update), or (my preference:) could create the file if it doesn't exist.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 11th, 2010, 3:16 pm 
Offline

Joined: January 8th, 2007, 1:14 pm
Posts: 83
Hey.

I noticed that concatenation does not appear to work as expected.

Code:
obj := Object()
obj["a"] := "this is"
obj["a"] .= "a test!"
; obj.a = "this is"

obj["a"] := obj["a"] . "a test!"
; obj.a = "this is a test"


I got the impression from the help that ".=" should work in the above case? Am i doing it wrong? :)

Cheers!


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: August 11th, 2010, 3:21 pm 
Offline
User avatar

Joined: May 24th, 2009, 5:35 am
Posts: 2099
Location: Iowa, USA
@Mystiq - Good question :wink: - it's already been discussed though.
Lexikos wrote:
For FileOpen, I think that the numeric flags are not user-friendly enough
+1 - I'd say "a" for append.

jethrow wrote:
I'm not sure if you want these messages in this thread or not, but I noticed a difference in performance between the COM Library to Built-In COM. The following works as expected with COM_CreateObject, but errors out with ComObjCreate:
Code:
x:=ComObjCreate("ScriptControl"), x.Language:="jScript", a:=x.Eval("a=[1,2]")

loop, % a.length {
   MsgBox, % a[A_Index-1] ; <-- Error:  0x80020006 - Unknown name.
   ; MsgBox, % a[n:=A_Index-1] ; works fine for both
   ; MsgBox, % a["" A_Index-1] ; works fine for both
}

Sean wrote:
... the function name of a COM Object should be a string basically. And I suppose that the error was produced in your example since A_Index-1 was resolved to a name of a empty string. BTW, compare it with the following which will work as you expect:
Code:
MsgBox, % a[0] . "|" . a["0"]
MsgBox, % a[1] . "|" . a["1"]

Although making it work as you want is relatively straightforward (:which I don't like to add personally), I think you better post it in AHK_L thread.

_________________
Image
Recommended: AutoHotkey_L
Basic Webpage Controls


Report this post
Top
 Profile  
Reply with quote  
PostPosted: August 11th, 2010, 8:00 pm 
Offline

Joined: August 3rd, 2007, 8:01 am
Posts: 555
Location: Houston, TX
Lexikos wrote:
tinku99 wrote:
AutoHotkey_L seems to leak more memory compared to official AutoHotkey in fileappend.
Thanks. I've found the problem ...
Downloads updated; see here for changes.
Thanks for fixing it.
Also, amazing job moving ahk forward and consolidating unicode, x64, com etc.


Report this post
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 1036 posts ]  Go to page Previous  1 ... 45, 46, 47, 48, 49, 50, 51 ... 70  Next

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 0 guests


You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group