 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
corrupt
Joined: 29 Dec 2004
Posts: 2485
|
 Posted: Wed Mar 15, 2006 4:55 am Post subject: |
 |
|
Updated to version 1.06  (code in first post)
- Removed the need to include InsertInteger and ExtractInteger functions
- Output returned as Return value only
- Read buffer handling changed to handle string termination
- Added cmdstub.exe to the .zip file to support 16 bit applications
Edit: updated download (first post)
Last edited by corrupt on Wed Mar 15, 2006 6:47 am; edited 2 times in total |
|
| Back to top |
|
 |
corrupt
Joined: 29 Dec 2004
Posts: 2485
|
| Posted: Wed Mar 15, 2006 5:15 am Post subject: |
|
|
Stress test script for version 1.06
| Code: | CommandIn := comspec " /c set"
testlen := StrLen(CMDret_RunReturn(CommandIn))
Loop, 100 {
IF (StrLen(CMDret_RunReturn(CommandIn)) <> testlen)
MsgBox, Output error during loop %A_Index%
}
MsgBox, Test Complete
MsgBox, 48, CMDret test - 1.06 beta - Return value output, % CMDret_RunReturn(CommandIn)
Return |
|
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2485
|
| Posted: Wed Mar 15, 2006 6:37 am Post subject: |
|
|
From doing a bit of testing it seems that there is an issue with trying to retrieve output from 16 bit applications. I have added cmdstub.exe to the download as a temporary solution (same method used with the .dll file) but it still seems to give an error:
| Quote: | ---------------------------
16 bit MS-DOS Subsystem
---------------------------
NTVDM has encountered a System Error
The handle is invalid.
Choose 'Close' to terminate the application.
---------------------------
Close Ignore
--------------------------- |
Output is displayed ok if Ignore is selected... Here's the test script: | Code: | | MsgBox, 48, CMDret test - 1.06 beta - Return value output, % CMDret_RunReturn("cmdstub command.com /c set") |
|
|
| Back to top |
|
|
shimanov
Joined: 25 Sep 2005
Posts: 610
|
| Posted: Wed Mar 15, 2006 7:31 am Post subject: |
|
|
| corrupt wrote: | | it seems that there is an issue with trying to retrieve output from 16 bit applications |
Try this :
| Code: | | CommandIn = cmd /c command /c set |
|
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2485
|
| Posted: Wed Mar 15, 2006 7:39 am Post subject: |
|
|
| Thanks for the workaround . It wouldn't work on Win9.x systems though... |
|
| Back to top |
|
|
shimanov
Joined: 25 Sep 2005
Posts: 610
|
| Posted: Wed Mar 15, 2006 7:42 am Post subject: |
|
|
| corrupt wrote: | | Thanks for the workaround . |
Sure.
| Quote: | | It wouldn't work on Win9.x systems though... |
Unfortunately, at the moment, I only have access to Windows XP. |
|
| Back to top |
|
|
toralf
Joined: 31 Jan 2005
Posts: 3910
Location: Bremen, Germany
|
| Posted: Wed Mar 15, 2006 11:15 am Post subject: |
|
|
| corrupt wrote: | Updated to version 1.06 :)
- Removed the need to include InsertInteger and ExtractInteger functions
- Output returned as Return value only
|
Thanks for the update. And thanks for changing the retrun value.
Is there a reason you removed the InsertInteger and ExtractInteger functions? Speed? Flexibility?
It seams to me that it complicates the code more then it helps reading it? I would prefer to have the functions used, since they encapsulate a special purpose/code and give it a specific name, so I do not have try to understand again the code i'm reading. And since several of my scripts already contain the InsertInteger and ExtractInteger functions it doesn't make them larger. But this is of cause personal taste.
_________________
Ciao
toralf  |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4710
Location: Boulder, CO
|
| Posted: Wed Mar 15, 2006 4:41 pm Post subject: |
|
|
Version 1.06 still works as it is, but:
- without SetBatchLines -1
- with Sleep 0 instead of Sleep 20
I get an error after 640 iterations, and 20 more thereafter, with my stress script | Code: | Loop 1000
{
If StrLen(CMDret_RunReturn("cmd /c set")) < 100
MsgBox ERROR
If StrLen(CMDret_RunReturn("cmd /c dir c:\")) < 100
MsgBox ERROR
TrayTip,,%A_Index%
} |
It just shows that the shortened version is the same. It is a very rare scenario, that someone runs RunReturn thousands of time in rapid successions, but there could be some basic problem behind, which disappears with longer Sleep. (I know, sleep deprivation can be unhealthy  .) |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2485
|
| Posted: Thu Mar 16, 2006 12:54 am Post subject: |
|
|
| toralf wrote: | | Thanks for the update. And thanks for changing the retrun value. |
It does seem to simplify things and allow more flexibility. Thanks for the suggestion .
| toralf wrote: | Is there a reason you removed the InsertInteger and ExtractInteger functions? Speed? Flexibility?
It seams to me that it complicates the code more then it helps reading it? I would prefer to have the functions used, since they encapsulate a special purpose/code and give it a specific name, so I do not have try to understand again the code i'm reading. And since several of my scripts already contain the InsertInteger and ExtractInteger functions it doesn't make them larger. But this is of cause personal taste. |
I've combined the functionality into the function for simplicity, a current lack of an include directory, many people do not regularily Include these functions (or want to have to include extras to get things working) and to have the possibility of simplifying the code a bit further (example: by filling values for multiple sections at the same time instead of having to call the function and loop multiple times for each call). At first I had thought that the code would look a lot more cryptic but honestly it doesn't look any worse than the Insert/Extract Integer function calls to me. A comment could be added at the end of each line (or on the line before if you prefer) for clarity but didn't seem necessary since these values are not adjusted throughout the code. It's probably more a matter of taste. I have a separate file that I use that lists the names, values & offsets that I refer to if I need to make a change or check a value. Do you find that the RtlFillMemory lines look any more confusing than the to the InsertInteger lines? They both contain the same info...
Last edited by corrupt on Thu Mar 16, 2006 1:37 am; edited 1 time in total |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2485
|
| Posted: Thu Mar 16, 2006 1:25 am Post subject: |
|
|
Laszlo, do your test results show a few characters more or less on the iterations that don't match or do you find that some have no output or some other result?
After stressing my PC a bit more and then running longer stress tests a few times, I was finding that I might get a difference of one character after around 600 - 800 times through the test (average). I wasn't able to reproduce having no output though. I'm wondering if the difference may still have to do with a bug in the way the string is stored related to the handling (or mishandling) of string termination. Does this seem like it may be the same on your system?
When doing a bit of testing with your code, I had found that the main difference in the testing was noted after replacing the IfEqual lines with If > 0 style tests and removing the use of continue. The problem seemed to disappear and then behave closer to the code I put together. I'm guessing this has to do with the timing in the read loop. My guess is that your code wouldn't have used a Sleep if the pipe didn't contain data (went back up to the start of the loop after continue - previous version I think, unless I changed it that way accidentally in testing...) and would therefore probably read smaller chunks more often. If there is an issue with dealing with string termination it would likely show up more after reading multiple times as data would be added to the result more times.
It sounds like we may have to add many more test points within the loop to try and determine where and when things are going wrong (if you haven't already). We could then compare the number of bytes in the pipe to how many we actually receive compared to how much larger the resulting string is after compared to before, does the read fail sometimes when the peek said there was data, did the process fail to start if the result was blank, if the result was blank, was there data received during that call, etc, etc... |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4710
Location: Boulder, CO
|
| Posted: Thu Mar 16, 2006 5:33 pm Post subject: |
|
|
| corrupt wrote: | | ...some have no output |
Yes, some return values are empty. I did not check for the correctness of the result, though in version 1.06 you have a Space between pieces of output patched together. Normally, there is only one piece, and the leading Space is ignored, so there is no problem. However, if you want to be exact, AutoTrim should be turned off, and you get an extra leading Space. (The directory listing normally starts with a Space.)
| corrupt wrote: | | I wasn't able to reproduce having no output |
I tried on 3 XP PC's, and Shimanov saw the disapearing output also on his XP machine. If you never see empty results, it must be an XP issue. But, in any case, it is timing related. With 50ms Sleep it never happened to me.
| corrupt wrote: | | replacing the IfEqual lines with If > 0 style tests and removing the use of continue |
These insert extra lines of code, which makes your script slightly slower, imitating a short Sleep. However, your unchanged code (only the Sleep is removed) behaves the same on my PC.
When the error occurs, the cmdretPID process does not exist and bSize = 0, which is the only exit from the loop. I wonder, maybe sometimes it takes longer to register the process as running, or it does not start at all. |
|
| Back to top |
|
|
shimanov
Joined: 25 Sep 2005
Posts: 610
|
| Posted: Thu Mar 16, 2006 5:58 pm Post subject: |
|
|
| Laszlo wrote: | | Shimanov saw the disapearing output also on his XP machine |
I have only observed this problem with your original code after removing the Sleep command.
On the other hand, the "robust method" in an earlier post works with, or without, the Sleep command; however, it is best to leave the Sleep command in place, to ensure the best overall performance. This is because the interprocess communication depends heavily on other system processes and the child process -- it doesn't help to starve dependencies for processor time.
| Laszlo wrote: | | empty results |
This can be explained with my original conjecture:
| shimanov wrote: | | The most likely source of failure occurs when the child process terminates, but the final [buffered] write operation has not been completed. |
Uncoordinated polling methods result in the observed failure. |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4710
Location: Boulder, CO
|
| Posted: Thu Mar 16, 2006 7:00 pm Post subject: |
|
|
| If someone likes to experiment, I posted a shorthand version of 1.06, with variable Sleep times in the first page of the thread. |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2485
|
| Posted: Fri Mar 17, 2006 10:07 am Post subject: |
|
|
Updated code in first post to Version 1.07 beta
- Fixed string termination bug
- Fixed lack of output after multiple calls (hopefully...)
This version seems to test ok here so far... (no difference in output after multiple runs, ouput seems correct) |
|
| Back to top |
|
|
toralf
Joined: 31 Jan 2005
Posts: 3910
Location: Bremen, Germany
|
| Posted: Fri Mar 17, 2006 10:22 am Post subject: |
|
|
Hi corrupt,
Could you please explain, why you use DllCall("Sleep", Int, 10)?
Is it different then "Sleep, 10"?
I guess you set "CMcpy = a" as a temporary content, right? So that the var isn't empty. It will be overwritten anyway, right?
_________________
Ciao
toralf |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
