elektron

Okay, the new changes are committed to my GitHub. I fixed many bugs in __DROPBOX.au3, added documentation (as requested) added a tasks section, and added a list of known bugs and a whole bunch of stuff. Check it out. :-)

You're basically looking for a minimum spanning tree, right?

That sounds great, I've been debugging all day working on this script so far and I've fixed so many bugs. How should I put the bugs, should I add them as an issue in GitHub's issue tracker, or should I do something different? I'm about to make a gigantic commit here, probably today, I've fixed a lot of bugs in the script, and the commit changes will be outlined later tonight when I'm not on company time. I appreciate all the advice. I've never done group programming over the internet, so I have no idea where to begin to start "leading" a project myself... Perhaps a rename is in accord, but I want to get it working (completely) with dropbox before I even begin to guarantee it'll work with something else. There are a few bugs with __REMOVE_CHANNEL(), where it won't delete a channel completely. I don't know how to unlock it and delete it forcefully. I'll post back here when I make my commit.

Wow, that's a pretty complex example. It would be pretty difficult and time consuming to performance-tune it, from what I see, and there's a good chance that performance tuning the regexp would not yield a good performance benefit. If it were me, I'd chunk it into several small pieces and parallelize it.

I've wanted to do this a couple of times, actually, in AutoIt, but this was at the time that I was more comfortable with AutoHotKey than I was with AutoIt, so I ended up writing the solution in AutoHotKey and wrote it in AutoIt at a later time. There's a design pattern that you can use to actually intercept the hotkey, and still let the keypress go through. Here's how it works: The hotkey gets pressed, and so then the function associated with that hotkey gets called, so then what you do is you send that keypress back to the active window, from within the script. As a general rule though, you don't want to have to do that. If you're writing a hotkey for your program that triggers some action or another, you want that hotkey to be a unique one. -- Alex

Well, this is more of an exercise in parsing than anything and it's not completely infallible unless there's never been a situation where your computer wasn't able to connect to the internet, but others could. 1). Write a function that pings google, and returns true or false as appropriate. 2). Write another function that generates a timestamp. 3). Write another function that logs output to a file. 4). Write the main function, which uses steps 1 through three and does them continuously to any given resolution you desire. You're going to need to brush up on FileOpen, FileFlush, FileClose, While loops, and the Ping() function. If you take all those components and put them together, then you'll be able to figure it out from there. The desired output should be a CSV file (basically, values separated by a comma) which you can later open up in excel, you'd want the output to look something like this: (<timestamp>), <result of function in step1>) -- Alex It sounds to me like this is one of your very first AutoIt scripts, and perhaps your very first glimpse into programming itself. If that's the case, here are some tips: 1). Don't get frustrated and quit (at least not immediately). 2). If you find a particular function or procedure twisty and hard to understand as a whole, then piecemeal the task into little subtasks that you have more control over. 3). Global variables are evil, don't use them unless you have to. 4). Seek help. 5). Don't just copy and paste code without understanding what it does. I hope this helps. When you're finished with your script, come back and post back. Have fun :-) -- Alex

Check out my topic (I actually just posted this), that has a #include that you can use for a stack data structure. It'll work pretty well, and after you're done using it, you can just call a function and it will return an array for you to use.

No problem. I think your problem is you don't have quite a handle on all the features of Dropbox. In dropbox, you can create a "shared folder" and share them with other dropbox accounts. Dropbox is such a well-written piece of software... Another thing, this script was awfully misnamed. Although I created it to use dropbox and with dropbox in mind, I suppose it could work with any platform where files are hosted on a central server and can be accessed as a file. This makes it possible for scripts to communicate with one another using network shares and so forth. Now, there are a couple of things that I want you to keep in mind, there are some serious bugs in this script, and I'm working on them, but I really need someone to help me with it. If you can take a serious glance at the code, and fork your own version in GitHub and start contributing and submit a pull request, that would help with the development process a lot.

