Leaderboard

Forever it seems. It's also one of those long distance things. We are still hoping that science will allow him to have my babies ... can you just imagine how cute they would be ... a bit of him a bit of me. And we intend to do that, without ever physically meeting one another. We are destined to be forever apart, especially thanks to COVID ... and it is better that way anyway, as I would have to reject him on the grounds he is male, and I ain't Gay. Currently though, I can pretend he is some exotic Indian Princess ... such is the beauty of our digital connection. P.S. However rosie things might seem, we still cannot get over the fact he doesn't laugh at my jokes, especially the constipated accountant pencil one, and for me, that's a deal-breaker.

@TheSaint & @TheDcoder: so how long have you two been married now?

Hello. So for some time now, I've been thinking about the possibilities with a package manager for AutoIt, like npm for UDF's and such. I am curious if anyone else would be interested in such a thing, or if it would be useless/problematic in practice? My personal problem with the idea so far, is the hurdle of legality and hosting options. Your thought(s) on this matter would be greatly appreciated. Edit: Package repo web page: https://au3pm.github.io/ Docs: https://genius257.github.io/au3pm/ Project: https://github.com/genius257/au3pm/ Latest release: https://github.com/genius257/au3pm/releases/tag/0.3.1 Download link: https://github.com/genius257/au3pm/releases/download/0.3.1/au3pm.exe

Check-If-Same is a little program, with a big heart (window), that I have been working on since the end of August. It's a somewhat simple affair, and one of the many file checkers out there, but I have put my own slant on it. The screenshot probably says it all. It was built to purpose for me, and you can see the MD5 stuff as an added extra. It has been suggested by my good buddy TheDcoder, that I should also add CRC32 checking, which I may do at some point. However, I just wanted a simple folder content comparison, where I was more interested in file names being matched, not the state of the files ... they having had their integrity checked already by TeraCopy. Files only appear on either list, if they are missing in the other folder or they fail the chosen compare test. If desired, missing files can be skipped (File Name option excepted). 'Source Size' and 'Compare Size' can alternatively be 'Source Date' and 'Compare Date', as specified by the Bytes combo field. Anyway, for what its worth, enjoy! Some of you might find it handy. Source is included in the zip. Check-If-Same v1.1.zip 589.41 kB (111 downloads) Check-If-Same v1.2.zip NEW You have two methods of MD5 checking, one is the AutoIt Crypt hash checking, the other is using third party FSUM. In my limited number of tests, I found the crypt method was faster with small files and FSUM much faster with big files, so take your pick. If you are keen to see timing comparisons, then with the individual MD5 button option, the times are stored in the 'Settings.ini' file for the entry you selected (see the [MD5 Test] section).

