AutoHotkey Community

[Dra_Gon]

That is excellent! I'm running you're already compiled one now. And you did this while BORED? Criminy!
Now how about a few predators for the bugs to fight off? And perhaps "territories" to defend against other bugs?
Totally impressive, to say the least.

Ciao,
Dra'Gon
_________________

For a good laugh {hopefully} >> megamatts.50megs.com

My WritersCafe profile>>
http://www.writerscafe.org/writers/BlueDragonFire/

[Slanter]

[Dra_Gon]

Well my bugs are still dyin' off, dagnabit! Of course, the same thing happens when I try to keep plants so I'm not surprised . Still a great little diversion!

Ciao,
Dra'Gon
_________________

For a good laugh {hopefully} >> megamatts.50megs.com

My WritersCafe profile>>
http://www.writerscafe.org/writers/BlueDragonFire/

[lrh9]

I know it's generally bad forum etiquette to resurrect a dead post (The original poster has been away since December.) However, since the topic of this post has not been discussed else where, I'll go ahead and post here.

I'd first like to make a suggestion for the original problem of having a script that could grow. Instead of having a large script that kept rewriting itself to increase its abilities, why not create a central script that could write and execute other scripts without having to modify itself?

[Jex]

I don't think it really matters how you would store extensions onto the main script. Though it would probably be easier to have separate files from a human stand point.

In my opinion depending on the language you were to write the code in it could be troublesome (for the AI) to figure out what each extension does if they were separate files.

But you could over come that by forcing each extension to have 2 or 3 methods/functions/subroutines detailing it use.
_________________
Woot.

Please read forum etiquette

[lrh9]

Well. My main interest is a.i. The reason why I found autohotkey is because I realized I'd be using a lot of functionality that macro recorders provide in my attempt to create a general purpose artificially intelligent computer program. Right now I'm working on a catch-all input system (keyboard, mouse, forms, etc.) for the a.i.

[XeonXT (NLI)]

[lrh9]

I'm approaching the problem using Alan Turing's child machine approach. Like him, I believe the first super-human generally intelligent program or computer will be a "learner" vs. a "knower", meaning that the a.i. will initially know nothing but learn as human children do.

I mentioned that I was programming a catch-all input system. I also want to program Internet and network interactivity as one of the input/output features of the a.i., as well as modeling the a.i. as an agent with basic "brain" functions such as recording information to and reading it from a file dynamically.

I think that higher level abilities required for truly intelligent action such as problem solving, planning, and logic are learned or taught (programmed), so I hope to program it to accomplish those things as well as language processing and perhaps ocr and image recognition.

The measure of my success will be how well the a.i. can accomplish goals (ones that it is familiar with - such as run application x, and ones that it is unfamiliar with - such as original research or subgoals necessary to accomplish a high level goal).

The program might best be summed up as a dynamic, constantly running interpreter for the autohotkey language, but modeled to have separation of functions and general input/output interfaces between the program and the user and between the components of the program itself.

[lrh9]

As for the actual implementation of the a.i. in autohotkey, this is what I've worked out so far.

1. The a.i. script will essentially model the human brain. It will be responsible for storing and retrieving data pertinent to itself to and from memory (both files - fileread/fileappend/etc. - and memory - numget/numput) and sending and retrieving data and signals to and from its input/output modules, performing calculations (and possibly comparisons), executing code/scripts/programs, and management of itself to an extent.

I quickly realized that users would want more than one instance of the a.i. running. Ultimately, I realized this would mean that each instance of the a.i. script would have to be uniquely identifiable. Obviously, I could not know how many scripts the user would want beforehand, so I couldn't make that many with unique names, and for the user to do so would be inefficient. So I realized a manager system would be appropriate.

2. The manager system would start on computer start-up and be responsible for ensuring that each a.i. script was uniquely identifiable and ensuring that tasks were assigned to the appropriate a.i. script. Each time an a.i. script started, it would query the manager for a unique identifier. The manager would generate one (ensuring that it is indeed unique by checking that it isn't a currently used a.i. identifier), and assign it to the a.i. There are more features that need to be worked out, but the basic premise is sound.

3. Input/output modules. Much like the manager system controls multiple a.i.s, the a.i. would have multiple input/output modules that it could generate and utilize. The system would utilize messages to ensure that data and commands got to and from the appropriate modules. Examples of modules include reading/downloading from the internet, getting data to and from the clipboard, displaying messages, storing and retrieving non-a.i. data to and from memory, etc.

One of the major subsystems of input/output is the catch-all input system I mentioned. Autohotkey was obviously intended to be utilized by a user with a personal computer and one mouse and keyboard input device (most users). Those two devices will be key in interacting with the a.i., but it must be organized. At first I envisioned this system to be a constantly running monitor recording mouse and keyboard data, but this would be inefficient if the data wasn't needed by any script. Now I'm thinking that a script will invoke this system if it needs mouse and keyboard information, and the system will operate depending on how long each script needs it. For instance, say there are two scripts.

One that needs to collect input data for five minutes or a certain condition is met, or one that needs to collect input data for ten minutes or a certain condition is met. As long as the ten minute script's alternate condition isn't met, the keyboard and mouse will be monitored for ten minutes. However, if it is met, there are a two scenarios. 1) The five minute script is still running. That means keyboard and mouse data will be monitored for the time remaining on the five minute timer or until its alternate condition is met. 2) The five minute timer is no longer running or its alternate condition was met. In which case the monitor will cease.

Due to the system's similarity to a keylogger, this raises security concerns that may have to be addressed in the next system.

4. A security system. A obvious necessity when working with anything capable of drastically altering its environment based on instructions and conditions other than what you place upon it. I have neglected planning this for the moment because working on the other parts is much more exciting. However, the system needs to be built around a model of two users working in the same user space. (There will be you, and the a.i.(s)) You are the more privileged and protected user, so your files/processes/etc. will have to be protected from the a.i. in case something goes wrong, and the a.i. will have to obey your commands. Portions of the security system may reside in its own script, or they may also have to be placed in the a.i. systems.

[lrh9]

Two months since my last update... ouch. I'm still working on the project. It's not abandoned. I've completed a large portion of the main a.i. script and I recently considered new ideas and had to perform some more research. I'm just about finished collecting information and after analysis I'll be able to resume work with a hopefully better and/or clearer direction. Most of my notes and discussions about the project and a.i. are on other sites. I post at http://aidreams.co.uk/forum/index.php?action=forum and www.ai-forum.org under the same user name.

[lrh9]

I'm sorry, but I think that I will not be able to use AutoHotkey to effectively build the program. I realized that some of the functionality of my program would depend on being able to utilize real threads and multiprocessing, and unfortunately AutoHotkey falls short in that department.

Another issue that is relatively unimportant but still an issue is that AutoHotkey is effectively limited to Windows at the moment. I know there are attempts at porting AutoHotkey or writing it using an API, but I'm not sure they are as complete as the original program.

So after some research, I've decided to try Python this time. It has modules for threading and multiprocessing, and according to its website it can run on several operating systems. Please don't take this badly. You have a good thing here.