Yes. The __DROPBOX__COMM__* namespace was intended exclusively for inter-script communication. I wanted to make communication between scripts more natural, so I created this script and approached the problem a little bit differently. I have this model of a "channel" by which the scripts, (or people for that matter) can "subscribe" to. It's pretty neat. There are a few bugs in the scripts and I'm trying to resolve them here and there as I use the code, but what I really need is another set of eyes to help me work on this code -- it's gotten pretty massive. Check my GitHub profile and look for DB_CHAT.exe, you're going to use that as a "shell." Then check out this example: #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_UseUpx=n #AutoIt3Wrapper_Change2CUI=y #AutoIt3Wrapper_Res_requestedExecutionLevel=asInvoker #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** #cs ---------------------------------------------------------------------------- AutoIt Version: 3.3.8.1 Author: Alexander Alvonellos Script Function: Host script for the client running dropbox and hosting the data used for vp update. #ce ---------------------------------------------------------------------------- #include "../Include/__DROPBOX.au3" #include "../Include/__GENERAL.au3" OnAutoItExitRegister("abort") Global $DATA_HOST_DEFAULT_CHANNEL_NAME = "comm" Global $DATA_HOST_DEFAULT_CHANNEL_PATH = @ScriptDir Global $DATA_HOST_DEFAULT_LOG_FUNCTION = "cerr" main() While(True) Sleep(100) WEnd Func main() cerr("In main(), initializing...") Local $bContactResult = __DROPBOX__COMM__CREATE_CHANNEL($DATA_HOST_DEFAULT_CHANNEL_NAME, _ $DATA_HOST_DEFAULT_CHANNEL_PATH, _ $DATA_HOST_DEFAULT_LOG_FUNCTION) If( $bContactResult = True ) Then cerr("In main(), I've created the channel, " & $DATA_HOST_DEFAULT_CHANNEL_NAME & ". " & _ "No errors were detected.") Else Local $msg = "In main(), " If( @error = -1 ) Then $msg &= "there was an error creating channel directory. Attempting to resolve." __DROPBOX__TERMINATE("cerr"); $bContactResult = __DROPBOX__COMM__CREATE_CHANNEL($DATA_HOST_DEFAULT_CHANNEL_NAME, _ $DATA_HOST_DEFAULT_CHANNEL_PATH, _ $DATA_HOST_DEFAULT_LOG_FUNCTION) __DROPBOX__INITIALIZE("cerr"); If( $bContactResult = True ) Then $msg &= " Resolution successful." Else $msg &= " Resolution unsuccessful." EndIf ElseIf( @error = -2 ) Then $msg &= " error creating configuration file." ElseIf( @error = -3 ) Then $msg = "In main(), channel already exists, everything's just fine." Else $msg = "In main(), BAD MAGIC." EndIf cerr($msg) EndIf Local $bPurgeResult = __DROPBOX__COMM__PURGE($DATA_HOST_DEFAULT_CHANNEL_NAME, _ $DATA_HOST_DEFAULT_CHANNEL_PATH, _ $DATA_HOST_DEFAULT_LOG_FUNCTION) cerr("In main(), purged old datagrams from channel " & $DATA_HOST_DEFAULT_CHANNEL_NAME & ".") Local $bSubscribeResult = __DROPBOX__COMM__SUBSCRIBE($DATA_HOST_DEFAULT_CHANNEL_NAME, _ $DATA_HOST_DEFAULT_CHANNEL_PATH, _ "RX_DATA_CALLBACK", _ $DATA_HOST_DEFAULT_LOG_FUNCTION) EndFunc Func RX_DATA_CALLBACK($hFile) $szDatum = FileRead($hFile, -1) $aszDatumBuf = StringSplit($szDatum, @LF, 2) If( $aszDatumBuf[1] <> @ComputerName ) Then RX_PARSE_COMMAND($aszDatumBuf[3]) EndIf EndFunc Func vars() ConsoleWrite($DATA_HOST_DEFAULT_CHANNEL_NAME & "::" & $DATA_HOST_DEFAULT_CHANNEL_PATH) EndFunc Func RX_PARSE_COMMAND($szCommand) ;__DROPBOX__TERMINATE("cerr") Local $oExecResult = Call($szCommand) ;__DROPBOX__INITIALIZE("cerr") __DROPBOX__COMM__WRITE($DATA_HOST_DEFAULT_CHANNEL_NAME, _ $DATA_HOST_DEFAULT_CHANNEL_PATH, _ $oExecResult, _ $DATA_HOST_DEFAULT_LOG_FUNCTION) EndFunc Func abort() cerr("In abort(), exiting.") Local $oRemoveResult = __DROPBOX__COMM__REMOVE_CHANNEL("comm", @ScriptDir) Exit EndFunc Func cerr($msg) ;__GENERAL__CERR($msg) ConsoleWrite($msg & @LF) EndFunc You may have to play with it to get it work. I just pulled this code from an environment that I didn't intend to release out as an example just yet.... but. Yeah. Let me know if you find a bug. -- Alex.

Want to write a priority queue with me in AutoIt (So much fun!)?