Here is a small application made for my own need. It allows you to follow the tail of a log file (or other txt file) in real time. To avoid some memory issues, it loads about 10MB from the end of the file, so you can follow your huge log files in real-time with it. Here is the code : #include <FileConstants.au3> #include <GUIConstantsEx.au3> #include <GuiEdit.au3> #include <StaticConstants.au3> #include <WindowsConstants.au3> Global $sAppTitle = "RT-LogFileViewer" Global $iSizeToLoad = 10 * 1024 * 1024 Global $iBlockSize = 1024, $iPause = False Global $sLastDirectory = RegRead("HKEY_CURRENT_USER\Software\" & $sAppTitle, "LastDirectory") Global $iFileChange = 0, $sFileDate, $sLogFile, $iFileSize, $hGui Global $idEdit, $idPause, $idSearch, $idFileName, $idProgress If Not StringLen($sLastDirectory) Or Not FileExists($sLastDirectory) Then $sLastDirectory = @MyDocumentsDir Opt("GUIOnEventMode", 1) Opt("MustDeclareVars", 1) _LoadGui() If $CmdLine[0] Then _FileOpen($CmdLine[1]) ProcessWaitClose(@AutoItPID) Func _LoadGui() Local $idOpen, $idAbout $hGui = GUICreate($sAppTitle, 800, 600, -1, -1, BitOR($WS_SYSMENU, $WS_SIZEBOX, $WS_MINIMIZEBOX, $WS_MAXIMIZEBOX) ) $idEdit = GUICtrlCreateEdit("" , 10 , 50 , 780, 490, BitOr($ES_READONLY, $ES_AUTOVSCROLL, $WS_VSCROLL, $WS_HSCROLL, $ES_NOHIDESEL)) $idOpen = GUICtrlCreateButton(ChrW(0x2f) , 10 , 10 , 30 , 30) $idPause = GUICtrlCreateButton(ChrW(0x3b) , 760, 10 , 30 , 30) $idSearch = GUICtrlCreateButton(ChrW(0x2315), 720, 10 , 30 , 30) $idFileName = GUICtrlCreateLabel ("" , 10 , 550, 680, 25) $idAbout = GUICtrlCreateLabel ("About" , 690, 550, 100, 25, $SS_RIGHT) $idProgress = GUICtrlCreateProgress(10, 540, 780, 5) Local $aAccelKeys = [["^o", $idOpen], ["^p", $idPause], ["^f", $idSearch]] GUICtrlSetFont($idOpen , 12, 400, 0, "Wingdings 2") GUICtrlSetFont($idPause , 12, 400, 0, "Webdings") GUICtrlSetFont($idSearch , 19, 800, 0, "Arial") GUICtrlSetFont($idEdit , 10, 400, 0, "Courier") GUICtrlSetFont($idFileName, 9 , 400, 0, "Verdana") GUICtrlSetFont($idAbout , 9 , 400, 4, "Verdana") GUICtrlSetTip($idOpen , "Open file (CTRL + O)") GUICtrlSetTip($idSearch, "Search... (CTRL + F)") GUICtrlSetTip($idPause , "Pause monitoring (CTRL + P)") GUICtrlSendMsg($idEdit, $EM_LIMITTEXT, -1, 0) GUICtrlSetColor($idAbout, 0x0000ff) GUISetOnEvent ($GUI_EVENT_CLOSE, "_Exit") GUICtrlSetOnEvent($idPause , "_Pause") GUICtrlSetOnEvent($idSearch , "_Search") GUICtrlSetOnEvent($idOpen , "_FileOpenGUI") GUICtrlSetOnEvent($idAbout , "_About") GUICtrlSetResizing($idOpen, $GUI_DOCKALL) GUICtrlSetResizing($idPause, $GUI_DOCKRIGHT + $GUI_DOCKTOP + $GUI_DOCKSIZE) GUICtrlSetResizing($idSearch, $GUI_DOCKRIGHT + $GUI_DOCKTOP + $GUI_DOCKSIZE) GUICtrlSetResizing($idEdit, $GUI_DOCKLEFT + $GUI_DOCKRIGHT + $GUI_DOCKTOP + $GUI_DOCKBOTTOM) GUICtrlSetResizing($idFileName, $GUI_DOCKLEFT + $GUI_DOCKRIGHT + $GUI_DOCKBOTTOM + $GUI_DOCKHEIGHT) GUICtrlSetResizing($idAbout, $GUI_DOCKRIGHT + $GUI_DOCKBOTTOM + $GUI_DOCKSIZE) GUICtrlSetResizing($idProgress, $GUI_DOCKLEFT + $GUI_DOCKRIGHT + $GUI_DOCKBOTTOM + $GUI_DOCKHEIGHT) GUICtrlSetState($idSearch, $GUI_DISABLE) GUICtrlSetState($idPause, $GUI_DISABLE) GUICtrlSetState($idProgress, $GUI_HIDE) GUISetAccelerators($aAccelKeys, $hGui) GUISetIcon(@SystemDir & "\SHELL32.dll", -25) GUISetState(@SW_SHOW) EndFunc Func _LoadTail($sLogFile) Local $sLines, $iPercent $iFileSize = FileGetSize($sLogFile) Local $hFile = FileOpen($sLogFile, $FO_READ) If @error Then Return 0 $sFileDate = FileGetTime($sLogFile, 0, 1) Local $iStartPos =($iSizeToLoad > $iFileSize ? 0 : $iFileSize - $iSizeToLoad) GUICtrlSetData($idProgress, 0) GUICtrlSetState($idProgress, $GUI_SHOW) For $i = $iStartPos To $iFileSize - $iBlockSize Step $iBlockSize $iPercent = Int( $i * 100 / $iFileSize) GUICtrlSetData($idProgress, $iPercent) FileSetPos($hFile, $i, 0) $sLines &= FileRead($hFile, $iBlockSize) If $i = $iStartPos Then $sLines = StringRegExpReplace($sLines, "^\V*\R", "", 1) Next $sLines &= FileRead($hFile) GUICtrlSetData($idProgress, 100) Sleep(100) GUICtrlSetState($idProgress, $GUI_HIDE) _GUICtrlEdit_AppendText($idEdit, $sLines) FileClose($hFile) Return 1 EndFunc Func _Search() _GUICtrlEdit_Find($idEdit) EndFunc Func _FileOpenGUI() _FileOpen() EndFunc Func _FileOpen($sFileToOpen = "") If Not FileExists($sFileToOpen) Then $sFileToOpen = FileOpenDialog("Select a file", $sLastDirectory, "Log File (*.log)|All (*.*)", 1, "", $hGui) If @error Then Return If $sFileToOpen = $sLogFile Then If not $iFileChange Then Return $iFileChange = 0 EndIf GUICtrlSetData($idEdit, "") GUICtrlSetState($idPause, $GUI_ENABLE) If Not $iPause Then _Pause() If _LoadTail($sFileToOpen) Then $sLogFile = $sFileToOpen GUICtrlSetData($idFileName, $sLogFile) $sLastDirectory = StringRegExpReplace($sLogFile, "\\[^\\]+$", "") RegWrite("HKEY_CURRENT_USER\Software\" & $sAppTitle, "LastDirectory", "REG_SZ", $sLastDirectory) Else MsgBox(16, $sAppTitle & " - Error", "Unable to load the specified file.") EndIf _Pause() EndFunc Func _Refresh() Local $sLines, $hFile Local $iNewSize = FileGetSize($sLogFile) Local $sNewFileDate = FileGetTime($sLogFile, 0, 1) If $sNewFileDate = $sFileDate Then Return $sFileDate = $sNewFileDate If $iNewSize > $iFileSize Then $hFile = FileOpen($sLogFile, $FO_READ) FileSetPos($hFile, $iFileSize, 0) $sLines = FileRead($hFile, $iNewSize - $iFileSize) FileClose($hFile) $iFileSize = $iNewSize _GUICtrlEdit_AppendText($idEdit, $sLines) Else $iFileChange = 1 _FileOpen($sLogFile) Return EndIf EndFunc Func _Pause() $iPause = Not $iPause If $iPause Then GUICtrlSetData($idPause, ChrW(0x34)) GUICtrlSetState($idSearch, $GUI_ENABLE) AdlibUnRegister("_Refresh") Else GUICtrlSetData($idPause, ChrW(0x3b)) GUICtrlSetState($idSearch, $GUI_DISABLE) AdlibRegister("_Refresh") EndIf EndFunc Func _About() Local $sAboutText = $sAppTitle & " is a real-time log file viewer. It allows you to monitor huge files by showing you the end of the file (not the whole file)." & @CRLF & _ "Thanks to use it !" & @CRLF & @CRLF & _ "Made with AutoIt version " & @AutoItVersion & " by JGUINCH." MsgBox(0, $sAppTitle, $sAboutText, 0, $hGui) EndFunc Func _Exit() Exit EndFunc

