Development
From OpenCog
This is a page is the hub for development ideas and documentation. API documentation will eventually be generated using Doxygen and hosted separately, so these pages are more for developing ideas before they are implemented and providing guides and tutorials.
Contents |
Projects
There is a list of project Ideas for anything broadly OpenCog related, plus a list of Projects (mostly pre-specifications) for OpenCog Core development. Many of these ideas and project specs are part of the 2008 Google Summer of Code and they are described in more detail at GSoCProjects2008.
Documentation
- Design documentation coming soon
- BuildingOpenCog - How to download OpenCog source from bzr and compile.
- Development standards - Code formatting and development practices
Examples
- Cookbook - small examples and code snippets on how to perform regular tasks.
- Hopfield network emulator - using attention allocation dynamics to memorize patterns.
Screencasts
Ari Heljakka of Dream Broker has donated the use of Dream Screen accounts to OpenCog developers making significant contributions (for use in the development and demonstration of OpenCog).
A demo.
Future Planning
There are several architectural design tasks planned for OpenCog. Some are a long way off, while others are more of a priority. However, there have been discussions on these topics and so records are kept here to avoid rehashing the same arguments when we DO come to implementing these tools.
Interactive shell
An interactive shell to manipulate the AtomSpace is needed.
- Should we have a foreign language function interface, which thus needs to be run locally? or
- Do we have a remote shell that connects with OpenCog and sends commands/receives output. or
- Both?
SWiG can be used to generate the bindings between C++ and Python (as well as Ruby, Lisp, etc.). One can then use Twisted to create a remote Python shell.
Linas has implemented a Guile LISP interpretor and extended Scheme so there are functions for adding links/atoms. Joel Pitt 04:18, 29 May 2008 (CDT)
Swapping atoms
TODO: summarise email thread starting April 29th.
- Memcachedb is a distributed key-value storage system designed for persistent. It is NOT a cache solution, but a persistent storage engine for fast and reliable key-value based object storage and retrieval. It conforms to memcache protocol(not completed, see below), so any memcached client can have connectivity with it. Memcachedb uses Berkeley DB as a storing backend, so lots of features including transaction and replication are supported.
Visualization Tool
The basic idea is to allow AI engineers to more easily visualise OpenCog dynamics. As well as provide an interface for manipulating the AtomSpace and debug high-level processes (i.e. not code errors, but erratic or unwanted system dynamics). It is discussed in more detail here VisualizationToolIdeas.
Multithreading
Currently OpenCog is single threaded. Making it multithreaded is highly desirable.
Some considerations:
- Will a single instance of a MindAgent be expected to run at the same time? Or will multiple instances be created on the off chance a MindAgent runs at the same time.
- Locking the AtomTable. What form should this take? Should each atom have a mutex? Each AtomType? Should MindAgents be expected to hold access only briefly per write, or to intelligently obtain locks trading freedom of other agents to make changes versus efficiency.
(Note from Joel: IANAMTA - I Am Not A Multi-Threaded Architect)
Distributed processing
Peer to peer systems:
- Using Skype as a p2p platform was discussed generally on the AGI mailing list. [1]
- n2n [2]
- Berkeley Open Infrastructure for Network Computing (BOINC) [3]
Optimization
- CUDA - utilize the power of NVIDIA consumer graphic cards [4].
Atom roles
Tables of atom properties such that MindAgents can associate arbitary properties with atoms.
