.
FRDCSA | internal codebases | UniLang

UniLang Architecture Diagram: GIF

Jump to: Project Description | Capabilities

Project Description

unilang is a system for providing the services you would expect from a Multi-agent System (MAS), and more. It allows IPC between different Agents connecting through sockets, and also has packages which client Agents can use to do most of the work, based on Event.pm.

The classifications are not correct, but, whatever.
[icodebase-capability-request, capability-radar, capability-unilang, solution-to-extant-problem, goal]
I think we should have some kind of autoformatting for unilang.
[capability-manager, unilang-specific-message, observation, shopping-list-item, complex-statement]
Great - corpus is working well, if a bit slow.
[shopping-list-item, complex-statement, capability-manager, unilang-specific-message, observation]
Now all we have to do is fix that data and worry about complexity/efficiency issues with corpus doing autoclassification.
We also have to add more elegant classification than bayes, as well as talking amongst agents to support better categorization and command execution from our notes.
[shopping-list-item, complex-statement]
I wonder how much memory this takes up.
[icodebase-capability-request, goal, solution-to-extant-problem, capability-radar, capability-unilang]
Maybe there's a way to save classifications models so the whole thing need not be reloaded.
[complex-statement, icodebase-capability-request, capability-radar, capability-unilang, solution-to-extant-problem]
unilang agents should, defined through audience, have a nominal state that allows unilang while dynamically starting them upon messages received for them (so they don't all have to start at once), that indicates they are ready for processing.
[goal, icodebase-capability-request, capability-radar, solution-to-extant-problem, capability-unilang]
Should define a general purpose classification scheme - so that the system can get really specific about what it just classified.
[capability-manager, shopping-list-item, complex-statement, observation, icodebase-capability-request]
Complex-statement for instance can be checked for using get_sentences
	[observation, shopping-list-item, complex-statement, capability-manager, unilang-specific-message]
Debugging unilang is rather difficult and we don't want to fall prey to the same problem as with GNU Hurd.
[capability-manager, goal, observation, shopping-list-item, complex-statement]
Now we have enough demos to definitely get people working on our projects.
Mike is right that I should learn persuasion.
[shopping-list-item, complex-statement, unilang-specific-message, capability-manager, observation]
We have to hurry, though.
[unilang-specific-message, observation, complex-statement, shopping-list-item, icodebase-capability-request]
You know, should set up regression testing soon.
[shopping-list-item, complex-statement, capability-manager, unilang-specific-message]

  Lord, don't let me fall, don't let me FALL!
1unilangunilang-ClientMon Oct  2 22:41:05 CDT 2006No one here by that name.

Capabilities

• unilang should have the capability to disconnect idle agents.
• Need to resolve time issues with unilang now that it is being used for certain important tasks.
• unilang should support RPC.
• note that I'm not sure all unilang.xml messages made it into the system.
• Write code to lookup contents of unilang message from ID.
• Some ideas for unilang. 'screen -r' and 'daemon' might assist with the type of agent interface we want. Right now, the problem with unilang is many fold. But I won't deal with this problem, I will side step it and start cso manually.
• Replace fortune with unilang or score messages.
• /var/lib/myfrdcsa/codebases/internal/unilang/start corpus ELog unilang-Client
• Use Jabber for unilang backend?
• unilang should also reply that the agent is not active.
• unilang should store messages for agents if they are not active.
• Write pid software for unilang.
• Figure out how to use a different mechanism for unilang messaging.
• Use Proc::Daemon and Sys::Syslog or some other logging facility to create daemons out of unilang agents, allowing for proper starting and stopping of all daemons. Add the code into the unilang client software.
• Create a fortunes file from my unilang db.
• Integrate email and unilang processing of todo items.
• In some sense unilang is mistaken because the simple TODO file mechanism would suffice?
• Figure out why unilang is not starting correctly the first time.
• Should use a tags system to boot strap the classification of unilang notes.
• Have it generate long flags like ./unilang-command --upload-all-contents-of-wiki
• unilang should really function as an /etc/init.d/ service.
• In fact, any task should relate to some entries in unilang as well as specific code.
• Perhaps add to unilang a flag to determine whether or not to log certain events. Actually unilang is supposed to judge that for itself.
• Every now and then unilang just kind of dies.
• unilang is kind of like my blog. Should have it blog for me, through socbot of course.
• unilang should give messages or talk to the user if it fails to log to SQL or some such thing.
• Definitely fix problem with unilang hogging the processor.
• Fix problem with unilang hogging everything.
• /var/lib/myfrdcsa/codebases/internal/unilang/start audience broker clear corpus cso ELog manager OpenCyc pse unilang-Client
• Probably want to convert unilang to a system service pretty soon.
• Get sinless micro reports to not have to pop up something. Maybe switch to unilang.
• Just have to unilang enable manager/Spark
• Lookup requesttracker. See if we can't use that as the basis for our systems, and just have unilang messages get piped into that.
• Predict unilang-Client entries.
• Worry about Spark OAA interaction later. Also write wrapper between unilang and OAA.
• Make sure the unilang entries are also color coded.
• Get event log prediction stuff working, so that the stochastic planning system can estimate the time of certain events. For instance, if mom get's home at a certain time each day, the event log should be able to generate a probability distribution as to when that event is going to happen next and again etc. That could then be used to estimate the probability of various task completions. We want to have a general language that we can use to query this. I suppose unilang can serve as the basis for this general language.
• Depending on the mood of the user, unilang can ask questions to disambiguate entries.
• Remove elog entries from unilang and get it filtering messages.
• /var/lib/myfrdcsa/codebases/internal/unilang/start audience broker clear corpus cso ELog OpenCyc pse unilang-Client
• Note that unilang should become a system service.
• Add duplicate detection to corpus feedback for unilang.
• Should use WSD on corpus entries and also run ExtractAbbrev.java on them to get abbreviations like Emacs unilang agent, run this through termios, and use that to boot strap translation. Also do anaphora resolution by running it on chunks of aligned texts.
• If an emacs unilang agent command finds that unilang is not running, start it.
• unilang client or the like should be able to run shell commands. Example is if clear crashes, and we want to restart it within the window, without having to restart everything.
• evangelist or hypermedia or whatever can control Emcas over UEA. Elements should be generalized into interfaces, to allow user input bcak from the different programs. Other programs can schedule elements. all interaction takes place as interactive movie. Can be used for collaborative/telepathic interface. Use unilang to distribute data over network. Add authentication to unilang over iSAKMP VPN.
• The planning system should actually send messages over unilang and all the programming be handled in Perl.
• Let's get manager going by turning him into a unilang agent and allowing him to send messages, or execute programs. For instance, if the daily items haven't been done by the end of the day, manager reports that.
• Write some Emacs wrappers for Emacs-unilang-Client. In fact, specify the entire API.
• unilang should do basic RPC.
• It is recording the messages send back from corpus to unilang-Client, not necessarily relevant.
• Have to deal, during classification of unilang messages with the possibility that it is actually a multipart.
• Debugging unilang is rather difficult and we don't want to fall prey to the same problem as with GNU Hurd.
• unilang agents should, defined through audience, have a nominal state that allows unilang while dynamically starting them upon messages received for them (so they don't all have to start at once), that indicates they are ready for processing.
• Could have a specific messaging format for unilang.
• I think we should have some kind of autoformatting for unilang.
• Determine whether using ID will break unilang.
• Should we have an unilang SQL agent?
• Maybe we can determine all instances of unilang debugging and not record those or something.
• Can apply clear topic jisting to unilang messages.
• Could write a manager::Dialog interface for unilang.
• Turns out there is no problem with unilang sql data, just with my visualization script.
• Note that the unilang data is corrupted in the sense that when converted, the max hour is 12:59:56
• What happens when unilang uses all the IDs.
• Adapt unilang to use SQL.
• Immediate subgoals: get unilang logging to SQL.
• sinless should record what type of temptation the user experienced and log that through event stream or unilang.
• We can extract project creation and renaming information from the unilang log by looking at first appearances of new names...
• Check out "error in process filter" error with Emacs-unilang-Client
• (Here is the todo for unilang/corpus/pse)
• (The key to this is to get unilang using SQL for its logging)
• They could use unilang to send messages reporting violations.
• Use a model of textual context to provide addition information that could use LSI for classification and clustering - to improve accuracy of unilang stuff.
• Solve problem with unilang-client quitting when using clear.el stuff
• Have unilang automatically deregister closed lines.
• In order to use critic in Emacs on Sorcerer data, simply send the list to unilang-emacs-client via some new function that converts it into an alist and browses it with some dired like editor.
• Everywhere I turn - problem. Cannot figure out. Why, network won't work for unilang, nor why, network won't work for Sorcerer! Blarg.
• Should put an authentication layer into unilang.
• Use picform Contexts for unilang classification, study assignment, etc. Eventually, develop Context classifier as part of critic?
• unilang agents should have a message QUEUE as part of their API.
• Looks like, if they can use Weka for information extraction, I can use it for classifying unilang messages.
• unilang/pse should also consider the changing landscape of requirements, when asserting these.
• RSR should look to see whether I am "blogging" to unilang about my family, and deal with me summarily.
• Or they could use a standard length like "AUDIENC: unilang: clear--: BUSROUT: etc
• Should be able to start an agent from this window, have a unilang, start agent audience, type feature.
• Should add a prompt to unilang-Client
• Need to figure out the unilang name system very quickly.
• Seems obvious to me now, CHILL is used to map sentences to semantic representations. That is how we formalize messages sent to pse and maybe unilang, etc.
• Write functinoality that will allow unilang to start agents itself
• The way other programmers are probably effective is by having special keys to load stuff for a given file. So, while we have this too, how does this compare to unilang? I suppose unilang, well, ideally unilang does a lot of nifty stuff - since it's ushell, you could add those hooks right into ushell.
• Improve the unilang naming scheme.
• Need to make sure that you can change the speed of that one system. You could rebuild and make it a unilang agent I'm sure.
• Come up with agent debugger framework for unilang.el, that is, you load it up and it helps you debug the unilang agent you are developing.
• I was just thinking that there is absolutely no hope that anyone could or would learn my system, but that's not true. For instance unilang is very effective, so what we need is to just heighten that.
• One way to make myself more effective is this - when I type an instruction, like "get latest knoppix dvd" into unilang, it is going to route this to the appropriate agent using the agent management system.
• Check that messages contents that match /^\w+,/ are being archived by unilang log
• Come up with grammar for using busroute, to allow it to be used over unilang.
• Fix bug with unilang-emacs-agent, where it aays args out of range, when receiving certain messages
• Convert unilang to a system service
• Making Emacs into a unilang agent greatly increases our abilities here.
• One possible thing to do is write something for unilang that interfaces with the corpus classifier.
• Convert busroute to be a unilang agent, by tomorrow
• Perhaps unilang messages ought to be stored in an sql database.
• If it's not obvious, unilang will be using corpus to classify the users entries.
• wow I got corpus working sort of. That's good news. It is now classifying unilang log messages,a dn doing a rather good job.
• The unilang interface does not serve this need.
• /var/lib/myfrdcsa/codebases/internal/unilang/start pse OpenCyc unilang-Client
• Josh seemed to like the unilang system.
• Also need unilang or corpus to record which messages have already been addressed.
• perhaps I could write a system that analyzed my log files for instances of ideas that I'm not supposed to write about. This would be an effective way ! Yes! To curb this. all I need to is write it and add it to unilang.
• Of course, make sure to use Conversation perl module in corpus analysis of unilang.xml
• Move the log reading utils to unilang and provide searching and so forth of logs.
• for unilang?: http://freshmeat.net/projects/pkt/?branch_id=50215&release_id=186636
• In case I forgot to mention this, run clustering on unilang-client logs.
• Ensure that unilang messages which are being incorrectly interpretted are nonetheless still being logged.
• Commission study of performance issues for event.pm given current unilang system
• Change that "stream of consciousness MAS" thing on unilang - looks silly
• unilang might employ routing rules.
• Now here's the kicker, its obvious now that we want a way to send perl data structures over unilang.
• In this way, way point routes can be had. I wish we had a waypoint DB of CMU's campus. I suppose that would not be too hard to generate. It would be nice to have connectivity information gleaned in this way. The most important point of all of this is prevent me from making the mistake of say going to the undergraduate lounge. Permission for any movement is to be had. Also, permission for any social interaction is to be had. Machiavelli, I suppose, must ultimately represent this list, not audience. Agentifying everything has the negative affect of forcing a certain design philosophy on all software, and a bad one at that since unilang is so primitive conceptually.
• For all agents. I.e., unilang::agent::agent should parse that automatically.
• Need to incorporate classification technology into most systems. Such as, don't log classified concepts in unilang, etc.
• Build an ontology of unilang messages, so for instance, some of them will be of the type "Yam would assist radar", i.e., relations asserted between software systems.
• /var/lib/myfrdcsa/codebases/internal/unilang/start pse opencyc unilang-client
• (Just checking that time management was fixed in this version of unilang).