yes, !! , just gathered that, and have downloaded the zip, and moved all files into my include area ( region?). Thanks so much. I promise not to be too lazy.

Well bud, I believe my test is valuable because it shows which algorithm is faster, thus simpler. Note that the algorithm does not change how it works, it always functions the same, both in laboratory and in the real world. Thanks, I knew you would see the merit in my suggestion. This discussion was started because I was a bit "bamboozled" by your benchmark, however now I understand why. It is indeed outside the box, good one. But it may not be much of a help... and it might make things worse as well. Yeah, all thanks to the "warm-up" phenomenon, this happens in almost all benchmarks, the first test is usually performs worse compared to when it is done in the middle. Not so fast, here is a real test with my real Seagate 5400RPM SATA disk: TheDcoder@arch /m/d/D/W/Windows 10> stat -c %b Win10_1909_EnglishInternational_x64.iso 10594256 TheDcoder@arch /m/d/D/W/Windows 10> time rhash --crc32 Win10_1909_EnglishInternational_x64.iso ; Generated by RHash v1.4.0 on 2020-09-07 at 15:32.28 ; Written by Kravchenko Aleksey (Akademgorodok) - http://rhash.sf.net/ ; ; 5424252928 17:49.07 2020-01-13 Win10_1909_EnglishInternational_x64.iso Win10_1909_EnglishInternational_x64.iso 6B7B6CB5 ________________________________________________________ Executed in 42.95 secs fish external usr time 3.42 secs 267.00 micros 3.42 secs sys time 1.49 secs 108.00 micros 1.49 secs TheDcoder@arch /m/d/D/W/Windows 10> time rhash --md5 Win10_1909_EnglishInternational_x64.iso d1f08aea37586702f6fbe2fe3ea8c3fd Win10_1909_EnglishInternational_x64.iso ________________________________________________________ Executed in 44.20 secs fish external usr time 8.33 secs 195.00 micros 8.33 secs sys time 1.73 secs 77.00 micros 1.73 secs TheDcoder@arch /m/d/D/W/Windows 10> time rhash --sha1 Win10_1909_EnglishInternational_x64.iso 31549049b73cef72456af0bff71f494e76e1f506 Win10_1909_EnglishInternational_x64.iso ________________________________________________________ Executed in 46.09 secs fish external usr time 6.01 secs 377.00 micros 6.01 secs sys time 1.84 secs 152.00 micros 1.84 secs TheDcoder@arch /m/d/D/W/Windows 10> time rhash --sha256 Win10_1909_EnglishInternational_x64.iso b7a4a0786ea9ed51ac7874490885400f9cf3bbc71ab3dad468282da25147a29e Win10_1909_EnglishInternational_x64.iso ________________________________________________________ Executed in 45.17 secs fish external usr time 12.78 secs 0.00 micros 12.78 secs sys time 1.84 secs 464.00 micros 1.84 secs And it looks like my disk is being the bottleneck, even the SHA1 and SHA256 cryptographic algorithms take the same amount of time as CRC and MD5. Perhaps my processor is too fast In fact, if you observe closely, SHA1 was one second slower than SHA256... and SHA1 is not even secure anymore. So really, we can't find out the ideal hashing algorithm if we use real world tests like these, because there will be hidden bottlenecks. In the end, all I want to say is that CRC32 is best because it was designed for the purpose of checking differences in files, as opposed to the other cryptographic algorithms, which are designed to test the integrity of the file, thus they will be slower. I rest my case