I'm guessing you can use the variable arguments functionality of AutoIt. Func Example2() ; Sample scriptusing @NumParams macro Test_Numparams(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14) EndFunc ;==>Example2 Func Test_Numparams($v1 = 0, $v2 = 0, $v3 = 0, $v4 = 0, $v5 = 0, $v6 = 0, $v7 = 0, $v8 = 0, $v9 = 0, _ $v10 = 0, $v11 = 0, $v12 = 0, $v13 = 0, $v14 = 0, $v15 = 0, $v16 = 0, $v17 = 0, $v18 = 0, $v19 = 0) #forceref $v1, $v2, $v3, $v4, $v5, $v6, $v7, $v8, $v9, $v10, $v11, $v12, $v13, $v14, $v15, $v16, $v17, $v18, $v19 Local $val For $i = 1 To @NumParams $val &= Eval("v" & $i) & " " Next MsgBox(0, "@NumParams example", "@NumParams =" & @NumParams & @CRLF & @CRLF & $val) EndFunc You may need to be rethinking your algorithm. Edit: junk

This isn't something that I've done in AutoIt, but I've done it it in a variety of other languages. I think the simplest way for you to get a taste of compression is to experiment with Huffman coding. It's not the most efficient compression algorithm, but it's definitely one of the simplest and easiest to understand. http://en.wikipedia.org/wiki/Huffman_coding One thing to remember though is that during the development process, make sure that you have the ability to output the compressed string in both binary and ascii form, because while you won't be compressing anything in the ascii form, you'll definitely have an easier time reading it. Compression algorithms are real fun to code. But in AutoIt, this will quickly become an exercise in data structures. -- Alex.

Hello everyone, I've been working on this for a couple of months now, improving as I go. I still think that all of you are going to take two looks at this code and laugh at me, but I'd really like someone to look at this. I've done a couple of things: I've written a stack data structure that performs pushes and pops is O(1) time. I've written a function that recursively copies a directory tree, and is capable of verifying files as it goes along the way. It will also use callback functions to notify your GUI and keep it from freezing up. I've make a function that will recursively list all the files in a given directory. I'm in the process of writing a script that allows scripts to communicate through dropbox and simplifies dropbox management. The scripts that allow scripts to communicate with each other can be used on files and folders other than dropbox -- think network share -- because the whole thing purely using files. All it depends on is that there is a place it can put a folder with a bunch of files in it. Whole ton of cool stuff, this is like 2500 lines of code. For the sake of simplicity, I've put the code up on GitHub. You can check it out at: https://github.com/alvonellos/AutoIt_Code-Snippets Comment if you plan on using it, are using it, or find any potential bugs. I've pulled this from production code, so if you see anything that shouldn't be there, let me know Take Care, -- Alex

Too much SPARC assembly. Doh. It's so easy to get mixed up.

Ah... I'm still not sure that Binary() is returning the proper representation of the number. It doesn't look right at all. Let me explain: F2 = 1111 0010 E4 = 1110 0100 72 = 0111 0010 44 = 0100 0100 DD = 1101 1101 10 = 0001 0000 E4 = 1110 0100 40 = 0100 0000 (Correct my math if I am wrong, I'm doing this in my head.) SO: 0xF2E47244DD10E440 = 1111 0010 1110 0100 0111 0010 0100 0100 1101 1101 0001 0000 1110 0100 0100 0000 = 64 bits SO: The first digit is the sign bit, it is 1 so the number is negative. 1 = - The next set, from 62 to 52 is the exponent field, and it is: 1110 0101 110 Which is, in decimal 1838 - 1023 = 815 Next up, from 51 to 0, we have the significand, which is: 0100011100100100010011011101000100001110010001000000 In decimal: 0.2778977046384767 Add the magic bit: 1.2778977046384767 Now we have to do the math 2^(Exponent - Bias)*Significand (with magic bit) And the result of that is: 2.7921744980454277e+245 And because the sign bit is 1, we add a negative: -2.7921744980454277e+245 ^That's the final answer. Maybe I'm not remembering my assembly correctly; however, I reversed the entire operation and got the same answer back. -2.7921744980454277e+245 The funny thing is. Reverse the order of the bits, and the answer is, coincidentally, what we want it to be (little endian vs big endian, maybe?) F2E47244DD10E440 = 40 E4 10 DD 44 72 E4 F2 ... Which equals ... 41094.914605567130 Am I an idiot? I dont' know. I'd love to write this thing in native AutoIt. It's always nice to have stuff run in native code... And it's looking like I need to brush up on my skills. They got a little rusty after not coding in assembly for so long. Take care, -- Alex EDIT: I wanted to add -- I'm going to find my notebook and look up my notes.