While 1 ;to loop $win_text = WinGetText("Alert") If StringInStr($win_text, "up") Then ;to search if the alert window has "up" msg WinActivate("Alert") Send("ENTER") ; to close the alert window MouseClick("left", 354, 237, 1, 10) ;to activate the 44189 window WinWaitActive("44189") MouseClick("left", 358, 294, 1, 10) ; coordinates for 03. Click "CLOSE ALL TRADES" ONCE MouseClick("left", 159, 314, 1, 10) ; coordinates for 04. Click twice at "GBPJPY" ONCE MouseClick("left", 74, 293, 1, 10) ; coordinates for 05. Click once "TRADE" ONCE EndIf If StringInStr($win_text, "down") Then ;to search if the alert window has the "down" msg WinActivate("Alert") Send("ENTER") ; to close the alert window MouseClick("left", 354, 237, 1, 10) ;to activate the 44189 window WinWaitActive("44189") MouseClick("left", 358, 294, 1, 10) ; coordinates for 03. Click "CLOSE ALL TRADES" ONCE MouseClick("left", 159, 314, 2, 10) ; coordinates for 04. Click twice at "GBPJPY" TWICE MouseClick("left", 74, 293, 1, 10) ; coordinates for 05. Click once "TRADE" ONCE EndIf Sleep(300) ; do tests 3x per second WEnd

@TheDcoder - Not that I need convincing, as I took you at your word, and so incorporated a CRC32 option into my program, without doing a single comparison test first. So far I haven't made any speed claims about CRC32 versus MD5, just reported on my real world result. Without definitive proof to the contrary, I believe you when you say CRC32 is faster, I accept you have the experience and knowledge to backup that claim. All that remains really, is how much under real world conditions, is CRC32 faster, and what can we maybe do to improve any conditional limitations. With that in mind, I decided to try out something, that occurred to me as I was waking today ... a kind of thinking outside the box thought. I gave my program, what I call a 'Local' option. What it does, is copy 'fsum.exe' to the root of Source and Compare drives, and use it from there, to see if that improves the checking speed. It seemed to, going by the following results, using the exact same 3.7 Gb file as before, with the same exact portable drives. New Results Previous Results Not a huge difference, but there appears to be some improvement with my Local method ... but no real change with CRC32 versus MD5. Now at this point, I don't know what variations might exist naturally anyway, so I am not claiming the Local method actually does improve things. NOTE - The copying of fsum.exe occurs before the timing begins, as with multiple files on the same drives, that would indeed be the case.

Gawd bud, it is not me going about it the wrong way, it is you. What possible value can your test be. You haven't proved anything in regard to the real world conditions, you have only done a test in RAM, which is not relevant, as it doesn't help or solve anything. You have proved what happens in RAM, and that is all, and seeing as that is not where any real world usage occurs, it is pointless. You are getting lost in a hypothetical, that is only a hypothetical, and while no doubt of interest to nerds or geeks, serves no practical purpose. It is of no comparison to the real effect of USB speed limitation, which is a real world thing. That is real, because it is where reality meets usage. As some would say, you need to take your test out of the laboratory and into the real world, where results have actual meaning beyond theoretical, where real life factors play a part, not perfect pristine conditions that just don't occur in the real world. How is your perfect test going to help us in the real world. 'The Real World' is defined by where you actually use the MD5 or CRC32 checking. And remember, it was you who suggested I should be using CRC32 in the real world instead of MD5, where I will supposedly gain a benefit. A RAM test achieves nothing in that regard, except to make you feel better ... it doesn't help or convince me. Haven't I already suggested that in my previous post, along with acknowledging where the likely bottleneck was. That is however a bottleneck that I have to put up with, unless you or I etc come up with an improvement with that real world scenario. Now I can keep repeating myself and saying things in as many different ways that I can think up, but it is clearly as pointless to do so as your RAM test, so I suggest we give up. I would much prefer we discuss something useful. I cannot see the value of your test, and you cannot understand the point I make ... let's leave it at that, because clearly, by this point, neither of us are going to be convinced by the other, and I've grown bored and tired of repeating myself, even if slightly couched differently. Let's leave our arguments in HexChat.

Use : $oPDF.PrintAllFit(True)